Stratégie

Pourquoi les projets informatiques échouent-ils encore ?

---

Malgré les efforts d'alignement entre DSI et métiers, les initiatives technologiques et de transformation échouent encore à un rythme inacceptable. Zoom sur les 8 erreurs les plus courantes menant à ces dérapages.

PublicitéLes organisations informatiques ont déployé des efforts considérables pour se défaire des problèmes qui ont entravé la réussite des projets par le passé. Elles ont éliminé les périmètres trop vastes, remplacé les cycles de développement en V par les itérations rapides, l'approche agile et les sprints de plusieurs semaines, espérant ainsi éviter les échecs retentissants qui ont jalonné l'histoire de l'informatique. Ces changements ont effectivement porté leurs fruits. Pourtant de nombreux projets informatiques échouent encore.

Les données mesurant le taux de réussite des projets informatiques sont difficiles à obtenir, mais certaines études apportent un éclairage sur le sujet. L'étude « Pulse of the Profession 2025 » du Project Management Institute estime ainsi qu'environ 80 % des projets d'entreprise atteignent leurs objectifs métiers, ce qui signifie aussi qu'un projet sur cinq n'y parvient pas. Parallèlement, une étude du MIT datant de 2025 et intitulée « The GenAI Divide : State of AI in Business 2025 » (La fracture de l'IA générative : État de l'IA en entreprise en 2025) révèle un taux d'échec de 95 % pour les projets pilotes d'IA générative en entreprise. L'échec étant ici défini comme l'absence de retours financiers mesurables dans les six mois suivant le lancement.

Certes, l'échec d'un projet n'entraîne plus l'effondrement de l'ensemble du système d'information, comme c'était parfois le cas il y a quelques décennies. Il ne signifie généralement pas non plus qu'un nouveau système est techniquement dysfonctionnel, autre scénario vécu au cours de l'histoire mouvementée des projets informatiques. Aujourd'hui, un échec signifie plutôt qu'un projet informatique ne produit pas les bénéfices escomptés, selon les DSI, les chefs de projet, les chercheurs et consultants. Un échec peut également se traduire par une absence de rentabilité, un retard tel qu'un projet est obsolète lors de sa mise en production, ou encore un manque d'engagement des utilisateurs qui, par conséquent, le rejettent. Alors, que se passe-t-il ? Pourquoi les projets informatiques continuent-ils d'échouer ? Voici les causes les plus fréquentes.

1. Manque d'expertise en gestion de projet

Les projets coûteux et à forte visibilité bénéficient de l'expertise de chefs de projet aguerris, contrairement aux projets de petite et moyenne envergure, explique Eric Bloom, directeur exécutif de l'IT Management and Leadership Institute, organisme spécialisé dans les formations et certifications à la gestion de projets. Ainsi, ces projets de petite et moyenne envergure sont souvent confiés à des analystes d'affaires sans véritable formation, explique-t-il. Ces personnes n'ont généralement ni l'expertise, ni la formation, ni l'expérience nécessaires pour réussir en tant que chef de projet, et on ne leur accorde pas suffisamment de temps pour apprendre les rouages de cette discipline, ni pour accomplir les tâches supplémentaires qui y sont liées.

PublicitéEric Bloom affirme que les DSI verraient leur taux de réussite grimper si davantage de projets étaient confiés à des chefs de projet dûment formés. Ces derniers sont mieux à même de mobiliser et de planifier les ressources, de coordonner les plannings des équipes et de fédérer les efforts de chacun, et ce, sur plusieurs projets simultanément. Ils sont également plus aptes à mettre en oeuvre la gouvernance nécessaire pour garantir que les projets restent sur de bons rails, atteignent leurs objectifs et évitent les dérives de périmètre qui font exploser les coûts et les délais sans apporter de réelle valeur ajoutée.

2. Alignement défaillant avec les objectifs métiers

Les responsables IT et désormais les directions métiers se passionnent pour les technologies. Malgré les mises en garde concernant leur mise en pratique, il en résulte un décalage entre les ambitions des projets et les objectifs métiers, constatent des DSI expérimentés et chefs de projet chevronnés. Kathleen Walch, directrice de l'engagement et de la communauté IA au Project Management Institute, affirme que les organisations continuent de « d'abord trouver une solution, puis un problème à résoudre ». L'injonction courante « d'agir avec l'IA » n'est que la dernière manifestation de ce problème, souligne-t-elle. Elle conseille évidemment aux organisations d'identifier d'abord un problème ou un objectif précis, d'élaborer un plan pour y remédier et de justifier sa pertinence économique.

Thomas Phelps IV, DSI de Laserfiche, entreprise spécialisée dans la gestion documentaire, et membre du conseil consultatif du SIM Research Institute, abonde dans ce sens : « les projets informatiques devraient commencer par une analyse de rentabilité approuvée et réévaluée tout au long de leur cycle de vie. « Souvent, cette analyse n'est réexaminée qu'après la mise en production, alors que des dépassements de coûts importants sont déjà survenus. »

3. Absence de responsabilité métier

Même lorsque l'informatique est parfaitement alignée sur les objectifs métier, un projet peut échouer si aucun responsable métier n'en est tenu responsable, selon Eric Stettler, associé au sein du pôle transformation technologique de Kearney, cabinet international de conseil en stratégie et management. Pour Eric Stettler, un dirigeant clairement identifié comme responsable de l'initiative est indispensable pour garantir la disponibilité des ressources de l'entreprise en temps voulu et pour assurer la mise en oeuvre des changements de processus et l'adhésion par les employés à ceux-ci.

L'associé de Kearney souligne que confier ces tâches au DSI plutôt qu'au dirigeant serait contre-productif : « le DSI peut veiller à ce que la responsabilité des processus soit clairement définie et que les dirigeants partagent des objectifs communs, mais en fin de compte, c'est au métier de décider s'il va modifier son mode de fonctionnement ».

4. Manque d'implication du sponsor

Désigner un sponsor métier ne suffit pas ; ce dernier doit également consacrer suffisamment de temps au suivi de l'initiative, souligne Eric Stettler. « Souvent, les responsables opérationnels d'une initiative font un point d'étape de 30 minutes, vérifient que tous les indicateurs sont au vert, mais ne s'impliquent pas pleinement dans les décisions prises, déplore-t-il. Le fait qu'ils ne consacrent pas plus de temps à la façon dont l'activité va tourner à l'avenir est une grave erreur. »

Par conséquent, ils peuvent manquer des signes indiquant que le projet dérape et ne développent pas suffisamment une relation de confiance avec les chefs de projet, pour que ces derniers se sentent à l'aise lorsqu'il s'agit de faire remonter des problèmes dès leurs prémisses. « Les dirigeants doivent consacrer plus de temps et s'impliquer à tous les niveaux du programme. Ils ne peuvent pas se contenter d'attendre que les responsables viennent leur parler, mais doivent effectuer des contrôles ponctuels et des revues de qualité des livrables. Le contact avec les responsables du projet doit être constant tout au long du programme, explique Eric Stettler. Et ils doivent afficher l'attitude suivante : "N'hésitez pas à me faire part de vos besoins lorsque je peux vous être utile." »

5. Insuffisance d'implication de toutes les parties prenantes

Krista Phillips, chef de projet informatique, raconte le cas d'une grande multinationale qui a déployé une nouvelle technologie dans toutes ses filiales, mais qui a pris par surprise une division qui ignorait totalement le déploiement en cours. Il s'avère que cette division avait été exclue de tous les processus de planification et de projet. « Je ne sais pas comment les chefs de projet ont pu passer à côté de cela, mais ils ont négligé une division entière. Du coup, quand le système a été mis en service, les équipes au sein de cette dernière se sont demandé : "C'est quoi ça ?" L'absence de prise en compte de cette entité a conduit l'équipe projet à mal définir le périmètre de l'initiative », explique Krista Phillips, titulaire de la certification PMP (Project Management Professional, une accréditation pour les professionnels en gestion de projets) et présidente de la section régionale Pikes Peak du Project Management Institute dans le Colorado.

Krista Phillips reconnaît qu'une telle omission reste rare, mais il arrive que les équipes projet oublient certaines parties prenantes, alors qu'elles sont nécessaires au processus. Par conséquent, elles passent à côté d'exigences essentielles, de réglementations à prendre en compte et d'opportunités à exploiter.

6. Sous-dimensionnement des ressources

Autre raison de l'échec des projets informatiques : la sous-estimation des ressources et compétences nécessaires, ainsi que la sous-estimation de la charge de travail elle-même. « C'est un problème récurrent, mais il s'aggrave aujourd'hui », souligne Sanjeev Vohra, directeur de la technologie et de l'innovation chez Genpact, une société de services informatiques. Il précise que les DSI qui souhaitent exploiter l'IA et d'autres technologies émergentes manquent d'expérience pour savoir précisément quelles compétences seront requises, combien elles coûteront et combien de temps il faudra pour parvenir à les réunir.

Même dans de tels cas, Sanjeev Vohra recommande une approche éprouvée pour résoudre le problème : « Réfléchissez bien à votre conception en faisant preuve de discernement, en consacrant plus de temps à trouver les bons partenaires et à obtenir des informations précises sur des aspects précis, et en effectuant les vérifications nécessaires afin de définir le périmètre adéquat et les ressources nécessaires.»

7. Équipes inexpérimentées

De même, selon Thomas Phelps IV, des équipes inexpérimentées peuvent compromettre un projet. « J'ai vu des projets échouer à cause de chefs de projet inexpérimentés. Ce n'est pas parce qu'une personne possède une certification en gestion de projet qu'elle est un bon chef de projet », affirme-t-il.

Par exemple, les chefs de projet inexpérimentés peuvent ne pas se rendre compte que chaque semaine supplémentaire dans le calendrier d'un projet augmente directement son coût. « Les équipes devront comptabiliser leurs heures pour les semaines de travail supplémentaires, qui seront absorbées et payées soit par le client soit par le fournisseur », explique-t-il.

Eric Stettler évoque un problème connexe qui peut également nuire à la réussite d'un projet : supposer qu'il est possible d'y greffer des compétences plus expérimentées en cas de difficultés. « Souvent, seules quelques personnes sont capables d'effectuer le travail nécessaire, et leur planning est généralement déjà bien chargé », explique-t-il, soulignant que même si ces experts acceptent une mission imprévue, ils n'auront probablement pas la disponibilité nécessaire pour mener à bien leurs tâches.

Thomas Phelps, Eric Stettler et d'autres recommandent aux DSI, à leurs partenaires métiers sur les projets et aux chefs de projet de vérifier scrupuleusement les compétences requises avant d'affecter des collaborateurs à une intiative, puis de s'assurer de leur engagement pour la durée nécessaire à l'exécution de leurs tâches.

8. Sous-estimation de la gestion du changement

Les projets ont besoin de bien plus que de chefs de projet compétents ; ils ont également besoin de leaders maîtrisant la conduite du changement. A défaut, les intiatives risquent fort de ne pas atteindre les objectifs fixés, affirme Nick Kramer, directeur des solutions appliquées chez SSA & Co., un cabinet de conseil international spécialisé dans l'accompagnement des entreprises en matière d'exécution stratégique.

Les gestionnaires du changement compétents savent aligner les incitations pour amener les gens à accepter de nouvelles méthodes de travail, et ils sont habiles pour identifier et contrer les obstacles qui pourraient freiner l'adoption des nouvelles technologies, explique-t-il. Ils parviennent souvent à convaincre les employés réticents en les aidant à comprendre le sens d'une transformation.

« La gestion du changement est souvent perçue comme un simple plan de communication, et on en parle peu. Mais elle est en réalité très complexe », dit Nick Kramer, soulignant qu'il a constaté davantage d'échecs à cause d'une mauvaise gestion du changement que d'implémentations technologiques hasardeuses. « Pour réussir, les projets ont besoin d'un DSI ou d'une autre personne capable de piloter le changement, quelqu'un qui sait comment le mener », résume-t-il.

Article rédigé par

Mary Pratt, CIO (adapté par Reynald Fléchaux)

Partager cet article