Audit de code : ce qu’il vérifie et ce qui détermine son prix

En résumé : un audit de code utile examine la structure, la santé des dépendances, les tests là où ils comptent, l'exposition en sécurité et les parties que seule une personne comprend, puis classe les constats et chiffre chacun. Son prix dépend de la taille du code et de la profondeur demandée : exigez un prix fixe, un périmètre écrit et une date. Voici ce qu'un bon audit couvre, avec des constats réels tirés d'audits de mes propres projets en production.

Ce qu'un audit de code vérifie

• La structure : les responsabilités sont-elles séparées de sorte qu'un changement ici ne casse pas trois choses ailleurs ? Le modèle de données peut-il porter les douze prochains mois ?
• La santé des dépendances : paquets obsolètes ou abandonnés, vulnérabilités connues. La commande d'audit du gestionnaire de paquets est un point de départ, pas une conclusion.
• Les tests là où ça compte : paiements, droits d'accès, migration de données. Un taux de couverture élevé peut masquer un cœur non testé.
• L'exposition en sécurité : authentification, sessions, isolation entre clients, envoi de fichiers, injections, secrets dans le dépôt.
• Les points de connaissance uniques : les modules que seul un développeur a touchés, repérés dans l'historique des commits.
• Le processus de livraison : comment le code arrive en production, et si une version peut être annulée.

Des constats réels

• Un SaaS multi-clients pour garages : 14 anomalies documentées corrigées, dont plusieurs risques sérieux de fuite entre clients : une requête sans filtre sur l'identifiant du client aurait pu exposer les certificats d'un garage à un autre.
• Un site d'agence avec son CMS : aucune requête vulnérable à l'injection SQL, malgré une connexion autorisant plusieurs instructions ; une faille de sévérité haute : un fichier GIF ou SVG mal étiqueté pouvait déclencher du XSS stocké. Corrigée.
• Un outil de résumé de réunions par IA : une clé d'API committée dans un fichier d'environnement du frontend (sévérité haute), plus trois constats moyens et quatre faibles.
• Une application de budget familial : une fuite d'isolation entre foyers via une clé étrangère non validée, et un jeton de rafraîchissement sans moyen de révocation.

Trois de ces quatre cas relèvent du contrôle d'accès ou de la gestion des secrets, pas d'attaques sophistiquées : les risques les plus lourds des produits jeunes sont rarement exotiques, ce sont des contrôles manquants.

Ce qui détermine le prix

Je ne donnerai pas de moyenne de marché : les prix varient fortement et un chiffre non sourcé vous tromperait. Ce qui fait le prix est connu :

• la taille et l'âge du code, et le nombre d'applications (web, mobile, API) ;
• la profondeur : une revue ciblée des zones à risque coûte beaucoup moins qu'une relecture ligne à ligne, et suffit souvent pour décider ;
• le livrable : une matrice de risques classée avec le chiffrage en jours-développeur demande plus de travail qu'une liste d'avertissements, mais c'est la seule version exploitable ;
• l'indépendance : un audit réalisé par un prestataire qui espère vendre la correction est une proposition commerciale avec une matrice de risques agrafée.

Cinq questions à poser à tout auditeur

1. Que vais-je recevoir exactement, et sous quelle forme ?
2. Chiffrez-vous chaque constat en jours-développeur ?
3. Comptez-vous répondre à l'appel d'offres de correction ?
4. Qui lira le code : vous, ou un junior et un scanner ?
5. Qu'est-ce qui n'est pas couvert ? Le test d'intrusion, par exemple, est une mission distincte.

Pour aller plus loin

Mon audit de risque projet suit ce cadre : dix jours ouvrés, prix fixe, matrice de risques sur une page, les trois zones les plus faibles chiffrées en jours-développeur, un plan à 90 jours et une restitution de 90 minutes. Je ne réponds pas à l'appel d'offres de correction.