« On ne va pas dire que vous n'avez rien compris à notre métier. Ce serait faux. Mais sur cette partie-là, vous n'avez clairement pas tout compris. »

C'est ce qu'un utilisateur a dit à l'équipe projet, lors d'un PI Planning, durant la démonstration du produit.

Le Product Owner (PO) se tourne vers le Product Manager (PM), cherche un appui. Le PM se tourne vers les équipes de développement et les Business Analyst (BA). Personne, dans la chaîne, n'a de réponse. Chacun a pourtant fait sa part du travail, dans les règles de l'art.

Le problème visible

Sur ce grand projet de migration de système d'information, comme sur tant d'autres, le diagnostic qui tombe après une scène pareille est toujours le même : les consultants n'ont pas fait leur travail. Le PO ne maîtrise pas vraiment son rôle. Le PM pilote le processus, pas le produit. L'architecte technique tranche seul dans son coin.
Alors on change des têtes, on muscle l'équipe, on rajoute des points de contrôle qualité.

L'équipe de développement, elle, prend souvent le pire de la charge. On dit d'elle qu'elle code sans réfléchir, qu'elle se fiche du résultat, qu'elle avance sans jamais poser de questions. C'est injuste. Une équipe de développement fait exactement son métier quand elle code ce qui est écrit dans les user stories. Elle a le droit, et le devoir, de signaler une incohérence qu'elle repère. Elle n'a pas à interpréter le métier.
Si le résultat ne correspond pas au besoin réel, ce n'est pas elle qui a manqué à sa tâche, c'est que le métier était mal ou pas assez spécifié.

Le mythe a la vie dure : si le produit ne colle pas au métier, c'est que le prestataire n'était pas assez bon. Mais le vrai sujet est ailleurs. Si le PO, le PM et le client ne restent pas connectés, vraiment connectés, à l'outil qu'ils sont en train de construire ensemble, rien de ce qui suit ne peut fonctionner.

Le problème humain invisible

Sur ce type de projet de grosse transformation digitale, l'équipe de consultants compte souvent quinze à vingt personnes. Côté client, deux ou trois, rarement plus, et aucune n'a vraiment le temps ni le mandat de s'impliquer dans la construction. Le PO écrit ses user stories, anime ses ateliers, avance vite : il fait bien son métier de consultant.

Mais personne, côté client, ne peut dire avec autorité « ça, ce n'est pas comme ça que ça se passe chez nous » au moment où ça compte.

Ce genre de moment aurait dû être le signal d'alerte, dès la construction de l'équipe projet. Mais nul, côté client, n'avait l'autorité de trancher sur le fond. Alors on prend note, on promet un ajustement au sprint suivant, et le projet continue comme si de rien n'était. Jusqu'à ce que corriger coûte dix fois plus cher.

Le consultant, lui, fait ce qu'on lui demande de faire : avancer. Il prend les décisions que personne d'autre ne prend. Il arbitre des zones grises du métier qu'il découvre en même temps qu'il les documente. Il construit, avec toute la rigueur de son métier à lui, un produit que personne, côté client, n'a jamais vraiment validé sur le fond.

Personne ne l'a fait exprès. C'est juste que pendant des mois, tout le monde a confondu « le projet avance » avec « le projet va dans la bonne direction ».

Décryptage humain : la grille IDA©

Une grille de lecture, pas un jargon de plus. IDA, Incarnation, Désirabilité, Acceptabilité, est la boussole que j'utilise pour lire ce qui se joue humainement dans une transformation, toujours dans cet ordre : qui porte la vérité du projet, est-ce que ça donne envie, est-ce que c'est vivable.
Je m'en sers ici parce que ce qui a manqué sur ce projet n'est ni une compétence ni un processus. C'est un problème d'incarnation : personne, côté client, ne portait la vérité du métier.

Dans l'incarnation, celui qui compte n'est pas celui qu'on veut embarquer : c'est celui qui embarque, celui qui porte la vérité et la fait vivre au quotidien.

Sur un projet de transformation, ce porteur ne peut être que le client. Un consultant peut porter une méthode, un cadre, une exigence de qualité. Il ne peut pas porter la vérité du métier de quelqu'un d'autre, même après l'avoir longuement étudiée.

Quand le client cesse d'incarner son propre métier dans le projet, il ne délègue pas seulement des tâches : il délègue une vérité qu'il est seul à posséder.

La dette qu'on ne voit pas venir

Le Standish Group le documente depuis trente ans dans ses rapports CHAOS : le manque d'implication des parties prenantes métier est la première cause d'échec des projets IT, loin devant les problèmes techniques (environ 35 % contre 12 %, CHAOS 2020-2023). Et l'ampleur est connue : à peine un projet IT sur trois est jugé pleinement réussi. McKinsey le confirme sur un périmètre plus large. Sur 5 400 grands projets étudiés avec l'université d'Oxford, le dérapage n'est même pas d'abord budgétaire (45 % de dépassement) ni calendaire (7 %). Il est ailleurs, et c'est le plus grave : 56 % de valeur métier en moins que prévu. Autrement dit, le projet finit. Mais il ne livre pas ce dont le métier avait besoin.

Ce ne sont pas des accidents de parcours. C'est le prix d'une dette qui s'accumule tant que personne ne la regarde. Le client se rassure : « ça avance, l'équipe consultants est bonne, on n'a pas besoin de s'en mêler davantage. » Cette phrase, prononcée en comité de pilotage, est le signal du danger. Pas celui de la réussite.

Le secret

Le levier n'est pas d'ajouter un sachant côté client, un référent affecté à 20 % de son temps pour cocher la case gouvernance. Le sujet est plus large et plus exigeant : il faut des sachants métier à tous les niveaux du projet où une décision métier se prend, dans les ateliers, dans les comités de pilotage, dans les arbitrages hebdomadaires, avec le mandat de valider, de dire oui ou non.

Et il y a une ligne qu'on ne franchit jamais : un consultant ne tranche pas un choix métier à la place du client. Jamais. Ce n'est pas une question de compétence, aussi expérimenté soit-il. C'est une question de légitimité.

Laisser un prestataire trancher seul ce qui relève du métier du client, c'est une hérésie. Une dette. Un risque.

Ce que ça change

Ça change la manière de monter un projet, avant même le premier atelier. Ça veut dire réserver, dès le cadrage, le temps des bons sachants métier, pas seulement celui d'un sponsor qui signe des livrables qu'il n'a pas eu le temps de lire.

  • Ça veut dire accepter qu'un projet démarre un peu moins vite, le temps que les bonnes personnes internes soient identifiées, mobilisées et surtout légitimées à dire non.
  • Ça veut dire, aussi, qu'un bon consultant sait dire à son client : « je ne peux pas valider ça à votre place », et être entendu plutôt que contourné.

Conclusion

Un client ne peut pas déléguer la construction de son avenir à une équipe de consultants, aussi excellente soit-elle. Il peut lui confier l'exécution. Jamais la vérité de son métier. Les projets préparent l'avenir. On ne prépare pas son avenir avec la vérité de quelqu'un d'autre.

Et vous ?

Si on vous demandait aujourd'hui qui, côté métier, a le mandat réel de valider ce qui se construit, est-ce que vous pouvez répondre sans hésiter ? Si non, vous n'avez pas un problème de compétence consultant devant vous. Vous avez une dette de validation à traiter d'abord.

Une transformation ne se décrète pas.
Elle se porte.
Les sponsors, les dirigeants et les managers ont un rôle central dans cette dynamique : incarner le cap, rendre le futur désirable et sécuriser l'acceptabilité.

C'est ce travail d'incarnation et de sponsoring que j'aide à structurer auprès des COMEX, CODIR et équipes de transformation.

Parce que l'engagement ne se pilote pas à distance.
Si ce sujet fait écho à ce que vous traversez, il mérite d'être travaillé sérieusement.