Un projet digital sur deux échoue. Presque jamais pour des raisons techniques.

Quand un projet échoue, la technique est mise en cause. C’est ce qui est visible : des retards, des bugs, une livraison qui ne convient pas.

Les causes réelles sont antérieures, et elles se repèrent tôt.

1. Personne ne sait à quoi mesurer la réussite

Question posée en début de projet : à quoi verrez-vous, dans six mois, que cela a servi ? Si les réponses divergent selon l’interlocuteur, le projet a déjà un problème.

Sans critère partagé, chaque partie prenante évalue le résultat à l’aune de ses propres attentes, jamais exprimées. La livraison déçoit tout le monde, pour des raisons différentes et contradictoires.

2. Il n’y a pas de décideur unique

Un projet avec cinq personnes qui peuvent dire non et aucune qui peut dire oui avance par consensus mou. Les arbitrages sont reportés, puis tranchés en fin de parcours, quand les changer coûte le plus.

Le signal est facile à repérer : une décision simple prend plus de trois semaines.

3. Le périmètre a été figé avant d’être compris

Un cahier des charges détaillé rédigé avant tout contact avec les utilisateurs décrit une solution imaginée. Le contrat porte dessus, l’exécution aussi, et le décalage avec le besoin réel se découvre à la recette.

À ce stade, corriger suppose de renégocier — c’est-à-dire d’admettre une erreur, ce qui prend souvent plus de temps que la correction elle-même.

4. Rien n’est montré avant la fin

Un projet qui ne produit rien de visible pendant quatre mois accumule quatre mois de malentendus. Ils apparaissent tous le même jour.

C’est la cause la plus facile à supprimer : une adresse consultable, mise à jour toutes les deux semaines, transforme un malentendu de quatre mois en une remarque de quinze jours.

5. Les utilisateurs découvrent l’outil à la livraison

Un outil conçu à partir des demandes de la hiérarchie, sans jamais avoir observé le travail réel, est contourné dès la mise en service. Les tableurs parallèles réapparaissent en quelques semaines.

Une demi-journée d’observation sur le terrain, en début de projet, corrige davantage qu’un comité de pilotage mensuel.

Ce que ces cinq causes ont en commun

Aucune n’est technique, et toutes sont visibles avant la première ligne de code. Elles se traitent au moment où elles coûtent le moins, à condition de poser les questions inconfortables : qui décide, à quoi se mesure la réussite, et qui a vu le travail réel.

Un prestataire qui pose ces questions au premier rendez-vous ne fait pas de la philosophie. Il réduit le risque que vous portez.