Checklist d'audit de code généré par IA pour 2026 : six sections, imprimable, avec un modèle gratuit

Pourquoi le code généré par IA a besoin de son propre audit

Le code produit par Cursor, Claude Code, Copilot ou Codex a l'air terminé. Il compile, les tests écrits par le modèle passent et la pull request se lit bien. Le guide MetaCTO de juillet 2026 sur les standards de revue du code généré par IA appelle cela le « piège de la revue » : un code plausible qui oublie une exigence, invente une API ou saute un contrôle d'autorisation, et passe une revue qui ne cherchait que le style.

Les chiffres ne sont pas du marketing. Le rapport GenAI Code Security 2025 de Veracode a soumis 80 tâches de programmation sélectionnées à plus de 100 modèles de langage et a constaté qu'ils introduisaient une vulnérabilité dans 45 pour cent des cas. Java échouait à plus de 70 pour cent ; Python, C# et JavaScript se situaient entre 38 et 45 pour cent. Le cross-site scripting restait ouvert dans 86 pour cent des cas et l'injection dans les logs dans 88 pour cent.

Les dépendances sont un problème plus récent. Une étude USENIX Security 2025 de Spracklen et ses collègues a testé 16 modèles sur environ 576 000 échantillons de code généré et a constaté que 19,7 pour cent des paquets recommandés n'existaient pas. Les attaquants enregistrent désormais ces noms inventés, une pratique appelée slopsquatting. Une revue classique ne vérifiait jamais qu'un paquet était réel, parce que jusqu'à récemment il l'était toujours.

Un audit de code IA n'est donc pas une revue ordinaire faite avec plus de soin. Il ajoute des contrôles sans équivalent pour le code humain et déplace l'effort humain là où une erreur d'apparence convaincante coûte le plus cher.

Les trois moteurs de 2026

Les MVP « vibe-codés » arrivent chez les clients. Des fondateurs livrent des produits construits en grande partie par des agents, souvent par une seule personne en quelques semaines. L'audit est la première fois que quelqu'un lit le code dans son ensemble. Les cabinets qui publient ce qu'ils trouvent dans ces bases de code décrivent le même schéma : des écrans d'administration protégés dans l'interface mais pas dans l'API, pas de limitation de débit, une sécurité au niveau des lignes absente ou mal configurée, des secrets dans le dépôt.

La diligence raisonnable SOC 2. Sous les critères de gestion des changements (CC8 des Trust Services Criteria de l'AICPA), la question de l'auditeur est de savoir si chaque changement significatif a été revu, approuvé et testé avant la production. Ni SOC 2 ni ISO 27001 ne nomment la « revue de code » comme contrôle, mais les deux attendent une gestion des changements appliquée et vérifiable. Une pull request écrite par un agent et approuvée par la personne qui l'a promptée est une réponse faible ; un audit documenté avec des relecteurs nommés est une réponse solide.

Le règlement européen sur l'IA. Les obligations des modèles d'IA à usage général s'appliquent depuis le 2 août 2025, et le règlement est devenu largement applicable le 2 août 2026. L'Omnibus IA (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026) a reporté les obligations des systèmes à haut risque autonomes de l'annexe III au 2 décembre 2027 et celles des produits intégrés au 2 août 2028. Si vous vendez dans l'emploi, l'éducation, le crédit ou les infrastructures critiques, « un agent l'a écrit et nous n'avons pas vérifié » n'est pas une entrée défendable dans la documentation technique.

La checklist, section par section

Imprimez-la, ou copiez le modèle de checklist d'audit de code dans votre espace de travail. Cochez chaque point, notez la preuve (lien vers un résultat de scan, un test, un commit) et nommez la personne qui a vérifié.

1. Inventaire et carte d'architecture

• Listez chaque dépôt, service, tâche planifiée et définition d'infrastructure dans le périmètre.
• Marquez quels fichiers ou modules ont été générés par IA, assistés par IA ou écrits à la main. Git blame et les messages de commit le disent généralement ; si l'équipe ne le sait pas, dites-le dans le rapport.
• Dessinez le chemin d'une requête : points d'entrée, couche d'authentification, stockages de données, appels tiers, workers en arrière-plan.
• Notez les versions des runtimes et la cible de déploiement.
• Listez chaque endroit où des données personnelles, de paiement ou des identifiants sont stockés ou transitent.

Sans cette section, le reste de l'audit échantillonne au hasard.

2. Analyse statique (SAST) et détection de secrets

• Exécutez un outil SAST sur toute la base de code (Semgrep, CodeQL, SonarQube ou l'équivalent du langage) et conservez la sortie brute.
• Exécutez un scanner de secrets (gitleaks, trufflehog ou l'analyse intégrée de votre hébergeur) sur tout l'historique git, pas seulement HEAD.
• Triez les résultats en vrai positif, faux positif et risque accepté, avec une ligne de justification chacun.
• Vérifiez à la main les faiblesses préférées du modèle : encodage de sortie dans chaque template et réponse d'API (XSS), et entrées utilisateur qui atteignent les instructions de log (injection dans les logs).
• Confirmez que l'agent n'a pas assoupli les vérifications de types ou les règles de lint en CI pour faire passer un build.

3. Authentification, autorisation et validation des entrées

• Chaque route protégée vérifie l'identité côté serveur, pas seulement dans l'interface.
• Chaque accès au niveau d'un objet (par id) vérifie que l'appelant possède l'objet ou peut le voir.
• Les fonctions d'administration sont conditionnées par un rôle, lu depuis la session et non depuis le corps de la requête.
• Les sessions et jetons expirent, tournent lors d'un changement de privilège et sont stockés avec les attributs HttpOnly et Secure.
• Les mots de passe utilisent un hachage actuel (Argon2id, scrypt ou bcrypt), sans cryptographie maison.
• Toute entrée est validée à la frontière avec un schéma (Zod, Pydantic, JSON Schema) et l'accès à la base de données est paramétré.
• Des limites de débit existent sur la connexion, l'inscription, la réinitialisation de mot de passe et tout point d'accès qui envoie un email ou un SMS.
• Une protection CSRF est présente sur les requêtes navigateur qui modifient l'état.

C'est là que les applications vibe-codées échouent le plus souvent, et là où la sortie du modèle est la plus convaincante. Lisez ces fichiers ligne par ligne.

4. Audit des dépendances

• Chaque paquet du lockfile existe sur le registre public sous ce nom exact et a un historique plausible (ancienneté, mainteneurs, téléchargements).
• Tout paquet ajouté pour la première fois par un outil IA a été vérifié par un humain sur la page du registre.
• Exécutez un outil d'analyse de composition logicielle (npm audit, pip-audit, OSV-Scanner, Snyk, Dependabot) et consignez les avis ouverts.
• Les licences sont compatibles avec votre mode de distribution (attention à la GPL dans un SaaS propriétaire).
• Versions épinglées et lockfile commité.

5. Tests de logique métier et d'exigences

• Écrivez les exigences que le code devait satisfaire. Si elles n'existent que dans des prompts, récupérez-les dans l'historique des prompts et gelez-les comme référence.
• Pour chaque exigence, nommez le test ou la vérification manuelle qui la prouve. Les manques sont des constats.
• Testez les cas limites que le modèle a tendance à sauter : listes vides, soumissions en double, mises à jour concurrentes, fuseaux horaires, arrondis monétaires, échecs partiels dans les opérations en plusieurs étapes.
• Vérifiez que les tests écrits par l'agent testent un comportement, pas seulement qu'une fonction retourne sans lever d'erreur.
• Exécutez l'application de bout en bout dans un environnement propre et suivez l'argent : payer, recevoir, rembourser, facturer.

6. Revue senior et signature

• Un ingénieur senior qui n'a pas écrit le code lit chaque fichier de la liste rouge : authentification, paiements, données personnelles, migrations, surface d'API publique, infrastructure.
• Chaque constat a une sévérité, une preuve, un responsable et une date cible.
• Le relecteur consigne ce qu'il a vérifié personnellement et ce qu'il a échantillonné.
• Une personne nommée signe le rapport, avec la date et le hash du commit audité.

Échelle de sévérité à utiliser

Gardez l'échelle courte. Quatre niveaux que tout le monde utilise valent mieux que dix sur lesquels personne ne s'accorde.

Comparaison des cadres publiés

En octobre 2026, les deux structures publiées les plus citées sont :

Nos six sections suivent l'ordre de SolGuruz et empruntent à MetaCTO la règle selon laquelle la personne qui a prompté le code ne peut pas être la seule à l'approuver.

Mener l'audit en cinq étapes

1. Périmètre et gel. Convenez des dépôts, du hash du commit et de la référence des exigences. Rien ne fusionne dans la branche auditée tant que le rapport n'est pas signé.
2. Automatiser d'abord. Lancez le SAST, la détection de secrets et le scan des dépendances dès le premier jour, pour que les humains passent leur temps à trier plutôt qu'à découvrir.
3. Lire la liste rouge. Authentification, paiements, données personnelles, migrations, API publique, infrastructure. Ligne par ligne, par quelqu'un qui ne l'a pas écrit.
4. Tester les exigences. Associez chaque exigence gelée à un test ou à une vérification manuelle. Consignez ce qui manque.
5. Rédiger, signer, suivre. Un rapport, une table de sévérité, un responsable par constat et un suivi où les corrections restent visibles jusqu'à leur clôture.

Pour une équipe de trois personnes avec une base de code de 20 000 lignes, prévoyez une semaine de travail : un jour pour les étapes 1 et 2, deux à trois jours pour l'étape 3, un jour chacune pour les étapes 4 et 5.

Où Atrix s'inscrit, et où il ne s'inscrit pas

Atrix AI ne scanne pas le code source, n'exécute pas d'analyse statique et ne trouve pas de vulnérabilités. Ce que fait son agent est un audit d'exigences : vous gelez une référence d'exigences (depuis une page PRD ou une exécution Develop), et l'audit indique quelles exigences sont couvertes par du travail planifié ou livré, lesquelles ont dérivé et lesquelles n'ont pas de responsable. Cela correspond à la section 5 de cette checklist et à rien d'autre ; la page de la fonctionnalité d'audit de code précise cette frontière.

L'audit de code humain est un service distinct. Atrix Digital, l'agence derrière le produit, réalise des audits de code avec des personnes qui lisent le code ; cela couvre les sections 1 à 4 et 6. Dans Atrix, les constats deviennent des tickets dans un cycle, le rapport vit dans une page avec un lien de partage pour le client, et le modèle de checklist est une base de données de page que vous cochez. C'est la configuration que nous utilisons pour nos propres audits.

FAQ

Qu'est-ce qu'un audit de code IA ?

Une revue structurée de code écrit en grande partie par des outils IA, couvrant l'inventaire, l'analyse statique, l'authentification et la validation des entrées, les dépendances, les tests de logique métier et une revue senior, avec des constats classés par sévérité et signés par un relecteur nommé. Elle ajoute des contrôles pour les paquets inventés et pour les exigences que le modèle a silencieusement abandonnées.

En quoi auditer du code généré par IA diffère-t-il d'une revue de code classique ?

Trois choses changent. Vous vérifiez que les dépendances existent et sont ce qu'elles prétendent être ; vous récupérez les exigences depuis les prompts et testez contre elles, parce que le modèle a pu résoudre un problème légèrement différent ; et vous déplacez l'attention humaine vers l'authentification, les paiements et les chemins de données, là où les tests Veracode de 2025 montrent que les modèles échouent le plus.

Combien de temps prend un audit de code IA ?

Pour une base de code de moins de 20 000 lignes avec un ou deux services, environ une semaine de travail d'un ingénieur senior. Les bases plus grandes évoluent avec la taille de la liste rouge, pas avec le nombre total de lignes.

Ai-je besoin d'un audit pour SOC 2 ?

SOC 2 n'exige pas d'audit sous ce nom, mais ses critères de gestion des changements attendent la preuve que les changements ont été revus, approuvés et testés par quelqu'un d'autre que l'auteur avant la production. Un rapport d'audit signé plus une revue obligatoire des pull requests constituent une preuve solide ; un fondateur solo qui approuve la sortie de son propre agent, non.

Le règlement européen sur l'IA m'oblige-t-il à auditer le code généré par IA ?

Pas directement. Le règlement encadre les systèmes d'IA selon leur usage, pas selon la façon dont leur code a été écrit. Mais si votre produit est un système à haut risque de l'annexe III, les obligations de documentation technique et de gestion des risques, applicables à partir du 2 décembre 2027, sont bien plus faciles à satisfaire si vous pouvez montrer comment le code a été revu et testé.

Atrix AI peut-il auditer mon code ?

Non. Atrix AI audite des exigences contre une référence gelée ; il ne lit ni ne scanne le code source. Pour un audit de code humain, passez par le service de l'agence Atrix Digital, et suivez les constats dans Atrix sous forme de tickets.

Prochaine étape

Copiez le modèle de checklist d'audit de code dans une page, gelez votre référence d'exigences et parcourez les six sections dans l'ordre. Si vous auditez une base de code que vous n'avez pas écrite, l'article complémentaire sur comment auditer du code généré par IA avant de le livrer détaille l'étape de la référence.

Sources

Faits vérifiés en octobre 2026 : communiqué du rapport GenAI Code Security 2025 de Veracode, MetaCTO, Establishing Code Review Standards for AI-Generated Code, SolGuruz, How to Audit AI-Generated Code in 2026, Commission européenne, cadre réglementaire et calendrier du règlement IA, Spracklen et al., étude sur les paquets hallucinés, résumée par Xygeni, AICPA Trust Services Criteria.