composer audit, c'est gratuit. Une commande, intégrée à Composer depuis des années. PHPStan, c'est gratuit aussi. Vous l'installez en une ligne et vous le pointez sur votre code. En deux minutes, n'importe qui sort la liste des problèmes de son projet PHP, sans payer personne.
Alors la question est légitime, et autant la poser franchement : pourquoi payer 900 € à quelqu'un pour faire un truc que deux commandes gratuites font à votre place ?
Parce que cette liste n'est pas un audit. C'est l'entrée d'un audit. Le point de départ, pas le livrable. Ce que vous payez, c'est tout ce qui vient après, et c'est exactement ce que les outils ne savent pas faire.
Je vais le montrer, pas l'affirmer. Sur un vrai projet que j'ai audité : un projet PHP/Laravel mature, ~44 000 lignes, en production depuis des années. Vous allez voir la sortie brute des outils, puis ce que j'en fais. La différence entre les deux, c'est le métier.
Ce que les outils vous crachent, gratuitement
Sur ce projet, voilà ce qui tombe quand on lance les outils, dans l'ordre.
composer audit : 72 failles de sécurité connues, réparties sur 19 paquets. PHPStan, poussé au niveau 9, le plus strict : 1 619 erreurs. PHPMD, qui traque la complexité : 1 028 alertes. PHP_CodeSniffer, sur le formatage : 537 violations PSR-12.
Faites le total. Des milliers de lignes rouges. Un mur.
Et tout ça est gratuit. Aucun de ces outils ne coûte un centime, ils sont dans l'écosystème PHP depuis longtemps, accessibles à quiconque sait taper deux commandes. La sortie brute n'est pas le produit rare. C'est le contraire : c'est la matière première que tout le monde peut extraire.
Le problème, c'est qu'un mur de 3 000 alertes est parfaitement inexploitable pour décider. Mettez-vous à la place du dirigeant qui reçoit ça. Par quoi je commence ? C'est grave, 1 619 erreurs ? C'est quoi le risque réel sur mon chiffre d'affaires ? L'outil ne répond à aucune de ces questions. Il ne sait pas y répondre, ce n'est pas son métier.
Et pourtant, c'est précisément ce rapport-là, la sortie d'outils empilée, que beaucoup s'imaginent acheter quand ils paient un audit. Une liste plus longue, présentée plus proprement. Ce n'en est pas un. Ces 1 619 erreurs, je les ai d'ailleurs lues palier par palier dans un autre article : passé le premier niveau, l'écrasante majorité est du bruit de typage, pas des bugs.
Le premier vrai travail : trier
Le jugement commence là où l'outil s'arrête. Reprenons les 72 CVE. La vraie question n'est pas combien : c'est lesquelles vous concernent vraiment.
Parce qu'une faille se lit sur deux axes, et les outils n'en donnent qu'un. Il y a la gravité : la note CVSS, de 0 à 10, que le scanner affiche. Et il y a l'exposition : est-ce que la condition d'exploitation est réunie chez vous ? Ça, aucun outil ne le sait, parce qu'il ne connaît ni votre config, ni votre infra, ni la façon dont votre appli tourne en prod.
Un exemple concret, tiré de ce projet. Une des CVE était notée 9.8, la criticité quasi maximale, le genre de chiffre qui fait paniquer un CODIR. Sauf qu'en lisant la faille, elle ne se déclenche que si l'application tourne en debug mode en production. Or le debug était coupé en prod sur ce projet. Le 9.8 ne le concernait pas. Inoffensif, dans ce contexte précis.
L'inverse est vrai aussi : une faille notée "moyenne", mais sur un endpoint exposé en plein chemin critique, peut être l'urgence numéro un. La gravité, c'est la note de la faille dans l'absolu. L'exposition, c'est ce qu'elle vaut chez vous. Les deux ne sont pas le même chiffre.
Même logique sur l'origine de la faille. Plusieurs des 72 CVE touchaient des paquets qui ne tournent jamais en production : des outils de test, de debug, qui restent côté développeur. Le risque existe sur le papier, mais il sort du chemin de l'attaquant. À requalifier, donc, pas à mettre en tête de pile. Là encore, le scanner ne fait pas la différence ; il compte. C'est vous qui savez ce qui part en prod.
Trier, c'est faire ce travail-là, ligne par ligne. 72 CVE qui deviennent peut-être 12 qui comptent, dont 3 à traiter cette semaine. 1 619 erreurs PHPStan qui se réduisent à la poignée qui sont de vrais bugs, le reste étant du bruit. Ce tri n'existe nulle part dans la sortie brute. Il demande de savoir ce qui est exposé chez vous, et ça, c'est un humain qui le sait, pas un scanner. J'ai déroulé la grille de tri appliquée à ces 72 CVE ailleurs : c'est le même raisonnement, faille par faille.
Ce qu'aucun outil ne voit
Le tri, c'est déjà du jugement. Mais le vrai coeur de l'audit est ailleurs : c'est ce qu'aucun outil ne signale, parce qu'aucun outil ne lit le code comme on lit une histoire.
Trois exemples de ce projet. Trois choses qu'aucun scanner n'a remontées comme critiques, et qui le sont.
Premier : une faute de frappe. Dans le bloc catch du flux de paiement, quelqu'un avait écrit \Exeption au lieu de \Exception. Un caractère manquant. Conséquence : ce catch n'attrape rien. Quand un paiement échoue, l'erreur passe à travers, silencieusement, et personne n'est prévenu. Aucun outil ne note ça "critique business", pour un linter, c'est au mieux une classe inconnue noyée dans 1 619 lignes. Pour un oeil qui suit le flux de paiement, c'est une hémorragie qui dure peut-être depuis des années. Ça, à soi seul, ça vaut le prix de l'audit.
Deuxième : un contrôleur de 822 lignes qui concentre tout le risque transactionnel de l'appli : commandes, paiements, billets, stocks, statistiques, le tout dans un seul fichier. Un outil voit "méthode trop longue", une alerte mineure perdue parmi les 1 028 de PHPMD. Un auditeur voit autre chose : le point de défaillance unique de l'application. L'endroit où une régression fait le plus de dégâts, et où il y a le moins de tests. Le même fait, deux lectures, et seule la seconde sert à décider.
Troisième : de la logique métier dupliquée. Le flux qui invite un participant reconstruit à la main tout le flux de commande que gère déjà le flux principal. Deux copies du même raisonnement. Corrigez un bug d'un côté, vous l'oubliez de l'autre, et les deux divergent en silence. Invisible à l'outil. Évident à la lecture.
Ce qui relie ces trois trouvailles, c'est qu'aucune ne se voit dans une métrique. Elles se voient en suivant le flux métier, en se demandant "qu'est-ce qui se passe quand un client paie, et qu'est-ce qui casse si ça rate". Un outil mesure des symptômes : longueur, complexité, classes inconnues. Il ne comprend pas l'enjeu derrière. C'est ça, la ligne de partage.
Les outils trouvent ce qui est mesurable. L'auditeur trouve ce qui est important. Tout l'écart entre une liste gratuite et un audit tient dans cette phrase.
De 1 619 problèmes à 3 décisions
Trier et lire, c'est trouver les bonnes pièces. Reste à en faire quelque chose qu'un dirigeant peut décider. C'est le dernier étage, et c'est là que la liste devient un plan.
Concrètement, ça tient en trois mouvements.
Pondérer. Toutes les dimensions ne pèsent pas pareil. Une faille de sécurité et une violation de formatage PSR-12 ne sont pas le même problème, même si l'outil les affiche dans la même couleur rouge. On donne un poids à chaque axe (la sécurité compte plus que la cosmétique) et on en sort un score unique, lisible d'un coup d'oeil. Sur ce projet : 19 sur 100. Un dirigeant non technique comprend ce chiffre. Il ne comprendra jamais "1 619 erreurs de niveau 9".
Hiérarchiser. Le score dit où on en est, pas par quoi commencer. Pour ça, chaque risque est croisé entre sa probabilité et son impact : ce qui est à la fois probable et grave passe devant. La faute de frappe sur le paiement passe avant la dette de formatage, forcément.
Séquencer. Enfin, on transforme cette hiérarchie en ordre de marche : ce qu'on fait ce mois-ci, ce qu'on fait dans trois mois, ce qui peut attendre. Chaque action estimée, chiffrée, priorisée.
Le résultat, c'est le basculement. On part de "1 619 problèmes", un chiffre qui paralyse, pour arriver à "voilà les 3 chantiers, dans cet ordre, pour ce budget". De la panique à la clarté. Ça, c'est le livrable. Pas la liste : la traduction de la liste en décision.
Le détail de ce que contient le rapport (les dimensions notées, la matrice risque/impact, le plan en phases) est sur la page de l'audit. Ici, ce que je voulais montrer, ce n'est pas ce qu'il y a dedans : c'est pourquoi ça vaut son prix.
Ce qu'un audit ne fait pas
Maintenant, la part honnête. Celle qui manque sur la plupart des pages qui vendent de l'audit, parce qu'elle ne se vend pas bien.
Un audit décide. Il ne répare rien. À la fin, le code a exactement les mêmes 72 CVE qu'avant, la même faute de frappe, le même contrôleur de 822 lignes. Je n'ai pas touché une ligne. Ce que vous avez en plus, ce n'est pas un code réparé : c'est de savoir lesquelles des 72, dans quel ordre, et pour quel budget. Confondre l'audit et la réparation, c'est une façon polie de vendre la suite. Je préfère poser la frontière.
Et l'audit a ses limites, assumées. Pas de test d'intrusion. Pas d'accès au serveur de production. L'analyse porte sur le code source, pas sur l'infra ni sur la base en conditions réelles. Dire ce qu'un audit ne couvre pas, c'est ce qui rend crédible ce qu'il couvre.
Alors qu'est-ce qu'on achète, au fond ? De la clarté avant d'engager un budget. Parce que la modernisation derrière, elle, se compte en dizaines de jours-homme. Et la pire façon de dépenser ce budget, c'est de le mettre sur le mauvais chantier en premier. Décider juste avant de dépenser : c'est précisément là que le rapport se rembourse.
Bref
Les outils vous donnent la liste. L'audit vous donne la décision. La liste est gratuite, n'importe qui peut la sortir en deux commandes, et c'est très bien, allez-y. Mais la décision, savoir quoi faire de ces 1 619 lignes rouges et dans quel ordre, ça ne sort d'aucune commande. C'est ça que vous payez. Et c'est ça qui vous fait économiser, parce qu'une mauvaise priorité de modernisation coûte bien plus cher que le rapport qui l'aurait évitée.
Le cas complet d'où sortent tous ces chiffres, le projet noté 19/100, je l'ai raconté de bout en bout, si vous voulez voir l'enquête entière.