Pourquoi les projets échouent encore : ce que la controverse Agile révèle sur le véritable goulot d’étranglement de la livraison des infrastructures numériques

Pourquoi les projets échouent encore : ce que la controverse sur Agile révèle des véritables goulots d’étranglement de la livraison des infrastructures numériques

À l’heure où les investissements dans les infrastructures et le numérique ne cessent d’augmenter, l’échec des projets n’a rien d’inhabituel. Un signal particulièrement révélateur est le suivant : même lorsque les entreprises investissent dans des cadres de delivery, des plans de transformation, des formations méthodologiques et des plateformes d’outillage, les projets IT continuent souvent à ne pas atteindre les résultats attendus. La discussion citée par iTnews ramène cette question à une réalité plus profonde : le problème n’est pas toujours la technologie elle-même, mais le système d’exécution.

Cela peut ressembler à une querelle interne au secteur du logiciel, mais sa portée dépasse largement l’IT d’entreprise. La numérisation des ports, les systèmes de dispatching énergétique, les plateformes de billetterie ferroviaire, la migration vers le cloud des services publics, la construction de centres de données, ainsi que les plateformes interservices d’administration, ressemblent de plus en plus à de grands projets d’infrastructure : ils reposent eux aussi sur une coordination complexe, une exploitation à long terme, la gestion des risques et les capacités organisationnelles. La réussite d’un projet dépend souvent de la structure de gouvernance, de la chaîne de compétences et de la discipline de mise en œuvre, et pas seulement du fait d’« adopter telle méthode ».

La méthodologie n’est pas rare ; c’est la capacité de livraison qui l’est

Dans cette discussion, un jugement revient sans cesse : les principes d’Agile n’ont pas échoué ; ce qui a vraiment échoué, c’est la manière dont les organisations les ont traduits en capacité de livraison quotidienne. Autrement dit, le problème ne réside généralement pas dans le cadre, mais dans la façon dont ce cadre est exécuté, compris et maintenu dans la durée.

C’est particulièrement important dans le secteur des infrastructures. Qu’il s’agisse de construire un nouveau centre de données, de moderniser un système de dispatching du réseau électrique ou de déployer une plateforme numérique de transport ferroviaire interurbain, les équipes projet peuvent disposer de diagrammes de processus, de revues d’étape et de contrats fournisseurs parfaitement rodés ; mais si, en interne, l’organisation n’a pas une compréhension commune des objectifs, des responsabilités, des risques et des priorités, le projet dévie malgré tout de sa trajectoire.

Du point de vue du capital d’ingénierie, cela signifie que beaucoup d’échecs de projets ne sont pas dus à un « manque de méthode », mais au fait que :

• la direction et les équipes d’exécution n’ont pas la même définition des résultats attendus ;
• la certification, la formation et le développement des compétences sont insuffisants, ce qui empêche l’extension de la méthodologie ;
• les équipes « adoptent » formellement un cadre sans le convertir en orientation résultats ;
• il y a beaucoup d’actions de gestion de projet, mais les progrès réels, la valeur et les risques ne sont pas effectivement visibles.

Ce type de problème n’a rien d’inconnu dans les grandes infrastructures. Qu’il s’agisse d’un système d’automatisation portuaire, d’une plateforme de gestion des actifs électriques ou d’un projet de jumeau numérique à l’échelle d’une ville, sans frontières de gouvernance claires ni mécanismes de feedback continu, on voit apparaître le phénomène suivant : « le système est mis en service, mais l’exploitation ne s’est pas améliorée ».

« Faire de l’Agile » ne veut pas dire « devenir Agile »

L’une des distinctions les plus intéressantes du débat est la suivante : une équipe peut « faire de l’Agile » sans pour autant être réellement « Agile ». Cette distinction ne s’applique pas seulement au développement logiciel, mais à tout système d’infrastructure complexe.

« Faire », cela signifie souvent accomplir quelques actions visibles : réunions quotidiennes, rétrospectives, planification d’itération, tableaux de tâches, mises en production. Ces actions ne sont pas mauvaises en soi ; mais si elles ne sont pas reliées aux objectifs métier, à la valeur délivrée et au contrôle des risques, elles peuvent se réduire à de la forme.Dans les grands projets d’infrastructure, cette situation se manifeste souvent comme suit :

• le plan de projet reste centré sur la conformité documentaire plutôt que sur la capacité de livraison ;
• le fournisseur et le maître d’ouvrage restent synchronisés sur le calendrier, sans parvenir à un consensus sur les décisions clés ;
• l’équipe est très « agile » au niveau local, mais l’organisation demeure hautement rigide ;
• la direction pense que les processus sont en place, tout en négligeant l’accumulation des écarts dans l’exécution réelle.

C’est aussi pourquoi de plus en plus de projets d’infrastructure numérique mettent l’accent sur la « visibilité de bout en bout ». Sans visualisation des risques, de la valeur et des dépendances, les projets complexes peuvent très facilement avancer en apparence tout en perdant silencieusement le contrôle.

Un décalage au niveau de la direction est la cause amont la plus fréquente de l’échec d’un projet

L’une des conclusions les plus importantes de la discussion est que l’échec d’un projet trouve souvent son origine non pas à l’extrémité de l’équipe, mais au niveau de la direction.

De nombreuses organisations sont très proactives lorsqu’elles lancent une transformation : elles définissent une vision, approuvent un budget, introduisent une méthode, constituent une équipe. Mais une fois le projet entré en phase d’exécution, la direction se retire trop tôt, ou se concentre uniquement sur les jalons sans prêter attention aux véritables problèmes systémiques. Cela amène l’équipe à avancer sur des tâches complexes sans limites claires ni soutien continu.

Pour les investissements dans les infrastructures, ce phénomène constitue presque un terreau pour la multiplication des coûts. En effet, les grands projets sont par nature gourmands en capital, longs, avec de nombreux points d’interface et une chaîne d’approvisionnement complexe. Dès lors que la gouvernance amont échoue, les problèmes qui suivent ne peuvent souvent pas être résolus par des corrections locales ; ils se propagent en cascade à travers la structure contractuelle, la conception, la livraison, l’exploitation et le financement.

C’est pourquoi de nombreux projets d’infrastructure publique accordent de plus en plus d’importance à :

• la clarté de la structure de gouvernance du projet ;
• la traçabilité des responsabilités ;
• l’alignement de la performance sur la « valeur » plutôt que sur les « actions » ;
• l’identification précoce des risques ;
• l’existence d’une véritable collaboration entre le maître d’ouvrage, les entrepreneurs, les consultants et les équipes techniques.

Dans le domaine des infrastructures numériques, ce point est particulièrement évident. Qu’il s’agisse d’un cloud gouvernemental, d’une plateforme de ville intelligente ou d’une extension de centre de données, si la direction considère le projet comme un simple achat informatique plutôt que comme un actif d’exploitation de long terme, la probabilité d’échec augmente fortement.

L’IA n’est pas un remède ; c’est plutôt un amplificateur

Cette discussion a également abordé une question à la fois concrète et urgente : l’IA entre sur le terrain de la livraison, mais elle ne corrige pas nécessairement les défauts organisationnels ; elle peut au contraire les amplifier.

Du côté positif, l’IA peut effectivement réduire la charge administrative répétitive, par exemple en générant des brouillons de documents, en synthétisant les comptes rendus de réunion, ou en accélérant la préparation des user stories et des livrables. Cela a de la valeur dans tout environnement de collaboration à haute fréquence, en particulier dans les projets de transformation numérique où les effectifs sont sous tension et les tâches nombreuses.

Mais le problème est que l’IA ne remplace pas le jugement. Elle ne fait que libérer une partie du temps, donnant à l’humain l’occasion de prendre de meilleures décisions. Si l’organisation manque de capacités de gouvernance, si les frontières des données sont floues, ou si la conscience du risque est insuffisante, l’IA ne produira pas un succès automatique ; elle fera simplement remonter les problèmes plus vite sur le devant de la scène.

• C’est aussi le point le plus préoccupant à l’ère des infrastructures numériques :- L’IA peut améliorer l’efficacité de la documentation et de la communication, mais elle ne peut pas remplacer la prise de décision dans les projets ;
• L’IA peut aider à synthétiser l’information, mais elle ne peut pas garantir que l’information elle-même soit complète ;
• L’IA peut accélérer la livraison, mais elle ne peut pas corriger une structure organisationnelle déformée ;
• L’IA peut raccourcir certains processus, mais elle amplifie les risques liés aux données causés par les lacunes de gouvernance.

Lorsque les entreprises intègrent l’IA dans la gestion de projet, les plateformes de service client, les systèmes d’exploitation et de maintenance ou les services numériques publics, les problèmes de gouvernance deviennent encore plus saillants. L’IA en elle-même n’est pas la cause de l’échec d’un projet, mais elle peut devenir un accélérateur des faiblesses existantes.

Enseignements pour l’investissement dans les infrastructures numériques : les capacités, la gouvernance et l’exploitation sont tout aussi importantes

Si l’on replace cette discussion dans une perspective d’infrastructure plus large, la conclusion est en réalité très claire : à l’avenir, la compétition dans les infrastructures numériques ne consistera plus seulement à savoir « qui passe d’abord au cloud », « qui adopte l’IA en premier » ou « qui lance la plateforme en premier », mais à déterminer qui est capable de livrer, d’exploiter et d’itérer de manière stable des systèmes complexes.

Cela est particulièrement important pour trois types d’investissements.

Premièrement, les centres de données et les infrastructures cloud. La valeur de ces actifs ne provient pas seulement des baies et de la capacité électrique, mais aussi des systèmes de livraison, d’exploitation et de gouvernance de la sécurité. Un contrôle défaillant pendant la phase de construction se transforme en coûts permanents au stade de l’exploitation.

Deuxièmement, la numérisation des transports et des services publics. Les transports ferroviaires, les ports, les aéroports et les services municipaux dépendent de plus en plus des plateformes de données et des systèmes d’automatisation. Si la gestion de projet ne parvient pas à assurer une coordination interservices, la numérisation ne fera qu’accroître la complexité, sans améliorer l’efficacité.

Troisièmement, les grands projets de transformation des gouvernements et des entreprises. Ce type de projets est le plus susceptible de produire un phénomène de « beaucoup de cadres, peu de résultats ». Plus la méthodologie est mature, plus l’organisation doit disposer d’une capacité d’apprentissage continu et d’exécution ; sinon, le système tournera à vide lors de la montée en échelle.

En ce sens, l’agilité n’est pas le problème en soi. Le véritable problème est de savoir si l’organisation dispose d’une structure capable de transformer les méthodologies en une capacité de livraison durable.

Conclusion : à l’ère des infrastructures, la réussite ou l’échec des projets dépend de l’ingénierie organisationnelle

Par le passé, on attribuait souvent l’échec des infrastructures à une mauvaise conception, à un manque de financement ou à des retards dans la chaîne d’approvisionnement. Aujourd’hui, avec les systèmes numériques devenus l’une des couches centrales des infrastructures, un nouveau mode d’échec est apparu : les projets ne manquent pas d’outils, ils manquent de capacités d’ingénierie organisationnelle.

Cela signifie que les acteurs des infrastructures réellement compétitifs de demain ne seront pas seulement ceux qui savent construire, acheter et intégrer, mais aussi ceux qui savent gouverner, apprendre et ajuster en continu. Qu’il s’agisse de centres de données, de plateformes énergétiques, de systèmes portuaires ou de fondations numériques urbaines, ce qui détermine le rendement à long terme n’est plus seulement l’ampleur des investissements en capital, mais la qualité du système d’exécution.

En d’autres termes, Agile n’« abîme » pas les projets ; ce qui les fait dévier encore et encore des attentes, c’est d’ignorer la coordination du leadership, le renforcement des capacités, la transparence de la gouvernance et la visibilité des risques.