Les décisions d'architecture ne sont pas de simples choix techniques. Ce sont des paris — sur la façon dont votre organisation va croître, comment votre équipe va s'étendre, et quels problèmes seront les plus importants dans deux, trois, cinq ans. La plupart de ces paris sont faits implicitement, sous pression des délais, sans que personne ne les nomme comme les décisions conséquentes qu'elles sont.
Pourquoi l'architecture a des conséquences disproportionnées
La plupart des décisions d'ingénierie sont réversibles. Vous pouvez refactoriser une fonction, changer une bibliothèque, réécrire un module. Les décisions d'architecture sont différentes car elles créent des contraintes structurelles à l'intérieur desquelles chaque décision ultérieure est prise. Choisir une structure monolithique tôt, par exemple, n'affecte pas seulement votre déploiement — cela façonne l'organisation de vos équipes, vos cycles de livraison, et les problèmes que vous pouvez résoudre sans un effort de restructuration de plusieurs mois.
“La loi de Conway n'est pas une suggestion. Votre architecture reflétera votre structure de communication, que vous le souhaitiez ou non. La seule question est de savoir si vous avez conçu cette structure délibérément.”
La décision que la plupart des équipes prennent mal
La décision architecturale la plus conséquente pour la plupart des organisations n'est pas microservices versus monolithe, ni SQL versus NoSQL. C'est là où tracer les frontières entre les domaines. Les frontières de domaine déterminent l'autonomie des équipes, la propriété des données, les contrats d'API et l'indépendance de déploiement.
Le test de l'horizon à cinq ans
Lors de l'évaluation d'une décision architecturale, nous demandons : si cette entreprise exécute bien et croît comme prévu, à quoi ressemble cette décision dans cinq ans ? L'architecture s'adapte-t-elle à la croissance, ou devient-elle le goulot d'étranglement ? Permet-elle à l'équipe de se réduire ou de se réorganiser si nécessaire ? Préserve-t-elle les options, ou vous enferme-t-elle dans un ensemble spécifique de fournisseurs, de patterns ou de modèles de déploiement ?
- Documentez la décision sous forme d'Architecture Decision Record (ADR) — ce qui a été décidé, les alternatives envisagées, et le contexte qui a rendu ce choix correct à ce moment.
- Identifiez les hypothèses dont dépend la décision. Que devrait-il changer pour que cette décision soit fausse ?
- Définissez un déclencheur de révision. Les décisions d'architecture doivent être revisitées quand l'échelle change d'un ordre de grandeur, quand la structure de l'équipe change significativement, ou quand le modèle commercial évolue.