Le dirigeant d'une société B2B reçoit depuis des mois des signaux inquiétants sur deux de ses sites web : pages lentes, comportements instables, et une relation tendue avec l'agence prestataire qui maintient les sites depuis des années. Le dialogue est difficile. Les alertes ne semblent pas prises au sérieux.
Il commande un audit technique externe. Le point de départ annoncé : les performances.
La mission
Intervenir en tant que regard extérieur, sans lien avec l'agence en place, pour analyser les deux sites web de bout en bout et produire un état des lieux objectif.
Durée : environ 9 jours. Périmètre : serveur, configuration, plugins, code custom, pratiques de développement.
Mon approche
Jour 1 - commencer par les logs, pas par le code
Avant de toucher à quoi que ce soit, j'ai lu les logs. Ce que j'y ai trouvé dès le premier jour : des crons qui se déclenchent à des intervalles trop rapprochés, s'empilent sans jamais terminer, et des appels à des colonnes et tables qui n'existent plus en base. Des symptômes visibles pour qui sait regarder.
Jours 2 à 7 - rester factuel
L'audit a progressé par périmètre : configuration serveur, plugins (nombreux), code métier custom. Ce type de mission pose souvent la même question implicite : le commanditaire veut-il confirmer que tout va bien, ou avoir la légitimité de dire que ça va mal ? La réponse ne m'appartient pas. Je documente ce que je trouve — à charge au client d'en faire l'usage qu'il juge utile.
Le tournant : une faille de sécurité critique
Au jour 6, j'ai découvert que des clés API confidentielles - contenant des données tarifaires de l'entreprise - étaient accessibles publiquement, en clair, sur internet. Une simple URL suffisait.
Le client n'a pas immédiatement saisi la gravité. J'ai reformulé, illustré l'impact concret, et signalé le point en urgence dans le mail récap - en bleu, en gras. Le sujet est remonté immédiatement dans les priorités.
Situation délicate : l'agence prestataire étant responsable du code en production, je ne pouvais pas corriger moi-même sans risque juridique. J'ai cadré clairement la frontière entre l'audit et la correction, et orienté le client vers son prestataire pour l'action immédiate.
Les livrables
1. Documentation technique (~100 pages)
Un état des lieux exhaustif, organisé par rubriques : serveur, base de données, plugins, code, sécurité. Dense, précis, destiné aux profils techniques qui prendront les décisions d'implémentation.
2. Support PowerPoint simplifié
Une synthèse visuelle conçue pour être présentée aux équipes non techniques - direction, responsables métier. Chaque problème est présenté avec deux indicateurs : niveau de complexité et niveau de danger. Ce format, suggéré par le client en fin de mission, est depuis intégré à tous mes livrables d'audit.
"Le dossier technique doit être violent, sinon il manque quelque chose. Mais le PowerPoint est là pour faire l'interface - pour que tout le monde puisse comprendre."
- Le client, au débrief de fin de mission
Le retour client
Le débrief de fin de mission a duré une trentaine de minutes. Quelques extraits :
"Tu étais complètement indépendante du projet. Tu arrives, tu regardes le site - et ça, c'était vraiment important dans notre contexte. Un prestataire interne n'aurait jamais remonté ses propres coquilles."
Sur la dérive de scope (performance → sécurité) :
"Au contraire, ça crédibilise l'audit. On n'avait pas fixé d'objectifs rigides - c'était de la découverte. Quand on réfléchit trop à ce qu'on cherche, on passe à côté."
Ce que cette mission illustre
L'indépendance comme condition de l'objectivité. Un prestataire qui maintient un projet ne peut pas en être le juge. Intervenir sans histoire avec le code existant, sans relation commerciale à préserver, c'est ce qui permet de dire ce qui est - même quand c'est inconfortable.
La lisibilité comme livrable à part entière. Un rapport technique qui ne peut être lu que par des spécialistes ne déclenche pas d'action. Le format double - technique pour les experts, vulgarisé pour les décideurs - permet à chaque interlocuteur de prendre ses responsabilités avec les informations adaptées à son niveau.
Audit ≠ correction. La frontière est contractuelle autant que technique. La signaler clairement protège tout le monde : le client, le prestataire en place, et moi.
