L’industrie a réglé ce problème il y a longtemps, et pas avec des consignes. Elle a inventé le détrompeur : une pièce dessinée pour qu’elle ne puisse pas être montée à l’envers. La prise qui n’entre que dans un sens, la carte SIM au coin coupé. La consigne devient inutile, parce que l’erreur est devenue impossible.
Mon métier consiste à poser des détrompeurs dans un logiciel. Une règle qui compte n’est pas un paragraphe dans une documentation : c’est quelque chose qui échoue, bruyamment, à la seconde où on la franchit. Avant la mise en ligne, avant vos clients, avant l’incident.
Ce que cela change pour vous
- Vos équipes n’ont plus à se souvenir de tout pour ne rien casser.
- Ce qui protège vos clients ne dépend plus de la mémoire de la personne qui l’a écrit : cela ne part donc pas avec elle.
- Vos outils IA travaillent à l’intérieur d’un cadre, au lieu de travailler à côté.
Ce que cela vous achète : pouvoir continuer à changer votre produit sans redouter ce que la modification va casser ailleurs.
C’est aussi, à mon sens, ce qui décide si le développement assisté par IA tient dans la durée. Une machine produit du code plausible — et plausible est exactement la propriété dangereuse : cela passe la relecture, et cela cède en conditions réelles. Ce n’est pas un problème de modèle. C’est un problème de frontière.
Trois exemples, pris sur mes propres systèmes
Les trois exemples qui suivent sont pris sur mes systèmes, pas sur ceux de mes clients : un dispositif s’éprouve chez moi avant d’être proposé ailleurs.
Une application qui doit fonctionner sans réseau, tenue par deux verrous
Latitudes est l’un de mes laboratoires : aucune version n’en a été publiée, et personne d’autre que moi ne s’en sert. Sa règle principale : ce que l’utilisateur y fait chaque jour ne doit jamais dépendre d’une connexion. Dans l’application mobile, un seul dossier a donc le droit de parler au serveur, et exactement deux fichiers ont le droit de l’atteindre. Cette liste est nominative, et elle est tenue par deux vérifications indépendantes : l’outil qui relit le code pendant qu’on l’écrit, et un test qui exige l’égalité exacte, ni un fichier de plus ni un de moins.
Pourquoi deux plutôt qu’un ? Parce qu’un verrou unique se retire en une modification discrète. Deux verrous se retirent en se voyant.
Des règles d’exploitation nées de pannes réelles, pas d’un guide de bonnes pratiques
Les serveurs qui portent mes projets sont gouvernés par une liste écrite de règles qui ne doivent jamais être enfreintes — des invariants. Elles ne viennent pas d’un guide de bonnes pratiques : elles sont écrites à partir de pannes que j’ai eues, et formulées pour que la même panne ne puisse plus se rejouer sans être vue.
Un exemple, lisible sans être développeur. Quand un logiciel s’arrête sur une erreur, il indique le fichier et la ligne en cause : c’est ce qui permet d’aller corriger au bon endroit. J’ai vérifié cette indication sur l’un de mes projets, aux 97 endroits où son code peut lever une erreur. Le fichier compilé n’en désignait la bonne ligne que 4 fois. Partout ailleurs il envoyait à une ligne fausse, et rien nulle part ne signalait l’écart. Après correction de la façon dont le code est compilé : 92 fois sur 97. C’est le type de défaut qui ne casse rien et ne se déclare jamais — on corrige au mauvais endroit en croyant être au bon.
Un second exemple, moins flatteur, et c’est précisément pour cela que je le publie. Un des composants que je publie pour installer mes propres serveurs est resté accessible à n’importe qui pendant neuf jours, du 8 au 17 août 2026, alors que le dépôt — l’endroit où le code est conservé et relu — était privé. Aucune relecture de code ne pouvait le voir : ce réglage-là ne vit pas dans le code. L’invariant qui en est sorti tient en une phrase : ce qui ne vit pas dans le dépôt se sonde, il ne se relit pas. Un contrôle automatique s’en charge désormais à chaque publication, dans chacun des dépôts concernés, et il échoue aussi lorsqu’il n’est pas concluant, au lieu de conseiller de réessayer.
Des agents IA qui contribuent au code sous contrainte écrite
Plume est mon second laboratoire : un environnement d’écriture longue assistée par IA, sans utilisateurs en dehors de moi. J’y travaille la question que rencontrent mes clients — faire contribuer des agents IA à un code sans que sa cohérence se dégrade, mois après mois.
Les agents n’y reçoivent pas des conseils, mais des règles écrites : ce que la règle interdit, l’incident qui l’a fait naître, et la commande qui prouve qu’on l’a respectée. Un fichier de contrôles de 503 lignes relit le code à chaque vérification et refuse les écarts. Cinq fichiers produits automatiquement à partir du code — dont la description de l’interface du serveur — sont enregistrés dans le dépôt, puis régénérés et comparés à chaque vérification : la moindre différence arrête tout.
C’est ce dispositif, transposé à votre dépôt et écrit à partir de vos incidents à vous, que j’installe en mission.
Ce qui tient par la relecture, je l’écris
Toutes les règles ne peuvent pas être rendues mécaniques. Sur Latitudes, la décision de ne pas mettre d’IA dans le moteur qui compose la journée tient par la structure du code et par la relecture, pas par une vérification automatique. Je l’inscris noir sur blanc plutôt que de laisser croire l’inverse.
Un inventaire honnête vaut mieux qu’une garantie approximative.