Après plusieurs années passées dans des programmes de transformation numérique, j'ai fini par remarquer un phénomène étrange.
Lorsque les projets prennent du retard, lorsque plusieurs équipes peinent à collaborer ou lorsqu'une organisation semble incapable de faire évoluer rapidement son système d'information, notre premier réflexe consiste presque toujours à regarder l'organisation.
Faut-il revoir les rôles ? Créer de nouvelles équipes ? Modifier la gouvernance ? Adopter un nouveau framework ? Recruter davantage de chefs de projet ? Ajouter un Scrum Master ?
La question est légitime.
Mais elle m'a souvent laissé une impression de déjà-vu.
Car dans un nombre surprenant de situations, le problème n'était pas organisationnel. Il était logiciel. Plus précisément, il était lié à la difficulté croissante de faire évoluer le système existant.
Cette observation m'a amené à relire un principe du Manifeste Agile que l'on cite rarement aujourd'hui :
« Une attention continue à l'excellence technique et à la qualité de conception améliore l'agilité. »
Vingt-cinq ans plus tard, ce principe est probablement l'un des plus négligés du manifeste. Et pourtant, il touche directement à l'un des sujets qui préoccupent le plus les CTO, les directeurs IT et les responsables de transformation : la capacité d'exécution de leur organisation.
Pourquoi avons-nous oublié ce principe ?
Si ce principe est si important, pourquoi est-il devenu si discret ?
Probablement parce que les transformations organisationnelles sont visibles alors que l'amélioration de l'ingénierie l'est beaucoup moins.
Une nouvelle organisation se voit immédiatement. Une nouvelle gouvernance se voit immédiatement. Un nouveau framework se voit immédiatement. Une nouvelle répartition des responsabilités se voit immédiatement.
À l'inverse, l'amélioration progressive de la qualité d'un système est beaucoup plus discrète. Elle demande du temps, de la discipline et produit rarement des résultats spectaculaires en quelques semaines.
Pourtant, c'est précisément cette amélioration continue qui détermine la capacité d'exécution à long terme.
- Au fil des années, nous avons beaucoup parlé de transformation des organisations. Peut-être n'avons-nous pas suffisamment parlé de transformation des systèmes.
Le grand malentendu de l'agilité
Au fil des années, l'agilité a souvent été réduite à une question de vitesse.
Comment livrer plus rapidement ? Comment raccourcir les cycles ? Comment augmenter le débit des équipes ?
Pourtant, la vitesse n'est qu'une conséquence.
L'agilité est avant tout la capacité d'une organisation à s'adapter lorsque son environnement change. Un nouveau besoin client, une évolution réglementaire, une opportunité de marché ou une décision stratégique impliquent tous une modification du système d'information.
La véritable question n'est donc pas de savoir si l'organisation est agile en théorie. La véritable question est de savoir combien lui coûte le changement.
Lorsqu'une évolution relativement simple nécessite plusieurs mois de travail, mobilise plusieurs équipes et génère un risque important, le problème n'est pas toujours lié à la gouvernance ou aux processus. Il est souvent lié au logiciel lui-même.
- Cette distinction explique pourquoi certaines organisations multiplient les transformations sans parvenir à améliorer durablement leur capacité d'exécution. Elles traitent un problème d'ingénierie comme un problème d'organisation.
Une conversation que j'entends régulièrement
Lorsque j'échange avec des CTO, des managers ou des responsables de transformation, j'aborde souvent un sujet qui me semble pourtant fondamental : les développeurs doivent continuellement progresser dans leur maîtrise de l'ingénierie logicielle.
Conception. Tests automatisés. Architecture. Gestion de la dette technique. Compréhension des mécanismes de découplage.
La réponse est souvent la même :
« Si tous les développeurs deviennent bons sur ces sujets, vous voulez donc que tout le monde devienne Tech Lead ? »
Cette remarque mérite qu'on s'y attarde parce qu'elle n'est pas absurde.
Les dirigeants technologiques évoluent dans un environnement où les contraintes sont réelles : budgets limités, pression des métiers, délais déjà engagés, difficultés de recrutement et exigences de rentabilité.
Dans ce contexte, concentrer l'expertise sur quelques profils seniors semble être une décision rationnelle. Pourquoi investir massivement dans la montée en compétence de toute une organisation lorsqu'il paraît plus économique de s'appuyer sur quelques experts capables de guider les autres ?
Le raisonnement paraît solide.
Mais il repose sur une hypothèse rarement formulée : le développement logiciel fonctionnerait comme une chaîne de production.
Et c'est précisément là que le raisonnement commence à se fissurer.
Le développeur n'exécute pas, il conçoit
Dans une usine, il est effectivement possible de séparer largement la conception de l'exécution. Une fois le processus défini, chaque opérateur reproduit un ensemble d'actions relativement stable.
Le logiciel fonctionne différemment.
Chaque nouvelle fonctionnalité apporte son lot d'incertitudes. Chaque évolution modifie potentiellement l'équilibre du système. Chaque développeur est donc amené à prendre des décisions de conception, qu'il en soit conscient ou non.
- Où placer une règle métier ?
- Comment structurer une fonctionnalité ?
- Comment gérer une dépendance ?
- Comment éviter qu'une modification n'en casse plusieurs autres ?
- Comment rendre le système plus simple à faire évoluer demain ?
Ces décisions sont prises quotidiennement, directement dans le code.
La question n'est donc pas de savoir si les développeurs font de la conception. Ils en font tous les jours. La véritable question est de savoir s'ils disposent des compétences nécessaires pour prendre de bonnes décisions.
- Lorsque l'organisation considère que la conception est réservée aux architectes et aux Tech Leads, elle demande à ses développeurs de construire un système évolutif tout en considérant que les compétences permettant de le rendre évolutif relèvent d'une minorité.
Le faux raisonnement économique
À première vue, limiter l'expertise à quelques personnes semble pourtant être une bonne décision de gestion.
Former l'ensemble des développeurs coûte de l'argent. Accompagner leur progression prend du temps. Investir dans les tests automatisés, l'amélioration continue du design ou la réduction de la dette technique ne produit pas toujours des résultats visibles à court terme.
Le problème est que cette approche mesure principalement les coûts visibles. Pas les coûts cachés.
Or la dette technique est précisément un coût caché.
- McKinsey estimait qu'environ 40 % du patrimoine technologique de nombreuses grandes organisations pouvait être assimilé à de la dette technique.
- Stripe rapportait que les développeurs perdaient en moyenne plus de 17 heures par semaine à gérer des inefficacités liées à leur environnement technique.
Ces chiffres révèlent une réalité souvent ignorée : le coût de la mauvaise qualité existe déjà. L'entreprise le paie quotidiennement sous forme de délais supplémentaires, d'incidents de production, de dépendances entre équipes et d'opportunités de marché manquées.
- Simplement, ces coûts n'apparaissent jamais dans une ligne budgétaire intitulée « dette technique ».
L'illusion de la vitesse
C'est probablement l'un des pièges les plus fréquents dans les programmes de transformation.
Sous pression, les organisations arbitrent systématiquement en faveur du court terme. Elles réduisent le temps consacré aux tests, à la simplification du système ou à la qualité de conception afin d'accélérer la livraison.
À court terme, les résultats semblent positifs. Les fonctionnalités arrivent plus vite, la roadmap avance et les indicateurs paraissent meilleurs.
Puis la complexité s'accumule.
Chaque évolution devient un peu plus difficile que la précédente. Chaque projet coûte un peu plus cher. Chaque dépendance ralentit davantage l'organisation.
- Ce qui ressemblait à un gain de vitesse se transforme progressivement en perte de capacité d'exécution. Beaucoup d'entreprises pensent avoir un problème d'organisation alors qu'elles ont simplement un logiciel devenu trop coûteux à faire évoluer.
Le réflexe de coordination
Lorsqu'un projet commence à accumuler du retard, les organisations réagissent rarement en se demandant si elles ont un problème d'ingénierie.
Le réflexe est généralement organisationnel.
On ajoute du suivi. On crée de nouveaux indicateurs. On multiplie les réunions de synchronisation. On recrute un chef de projet supplémentaire.
Dans les organisations agiles, la réponse prend souvent une autre forme :
« Nous avons besoin d'un Scrum Master. »
L'hypothèse implicite est que le problème provient de la communication, des interactions entre équipes ou de l'organisation du travail. Bien entendu, ces problèmes existent. Mais ils ne sont pas toujours la cause principale.
Dans de nombreuses situations, les équipes savent parfaitement ce qu'elles doivent construire. Les objectifs sont clairs. Les responsabilités sont identifiées. Le véritable problème est que le système est devenu difficile à faire évoluer.
- Chaque changement demande davantage d'efforts que prévu.
- Les tests sont fragiles.
- Les dépendances sont nombreuses.
- L'architecture résiste au changement.
- Ajouter davantage de coordination ne résout pas le problème fondamental. Cela revient parfois à mieux organiser un embouteillage.
Cette idée a été brillamment illustrée par Emily Bache dans sa conférence « I Don't Need Another Scrum Master, Get Me a Technical Coach! » présentée à GOTO 2024. Son constat est simple : lorsque les difficultés proviennent principalement de la capacité technique des équipes à faire évoluer leur système, renforcer uniquement l'organisation du travail produit peu d'effet. Les gains les plus significatifs apparaissent souvent lorsque les équipes développent leurs compétences en conception, en tests automatisés, en refactoring et en ingénierie logicielle.
- Certaines organisations recrutent des coordinateurs pour résoudre des problèmes qui nécessitent avant tout davantage d'expertise technique.
Ce que montrent les organisations les plus performantes
Cette idée n'est pas une opinion. Elle apparaît de manière récurrente dans les travaux les plus sérieux réalisés sur la performance des organisations logicielles.
Les recherches DORA, popularisées notamment par Accelerate, ont étudié pendant plusieurs années des milliers d'équipes de développement. L'un des résultats les plus frappants :
Le chiffre est spectaculaire. Mais l'enseignement est ailleurs.
Il suggère que vitesse et qualité ne sont pas opposées. Elles se renforcent mutuellement.
- Les équipes les plus rapides ne sont pas celles qui investissent moins dans la qualité. Ce sont celles qui investissent le plus dans la réduction du coût du changement : tests automatisés, intégration continue, architecture évolutive, qualité de conception et réduction des dépendances.
Continuous Delivery apporte le même constat : la capacité à livrer fréquemment n'est pas d'abord un problème d'outillage. C'est un problème d'ingénierie.
Team Topologies apporte un éclairage complémentaire. Lorsqu'il explique comment construire des équipes autonomes, le sujet n'est pas uniquement organisationnel. Une équipe ne peut être autonome que si le système qu'elle manipule reste compréhensible. Sinon, chaque décision importante finit par remonter vers quelques experts. L'organisation paraît alors décentralisée. La prise de décision, elle, reste centralisée.
- Toutes ces approches convergent vers une idée simple : l'excellence technique n'est pas un luxe réservé aux ingénieurs. Elle constitue l'un des principaux leviers permettant à une organisation de conserver sa capacité d'exécution.
Par où commencer ?
Pour les organisations engagées dans une transformation numérique, la question n'est pas de transformer tous les développeurs en architectes.
La question est de savoir si l'organisation dispose du niveau d'expertise collectif nécessaire pour faire évoluer son système d'information au rythme de ses ambitions.
Quelques questions simples permettent souvent d'obtenir un premier diagnostic :
- Combien de personnes peuvent réellement modifier les applications stratégiques sans dépendre systématiquement de quelques experts ?
- Combien de temps faut-il pour mettre en production une évolution simple ?
- Quelle part du temps des équipes est consacrée à créer de la valeur plutôt qu'à gérer la complexité existante ?
- Quel investissement est consacré à la montée en compétence technique des équipes ?
- Les réponses à ces questions sont souvent plus révélatrices que n'importe quel indicateur de vélocité.
Conclusion
Pendant vingt ans, nous avons énormément investi dans la transformation des organisations. Nous avons redéfini les rôles, les structures, les processus et les modes de gouvernance. Ces évolutions étaient nécessaires.
Mais elles ont parfois occulté une réalité plus simple : une organisation ne peut pas s'adapter plus vite que le logiciel sur lequel elle repose.
Tant que ce logiciel reste facile à comprendre, à modifier et à faire évoluer, l'entreprise conserve sa capacité d'exécution. Lorsqu'il devient trop complexe, chaque initiative stratégique devient plus coûteuse, plus lente et plus risquée.
- C'est peut-être la raison pour laquelle le principe le plus oublié du Manifeste Agile est aussi l'un des plus importants. Car l'excellence technique n'est pas seulement une affaire d'ingénieurs. Elle détermine, en grande partie, la capacité d'une organisation à transformer ses ambitions en réalité.