Pourquoi un audit, et pourquoi maintenant
La plupart des équipes qui me contactent pour un audit n'ont pas un problème technique, elles ont un doute. L'application tient, mais plus personne ne sait dire jusqu'où. La facture d'hébergement grimpe sans que le trafic suive. Un audit de sécurité a été promis à un client et personne n'a le temps de le faire. Dans ces trois cas, un regard extérieur qui n'a ni historique ni susceptibilité dans le projet vaut plus que trois semaines de réunions internes.
Ce que je regarde concrètement
Je commence par lire le code, pas les slides. Architecture, dépendances, dette accumulée, points de fragilité que tout le monde contourne sans les nommer. Ensuite je mesure : profilage des chemins critiques, requêtes qui pèsent, latence sous charge, avec de vrais chiffres et pas des impressions. Je termine par la sécurité, en suivant la grille de l'OWASP et en passant vos dépendances au scan, parce que c'est là que se cachent les mauvaises surprises. Si votre infrastructure fait partie du périmètre, j'audite aussi la chaîne de déploiement, le monitoring, et ce qui se passerait le jour où un serveur disparaît.
Ce que vous recevez
Un rapport écrit que vos équipes peuvent lire sans moi, avec pour chaque constat le risque réel, l'effort estimé et un ordre de priorité argumenté. Pas une liste de généralités ni un devis déguisé : un plan d'action que vous pouvez confier à qui vous voulez, y compris à quelqu'un d'autre que moi. Je le présente ensuite de vive voix, pour répondre aux questions et discuter les arbitrages.
Durée et conditions
Comptez trois à cinq jours selon la taille du code et de l'infrastructure. J'ai besoin d'un accès en lecture au dépôt, d'un environnement représentatif et, si possible, des métriques de production. Un accord de confidentialité est signé avant que je n'ouvre quoi que ce soit.