J'ai vu ce scénario se répéter sur plusieurs projets. Une application démarre vite, les premières fonctionnalités sortent en quelques semaines, les clients sont satisfaits. Puis, progressivement, tout ralentit. Ajouter une nouvelle fonctionnalité prend trois fois plus longtemps qu'au début. Corriger un bug en crée deux autres. L'équipe passe plus de temps à comprendre le code existant qu'à en écrire du nouveau.
Ce n'est pas une question de compétence des développeurs. C'est une question d'architecture, ou plutôt d'absence d'architecture réfléchie dès le départ.
Sur le projet Alpha ERP, la première version tenait dans deux fichiers PHP et une dizaine de tables. Deux ans plus tard, sans refactoring architectural, ce type de base de code devient ingérable : chaque modification touche dix endroits, les tests sont impossibles à écrire, et personne ne comprend plus ce que fait une fonction sans la tracer pendant vingt minutes.
Ce qui se passe réellement pendant ces 2 ans
La dette technique s'accumule silencieusement. Chaque décision
prise sous pression —
// TODO: refactoriser plus tard, une logique métier
copiée-collée dans trois contrôleurs, une dépendance forte entre
deux modules qui ne devraient pas se connaître — s'ajoute aux
précédentes.
Le problème n'est pas le code lui-même. C'est que ces décisions créent des couplages invisibles. Modifier le module de facturation casse le module de rapport. Changer la structure d'un objet client oblige à modifier quinze fichiers. Le système devient fragile précisément parce qu'il a grandi sans structure.
Les trois symptômes qui apparaissent en premier
- Le temps d'onboarding explose. Un nouveau développeur met deux semaines à comprendre comment fonctionne le système au lieu de deux jours. La connaissance est enfouie dans le code, pas dans une structure lisible.
- Les estimations deviennent impossibles. Personne ne peut dire avec certitude combien de temps prendra une modification, parce que personne ne sait exactement ce qu'elle va toucher.
- Les bugs régressifs se multiplient. On corrige un problème ici, un autre apparaît ailleurs. Le système est trop couplé pour qu'une modification reste localisée.
Pourquoi l'architecture prévient ce problème
Une bonne architecture ne rend pas le code parfait. Elle rend le changement prévisible. C'est la seule chose qui compte sur le long terme.
La Clean Architecture de Robert C. Martin repose sur un principe simple : les dépendances ne pointent que dans une direction. La logique métier ne connaît pas la base de données. Les cas d'usage ne connaissent pas le framework HTTP. L'interface utilisateur ne connaît pas le domaine.
Une règle de dépendance claire signifie qu'on peut remplacer n'importe quelle couche technique sans toucher à la logique métier. Migrer de MySQL vers PostgreSQL ne devrait pas modifier un seul cas d'usage. Changer de framework web ne devrait pas toucher les entités du domaine.
Ce que ça change concrètement
| Sans architecture | Avec Clean Architecture |
|---|---|
| La logique métier est dans les contrôleurs | La logique métier est dans des cas d'usage isolés |
| Les tests nécessitent une base de données réelle | Les tests unitaires s'exécutent en mémoire |
| Changer de framework = réécriture partielle | Changer de framework = remplacer les adaptateurs |
| Un nouveau dev met 2 semaines à s'orienter | La structure du dossier reflète le domaine métier |
| Modifier une feature touche 10 fichiers | Modifier une feature touche 1 à 3 fichiers ciblés |
La dette technique n'est pas inévitable
Il existe un mythe tenace dans notre industrie : aller vite oblige à sacrifier la qualité. C'est faux. Ce qui oblige à sacrifier la qualité, c'est de ne pas savoir où placer la logique avant de commencer à coder.
Un projet bien architecturé au départ prend 10 à 20% de temps supplémentaire sur les premières semaines. Ce surcoût est récupéré dès le troisième mois, quand les modifications restent prévisibles, les bugs sont localisables en minutes, et les nouvelles fonctionnalités s'ajoutent sans crainte de tout casser.
Avant d'écrire la première ligne de code, je cartographie le domaine métier avec le client. Quels sont les concepts clés ? Quels sont les invariants qui ne changeront jamais ? Quelles sont les règles métier qui doivent être protégées ? Cette conversation prend deux heures et évite six mois de refactoring.
Par où commencer si votre application existe déjà
Si votre application est déjà en production et présente ces symptômes, la réécriture complète est rarement la bonne réponse. Elle est coûteuse, risquée, et reproduit souvent les mêmes erreurs dans un nouveau code.
L'approche pragmatique est le refactoring incrémental :
- Identifier les zones de douleur. Quels modules sont touchés par la majorité des bugs ? Quelles fonctionnalités prennent le plus longtemps à modifier ? Ce sont les candidats prioritaires.
- Écrire des tests de caractérisation. Avant de toucher à quoi que ce soit, documenter le comportement actuel par des tests. Pas pour valider que c'est correct, mais pour détecter si on casse quelque chose lors du refactoring.
- Extraire la logique métier progressivement. Sortir la logique des contrôleurs vers des services, puis vers des cas d'usage isolés. Un module à la fois, une feature à la fois.
- Ne jamais ajouter une nouvelle feature dans l'ancienne architecture. Toute nouvelle fonctionnalité suit la nouvelle structure. Progressivement, l'ancien code est remplacé sans réécriture massive.
Conclusion
L'architecture logicielle n'est pas un luxe réservé aux grands projets. C'est la décision la plus économique qu'on puisse prendre sur un projet qui doit durer plus de six mois.
La question n'est pas "est-ce qu'on a le temps de bien architecturer ?" mais "est-ce qu'on peut se permettre de ne pas le faire ?"
Si vous travaillez sur un projet qui présente ces symptômes — ou si vous démarrez un nouveau projet et voulez éviter de les rencontrer — je suis disponible pour un audit ou un accompagnement architectural.
Je propose des audits architecturaux et des sessions de conseil technique. On fait le point sur votre base de code et je vous donne un plan d'action concret.
Me contacter