Comment les builds se vérifient eux-mêmes

0:00 — une construction se termine. L'agent dit qu'elle est terminée, ce qui est une affirmation sur l'écriture du code, pas sur son bon fonctionnement. Tout utilisateur d'un générateur IA a déjà ressenti, au moins une fois, l'écart entre ces deux affirmations : l'aperçu s'ouvre, on clique sur le troisième bouton, rien ne se passe. J'ai vu une salle de démonstration devenir silencieuse à exactement ce moment-là. Alors, avant qu'un humain ne voie une construction, elle traverse environ six minutes d'une chaîne qui se contredit elle-même. Voici à quoi cela ressemble concrètement, retracé à travers une construction que nous avons vue déraper puis être corrigée.

0:02 — la revue de code commence. Pas l'agent qui a écrit le code en relisant son propre devoir — un agent distinct, avec un prompt différent, sans aucun enjeu dans la réussite de la construction. Cette séparation compte plus qu'il n'y paraît. Un agent qui a décidé à 14h14 qu'un appel fetch sans gestion d'erreur convenait pensera toujours la même chose à 14h15 si vous lui demandez de vérifier son propre travail. Un relecteur nouveau, à qui on a demandé de « trouver ce qui est cassé, citer le fichier », se comporte comme l'ingénieur senior grincheux dont vous avez vraiment besoin pour cette tâche. Sur une construction passée, il a repéré un total de panier qui ne se mettait jamais à jour silencieusement — `updateTotal` était défini dans `Cart.jsx` mais jamais relié au gestionnaire de changement de quantité, si bien que la fonction existait et ne s'exécutait tout simplement jamais. C'est exactement le type de problème pour lequel la revue de code existe : ce qu'un compilateur ignore superbement.

0:04 — audit de sécurité. Plus ciblé qu'il n'y paraît, délibérément — ce n'est pas un test d'intrusion, c'est une chasse aux motifs pour la poignée d'erreurs qui apparaissent réellement dans le code généré par IA. SQL construit par concaténation de chaînes. Validation côté client uniquement, traitée comme si c'était toute l'histoire. Et la spécialité maison : une clé API codée en dur, parce que l'agent qui écrivait la fonctionnalité n'avait pas de convention de variable d'environnement sous les yeux et a pris ce qui fonctionnait. On voit ce cas assez souvent pour qu'il ne surprenne quasiment plus.

0:07 — liens et SEO. Peu glamour, et cela détecte ce que personne ne remarque jusqu'à ce qu'un client le fasse : un lien de navigation pointant vers /pricing alors que la page a en réalité été générée à /price, une entrée de sitemap pour une page en 404, une meta description qui contient encore le texte du modèle. Rien de tout ça ne casse le build. Mais tout ça sabote discrètement la chose que la plupart de nos utilisateurs sont venus chercher sur ce site — être trouvés, être cliqués.

0:09 — accessibilité. Il s'agit d'une passe automatisée axe-core, pas d'un audit manuel complet, et il vaut mieux être honnête sur ce que ce compromis apporte. axe-core repère les ratios de contraste, le texte alternatif manquant, les champs de formulaire sans étiquette, les pièges d'ordre de tabulation — la couche mécanique, quelque chose comme 30 à 40 % de ce qu'un audit WCAG complet signalerait. Il ne détectera pas une expérience de lecteur d'écran techniquement conforme mais réellement confuse à utiliser. Nous avons choisi l'automatisation uniquement parce qu'elle s'exécute en quelques secondes et que la plupart de ce qui est livré ici sont des sites vitrines et de petits outils, pas le genre d'application où un audit partiel représente un vrai risque pour quelqu'un.

0:11 — conformité. Cette couche ne demande pas « est-ce bien », elle demande « est-ce conforme à ce qui a été promis ». Le plan prévoyait quatre pages, la construction en a livré trois — la conformité est ce qui le remarque. Le plan promettait un formulaire de contact fonctionnel, ce qui a été livré est un formulaire sans action de soumission — même couche, même détection. C'est la vérification la plus directement redevable envers l'utilisateur, car elle mesure par rapport à l'intention exprimée par l'utilisateur, pas à une notion abstraite de qualité.

0:13 — la vérification dans le navigateur, et c'est là que notre construction a réellement échoué. Cette couche est la plus difficile à contourner car elle ne lit pas le code, elle pilote un vrai navigateur — clique, tape, attend, vérifie que le DOM a changé comme il aurait dû. La construction en question était un jeu incrémental (idle game), et les jeux ont droit à une passe supplémentaire ici parce qu'un jeu peut s'afficher pixel-perfect et rester injouable — l'affichage du score peut sembler impeccable tout en étant complètement déconnecté de la logique de calcul. Le vérificateur a joué. Le score se mettait bien à jour. L'audio ne produisait aucun son.

Trois cycles, puis une escalade

La découverte ne nous est pas parvenue sous forme de rapport de bug — elle est allée directement dans une passe de correction, et la chaîne a revérifié, jusqu'à trois cycles au sein de la construction. Cycle un : la correction a touché l'initialisation du mixeur, qui était déjà correcte, donc l'audio est resté muet. Cycle deux : une correction différente a traité un cas limite d'état de chargement qui semblait proche du problème et — cela arrive plus souvent qu'on ne le pense — a introduit un nouveau petit problème sans résoudre le problème initial. Cycle trois : toujours muet, et à ce stade, on est généralement soit face à quelque chose de vraiment difficile, soit face à une fausse alerte — ici, c'était le cas difficile.

La plateforme a donc escaladé d'elle-même. Elle a mis en file d'attente une passe de correction de suivi entièrement dédiée à la découverte persistante, travaillant sur un clone de la construction plutôt que sur la construction elle-même — ce qui signifie que cette passe d'escalade pouvait échouer sans nous faire perdre la version fonctionnelle déjà obtenue. Cette passe a trouvé la cause réelle : un indicateur de sourdine (mute) activé lors d'une passe de débogage antérieure et jamais désactivé, situé dans un fichier complètement différent de ceux touchés par les deux corrections précédentes. L'indicateur a été effacé, la vérification refaite, et le test a réussi. Personne n'a regardé cette construction avant qu'elle ne fonctionne déjà.

Ce que j'éviterais la prochaine fois

Quelques mois avant l'exécution de ce jeu incrémental, nous avons essayé une version plus souple de l'ensemble du système — les vérificateurs pouvaient soulever n'importe quelle préoccupation, formulée comme ils le souhaitaient. Cela a produit des remarques comme « envisagez d'extraire ceci dans une fonction utilitaire » et « ce nom de variable pourrait être plus clair », qui donnaient l'impression de rigueur sans rien corriger. Les passes de correction ont épuisé des cycles entiers à peaufiner la prose au lieu de corriger ce qui était réellement cassé. Nous avons resserré la règle ainsi : nommer un fichier, décrire une défaillance, ou ne rien dire. Les remarques des vérificateurs ont chuté d'environ moitié et presque tout ce qui restait était exploitable. Si je devais tout reconstruire, je sauterais entièrement la version souple et j'irais directement à la règle de la preuve — nous n'avions pas besoin d'apprendre cette leçon de la manière coûteuse, mais c'est ce que nous avons fait.

Cette règle a un coût réel, et je ne le nierai pas : une préoccupation vague mais vraie comme « cette conception d'API posera problème dans six mois » est désormais écartée, car un vérificateur ne peut pas la relier à une défaillance concrète. Nous avons accepté ce compromis. Une chaîne qui ferait aussi de la revue d'architecture ne serait pas assez rapide pour s'exécuter sur chaque construction, et la rapidité est tout l'intérêt d'automatiser ce processus plutôt que de demander à un humain de le faire.

Je déconseillerais aussi d'ajouter un quatrième cycle, si la question se pose. Nous avons ajusté le nombre de cycles à partir de constructions réelles, et la valeur marginale au-delà du troisième cycle chute nettement — le premier cycle résout la plupart des découvertes corrigibles, le deuxième nettoie surtout les problèmes introduits par le premier, et au troisième, ce qui reste est soit vraiment difficile, soit n'a jamais vraiment été cassé. Un quatrième cycle n'apporte surtout que des temps d'attente plus longs pour le même résultat.

Rien de tout cela n'est gratuit, ni infaillible. Six couches, plus autant de cycles de correction que nécessaire, ajoutent un temps réel à chaque construction — la différence entre terminer en moins d'une minute et terminer en plusieurs minutes. Nous pensons que c'est le bon compromis pour tout ce que vous êtes sur le point de présenter à vos propres clients, mais « rapide » et « vérifié » tirent dans des directions opposées, et nous avons choisi la vérification. Les vérificateurs sont aussi des LLM, ils signalent donc parfois quelque chose qui n'est pas réellement cassé, ou passent à côté de quelque chose qui l'est. La règle de la preuve et la boucle à plusieurs cycles sont des garde-fous contre cela, pas des garanties.

Ce que vous obtenez à la fin, c'est un registre : quelles couches se sont exécutées, ce qu'elles ont trouvé, ce qui a été corrigé, et ce qui reste soumis à votre propre jugement. Ce registre est plus proche du produit réel que ne l'est le code — c'est la différence entre faire confiance à une construction parce qu'elle a l'air terminée et lui faire confiance parce que quelque chose d'hostile a d'abord tenté de la casser et a échoué.