Modèle de rapport d'audit de code IA : les sections qu'un audit payant doit livrer
Modèle de rapport d'audit de code IA avec ce que les clients attendent : périmètre, tableau de sévérité, constats avec preuves, remédiation et validation.
Sur cette page
Un rapport d'audit de code généré par IA compte sept parties : une synthèse pour la direction, le périmètre et les exclusions, la méthode, un tableau de sévérité, une entrée par constat avec preuve et correctif, un plan de remédiation avec responsables et dates, et une validation signée. Le client paie pour les constats, mais il juge le rapport à une chose : peut-il agir sans vous rappeler.
Cet article s'adresse aux agences et studios qui vendent des audits de code généré par IA, et aux fondateurs qui lisent ce rapport de l'autre côté. La structure suit les conventions publiques déjà utilisées par les testeurs en sécurité, le chapitre consacré aux rapports de l'OWASP Web Security Testing Guide et l'échelle de sévérité CVSS v4.0, appliquées à ce que les clients demandent aujourd'hui : une base de code construite en quelques semaines, surtout par Cursor, Claude Code ou Copilot, sans que personne sache vraiment ce qu'elle contient.
À quoi sert un rapport d'audit de code IA
Un rapport d'audit fait trois choses à la fois. Il dit à un acheteur non technique si le produit peut être lancé, vendu ou présenté à des investisseurs. Il dit aux ingénieurs exactement quoi corriger et dans quel ordre. Et il laisse une trace qu'un relecteur ultérieur, le conseiller technique d'un investisseur ou un auditeur SOC 2 pourra vérifier.
Le code généré par IA déplace l'accent, pas le format. Les défauts que nous voyons le plus souvent sont ceux que l'OWASP Top 10:2025 place en tête : contrôle d'accès défaillant, configuration non sécurisée et problèmes de chaîne d'approvisionnement dus à des dépendances que personne n'a choisies volontairement. S'y ajoute une classe de problèmes propre au code généré : des fonctionnalités qui marchent dans la démo et ne font rien dans les cas limites, et des exigences jamais implémentées parce que le prompt qui a produit la fonctionnalité ne les mentionnait pas.
Un bon rapport répond donc à deux questions, pas une. Le code est-il sûr ? Et le code fait-il ce qui a été demandé ? La seconde est un audit des exigences, et le client ne sait généralement pas qu'il doit le demander.
Les sept sections que les clients attendent
L'OWASP Web Security Testing Guide recommande quatre sections de premier niveau pour un rapport de test de sécurité : Introduction, Synthèse, Constats et Annexes. Le modèle de rapport d'évaluation de Lenny Zeltser, très utilisé, répartit la même matière en huit. Nous en utilisons sept, parce qu'un audit de code doit aussi couvrir ce que fait le code, pas seulement comment on peut l'attaquer.
| Section | Qui la lit | Ce qu'elle doit contenir |
|---|---|---|
| 1. Synthèse | Fondateur, investisseur, acheteur | Verdict en un paragraphe, décompte par sévérité, les trois thèmes, ce que l'équipe fait bien |
| 2. Périmètre et exclusions | Tout le monde | Dépôts, commits, environnements, dates, ce qui n'a pas été examiné et pourquoi |
| 3. Méthode | Ingénieurs, auditeurs | Outils, versions, listes de contrôle, modèle de sévérité, comment le code généré a été identifié |
| 4. Tableau de sévérité | Tout le monde | Chaque constat sur une ligne : ID, titre, sévérité, statut |
| 5. Constats | Ingénieurs | Une entrée chacun : preuve, impact, reproduction, correctif |
| 6. Plan de remédiation | Responsable technique, chef de projet client | Correctifs ordonnés, responsable, date cible, étape de vérification |
| 7. Validation | Les deux parties | Qui a audité, qui a accepté, conditions de re-test, confidentialité |
L'ordre compte. Les dirigeants lisent la première page et le tableau. Les ingénieurs vont droit à la section 5. Si l'un des deux groupes doit chercher, le rapport a échoué.
1. Synthèse
Rédigez-la en dernier et tenez en une demi-page. Dites ce qui a été audité en une phrase, donnez le verdict en une phrase (« l'application n'est pas prête pour des clients payants tant que les deux constats critiques ne sont pas corrigés »), puis le décompte par sévérité, puis les deux ou trois thèmes qui expliquent la plupart des constats. Nommez une chose que la base de code fait bien ; cela rend le reste crédible. Ni payloads, ni numéros de CVE, ni noms d'outils ici.
2. Périmètre et exclusions
Listez chaque dépôt avec le hash du commit audité, les branches, les environnements auxquels vous avez eu accès et les dates. Puis les exclusions, avec leurs raisons : services tiers, infrastructure invisible pour vous, applications mobiles hors périmètre, tout ce que le client a demandé de ne pas toucher. Une section de périmètre qui ne liste que ce qui est inclus sera lue comme une garantie sur tout le reste.
Pour du code généré par IA, ajoutez une ligne sur la provenance : quelle part de la base de code le client estime générée, avec quels outils, et si un humain l'a relue avant fusion. Vous ne pourrez pas le vérifier précisément, écrivez-le donc comme une déclaration du client.
3. Méthode
Nommez les outils et leurs versions (le scanner SAST, l'audit de dépendances, le scanner de secrets), la liste de contrôle manuelle suivie et le modèle de sévérité. Si vous avez utilisé un assistant IA pendant la revue, dites-le et dites ce qu'il était autorisé à faire. Citez les standards utilisés : l'OWASP Top 10:2025 pour les noms de catégories, l'échelle qualitative CVSS v4.0 pour la sévérité, et l'OWASP ASVS 5.0.0 si le client a besoin d'un niveau de vérification nommé. Un client qui engage plus tard un autre cabinet doit pouvoir comparer les deux rapports.
4. Tableau de sévérité
Une ligne par constat. Nous utilisons les bandes qualitatives de CVSS v4.0 parce qu'elles sont publiques et que personne ne les conteste : Critique correspond à un score de 9,0 à 10,0, Élevé de 7,0 à 8,9, Moyen de 4,0 à 6,9, Faible de 0,1 à 3,9. Ajoutez un niveau Informatif pour ce qui n'est pas une vulnérabilité mais coûtera à l'équipe plus tard, comme l'absence de suite de tests ou une dépendance non maintenue.
| ID | Constat | Catégorie | Sévérité | Statut |
|---|---|---|---|---|
| F-01 | Tout utilisateur authentifié peut lire les factures de n'importe quel espace via /api/invoices/:id | Broken Access Control | Critique | Ouvert |
| F-02 | Le webhook Stripe accepte des événements non signés | Software or Data Integrity Failures | Élevé | Ouvert |
| F-03 | 14 dépendances avec des avis connus, 2 sans mainteneur | Software Supply Chain Failures | Moyen | Ouvert |
| F-04 | Les jetons de réinitialisation de mot de passe n'expirent jamais | Authentication Failures | Moyen | Ouvert |
| F-05 | La fonction d'export prévue dans la spécification n'est pas implémentée | Écart d'exigence | Informatif | Ouvert |
Les lignes ci-dessus illustrent la forme ; ce ne sont pas des constats d'une mission réelle. Les catégories de la troisième colonne sont les noms de l'OWASP Top 10:2025, pour que le client puisse s'y référer.
5. Constats avec preuves
Chaque constat reçoit les mêmes champs, dans le même ordre, à chaque fois. Le WSTG les liste : un ID de référence, un titre, la vraisemblance, l'impact, une note de risque, une description du problème et de son exploitation, des étapes de remédiation et, en option, des artefacts reproductibles comme une commande curl pour que le développeur confirme le correctif. Nous ajoutons deux champs pour le code généré par IA :
- D'où ça vient. Le fichier et la ligne, et si le motif se répète ailleurs. Le code généré copie ses propres erreurs ; un identifiant de tenant non vérifié, c'est en général cinq.
- Pourquoi c'est probablement arrivé. Non pour désigner un coupable, mais parce que le correctif se trouve souvent dans le prompt ou le gabarit, pas seulement dans le code. « Le handler de route a été généré sans périmètre d'espace de travail parce que l'instruction ne mentionnait pas la multi-location » dit à l'équipe comment arrêter de produire le même bug.
Une preuve, c'est quelque chose que l'ingénieur du client peut exécuter. Une capture d'écran de scanner n'est pas une preuve ; la requête qui a renvoyé les données d'un autre tenant en est une.
6. Plan de remédiation
Transformez les constats en travail. Classez-les par sévérité, puis par le nombre d'autres constats qu'un correctif ferme. Donnez à chacun un responsable côté client, une date cible et une étape de vérification (« re-tester F-01 avec le script à deux tenants de l'annexe B »). Distinguez corriger maintenant, corriger avant le lancement et corriger dans le trimestre. Un plan sans dates est une liste.
7. Validation
Qui a réalisé l'audit et ses qualifications, qui côté client a accepté le rapport et quand, quel re-test est compris dans le tarif, jusqu'à quand le rapport est valable (nous indiquons le commit, pas une date) et les conditions de confidentialité. Si le client montrera le rapport à un tiers, précisez quelle version : la plupart des acheteurs n'ont besoin que de la synthèse et du tableau de sévérité, pas des étapes de reproduction.
Un squelette Markdown à copier
Collez-le dans votre outil de documents et remplissez-le. Les libellés de section sont en gras pour ne pas entrer en conflit avec les titres de la page où vous le collez.
**Rapport d'audit : <nom du produit>**
Version 1.0 · <date> · Préparé par <cabinet> pour <client> · Confidentiel
**1. Synthèse**
Périmètre en une phrase. Verdict en une phrase.
Constats : <n> critiques, <n> élevés, <n> moyens, <n> faibles, <n> informatifs.
Thèmes : (1) ... (2) ... (3) ...
Ce qui fonctionne bien : ...
**2. Périmètre et exclusions**
Dépôts et commits : <repo>@<sha>
Environnements : ...
Dates : <début> au <fin>
Provenance (déclaration du client) : ~<x> % généré avec <outils>, relu par ...
Hors périmètre : ... (raison)
**3. Méthode**
Outils et versions : ...
Liste de contrôle : <lien>
Modèle de sévérité : échelle qualitative CVSS v4.0 + Informatif
Assistance IA pendant la revue : oui/non, pour ...
**4. Tableau de sévérité**
| ID | Constat | Catégorie (OWASP Top 10:2025) | Sévérité | Statut |
**5. Constats**
F-01 <titre>
Sévérité : ... Vraisemblance : ... Impact : ...
Emplacement : <fichier:ligne>, aussi dans ...
Description : ...
Preuve (reproductible) : ...
Pourquoi c'est probablement arrivé : ...
Correctif : étape 1, étape 2 ...
Références : ...
**6. Plan de remédiation**
| Ordre | Constat | Responsable | Date cible | Vérification |
**7. Validation**
Audité par : ... Accepté par : ... Date : ...
Re-test inclus : ... Valable pour le commit : ...
Le modèle de liste de contrôle d'audit de code hébergé est le pendant côté revue : c'est la liste que vous parcourez avant d'avoir quoi que ce soit à mettre en section 5.
Produire le rapport en cinq étapes
- Fixez le périmètre par écrit avant de commencer. Hashes de commit, environnements, exclusions. Envoyez-le au client et attendez sa réponse. Tout le rapport y renvoie.
- Lancez d'abord les passes automatiques et triez-les. SAST, audit de dépendances, scan de secrets. L'essentiel de ce qu'elles renvoient est du bruit ; le rapport ne doit contenir que ce que vous avez confirmé à la main, la sortie des scanners allant en annexe.
- Faites la revue manuelle avec une liste de contrôle. Authentification, autorisation sur chaque route, traitement des entrées, paiements et webhooks, export et suppression des données, tâches en arrière-plan. Pour du code généré par IA, lisez aussi les prompts, gabarits et fichiers de règles si le client les a ; ils expliquent les motifs que vous allez trouver.
- Auditez les exigences, pas seulement le code. Prenez le PRD ou le brief d'origine, listez chaque exigence et marquez-la implémentée, partielle ou absente. Les bases de code générées sont souvent complètes sur le chemin nominal et vides pour tout ce que le prompt n'a pas mentionné. Reportez les écarts dans le tableau de sévérité en Informatif ou plus, selon ce que le client a promis à ses propres clients.
- Rédigez les constats, puis le plan, puis la synthèse. Dans cet ordre. La synthèse est une compression des constats ; l'écrire en premier produit une synthèse de vos hypothèses.
Comment nous procédons dans Atrix
Nous rédigeons le rapport comme une page dans Atrix, pas comme un fichier Word, parce que le rapport et le travail de remédiation doivent vivre côte à côte. La page contient les sept sections ; chaque ligne du plan de remédiation est un ticket dans un cycle, avec un responsable, une échéance et l'étape de vérification dans sa description. Quand un ingénieur ferme F-01, le plan se met à jour, et le re-test est un second ticket, pas un rappel dans la boîte mail de quelqu'un.
Le client reçoit un lien de partage vers la page : il lit la version courante et les commentaires restent dans un seul fil. L'historique des versions montre ce qui a changé entre le brouillon et le rapport accepté. À la clôture de la mission, l'export Markdown donne au client un fichier qui lui appartient.
Une limite à énoncer clairement : l'agent IA d'Atrix ne scanne pas le code. Sa fonction d'audit est un audit des exigences, qui compare ce qui a été construit à une base de référence d'exigences figée et rend compte de la couverture et des dérives. C'est l'étape 4 ci-dessus, et elle est utile. Les étapes 2 et 3, les scanners et la lecture humaine des chemins d'authentification et de paiement, se font dans vos outils SAST et dans la tête de vos relecteurs. Si un client veut un audit de code humain réalisé par nous plutôt que par le logiciel, c'est le travail de l'agence, pas du produit ; voir notre approche des audits de code avec l'IA pour savoir où l'IA aide la revue et où elle induit en erreur.
FAQ
Que doit contenir un rapport d'audit de code IA ?
Sept sections : une synthèse, le périmètre et les exclusions, la méthode, un tableau de sévérité, une entrée par constat avec preuve reproductible et correctif, un plan de remédiation avec responsables et dates, et une validation. Pour du code généré par IA, ajoutez la provenance au périmètre et une vérification de couverture des exigences aux constats.
Quelle échelle de sévérité utiliser dans un rapport d'audit de code ?
Une échelle publique, pour que les clients puissent comparer les rapports. L'échelle qualitative CVSS v4.0, publiée par FIRST, classe 9,0 à 10,0 en Critique, 7,0 à 8,9 en Élevé, 4,0 à 6,9 en Moyen et 0,1 à 3,9 en Faible. Ajoutez un niveau Informatif pour les constats qui ne sont pas des vulnérabilités, comme des tests absents ou des exigences non implémentées.
Quelle longueur doit avoir un rapport d'audit de code ?
Celle qu'exigent les constats, pas plus. Un audit de deux semaines d'un petit SaaS produit en général une synthèse d'une demi-page, un tableau de sévérité d'une page et cinq à vingt entrées de constat d'une demi-page chacune. Les sorties de scanners et les journaux bruts vont en annexe, pas dans le corps.
Le client doit-il recevoir le rapport complet ou seulement un résumé ?
Les deux, en documents séparés. Le rapport complet va au responsable technique du client. Une version courte avec la synthèse et le tableau de sévérité, sans étapes de reproduction, est celle qu'il peut transmettre à un acheteur, un investisseur ou un auditeur.
Un audit de code IA remplace-t-il un test d'intrusion ?
Non. Un audit de code lit la source ; un test d'intrusion attaque le système en fonctionnement. Ils trouvent des choses qui se recoupent mais diffèrent. La plupart des acheteurs SOC 2 demandent un test d'intrusion de moins de douze mois ; l'audit de code se fait avant, pour que le test trouve moins.
En quoi un audit de code IA diffère-t-il d'un audit de code classique ?
Le format est le même. L'accent se déplace vers des contrôles d'accès absents plutôt qu'erronés, des dépendances que personne n'a choisies, des motifs répétés dans de nombreux fichiers et des exigences jamais implémentées parce que le prompt ne les mentionnait pas. Le rapport doit indiquer quelle part du code a été générée et vérifier les exigences en plus de la sécurité.
Prochaine étape
Parcourez la liste de contrôle d'audit de code hébergée avant de rédiger la section 5, et voyez comment les agences gèrent le travail client dans Atrix avec le rapport en page, les correctifs en tickets et le client sur un lien de partage. Pages et tableaux blancs couvre la coédition, l'historique des versions et l'export Markdown.
Sources
Structure du rapport et champs des constats : OWASP Web Security Testing Guide, Reporting Structure et modèle de rapport d'évaluation de sécurité de Lenny Zeltser. Bandes de sévérité : spécification CVSS v4.0, FIRST, tableau 22. Noms de catégories : OWASP Top 10:2025. Niveaux de vérification : OWASP ASVS 5.0.0, publié le 30 mai 2025. Le tout vérifié en octobre 2026.