Dans les ateliers d'architecture, la tentation est forte de comparer les plateformes à la liste de fonctionnalités. Sur le terrain, l'arbitrage est plus concret: quelle complexité l'équipe peut absorber sans dégrader la continuité.
Le signal à regarder en premier
Le facteur déterminant est souvent la fatigue opérationnelle, bien avant l'élégance de l'architecture cible.
Indices fréquents d'une plateforme devenue trop lourde:
- MTTR qui s'allonge,
- incidents post-change en hausse,
- dépendance à deux ou trois personnes clés,
- runbooks rarement fiables en situation réelle.
Quand ces signaux apparaissent, la "richesse" devient parfois une dette.
Ce qu'apporte la simplicité
Une architecture plus sobre réduit souvent:
- le temps de diagnostic,
- l'incertitude en astreinte,
- la variabilité entre sites,
- la charge cognitive en période de changement.
C'est moins visible qu'une nouvelle feature. Mais c'est ce qui protège la production.
Ce qu'on perd, et qu'il faut assumer
Simplifier implique aussi des renoncements:
- moins d'options natives,
- parfois plus de procédures autour,
- une trajectoire de transition plus progressive.
Un arbitrage mature n'ignore pas ces pertes. Il les nomme et les compense.
Position
Je préfère une plateforme un peu moins brillante sur le papier mais tenue proprement par l'équipe, à une plateforme "parfaite" qui devient fragile à la moindre tension.
L'architecture est un sujet technique. C'est aussi un sujet d'organisation, de gouvernance et d'humilité opérationnelle.