Passer au contenu
Aperçus

Quand interrompre un projet de plateforme en difficulté (et l'expliquer)

Chaque DPI a déjà vu un projet de plateforme en difficulté avancer péniblement bien après l'apparition des signaux d'alerte. Le plus difficile n'est presque jamais la technologie. C'est de savoir quand l'arrêter — et comment expliquer cette décision pour qu'elle traduise du leadership, et non un échec.

 
Projet de plateforme défaillante - quand un DSI doit arrêter, pivoter ou persévérer

Pourquoi un projet de plateforme en difficulté se poursuit

Un projet de plateforme en difficulté échoue rarement bruyamment. Il ne s'effondre pas en une seule journée dramatique. Il dérive plutôt. Un jalon glisse ici, un changement de portée survient là, et un contournement imposé par le fournisseur devient discrètement permanent. Comme chaque étape paraît mineure, personne ne qualifie le projet d'échec. Pourtant, le risque continue de s'accumuler en dessous.

Plusieurs forces maintiennent un projet en difficulté en vie. Premièrement, le coût irrécupérable pèse lourdement — les dirigeants qui ont déjà dépensé deux millions de dollars hésitent à le “ gâcher ” en arrêtant. Deuxièmement, l'optimisme prend le dessus, car le prochain sprint promet toujours d'arranger les choses. Troisièmement, la politique s'en mêle, étant donné que le dirigeant qui a défendu la plateforme ne veut pas avoir tort publiquement.

Les chercheurs appellent ce phénomène l'escalade de l'engagement, et ils l'étudient depuis des décennies. L'analyse classique de la Harvard Business Review sur les raisons pour lesquelles les managers ont du mal à couper la proie dans un projet en difficulté décrit encore avec précision la plupart des initiatives bloquées. Par conséquent, la décision d'arrêter n'intervient presque jamais d'elle-même. Quelqu'un doit la forcer — et ce quelqu'un est généralement le DSI.

 

Les signaux d'alerte d'un projet de plateforme en difficulté

Alors, comment distinguer un projet ordinairement difficile d'un projet de plateforme en difficulté? La différence apparaît dans les tendances, pas dans les événements isolés. Plus précisément, surveillez ces cinq signaux.

  • La plateforme combat le cas d'usage. Votre équipe passe plus de temps à contourner le produit qu'à le configurer. Chaque exigence semble nécessiter une extension sur mesure.
  • Les échéanciers se réinitialisent sans nouvelle portée. La date limite recule deux fois, alors que les exigences n'ont pas augmenté. Cet écart, c'est du risque non géré qui remonte à la surface.
  • La réponse du vendeur est toujours le module suivant. Chaque problème se heurte à une autre licence ou à un module complémentaire, plutôt qu'à une correction de ce que vous avez déjà acheté.
  • La sécurité ou la conformité bloque sans cesse la mise en ligne. Pour un projet d'IA ou de recherche d'entreprise en particulier, un modèle de permissions non résolu n'est pas un détail. C'est un signal d'arrêt.
  • Plus personne ne sait énoncer le résultat d'affaires. L'équipe parle de fonctionnalités et de billets, et non du résultat de productivité ou de revenus que le projet devait livrer.

Un seul signal est normal dans toute initiative complexe. Cependant, trois ou plus en même temps signifient que le risque du projet augmente plus rapidement que sa progression. C'est le moment d'agir, pas le moment d'attendre le prochain rapport d'avancement.

 

Interrompre, réorienter ou poursuivre : un cadre décisionnel

Arrêter n'est pas la seule solution de rechange à la poursuite. En pratique, une initiative en difficulté offre généralement trois voies honnêtes, et un DPI devrait les nommer toutes les trois à voix haute.

  1. Poursuivre. Ne choisissez cette voie que lorsque la plateforme elle-même est solide et que le problème relève de l'exécution — un enjeu d'équipe, de processus ou de portée que l'on peut corriger. Ici, la solution est l'attention de la direction, pas une nouvelle plateforme.
  2. Réorienter. Conservez ce qui fonctionne et changez ce qui ne fonctionne pas. Vous pourriez redéfinir la portée vers une première version plus modeste, remplacer un composant ou modifier l'approche d'intégration. La réorientation préserve l'investissement réel tout en réduisant le risque.
  3. Interrompre. Arrêtez délibérément la voie actuelle, avant que plus de budget ne se transforme en plus de risque. Interrompre n'est pas abandonner. Au contraire, cela met fin à une approche pour qu'une meilleure puisse commencer.

Pour choisir entre ces voies, posez une seule question. Si nous commencions aujourd'hui, en sachant ce que nous savons maintenant, achèterions-nous encore cette plateforme? Lorsque la réponse honnête est non, vous ne poursuivez plus un projet difficile — vous financez un projet de plateforme en difficulté. Dans ce cas, réorientez ou interrompez plutôt.

 

Comment le risque lié à la plateforme s'aggrave quand vous attendez

Le délai n'est jamais neutre. Chaque mois où un projet en difficulté se poursuit, trois types de risque augmentent en même temps.

  • Risque financier. Plus de budget est engagé, et une part croissante devient irrécupérable. Les études sur les grands projets informatiques constatent systématiquement qu'ils dépassent les budgets et livrent moins de valeur à mesure qu'ils s'étirent.
  • Risque technique. Les contournements temporaires se figent en architecture permanente. Plus ils durent, plus ils coûtent cher à défaire.
  • Risque organisationnel. Vos meilleurs ingénieurs s'épuisent sur un travail qu'ils savent en privé voué à l'échec. Pendant ce temps, votre crédibilité auprès du conseil s'érode à chaque glissement silencieux.

Les preuves ici sont bien documentées. La recherche de McKinsey sur Grands projets informatiques montre à quel point ils ont tendance à dériver. De la même manière, les coûts cachés d'une mise en œuvre échouée apparaissent rarement sur la ligne budgétaire d'origine.

C'est l'argument central pour agir tôt. Le coût d'un arrêt est visible et limité aujourd'hui. À l'inverse, le coût de l'attente est invisible et cumulatif. Par conséquent, une décision reportée n'est pas une décision évitée. C'est simplement une version plus coûteuse de la même décision.

 

Comment parler à votre conseil de l'arrêt du projet

La décision ne représente que la moitié du travail. La manière dont vous communiquez la fin d'un projet de plateforme en difficulté détermine si le conseil y voit un leadership rigoureux ou un défaut de gestion. Utilisez ces cinq leviers.

  1. Commencez par la décision tournée vers l'avant, pas par l'autopsie. Ouvrez sur la voie la plus intelligente, pas sur la liste de ce qui a mal tourné. Après tout, le conseil finance l'avenir, pas le passé.
  2. Quantifiez le risque de continuer. Présentez le coût projeté et l'exposition d'une poursuite, côte à côte avec le coût d'un arrêt. Rendez visible l'option la plus coûteuse.
  3. Apportez l'option de rechange entièrement définie. Ne présentez jamais un arrêt sans une prochaine étape. Au contraire, arrivez avec le plan de réorientation ou l'approche de remplacement déjà cadré et chiffré.
  4. Assumez sans dramatiser. Énoncez clairement ce que l'équipe a appris et ce qui a changé. C'est l'assurance, et non les excuses, qui rassure un conseil.
  5. Protégez l'équipe. Présentez-le comme une décision de plateforme et d'adéquation, et non comme un blâme individuel. Vous voulez vos meilleurs talents mobilisés pour la prochaine voie, pas sur la défensive à propos de la précédente.

Surtout, présentez au conseil une recommandation, pas un dilemme. Les administrateurs respectent un DPI qui a déjà fait l'analyse et leur demande de confirmer une décision claire. En somme, vous n'annoncez pas une mauvaise nouvelle. Vous démontrez votre maîtrise.

 

Changez de perspective : arrêter un projet de plateforme en difficulté, c'est gérer le risque

Le mot “ échec ” est le plus dommageable ici, alors reformulez-le délibérément. Choisir d'arrêter un projet de plateforme défaillant n'est pas un échec de projet. Au contraire, c'est la gestion des risques qui fonctionne exactement comme prévu.

Considérez le comportement de chaque autre partie de l'entreprise. Un gestionnaire de portefeuille sort d'une position perdante. Un assureur plafonne son exposition. Un conseil d'administration retire une ligne de produits sous-performante. Rien de tout cela ne compte comme un échec, tout cela compte comme de la discipline. La gouvernance informatique mérite le même traitement. En effet, le guide de gouvernance des projets d'organismes tels que Project Management Institute considère un arrêt délibéré et fondé sur des preuves comme un signe de surveillance mature.

Le véritable échec est tout autre. C'est laisser un projet condamné se poursuivre en silence pendant une autre année parce que personne ne voulait d'une conversation inconfortable. À l'inverse, le DPI qui interrompt tôt protège du même coup le budget, les talents et la crédibilité auprès du conseil.

 

Comment Sengo aide les DPI à trancher

Trancher est bien plus facile avec une partie neutre dans la pièce. Sengo offre aux DPI une lecture honnête et indépendante des fournisseurs sur la question de savoir si un projet de plateforme en difficulté doit poursuivre, se réorienter ou s'arrêter.

Nous sommes un partenaire d'implémentation officiel des principales plateformes CMS, DXP et d'activation de l'IA — et pourtant, nous n'en vendons jamais une comme solution par défaut. Cette indépendance est primordiale. Grâce à elle, nous pouvons évaluer votre plateforme selon ses mérites, modéliser le risque de chaque voie et vous aider à évaluer votre pile de plateformes sans qu'un fournisseur n'influence les choses. Pour le travail spécifique en IA et en recherche d'entreprise, notre Coveo l'expertise signifie que nous savons précisément où ces projets ont tendance à stagner.

Nous avons accompagné des entreprises telles que iA Groupe financier, le Cirque du Soleil et LCI Éducation dans des décisions stratégiques de plateformes, en français et en anglais. Alors si un projet de plateforme défaillant vous empêche de dormir, rappelez-vous que la décision la plus coûteuse est d'attendre. Examinons cela ensemble et trouvons le chemin le plus court pour revenir sur des bases solides.

 

Parlez à Sengo de votre projet de plateforme

Sources et références

  1. Savoir quand arrêter — Harvard Business Reviewhbr.org
  2. Mener à bien des projets informatiques d'envergure dans les délais, le budget et la valeur – McKinseymckinsey.com
  3. Pulse of the Profession — Project Management Institutepmi.org
Sengo Robot Nikko