Sortir d’une crise projet : comment récupérer un programme en dérive

Un programme ne “tombe” pas en crise d’un coup. Il glisse. Il se met à prendre du retard sans que personne ne veuille le nommer. Les comités se multiplient, les slides se polissent, les statuts deviennent des romans. On parle de “complexité”, de “dépendances”, de “montée en charge”, comme si la situation était un phénomène naturel. Puis un jour, le business pose la seule question qui compte : “qu’est-ce qu’on a vraiment, là, maintenant ?” Et la réponse est floue, parce que la gouvernance s’est habituée à raconter une trajectoire au lieu de prouver un delivery.

Dans ces moments-là, il y a deux options. Soit on continue le théâtre : on change le plan, on relance un audit, on ajoute un PMO, on “remobilise”. Soit on fait ce qui dérange : on met de la clarté, on recadre, on tranche, on accepte de perdre des batailles pour sauver la guerre. Récupérer un programme en dérive n’est pas une question de motivation. C’est une question de cadre, de scope, de gouvernance et de règles d’arrêt. Autrement dit : de décisions.

Re-cadrage : remettre le programme face à la réalité, pas face au storytelling

La première étape d’un redressement n’est pas de rassurer. C’est de faire tomber le vernis. Dans une crise projet, le problème n’est pas seulement le retard : c’est la perte de vérité commune. Chacun finit par avoir sa version du programme, son niveau de gravité, sa liste de causes. Le produit pense que l’IT complique. L’IT pense que le métier change d’avis. Les fournisseurs pensent que le client ne tranche pas. Et le client pense que les fournisseurs survendent. Quand tout le monde a raison, personne n’est responsable.

Le re-cadrage commence par une page, pas par un PowerPoint. Une page qui oblige à écrire l’essentiel, en langage business, sans jargon protecteur : l’objectif du programme en une phrase, la valeur attendue, les utilisateurs, la date cible, les critères de succès mesurables, et la liste courte des risques majeurs. Si cet exercice est impossible, c’est le signal le plus fiable : le programme n’est pas piloté, il est porté par inertie.

Ensuite, on rétablit une règle simple qui change la dynamique : ce qui n’est pas démontré n’existe pas. Les pourcentages d’avancement, les “on est à 80%”, les “c’est fini mais pas intégré”, les “ça marche sur l’environnement de recette”… tout cela devient secondaire. La preuve, c’est une fonctionnalité en production, utilisée, mesurable. En crise, la vérité n’est pas une intention : c’est un fait observable.

Scope : réduire pour livrer, plutôt que promettre pour survivre

Un programme en dérive a presque toujours un scope trop large, ou trop instable, ou les deux. L’illusion la plus coûteuse est celle du “tout, mais par étapes”. Dans la réalité, l’étape 1 mange l’énergie, l’étape 2 devient une dette, et l’étape 3 sert à justifier pourquoi on n’a pas fini. La dérive est souvent une accumulation de “petits plus” qui n’ont jamais été payés en budget, en délai, ou en ressources.

La récupération passe par une décision impopulaire : choisir un Minimum Viable Outcome. Pas un MVP marketing, mais une tranche de valeur minimale qui fait réellement avancer le business, sans dépendre d’un miracle organisationnel. On identifie ce qui est indispensable pour que le programme “existe” : un flux bout-en-bout, un périmètre utilisateur précis, un process stable, un niveau de qualité acceptable. Tout le reste n’est pas “abandonné” : il est replanifié, explicité, mis en backlog avec un coût et une date qui ne mentent pas.

Il faut aussi neutraliser une source majeure de dérive : les changements non arbitrés. Les modifications de périmètre doivent redevenir des décisions, pas des discussions. Chaque nouvelle demande doit porter son étiquette : “si on ajoute ceci, on retire quoi, on décale quoi, ou on finance quoi ?” Sans ce mécanisme, le scope n’est pas un périmètre, c’est une fuite.

Gouvernance : reconstruire une machine à trancher, pas une machine à constater

Dans les programmes en crise, la gouvernance ressemble souvent à un rituel. On se réunit, on écoute, on constate, on prend des “actions”, et on se revoit la semaine suivante avec les mêmes problèmes. Ce n’est pas une gouvernance : c’est un amortisseur émotionnel. Une gouvernance de redressement doit avoir une propriété rare : la capacité de décider vite.

Cela commence par une clarification brutale des responsabilités. Un programme ne se “co-pilote” pas dans le flou. Il doit avoir un propriétaire unique, visible, accountable, capable d’arbitrer les conflits de priorités et de porter les décisions. Le rôle d’un comité de crise n’est pas de produire une unanimité. C’est de sortir des décisions claires, écrites, datées, avec un responsable et un résultat attendu.

La gouvernance doit aussi changer sa métrique. En crise, on ne pilote plus par activité, on pilote par risque et par valeur livrée. Le tableau de bord doit devenir austère : ce qui est livré et adopté depuis la dernière revue, les risques top 5 qui peuvent stopper le programme, les décisions en attente, les dépendances bloquantes, et l’état de qualité (incidents, régressions, dette de tests, performance). Moins de chiffres, plus de signaux. Moins de “vert”, plus d’honnêteté.

Reprise du contrôle : remettre l’exécution au centre, et le planning à sa place

Le planning est souvent l’outil le plus toxique d’un programme en dérive. Non pas parce que planifier est inutile, mais parce qu’en crise le planning devient un objet politique : il doit “tenir”, donc on l’ajuste jusqu’à ce qu’il redevienne présentable. À la fin, plus personne n’y croit, mais tout le monde fait semblant, parce qu’admettre l’écart coûterait trop cher.

Pour récupérer, il faut inverser la relation : le planning ne dicte pas le delivery, il reflète le delivery. On revient à une mécanique d’exécution simple : un backlog priorisé, des incréments courts, une définition of done strictement appliquée, des démonstrations régulières, une gestion explicite des dépendances et des environnements. Le programme doit redevenir un flux de livraison, pas une narration.

Cette reprise du contrôle implique souvent une opération délicate : remettre à plat la chaîne de fabrication. En crise, les environnements sont instables, les tests sont tardifs, l’intégration est douloureuse, les données de recette sont mauvaises, et la mise en production est une épreuve. On ne récupère pas sans investir un minimum dans la capacité à livrer : industrialisation, CI/CD, automatisation de tests clés, outillage de déploiement, observabilité. Sinon, chaque release devient un événement, donc un risque, donc un frein.

Stopping rules : l’arme que personne n’ose sortir

La plupart des organisations n’échouent pas par manque de talent. Elles échouent par incapacité à s’arrêter. Un programme en crise survit souvent parce qu’il est trop gros pour mourir : trop de budget engagé, trop de promesses, trop d’ego. Alors on continue. On espère que “le prochain jalon” changera tout. Et plus on continue, plus il devient difficile d’admettre que la trajectoire est mauvaise.

Les stopping rules sont des règles d’arrêt explicites, définies à froid, qui protègent l’entreprise contre l’acharnement. Elles peuvent être simples : si, après X semaines, le programme ne démontre pas un flux bout-en-bout utilisable ; si la qualité ne se stabilise pas au-delà d’un seuil ; si la charge de correction dépasse la charge de construction ; si l’adoption réelle reste nulle malgré les livraisons ; si les dépendances critiques ne sont pas débloquées. Ces règles ne sont pas des menaces : ce sont des garde-fous.

L’objectif n’est pas de “tout arrêter”, mais d’éviter le pire : continuer à financer un programme qui ne produit pas de valeur, ou qui détruit le run en voulant produire du change. Paradoxalement, instaurer des stopping rules rassure : elles rendent la trajectoire pilotable, parce qu’elles disent clairement ce qui déclenche un pivot, une réduction de scope, un changement de fournisseur, ou une pause technique.

Réalignement : refaire un pacte de vérité entre IT, métiers et fournisseurs

Aucun redressement ne tient si les acteurs continuent de jouer à se protéger. Les métiers doivent accepter que certaines demandes attendront. L’IT doit accepter de montrer ses contraintes et ses dettes, sans les utiliser comme bouclier. Les fournisseurs doivent être mis face à des livrables vérifiables, pas à des promesses. Et la direction doit accepter que la récupération d’un programme a un coût : parfois un délai assumé, parfois un budget complémentaire, parfois une baisse de périmètre. Ce coût est toujours inférieur à celui d’une dérive prolongée, mais il doit être nommé.

Le point de bascule, c’est quand le programme cesse d’être un “projet” et redevient un produit livré, mesuré, amélioré. Quand les décisions sont écrites, quand la valeur est prouvée, quand les exceptions sont payées, quand les règles d’arrêt existent. À ce moment-là, la crise ne disparaît pas miraculeusement. Mais elle change de nature : elle devient un chantier pilotable, au lieu d’être un gouffre narratif.

Sortir d’une crise projet, ce n’est pas sauver la face. C’est sauver la capacité de l’entreprise à livrer. Et ça commence toujours pareil : en remplaçant les buzzwords par des choix, et les espoirs par des règles.