Gestion de projets technologiques : on vous juge sur l'écart, pas sur la livraison
Un programme technologique est jugé comme une valeur cotée un jour de résultats : sur l'écart entre le résultat et l'attente, jamais sur le résultat en soi. La plupart des business cases perdent cet examen avant même que le projet ne commence.
Chaque saison de résultats, quelqu'un demande pourquoi l'action d'une entreprise a chuté après de bons chiffres, et chaque comité de pilotage rejoue la même scène : le projet est livré, la démonstration fonctionne, le tableau de bord est au vert, et la salle reste froide. Aucun des deux publics n'est irrationnel. Chacun corrige une copie différente. Le verdict ne porte jamais sur le résultat ; il porte sur l'écart entre le résultat et l'attente fixée en amont. La gestion des attentes dans un projet technologique n'est pas une compétence relationnelle greffée sur la livraison. C'est le dénominateur par lequel toute livraison est divisée, et la plupart des programmes laissent ce dénominateur être fixé par le document le plus optimiste qu'ils produiront jamais : le dossier de financement.
Les marchés rendent ce mécanisme visible parce qu'ils le tarifient chaque jour. Un cours de bourse est une prévision, et le jour de la publication, cette prévision contient déjà une estimation fine de l'annonce à venir. C'est pourquoi les résultats sont jugés à l'aune du consensus des analystes et des prévisions communiquées par l'entreprise, plutôt que dans l'absolu : une société aux bénéfices en repli peut progresser après avoir franchi une barre pessimiste, tandis qu'une société aux bénéfices en hausse peut chuter après avoir manqué une barre optimiste. Chaque publication de résultats voit une valeur bénéficiaire vendue et une valeur déficitaire achetée, et chaque fois les commentateurs parlent de sentiment de marché. C'est de l'arithmétique. Le chiffre publié est le numérateur. Le dénominateur a été fixé des mois plus tôt, par quelqu'un d'autre, et le mouvement du cours n'est que le résultat de la division.
Votre programme a lui aussi un cours de bourse. Simplement, il est illiquide, et il se négocie en comité de pilotage. Le consensus, c'est ce que le comité a retenu du business case. La prévision, c'est votre feuille de route. La crédibilité, c'est le multiple : la part de votre prochaine prévision que l'on est encore prêt à croire.
Pourquoi les projets informatiques réussis sont-ils perçus comme des échecs ?
Parce que l'attente a été fixée au moment de l'ignorance maximale et de la vente la plus assumée. Un business case s'écrit avant le lancement du projet, par des personnes qui ont besoin de le faire approuver, en concurrence avec d'autres dossiers eux aussi survendus. Le chiffre retenu est choisi pour sa force de persuasion, pas pour sa justesse, puis il se fige en consensus : c'est lui qui servira de référence à la livraison. Dix-huit mois plus tard, une équipe livre une migration de plateforme qui fonctionne, dans un délai qui était défendable, et découvre qu'elle est jugée à l'aune de la version du projet qui n'a jamais existé ailleurs que dans le dossier d'approbation. Livrer 3 % d'amélioration quand on en avait promis 5, c'est un échec, quoi qu'en dise le retour d'expérience.
Ce que cela permet de prédire : l'organisation la mieux notée n'est pas celle qui livre le plus. C'est celle dont les hypothèses de départ étaient les plus honnêtes. C'est inconfortable, parce que la plupart des processus de financement pénalisent activement les hypothèses honnêtes. Si votre gouvernance ne finance que les projets qui promettent des retours spectaculaires, vous n'avez pas relevé le niveau d'exigence. Vous avez seulement garanti que chaque projet mentira au départ ou échouera à l'arrivée.
Quand faut-il arrêter un programme technologique qui échoue ?
Plus tôt que vous ne le souhaiteriez, et plus franchement. Les directions redoutent le moment de la dépréciation : l'aveu formel que la refonte de plateforme prévue sur deux ans ne rapportera pas ce que la feuille de route promettait. Mais les données de marché sur les dépréciations comptables disent le contraire. Les études sur les annonces de dépréciation de survaleur montrent des rendements anormaux positifs dans les six à douze mois qui suivent, d'autant plus marqués que la dépréciation est importante. Ce que j'en retiens : une perte que le marché ou l'organisation soupçonne déjà coûte peu cher à reconnaître, parce que l'aveu ne crée pas la perte. Il libère l'incertitude qui pesait déjà sur vous pendant que vous la niiez.
La version organisationnelle est tout aussi exacte. Le temps que la direction débatte de l'arrêt d'un programme qui échoue, l'organisation l'a généralement déjà déprécié en interne : les ingénieurs contournent le système, les sponsors désertent les comités, les équipes dépendantes découplent discrètement leurs propres plans. L'arrêt officiel ne fait que confirmer une valorisation que les couloirs avaient déjà actée des mois plus tôt. Ce qui coûte vraiment, c'est le goutte-à-goutte : trimestre après trimestre d'un statut « orange, en voie de rétablissement » qui maintient tout le monde dans l'incertitude tarifée. Si je me trompe sur ce point, cela devrait se traduire par des organisations qui privilégient l'hémorragie lente et conservent davantage de confiance et de meilleurs talents que celles qui reconnaissent franchement leurs échecs. Je n'ai jamais observé ce cas de figure.
L'adoption imposée est-elle une vraie adoption ?
Le piège le plus discret se niche dans les chiffres apparemment bons. Un chiffre d'affaires peut croître parce que les clients veulent davantage du produit, ou parce qu'on leur facture plus cher le même produit : les travaux de McKinsey sur le pilotage de la croissance du chiffre d'affaires décrivent des entreprises qui, en période d'inflation, maintiennent leurs ventes nettes à flot par de fortes hausses de prix alors même que les volumes stagnent ou reculent. Les deux se ressemblent en haut du compte de résultat et signifient pourtant l'inverse l'un de l'autre pour l'avenir.
Les programmes technologiques produisent la même illusion avec les taux d'usage. Un assistant IA déployé par obligation affichera des courbes d'adoption que n'importe quel chef de produit envierait, pour la simple raison que l'alternative était de l'éteindre. L'usage décrété est le cousin de la croissance tirée par les prix : le chiffre grimpe pendant que la réalité de la demande reste cachée, et elle refait surface au moment du renouvellement, en même temps que la remise à plat des attentes. Pour savoir si votre programme d'IA s'accumule ou se contente de suivre le mouvement, ne demandez pas combien de personnes l'ont utilisé. Demandez ce qu'elles ont fait quand elles avaient le choix.
Comment gérer les attentes dans un projet technologique ?
Comme une entreprise cotée qui souhaite le rester. Écrivez l'hypothèse de départ avant le lancement du projet : la version précise, datée et réfutable de ce que l'investissement doit rapporter, clairement séparée de l'objectif d'entraînement que vous utilisez pour mobiliser l'équipe. C'est en grande partie ce que revient à faire l'évaluation de la maturité IA avant tout lancement de projet : fixer le consensus tant que vous pouvez encore vous permettre qu'il soit honnête. Traitez ensuite la feuille de route comme une prévision, puisque c'est déjà ainsi que vos parties prenantes la lisent : révisez-la dès que votre estimation bouge, pas au comité où l'échec devient impossible à nier. Et rendez compte de l'écart ensuite, publiquement. Cette discipline, hypothèses écrites et écarts rendus publics, c'est ce que notre accompagnement en stratégie technologique s'efforce avant tout de laisser derrière lui chez un client, parce qu'un résultat sans hypothèse de départ n'est qu'un chiffre, et qu'un chiffre isolé n'apprend rien à personne.
Reste l'asymétrie que personne ne tarife. Un résultat au-dessus des attentes vous achète un bon comité de pilotage. Un résultat en dessous vous coûte ce comité, et quelque chose de bien plus long à reconstruire : la disposition de chacun, dans la salle, à prendre votre prochaine prévision au pied de la lettre. Les attentes sont le seul actif dont un directeur de programme contrôle entièrement l'émission, et le plus systématiquement sur-émis. Fixez la barre bas, rendez compte avec exactitude, et laissez l'écart faire le travail.
Questions fréquentes
Pourquoi une action baisse-t-elle après de bons résultats ?
Parce que les marchés jugent les résultats à l'aune du consensus des analystes et des prévisions déjà intégrées dans le cours, jamais dans l'absolu. Une croissance des bénéfices inférieure au niveau attendu se lit comme un échec, et un abaissement des prévisions peut effacer un résultat pourtant historique. Le même mécanisme opère dans les comités de pilotage : le business case fixe le consensus à l'aune duquel un projet est jugé.
Qu'est-ce qu'un écart d'attentes dans la conduite de projet ?
La différence entre ce qu'un programme technologique livre réellement et ce que son business case approuvé, ses plans et ses points d'avancement ont laissé espérer aux parties prenantes. Les verdicts suivent cet écart plutôt que le résultat absolu, ce qui explique qu'un projet survendu mais correctement exécuté puisse tout de même être jugé comme un échec.
Un business case pour un projet d'IA doit-il être prudent ou ambitieux ?
Séparez les deux fonctions. Financez le projet sur une prévision prudente et réfutable, que vous accepteriez de voir servir de référence, et mobilisez l'équipe avec un objectif d'entraînement explicitement distinct du chiffre de financement. Confondre les deux revient à faire juger chaque futur comité à l'aune de votre jour le plus optimiste.
À lire aussi
- La croissance IA de votre cloud est en partie un aller-retour financier. Passez au crible avant de signer
- Mégadeals de l'IA : l'annonce n'est pas le contrat
- Le chiffre sans repère : les capteurs de glucose transforment les objets connectés fitness en machines à anxiété
- Data & Strategy
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.