Le pipeline était vert. Quatorze checks, tous passés, et le bouton de merge avec ce beau bleu confiant qu'il prend quand plus rien ne bloque le chemin. Quelqu'un avait demandé à un assistant un wrapper de retry autour d'un callback de paiement, lu les huit premières lignes, scrollé le reste, puis livré, parce que ça ressemblait exactement à ce qu'un bon dev aurait écrit à la main un mardi après-midi. C'était vrai. Presque. Les doubles facturations sont sorties dix-neuf jours plus tard, et les deux jours passés à les retracer se sont terminés sur une phrase que personne dans le dépôt n'était capable de produire : ce que ce code était censé faire quand un timeout réseau et une autorisation peut-être déjà appliquée arrivent en même temps.
Personne n'a sauté la revue. C'est ça qui dérange, parce que le réflexe dans ces moments-là, c'est d'aller magasiner un autre analyseur. Le State of Code Developer Survey de Sonar, publié le 8 janvier 2026 auprès de plus de 1 100 développeurs dans le monde, place l'IA à 42 % de tout le code livré, et les développeurs sondés s'attendent à 65 % en 2027. Dans la même enquête, 96 % disent ne pas avoir pleinement confiance que ce code est fonctionnellement correct. Et seulement 48 % le vérifient toujours avant de commiter.
Mets les trois chiffres côte à côte et ça arrête d'être une histoire de développeurs paresseux. La méfiance est quasi totale. La vérification tient du pile ou face. En 25 ans dans la livraison de logiciels d'entreprise, je n'ai jamais vu un groupe de professionnels se méfier autant de quelque chose et agir aussi peu en conséquence, et l'explication facile, celle de la pression de livraison, en couvre peut-être la moitié. Le reste est plus silencieux. Vérifier par rapport à quoi ?
Pourquoi autant de code IA passe sans vérification ?
Parce que la vérification a un dénominateur que personne ne dit tout haut. Pour vérifier quelque chose, ça prend un standard contre lequel vérifier, et pour un changement ordinaire ce standard vit à trois endroits : le compilateur, la suite de tests, et la mémoire d'une personne qui sait à quoi la fonctionnalité est censée servir. Deux des trois sont écrits et appliqués par la machine. Le troisième, non. L'IA a poussé le volume de code au-delà de ce qu'un standard non écrit dans une seule tête peut suivre, et le pire, c'est que la faille est presque invisible, parce qu'elle n'a jamais l'air d'une faille. Elle a l'air d'un build qui passe.
Regarde ce qui arrive à un réviseur dans ce contexte. Quand tu lis la pull request d'un collègue humain, l'intention arrive gratuitement : le message de commit, le ticket, le fait que Mélanie était assise deux bureaux plus loin et avait mentionné le mercredi que la job de réconciliation était instable depuis la migration. Le contexte vient avec le code. Le code IA arrive sans rien de tout ça, fluide et confiant et structurellement impeccable, et le réviseur se retrouve à déduire ce que le code était censé faire à partir de ce qu'il fait. Pas une revue. C'est du reverse engineering, à vitesse grand V, un vendredi, par quelqu'un qui a quatre autres pull requests ouvertes.
Le volume empire l'affaire. Et le 42 % n'est pas réparti également sur des scripts jetables, ce qui est le détail qui a changé ma lecture de cette enquête. Sonar a trouvé que 88 % des devs sortent l'IA sur les prototypes et 83 % sur les logiciels internes non critiques, correct, on s'y attendait. Mais aussi 73 % sur les applications destinées aux clients et, celui-là fait mal, 58 % sur les services critiques pour l'entreprise, ceux qu'une équipe de Longueuil réveille à trois heures du matin quand ils lâchent. Le code qui entre le plus vite atterrit le plus proche de l'argent.
Problème d'outils ou problème d'exigences ?
Les deux, mais pas à parts égales, et je veux être honnête sur la moitié « outils » plutôt que de vendre un faux dilemme. L'analyse statique attrape pour vrai des affaires qu'un humain fatigué à 17 h 40 va manquer : le déréférencement nul, la ressource jamais fermée, le chemin d'injection qui traverse quatre appels. Les nouvelles couches de revue par IA sont réellement bonnes pour reconnaître la forme d'un défaut. On a écrit ce que cette charge de revue coûte à une équipe dans le coût caché de la pile IA, et la réponse n'était pas zéro. Achète les outils. Ils se paient tout seuls.
Maintenant, remarque la question à laquelle ils répondent tous. Est-ce que ce code est croche d'une façon que je reconnais ? Aucun d'eux ne répond à l'autre question : est-ce que ce code est croche d'une façon que seule ton entreprise connaît ? Un analyseur n'a jamais signalé une implémentation impeccable de la mauvaise règle. Il ne peut pas. La règle ne lui a jamais été donnée, et un rapport propre sur un standard non défini veut seulement dire que l'outil n'a rien trouvé de ce qu'il sait chercher, ce que les équipes lisent comme de la sécurité alors que c'est du silence.
C'est le même défaut habillé différemment dans trois de nos textes récents. Quand les devs disent que la sortie de l'IA est presque correcte, mais pas tout à fait, c'est le « presque correcte par rapport à quoi » qui fait tout le travail dans la phrase. Quand les commits assistés par IA échappent des secrets à environ deux fois le taux de base (GitGuardian, State of Secrets Sprawl 2026), comme on l'a couvert dans la dette de sécurité de l'IA, l'artéfact manquant est une règle écrite sur ce qui a le droit de toucher à un identifiant. Symptômes différents. Une seule cause. Le critère d'acceptation n'a jamais été écrit, alors rien en aval ne pouvait l'appliquer.
À quoi ressemble un standard vraiment vérifiable ?
Assez concret pour qu'une machine ou un inconnu puisse contredire le code. « Réessayer en cas d'échec » n'est pas un standard, c'est un souhait, et un assistant va le satisfaire de douze façons incompatibles entre elles avec le sourire. « Réessayer au maximum deux fois sur un timeout de connexion, jamais sur une réponse qui a peut-être déjà été appliquée, et émettre un événement de réconciliation quand le résultat est inconnu », ça, c'est un standard. Même fonctionnalité. Une des deux versions peut être testée, mise dans un prompt et contestée. L'autre, non, et cette différence-là c'est tout l'article.
Google a publié un rapport d'expérience sur l'utilisation de grands modèles de langage pour ses migrations de code internes, et les chiffres sont tout sauf timides. Sur la migration des identifiants 32 bits vers 64 bits dans Google Ads, à l'intérieur d'une base de code de plus de 500 millions de lignes, l'équipe a trouvé que 80 % des modifications de code dans les changelists livrées étaient entièrement écrites par l'IA, et a estimé que le temps total de migration a baissé d'environ la moitié. La moitié. Un autre chantier, JUnit3 vers JUnit4, a déplacé 5 359 fichiers et plus de 149 000 lignes de code en trois mois, et environ 87 % de ce que le modèle a généré a été livré sans aucune modification.
Maintenant, regarde comment ils ont gagné le droit d'aller aussi vite. La boîte à outils « produit des changements vérifiés qui ne contiennent que du code qui passe les tests unitaires », avec une validation configurée par migration : compiler les fichiers modifiés, rouler leurs tests, renvoyer chaque échec au modèle pour réparation. Puis le bout important. Les règles de chaque migration étaient écrites avant que la génération commence, comme instructions explicites dans le prompt, jusqu'à des détails du genre « si l'ancien identifiant était négatif, la nouvelle valeur doit être négative ». Des humains ont quand même révisé chaque changement comme n'importe quel autre, et l'équipe a été franche : dans la plupart des cas, quelqu'un a dû annuler au moins une chose que le modèle avait mal faite ou faite pour rien.
C'est ça la leçon, et elle est encourageante. Google n'a pas comblé l'écart de vérification avec un meilleur modèle. Ils l'ont comblé en définissant « correct » comme un contrat vérifiable par la machine en premier, en écrivant les règles quelque part où un serveur de build pouvait les appliquer, et seulement ensuite en laissant le modèle courir fort à l'intérieur de cette limite. La vitesse était sécuritaire. Le standard existait avant le code.
Source : Nikolov, Codecasa, Sjovall, Tabachnyk, Chandra, Taneja et Ziftci (Google Core et Google Ads), « How is Google using AI for internal code migrations? », arXiv:2501.06972, 12 janvier 2025.
La plupart des équipes font ça à l'envers. Elles génèrent d'abord, puis partent à la recherche d'une façon de vérifier ce qui est sorti, et c'est comme ça qu'on finit par acheter un analyseur au quatrième mois tout en livrant quand même le bogue de paiement au cinquième. Google a inversé l'ordre. Les règles dans le prompt, la validation automatique, et la revue humaine avait enfin quelque chose de précis contre quoi réviser au lieu d'un vague sentiment que le diff avait l'air correct. Rien là-dedans n'exigeait une capacité de pointe. Ça exigeait que quelqu'un s'assoie et écrive ce que « correct » voulait dire.
Par où commencer lundi matin ?
Pas par une politique. Prends les trois services où une mauvaise réponse coûte de l'argent pour vrai, et laisse faire les quarante autres pour l'instant, parce qu'un standard que personne n'a le temps d'écrire vaut exactement autant que pas de standard pantoute. Une semaine d'ouvrage, peut-être deux. Quatre étapes, dans cet ordre :
- Cible le rayon d'impact. Classe les services selon ce que coûte une mauvaise réponse, pas selon la quantité d'IA qui les touche. Garde les trois premiers.
- Écris les règles, les états interdits et les limites. Pour chaque service : ce que le code doit respecter, les états qu'il ne doit jamais atteindre, et ce qui devrait arriver aux limites dont le monde débat sur Slack sans jamais trancher. Les limites, c'est le bout que tout le monde saute, et c'est le bout qui produit les doubles facturations.
- Mets les critères dans le prompt. Donne-les à l'assistant avant qu'il génère, comme Google écrivait les règles de chaque migration dans le prompt avant qu'une seule ligne sorte.
- Mets les mêmes critères dans la revue. Le réviseur arrête de deviner l'intention et commence à vérifier contre quelque chose. C'est toute la différence entre une revue et du reverse engineering.
Là, le mot « vérifier » a enfin quelque chose derrière lui. Pas de la discipline. C'est une mesure du nombre d'équipes qui se sont rendues à l'étape deux, et si ça a l'air d'une petite affaire à manquer, pense que chaque analyseur, chaque test et chaque audit en aval hérite de ce que tu as écrit là.
L'écart de vérification est un écart d'exigences.
L'IA écrit maintenant 42 % du code livré, avec une projection de 65 % en 2027. 96 % des développeurs n'ont pas pleinement confiance qu'il est fonctionnellement correct, et seulement 48 % le vérifient toujours avant de commiter. Pas la discipline. Vérifier exige un standard, et pour l'exactitude, la sécurité et la conformité, ce standard vit habituellement dans la tête de quelqu'un plutôt que dans une exigence, c'est-à-dire exactement là où aucun test, aucun analyseur et aucun réviseur ne peut l'atteindre.
Les outils de revue aident pour vrai et valent leur prix, mais remarque que chaque analyseur sur le marché répond exactement à la même question : est-ce que ce code est croche d'une façon que je reconnais déjà ? Aucun ne peut signaler une implémentation impeccable de la mauvaise règle. Google a laissé l'IA écrire 80 % d'une migration en toute sécurité parce que « correct » avait été défini comme un contrat vérifiable par la machine avant qu'une seule ligne soit générée. Écris-le en premier. Tout ce qui vient après, le test, la revue, la piste d'audit, ne vaut jamais mieux que cette phrase-là.
Quelles sont les questions les plus fréquentes sur la vérification du code généré par l'IA ?
