Un audit d'architecture n'est pas un avis sur votre stack technique. C'est une carte des endroits où le système casse sous le plan que vous avez réellement.
Les revues d'architecture ont mauvaise réputation parce que beaucoup ne sont que des exercices de goût — un consultant expliquant qu'il aurait choisi autrement. Un audit utile répond à une question plus étroite et bien plus précieuse : étant donné où cette entreprise compte être dans dix-huit mois, qu'est-ce qui casse, quand, et que coûte la correction ?
Les signaux qu'il en faut un maintenant
- Les performances se dégradent nettement avec l'usage, et personne ne sait dire précisément pourquoi
- Les coûts d'infrastructure augmentent plus vite que le revenu
- Un composant tombe et entraîne avec lui des fonctionnalités sans rapport
- Livrer une petite fonctionnalité oblige à toucher de nombreuses parties du système
- Vous êtes sur le point de multiplier le trafic par dix — un lancement, un partenariat, une levée
- Un investisseur a demandé si l'architecture tient la charge, et la réponse honnête est que personne ne le sait
Ce que l'audit examine
La couche de données, d'abord et surtout
Dans la plupart des systèmes, la base de données est le vrai plafond, et c'est la chose la plus coûteuse à changer plus tard. Ce qui compte : séparation lecture/écriture, indexation face aux vrais patterns de requêtes, requêtes non bornées qui grossissent avec la table, la question de savoir si un maître d'écriture unique est la limite, et si le schéma peut évoluer sans interruption.
Isolation des pannes
- Ce qui se passe quand une dépendance tierce est lente plutôt que tombée — timeouts et disjoncteurs, ou épuisement en cascade des threads
- Si un tenant ou un client lourd peut dégrader le service pour tout le monde
- Si les tâches de fond peuvent affamer le chemin des requêtes
Vitesse de changement
L'architecture ne concerne pas que la charge. Un système qui ne peut pas être modifié en sécurité échoue à sa mission, même s'il ne tombe jamais. Nous cherchons le couplage qui force des changements multi-modules, l'absence de coutures pour tester, et l'état partagé qui rend impossible tout raisonnement local.
Adéquation à la taille de l'équipe
À quoi doit ressembler le livrable
| Mauvais livrable d'audit | Livrable utile |
|---|---|
| « Envisagez les microservices » | « La table Orders atteindra la saturation en écriture vers 4× le volume actuel ; le sharding par tenant représente ~3 semaines-ingénieur » |
| « La couverture de test est faible » | « La réconciliation des paiements n'a aucun test ; une régression ici est silencieuse et financière » |
| « La dette technique est importante » | « Trois éléments bloquent la roadmap du T4 ; le reste peut attendre, et voici pourquoi » |
| Un rapport de 60 pages | Un résumé d'une page, une liste classée et un plan séquencé |
L'objet d'un audit d'architecture est de convertir une angoisse vague sur la montée en charge en un petit nombre de décisions datées et chiffrées.
Tester une hypothèse de croissance concrète
Un schéma ne montre pas la limite réelle du système. Relier une évolution d'usage aux dépendances et preuves opérationnelles.
- Suivre une requête critique à travers services, files et stockage.
- Identifier défaillances communes et hypothèses de capacité non vérifiées.
- Comparer améliorations ciblées selon impact et coût de vérification.
Questions fréquentes
Combien de temps prend un audit d'architecture système ?
Une à trois semaines pour la plupart des systèmes. Le travail consiste à lire le code et l'infrastructure, examiner les vraies métriques de production et les patterns de requêtes, et interroger les ingénieurs. Des missions plus longues signifient généralement que le périmètre a glissé vers l'implémentation.
Allez-vous nous dire de tout reconstruire ?
Très rarement, et méfiez-vous de quiconque recommande par défaut une reconstruction. La plupart des plafonds de montée en charge se relèvent par des changements ciblés — un index, une file, un cache, une clé de sharding — plutôt que par une nouvelle architecture.
Faut-il un audit d'architecture avant une levée ?
Cela vaut la peine si les investisseurs mènent une due diligence technique, ce qui est standard à partir de la Série A. Trouver les problèmes vous-même coûte bien moins cher que de les laisser découvrir par l'autre partie en pleine négociation.
Faut-il systématiquement un test de charge ?
Seulement pour une question de capacité importante restée ouverte, avec un périmètre convenu. La télémétrie existante peut répondre à certaines questions.
Inquiet de ce qui casse à 10× ?
Nous cartographions les plafonds, chiffrons les correctifs et les séquençons — généralement en moins de trois semaines.
Pour aller plus loin
Dette technique en startup : à partir de quand est-ce trop ?
Toute startup a de la dette technique, et l'essentiel était le bon choix. La question n'est pas comment l'éliminer — c'est quelles parties facturent des intérêts que vous ne pouvez plus payer.
Audit technique de MVP : ce que nous vérifions dans les 48 premières heures
La plupart des audits de MVP produisent un document. Un audit utile produit des décisions : ce qui brûle, ce qui peut attendre, et ce que coûte la correction.