Les projets digitaux déçoivent le plus souvent pour des raisons humaines et d'organisation, non pour des raisons techniques : un objectif mal défini, des utilisateurs consultés trop tard, un périmètre trop ambitieux, une direction qui se désengage après la signature. La bonne nouvelle est que ces causes sont connues et qu'elles se préviennent. Six d'entre elles expliquent l'essentiel des déceptions.
À quoi reconnaît-on un projet qui déçoit ?
L'échec franc, celui du projet abandonné avant la livraison, n'est pas le cas le plus courant. La déception ordinaire est plus discrète. L'outil est livré, il fonctionne, et pourtant :
- une partie des équipes continue de travailler comme avant ;
- les données saisies sont incomplètes, donc les tableaux de bord sont faux ;
- la direction ne consulte plus les rapports qu'elle avait réclamés ;
- personne n'est capable de dire ce que le projet a rapporté.
Le logiciel existe, la transformation n'a pas eu lieu. C'est cette situation, plus que la panne, qu'il faut apprendre à éviter.
Les six causes qui reviennent toujours
1. On a acheté une solution avant d'avoir défini le problème
« Il nous faut un ERP », « il nous faut une application », « il nous faut de l'intelligence artificielle ». Ces phrases décrivent un moyen. Elles ne disent rien du résultat attendu. Un projet qui démarre ainsi ne peut pas réussir, puisque personne n'a précisé ce que réussir veut dire.
La parade : formulez le besoin en termes d'activité. « Connaître notre stock réel chaque soir », « facturer le jour de la livraison », « réduire le délai de délivrance d'un acte ». Le choix de l'outil vient ensuite.
2. Le terrain a été oublié
Le projet a été conçu en salle de réunion, entre la direction et le prestataire. Les personnes qui utiliseront l'outil huit heures par jour le découvrent à la formation. Elles y voient aussitôt ce qui ne marchera pas, et elles ont raison.
La parade : associez des utilisateurs dès le cadrage. Observez leur travail sur place. Faites-leur tester les maquettes. Ce principe est au centre de notre article adapter l'outil au métier, pas le métier à l'outil.
3. Le périmètre était trop large
Vouloir tout traiter d'un coup conduit à un projet long, coûteux, dont les bénéfices n'apparaissent qu'à la fin. Entre-temps, l'enthousiasme retombe, les priorités changent, le budget s'épuise.
La parade : commencez par un processus, un site, une équipe. Livrez, mesurez, étendez.
4. La direction s'est retirée après la signature
Un projet digital modifie des habitudes, des responsabilités, parfois des rapports de pouvoir. Ces arbitrages ne peuvent pas être délégués au prestataire ni au service informatique. Quand la direction disparaît, les décisions restent en suspens et chaque service défend son territoire.
La parade : un dirigeant doit porter le projet, visiblement, du début à la fin. Il nomme un chef de projet interne et lui donne du temps et de l'autorité.
5. Les données ont été sous-estimées
Un outil neuf alimenté par des données fausses produit des résultats faux, plus vite. Fichiers clients en double, références d'articles incohérentes, soldes jamais rapprochés : si ce travail de nettoyage n'est pas fait, les utilisateurs perdent confiance dès la première semaine.
La parade : traitez la reprise des données comme un chantier à part entière, avec un responsable et un calendrier.
6. L'accompagnement s'est arrêté le jour de la mise en service
Une formation de deux heures, un manuel, et chacun retourne à son poste. Or les vraies questions arrivent la troisième semaine, quand surviennent les cas particuliers. Sans personne pour y répondre, les vieilles habitudes reprennent le dessus.
La parade : prévoyez une présence renforcée pendant les premières semaines, des référents dans chaque équipe, et un canal simple pour remonter les difficultés. Les méthodes sont détaillées dans comment faire adopter un nouvel outil.
Un cas typique : la clinique de Dakar
Une clinique privée de Dakar décide d'informatiser le parcours de ses patients : accueil, consultations, pharmacie, facturation. La direction choisit un logiciel hospitalier réputé et fixe une date de démarrage générale, tous services confondus, un lundi matin.
Ce lundi-là, la file d'attente à l'accueil déborde sur le trottoir. Les secrétaires, formées la semaine précédente, cherchent leurs écrans. Les médecins découvrent qu'ils doivent saisir eux-mêmes leurs prescriptions selon une nomenclature qu'ils ne connaissent pas. La pharmacie constate que son stock initial, importé depuis un ancien fichier, est faux. À midi, les fiches papier sont ressorties. Elles ne sont jamais reparties.
Six mois plus tard, le logiciel ne servait plus qu'à éditer les factures. Tout le reste se faisait comme avant, avec une ressaisie en fin de journée.
Le logiciel n'était pas en cause. Quatre des six causes étaient réunies : périmètre total dès le premier jour, soignants non consultés, données non vérifiées, accompagnement réduit à une formation. La clinique a repris le projet plus tard, autrement : d'abord l'accueil et la facturation seuls, avec deux secrétaires associées à la conception, puis la pharmacie après un inventaire complet, puis les consultations, médecin par médecin. Le même outil, cette fois, a été adopté.
La grille de contrôle avant de lancer un projet
| Question | Si la réponse est non |
|---|---|
| Le résultat attendu tient-il en une phrase sans nom de technologie ? | Reprenez la définition du besoin |
| Des utilisateurs de terrain participent-ils à la conception ? | Désignez-les avant de continuer |
| Existe-t-il une première étape livrable en quelques semaines ? | Découpez le périmètre |
| Un dirigeant porte-t-il personnellement le projet ? | Le projet n'est pas prêt |
| Les données à reprendre ont-elles été examinées ? | Lancez un audit des fichiers |
| Un ou deux indicateurs de réussite ont-ils été mesurés avant le démarrage ? | Mesurez la situation actuelle |
| L'accompagnement après la mise en service est-il budgété ? | Ajoutez-le au plan |
Sept « oui » ne garantissent pas le succès. Mais chaque « non » laissé sans réponse annonce une difficulté précise, que vous retrouverez plus tard. Pour le choix des indicateurs, l'article mesurer le ROI d'un projet digital propose une méthode simple.
Et si votre projet a déjà déçu ?
Un projet décevant n'est pas forcément un projet perdu. Avant de tout jeter et de recommencer, cherchez laquelle des six causes a joué. Bien souvent, l'outil peut être conservé : c'est le périmètre qu'il faut resserrer, les utilisateurs qu'il faut réassocier, ou les données qu'il faut assainir.
Ce diagnostic demande un regard extérieur, parce que ceux qui ont vécu le projet ont chacun leur explication. Il commence toujours au même endroit : sur le terrain, auprès de ceux qui devaient utiliser l'outil et qui ont cessé de le faire. Leurs raisons sont presque toujours bonnes.
L'essentiel
Un projet digital réussit quand il part d'un problème précis, qu'il est conçu avec ceux qui feront le travail, qu'il avance par étapes et qu'il est porté jusqu'au bout. La technologie vient après, et elle pose rarement problème quand le reste est en place.
Que vous prépariez un projet ou que vous cherchiez à en redresser un, nos équipes peuvent vous aider à passer cette grille au crible de votre situation. Parlons-en, sans engagement, à partir de ce que vous vivez sur le terrain.