Je ne documente pas les règles. Je fais en sorte que le système les refuse.

La phrase qui sépare deux développeurs

Il y a deux façons de tenir une règle importante dans un produit.

La première : l'écrire. Dans un wiki, un commentaire, un message Slack épinglé. « On ne doit jamais requêter les données d'un autre client. » « Pensez à masquer les PII. » « Vérifiez la marge avant de pousser un plan. » Ça marche — jusqu'au jour où quelqu'un oublie. Un nouveau dev, un vendredi soir, un copier-coller. La règle était vraie ; elle n'a pas tenu.

La seconde : faire en sorte que le système refuse de violer la règle. Pas un rappel. Un mur. Le code ne compile pas, le CI bloque le déploiement, l'objet métier rejette sa propre création.

C'est, je crois, la vraie ligne de partage entre un senior et un dev qui se croit senior. Voici cinq fois où je l'ai appliquée, sur du code en production.

1. SaleCast — l'isolation entre clients, refusée à la compilation

La peur n°1 d'un acheteur de SaaS B2B : « est-ce que mes données peuvent fuiter chez un autre client ? ». Sur SaleCast, la réponse n'est pas « on fait attention ».

Chaque requête est filtrée par identité de client (tenant) au niveau du moteur de base. Le seul moyen de contourner ce filtre — IgnoreQueryFilters() — est traqué par un contrôle au build : tout usage non explicitement justifié fait échouer la release. Un dev ne peut pas livrer un accès cross-tenant par inadvertance. La règle « on ne fuite pas les données d'un client » n'est pas dans un wiki : elle est dans le pipeline.

2. Matchr — la rentabilité, dans le CI

Un produit GenAI qui n'a pas de marge sur le coût des appels IA meurt en silence : chaque utilisateur creuse le déficit. Sur Matchr, le coût de l'IA est traité comme une contrainte d'architecture, pas comme une ligne de facture qu'on découvre.

La règle est codée : un plan tarifaire qui ne couvre pas au moins 2× le coût IA estimé est refusé au déploiement. Pas « on vérifiera la marge » — le CI bloque. La rentabilité n'est pas un tableur à part, elle est dans le build.

3. Vouch — « cité, ou rejeté », dans l'objet métier

Sur Vouch, une réponse de conformité (SOC 2, ISO 27001) sans source citée est pire qu'inutile : elle peut coûter un deal. La garantie « chaque réponse est citée jusqu'au paragraphe source, ou rejetée » aurait pu vivre dans un service que les devs appellent. Mauvaise idée : un jour, un call site oublie de l'appeler.

Alors l'invariant vit sur l'objet métier lui-même : une réponse haute confiance sans citation est rejetée à sa création. Aucun chemin de code futur ne peut la contourner — même par accident. C'est la différence entre « on s'engage à ne pas halluciner » et « halluciner est techniquement impossible ». La seconde formulation est la seule qu'un responsable conformité accepte.

4. OneRP — le compilateur comme garde-fou d'équipe

Sur OneRP, j'ai supprimé tout le REST au profit d'un canal temps réel auto-invalidé. Le risque : qu'un dev de l'équipe casse le pattern sans s'en rendre compte (un appel HTTP par-ci, un cache manuel par-là) et fasse s'effondrer la scalabilité.

Plutôt que de surveiller ça en revue de code, j'ai écrit des analyseurs Roslyn qui refusent les anti-patterns à la compilation. Le pattern d'architecture n'est pas tenu par la vigilance de l'équipe — il est tenu par le compilateur. N'importe qui peut contribuer sans casser la base, même un nouveau venu, même fatigué.

5. MyRoadTrip — le conflit de données, structurellement impossible

Sur MyRoadTrip, deux personnes éditent le même voyage, parfois hors réseau pendant des heures. La plupart des apps « choisissent » alors arbitrairement quelle version gagne — l'autre perd son travail.

Je n'ai pas écrit une logique de résolution de conflit (fragile, pleine de cas particuliers). J'ai utilisé un CRDT (Yjs) : une structure de données conçue pour fusionner sans conflit. Le conflit de fusion n'est pas « géré » — il est structurellement impossible. La garantie est dans le type de données, pas dans mon code applicatif.

D'où vient ce réflexe

Il ne vient pas du web. Il vient de l'IoT industriel : du firmware embarqué produit à l'échelle de 150 000 systèmes par an. Là-bas, on ne « patche pas en prod » — un bug part chez 150 000 clients et y reste. Quand c'est le contexte, on apprend vite à concevoir les contraintes en amont, parce qu'il n'y a pas de filet en aval.

J'ai gardé ce réflexe sur tout le reste. C'est exactement ce qu'on cherche chez un senior à qui on confie un système critique :

Quelqu'un qui ne fait pas confiance à la mémoire humaine — la sienne comprise — pour ce qui coûte cher. Quelqu'un qui déplace les règles importantes là où on ne peut littéralement pas les oublier : le compilateur, le CI, le type, l'objet métier.

Le bénéfice pour vous est concret : moins d'incidents, une équipe qu'on peut faire grandir sans tout casser, et des règles qui survivent au départ de la personne qui les connaissait. Parce qu'elles ne sont plus dans sa tête — elles sont dans le système.