Mission Failed
Et voilà, c’est arrivé : le produit sur lequel je travaillais a échoué, mort avec pertes et fracas. Que s’est-il passé ? Ce n’est évidemment pas la première fois qu’une intégration de progiciel dans un cycle en V échoue lamentablement. Tous les éléments classiques de l’échec étaient réunis : intégration de progiciel, guéguerres managériales, cycle en V non assumé, contractualisation à outrance, manque de délégation, etc. Il n’y aurait rien de plus à dire que ce qui a déjà été dit et qui a fait que l’agilité a émergé. Mais alors pourquoi ces échecs à plusieurs millions d’euros existent-ils encore ? Reprenons une discussion qui court sur plus de cinquante ans sur le sujet de la gestion de projet et essayons de voir pourquoi il existe encore des décideurs qui choisiraient rationnellement une méthode prédictive dans des contextes complexes, et pourquoi c’est probablement une erreur.
Un échec cuisant, état des lieux
Le produit avait deux objectifs majeurs : rationaliser le développement d’offres d’assurance de plusieurs départements et améliorer sensiblement le Time To Market. Comment ? En intégrant un progiciel qui promettait assez de souplesse pour pouvoir créer une offre d’assurance en moins de trois mois. Après avoir développé un MVP (Minimum Viable Product), la MOE et la MOA s’engagent sur un cahier des charges à trois ans. En attendant, les utilisateurs refusent de se servir du livrable en l’état. La MOA insiste sur le fait que les délais devront être tenus et la MOE promet que les délais seront tenus. Quelques mois plus tard, le projet est arrêté. Un an et demi de travail de plusieurs dizaines de personnes mis à la poubelle, plusieurs millions d’euros perdus, des prestataires sortis en catastrophe, etc. Le bilan est lourd. Comment en est-on arrivés là ? Un atelier de rétrospective nous apprend que ce fiasco serait dû à de mauvais choix techniques, des erreurs de management et d’organisation en général. Mais un point a particulièrement retenu mon attention : comment se fait-il qu’en 2019 on puisse encore développer des produits informatiques complexes avec une approche prédictive et un cahier des charges sur trois ans ?
Un échec cuisant, le plan à trois ans
En reprenant l’état du backlog au temps T et le débit d’items livrés en moyenne par semaine par les équipes, une première projection me donnait un travail restant à faire à plus de 6 mois, alors que tout devait déjà être terminé. Cela n’empêcha pas les décideurs de demander un cahier des charges qui contenait plus de 150 fonctionnalités planifiées sur 3 ans. Puisqu’on considérait que l’utilisateur ne pouvait pas utiliser une application qui ne serait pas « complète », et puisque les mises en production se font tous les 6 mois, chaque partie prenante chargeait au maximum ses fonctionnalités de peur de rater le train et de devoir attendre de longs mois. Ainsi s’est formé un plan détaillé avec ses livrables, ses jalons, le tout jusqu’en 2021. Une date qui évidemment allait être tenue, puisqu’elle devait être tenue, selon les principes de M. Coué. S’il y eut des tentatives d’adoucir ce monolithe, comme une priorisation à 3 mois et une communication rapprochée avec le prestataire du progiciel, elles étaient réduites à néant par les engagements contractuels du cahier des charges. Heureusement la mascarade fut arrêtée suffisamment tôt pour éviter des pertes encore plus importantes. Au-delà de l’état de fait, qu’est-ce qui pourrait soutenir l’efficacité de l’utilisation d’un cahier des charges sur plusieurs années ?
La Hiding Hand : principe
Dans une publication de 1967 appelée « The principle of the Hiding Hand » (1), l’économiste Albert O. Hirschman expose comment, selon lui, il est bon de planifier à long terme sur de gros projets et de se tromper sur ses prédictions. Le principe qu’il appelle la Hiding Hand –qu’on pourrait traduire litérallement par « la main qui cache » mais aussi « la main qui donne une raclée »– forcerait les décideurs à rencontrer des difficultés non prévues et à s’y adapter, les transformant en entrepreneurs capables de prises de risque. Il explique que l’erreur de planification s’explique selon 2 modes : la « pseudo-imitation » et le « pseudo-programme-complet ». La « pseudo-imitation » fait croire au décideur qu’un modèle ayant déjà été appliqué avec succès ailleurs pourra donc se dérouler sans problème majeur ici avec un ratio de 90/10 entre le pareil et le différent. Hirschman nous explique qu’en fait ce ratio se retrouve souvent inversé avec 90 % de spécifique, et donc de différent, et 10 % de pareil. On retrouve typiquement ce mode dans l’intégration de progiciel, avec la promesse du ratio entre ce qui est disponible sur étagère et ce qui reste de spécifique à développer. Le second mode qui permet la Hiding Hand est le « pseudo-programme-complet ». Ici le décideur prend pour argent comptant le discours de l’expert qui planifie les étapes, un budget, les personnes impliquées, le matériel à déployer, le tout sur plusieurs années. En bref un programme exhaustif qu’il suffira de dérouler pour aboutir au succès du projet. L’application du plan dévoilera bien souvent que cette expertise était en fait l’équivalent d’une boule de cristal et que ses prédictions ne se dérouleront pas comme annoncées. Toute personne ayant une expérience d’un cycle en V d’au moins 6 mois sur un projet informatique reconnaîtra le mode « pseudo-programme-complet ». En résumé, le mode « pseudo-imitation » fait apparaître un projet comme moins difficile, et le mode « pseudo-programme-complet » donne l’illusion aux décideurs qu’ils peuvent déjà savoir ce qu’il va se passer. Et ils sont tout à fait compatibles sur un même projet. Hirschman considère que ces deux modes entrainent bien des difficultés par leurs erreurs d’appréciation, mais que c’est dans cette adversité que les décideurs seront forcés d’être créatifs et de prendre des décisions pertinentes et rapides, en résumé de s’adapter comme dans la fameuse maxime de Nietzsche : « ce qui ne te tue pas te rend plus fort ».
L’exemple de l’usine de bambou pakistanaise
Hirschman donne l’exemple d’une grosse exploitation de bambou située dans un Pakistan au sortir de l’indépendance. Après quelques déboires techniques, l’usine était prête à fonctionner et exploiter les centaines d’hectares de bambou au milieu desquels elle était installée. Mais suite à une rarissime floraison du bambou le bois fut rendu inexploitable et l’usine s’est retrouvée sans matière première. Rapidement, les responsables lancèrent des recherches pour identifier une autre espèce de bambou qui soit fiable et dont la pousse est rapide, et ils arrivèrent ainsi à se sortir de ce guêpier et même à dépasser les prévisions de départ. Les décideurs avaient donc surestimé la disponibilité de matière première, mais ils avaient aussi sous-estimé leur capacité d’adaptation. C’est dans ce mécanisme que se déploie la Hiding Hand. On peut retrouver des exemples similaires dans l’informatique. Citons l’entreprise Ludicorp qui, confrontée au manque d’intérêt suscité par le jeu vidéo qu’ils développaient, ont dû s’adapter et ont créé une application web d’échange de photos très populaire : Flickr. Alors si la Hiding Hand fonctionne, pourquoi mon dernier projet a-t-il échoué ?
Le problème statistique
En 2014, Bent Flyvbjerg et Cass R. Sunstein répondent à Hirschman dans une publication nommée « The principle of the Malevolent Hiding Hand; or, the Planning Fallacy Writ Large » (2). Ils éprouvent la Hiding hand en confrontant statistiquement ses résultats. Ils observent d’abord qu’Hirschman ne compile que onze projets dans sa démonstration, ce qui est évidemment trop faible pour prouver un phénomène général. Ils entreprennent donc d’étudier 2062 grands projets et leur réussite au regard de leur coût prévu et de leur bénéfice final. Si Hirshman a raison, on devrait observer que les projets dont les coûts sont sous-évalués devraient voir leurs hausses de bénéfices largement compenser ces pertes grâce à la créativité de leurs décideurs. Qu’en est-il ? On constate que non seulement les bénéfices ne compensent que très rarement les coûts, mais qu’il n’y a en moyenne pas de hausse des bénéfices du tout. Les auteurs décrivent une Hiding Hand malveillante : les erreurs de planification ne sont pas couvertes par une créativité émergente qui soit est absente, ou bien arrive trop tard, ou bien qui est simplement insuffisante. Cette Hiding Hand malveillante est observée 3,5 fois plus que la Hiding Hand bienveillante, ce qui les conduit à la conclusion suivante : la Hiding Hand est un cas particulier et un plan optimiste n’est pas une condition suffisante à la réussite d’un projet.
Se faire mal, mais pas trop mal
En reprenant ce dialogue d’économistes sur un demi-siècle, j’ai cherché à trouver ce qui pourrait encore justifier, dans l’industrie logicielle, l’utilisation des méthodes prédictives dans un environnement complexe. En dehors des problématiques de contractualisation ou de psychologie (comme l’habitude ou le biais d’optimisme comparatif), qu’est-ce qui pourrait expliquer qu’on utilise encore des Cycles en V dans des développements logiciels complexes ? Tout le monde convient qu’il est difficile de planifier la création d’un logiciel sur 3 ans, et les béquilles que sont la «pseudo-imitation » et le « pseudo-programme-complet » sont des illusions dangereuses. Et il apparaît d’après Flyvbjerg et Sunstein que se sortir d’une planification fallacieuse est statistiquement difficile. Je repense aux mots d’un des décideurs de mon projet raté : « on contractualise un planning sur trois ans, avec une variation maximum de 20 % sur les jalons ». Mais pourquoi rigidifier le poids de la planification dans une industrie, le logiciel, où nous avons la chance de travailler un produit suffisamment souple et évolutif pour pouvoir faire des choix et s’adapter –dans certaines limites– tout au long du développement ? Le but de la Hiding Hand est de rendre les décideurs plus créatifs et plus capables de prise de risque. Et c’est précisément ce que propose l’empirisme, en essayant puis en analysant le résultat. On peut allier de cette manière des essais audacieux à une prise de risque mesurée. Dans un an le Manifeste Agile aura 20 ans, et pourtant l’oubli de sa quatrième valeur « l’adaptation au changement plus que le suivi d’un plan » aura encore conduit à l’échec d’un projet. Nous n’avons pas besoin d’une mauvaise planification : nous avons l’empirisme. Les méthodes prédictives avec leur planification rigide sont dangereuses ? Heureusement nous pouvons accompagner le changement ! Nous voulons fabriquer des acteurs entreprenants ? Nous avons le terrain de jeu pour essayer. J’ai une vision, un objectif, et j’avance pas à pas en m’inspectant et en m’adaptant régulièrement.
Never say never again
L’optimisme naïf de la Hiding Hand d’Hirschman n’apporte manifestement pas de solution intéressante, mais elle décrit étonnamment bien deux modes d’échec courants des méthodes prédictives. L’inspection et l’adaptation sont évidemment des conditions insuffisantes à la réussite d’un logiciel complexe, mais elles en sont les conditions nécessaires. Ce sont elles qui permettent de prendre les risques qui permettront d’avancer, au pire en se faisant mal mais jamais « trop » mal. J’aimerais conclure en partageant un contre-exemple à cet échec. Il y a quelques années un projet de compteurs électriques communicants était lancé en fanfare. Les attentes étaient fortes. Un département majeur de ce SI démarra le projet comme il savait le faire : MOA, MOE, cahier des charges sur plusieurs années etc. Mais au bout d’un an, les indicateurs étaient au rouge. Le directeur du département était expérimenté et il pressentait l’échec à venir du projet. Il prit donc une décision courageuse : se faire accompagner, changer de méthode, faire des itérations et livrer un premier service de bout en bout. Aujourd’hui plus de 13 millions de compteurs Linky fournissent de l’électricité à 50 millions de Français.
