Programme IT en dérive : huit décisions à prendre avant d’ajouter un nouveau comité

Un programme IT ne dérape presque jamais en une seule fois. Il se dégrade par petites couches : une décision repoussée, un fournisseur qui attend, un jalon déplacé « provisoirement », une dette technique qui devient structurelle, un comité supplémentaire créé pour compenser un manque d’arbitrage. Au bout de quelques semaines, l’organisation travaille beaucoup mais ne réduit plus réellement le risque.

Dans cette situation, la mauvaise réaction consiste à ajouter immédiatement du reporting. Le bon réflexe est de remettre le programme sous décision. Un directeur de programme ou un DSI de transition doit d’abord rétablir une chaîne simple : identifier le problème, décider qui tranche, fixer une échéance et vérifier l’effet de la décision. Tant que cette mécanique n’est pas revenue, les outils de pilotage donnent surtout l’illusion du contrôle.

1. Nommer les trois risques qui peuvent réellement arrêter le programme

Une liste de quarante risques n’aide pas un comité de direction. Il faut isoler ceux qui peuvent provoquer un arrêt, une perte financière significative, une exposition réglementaire, une rupture de service ou une dépendance impossible à absorber. Ce tri oblige à distinguer les irritants des menaces réelles.

Le premier travail de reprise consiste donc à choisir trois risques maximum à porter au niveau exécutif. Pour chacun, il faut un propriétaire, une décision attendue et une date. Cette discipline réduit immédiatement le bruit et redonne de la lisibilité.

2. Réouvrir les décisions restées « en attente »

Les programmes en difficulté accumulent des décisions fantômes : personne n’a vraiment dit non, mais personne n’a dit oui. Architecture cible, périmètre fonctionnel, fournisseur, budget, responsabilités, calendrier : ces sujets restent ouverts et contaminent ensuite toutes les équipes.

Il faut les remettre sur la table avec une règle simple : une décision qui n’est pas prise a elle aussi un coût. Le rôle du pilotage est de rendre ce coût visible. Si l’entreprise accepte de différer, elle doit accepter explicitement l’effet sur le planning, le budget ou le risque.

3. Redéfinir le prochain jalon en preuve observable

« Finaliser la migration » ou « sécuriser le déploiement » ne sont pas des jalons suffisamment précis. Un jalon de reprise doit produire une preuve : un environnement testé, un lot de données réconcilié, un processus métier exécuté de bout en bout, un plan de retour arrière validé ou une décision d’architecture signée.

Plus la situation est tendue, plus le prochain jalon doit être proche et vérifiable. On ne reprend pas le contrôle avec une promesse à six mois. On le reprend avec une preuve dans les deux ou trois prochaines semaines.

4. Séparer les problèmes de gouvernance des problèmes techniques

Une équipe peut être techniquement compétente et pourtant incapable d’avancer si personne ne tranche. À l’inverse, une gouvernance claire ne compense pas une architecture irréaliste. Il faut donc séparer les deux diagnostics.

D’un côté : quelles décisions, responsabilités et interfaces sont floues ? De l’autre : quelles limites techniques, dettes ou dépendances rendent le plan actuel impossible ? Cette séparation évite de demander aux équipes techniques de résoudre des problèmes politiques ou organisationnels qu’elles ne peuvent pas régler.

5. Requalifier les fournisseurs critiques

Lorsqu’un programme dérive, la relation fournisseur devient souvent émotionnelle : on accuse, on menace, on renégocie. Cela ne suffit pas. Il faut revenir au contrat réel, aux engagements, aux livrables, aux dépendances et aux capacités disponibles.

Pour chaque fournisseur critique, trois questions suffisent pour commencer : que doit-il livrer dans les trente prochains jours ? De quoi dépend-il côté client ? Que se passe-t-il s’il n’y arrive pas ? Cette approche remet la discussion sur des faits et permet de décider rapidement entre soutien, renforcement, renégociation ou remplacement.

6. Réduire le reporting à ce qui déclenche une décision

Un bon tableau de bord de crise ne doit pas raconter tout le programme. Il doit permettre de décider. Quelques indicateurs suffisent : jalons critiques, budget engagé, incidents bloquants, dépendances externes, qualité mesurée et décisions en attente.

Chaque indicateur doit être relié à une action. Si un chiffre ne change aucune décision, il ne mérite probablement pas sa place dans le cockpit de reprise.

7. Clarifier le mandat du responsable de reprise

Nommer un manager de transition ou un directeur de programme sans mandat explicite ne change rien. Peut-il re-prioriser ? Peut-il arbitrer entre directions ? Peut-il challenger un fournisseur ? Peut-il proposer l’arrêt d’un lot ? Peut-il engager une dépense dans une enveloppe définie ?

Ces réponses doivent être claires dès le départ. Un responsable qui doit demander l’autorisation pour chaque correction urgente devient un simple coordinateur. Or une reprise exige une capacité réelle à décider et à faire appliquer les décisions.

8. Fixer les critères de sortie de crise

Un programme ne doit pas rester éternellement en mode crise. Il faut définir les conditions de retour à une gouvernance normale : stabilité des jalons, incidents sous contrôle, décisions critiques closes, responsabilité transférable, trajectoire budgétaire crédible et équipe capable de poursuivre sans dispositif exceptionnel.

Cette dernière étape est essentielle. Une mission de transition réussie ne se mesure pas au nombre de réunions tenues ni au nombre de problèmes absorbés. Elle se mesure à la capacité de rendre le programme à nouveau gouvernable par l’organisation elle-même.

La reprise d’un programme IT commence donc rarement par un nouvel outil. Elle commence par des décisions plus courtes, des preuves plus proches et des responsabilités plus nettes. C’est ce qui transforme une urgence en trajectoire maîtrisable.

Pour auditer ou reprendre un programme SI en difficulté : échanger avec GDL T&C.

#ManagementDeTransition #DSI #GouvernanceIT #TransformationDigitale