Piège 10 - La mise en production

Préparer le mariage, pas la vie à deux

Quiconque a organisé un mariage connaît ce sentiment. Dix-huit mois de décisions : le lieu, le menu, les fleurs, l’orchestre. Un plan de table redessiné onze fois pour que deux oncles ne partagent jamais la même table. Un déroulé de la journée, à la minute près. Toute une industrie est là pour vous aider : wedding planners, checklists, applications, dîners de répétition.

Puis le jour arrive, et il est parfait. Tout le monde pleure au bon moment. Les photos sont magnifiques. Les derniers invités partent à quatre heures du matin.

Et le lundi, la vraie vie commence. À qui le tour de cuisiner ? Quel compte bancaire paie le loyer ? Où passe-t-on Noël ? Personne n’a écrit ce plan-là. Personne ne l’a répété. Il y a des wedding planners partout ; je n’ai jamais rencontré de planificateur de vie à deux.

Le mariage dure une journée. La vie à deux, c’est tout ce qui vient après. Les grands programmes font exactement la même erreur, avec des budgets bien plus importants.

Le programme qui a réussi, et qui a quand même échoué

Chaque programme a son grand jour : la mise en production. Pendant deux ou trois ans, tout converge vers elle. Le plan, le budget, le comité de pilotage, les tableaux de bord, et même les objectifs et les primes des gens. Le week-end de bascule est répété comme une cérémonie. Quand ça marche, il y a un gâteau, un e-mail de remerciement du PDG et une diapositive qui dit « livré à temps ».

Puis l’équipe programme passe au programme suivant. Et discrètement, dans les mois qui suivent, l’histoire change. Les utilisateurs gardent leurs vieux tableurs « juste pour le moment ». L’ancien système tourne toujours, parce qu’une équipe en a encore besoin. L’équipe d’exploitation apprend le nouveau système à travers ses incidents. Le business case promettait des économies, un onboarding plus rapide, des clients plus satisfaits, et personne ne vérifie jamais si tout cela est arrivé.

Officiellement, le programme est un succès. Il a été livré. En réalité, l’organisation a payé pour une transformation et a obtenu un nouveau système qui tourne à côté de l’ancienne façon de travailler.

C’est cela, le piège de la mise en production : traiter la livraison comme la ligne d’arrivée, alors qu’elle n’est que le moment où la valeur peut commencer.

Les dix visages du piège

En 25 ans, je l’ai vu prendre dix formes, en trois familles : avant le grand jour, le jour J, et après la fête. La plupart des programmes qui ont « réussi » sans rien changer en présentent au moins la moitié.

Avant le grand jour

La mise en production comme ligne d’arrivée. La définition de « terminé » du programme, son budget et ses critères de succès s’arrêtent tous à la mise en production. Tout ce qui vient après appartient au « métier » ou au « run », c’est-à-dire à personne en particulier.
Les utilisateurs le découvrent en semaine de formation. Les vrais utilisateurs voient le système pour la première fois quelques semaines avant la mise en production, dans une salle de cours, avec des données de démonstration. Leurs retours arrivent quand plus rien ne peut changer. La conduite du changement se réduit à un plan de communication.
L’exploitation, pas invitée. L’équipe de run découvre le système à la passation : pas de runbooks, une supervision ajoutée à la dernière minute, un planning d’astreinte monté en un week-end. Ils en seront responsables pendant dix ans ; ils l’ont rencontré vendredi.

Le jour J

La bascule big bang. Tous les utilisateurs, toutes les fonctionnalités, toutes les données, le même week-end. Le pari est que tout fonctionne d’un coup, parce que le plan n’a laissé de place à rien d’autre.
Pas de retour possible. Il y a un plan pour basculer, et aucun plan répété pour revenir en arrière. Quand le premier problème sérieux apparaît le lundi matin, la seule option est de corriger en avançant, sous pression, en production.
L’équipe part avec les invités. L’équipe programme est dissoute, réaffectée ou en fin de contrat la semaine qui suit la mise en production. Les personnes qui comprennent pourquoi le système fonctionne comme il fonctionne sont parties juste au moment où les questions commencent.

Après la fête

Des bénéfices que personne ne mesure. Le business case a été écrit pour obtenir le financement, puis classé. Personne n’a pris de mesure de référence avant le démarrage, donc personne ne peut dire ce qui a changé après.
L’ancien système zombie. L’ancien système devait être éteint « trois mois après la mise en production ». Des années plus tard, il tourne encore pour un rapport, une équipe, un cas particulier, et l’organisation paie pour les deux.
Les contournements deviennent le processus. Les utilisateurs contournent ce qui ne leur convient pas : un export vers un tableur, une boîte mail partagée, une étape manuelle. Bientôt, le vrai processus vit en dehors du système, et personne ne l’a conçu.
La DSI possède le programme, personne ne possède le résultat. L’attention du sponsor est passée à autre chose le lendemain de la fête. Le système a un propriétaire ; le résultat pour lequel il a été construit n’en a pas.

Le lendemain matin

Si vous avez lu Le piège de la planification, vous avez rencontré le chiffre qui donne à réfléchir de Bent Flyvbjerg : sur des milliers de grands projets, un seul sur deux cents a été livré dans le budget, dans les délais, et avec les bénéfices promis. L’essentiel de cette série a porté sur les deux premiers. Cet épisode porte sur le troisième, celui que presque personne ne vérifie.

Et il est vraiment rarement vérifié. Dans son Pulse of the Profession de 2016, le PMI indiquait qu’une large majorité des organisations, plus de quatre sur cinq, manquaient de maturité en matière de réalisation des bénéfices. Les programmes mesurent ce qu’ils dépensent à l’euro près, et ce qu’ils rapportent presque pas du tout.

Les incitations s’arrêtent à l’autel. Le budget, l’équipe, le comité de pilotage et les critères de succès s’arrêtent tous à la mise en production. Les bénéfices arrivent six, douze, vingt-quatre mois plus tard, quand le programme n’existe plus pour les récolter. Ce que personne ne possède, personne ne le livre.

Le creux que personne n’a prévu. Après presque chaque mise en production, la performance se dégrade avant de s’améliorer. Les utilisateurs sont plus lents, le support est submergé, les petits défauts s’accumulent. Ce creux est normal ; chaque nouveau couple a ses premiers mois difficiles. Mais quand personne ne l’a prévu, il ressemble à un échec. Les managers demandent à garder l’ancien système « par sécurité ». Et le filet de sécurité devient permanent.

Deux maisons, un seul budget. Chaque mois où l’ancien système continue de tourner, l’organisation paie deux fois : deux licences, deux infrastructures, deux jeux de compétences, deux sources de vérité à réconcilier. Les économies du business case se transforment discrètement en surcoûts, et personne ne met cette ligne dans un tableau de bord.

Signaux précoces

On peut savoir si un programme prépare un mariage ou une vie à deux bien avant le grand jour :

Le plan se termine à la date de mise en production.
Personne ne peut nommer la personne responsable des bénéfices, par opposition à la livraison.
Aucune mesure de référence n’a été prise avant le démarrage du programme.
Les vrais utilisateurs n’ont pas touché au système trois mois avant la mise en production.
L’équipe de run ne l’a pas encore vu, ou ne le voit qu’en réunion de passation.
Le plan de bascule n’a pas de retour arrière répété.
Les contrats de l’équipe programme se terminent tous dans le mois qui suit la mise en production.
La date de décommissionnement de l’ancien système indique « après la mise en production », sans date ni responsable.
Le succès est défini comme « livré », pas comme un changement que quiconque pourrait mesurer.

Préparer la vie à deux

La réponse n’est pas de moins célébrer la mise en production. Les équipes méritent la fête. C’est de définir le succès comme le changement que l’on voulait, et de garder le programme en vie jusqu’à ce que ce changement soit réel.

Définir « terminé » comme de la valeur. Écrivez le résultat comme un changement mesurable, prenez la mesure de référence avant le démarrage du programme, et nommez le responsable métier qui en rendra compte à trois, six et douze mois. Si un bénéfice ne peut pas être mesuré au moment de l’approbation, il ne le sera pas après la mise en production.
Impliquer les utilisateurs dès le premier mois. Co-concevez avec de vrais utilisateurs, testez avec eux tôt, menez des pilotes avec un groupe bienveillant. Traitez leurs contournements et leurs frustrations comme des exigences, pas comme de la résistance.
Faire de l’exploitation une porte, pas une invitée. L’équipe de run aide à construire le système, écrit les runbooks avec vous, et détient un vrai droit de veto lors de la revue de préparation opérationnelle. Mieux encore, laissez les équipes qui le construisent aussi l’exploiter.
Basculer par vagues. Un site, un segment, un produit à la fois. Chaque vague enseigne quelque chose à la suivante, et un problème touche quelques centaines d’utilisateurs au lieu de tous.
Répéter le chemin du retour. Chaque bascule a un plan de retour arrière, testé comme la bascule elle-même, avec un point de décision clair et une personne nommée autorisée à le déclencher.
Garder l’équipe pendant la lune de miel. Prévoyez une période d’hypercare avec les personnes qui ont construit le système, et ne les libérez que lorsque les objectifs d’adoption sont atteints, pas lorsque le calendrier le dit.
Prévoir le creux. Dites à l’avance aux sponsors que la performance va baisser avant de s’améliorer, de combien, et pour combien de temps. Un creux annoncé est un jalon ; un creux non annoncé est une crise.
Mettre le décommissionnement dans le plan et dans le budget. L’ancien système reçoit une date d’extinction, un responsable et une ligne budgétaire, tout comme le nouveau a reçu une date de mise en production. Le programme n’est pas terminé tant que les deux tournent.
L’écrire avant que l’équipe parte. Les décisions, les runbooks, les problèmes connus, les raisons derrière les parties étranges de la conception. Le savoir doit survivre au programme, pour les personnes qui l’exploiteront et pour les agents IA qui les aideront.

Ce qu’il faut éviter

Un plan, un budget ou une équipe qui s’arrête à la date de mise en production.
Montrer le système aux utilisateurs pour la première fois en semaine de formation.
Remettre le système à l’exploitation au lieu de le construire avec elle.
Une bascule big bang sans chemin de retour répété.
Garder l’ancien système en marche « par sécurité », sans date d’extinction.
Déclarer le succès à la livraison, sans résultat mesuré.
Laisser l’équipe programme, et son savoir, partir le lendemain de la fête.

Le tournant de l’IA

L’IA est le wedding planner le plus spectaculaire jamais inventé. Une démo convaincante prend désormais quelques jours ; un pilote, quelques semaines. Alors les organisations célèbrent plus de mariages que jamais, et les couples peinent. En 2025, un rapport du MIT affirmait qu’environ 95 % des pilotes d’IA générative en entreprise n’avaient produit aucun retour financier mesurable. Le chiffre exact est débattu. Le schéma ne l’est pas : la démo était le mariage, et personne n’avait prévu le lundi.

L’IA accélère aussi la livraison, ce qui signifie plus de mises en production qui atterrissent sur les mêmes utilisateurs. Les gens ne peuvent absorber qu’une quantité limitée de changement à la fois. Livrez plus vite qu’ils ne peuvent adopter, et vous obtenez un portefeuille de systèmes livrés que personne n’a eu le temps de commencer à vraiment utiliser.

Et le piège de la mise en production a une nouvelle victime : les agents IA eux-mêmes. Quand l’équipe programme part sans écrire pourquoi les choses sont comme elles sont, ceux qui restent peuvent au moins se renseigner autour d’eux. Les agents ne le peuvent pas. Comme je l’ai défendu dans Le troisième grand livre, le savoir non documenté est désormais une dette qui porte intérêt.

Utilisée après la fête, en revanche, l’IA pourrait être le conseiller conjugal que les programmes n’ont jamais eu. Elle peut lire les données d’usage et montrer quelles fonctionnalités sont adoptées et lesquelles sont évitées. Elle peut repérer les tableurs et les étapes manuelles par lesquels les utilisateurs contournent discrètement le système. Elle peut répondre aux questions des utilisateurs dans l’outil, au moment où ils sont bloqués, plutôt que dans une session de formation trois semaines plus tôt. Elle peut cartographier ce qui dépend encore de l’ancien système, pour qu’il puisse enfin être éteint. Et elle peut rédiger des runbooks et des fiches de décision à partir du code et des tickets, avant que l’équipe parte.

Jusqu’à ce que la valeur nous sépare

Les meilleurs programmes sur lesquels j’ai travaillé ont eu des mises en production étonnamment calmes. Une première vague un mardi, une deuxième deux semaines plus tard, pas de gâteau, quelques cafés nerveux. La vraie célébration est venue six mois plus tard, quand les chiffres du business case ont enfin bougé, et que l’ancien système a été éteint pour de bon. C’est ce jour-là dont tout le monde s’est souvenu.

C’est le dernier épisode de la série, alors permettez-moi de prendre un peu de recul. Dix pièges : le moustique des trop nombreux oui, l’Everest gravi d’une seule traite, le vol d’une heure qui en prend cinq, la route d’Abilene, l’Opéra de Sydney, le Vasa, neuf femmes et un mois, un pont qui a raté de 54 centimètres, la pastèque, et maintenant le mariage sans vie à deux.

Aucun programme ne les évite tous. Moi non plus, jamais. Voyez-les comme des cartes qu’on vous distribue en chemin. Vous en ramasserez quelques-unes ; tout le monde le fait. Les programmes qui réussissent ne sont pas ceux qui ne tirent jamais de carte. Ce sont ceux qui reconnaissent chaque carte tôt, la nomment à voix haute, et la posent avant que la suivante n’arrive. Les programmes qui échouent sont ceux qui ont encore la main pleine le jour J.

Alors, à votre prochaine mise en production, après le gâteau, posez une question en douceur : dans un an, qu’est-ce qui aura changé, pour qui, et qui sera encore là pour le vérifier ? Si la salle devient silencieuse, le mariage est préparé. La vie à deux ne l’est pas encore.

Merci d’avoir suivi cette série jusqu’au bout. Lequel de ces dix pièges avez-vous rencontré le plus souvent, et lequel avez-vous réussi à poser ? J’aimerais sincèrement entendre votre histoire.

Toutes les situations décrites ici sont des composites, tirés de nombreux programmes sur 25 ans.