La qualité ne se relit pas. Elle s'exécute.

---

Oui, je fais confiance aux modèles de pointe. Je les éprouve tous les jours, sur des scénarios très différents, et je sais assez précisément ce qu'ils produisent : où ils sont excellents, où ils dérapent, ce qu'ils rendent quand la consigne est mauvaise. Cette confiance n'a rien d'aveugle. Elle est le résultat d'un étalonnage quotidien.

Et elle ne prouve rien.

Ma confiance parle de moi, pas du logiciel. Elle ne se transmet pas, elle ne s'audite pas, et elle ne vaudra rien devant quelqu'un qui demande comment nous garantissons qu'une trace d'audit est écrite. C'est pour cela que je ne relis plus les diffs ligne à ligne, et que j'ai construit autre chose à la place.

Ce que « qualité » veut dire ici

Le logiciel qu'on écrit — Solstice*, un ERP pour un groupement d'hôpitaux publics — gère des dossiers patients. Ce contexte décide de toute la définition.

Ici, la qualité n'est ni une note ni un décompte de défauts. C'est une courte liste de propriétés qui doivent être vraies après chaque changement, sans exception :

• Une écriture qui peut nous être opposée porte une trace d'audit légale, et l'écriture est refusée si la trace ne peut pas être écrite.
• L'identité d'un utilisateur ne se déduit jamais de quelque chose que l'appelant peut taper.
• Les champs régulés ne sortent jamais en clair.
• L'accessibilité n'est pas un confort. Dans la commande publique française, c'est une obligation légale avec un référentiel nommé.
• Le contrat d'interopérabilité que nous publions décrit ce que le déploiement sert réellement.

Aucune de ces propriétés ne se vérifie en demandant « est-ce que la fonctionnalité marche ». Chacune peut être violée en silence par une fonctionnalité qui marche parfaitement. C'est tout le problème, et il existait bien avant les agents.

La qualité n'est pas l'absence de bogues. C'est l'ensemble des propriétés qui survivent au changement suivant.

Pourquoi la relecture a cessé d'être l'instrument

Deux raisons, et une seule concerne le volume. Le volume est réel et tout le monde l'a constaté : il arrive chaque semaine plus de code qu'aucune équipe n'en lit vraiment.

La seconde tient même avec un temps de lecture infini. Relire un diff est un instrument fait pour trouver une ligne fausse. Les défauts qui passent sont le plus souvent une ligne manquante, dans un fichier que le diff n'a jamais ouvert.

On ne remarque pas une absence dans un document qui ne la contient pas.

Près de la moitié de nos contrôles existent parce que l'obligation traverse les fichiers. Une classe de ressource annoncée dans le contrat public oblige à provisionner une adresse dans le fichier de déploiement. Un port publié à côté de la passerelle supprime silencieusement l'authentification qu'elle assure. Le changement relu est localement correct ; l'obligation vit là où le relecteur ne regarde pas. C'est exactement là que la revue humaine est au plus faible et un script au plus fort.

Un résultat a changé ma façon de lire une proposition. Une étude acceptée à MSR 2026 mesure que les propositions écrites par des agents portent nettement plus de code redondant — et que les relecteurs les ont jugées plus favorablement que celles des humains. Un code idiomatique et bien commenté inspire moins de méfiance qu'il n'en mériterait. Il est plausible avant d'être juste, et c'est sur la plausibilité que le relecteur s'arrête.

Ce n'est pas une nouvelle espèce de défaut pour autant : un ingénieur fatigué oublie le même appel un vendredi après-midi. Ce qui a changé, c'est la cadence de l'omission et le coût de sa détection par la lecture.

Les 4 couches

Rien de tout cela n'est un jugement sur les modèles. Ces propriétés doivent tenir quel que soit l'auteur de la ligne : un agent, un ingénieur chevronné, ou moi un vendredi soir. Elles ne reposent donc plus sur l'attention de quelqu'un, mais sur du code qui s'exécute.

67 décisions consignées. Datées, versionnées, lues par chaque agent avant tout changement structurant. Elles portent la raison — la partie qu'un agent supprime au premier remaniement parce qu'elle ressemble à un accident. Aucun humain de l'équipe ne lit les 67. Moi non plus.

39 contrôles bloquants, dans 44 travaux d'intégration continue. Un par propriété, chacun né d'une erreur réelle. Une seule règle de conception les gouverne, et c'est la seule chose transposable de ce billet : dériver le périmètre du code, jamais le recopier. Une liste tenue à la main est fausse un renommage plus tard, et elle échoue en silence.

1 verdict avant la fusion. Une commande cadrée sur le diff, qui rejoue exactement les contrôles de la chaîne et imprime PASS ou FAIL. Elle ne prouve pas que le changement est bon : elle transforme « jette un œil » en une affirmation vérifiable.

1 périmètre humain, exprès. La surface joignable de l'extérieur, secret d'entrée statique et suppression destructrice. Revue obligatoire par un non-auteur. Nous aurions pu écrire un script ; nous avons décidé que cette erreur-là devait coûter une conversation.

Un mot sur la revue, parce que le mot induit en erreur. Chez nous elle est très majoritairement automatisée : des agents relisent des agents et rendent un rapport. L'humain ne lit pas les lignes, il lit ce qui s'est passé — et il assume ce qu'une machine ne peut pas assumer : les décisions opposables et les arbitrages de sécurité.

Une responsabilité ne se délègue pas à un modèle.

Rien de tout cela n'existe pour ralentir, et j'abandonnerais l'ensemble demain si c'était le cas. Une règle exécutable est ce qui permet de fusionner sans réunion. La vélocité et la qualité ne s'échangent pas ici : elles montent ensemble.

Comment on le prouve

« Nous avons des garde-fous » est une affirmation, pas une preuve. Un système qui impose des propriétés doit être mesuré, sinon ce n'est que de l'architecture pleine de bonnes intentions.

Nous mesurons sur une seule échelle : combien d'étapes un défaut franchit avant que quelque chose l'attrape. 6 étapes, dans l'ordre — la chaîne, la revue de code, le test manuel, la recette, le client pilote, la production. Chaque défaut porte l'étape qui l'a attrapé. Tout le reste en découle : densité de défauts rapportée aux propositions fusionnées, délai de correction par sévérité, taux de réouverture, backlog ouvert.

Les deux dernières étapes ont leur propre nom, et c'est le seul chiffre que je défendrais en comité de pilotage : les défauts échappés. Tout ce qui est trouvé chez le pilote ou en production a échappé à tous nos filets.

Cela redéfinit ce à quoi sert un garde-fou. Un contrôle n'est pas là pour faire baisser un décompte. Il est là pour déplacer une classe de défauts définitivement vers la gauche — de « un testeur le trouve » à « la compilation le refuse » — et cela ne revient jamais en arrière. Voilà pourquoi le nombre de règles exécutables compte davantage que le nombre de bogues. Un bogue corrigé peut revenir. Une règle écrite, non.

La question n'est pas combien de défauts nous avons trouvés. C'est jusqu'où chacun est allé avant que quelque chose l'arrête.

Ce que tout cela ne prouve pas

Ma confiance ne se transmet pas. Elle n'existe pas chez la personne qui arrive lundi, ni pour un modèle que je n'ai pas encore éprouvé, ni pour moi sur un sujet que je maîtrise mal. Les contrôles sont ce qui reste quand mon étalonnage n'est pas là.

Ça n'attrape pas tout, ça empêche de retomber. 39 contrôles encodent 39 défauts déjà payés. Chacun a été écrit après coup, une fois le mal fait. Nous ne pouvons plus refaire 39 erreurs précises — cela ne dit rien de celles que personne n'a encore remarquées.

Le verdict est étroit. PASS signifie qu'aucune règle connue n'est violée. La phase de bout en bout tourne sur des bouchons, jamais sur une vraie base. Plusieurs des défauts qui nous ont le plus appris seraient passés au travers.

Les deux dernières étapes sont vides parce que nous n'y sommes pas encore arrivés. Rien ne s'est échappé chez un client pilote ni en production, pour la bonne raison qu'il n'y a encore ni l'un ni l'autre. Les premiers tests sur site sont dans quelques semaines. C'est là que ces deux colonnes commenceront à se remplir, et que je saurai ce que tout ce qui précède vaut vraiment. La preuve la plus dure — ce qui survit à de vrais utilisateurs, sur de vraies données hospitalières — nous ne l'avons pas. Quiconque vous présente un tableau de détection dont les deux dernières colonnes sont vides vous montre un calendrier, pas un résultat. Moi compris.

Les contrôles attrapent la maladie qu'ils soignent. L'un des nôtres est né d'un changement de schéma qui ne s'appliquait qu'aux bases neuves : vert en chaîne, vert en local, cassé partout ailleurs. Sa première version avait un angle mort exactement de la même forme.

Les dérogations ne sont pas comptées. Environ 12 sont en usage, chacune avec sa raison écrite à côté. Un seul contrôle les compte dans le temps. Rien n'empêche un agent d'écrire sa propre exemption pour se rendre vert. C'est la faille ouverte de tout ce qui précède, et je n'ai pas de correctif.

Ce qui reste aux humains

Être surpris le premier. Chacun de ces contrôles existe parce qu'une personne a senti que quelque chose clochait et est allée regarder. Aucune règle n'a jamais écrit la première règle.

Décider ce qu'un défaut signifie. Qu'un contrôle ne soit pas atteignable au clavier est un fait technique. Que cela nous mette en défaut sur une obligation légale d'accessibilité, et bloque donc une livraison au lieu de rejoindre un backlog, est un jugement.

Juger une dérogation. Une exemption marquée dans le code n'est auditable que si quelqu'un va la lire — le marqueur ne s'audite pas tout seul.

Signer. Une décision opposable engage quelqu'un, et un modèle ne peut pas être ce quelqu'un. Ce n'est pas une limite de la génération actuelle. C'est le sens du mot.

Et la question qu'aucun contrôle ne pose : est-ce que ça devrait exister.

Rien de tout cela n'est un argument pour moins de monde. Ce sont les gens qui sont surpris les premiers, et être surpris est la seule partie de tout ceci qui ne passe pas à l'échelle en écrivant plus de scripts.

Quoi faire lundi matin

1. Écrivez les propriétés, pas le processus. Cinq phrases qui doivent rester vraies après chaque changement. Si vous ne savez pas les nommer, aucun outillage ne les protégera.
2. Étiquetez chaque défaut avec l'étape qui l'a attrapé. Un champ, et c'est la mesure la plus rentable de tout ce billet. Sans elle, vous comptez des bogues au lieu de mesurer leur portée.
3. Prenez un incident déjà payé et transformez-le en contrôle bloquant cette semaine. Pas une politique. Un incident, un script.
4. Préférez les obligations qui traversent les fichiers, et dérivez chaque périmètre du code. Tout ce qu'on tient à la main dérive, et ça dérive sans bruit.
5. Comptez vos dérogations contre une référence qui ne peut que décroître. Un seul de mes contrôles le fait. Il devrait y en avoir 40.

Lire la suite de la série : La doctrine capitalise. Pas les modèles. — pourquoi les règles survivent aux modèles qui les lisent. Le backlog n'a jamais été le métier — qui signe quand la règle et le jugement divergent. 100 % écrit par des agents — la taxe de vérification, comptée. Encore un prompt — pourquoi mon propre ressenti de vitesse n'est pas une preuve. Le LAN est mort — la case que personne n'a lue. La compétence était réelle. Le poste, non. — le test n'est pas la seule compétence à avoir cessé d'avoir besoin de son propre poste.

---

Sources

• More Code, Less Reuse (MSR 2026) : les propositions écrites par des agents portent nettement plus de code redondant, et les relecteurs les ont jugées plus favorablement que celles des humains. Comité de lecture, aucun financement d'éditeur. Le sentiment n'est pas la rigueur de revue : prenez la direction, pas un taux.
• Perry et coll., Do Users Write More Insecure Code with AI Assistants ? (ACM CCS 2023) : les participants assistés ont écrit du code moins sûr et étaient plus convaincus qu'il l'était. 47 participants, cadre de laboratoire, modèle vieux de trois générations. À citer pour le mécanisme, jamais comme un taux actuel.
• Debt Behind the AI Boom (2026) : 304 362 commits écrits par des agents et vérifiés par métadonnées ; parmi les problèmes trouvés, 89,1 % de maintenabilité, 5,8 % de bogues d'exécution, 5,1 % de sécurité. Les auteurs déclarent n'avoir fait tourner aucune référence humaine : cela décrit la forme de la dette, pas un écart avec les gens.
• GitClear — The AI Code Quality Maintainability Gap (2026) : duplication en hausse, remaniement en baisse sur 623 millions de lignes modifiées. Corrélation par année civile, sans attribution d'auteur, publiée par une société qui vend de l'analyse de qualité de code. Corroboration, pas preuve.
• Veracode GenAI Code Security (2025, retesté en 2026) : 45 % des échantillons produits échouent à un contrôle de sécurité, stable d'une génération à l'autre. Financé par l'éditeur, invites synthétiques, sans revue ni chaîne dans la boucle : sortie brute d'un modèle, pas du code livré. La platitude de la courbe est le seul point durable.
• Sur le chiffre le plus cité de ce débat — les 19 % de ralentissement mesurés sur des développeurs expérimentés dans des dépôts matures — j'ai écrit ce qui s'est passé quand ses propres auteurs en ont retiré le cadrage, dans le billet sur la mesure de son propre ressenti. Il n'est pas rejoué ici.
• Solstice* — les couches, les décomptes et l'échelle de mesure viennent du dépôt et de son suivi d'issues. Interne, sans lien : le nom de code est fictif et le projet réel, ses produits et son éditeur sont anonymisés. Chiffres vérifiés le 29 août 2026.