Revue du code généré par IA : relire ce que la machine a écrit

Une part croissante du code qui part en production n’a pas été écrite ligne à ligne par un développeur. Elle a été proposée par un assistant, complétée par un modèle, générée par un agent. La porte par laquelle ce code entre en production, elle, n’a pas bougé : quelqu’un valide une fusion (merge), approuve une modification, laisse passer un lot. Ce responsable approuve désormais du code qu’il n’a pas écrit, à un volume qui dépasse ce qu’une relecture d’autrefois absorbait. La porte est la même. Ce qui la franchit a changé de nature.

Relire du code écrit par une intelligence artificielle (IA) n’est pas relire du code écrit par un humain. Les deux peuvent échouer, mais pas au même endroit. Le code d’un développeur porte des erreurs d’intention : un besoin mal compris, un cas oublié, un raisonnement faux. Le code d’un modèle porte des erreurs de plausibilité : il reproduit la forme d’un code correct, apprise sur un immense corpus, sans porter le contexte de sécurité propre à votre application. Cette différence n’est pas cosmétique. Elle déplace ce qu’une revue doit chercher, où elle doit regarder, et ce qu’elle peut confier à l’outillage.

Cet article traite le premier des trois fronts sur lesquels le risque d’un développement assisté par l’IA s’est déplacé du réseau vers le code : le code généré lui-même. Il situe où ce code échoue le plus souvent, comment mener une revue qui reste soutenable quand la machine produit plus vite que l’œil ne lit, et comment rendre cette revue vérifiable, pour qu’elle cesse d’être un acte de foi et devienne un indicateur qu’une direction peut suivre.

Un code qui « a l’air juste » échoue autrement

Un agent produit du code qui compile, franchit les tests visibles et ressemble à s’y méprendre à du bon code. Cette ressemblance est le piège. Rien, dans l’apparence d’un extrait, ne distingue une fonction sûre d’une fonction qui en a seulement la forme.

Pour comprendre ce que cela change, il faut regarder comment chaque type de code échoue. Un développeur qui écrit une validation d’entrée sait pourquoi il la met : il a en tête la donnée hostile, l’utilisateur mal intentionné, le cas limite. Quand il se trompe, il se trompe sur son intention, un raisonnement qu’une revue peut reconstituer et contester. Un modèle, lui, ne raisonne pas sur votre menace. Il reproduit le motif le plus fréquent de son corpus d’entraînement, lequel contient autant de code négligent que de code soigné. S’il omet la validation, ce n’est pas par défaut de jugement, c’est parce qu’une part de ses exemples l’omettait.

La conséquence pour la revue est directe. Relire du code humain, c’est chercher un raisonnement défaillant : cette personne a-t-elle bien compris le problème ? Relire du code généré, c’est poser une autre question : ce code, plausible, porte-t-il vraiment les garanties que le contexte exige, ou seulement l’apparence d’un code qui les porterait ? La revue cesse d’interroger une intention pour vérifier des garanties. C’est un déplacement de regard, et il réclame une grille différente. Reste à savoir où ces garanties manquent le plus souvent.

Ce que la machine ne voit pas

Le code généré ne rate pas au hasard. Il rate là où son corpus est faible, ambigu ou négligent, et ces zones recoupent largement celles qui produisent, dans la vraie vie, le plus de failles. Le référentiel CWE (Common Weakness Enumeration, la nomenclature de référence des types de faiblesses logicielles) publie, avec l’agence américaine de cybersécurité, un classement des faiblesses les plus répandues et les plus graves, établi à partir de dizaines de milliers de vulnérabilités réelles. En tête, année après année, les mêmes familles : entrées non filtrées menant à l’injection ou au script inter-sites, débordements, gestion défaillante des accès. Ce sont précisément les terrains où un modèle, laissé à sa pente, produit du code fragile.

Cinq angles morts reviennent assez pour structurer une revue. Le premier est la validation des entrées : un modèle génère volontiers le chemin nominal, celui qui fonctionne pour un utilisateur coopératif, et néglige l’entrée hostile qui n’apparaît dans aucune démonstration. Vient ensuite le secret en dur, clé ou jeton d’accès glissé dans le code parce qu’innombrables sont les exemples publics qui le font. Puis la gestion d’erreur qui masque : un bloc qui capture une exception, l’avale en silence et laisse l’application continuer dans un état incertain. Plus insidieux, le motif de sécurité périmé, algorithme de hachage dépassé ou configuration permissive recopiée d’un exemple ancien que le modèle a sur-appris. Enfin la sur-permissivité : un accès, une portée ou un droit plus larges que nécessaire, parce que c’est la version qui aboutit le plus vite dans les exemples dont le modèle s’inspire.

Ces angles morts ont une propriété précieuse : ils sont prévisibles. Une revue qui sait où ils se logent va vite à l’essentiel ; une revue qui relit tout de façon uniforme se noie et finit par ne plus rien voir. La carte de ces zones n’est pas un supplément à la revue, elle en est l’outil de priorisation.

Une revue soutenable au volume de l’IA

Reste un obstacle pratique : au volume que produit une IA, relire chaque ligne est hors de portée. Vouloir tout contrôler à la main, c’est reprendre d’une main la vitesse gagnée de l’autre, et transformer le réviseur en goulet d’étranglement. Une revue soutenable ne vise pas l’exhaustivité. Elle est pilotée par le risque, pas par le volume.

Le principe tient en une répartition. L’attention humaine se concentre là où le jugement est irremplaçable : les zones sensibles repérées plus haut, et tout code qui touche à l’authentification, aux autorisations, aux données sensibles ou aux appels vers l’extérieur. Une machine ne sait pas que, dans votre application, tel champ provient d’une source non fiable, ni que tel accès doit rester cloisonné pour une raison métier. Le réviseur apporte ce contexte que ni le générateur ni l’outil ne possèdent. Sa tâche est de lire et d’interroger, pas d’écrire, ce qui suppose de distinguer les étapes à confier à la machine de celles qui exigent un jugement humain.

Le reste, le prévisible, revient à l’outillage. L’analyse statique (SAST, pour static application security testing : l’inspection du code sans l’exécuter, à la recherche de motifs de faiblesse connus) débroussaille les erreurs répétitives. Les linters de sécurité signalent les secrets en dur et les configurations douteuses. L’analyse de composition logicielle (SCA, software composition analysis) surveille les dépendances. Branchés dans la chaîne de construction, ces outils traitent le volume ; l’humain tranche l’ambigu. Le partage est net : un outil reconnaît un motif connu, il ne juge pas si ce motif pose problème dans votre contexte.

Reste une tentation : faire relire le code d’une IA par une autre IA. Comme premier passage, l’idée a du sens et fait gagner du temps. Seule, elle ne suffit pas. Deux modèles entraînés sur des corpus voisins partagent des angles morts, et l’un peut valider tranquillement la faiblesse que l’autre a produite. L’IA qui relit l’IA déplace le contrôle, elle ne le referme pas. Le dernier maillon reste un regard humain, d’autant plus efficace que le code est propre : une structure lisible et durable se révise plus vite qu’un code écrit pour tenir en démonstration.

Une revue qui ne se mesure pas n’existe pas

Reste une faiblesse, et elle n’est pas dans le code. Une revue demeure souvent un acte de foi. « Le code a été relu » ne dit ni ce qui a été vérifié, ni jusqu’où. Tant qu’une revue n’est pas mesurable, elle n’est pas pilotable : une direction ne peut ni objectiver le risque, ni savoir si la vigilance tient quand l’équipe accélère.

Rendre la revue vérifiable, c’est l’adosser à des critères testables plutôt qu’à l’appréciation de chacun. Le référentiel OWASP ASVS (Application Security Verification Standard, standard ouvert de vérification de la sécurité applicative) est construit pour cela : chaque exigence y est formulée comme un énoncé testable, et l’ensemble se module par niveaux selon le risque de l’application. Sa logique transforme une question molle, « est-ce sûr ? », en questions fermes : telle garantie est-elle présente, a-t-elle été vérifiée, oui ou non. La sécurité cesse d’être une impression pour devenir un état constaté.

Pour une direction, trois indicateurs suffisent à sortir de l’acte de foi. Un taux de couverture, qui dit quelle part des zones sensibles a effectivement été revue. Une traçabilité, qui garde mémoire de ce qui a été vérifié et par qui. Une définition du terminé (definition of done) qui inscrit la revue de sécurité parmi les conditions de fusion, et non comme une étape facultative repoussée à plus tard. Aucun de ces trois éléments ne ralentit l’équipe. Ils rendent visible ce qui, sinon, reste dans les têtes.

Le fil se referme là. Le risque a glissé vers le code que l’IA écrit ; la revue est le premier maillon capable de le rattraper. Mais une revue qui reste un geste artisanal, ciblée par habitude et jamais mesurée, ne protège que tant qu’elle a de la chance. La rendre vérifiable, c’est cesser de compter sur cette chance. C’est aussi la condition pour garder la vitesse que l’IA a fait gagner sans en hériter le risque à l’aveugle.