Simplicité opérationnelle vs richesse fonctionnelle: arbitrage d'architecte

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

Ce n'est pas la beauté de l'architecture cible. C'est la fatigue opérationnelle.

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.