Depuis quelques années, je vois passer le même conseil : "Une bonne architecture doit rester simple et adaptée au contexte. Un vrai dev ne fait pas d’over-engineering."

Puis : "Pas besoin de microservices, CQRS, Event Sourcing..."

Déjà, mettre microservices, CQRS et ES dans le même sac, c’est comparer l’urbanisme, la circulation et les archives d’une ville : même système, problèmes différents.

Mais surtout : sur quoi vous basez-vous pour déterminer le "bon niveau d’architecture" ? Sur ce que le client vous a raconté au premier atelier de 10mn ?

Un client décrit ce qu’il croit vouloir aujourd’hui, rarement ce que son logiciel devra absorber demain.

Sur mes 3 derniers projets :

• "Il nous faut juste une calculatrice" est devenu un système de pilotage des achats pour 30 M€.
• "Un Excel amélioré" est devenu un outil gérant charges, machines, compétences et turnover.
• "Le planning sera très simple" est devenu une application multisite avec des problèmes de connexion.

Si j’avais dimensionné l’architecture sur le discours initial, j’aurais fait quelque chose de "simple". Tellement simple qu’il aurait fallu tout réécrire quelques mois plus tard. 🤦‍♂️

Une partie du problème vient du web : on appelle "application" une page avec trois formulaires et une base derrière. Pour un site plaquette, pas besoin de sortir l’artillerie lourde. Mais une vraie application de gestion utilisée par des 10ene ou 100ene de personnes, c’est autre chose : les règles bougent et les exceptions deviennent la norme.

Je vais bientôt avoir 30 ans d’expérience dans la tech : 5 ans dans l’infra, 15 ans sur des logiciels de gestion traditionnels, bientôt 10 ans en CQRS/ES. J’ai eu le temps de voir ce qui tient dans la durée et ce qui casse à la prochaine demande métier.

Le coût d’une architecture ne se mesure pas au nombre de classes créées au démarrage, mais au prix du changement 6 mois, 3 ans ou 10 ans plus tard.

Une architecture trop simpliste produit souvent un effet cocasse : comme le logiciel supporte mal le changement, on essaie d’empêcher le client de changer d’avis. On contractualise, on fige, on ressort le fameux "Mais vous aviez dit que...".

C’est pratique : au lieu de rendre le logiciel adaptable, on essaie de rendre le client immuable.

Et non, CQRS/ES ne servent pas uniquement à l’audit ou à la traçabilité. On peut aussi les choisir parce qu’on accepte une évidence : on ne sait pas encore ce que le métier nous demandera demain.

Bref, considérer qu'une architecture ambitieuse est forcément de l’over-engineering parce que le besoin semble simple aujourd’hui, c’est juste remplacer un dogme par un autre.

C’est comme partir à la guerre sans arme en disant : "YAGNI. On fabriquera les fusils quand quelqu’un commencera à tirer. 🤓 "

Une bonne architecture n’a pas pour but de prédire l’avenir. Elle doit faire en sorte que, lorsqu’il vous donne tort, vous ne soyez pas obligé de tout réécrire.

La simplicité, oui. Le simplisme déguisé en expertise, beaucoup moins.