Vos logiciels de gestion de projet sont construits à l’envers …

… et c’est pour cela que vos projets échouent
Il existe aujourd’hui plus de logiciels de gestion de projet que de façons de rater un projet. Et c’est tout dire. Asana, Monday, Trello, Jira, Wrike, ClickUp, Notion : chaque trimestre apporte sa nouvelle promesse de productivité. Le tableau est plus fluide, l’IA plus enthousiaste. De plus, le marché pèse des dizaines de milliards d’euros et croît à deux chiffres. Jamais une entreprise n’avait disposé d’autant de moyens. Désormais, elle sait qui doit faire quoi, et quand.
Et pourtant. Trente ans après les premières études sérieuses sur la performance des projets, le verdict n’a pas bougé. La majorité d’entre eux dérapent encore. Ils explosent leurs budgets, livrent moins que promis, ou meurent purement et simplement. Nous avons pourtant numérisé le diagramme de Gantt environ mille fois. Or ce dernier date de 1910. Malgré cela, le taux d’échec est resté d’un calme olympien. Il y a là un paradoxe que l’industrie du logiciel n’aime pas regarder en face. Et si tous ces logiciels de gestion de projet étaient, depuis le départ, construits à l’envers ?
Trente ans de logiciels de gestion de projet, zéro progrès : le paradoxe que personne n’ose nommer
Commençons par le seul juge de paix qui vaille : les chiffres. Le Standish Group publie son CHAOS Report depuis 1994. C’est la référence internationale sur la performance des projets informatiques. Dans l’édition 2020, le constat tient en trois nombres. D’abord, 31 % des projets seulement sont vraiment réussis. Autrement dit, ils sont livrés à temps, dans le budget, et avec un résultat satisfaisant. Ensuite, 50 % sont « challengés » : terminés, mais en retard, en dépassement ou amputés de fonctionnalités. Enfin, 19 % sont annulés avant d’avoir vu le jour. Au passage, le projet « challengé » moyen coûte environ 189 % de son budget initial. Vous avez bien lu : presque le double.
Or ces chiffres ressemblent étrangement à ceux des années 1990. À l’époque, pourtant, il n’y avait ni cloud, ni SaaS, ni cartes Kanban animées. Gartner fait le même constat de son côté. Les grands projets informatiques sont jugés ratés par leurs propres commanditaires dans près de 80 % des cas. De plus, la probabilité d’échec grimpe d’environ 50 % dès qu’un budget dépasse le million de dollars. Trois décennies d’innovation logicielle frénétique, donc, pour un score inchangé. À la place, on a sorti une nouvelle version de l’outil.
La conclusion est difficile à esquiver. Si l’outillage avait été la cause du problème, son explosion aurait dû améliorer les choses. Or elle ne l’a pas fait. Le problème est donc ailleurs.
Le péché originel du logiciel de gestion de projet : tout part de la tâche
Pour comprendre cet échec, il faut remonter à la brique élémentaire de ces logiciels. Cet atome conceptuel porte un nom : la tâche. Une tâche, c’est une chose à faire. On l’assigne à une personne, on lui colle une échéance, puis on la fait glisser d’une colonne à l’autre. Grattez le vernis de n’importe quel logiciel de gestion de projet du marché. Vous y retrouverez toujours le même noyau dur. À chaque fois, ce sont des actions, des assignés, des dates. Et toujours le même geste : glisser une carte vers « Terminé ».
Or ce choix n’a rien d’anodin. C’est une vision du monde déguisée en outil neutre. En effet, bâtir un logiciel à partir de la tâche revient à poser un postulat. Gérer un projet consisterait à organiser une séquence d’actions confiées à des collaborateurs. Le management de projet se réduit alors à de la tuyauterie. C’est propre, rassurant, parfait en démonstration commerciale. C’est surtout faux.
La tâche, ou l’art de regarder le doigt qui montre la lune
La tâche, c’est la surface du projet. Ce n’est jamais sa substance. En effet, elle est ce qui se voit et se mesure facilement. Elle rend bien sur un tableau de bord. Les feux arrière d’une voiture renseignent sur la circulation, mais ne disent rien du moteur. Ainsi, on peut piloter une organisation entière en regardant des cartes changer de colonne. Et passer complètement à côté de l’essentiel. Car l’essentiel se cache dans trois questions. A-t-on défini ensemble ce que « réussir » veut dire ? Qui tranche en cas de désaccord ? Et qui répond du résultat, devant qui ? Aucune de ces questions ne tient dans une tâche. Toutes relèvent d’un autre registre. Or la quasi-totalité des outils l’a relégué au rang d’accessoire : la gouvernance.
Ce qu’est vraiment un projet : un contrat, des rôles, et un seul responsable
Un projet n’est pas une chorégraphie de tâches. C’est une relation contractuelle. Et cela vaut aussi, c’est capital, lorsqu’elle est interne à l’entreprise. Prenons un exemple. Une direction métier confie un développement à une DSI, ou deux équipes s’engagent l’une envers l’autre. À chaque fois, la même chose se noue. D’abord un accord sur un objectif. Ensuite un partage des rôles et des responsabilités. Et surtout une redevabilité. Or les logiciels ont oublié ce mot dans leur dictionnaire.
Ce vocabulaire n’est pas une coquetterie de consultant. Il a un nom, une grammaire, et des décennies de pratique : la matrice RACI. Pour chaque livrable, on distingue quatre rôles. Le R réalise, le C est consulté, le I est informé. Et surtout, le A est redevable (pour Accountable). C’est lui qui valide, qui arbitre, qui garantit les moyens et qui répond du résultat. La règle d’or tient en une phrase. Il y a un, et un seul, A par ligne. En effet, lorsque la redevabilité est partagée entre tous, plus personne ne la porte. C’est mathématique. Et c’est mortel.
La redevabilité, ce mot que votre logiciel de gestion de projet ignore
Faites le test avec votre logiciel préféré. Demandez-lui qui est le redevable du jalon de la semaine prochaine. Non pas qui en a la tâche, mais qui en répond. Demandez-lui aussi où est tracée la décision du dernier comité. Sur quels critères, et validée par qui ? Au mieux, vous obtiendrez un commentaire dans une carte. Et un compte-rendu qui se perdra dans les e-mails. Car ces outils ont été pensés pour orchestrer l’exécution. Jamais pour incarner la gouvernance. Ainsi, ils savent dire qui fait quoi. En revanche, ils ne disent pas qui décide, qui valide et qui répond. En somme, ils gèrent l’agitation, pas l’engagement. Or les causes d’échec vivent toutes du côté de la gouvernance. On a donc fabriqué des machines très perfectionnées. Mais elles résolvent un problème qui ne s’est jamais posé. C’est précisément cela, construire à l’envers.
Pourquoi les structures les mieux outillées sont aussi celles qui échouent le plus
Si le logiciel de gestion de projet était la clé, les organisations les mieux équipées seraient les plus performantes. Or c’est l’inverse qui se produit. Selon le Standish Group, le taux de réussite s’effondre quand l’entreprise grandit. Dans les grands groupes, il atteint péniblement 9 %. Pourtant, ces structures regorgent de chefs de projet certifiés, de budgets colossaux et de PMO. De même, les entreprises de taille intermédiaire battent un record d’abandon, autour de 37 %. Autrement dit, plus on a de moyens, de méthode et de logiciels, plus on rate.
Gartner observe la même mécanique. Un projet de plus d’un million de dollars échoue bien plus souvent qu’un petit. Pourtant, il bénéficie de davantage de ressources et de supervision. McKinsey enfonce le clou sur les grands programmes informatiques. En effet, 17 % d’entre eux menacent carrément l’existence de l’entreprise. Et la valeur réellement livrée reste inférieure de plus de moitié à la promesse. La leçon est limpide. Ajouter de la puissance d’exécution à un dispositif mal gouverné ne le sauve pas. Au contraire, cela le fait échouer plus cher et plus loin. Le tout avec une traçabilité impeccable de son propre naufrage.
La preuve par l’absurde : Louvois, Berlin et les fantômes du pilotage
Les statistiques convainquent les têtes. Les histoires, elles, convainquent les tripes. En voici deux que les budgets ne rattraperont jamais.
La première est française. Son acronyme est presque comique au regard du désastre : Louvois. Cela signifie « Logiciel Unique à VOcation Interarmées de la Solde ». Il devait payer les militaires des trois armées. Mis en service en 2011, il sombre aussitôt dans le surréalisme. Plus de 160 000 soldats voient leur solde mal calculée. Certains touchent 90 euros par mois. D’autres reçoivent des sommes mirobolantes, qu’on leur réclamera des années plus tard. Or l’argent a déjà été dépensé. Au total, les trop-perçus dépassent le demi-milliard d’euros. Fin 2013, le ministère annonce donc l’abandon pur et simple du système. Mais le plus instructif n’est pas le montant. C’est le diagnostic. En effet, les rapports parlementaires ne pointent pas un bug. Ils pointent les défaillances du pilotage du projet. Concrètement, une multitude de services se partageaient le sujet. Aucune autorité n’était clairement redevable du résultat d’ensemble. Et personne ne parvenait même à arrêter le projet, faute de pilote pour trancher. Ainsi, le code n’a fait que rendre visible une faillite de gouvernance, à l’échelle de la nation.
Berlin, ou quand le logiciel de gestion de projet n’y est pour rien
La seconde histoire est allemande. Et elle possède une vertu redoutable : elle ne contient pas une ligne de logiciel de gestion de projet. L’aéroport de Berlin-Brandebourg devait ouvrir en 2011, pour environ deux milliards d’euros. Finalement, il a ouvert le 31 octobre 2020. Soit neuf ans de retard. Entre-temps, six dates d’ouverture ont été annoncées puis abandonnées. De plus, la facture a doublé, puis triplé, pour dépasser les six milliards. Un ancien responsable a même été condamné pour corruption. D’ailleurs, le patron de l’aéroport a reconnu que le projet avait fait de l’Allemagne la risée du monde. Une « solution » fut même envisagée pour le système anti-incendie. Elle consistait à poster des centaines de personnes sur des tabourets, téléphone en main. Car lorsque la gouvernance s’effondre, aucune prouesse technique ne comble le trou. On invente seulement des rustines de plus en plus humiliantes. Le quotidien des entreprises rejoue d’ailleurs le même scénario, à voix plus basse. Pensez au prestataire dont les projets au forfait finissent au tribunal. Ou à la banque qui empile les « task-forces » sans jamais toucher au management.
Le coût caché de l’illusion : ce que personne ne met dans le business case
On aime croire que le coût d’un projet raté s’arrête à son budget. Charmante naïveté. Le Consortium for Information & Software Quality a chiffré le coût de la mauvaise qualité logicielle. Aux seuls États-Unis, il atteint environ 1 820 milliards de dollars par an. Une part vient des échecs eux-mêmes. Mais l’essentiel vient des défaillances opérationnelles qui suivent. En somme, un projet raté n’est pas une ligne barrée dans un tableur. C’est une dette qui irrigue l’organisation pendant des années.
Et puis il y a le coût que personne n’inscrit noir sur blanc : l’humain. Gallup le mesure dans son State of the Global Workplace 2026. En Europe, le taux d’engagement des salariés plafonne à 12 %. C’est le plus bas du monde, derrière toutes les autres régions. De plus, le désengagement coûte à l’économie mondiale l’équivalent de 9 % du PIB. Or les projets qui dérapent fabriquent justement du désengagement. On y trouve la surcharge, le conflit larvé, le sentiment d’absurdité. Et des signaux faibles que personne ne capte à temps. D’ailleurs, la dérive humaine précède toujours la dérive du jalon. Mais elle survient hors champ des logiciels, qui regardent ailleurs.
L’agilité ne vous sauvera pas (et la prochaine licence non plus)
À ce stade surgit toujours la même objection. « Nous, on fait de l’Agile. » C’est mignon, et c’est insuffisant. Le PMI le montre dans son Pulse of the Profession. En effet, les approches prédictive, agile et hybride se valent globalement. Autrement dit, l’adoption massive de l’agilité n’a rien changé au taux de réussite. Car la méthode, comme l’outil, n’est qu’un instrument. Appliquée au mauvais problème, elle ne le corrige pas. Au contraire, elle le ritualise.
Faut-il pour autant jeter les logiciels par la fenêtre ? Pas davantage. En effet, PWC observe une corrélation nette. 77 % des projets très performants s’appuient sur un logiciel de gestion de projet. Seuls 23 % s’en passent. L’outillage compte donc. Mais il compte comme serviteur de la gouvernance, jamais comme substitut. Ainsi, ce qui corrèle avec la performance, c’est le suivi des décisions et la traçabilité. C’est aussi le pilotage transverse et l’attention portée à l’humain. Ce n’est pas la énième fonction de glisser-déposer. En somme, ni la méthode ni l’outil ne font réussir un projet. La gouvernance, oui.
Ni le logiciel de gestion de projet ni l’IA ne remplacera le pilote
Reste la grande promesse du moment. L’intelligence artificielle, enfin, réglerait la question. Copilotes, comptes-rendus automatiques, tableaux de bord prédictifs, agents qui relancent à votre place. C’est séduisant, et parfois utile. Mais l’IA repose sur la même fondation inversée. En effet, elle accélère la surface. Elle fait avancer la carte plus vite. Elle résume la réunion et anticipe le glissement de planning. En revanche, elle ne gouverne pas. Et pour une raison simple : elle ne le peut pas.
La redevabilité ne se délègue pas à un modèle
Car la redevabilité (le « A » de la matrice RACI) n’est pas une donnée à calculer. C’est une position morale et contractuelle. Être redevable, c’est répondre du résultat. C’est arbitrer entre des intérêts opposés, et porter les conséquences devant le client. Or on ne délègue pas cela à un modèle. Ce dernier ne signe rien, ne risque rien, et n’est licencié par personne. D’ailleurs, Gallup le formule sans détour. Gagner la révolution de l’IA dépendra moins de la technologie que de la qualité du leadership. Des chercheurs de Stanford, Harvard et du MIT l’avaient déjà mesuré. En effet, les pratiques managériales pèsent plus lourd que la technologie sur la productivité.
Le malentendu, depuis le début, tient en un mot. On a confondu la gestion des tâches avec la vraie gestion de projet. La première, les logiciels la font bien, et l’IA la fera mieux encore. La seconde est une gestion de la gouvernance. Concrètement, cela veut dire cadrer un objectif et distribuer les redevabilités. Cela veut dire aussi lire les signaux humains faibles. Cela veut dire, enfin, tenir un go/no-go et désamorcer un conflit à temps. Or cela ne s’achète pas sous licence. Cela s’acquiert sur le terrain, dans les projets qui brûlent. Bref, c’est une compétence rare, chèrement payée, et irréductiblement humaine.
Entre des mains incompétentes, l’outil le plus puissant n’efface pas le chaos. Au contraire, il l’industrialise. Il produit alors de superbes tableaux de bord d’un navire qui coule. Simplement plus vite. D’où une conclusion inconfortable et libératrice. Aucun logiciel de gestion de projet, présent ou à venir, ne pilotera vos projets à votre place. Le pilote est, et restera, humain. C’est donc là qu’il faut investir. Pas dans la prochaine licence.
Sources
Études et données de référence
- The Standish Group International (2020). CHAOS Report 2020: Beyond Infinity : taux de réussite, projets « challengés » et abandonnés ; dépassement budgétaire moyen ; taux de succès par taille d’entreprise.
- The Standish Group International (1994). The CHAOS Report : première édition de référence.
- PM World Journal (janvier 2026). Arcidiacono, G. « Comparative research on IT project failure rates » : données consolidées 2020-2024.
- Gartner (2011-2012). Five-country IT project survey et synthèses associées : taux d’échec selon la taille de budget ; proportion de projets jugés ratés par les commanditaires.
- Gallup (2026). State of the Global Workplace: 2026 Report : engagement des salariés en Europe (12 %) ; coût mondial du désengagement (≈ 9 % du PIB) ; déclaration de Jon Clifton sur le lien entre IA et qualité du leadership.
- PricewaterhouseCoopers. Insights and Trends: Current Programme and Project Management Practices (213 répondants) : 77 % des projets très performants s’appuient sur un logiciel de gestion de projet ; rôle de la gouvernance.
- Project Management Institute (2024). Pulse of the Profession : The Future of Project Work : peu de variation de performance entre approches prédictive, agile et hybride.
Coûts, management et cas cités
- McKinsey & Company (2012). Delivering large-scale IT projects on time, on budget, and on value : la moitié des grands projets IT explosent leur budget ; valeur livrée inférieure de plus de moitié ; 17 % menacent l’existence de l’entreprise.
- McKinsey & Company (2020). Managing large technology programs in the digital era : 25 à 40 % des grands programmes dépassent leur budget ou leurs délais de plus de moitié ; leviers managériaux de réussite.
- Consortium for Information & Software Quality (2020). The Cost of Poor Software Quality in the US: A 2020 Report : coût annuel ≈ 2 080 Md$, dont ≈ 1 560 Md$ de défaillances opérationnelles et ≈ 260 Md$ de projets ratés (soit les ≈ 1 820 Md$ cités).
- Bloom, N., Sadun, R. & Van Reenen, J. (2016). Management as a Technology? NBER Working Paper n° 22327 : les pratiques managériales expliquent une part de la variance de productivité supérieure à la technologie.
- Cour des comptes / Assemblée nationale et presse spécialisée (Le Monde Informatique, France Bleu), avec la notice Wikipédia Logiciel unique à vocation interarmées de la solde (LOUVOIS) : coûts, trop-perçus, militaires affectés, défaillances de pilotage, abandon (décembre 2013).
- AP / dpa, CNN, AeroTime, The Points Guy (2020-2021), avec la notice Wikipédia Aéroport de Berlin-Brandebourg (BER) : retard d’environ 9 ans ; dérive budgétaire (de ≈ 2 à ≈ 6,5 Md€) ; six dates d’ouverture ; condamnation pour corruption ; ouverture le 31 octobre 2020.
- Fredaigues, C. (2025). « Gestion de projet : succès et échecs ». Orgatypik : cas terrain (prestataire au forfait ; grande banque et « task-forces » successives).
En savoir plus sur orgatypik
Subscribe to get the latest posts sent to your email.