Comment lire un rapport d'audit de code sans être dev

Un client m'a appelé un samedi matin, en panique. Il venait de recevoir son rapport d'audit : 47 vulnérabilités. Il voulait tout arrêter — couper les serveurs, prévenir ses clients, appeler un avocat. J'ai ouvert le rapport. 45 des 47 vulnérabilités étaient des dépendances logicielles obsolètes sans impact réel. Le vrai problème tenait en une ligne, page 18 : une interface qui exposait les données de tous ses clients sans aucune vérification d'identité.

Ce fondateur n'est pas stupide. Il est dirigeant. Il ne code pas. Et personne ne lui a jamais expliqué comment lire un rapport d'audit.

Voici ce que j'aurais aimé lui dire avant qu'il panique : comment lire un rapport d'audit technique en 15 minutes, distinguer ce qui est critique de ce qui est cosmétique, et savoir exactement quoi demander à votre équipe ensuite.

Un rapport d'audit de code, c'est quoi concrètement ?

C'est un document qui liste les problèmes trouvés dans votre application par un expert externe. Sécurité, qualité du code, performance — selon le périmètre de l'audit, le rapport couvre un ou plusieurs de ces axes.

La structure est presque toujours la même :

1. Un résumé exécutif — la synthèse pour les décideurs (en théorie)
2. La liste des findings — chaque problème identifié, classé par niveau de gravité
3. Les détails techniques — le code concerné, la démonstration, la recommandation
4. Un récapitulatif chiffré — le nombre de problèmes par catégorie

Le problème : ces rapports sont écrits par des développeurs pour des développeurs. L'auditeur s'adresse au CTO ou à l'équipe technique. Pas au fondateur. Vous vous retrouvez avec 30 pages de jargon, des scores que vous ne comprenez pas, et zéro visibilité sur ce qui nécessite une décision de votre part.

Ce qu'il faut retenir : le rapport n'est pas la fin du process, c'est le début. Un rapport qui reste dans Google Drive ne sert à rien. Ce qui compte, c'est ce que vous en faites. Et pour ça, il faut savoir le lire.

Les 5 choses à regarder en premier

Vous n'avez pas besoin de lire les 30 pages. Vous avez besoin de regarder 5 choses, dans cet ordre.

1. Les findings "critiques" — pas le résumé exécutif

Je sais, ça semble contre-intuitif. Le résumé est censé être fait pour vous. Mais j'ai vu des executive summaries qui disent "globalement satisfaisant" alors qu'une faille critique se cache en page 18.

Pourquoi ? Certains auditeurs édulcorent le résumé pour ne pas affoler le client. D'autres résument 30 findings en 3 lignes et la nuance se perd.

Ce que vous devez faire : cherchez la section qui liste les problèmes classés "Critique" ou "High". C'est souvent un tableau avec des codes couleur — rouge pour critique. S'il y a zéro critique, soufflez. S'il y en a un seul, lisez-le, même si le jargon vous échappe.

J'ai un autre client, dans le e-commerce, qui a fait l'inverse. Il a lu le résumé — "rien de bloquant" — et rangé le PDF. Trois mois plus tard, piratage. L'auditeur avait signalé une injection SQL sur la page de paiement, classée "critique". Mais elle était noyée entre une alerte sur les cookies et un problème de compression d'images. Personne ne l'avait vue.

2. Les problèmes d'accès aux données

Dans le rapport, vous verrez peut-être les termes "IDOR", "broken access control" ou "unauthorized data access". Traduction : est-ce qu'un utilisateur peut voir ou modifier les données d'un autre utilisateur ?

C'est le problème le plus dangereux que je retrouve dans mes audits de code, surtout sur du code généré par IA. L'application fonctionne parfaitement — chacun voit son profil, ses commandes, ses données. Mais en coulisses, il suffit de changer un numéro dans l'URL pour accéder aux données de quelqu'un d'autre.

Si votre rapport mentionne ce type de problème, c'est l'urgence absolue. Ça veut dire que les données de vos clients sont accessibles à n'importe qui.

3. Les secrets exposés

"Secrets exposés", "clés API en clair", "credentials hardcodés" — si vous voyez ces termes, soulignez-les en rouge.

Ça veut dire que des mots de passe ou des clés d'accès à vos services (paiement, hébergement, base de données) sont visibles dans le code source. Pour simplifier : c'est comme si les clés de votre bureau étaient scotchées sur la porte d'entrée.

Si le code est sur un dépôt public — GitHub par exemple — ces clés sont potentiellement déjà compromises. Le rapport devrait le mentionner clairement et recommander de les révoquer immédiatement.

4. Les problèmes d'authentification

L'authentification, c'est la porte d'entrée de votre application. Le rapport peut signaler des choses comme :

• Mots de passe stockés en clair — si la base de données fuit, tous vos utilisateurs sont compromis
• Pas de limite de tentatives de connexion — un attaquant peut tester des milliers de combinaisons automatiquement
• Sessions qui n'expirent jamais — un accès volé reste valide indéfiniment
• Back-office accessible sans protection — n'importe qui tombe sur l'interface d'administration

Chacun de ces points est un risque concret. Pas dans 2 ans. Maintenant.

5. Les risques sur les données personnelles

Si votre application collecte des emails, des noms, des adresses, des numéros de téléphone — le rapport peut signaler des problèmes liés au RGPD :

• Des données personnelles envoyées à des services tiers sans consentement
• Des données stockées sans chiffrement
• Aucun mécanisme de suppression (le fameux droit à l'oubli)

Ce n'est pas qu'un sujet technique. C'est un risque juridique. Une seule plainte d'un utilisateur peut déclencher un contrôle CNIL. Si votre rapport signale ce type de problème, ne remettez pas ça à plus tard.

Critique vs cosmétique : le ratio qui change tout

Dans un rapport d'audit typique, la répartition ressemble à ça :

• 5% des findings sont critiques — ce qui peut vous faire pirater ou tomber sous le coup de la loi
• 15% sont de vrais problèmes — à traiter dans les 3 mois
• 80% sont du bruit — bonnes pratiques non suivies, suggestions d'amélioration, warnings mineurs

Reprenons mon client aux 47 vulnérabilités :

• 45 vulnérabilités "moyennes" ou "basses" — des bibliothèques logicielles pas mises à jour. Risque réel dans son cas : quasi nul. C'est l'équivalent de "vos pneus ont 18 mois, pensez à les changer un jour".
• 1 vulnérabilité "basse" — un avertissement de propreté du code. Impact : zéro. Purement cosmétique.
• 1 vulnérabilité "critique" — l'interface qui exposait les données de tous ses clients. Impact : vol de données, perte de confiance, potentiellement amende CNIL.

47 vulnérabilités. 1 seul vrai problème. Le chiffre fait peur. La réalité est plus nuancée — et c'est pour ça que le nombre de findings ne veut rien dire sans le contexte de criticité. Un rapport avec 3 problèmes dont 1 critique est bien plus préoccupant qu'un rapport avec 50 warnings mineurs.

Comment lire les niveaux de criticité

La plupart des rapports classent les findings en 4 niveaux :

Certains rapports utilisent des scores numériques (CVSS). La règle simple : en dessous de 4, c'est mineur. Entre 4 et 7, c'est sérieux. Au-dessus de 7, c'est urgent. Au-dessus de 9 — arrêtez de lire cet article et appelez votre dev.

Les 5 questions à poser après

Vous avez lu le rapport. Vous savez ce qui est critique. Reste à transformer ça en actions.

"Quels problèmes peuvent causer un vol de données ou un piratage ?" Attendez une liste précise. Pas un "on gère" ou un "c'est en cours". Si votre dev ne peut pas isoler les risques réels des warnings cosmétiques, c'est un signal d'alerte en soi.

"Combien de temps et combien ça coûte pour corriger les points critiques ?" Un problème critique, ça se corrige en heures ou en jours. Pas en mois. Si on vous annonce 3 mois pour corriger une faille critique, creusez — soit le problème est plus profond qu'une simple faille, soit l'estimation est gonflée.

"Faut-il couper l'accès en attendant ?" Si une faille permet d'accéder aux données d'autres utilisateurs, la réponse est peut-être oui. Mieux vaut une app indisponible 2 heures qu'une fuite de données qui vous coûte des mois de réputation.

"Comment on vérifie que c'est corrigé ?" La bonne réponse : un re-test. L'auditeur repasse sur les points critiques après correction. Un rapport "corrigé" sans vérification, ça ne vaut pas grand-chose. Demandez une confirmation écrite.

"Quand est-ce qu'on refait un audit ?" Un audit n'est pas un one-shot. Après chaque évolution majeure de l'application, avant chaque milestone business — levée de fonds, gros client, mise en conformité — un nouvel audit s'impose.

J'ai eu un client avec un rapport impeccable. 45 pages, détaillé, chaque finding documenté. Le CTO a tout compris. Le fondateur, rien. Le rapport a traîné 6 mois dans un dossier partagé. Aucune correction. Le problème n'était pas la qualité du rapport — c'était l'absence de traduction en décisions business. Ces 5 questions, c'est exactement ça : transformer un document technique en plan d'action.

Guide : les 5 choses à regarder en premier dans un audit de code

La version condensée. Gardez-la sous la main pour votre prochain rapport.

1. Section "Critiques" Allez-y directement, ignorez le résumé exécutif. → "Est-ce qu'un de ces problèmes est exploitable aujourd'hui ?"

2. Accès aux données Cherchez : "IDOR", "access control", "unauthorized access". → "Un utilisateur peut-il voir les données d'un autre ?"

3. Secrets exposés Cherchez : "API key", "credentials", "hardcoded", "secrets". → "Des clés ou mots de passe sont-ils visibles dans le code ?"

4. Authentification Cherchez : "authentication", "password", "token", "session". → "La porte d'entrée de notre app est-elle solide ?"

5. Données personnelles Cherchez : "GDPR", "RGPD", "personal data", "PII". → "Est-ce qu'on risque quelque chose côté CNIL ?"

Un rapport d'audit de code n'est pas un verdict. C'est un outil de décision. Le plus grave, ce n'est pas d'avoir des vulnérabilités — toutes les applications en ont. C'est de ne pas savoir lesquelles sont dangereuses.

Maintenant, vous savez où regarder. Si vous avez un rapport sous le coude qui dort dans un dossier, rouvrez-le avec cette grille. Et si vous n'avez jamais fait auditer votre code — c'est peut-être le moment d'y penser.