La plupart des audits technologiques sont des exercices de documentation. Un consultant examine vos diagrammes d'architecture, interviewe quelques ingénieurs seniors, lit vos politiques de sécurité, et produit un rapport qui décrit ce que vous lui avez dit. Un véritable audit fait quelque chose de différent : il expose l'écart entre ce que vous croyez de vos systèmes et ce qui est réellement vrai.
Ce que la plupart des audits manquent
La documentation de vos systèmes décrit les systèmes tels qu'ils ont été conçus pour fonctionner. Elle décrit rarement comment ils fonctionnent réellement en production. Ces deux réalités divergent avec le temps — parfois de façon dramatique — au fur et à mesure que les équipes prennent des décisions pragmatiques sous pression, que le code legacy s'accumule, et que la connaissance institutionnelle de certains processus critiques vit dans la tête de deux ou trois ingénieurs qui ne font peut-être plus partie de l'entreprise.
Les cinq couches d'un vrai audit
- Qualité du code et dette technique : pas seulement la revue de code, mais l'analyse des dépendances, la réalité de la couverture des tests, et l'identification des modules que personne ne veut toucher.
- Architecture et intégrité des données : où les données vivent réellement, comment elles se déplacent entre les systèmes, si les données sur lesquelles vous rapportez sont celles que vous pensez.
- Posture de sécurité : pas une checklist contre un framework, mais une revue du modèle de menaces par rapport à votre surface d'attaque réelle.
- Résilience opérationnelle : comment le système se comporte réellement sous charge, ce qui se passe quand les dépendances échouent.
- Distribution des connaissances de l'équipe : où se trouvent les points de défaillance uniques dans la connaissance humaine, pas seulement dans l'infrastructure.
“Le risque technique le plus coûteux dans la plupart des organisations n'est pas une vulnérabilité dans leur code. C'est la fragilité de la connaissance qui maintient leurs systèmes en fonctionnement.”
Comment utiliser les résultats
Un audit technique n'est utile que s'il produit un plan d'action priorisé, pas une liste de problèmes. Nous classons chaque constat selon deux dimensions : la probabilité qu'il cause un incident grave dans les 12 prochains mois, et le coût de le traiter maintenant par rapport à après qu'il devienne une crise.