Comment auditer du code généré par IA avant de le livrer : un processus en cinq étapes pour une équipe de trois

Pourquoi le code généré par IA demande un autre type d'audit

Le code écrit par une IA échoue selon un schéma différent de celui écrit par une personne. Quelqu'un qui comprend mal une exigence laisse généralement des traces : un commentaire, une question dans le chat, un nom de variable bizarre. Un agent produit du code assuré, bien formaté, qui compile, passe les tests qu'il a écrits pour lui-même et peut quand même faire la mauvaise chose.

Deux chiffres décrivent le problème, en octobre 2026 :

• Le GenAI Code Security Report 2025 de Veracode (publié le 30 juillet 2025) a testé 80 tâches de programmation sur plus de 100 grands modèles de langage et constaté que le code généré introduisait une vulnérabilité de sécurité dans 45 % des cas. Les modèles n'ont pas protégé contre le cross-site scripting dans 86 % des tâches concernées ni contre l'injection dans les logs dans 88 %, et Java affichait un taux d'échec supérieur à 70 %.
• La Developer Survey 2025 de Stack Overflow (plus de 49 000 répondants, publiée le 29 juillet 2025) a constaté que 80 % des développeurs utilisent désormais des outils d'IA, mais que la confiance dans leur exactitude est tombée à 29 %. La première frustration, citée par 45 %, concerne les « solutions d'IA presque justes, mais pas tout à fait », et 66 % disent passer plus de temps à corriger du code d'IA presque juste.

Les deux modes de défaillance à auditer sont donc la dérive de périmètre (il a construit autre chose que ce qui était demandé) et l'insécurité silencieuse (il a construit ce qui était demandé d'une manière qui fuit). Une revue de diff dans une pull request ne détecte ni l'un ni l'autre de façon fiable, parce que le relecteur lit le code que l'agent a choisi de montrer, face à une exigence dont il se souvient à moitié.

Étape 1 : Figer une base de référence des exigences

On ne peut pas auditer du code par rapport à une exigence qui n'existe que dans une transcription de chat. Avant l'audit, écrivez ce que le code devait faire sous forme de liste numérotée de phrases déclaratives courtes, et figez-la.

Une bonne ligne de base ressemble à ceci :

• R-07 Un visiteur non connecté qui ouvre /app/* est redirigé vers /sign-in puis renvoyé vers l'URL d'origine après connexion.
• R-12 Une facture ne peut être marquée comme payée que par un propriétaire ou un administrateur de l'espace de travail.
• R-15 Les payloads de webhook Stripe sont rejetés tant que la signature n'est pas vérifiée.

Une mauvaise ligne ressemble à « gérer correctement l'auth ». Si vous ne pouvez pas dire si une ligne est satisfaite ou non en regardant le produit en marche, réécrivez-la jusqu'à ce que ce soit possible.

Pour une fonctionnalité construite en une semaine avec Cursor ou Claude Code, la base compte généralement 15 à 40 lignes. Tirez-les du PRD, des descriptions de tickets et des prompts donnés à l'agent. Puis arrêtez de la modifier : l'intérêt d'une base de référence des exigences est d'être une référence fixe, pour que l'étape suivante soit une comparaison et non une négociation.

Dans Atrix, le run Develop transforme un brief en liste d'exigences, que vous figez comme base de référence du produit. Si vous n'utilisez pas Atrix, un fichier Markdown numéroté et commité dans le dépôt remplit le même rôle. Ce qui compte, c'est qu'elle soit écrite, numérotée et datée.

Étape 2 : Comparer ce qui a été construit à la base de référence

Parcourez maintenant la base ligne par ligne et classez chaque exigence dans l'un de ces trois états :

Faites-le avec le produit ouvert et en marche, pas seulement le code. Les agents sont doués pour écrire une fonction nommée requireAdmin et ne pas l'appeler sur une route.

Trois choses à chercher en particulier :

1. Des tests modifiés pour passer. Cherchez dans le diff les assertions modifiées, les cas de test supprimés et les nouveaux marqueurs skip ou only. D'après notre expérience, c'est la façon la plus courante dont un agent clôt une tâche en échec.
2. Des exigences réinterprétées par l'agent. « Rediriger après connexion » devient « rediriger vers le tableau de bord » ; « propriétaire ou administrateur » devient « tout membre connecté ». Le code est propre, et faux.
3. Du comportement supplémentaire que personne n'a demandé. Les agents ajoutent des fonctionnalités. Chacune est une surface non relue. Soit vous l'ajoutez à la base et la relisez, soit vous la supprimez.

C'est la partie qu'Atrix automatise. L'audit des exigences d'Atrix AI compare la base figée à ce que l'équipe a planifié et construit dans l'espace de travail, et rapporte la couverture et la dérive par exigence. Soyons clairs sur sa limite : il audite des exigences, pas du code source. Il ne lit pas votre dépôt, ne lance pas d'analyse statique et ne trouve pas de vulnérabilités. Il répond à « avons-nous construit ce que nous avions dit ? », ce qui est l'étape 2, et rien des étapes 3 à 5.

Étape 3 : Lancer une analyse statique sur tout le dépôt

L'analyse statique de sécurité (SAST) est l'étape la moins chère et celle que les équipes sautent. Lancez-la sur tout le dépôt, pas seulement sur le diff, parce qu'un changement de l'agent peut rendre accessible d'une nouvelle manière du code auparavant sûr.

En octobre 2026, trois outils couvrent la plupart des petites équipes :

Les prix viennent de la page tarifaire de chaque éditeur en octobre 2026 et changent souvent.

Lancez le scan en CI pour qu'il s'exécute à chaque pull request, et triez la première exécution à la main. Attendez-vous à beaucoup de bruit la première fois ; le but est d'arriver à une base propre pour que le prochain changement écrit par un agent ne montre que les nouvelles alertes.

Ce que le SAST détectera dans du code écrit par IA : injections (SQL, commandes, logs), absence d'encodage de sortie, secrets en dur, aléatoire non sûr, dépendances vulnérables connues. Ce qu'il ne détectera pas : une vérification d'autorisation manquante sur une route, un gestionnaire de webhook qui fait confiance à un payload non signé, un prix calculé côté client. C'est l'étape 4.

Étape 4 : Relire à la main les chemins d'auth et de paiement

Une personne les lit du début à la fin, la base de référence ouverte :

1. Chaque route qui modifie des données. Pour chacune, trouvez la ligne qui vérifie qui appelle et ce qu'il a le droit de faire. Si vous ne trouvez pas la ligne, elle n'existe pas.
2. Gestion des sessions et des jetons. Où la session est créée, combien de temps elle vit, comment elle est invalidée à la déconnexion et au changement de mot de passe.
3. Webhooks et callbacks. Vérification de signature avant tout parsing. Idempotence sur les relances.
4. L'argent. Où sont calculés prix, totaux et remises. Tout ce qui est calculé dans le navigateur et accepté par le serveur est une alerte.
5. Secrets et configuration. Cherchez dans le diff les clés d'API, chaînes de connexion et jetons. Les agents collent des clés d'exemple dans le code plus souvent que les humains.

Prévoyez deux à quatre heures pour un changement de la taille d'une fonctionnalité. Le relecteur ne devrait pas être la personne qui a prompté l'agent, pour la même raison qu'un auteur ne devrait pas relire son propre brouillon.

Si vous utilisez l'intégration GitHub, les tickets ouverts depuis cette revue renvoient à l'exigence et à la pull request, de sorte que « R-12 partielle : les admins peuvent marquer payé, les propriétaires non » est un élément suivi avec un responsable, pas un commentaire qui disparaît.

Étape 5 : Consigner les constats et corriger dans l'ordre

Enregistrez chaque constat comme un ticket avec quatre champs : l'exigence concernée, la sévérité, le fichier et la ligne, et la correction. À cette échelle, la sévérité est simple :

• Critique : accès non authentifié ou inter-tenants à des données, ou argent mal calculé. À corriger avant de livrer.
• Haute : faille de sécurité exploitable uniquement par un utilisateur connecté. À corriger dans le même sprint.
• Moyenne : cas limite manquant que les utilisateurs rencontreront. À planifier.
• Basse : style, code mort, logique dupliquée. À regrouper.

Placez les éléments critiques et hauts dans le cycle en cours, et relancez l'audit quand ils sont clos. La seconde passe est rapide parce que la base et le scan existent déjà ; le seul travail nouveau est de relire les lignes qui ont changé.

Les outils qui facilitent tout cela avec Cursor et Claude Code

L'audit coûte moins cher quand l'agent a la base de référence sous les yeux pendant qu'il travaille. Trois choses que nous faisons :

• Donner la base à l'agent, pas seulement le prompt. Avec l'intégration Cursor ou l'intégration Claude, l'agent peut lire la page d'exigences et les tickets via le serveur MCP d'Atrix, de sorte que la liste numérotée sur laquelle il construit est celle sur laquelle vous auditerez.
• Demander la correspondance dans la pull request. Une règle dans les instructions de l'agent, « liste les identifiants d'exigence que ce changement implémente », transforme l'étape 2 d'une chasse en une vérification.
• Faire lancer le SAST par l'agent avant d'ouvrir la PR. Semgrep tourne en local en quelques secondes. Si l'agent voit les alertes, il en corrige la plupart lui-même.

Rien de cela ne remplace les étapes 3 et 4. Cela les raccourcit.

Pour une équipe de trois, le premier audit complet d'une fonctionnalité construite avec des agents prend environ une journée. Le second prend moitié moins, parce que le processus de base de référence et le scanner sont déjà en place.

FAQ

Quelle est la différence entre un audit des exigences et un audit de code ?

Un audit des exigences vérifie si ce qui a été construit correspond à la liste de ce qui devait l'être : couverture et dérive par exigence. Un audit de code vérifie si le code lui-même est correct, sûr et maintenable : analyse statique, revue des dépendances, lecture humaine des chemins sensibles. Pour du code généré par IA, il faut les deux, ce sont l'étape 2 et les étapes 3 à 4 ci-dessus. Atrix AI fait le premier ; le second, c'est un SAST plus une personne. Le volet agence d'Atrix, Atrix Digital, réalise des audits de code humains en prestation.

Un outil d'IA peut-il auditer du code généré par IA ?

En partie. Les outils SAST, dont certains utilisent désormais des modèles pour le tri, repèrent bien les failles au niveau des motifs. Un second modèle qui relit la sortie du premier attrape quelques erreurs de logique, mais partage ses angles morts sur l'autorisation et les règles métier. En octobre 2026, nous traitons la revue par IA comme un préfiltre de la revue humaine de l'étape 4, pas comme un remplacement.

Comment auditer une application « vibe-codée » que je n'ai pas construite ?

Commencez quand même par l'étape 1 : écrivez ce que l'application est censée faire à partir du produit lui-même, écran par écran, et numérotez la liste. Lancez ensuite le SAST sur tout le dépôt, et lisez chaque route qui modifie des données ou de l'argent. Comptez sur une base de référence plus longue à établir que pour du code que vous avez construit, parce que les exigences n'ont jamais été écrites.

À quelle fréquence auditer ?

Par fonctionnalité, avant qu'elle n'atteigne des utilisateurs payants, puis de nouveau quand les constats critiques et hauts sont clos. Pour une équipe qui livre chaque semaine, cela fait un audit court chaque semaine et un audit complet à chaque cycle.

Quel outil SAST une petite équipe devrait-elle choisir ?

La Free Edition de Semgrep couvre jusqu'à 10 contributeurs et 10 dépôts privés en octobre 2026, tourne en local et en CI, et est la plus simple pour démarrer. Si votre code est sur GitHub et que vous payez déjà Code Security, l'intégration de CodeQL aux pull requests est l'option avec le moins de friction. Choisissez-en un et lancez-le à chaque pull request ; lequel importe moins que de le lancer.

Prochaine étape

Écrivez d'abord votre base de référence. L'audit des exigences d'Atrix AI s'exécute contre elle sur tous les plans, et notre article précédent sur les audits de code avec IA explique quand une petite équipe a besoin d'un audit complet et quand un audit léger suffit.

Sources

Communiqué du Veracode 2025 GenAI Code Security Report, 30 juillet 2025. Résultats de la Stack Overflow 2025 Developer Survey, 29 juillet 2025. Prix vérifiés en octobre 2026 sur la tarification Semgrep, GitHub Advanced Security, la documentation de facturation GitHub et les plans Snyk.