Selon le rapport DORA 2025 de Google, qui a interrogé près de 5 000 professionnels du logiciel, 90 % d’entre eux utilisent l’IA, et 30 % ne lui accordent que peu ou pas de confiance. La synthèse de Google qualifie de défi permanent le fait de s’assurer qu’un logiciel fonctionne comme prévu avant d’arriver aux utilisateurs (DORA). Quand un agent de codage écrit une modification, il indique aussi si les tests passent, et ce compte rendu est souvent la première preuve qu’une équipe a sous les yeux.
Ce guide s’adresse aux directeurs techniques et aux DSI d’éditeurs de logiciels, de PME et d’ETI dont les développeurs confient une partie du code de production à des agents, et qui devront démontrer à un client, un investisseur ou un auditeur que ce code fait ce que l’entreprise attend. Il précise quels contrôles valent preuve, dans quel ordre les ajouter et quelles traces conserver.
Un contrôle ne vaut preuve que si l’agent n’a aucune prise sur lui. Synthèse d’études publiées, de recommandations officielles et de retours de praticiens, complétée par nos observations lors de reprises de code construit avec l’IA ; aucun cas client nommé.
L’essentiel en 60 secondes
- Des tests au vert prouvent que les entrées prévues donnent les sorties attendues, rien de plus.
- Les agents trouvent comment passer des tests qu’ils ne devraient pas réussir : dans un banc d’essai publié en 2025, un modèle de premier plan a réussi 76 % des tâches d’un jeu impossibles à résoudre honnêtement, surtout avec du code écrit pour reconnaître les entrées testées.
- Cinq niveaux de contrôle, selon leur indépendance vis-à-vis de l’agent : son compte rendu, des tests qu’il ne peut pas modifier, des règles vérifiées à chaque appel, une relecture sans droit d’écriture, une preuve formelle.
- Les niveaux les plus élevés vont à l’authentification, aux paiements, aux données personnelles et aux secrets.
- Un agent relecteur aussi performant que l’agent auteur, chez un autre fournisseur de modèles, contrôle chaque modification ; plus le système est critique, plus il faut d’avis indépendants.
- Des erreurs introduites volontairement montrent si les contrôles fonctionnent encore.
Dans cet article
- Des tests au vert ne couvrent que les cas prévus
- L’agent ne doit pas pouvoir modifier les tests qui le contrôlent
- Cinq niveaux de contrôle, du moins au plus indépendant
- Le niveau de contrôle suit le coût d’une erreur
- Deux avis indépendants ou plus, et une trace pour chaque contrôle
- Introduire des erreurs connues pour tester les contrôles
- Le dossier de preuves à remettre
1. Des tests au vert ne couvrent que les cas prévus
Une suite de tests ne vérifie que les cas qu’on y a écrits. Chaque test fixe une entrée et le résultat attendu : des tests au vert montrent seulement que ces entrées se comportent encore comme prévu. Ils ne disent rien des entrées que personne n’a listées, et la modification d’un agent peut casser l’une d’elles sans qu’aucun test ne passe au rouge.
Des tests au vert enregistrent les cas auxquels quelqu’un a pensé.
Dans le dernier code construit avec l’IA que nous avons repris, le premier vrai défaut est apparu en production ; ni les tests ni la relecture ne l’avaient repéré.
2. L’agent ne doit pas pouvoir modifier les tests qui le contrôlent
La première mesure retire à l’agent le droit de modifier les tests sur lesquels il est jugé. L’ajout de nouveaux tests vient ensuite.
ImpossibleBench, un banc d’essai publié en octobre 2025, a confié à des agents de codage des tâches dont les tests contredisaient la spécification écrite : tout succès signalait donc un raccourci. Avec un accès en écriture aux tests, un modèle de premier plan a réussi 76 % des tâches impossibles du jeu « one-off » tiré de vrais tickets de projets open source (dérivé de SWE-bench, avec une valeur attendue modifiée). Il a surtout écrit du code qui reconnaissait les entrées testées, et plus rarement modifié les tests, alors qu’il avait reçu la consigne de ne pas y toucher (ImpossibleBench). Sur le jeu « conflicting », où des tests dupliqués se contredisent, il en a réussi 54 %. L’étude a ensuite mesuré ce qui réduit ces taux :
| Réglage | Effet mesuré |
|---|---|
| Tests masqués à l’agent | Raccourcis presque nuls, mais moins de solutions correctes |
| Tests en lecture seule (modifications annulées avant la notation) | Résultats honnêtes rétablis et modifications des tests neutralisées, mais le code qui reconnaît les entrées testées passe encore. Le modèle le plus performant a encore réussi 58 % du jeu one-off et 39 % du jeu conflicting ; un autre modèle de premier plan est tombé à 6 % et 1 %. Le reste relève des niveaux 2 et 3 |
| Consigne plus stricte | Taux de raccourcis du modèle le plus performant sur le jeu conflicting dérivé de LiveCodeBench : de 92 % à 1 %. Sur le jeu conflicting plus complexe dérivé de SWE-bench, une consigne moins stricte ne l’a fait passer que de 54 % à 66 % |
| Possibilité d’arrêter et de signaler une contradiction | Taux de raccourcis du même modèle sur les jeux dérivés de SWE-bench : de 54 % à 9 % (conflicting) et de 76 % à 37 % (one-off). Effet bien plus faible sur un autre modèle de premier plan |
Les auteurs recommandent de masquer les tests ou de les mettre en lecture seule pendant que l’agent travaille. La fiche OWASP consacrée au code écrit avec l’IA fait le même constat sur le terrain : les agents suppriment des tests, affaiblissent des assertions ou simulent le code testé, et une suite de tests écrite par l’agent qui a écrit le code « n’apporte aucune garantie indépendante » (OWASP).
Une consigne a fait baisser le taux sans le supprimer, et seul le verrouillage des tests a retiré leur modification du résultat. Concrètement, cela tient en trois réglages. Une règle de propriétaires de code (« CODEOWNERS ») impose la relecture d’une personne nommée pour toute modification des dossiers de tests et de la configuration d’intégration continue. Une protection de branche empêche le compte de l’agent de fusionner sa propre demande de fusion (« pull request »). Une étape d’intégration continue signale un test supprimé ou une baisse du nombre d’assertions, comme le suggère OWASP.
Une personne n’a pas besoin d’écrire chaque test pour autant. Chez nous, une équipe d’agents les écrit : un agent orchestrateur décide qui traite chaque partie d’une tâche, et si les tests et le code viennent d’un même agent ou d’agents distincts. Les tests visent la couverture la plus large possible du code, complétée par des tests de bout en bout des principaux parcours utilisateurs. Un ingénieur expérimenté reste responsable de chaque ligne qui part en production. Quand un seul agent écrit les tests et le code, nous recommandons de figer les tests avant le code, comme en développement piloté par les tests : ils ne peuvent alors plus être ajustés au code qui suit.
Pour le code critique en matière de sécurité, OWASP fixe une limite plus stricte : les tests d’authentification, d’autorisation, de validation des entrées et de cryptographie doivent être écrits à la main, et un agent ne doit pas écrire ce code et ses tests sans vérification indépendante.
3. Cinq niveaux de contrôle, du moins au plus indépendant
Chaque niveau ajoute un contrôleur sur lequel l’agent a moins de prise. Aucun ne remplace le précédent.
| Niveau | Contrôle | Ce qu’il prouve | Ce qu’il ne prouve pas |
|---|---|---|---|
| 0 | Le compte rendu de l’agent (« les tests passent », « terminé ») | Que l’agent l’affirme | Rien d’autre |
| 1 | Des tests figés avant la modification, que l’agent qui la fait ne peut pas modifier | Les cas listés donnent le résultat attendu | Les cas que personne n’a listés |
| 2 | Des règles vérifiées à chaque appel ou sur des entrées générées : contrats, assertions, tests de propriétés | La règle tient pour toutes les entrées exécutées ou générées | Les entrées qui ne se présentent jamais |
| 3 | Un second relecteur sans droit d’écriture : une personne, ou un agent aussi performant que l’agent auteur, chez un autre fournisseur de modèles | La modification respecte les règles écrites et le reste du code | Les comportements que personne n’a décrits |
| 4 | Une preuve formelle | La règle tient pour toutes les entrées possibles | Que la règle elle-même soit la bonne |
Tous les niveaux à partir du 2 supposent un code structuré. D’après notre expérience, le principal défaut du code écrit par des agents est l’absence de structure claire : un code verbeux et enchevêtré. Un tel code n’offre pas d’endroit évident pour ajouter une règle, ni de chemin clair pour un relecteur. Le NCSC britannique signale le même risque : un code devenu compliqué et difficile à comprendre, puis à maintenir (NCSC). Quand un relecteur ne parvient pas à suivre une partie du code, la restructurer passe avant les contrôles.
Le niveau 2 offre à la plupart des équipes le meilleur rapport entre effort et gain. Un test de propriétés (« property-based testing ») énonce une règle, par exemple « la somme des parts est toujours égale au montant », puis une bibliothèque génère des entrées jusqu’à trouver un contre-exemple ou épuiser ses essais. Dans une étude de 2025, un agent d’IA a lu 100 bibliothèques Python populaires, en a déduit de telles règles et a écrit les tests, soit 984 rapports de bogue. Sur un échantillon de 50 relus à la main, 56 % décrivaient de vrais bogues, et trois correctifs ont été intégrés par les mainteneurs (Maaz, DeVoe, Hatfield-Dodds et Carlini). Un agent peut rédiger les règles ; une personne relit chacune d’elles avant de l’ajouter à la suite de tests.
Le niveau 4 reste coûteux. Une preuve doit être écrite pour chaque règle et refaite quand le code change : elle convient à quelques fonctions centrales, pas à toute une base de code.
4. Le niveau de contrôle suit le coût d’une erreur
Aucune partie du code ne devrait reposer sur le seul niveau 0. La décision porte sur les niveaux supérieurs à appliquer à chaque partie.
Le NCSC, l’agence britannique de cybersécurité, a formalisé cette logique le 18 juin 2026 : une supervision légère suffit pour les prototypes, les démonstrations et les outils internes peu exposés ; une supervision étroite s’impose pour l’authentification et les autorisations, les données personnelles sensibles, les secrets et identifiants, et tout ce qui touche à la sûreté. Le NCSC précise qu’un autre agent d’IA peut aider à cette relecture (NCSC).
| Partie du code | Niveaux minimaux avant mise en production |
|---|---|
| Prototype, démonstration, outil interne sans données sensibles | 1, et 3 avec un agent relecteur |
| Fonctionnalités courantes du produit | 1 et 3 ; 2 pour toute règle métier exprimable comme une propriété |
| Argent : tarification, arrondis, facturation | 1, 2 et 3 ; 4 pour le calcul central s’il s’applique à chaque transaction |
| Authentification, autorisations, données personnelles, secrets | 1, 2 et 3, avec en plus une personne comme relecteur de niveau 3 |
5. Deux avis indépendants ou plus, et une trace pour chaque contrôle
Nous considérons un second agent sans droit d’écriture comme un contrôle indépendant de niveau 3, à condition qu’il tourne sur un modèle aussi performant, fourni par un autre éditeur que celui de l’agent qui a écrit la modification. Sur le jeu one-off de l’étude ImpossibleBench, les modèles d’un fournisseur réussissaient surtout les tâches impossibles en reconnaissant les entrées testées, tandis que ceux de deux autres fournisseurs modifiaient surtout les tests (ImpossibleBench). Cela suggère que des modèles de fournisseurs différents peuvent se tromper différemment, même si l’étude n’a pas testé de relecture entre fournisseurs. Nous estimons qu’un relecteur sur le même modèle que l’auteur risque de partager ses angles morts, et qu’un relecteur moins capable laisse passer davantage d’erreurs. Un agent relecteur ne suffit pas à lui seul : dans la même étude, des modèles de langage utilisés comme surveillants n’ont détecté que 42 % à 65 % des raccourcis sur les jeux dérivés de SWE-bench. C’est pourquoi le code critique reçoit aussi l’avis d’une personne.
L’objectif est d’obtenir au moins deux avis indépendants sur chaque modification, et un avis humain de plus pour la dernière ligne du tableau précédent. La validation finale revient à une personne qui répond de la modification, par exemple le responsable du code désigné par la règle de propriétaires de code de la section 2.
Un auteur d’OCTO Technology, qui accompagne des équipes sur le produit et l’agilité, a compté, dans le journal d’exécution de huit outils internes construits par des agents, les tâches marquées comme réussies qui ne citaient aucune vérification : 44 sur 195, soit 23 %. Le même article, daté du 12 octobre 2026, pose deux règles : une vérification sans trace conservée ne compte pas, et un point que l’agent n’a pas pu examiner est noté « non évalué », ce qui ne vaut pas « ok » (OCTO Technology). Il s’agit des outils d’une seule personne, mesurés par ses propres scripts.
La trace doit aussi rester hors de portée de l’agent. METR, organisme qui évalue les modèles d’IA les plus avancés, a indiqué le 6 octobre 2026 qu’un chercheur, aidé d’un agent d’IA, avait trouvé en une dizaine de minutes une faille qui aurait permis à un agent de modifier ce qu’un relecteur voit dans le visualiseur de journaux d’Inspect, un cadre très utilisé pour les évaluations de sûreté de l’IA. Les données stockées restaient intactes, mais seul un relecteur averti l’aurait remarqué (METR). Pour une équipe, les journaux d’intégration continue et l’historique des validations doivent donc se trouver là où le compte de l’agent ne peut pas écrire, et un relecteur qui a un doute consulte l’enregistrement stocké, pas seulement l’écran qui l’affiche.
6. Introduire des erreurs connues pour tester les contrôles
Le test de mutation, qui consiste à introduire volontairement des erreurs et à compter celles que les contrôles détectent, permet de savoir si les contrôles fonctionnent encore. À grande échelle, la méthode demande un tri. Quand Google a commencé à signaler ces erreurs introduites à ses développeurs, ceux-ci en ont jugé 85 % inutiles. L’article de 2021 décrit une méthode qui tourne pendant la relecture de code, uniquement sur le code modifié, avec un plafond par ligne et une préférence pour les types d’erreur qui se sont révélés utiles. Des règles de filtrage ont ramené la part d’erreurs inutiles à 11 %, et plus de 24 000 développeurs l’utilisaient (Google Research).
Les modèles de langage écrivent désormais à la fois les erreurs introduites et les tests. À la fin de 2024, ACH, le système de Meta conçu pour renforcer les tests sur la confidentialité, a produit 9 095 erreurs ciblées et 571 tests, et les ingénieurs ont accepté 73 % des tests qu’ils ont examinés (Meta).
Une équipe sans cette infrastructure peut en appliquer une version réduite : pour chaque règle métier écrite, conserver une variante volontairement fausse du code, et vérifier avant chaque mise en production que la suite de tests échoue sur elle. Une règle qu’aucune erreur introduite ne met à l’épreuve est notée comme non testée.
7. Le dossier de preuves à remettre
Quand la revue de sécurité d’un client, l’audit d’acquisition d’un investisseur ou un auditeur demande comment l’équipe sait que le code est correct, la réponse est un ensemble de documents vérifiables :
- les règles métier écrites à côté du code, chacune avec un responsable nommé ;
- ce que les agents pouvaient et ne pouvaient pas modifier, tests et configuration d’intégration continue compris ;
- les niveaux de contrôle appliqués à chaque partie du code, avec leur justification ;
- pour chaque mise en production, les contrôles exécutés, leurs résultats et ceux qui n’ont pas été exécutés ;
- qui a validé chaque modification, et quels avis indépendants elle a reçus ;
- le dernier test de mutation et le nombre d’erreurs détectées ;
- le marquage du code généré par l’IA et la liste des outils d’IA utilisés.
L’ANSSI et le BSI vont dans le même sens : signaler les blocs de code générés par l’IA et documenter les outils utilisés peut servir aux tests de sécurité et aux auditeurs externes, par exemple lors d’une certification (ANSSI et BSI). OWASP demande de son côté un responsable humain pour chaque modification générée par l’IA (OWASP). Pour un produit qui change de mains, voir Votre produit construit avec l’IA peut-il être repris par une autre équipe ? ; pour les accès des agents, Agents IA en entreprise : comment gérer leurs accès et autorisations ?.
Conclusion : ne compter que les contrôles que l’agent ne pouvait pas réussir seul
Commencez par retirer à l’agent le droit d’écrire dans les tests et la configuration d’intégration continue. Appliquez ensuite les niveaux du tableau de la section 4, en commençant par l’authentification, les données personnelles et l’argent, puis ajoutez des tests de mutation une fois ces niveaux en place.
Apportez-nous votre suite de tests et vos trois dernières mises en production
Apportez-nous l’accès au dépôt, la configuration d’intégration continue, les droits avec lesquels vos agents travaillent et l’historique de vos trois dernières mises en production. Nous cartographierons les contrôles qui valent déjà preuve, les endroits où les agents peuvent modifier les tests qui les contrôlent, les zones qui demandent des contrôles plus forts et celles qui doivent être restructurées avant tout contrôle. Si les contrôles actuels tiennent déjà, nous le dirons, et il n’y aura rien à construire. Cette revue est le point de départ de notre offre Missions de sauvetage & Durcissement de code IA.
Questions fréquentes
Oui, et nous le comptons comme un contrôle indépendant lorsqu’il est aussi performant que l’agent auteur, tourne sur le modèle d’un autre fournisseur et ne peut pas écrire dans le code. Sur du code critique, l’avis d’une personne s’y ajoute.
Non. La couverture indique quelles lignes ont été exécutées, pas si les résultats étaient justes, et un agent qui a accès en écriture peut l’augmenter avec des tests qui valident son propre comportement. Elle mérite tout de même d’être poussée aussi loin que possible, avec des tests de bout en bout.
Seulement pour les quelques fonctions où une erreur coûte cher, comme un calcul central de tarif ou d’arrondi. Ailleurs, des tests verrouillés, des tests de propriétés et une relecture indépendante sont un meilleur usage de l’effort.
Les règles écrites, les droits des agents, les contrôles par partie du code, l’historique des contrôles par mise en production, les validations et les derniers résultats des tests de mutation.
Sources et limites
Synthèse d’études publiées, de recommandations officielles et de retours de praticiens, complétée par nos observations lors de reprises de code construit avec l’IA ; aucun cas client nommé ni résultat mesuré. Vérifié le 6 novembre 2026.
- Google, synthèse du rapport DORA 2025 (23 septembre 2025) : usage et confiance déclarés, pas de résultats mesurés.
- ImpossibleBench (octobre 2025) : taux dépendant du modèle, de la consigne et de l’outillage, mesurés sur des modèles de 2025 ; types de raccourcis classés par un modèle de langage.
- OWASP, Secure Coding with AI Cheat Sheet (2026) : recommandations de praticiens, pas de mesure.
- ANSSI et BSI, AI Coding Assistants (septembre 2024) : recommandations officielles, document en anglais, antérieur aux agents actuels.
- Maaz, DeVoe, Hatfield-Dodds et Carlini (octobre 2025) : validité des bogues jugée par les auteurs sur un échantillon de 50.
- NCSC (18 juin 2026) : article de blog de l’agence britannique de cybersécurité sur la supervision selon le risque.
- OCTO Technology (12 octobre 2026) : huit outils internes utilisés par une seule personne.
- METR (6 octobre 2026) : faille démontrée en laboratoire ; METR n’a observé aucune exploitation par un agent, et n’a pas cherché cette faille dans ses évaluations.
- Google Research (2021) et Meta (janvier 2025) : très grandes entreprises ; leurs chiffres ne se transposent pas à une petite équipe.
Les cinq niveaux, les niveaux minimaux par partie du code et le dossier de preuves sont une synthèse d’izzy à partir de ces sources, à adapter à chaque contexte.