Depuis des décennies, les entreprises raffinent leur manière de conduire les projets informatiques. Elles investissent dans les méthodes, renforcent la gouvernance, se convertissent à l’agilité. Mais malgré tous ces efforts, le taux de réussite reste désespérément bas.

Et si le véritable problème n’était pas la façon dont les projets sont menés, mais ce qu’on y met ? Car dans les systèmes d’information comme dans la vie, ce n’est pas en ajoutant que l’on progresse, c’est en simplifiant.

Le chiffre est connu, mais toujours aussi peu digéré : seuls 30 % des projets informatiques aboutissent dans les temps, dans les coûts, avec la qualité attendue. Depuis trente ans, les entreprises traquent ce que l’on appelle le « triangle d’or » du pilotage – coût, délai, qualité – sans jamais parvenir à franchir ce plafond de verre. Alors, elles pilotent mieux. Elles changent de méthode. Elles se tournent vers l’agilité. Pourtant, malgré ce ballet méthodologique, les chiffres stagnent. Pire, certaines études récentes notent une dégradation.

Mais si l’on s’éloigne un instant de cet indicateur-phare, une réalité bien plus inquiétante émerge : dans la majorité des projets IT, c’est plus de la moitié des fonctionnalités développées ne sont jamais utilisées. Car, tout aussi constant que le taux de réussite est celui de l’usage, et il est désespérément bas : 20 % des fonctionnalités sont utilisées régulièrement et 20 % supplémentaires le sont occasionnellement. Cela fait tout de même 60 % qui ne le sont jamais. Ce n’est plus une question de retard ou de dépassement budgétaire, mais de pertinence. On fabrique trop. Trop vite. Et surtout : à côté du besoin.

Prenons un budget annuel projet à 500 M€. En admettant que les 60 % de fonctionnalités inutilisées ne représentent « que » 30 % du budget, ce sont déjà 150 M€ dépensés en pure perte. Malheureusement, en informatique, l’investissement initial n’est que le début de l’histoire. Chaque euro engagé sur un projet génère environ 20 centimes de charges récurrentes chaque année. Sur quinze ans, durée de vie moyenne d’un outil informatique, ces 150 M€ se transforment en plus de 450 M€ de coûts de fonctionnement pour maintenir ce qui n’est d’aucune utilité.

Une dette fonctionnelle qui plombe toute l’entreprise

Aucune utilité ? Pas pour tout le monde car le monstre de la complexité s’en trouve lui fortement nourrit. Cette complexité invisible agit comme du sable dans les rouages. Plus il y a de fonctionnalités, plus les systèmes deviennent opaques, plus ils coûtent cher à maintenir, plus ils ralentissent les utilisateurs. On complique les processus. On multiplie les écrans. On dilue l’attention. Le tout pour des fonctions que personne n’a demandées, ou qui ne répondent plus aux usages réels.

Ce trop-plein digital a un coût humain et organisationnel. Il freine l’adoption, alourdit la formation, multiplie les tickets support. Il nuit à la qualité de service, rend l’expérience client moins fluide, épuise les équipes métiers. À force d’avoir voulu tout couvrir, on oublie l’essentiel : un outil bien conçu est un outil qui disparaît derrière son usage.

Et pourtant, on continue de dérouler les projets comme on déroulerait une liste de courses : un backlog figé, des MVP surdimensionnés, des spécifications qu’on ose à peine remettre en question. Ce réflexe du « tant qu’on y est » traduit une peur : celle de ne jamais pouvoir revenir plus tard. Alors on surcharge dès le départ. On cale tout ce qu’on peut. Et on s’étonne que les projets soient trop longs, trop chers, et surtout… trop vides de sens.

La méthode n’y peut rien sans un changement de culture

L’agilité, dans son esprit initial, avait pourtant tout pour inverser la tendance. Livrer vite, par petits incréments. Prioriser. Ajuster. Dire non. Mais dans la réalité, elle s’est souvent vidée de sa substance. On a remplacé le tunnel de spécifications par un tunnel de sprints. Et le backlog, censé évoluer avec les retours utilisateurs, s’est figé dès les premières réunions.

Tant que la gouvernance des projets reste centrée sur le « comment » au lieu du « quoi », on continuera de livrer des produits inutiles, avec une efficacité redoutable. Car sans remise en question du besoin, même la meilleure usine logicielle finit par produire des biens invendables.

Ce qu’il faut, c’est un changement de posture. Redonner aux métiers le pouvoir – et la responsabilité – de dire ce qui compte vraiment. Accepter que tout ne sera pas livré tout de suite. Repenser les comités de validation non plus comme des chambres d’enregistrement, mais comme des lieux de décisions sur la valeur. Et surtout, instaurer un climat de confiance : oui, il sera possible d’obtenir un complément plus tard, si la demande est fondée. Non, il n’est pas nécessaire de tout faire maintenant.

Simplifier n’est pas renoncer, c’est choisir

Le mot clé, ici, c’est la frugalité. Pas l’austérité, mais la frugalité choisie. L’art de faire moins pour faire mieux. Car réduire le périmètre d’un projet, ce n’est pas appauvrir la solution. C’est la rendre plus claire, plus efficace, plus utile.

Les entreprises ont tout à y gagner. Un système allégé, c’est moins de maintenance, moins de support, une adoption plus rapide. C’est aussi un meilleur moral des équipes, une expérience client optimisée, une image plus moderne. C’est, enfin, une informatique alignée avec ce qu’elle aurait toujours dû être : un levier de performance, pas un fardeau de complexité.

À l’heure où l’on parle de numérique responsable, de sobriété technologique et de durabilité, il est urgent de revoir nos ambitions à la baisse – pour faire remonter la valeur. Ne plus confondre performance et accumulation. Et se rappeler, comme le disait déjà Léonard de Vinci, que la simplicité est la sophistication suprême.