Pourquoi vos développeurs vous disent que c'est compliqué à modifier
Un an après la mise en ligne, la moindre évolution coûte trois fois plus cher qu'au départ. Ce n'est pas de la mauvaise volonté : c'est une décision d'architecture prise le premier mois.
6 min de lecture
Vous avez fait développer un outil. Les six premiers mois, tout allait vite. Aujourd'hui, la moindre demande revient avec un devis qui vous surprend et un délai qui vous agace.
Ce qui s'est passé
La logique de votre métier — qui a le droit de faire quoi, comment se calcule une remise, quand part une relance — a été écrite à l'intérieur des écrans. Elle est éparpillée dans les boutons, les formulaires, les requêtes.
Tant qu'il y a dix écrans, ça tient. À trente, changer une règle oblige à la retrouver dans dix-sept endroits, et à en oublier deux.
Ce qu'on fait à la place
On isole les règles métier dans une couche qui ne connaît ni l'écran, ni la base de données. Elles s'écrivent une fois, se testent seules, et l'écran ne fait que les appeler.
Le bénéfice n'est pas visible à la livraison. Il l'est au dix-huitième mois, quand vous demandez une évolution et qu'elle coûte ce qu'elle devrait coûter.
Sujets abordés
- architecture
- dette technique
- clean architecture