Le programme n’est pas bloqué sur un bug. Il est bloqué sur une question que personne ne tranche
Quand un groupe nous appelle, les symptômes sont toujours les mêmes. Le déploiement s’est arrêté après la deuxième entité. Deux filiales sont en production et font tourner discrètement des tableurs en parallèle. Une troisième a refusé deux fois une date de bascule sans dire pourquoi.
Le comité de pilotage cherche en général un coupable technique, parce qu’un coupable technique est une réponse confortable. Ce n’est presque jamais la bonne. Ce qui s’est passé, c’est qu’une décision qui appartenait au comité de direction est descendue dans un atelier de paramétrage, où personne n’avait l’autorité pour la trancher. Elle a donc été tranchée par défaut, et ce défaut est aujourd’hui en production.
Un sauvetage qui ne répare que du code vous rendra le même blocage dans six mois, avec un coût déjà engagé plus lourd. Le premier livrable n’est donc pas un correctif. C’est un état écrit de ce qui bloque réellement, et de qui est propriétaire de chaque décision bloquante.
La majorité de ce que vous avez payé mérite d’être gardée
C’est ce qui surprend le plus, et c’est la raison pour laquelle nous ne commençons pas par proposer une réimplémentation. Dans la plupart des programmes à l’arrêt, l’essentiel de ce qui a été construit est sain. Le problème, c’est que personne dans la salle ne peut aujourd’hui dire quelles parties, et cette incertitude est exactement ce qui fige tout.
Nous auditons donc ce qui tourne réellement dans chaque entité, pas ce que la documentation prétend, et nous trions en trois piles : ce qui marche et reste, ce qui rustine un process jamais défini, et ce qui n’aurait jamais dû être construit.
Repartir de zéro est parfois la bonne réponse. C’est beaucoup plus souvent la réponse de celui qui veut le contrat suivant. Nous vous dirons dans lequel des deux cas vous êtes, et nous vous le dirons par écrit.
Pourquoi ça casse à la deuxième entité et pas à la première
Presque tous les déploiements multi-entités qui s’arrêtent s’arrêtent au même endroit. L’entité une passe en production et tout le monde crie victoire, parce que l’entité une est celle sur laquelle la conception a été faite et que la conception lui va parfaitement.
L’entité deux est là où les hypothèses sont testées. On découvre que le même mot désignait deux choses. On découvre qu’une filiale valide à un autre moment du flux. On découvre que le plan comptable était harmonisé sur le papier et pas dans les faits.
Ce ne sont pas des anomalies. Ce sont des différences non arbitrées, découvertes tard, au pire moment, par des gens qui n’ont pas le mandat pour les résoudre. Un sauvetage qui ne fait pas remonter cet arbitrage au niveau où il appartient n’est qu’un report.
Ce que vous obtenez, et ce que vous pouvez présenter en comité
Un sauvetage doit survivre au comité de pilotage, donc le livrable est fait pour cette salle, pas pour un backlog technique.
Vous obtenez un audit de ce qui tourne dans chaque entité, un verdict sur ce qui est récupérable et ce qui ne l’est pas, la liste des décisions à prendre et par qui, et un plan par phases avec des points où vous pouvez légitimement vous arrêter et réévaluer, plutôt qu’un redémarrage unique en tout ou rien.
Vous obtenez aussi la version inconfortable. Si le programme n’est pas récupérable dans ses termes actuels, nous le disons tôt, tant qu’il reste un budget pour agir.
Nous travaillons avec l’intégrateur qui l’a construit
Il y a en général un intégrateur en place, et la relation est en général tendue. Le remplacer n’est pas automatiquement la solution, et ça coûte souvent une année de contexte que personne n’a budgétée pour la reconstruire.
On nous fait fréquemment intervenir pour arbitrer, pas pour évincer : nommer les décisions que personne n’arrive à trancher, et donner aux deux parties une lecture commune de ce qui est réellement vrai du système.
Ce que nous ne ferons pas, c’est livrer de la personnalisation cosmétique pour acheter la paix. C’est comme ça que le programme en est arrivé là.
