Quand les gens métiers accusent les TI : un problème d’architecture ?
"Les TI nous bloquent."
C’est une phrase qu’on entend souvent dans les organisations. Elle revient dans les rencontres, dans les ateliers, parfois même autour de la machine à café. Elle exprime une frustration réelle des équipes métiers qui peinent à voir leurs besoins traduits rapidement en solutions concrètes.
Mais derrière ce reproche, que se passe-t-il vraiment ? Et si le véritable coupable était ailleurs ?
Robert C. Martin, dans Clean Architecture, nous propose un regard en profondeur : celui d’un architecte qui connaît les dessous du logiciel. Et ce qu’il montre est aussi troublant que familier.
Une histoire familière (et mesurabe)
Prenons un exemple classique :
Une entreprise connaît un grand succès avec son logiciel. Les clients affluent, les demandes s’accumulent. Pour suivre la cadence, on embauche plus de ressources : développeurs, analystes, .. etc. On veut livrer plus vite, et à tout prix.
Mais à mesure que l’équipe grandit… tout ralentit!
Les délais explosent.
La qualité se dégrade.
Les bugs se multiplient.
Les frustrations montent.
Et les dirigeants ne comprennent plus : Pourquoi plus de moyens donnent moins de résultats ?
Le constat tombe : malgré les ressources, le système ne suit pas.
Les deux graphiques ci-dessous racontent cette histoire en chiffres :
Évolution de l’équipe vs Taille du Produit
Productivité vs Taille du Produit
Malgré une croissance constante de l’équipe, la productivité chute à mesure que la taille du produit augmente. En effet, tout commence bien : à la première version, la productivité est au sommet. Mais à chaque release, le produit prend du poids… et la productivité s’effondre.
Ces graphiques illustrent une réalité discrète mais redoutable : la dette technique s’accumule en silence. À mesure que le code grossit, l’agilité disparaît.
Et parfois, ce n’est plus le code qu’on développe… mais la complexité qu’on subit.
Quand plus de monde n'aide plus
Comme Robert C. Martin le dit lui-même dans son livre Clean Architecture:
“There are systems that are practically impossible to change, because the cost of change exceeds the benefit of change.”
Imagine une vieille voiture des années 80, customisée pour suivre l’évolution du besoin.
Elle roule encore (plus ou moins), mais elle a été modifiée tellement de fois que :
Le moteur vient d’un autre modèle,
Elle a été modifiée pour fonctionner comme voiture sur terre… et comme bateau sur l’eau,
Le tableau de bord est bricolé avec des pièces d’ordinateur portable,
Et il faut taper sur la portière pour démarrer le chauffage.
Tu te dis : “Et si on la modernisait ?”
Mais là, tu réalises que changer une seule pièce nécessite de démonter trois autres.
Mettre un GPS ? Impossible sans refaire tout le circuit électrique.
Installer une clim ? Tu dois toucher au moteur.
Le coût du changement est astronomique.
Alors tu fais appel à des mécanos. Puis à d’autres. Puis encore plus.
Mais chaque intervention complexifie l’ensemble au lieu de l’améliorer.
Résultat : on avance moins vite.
Le problème n’est pas humain. Le problème, c’est l’architecture.
L’illusion d’échelle cache une réalité plus dure :
une architecture pensée pour un moment figé, pas pour le changement, pas pour l’incertitude, pas pour l’évolution du métier.
5 leçons à retenir de Clean Architecture
Pour éviter de transformer nos systèmes en monstres inchangeables, voici ce que Clean Architecture nous enseigne…
L’architecture, c’est la capacité de changer: trop souvent, elle est considérée comme un luxe ou une “affaire de développeurs”. Mais c’est un investissement stratégique. Une bonne architecture rend le changement simple, local, peu coûteux.
Le couplage tue la vitesse: quand un interface utilisateur est intimement liée à la logique d’affaire, elle-même dépendante de la base de données, chaque modification a des effets en cascade.
Les choix techniques deviennent des contraintes métiers: un framework imposé, une base de données trop ancrée, un modèle rigide : tout cela finit par freiner l’entreprise.
Une architecture vivante laisse les options ouvertes: Robert C. Martin insiste que le rôle de l’architecture est de retarder les décisions irréversibles pour rester adaptable le plus longtemps possible.
Ce n’est pas les TI qui bloquent, c’est souvent l’oubli de l’architecture: l’absence de réflexion sur la structure à long terme du système mène inévitablement à des blocages. Les TI ne sont que l’écho des choix accumulés.
Repenser la critique
La prochaine fois qu’on entend “les TI nous bloquent”, posons-nous une autre question : Notre architecture est-elle prête pour la vitesse, le changement, l’évolution continue que demande l’entreprise ?
Et si la réponse est non, alors ce n’est pas une question de TI.
C’est une invitation à reconstruire les fondations. Et ça commence souvent par de petites décisions bien pensées : isoler la logique affaire, clarifier les dépendances, revoir le cycle de vie des composants...
🙏 Merci pour votre lecture, et n’oubliez pas :
Une architecture solide, c’est la première condition pour que les données, et les idées, circulent librement.
Avertissement
Rédigé en dehors de tout cadre professionnel, cet article est une contribution personnelle à la réflexion collective sur l’architecture. Il reflète une réflexion personnelle basée sur des lectures et observations générales. Aucun lien ne doit être fait avec des projets ou entreprises spécifiques. Les opinions exprimées sont strictement personnelles.
Abonnez-vous à cette publication si ce n’est pas encore fait, et n’hésitez pas à réagir ou à me contacter sur LinkedIn — je serais ravi d’échanger sur vos expériences, vos défis ou vos réflexions autour de l’architecture et de la collaboration entre TI et lignes d’affaires.