De nombreux projets informatiques échouent encore malgré les méthodologies modernes
Le monde de la technologie est passé d’un modèle en cascade à un modèle AgileLes équipes travaillent dans des cycles plus courts, livrant en quelques semaines au lieu de quelques mois. Les équipes travaillent dans des cycles plus courts, livrant en quelques semaines au lieu de quelques mois. Mais la réalité est là : un grand nombre de projets informatiques n’aboutissent toujours pas.
À quoi ressemble l’échec aujourd’hui ? Il ne s’agit pas de systèmes qui tombent en panne ou de matériel qui se casse. C’est plus subtil et plus coûteux : des projets qui ne génèrent pas le rendement escompté, des outils que les gens n’adoptent pas, des déploiements qui arrivent trop tard pour avoir de l’importance. Vous pouvez créer un code propre, mais si le résultat ne correspond pas à l’objectif de l’entreprise, c’est peine perdue.
Le rapport 2025 Pulse of the Profession du PMI indique qu’environ 20 % des projets d’entreprise n’atteignent pas les objectifs de l’entreprise. Cela représente un projet sur cinq. La situation est encore plus grave dans le domaine de l’IA : l’étude du MIT intitulée « The GenAI Divide : State of AI in Business 2025 » du MIT indique que 95 % des projets pilotes d’IA générative ne parviennent pas à générer des bénéfices financiers au cours des six premiers mois.
C’est clair : la vitesse et l’itération ne suffisent pas. Vous avez besoin d’impact. Vous avez besoin d’un alignement entre ce qui est construit et les besoins de l’entreprise. Sinon, vous ne ferez qu’accélérer vers le mauvais résultat.
Le manque d’expertise en matière de gestion de projet continue de nuire à l’exécution des projets
La gestion professionnelle des projets est fondamentale. Pourtant, trop souvent, les projets de petite et moyenne envergure sont confiés à des personnes qui n’ont ni la formation ni les outils nécessaires pour les gérer. Les entreprises chargent des analystes ou des chefs d’équipe de s’occuper de tâches essentielles sans leur donner la structure, la connaissance des processus ou le temps dont ils ont besoin pour bien faire les choses.
Il ne s’agit pas d’un problème de formation, mais d’un problème structurel. Les chefs de projet dotés d’une véritable expérience ne se contentent pas de gérer un calendrier. Ils prévoient les risques, alignent les ressources, font respecter la discipline au sein des équipes et protègent les calendriers contre les changements inutiles. Ils savent quand il faut être flexible et quand il faut être ferme. C’est à cela que ressemble la livraison à grande échelle.
Eric Bloom, directeur exécutif de l’IT Management and Leadership Institute, en souligne les conséquences : lorsque de petits projets sont menés par des non-spécialistes, le champ d’application s’élargit, les engagements dérivent et le contrôle disparaît. Et contrairement à ce que pensent de nombreuses organisations, les petits projets ne sont pas moins critiques, ils sont souvent interconnectés avec des systèmes et des objectifs plus vastes. S’ils échouent, ils créent des effets d’entraînement en amont.
Les dirigeants doivent se rendre à l’évidence : des chefs de projet bien formés augmentent les chances de succès. Le retour sur cette capacité est direct, mesurable et stratégiquement significatif. Si vous dépensez des millions pour le développement, dépenser proportionnellement pour la direction de projet n’est pas un luxe. C’est une nécessité.
L’inadéquation entre les initiatives informatiques et les objectifs de l’entreprise compromet la réussite.
Trop souvent, les entreprises lancent des initiatives technologiques sans avoir une destination précise à l’esprit. Un nouvel outil ou une nouvelle tendance attire l’attention et les dirigeants se disent : « Faisons quelque chose avec ça ». Résultat ? Des projets motivés par l’enthousiasme et non par la stratégie. C’est le chemin direct vers la perte de temps et les attentes non satisfaites.
La bonne méthode : commencez par un objectif commercial. Identifiez un problème qui mérite d’être résolu. Définissez ensuite ce que signifie la réussite, sur le plan financier, opérationnel ou autre, et choisissez ensuite la technologie. Cela semble élémentaire, mais selon les experts, ce n’est pas encore assez souvent le cas.
Kathleen Walch, directrice de l’engagement et de la communauté IA au Project Management Institute, affirme que les organisations adoptent encore des outils avant de définir le besoin qu’ils résolvent. Cela est visible dans les déploiements d’IA, où les projets sont lancés sans stratégie précise, ce qui conduit à des résultats qui ne font pas évoluer les indicateurs de l’entreprise.
Thomas Phelps IV, DSI de Laserfiche et membre du conseil d’administration de l’Institut de recherche SIM, insiste sur un point essentiel : les entreprises doivent considérer l’analyse de rentabilité comme un document vivant. En le réexaminant régulièrement, et pas seulement après la mise en service, on s’assure que le projet continue à s’adapter à l’évolution du paysage. Les marchés changent, les objectifs s’adaptent. Votre projet doit l’être aussi.
Les dirigeants doivent faire preuve de discipline dans ce domaine. Si un projet ne peut pas se référer à un résultat commercial ou n’a pas de mesure claire liée aux résultats, soit il n’est pas prêt, soit il ne devrait pas être mis en œuvre.
L’absence d’une appropriation claire par l’entreprise diminue la responsabilité du projet
La réussite des projets technologiques n’est pas l’apanage des seuls informaticiens. Lorsque personne du côté de l’entreprise ne s’approprie réellement le projet, la responsabilité disparaît. C’est un problème majeur.
Les projets qui ne sont pas menés par un chef d’entreprise ne parviennent souvent pas à s’intégrer dans les opérations. Les ressources ne sont pas engagées au moment voulu. Les changements de processus ne se produisent pas dans les délais prévus. Et lorsque le système est opérationnel, les équipes ne l’adoptent pas, non pas parce que la technologie ne fonctionne pas, mais parce que l’entreprise n’était pas prête à fonctionner différemment.
Eric Stettler, associé dans la pratique de la transformation technologique chez Kearney, l’a dit clairement : les projets d’entreprise menés uniquement par les DSI deviennent un scénario où l’on se fait tirer l’oreille. La fonction informatique peut permettre la mise en œuvre d’un processus, mais il ne faut pas lui demander de concevoir et d’appliquer l’exécution opérationnelle dans l’ensemble de l’entreprise.
Ce rôle revient à un leader clair du côté de l’entreprise, quelqu’un qui est responsable du début à la fin. Il doit s’approprier le problème, contrôler le budget et avoir l’autorité nécessaire pour prendre les décisions qui ont un impact sur sa partie de l’organisation.
Pour les cadres, cette évolution implique de poser une question élémentaire mais essentielle au début de tout projet : qui est responsable de ce projet du point de vue de l’entreprise ? Si cette personne n’existe pas ou n’est pas impliquée, le risque d’échec augmente fortement.
Un engagement insuffisant de la part du sponsor conduit à une surveillance et à une mauvaise orientation.
Les sponsors commerciaux sont souvent identifiés au début d’un projet, mais ils sont trop nombreux à prendre du recul une fois que l’exécution a commencé. Ils assistent à des mises à jour occasionnelles de l’état d’avancement, jettent un coup d’œil aux tableaux de bord et passent à autre chose. Ce n’est pas de l’engagement, c’est de l’observation. Et cela expose les projets.
Les sponsors qui ne s’engagent pas activement manquent les premiers signaux d’alerte. Ils n’établissent pas de relations directes avec les équipes de projet. Lorsque les équipes hésitent à faire remonter les problèmes en raison d’un manque de confiance ou d’accessibilité, les petits problèmes deviennent des obstacles coûteux. Les décisions critiques sont retardées. Les corrections de trajectoire ne se font pas à temps.
Eric Stettler, associé chez Kearney, souligne que l’implication limitée du sponsor conduit à des occasions manquées d’exercer une influence au moment le plus important. Les sponsors ne doivent pas se contenter de regarder les indicateurs d’état verts, ils doivent être suffisamment sur le terrain pour remettre en question les hypothèses, valider les progrès et soutenir l’équipe lorsqu’elle se heurte à des résistances.
Cela ne signifie pas qu’il faille faire de la microgestion. Il s’agit d’être stratégiquement attentif. Un parrain exécutif crédible doit effectuer des contrôles ponctuels, examiner directement les mises à jour et s’assurer qu’elles aident et ne se contentent pas de rendre compte. Lorsque les équipes considèrent le sponsor comme un partenaire actif plutôt que comme une figure de proue, la transparence augmente et les problèmes apparaissent plus rapidement.
Les dirigeants doivent redéfinir la norme en la matière. Le parrainage n’est pas symbolique. Il est opérationnel. Si un projet revêt une importance stratégique, le sponsor doit passer du temps à s’assurer de sa réussite.
Une implication insuffisante des parties prenantes se traduit par des exigences non satisfaites et une adoption réduite.
L’exclusion des parties prenantes clés au cours des phases de planification et d’exécution provoque plus que des frictions, elle conduit à l’échec. Des unités opérationnelles entières peuvent être prises au dépourvu, non pas parce qu’elles ont résisté au changement, mais parce qu’elles n’ont jamais été associées à la conversation.
Lorsque les parties prenantes ne sont pas consultées à un stade précoce, les équipes de projet passent à côté d’exigences commerciales importantes, ignorent les besoins réglementaires ou négligent la manière dont les utilisateurs quotidiens interagiront avec la solution. Il en résulte un projet qui, bien que techniquement achevé, ne reflète pas les activités réelles de l’entreprise. L’adoption chute. La résistance s’accroît.
Krista Phillips, PMP et présidente de la section régionale Pikes Peak du PMI, a partagé un exemple clair : une multinationale a oublié une division entière lors du déploiement d’une plateforme majeure. Cette unité n’avait aucune idée du changement à venir, ce qui a entraîné une certaine confusion, un manque d’adoption et un projet dont la portée a dû être ajustée rétroactivement.
Cela peut être évité. La cartographie des parties prenantes n’est pas facultative. Elle doit être complète et validée par tous les services, en particulier dans les organisations complexes ou mondiales. Toutes les équipes concernées doivent être représentées dès le début du développement et de manière continue.
Pour les cadres, la conclusion est directe : ne présumez pas de l’alignement. Confirmez-le. Poussez les chefs de projet à valider qui est à la table dès le premier jour. Confirmez que les acteurs opérationnels, et pas seulement les cadres supérieurs, sont impliqués. Cela permet de clarifier les choses, de réduire les retouches et d’augmenter la probabilité d’une adoption réelle lorsque le commutateur bascule.
Une planification inadéquate des ressources et des équipes inexpérimentées sont à l’origine de l’échec des projets.
La plupart des dirigeants du secteur technologique sous-estiment ce qu’il faut vraiment faire pour obtenir des résultats. Non pas en termes d’ambition, mais en termes de ressources. Nombre d’entre eux pensent qu’ils pourront augmenter leur expertise plus tard ou emprunter des talents en cours de route lorsque la complexité augmentera. Ce n’est pas ainsi que fonctionne l’exécution.
Une planification précise des ressources doit intervenir tôt, avant les approbations, avant le coup d’envoi. Vous devez disposer d’estimations claires sur le temps, la spécialisation, la disponibilité et le coût. Plus important encore, les personnes affectées doivent rester engagées du début à la fin. L’élan du projet est brisé lorsque des collaborateurs clés sont retirés en cours de projet pour résoudre des problèmes sans rapport avec le projet.
Thomas Phelps IV, directeur informatique chez Laserfiche, a observé que de nombreux échecs sont imputables à des chefs de projet qui possèdent des certifications mais n’ont pas d’expérience réelle de la mise en œuvre. Des détails leur échappent, comme le fait que les retards se traduisent directement par des dépassements de budget, en particulier lorsque des équipes de consultants ou des fournisseurs sont impliqués.
Eric Stettler, associé chez Kearney, a ajouté un point critique : la plupart des organisations s’attendent à pouvoir « brancher » des talents expérimentés si les choses tournent mal. En pratique, ces talents ne sont généralement pas disponibles. Les entrepreneurs qualifiés et les experts internes sont réservés des mois à l’avance. Les attendre tue la vélocité au moment où on en a le plus besoin.
Sanjeev Vohra, directeur de la technologie et de l’innovation chez Genpact, a souligné que l’estimation des besoins en ressources devient encore plus difficile avec l’IA et les technologies émergentes. Les compétences disponibles sont rares. Sans précision dans la portée et l’embauche, il est facile de surpromettre et de ne pas tenir ses promesses.
Pour les cadres, il s’agit d’une discipline de planification. N’approuvez pas un projet sans avoir vu l’ensemble du modèle de dotation. Au-delà des titres, validez les capacités, la disponibilité et l’historique des livraisons. L’investissement initial vaut la peine d’éviter les pannes ultérieures.
Négliger la gestion du changement limite l’adoption et réduit la valeur du projet
La mise en œuvre de la technologie n’est que la surface. Aujourd’hui, la plupart des projets échouent non pas parce que le logiciel est défectueux, mais parce que les gens ne changent pas leur façon de travailler. Il s’agit là d’un problème de leadership, et non de plateforme.
La gestion du changement ne se limite pas à la communication. Il s’agit d’un ensemble structuré d’activités qui alignent les personnes, les incitations et les flux de travail pour fonctionner différemment. Cela inclut la formation, les boucles de retour d’information, l’aide à la transition et une justification visible de l’importance du changement. Lorsque le changement est précipité ou effectué tardivement, les gens reviennent à leurs vieilles habitudes. L’adoption stagne.
Nick Kramer, directeur des solutions appliquées chez SSA & Co, a vu plus d’échecs liés à une mauvaise gestion du changement qu’à une mauvaise technologie. Il souligne que les projets ont besoin d’une personne qui se concentre sur l’exécution et la transformation, et pas seulement sur le déploiement. Les agents du changement comprennent les schémas de résistance. Ils identifient les obstacles et les éliminent par des actions pratiques, et non par l’espoir.
Trop de dirigeants considèrent cette fonction comme des frais généraux. Ce n’est pas le cas. Sans accompagnement du changement, même les systèmes bien conçus ne produisent pas le retour sur investissement escompté.
Si vous financez un projet, financez l’équipe chargée du changement. Attendez-vous à une stratégie de transition pour les employés, et pas seulement pour les changements de technologies de l’information. Faites en sorte que quelqu’un soit responsable des résultats au-delà de la mise en service. C’est ainsi que la valeur se concrétise, et pas seulement qu’elle se construit.
Dernières réflexions
L’échec dans l’informatique n’est plus un problème de technologie, c’est un problème de leadership. Les outils fonctionnent. Le code fonctionne. Ce qui se brise, ce sont les fondamentaux : une appropriation claire, un alignement stratégique, une supervision forte et la capacité de mener les gens à travers le changement.
Vous n’avez pas besoin de plus de cadres ou de couches de processus. Vous avez besoin de responsabilité là où c’est important. Attribuez de véritables responsables d’entreprise. Financez des chefs de projet expérimentés. Impliquez chaque partie prenante dès le début. Et ne vous contentez pas de déployer la technologie, gérez le changement qui l’accompagne.
Si vous approuvez des projets de plusieurs millions de dollars, assurez-vous qu’ils sont liés à des résultats commerciaux spécifiques. Assurez-vous que les bonnes personnes les pilotent. Et assurez-vous d’être prêt à intervenir lorsque c’est nécessaire. C’est ainsi que vous modifiez les chiffres. C’est ainsi que vous mettrez fin aux échecs évitables.
