La plupart des audits d’architecture sont inutiles
Soyons directs : 80% des audits d’architecture que j’ai vus dans ma carrière sont des exercices de style. Des documents de 150 pages que personne ne lit, remplis de recommandations génériques qu’on pourrait copier-coller d’un projet à l’autre.
“Nous recommandons d’adopter une architecture microservices.” Merci, mais quel service découper, comment, et surtout pourquoi maintenant plutôt que dans 6 mois ?
Un vrai audit d’architecture, c’est un diagnostic médical. Il ne se contente pas de dire “vous avez mal” — il localise précisément la douleur, en identifie la cause, et propose un traitement adapté à votre contexte.
Ce qu’un audit sérieux couvre vraiment
La cartographie de l’existant
Avant de recommander quoi que ce soit, il faut comprendre ce qui existe. Pas ce qui est documenté (la doc est toujours obsolète) — ce qui tourne réellement en production.
- Inventaire des services et dépendances : qui appelle qui, avec quelle fréquence, quel volume
- Flux de données : où naissent les données, où elles transitent, où elles sont stockées
- Points de couplage : les dépendances dures qui empêchent de faire évoluer un composant sans tout casser
- Dette technique localisée : pas “il y a de la dette technique” — mais précisément où, combien ça coûte, et quel est le risque associé
L’analyse de performance sous charge
Les tests de performance en conditions normales ne servent à rien. Ce qui compte, c’est le comportement sous stress.
Un audit rigoureux inclut :
- Tests de charge progressifs jusqu’au point de rupture
- Identification des goulots d’étranglement : base de données, réseau, CPU, mémoire
- Analyse du comportement de dégradation : comment le système se comporte quand il atteint ses limites (graceful degradation vs crash brutal)
- Mesure des temps de récupération : combien de temps pour revenir à la normale après un pic
La posture de sécurité
Pas un pentest (c’est un autre sujet). Mais une évaluation de la surface d’attaque architecturale :
- Gestion des secrets et des credentials
- Segmentation réseau et isolation des services
- Politiques d’authentification et d’autorisation entre services
- Chiffrement des données au repos et en transit
- Conformité RGPD dans les flux de données identifiés
Les coûts d’infrastructure
Un audit qui ignore le volet financier est incomplet. L’architecture a un coût, et ce coût doit être maîtrisé :
- Analyse FinOps : répartition des coûts par service et par environnement
- Identification des ressources surdimensionnées (le classique : des instances en prod dimensionnées pour le Black Friday toute l’année)
- Projection des coûts en fonction des scénarios de croissance
Les livrables concrets à exiger
Ce que vous devez recevoir
- Un schéma d’architecture as-is — pas un dessin conceptuel, mais le reflet exact de la production avec les versions, les protocoles, les volumes
- Une matrice de risques priorisée — chaque risque identifié, qualifié (probabilité x impact), avec une recommandation d’action
- Un plan de remédiation séquencé — pas une liste de courses, mais un ordre d’exécution logique avec les dépendances entre actions
- Des quick wins identifiés — les actions à fort impact et faible effort qui peuvent être lancées immédiatement
- Des métriques de référence — les chiffres actuels qui serviront de baseline pour mesurer les progrès
Ce qui doit vous alerter
Si votre auditeur vous livre uniquement :
- Un document Word sans schémas techniques détaillés
- Des recommandations sans estimation d’effort ni de priorité
- Des préconisations technologiques sans analyse du contexte existant
- Un audit réalisé sans accès aux environnements de production — c’est un signal fort que le travail est superficiel
La méthodologie qui fonctionne
Phase 1 : Immersion (3-5 jours)
L’auditeur s’immerge dans le contexte. Il lit le code, parcourt les pipelines, analyse les logs de production, interviewe les équipes techniques. Pas les managers — les développeurs et ops qui vivent le quotidien.
C’est la phase la plus importante et la plus souvent bâclée. Un audit sans immersion technique, c’est un médecin qui diagnostique par téléphone.
Phase 2 : Analyse (5-8 jours)
Croisement des données collectées. Identification des patterns problématiques. Tests de charge et de résilience. Construction de la cartographie et de la matrice de risques.
Phase 3 : Recommandations (3-5 jours)
Formulation des recommandations concrètes, chiffrées, séquencées. Pas “il faudrait migrer vers Kubernetes” mais “migrer le service catalogue sur GKE en Q2 permettrait de réduire les coûts d’infrastructure de 30% et d’améliorer le temps de déploiement de 4h à 15 minutes — voici le plan en 6 étapes.”
Phase 4 : Restitution et transfert
La restitution ne se fait pas en une réunion de 2 heures devant 20 personnes. Elle se fait en atelier technique avec les équipes qui vont implémenter les recommandations. Questions, challenges, ajustements — c’est un dialogue, pas une présentation.
Les erreurs classiques des audits
Auditer sans contexte business
L’architecture n’existe pas dans le vide. Un audit qui recommande une refonte complète sans comprendre que le Black Friday est dans 8 semaines est un audit hors sol. Les contraintes business dictent les priorités techniques, pas l’inverse.
Recommander la stack à la mode
Kubernetes n’est pas la réponse à tout. Ni les microservices. Ni le serverless. La bonne architecture est celle qui répond au besoin avec la complexité minimale nécessaire. Un monolithe bien structuré est souvent préférable à une architecture distribuée mal maîtrisée.
Ignorer le facteur humain
L’architecture cible doit être opérable par l’équipe en place. Recommander une stack que personne ne maîtrise sans prévoir la montée en compétence, c’est programmer l’échec.
Quand lancer un audit
Les déclencheurs classiques :
- Avant une refonte majeure : pour cadrer le périmètre et éviter de reproduire les mêmes erreurs
- Après une série d’incidents : pour identifier les causes structurelles, pas juste les symptômes
- En cas de croissance rapide : quand l’architecture conçue pour X commence à craquer à 10X
- Lors d’un changement de direction technique : nouveau CTO, nouvelle stratégie, besoin d’un état des lieux objectif
L’audit n’est pas une fin en soi. C’est le point de départ d’une feuille de route technique fondée sur des faits, pas sur des intuitions.
FAQ
Combien de temps dure un audit d’architecture complet ?
Entre 3 et 6 semaines selon la taille du périmètre. Méfiez-vous des audits express en 3 jours — ils survoleront nécessairement des aspects critiques. À l’inverse, un audit qui s’étend sur 3 mois est probablement surdimensionné par rapport au besoin. Le sweet spot pour une plateforme e-commerce de taille moyenne est autour de 4 semaines.
Faut-il donner accès à la production à l’auditeur ?
Oui, c’est indispensable. Un audit sans accès aux environnements réels est comme un diagnostic sans examen clinique. L’accès doit être encadré (lecture seule, traçabilité, NDA), mais il est non négociable pour un audit sérieux. Si votre prestataire ne demande pas d’accès à la prod, questionnez la profondeur de son analyse.
Comment choisir le bon auditeur ?
Trois critères : premièrement, il doit avoir une expérience opérationnelle réelle (avoir construit et opéré des systèmes, pas seulement audité). Deuxièmement, il doit connaître votre domaine métier (un expert e-commerce n’auditera pas de la même façon qu’un expert fintech). Troisièmement, demandez des exemples concrets de recommandations passées et leurs résultats mesurés.
Que faire si l’audit révèle une dette technique massive ?
Ne paniquez pas — c’est plus courant qu’on ne le pense. L’important est de prioriser. Toute la dette ne se vaut pas. Concentrez-vous d’abord sur la dette qui génère des risques business (incidents, perte de revenus, failles de sécurité), puis sur celle qui freine la vélocité de l’équipe. Un plan de remédiation sur 12-18 mois est réaliste et permet de ne pas bloquer les évolutions métier en parallèle.