Avant de laisser passer du code écrit par un agent, beaucoup d'équipes exigent qu'un humain l'ait lu en entier. Elles n'ont pourtant jamais fait la même chose avec le système d'exploitation ou les dépendances de leurs applications, auxquels elles font confiance parce que d'autres les ont relus avant elles. Sauf que cette relecture-là a laissé passer pendant des années des failles que des modèles d'IA viennent de mettre au jour. Gildas Vinsot, Principal Tech & IA chez Thiga, revient sur ce deux poids, deux mesures, et sur ce qui devrait fonder la confiance quand ce sont des agents qui écrivent le code.
Combien de lignes du noyau Linux avez-vous lues ? Et de PostgreSQL, de la bibliothèque qui gère vos dates, du runtime qui exécute votre application ? Pour la plupart d'entre nous, la réponse est zéro ou presque, et nos produits tournent dessus tous les jours.
Pourtant, dès qu'un agent écrit du code, on voit revenir la même exigence : il faudrait le relire et le comprendre ligne par ligne avant de l'accepter. C'est assez curieux quand on y pense, parce qu'on n'a jamais appliqué cette règle au reste de notre pile logicielle.
On faisait confiance à des gens sérieux
On n'a jamais lu le noyau Linux, c'est vrai, mais on savait qui l'avait écrit et relu. Notre confiance allait à des organisations et à des mainteneurs connus pour leur exigence, et on partait du principe que si des gens sérieux avaient relu sérieusement, on pouvait y aller. Eric Raymond en a même fait un principe de l'open source en 1999 : "given enough eyeballs, all bugs are shallow". Autrement dit, avec assez de regards, aucun bug ne reste caché longtemps.
Sauf que les découvertes de cette année lui ont donné tort. Le noyau Linux est probablement le code le plus relu au monde… et c'est là qu'en avril 2026, Nicholas Carlini, chercheur chez Anthropic, a trouvé avec Claude Code un dépassement de tampon passé inaperçu pendant 23 ans. Il dit avoir en réserve des centaines de plantages potentiels qu'il n'a pas encore eu le temps de valider. Le même mois, Claude Mythos Preview a trouvé une faille vieille de 27 ans dans OpenBSD, un système dont la sécurité est la raison d'être, et a enchaîné plusieurs bugs mineurs du noyau Linux pour obtenir les droits root. Depuis, les annonces se succèdent : une faille dans les futex cachée depuis quinze ans, une autre dans vhost qui touche près de dix ans de versions, et en novembre une vulnérabilité réseau notée 9,8, exploitable à distance sans aucune action de la victime.
Ces failles ont résisté à des décennies de relecture par certains des meilleurs spécialistes au monde. Pendant longtemps, on s'est méfié du code écrit par une machine et on se rassurait avec la relecture humaine. Mais en matière de sécurité, elle ne suffit plus, et c'est la machine qui trouve ce que les humains ont laissé passer.
Dans le cas de la faille "Copy Fail", l'équipe de Xint explique que l'intuition d'un chercheur a orienté la recherche, et que l'IA a fait le travail de fond. Le point de blocage s'est aussi déplacé : on trouve désormais les failles plus vite qu'on ne sait les valider et les corriger (les centaines de plantages en attente de Nicholas Carlini en sont un bon exemple). Du coup, exiger qu'un humain relise ligne par ligne le code d'un agent, c'est s'appuyer sur le contrôle qui vient de montrer ses limites. En 2026, un éditeur sérieux lance plutôt des agents sur son propre code avant que les attaquants ne le fassent.
L'usage a souvent eu le dernier mot
L'histoire du logiciel a rarement récompensé la pureté technique pour elle-même. Facebook, par exemple, a misé sur la vitesse d'itération de PHP, et ce n'est qu'ensuite qu'il a développé HipHop pour diviser par deux environ la consommation CPU de ses serveurs. Chez Microsoft, Raymond Chen a documenté pendant des années les adaptations de Windows qui maintenaient les anciennes applications en état de marche, parce que les utilisateurs, eux, n'allaient pas chercher des correctifs.
Richard Gabriel appelait ça "worse is better" : un logiciel simple et imparfait, disponible tôt, l'emporte, et c'est sa diffusion qui finance ensuite son amélioration. Le noyau Linux en est d'ailleurs la preuve, avec des failles dedans depuis des décennies et des produits qui tournent dessus tous les jours. Mais ces failles ne restent plus cachées, parce qu'un attaquant peut maintenant les trouver avec les mêmes agents. Le code produit par un agent peut donc suivre la même logique, à une condition : passer des agents de sécurité dessus avant de le livrer, ce qui fait partie du harness engineering. Ensuite, on le met devant de vrais utilisateurs et on consolide ce qui sert.
Les builders livrent déjà
Et puis il y a une catégorie que le débat oublie : les projets qu'on n'aurait jamais lancés sans IA. Avec ArtCraft, un développeur seul recrée en Rust plusieurs applications de la suite Adobe avec Claude. Elles sont téléchargeables, mais encore en alpha, et elles ne remplacent évidemment pas des décennies de Creative Cloud.
Peter Steinberger, lui, a obtenu une réécriture fonctionnelle du système de transfert de VibeTunnel en Zig après plus de cinq heures de travail autonome de son agent, alors que les modèles précédents avaient échoué. Son projet personnel OpenClaw a depuis réuni une communauté et engagé une transition vers une fondation.
Bien sûr, deux cas ne disent pas que tout réussit, mais ils montrent qu'un développement largement délégué aux modèles produit déjà des logiciels ambitieux.
Ce qui reste à l'équipe
Si les machines écrivent le code et le relisent mieux que nous, compter les lignes, les tickets fermés et les pull requests fusionnées n'a plus vraiment de sens. On regarde plutôt le coût d'une fonctionnalité réellement utilisée, et ce que ça coûte de la faire évoluer ensuite, dette technique comprise. L'équipe, elle, garde ce que l'agent ne peut pas trancher à sa place : ce que le logiciel doit faire, pour qui, et quel niveau de risque on accepte.
Au fond, la question n'est plus de savoir qui a relu le code, mais quelle intelligence on a mise au travail et comment on la pilote selon l'usage visé.
Vos équipes peuvent-elles faire confiance au code de leurs agents ? Le Product Operating Model AI (POM-AI) de Thiga définit les règles de fonctionnement et les garde-fous qui permettent aux équipes Produit et Tech de produire avec l'IA à l'échelle de l'entreprise. Découvrir le POM-AI.
