Pourquoi les projets logiciels déraillent, et comment désamorcer la bascule

Un grand projet logiciel s'effondre rarement le jour où vous l'attendez. Il s'enlise. Une release glisse d'un trimestre, un module passe à la phase suivante, l'ancien et le nouvel environnement tournent des mois côte à côte. Le temps que la grande bascule arrive, la moitié de ce qui était promis se révèle absente. La facture, elle, est déjà payée.

Le schéma est mesuré

McKinsey a étudié avec l'University of Oxford (2012) plus de 5 400 grands projets IT, chacun avec un prix initial supérieur à 15 millions de dollars. En moyenne, ils ont dépassé leur budget de 45 % et leur délai de 7 %, et ont livré 56 % de valeur en moins que prévu au départ. La moitié dépasse fortement le budget. Un budget plus élevé ne protège pas, il augmente seulement la mise.

Pourquoi cela tourne mal

La cause est rarement un seul mauvais choix technique. C'est l'organisation. Un remplacement est adjugé comme un seul grand bloc, avec une seule date de fin où tout doit passer en production en même temps. Le périmètre est verrouillé à l'avance, alors que l'entreprise, elle, continue d'évoluer. Plus le projet avance, plus il contient d'argent, et plus il pèse lourd de l'arrêter ou de le corriger. Les mauvaises nouvelles remontent lentement, car personne ne veut en être le porteur.

Ainsi naît un projet trop grand pour échouer et trop lourd pour réussir. La décision de continuer est déjà prise à chaque instant, bien avant que quiconque puisse voir si cela fonctionne.

Ne croyez pas que cela ne concerne que les projets de 15 millions de dollars. Le mécanisme se transpose à plus petite échelle. Une migration ERP, un nouveau système de caisse, un CRM enfin relié à la comptabilité : c'est la même organisation d'un grand coup unique à une seule date. Pour une entreprise de deux cents personnes, une bascule ratée est tout aussi menaçante qu'un amortissement de dizaines de millions pour un grand groupe. Ce qui compte, c'est le rapport au chiffre d'affaires, pas le montant absolu.

La bascule est le vrai risque

Demandez à une direction où se trouve la douleur, et la réponse est presque toujours la même : la bascule. Le jour où l'ancien outil s'éteint et le nouveau s'allume. Tout ce qui tenait sur le papier pendant des mois doit alors fonctionner d'un coup, avec de vraies données, de vrais clients et un comptoir qui ne peut pas attendre. Si ce jour échoue, l'entreprise retombe sur le système qu'elle voulait justement quitter.

C'est là qu'un big bang montre son prix. Tout le risque est mis de côté jusqu'à un seul moment. Qui veut réduire ce risque doit découper ce moment.

Un projet trop grand pour échouer est aussi trop grand pour être piloté. Le seul vrai contrôle est la liberté de s'arrêter après chaque étape.

Des vagues plutôt qu'un big bang

Nous construisons par vagues. Chaque vague livre un élément de la plateforme qui fonctionne, en production, avec de vrais utilisateurs, avant que la suivante ne commence. À la fin de chaque vague se tient un go/no-go. Pas un comité de pilotage qui feuillette un rapport d'avancement, mais une décision fondée sur quelque chose qui tourne.

Une étape ne passe au vert que lorsque cet élément qui fonctionne remplit quelques conditions strictes :

• les utilisateurs font leur vrai travail dans le nouveau module, pas dans un environnement de test
• les données sont migrées et vérifiées par les personnes qui les manipulent au quotidien
• les objectifs mesurables de cette vague sont atteints, en chiffres, pas en impression
• la finance a vu et cosigné les coûts de l'étape

Tant qu'une vague n'atteint pas ce seuil, le legacy continue simplement de tourner. Vous n'éteignez jamais un système qui fonctionne pour quelque chose qui doit encore faire ses preuves. L'ancien et le nouveau module tournent côte à côte jusqu'à ce que le nouveau soit stable, et c'est seulement alors que l'ancien est retiré. Il n'y a plus de jour où tout doit réussir en même temps, car jamais plus d'une vague n'est en jeu à la fois.

Avoir vite quelque chose en main, et la liberté de s'arrêter

La première vague livre un résultat qui fonctionne sous 90 jours, quelque chose qui est en production et que vos équipes utilisent réellement. Pas une démo, pas un rapport qui demande de la confiance à crédit. À partir de ce point, vous prenez chaque vague suivante séparément. Si un go/no-go tombe sur un no-go, le base fee s'arrête. Vous ne continuez pas à payer pour une direction qui ne fait pas ses preuves, et vous n'êtes lié à rien, car le code se trouve dans votre propre dépôt dès le premier jour.

Cela inverse la logique du grand projet. L'élan ne réside plus dans le fait de continuer parce qu'il y a déjà tant d'investi. Il réside dans la preuve. Chaque étape doit se mériter avant que la suivante ne commence. Et parce que le legacy continue de tourner jusqu'à ce que cette preuve soit là, un no-go vous coûte du temps et un peu d'apprentissage, pas une entreprise.

Un remplacement de logiciel n'a pas à être un pari sur une seule date. Qui construit par vagues sait après les 90 premiers jours si l'approche est juste, et garde à chaque étape le choix de s'arrêter, de corriger ou de poursuivre. La vague suivante ne commence que lorsque la précédente tourne en production et que les chiffres sont atteints. Ce n'est pas plus lent. C'est la différence entre un projet qui n'arrête pas de glisser et un projet qui livre chaque mois quelque chose que vous pouvez utiliser.