Un projet technologique qui échoue le fait rarement d’un coup. Il ne s’arrête pas un matin sur un message d’erreur. Il glisse. Une fonctionnalité reportée à la phase 2, un module qui « demande un petit ajustement », une date de mise en production repoussée d’un trimestre, puis d’un autre. Douze mois plus tard, l’organisation a dépensé un budget considérable pour un outil que personne n’utilise vraiment, et tout le monde cherche un coupable du côté du fournisseur ou de la technologie choisie.
Le coupable est presque toujours ailleurs.
Le symptôme n’est pas la maladie
Les chiffres sur l’échec des projets TI circulent depuis vingt ans et ils sont remarquablement stables : une majorité de projets dépassent leur budget, leur échéancier, ou livrent nettement moins de valeur que promis. Une étude conjointe de McKinsey et de l’Université d’Oxford sur les grands projets informatiques a établi qu’ils dépassaient en moyenne leur budget de 45 % et livraient 56 % de valeur en moins que prévu.
Ce qui frappe, quand on examine ces projets après coup, c’est la nature des causes. On y trouve rarement une erreur d’architecture, un mauvais choix de langage ou une base de données mal dimensionnée. On y trouve des exigences mal comprises, des besoins qui changent parce qu’ils n’avaient jamais été correctement formulés, des arbitrages jamais tranchés, des utilisateurs consultés trop tard.
Autrement dit : le dépassement de budget est un symptôme. La maladie est un problème de traduction entre ceux qui connaissent le métier et ceux qui construisent la solution.
Les trois fractures
La fracture du vocabulaire
Un directeur des opérations dit « il faut que le système gère les retours de marchandise ». Pour lui, cette phrase contient trente ans de pratique implicite : les cas particuliers, les exceptions négociées avec les gros clients, ce qu’on fait quand le produit revient sans facture, la personne qui a le droit d’autoriser un remboursement au-delà d’un certain montant.
Pour l’équipe technique, cette même phrase décrit une fonctionnalité. Elle est estimée à trois semaines. Elle en prendra quatorze.
Le mot le plus dangereux dans un projet TI est le mot « simple ». Quand quelqu’un dit qu’une demande est simple, cela signifie généralement qu’il n’a pas encore rencontré les exceptions.
La fracture des priorités
Les équipes métier sont évaluées sur des résultats opérationnels immédiats : volume traité, satisfaction client, délais. Les équipes TI sont évaluées sur la stabilité, la sécurité, la dette technique, la conformité. Ces objectifs ne sont pas opposés, mais ils ne se déclenchent pas au même rythme.
Résultat : le métier perçoit la TI comme un frein administratif, la TI perçoit le métier comme une source de demandes désordonnées. Chacun a raison de son point de vue, et personne n’arbitre.
La fracture de la décision
C’est la plus coûteuse et la plus discrète. Dans beaucoup de projets, personne n’a formellement le pouvoir de trancher entre deux visions du besoin. Les réunions se multiplient, les décisions sont « à valider », les comptes rendus s’accumulent. Le projet avance techniquement pendant que les questions de fond restent ouvertes, et il faudra les rouvrir en phase de test, au moment où chaque changement coûte dix fois plus cher.
Ce que l’écart coûte réellement
Le dépassement budgétaire est la partie visible. En dessous, il y a des coûts que les tableaux de bord ne capturent presque jamais :
Le coût du travail refait. Une exigence mal comprise en analyse coûte quelques heures à corriger. La même exigence corrigée après la mise en production peut coûter cent fois plus.
Le coût d’opportunité. Pendant qu’une équipe interne consacre 30 % de son temps à un projet qui patine, elle ne fait pas autre chose.
Le coût d’adoption. Un outil livré techniquement conforme mais mal aligné sur la réalité du terrain produit du contournement : des fichiers Excel parallèles, des doubles saisies, des processus officieux. L’investissement est comptabilisé, la valeur ne se matérialise jamais.
Le coût de crédibilité. Après deux projets ratés, faire approuver le troisième devient politiquement très difficile, même quand il est nécessaire.
Cinq signaux d’alerte à surveiller dès les premières semaines
Un projet en dérive donne des signes bien avant que l’échéancier ne bouge. Les plus fiables :
Les exigences tiennent en une liste de fonctionnalités, pas en une description de processus. Si le document de départ énumère des écrans plutôt que de décrire ce que fait un utilisateur dans sa journée, l’analyse n’a pas été faite.
Aucun utilisateur final n’a été interrogé. Le besoin a été formulé par la direction ou par un chef de service, jamais par les personnes qui feront la saisie.
Personne ne sait nommer le décideur. Demandez qui tranche en cas de désaccord entre deux départements. Si la réponse prend plus de dix secondes, le risque est déjà installé.
Les cas d’exception sont renvoyés à plus tard. « On verra les cas particuliers en phase 2 » est la phrase qui précède la plupart des dépassements, parce que dans beaucoup de métiers, les cas particuliers représentent la moitié du volume.
Le critère de succès n’est pas mesurable. Si le projet vise à « améliorer l’efficacité » sans indicateur de départ ni cible chiffrée, personne ne pourra dire s’il a réussi, et il sera donc réputé avoir échoué.
Comment refermer l’écart
Investir en amont, là où c’est le moins cher. Chaque heure passée à clarifier un besoin avant le développement en économise plusieurs dizaines ensuite. C’est contre-intuitif pour une direction qui veut voir des livrables rapidement, mais c’est le seul endroit du projet où le retour est aussi élevé.
Documenter les processus réels, pas les processus officiels. Il y a presque toujours un écart entre la procédure décrite dans le manuel et ce que les équipes font vraiment. C’est dans cet écart que se cachent les exigences oubliées.
Nommer un traducteur. Quelqu’un dont le mandat explicite est de comprendre le métier assez profondément pour le formaliser, et la technologie assez bien pour dialoguer avec les développeurs. Ce rôle, c’est celui de l’analyste d’affaires. Quand il est absent, la traduction se fait quand même, mais par défaut, par des gens dont ce n’est pas le métier, et avec des pertes.
Établir un critère de succès avant de commencer. Une mesure de départ, une cible, une date. Sans cela, le projet n’a pas de définition de fin.
Rendre les décisions traçables. Pas des comptes rendus de réunion : un registre des arbitrages, avec ce qui a été décidé, par qui, et ce qui a été écarté. C’est ce document qui empêche de rouvrir six mois plus tard un débat déjà tranché.
Le vrai enjeu
Une organisation qui échoue à ses projets TI n’a généralement pas un problème de fournisseur. Elle a un problème de capacité à formuler ce qu’elle veut, à l’arbitrer, et à le vérifier. Changer d’intégrateur sans corriger cela revient à recommencer le même projet avec une équipe différente.
C’est aussi une bonne nouvelle : contrairement à la technologie, cette capacité s’installe. Elle demande une méthode, une discipline de documentation, et quelqu’un pour tenir la ligne entre le besoin et la solution.
Vous vous reconnaissez dans un ou plusieurs de ces signaux ? Chez Ruby Edge Consulting, nous commençons chaque mandat par un diagnostic de l’existant avant de proposer quoi que ce soit. Réservez une consultation stratégique pour faire le point sur votre projet.
