Quand le magazine des Ingénieurs de l’Armement m’a contacté pour un article sur la difficulté de mener les projets informatiques à bien, je me suis retrouvé plongé 30 ans en arrière, à mes débuts dans les programmes SIC. Confrontés à des obstacles récurrents, les projets informatiques étaient déjà le cauchemar des services techniques. Je me souviens de groupes de travail sur les « Programme à Logiciels Prépondérants ». On recommandait à l’époque de réduire la durée des programmes avec des « incréments » courts (1 à 2 ans) et de s’appuyer sur du prototypage pour éviter les dérives fonctionnelles. C’était pertinent, mais insuffisant comme on le verra... 

Mon parcours dans le monde du service informatique m’a permis d’analyser la situation à partir d’échantillons plus larges. Quelques chiffres :

- Les dépassements en coûts et délais sont fréquents : 20% en moyenne, comparé au devis initial. Ce n’est pas si préoccupant : 20% représente environ la somme des provisions pour aléa du maître d’ouvrage et du prestataire (interne ou externe), chacune de l’ordre de 10%. L’exécution reste sous contrôle.

- C’est la dispersion des dépassements autour de cette moyenne de 20% qui pose le problème. On est assez loin d’une distribution gaussienne : si 99% des dépassements restent bien inférieurs à 50%, confinés dans une bande à 3 écart-types autour des 20%, une proportion marginale de projets (moins de 0.2%) double ou triple leur coût initial et/ou leur durée (soit plusieurs dizaines d’écart-types). Parmi ceux-ci, environ une moitié ne va pas à son terme : le projet est arrêté, avec des conséquences souvent catastrophiques pour les parties prenantes. 

C’est de là que vient la mauvaise réputation des grands projets : un faible nombre de cas graves, mais avec des impacts dévastateurs, de l’ordre de l’accident industriel.

Comment gérer le risque lié à cette distribution si particulière ?

Essayons d’abord de comprendre les racines du mal en identifiant 3 catégories de problèmes :

1. Les difficultés classiques

Je range ici ce qui est lié à :

- Des erreurs dans la gestion du cycle de vie du logiciel : migration de données mal planifiée (cette phase est toujours sur le chemin critique des projets, cf. Socrate à la SNCF), trop d’évolutions par rapport au cahier des charges initial, disponibilité insuffisante d’experts du domaine, etc.

- Un manque d’alignement entre le « métier » (les opérationnels dans le cadre d’un programme militaire) et « l’informatique ». On s’aperçoit trop tard que le système développé ne correspond pas à ce que le métier voulait ...

- Une conduite du changement insuffisante. Un projet n’est en général qu’un composant d’un programme de transformation englobant des volets organisationnels de refonte des processus. Si cette dimension humaine n’est pas prise en compte, le projet informatique va à l’échec.

Une maîtrise d’œuvre ou d’ouvrage un tant soit peu professionnelle (le cas général aujourd’hui) va s’appuyer sur un plan de gestion des risques formalisé pour traiter ces difficultés. L’imprédictibilité sera réduite à son minimum.

2. Plus difficile à éviter…un optimisme sur les délais

Un projet informatique est souvent le résultat d’une mise en concurrence, puis d’une âpre négociation sur les coûts et les délais. Dans cette négociation et pour des raisons faciles à comprendre, les donneurs d’ordres comme les prestataires ne vont retenir que des hypothèses favorables. Les délais, perçus comme moins engageants, pâtiront encore plus de cet optimisme que les coûts. Pour finir, les parties se mettront d’accord sur un planning presque toujours irréaliste, généralement à cause de durées de conception et d’intégration trop courtes. C’est évidemment problématique, d’autant plus que coûts et délais sont liés (compter 6% de dépassement de coûts pour 10% de dépassement de délais).

Cet enchaînement est courant et l’obstacle difficile à surmonter. Le mieux à faire sera de limiter le périmètre d’une première version aux fonctionnalités les plus importantes pour montrer des avancées visibles dans un délai raisonnable. On reste en général heureusement dans des dépassements gérables (les 3 écart-types au-delà des 20% de dépassement !). Mauvaise humeur et conversations difficiles seront au menu des comités de pilotage mais l’accident industriel n’aura pas lieu. 

3. Le vrai problème, la complexité fonctionnelle sous-estimée …

Les grands projets visant à remplacer un système existant et l’enrichir par de nouvelles fonctionnalités constituent la vraie difficulté. Les migrations massives vers le cloud, vues à juste titre comme un moyen de réduire le coût de fonctionnement des systèmes tout en augmentant leur « agilité », rentrent dans cette catégorie. 

Les estimations de coût sont ici logiquement basées sur les fonctionnalités visibles du système existant. Or celles-ci ne représentent que la partie émergée de l’iceberg : les exceptions, les situations spécifiques peu utilisées, développées au fil de la maintenance de l’application, sont mal connues et, par suite, largement sous-estimées (des opérations d’après-vente complexes dans une refonte des points de vente par exemple). Elles peuvent facilement venir doubler ou tripler le coût des parties visibles, d’autant plus que les experts présents lors du développement de l’application précédente ne sont généralement plus là pour aider à la conception ou aux tests.

« VOULOIR REDÉVELOPPER LES GRANDES FONCTIONS EN PARTANT DE ZÉRO EST UNE ERREUR… »

C’est particulièrement vrai pour les grandes fonctions de l’entreprise (comptabilité, RH, logistique, relation client). Vouloir les redévelopper en partant de zéro est une erreur qu’on paiera très cher, mieux vaut s’appuyer sur un progiciel intégré de type SAP ou Oracle. 

Il n’y a pas beaucoup de remèdes une fois le programme lancé. Il faut donc impérativement s’appuyer sur l’avis d’experts en amont si l’on pressent une situation de ce type. Un développement itératif permettra d’évaluer l’ampleur des dégâts dès les premières versions, mais le dépassement sera à coup sûr significatif ; l’entreprise ou l’administration saura ou non le supporter selon l’urgence à remplacer le système existant.

Face à ces risques, une question récurrente se pose depuis longtemps : faut-il « traiter les grands projets informatiques comme un programme d’armement ? »

Indubitablement oui pour tout ce qui relève de la maîtrise des coûts, des évolutions fonctionnelles, de la gestion financière, de l’alignement avec les états-majors, de la gouvernance pendant l’exécution (typiquement les deux premières catégories de problème). Etant en mesure de comparer, je peux confirmer que la DGA est une maîtrise d’ouvrage informatique performante à cet égard. Deux remarques cependant :

- Comme on aura pu le constater, une méthode itérative, avec des versions tous les deux ou trois mois (8 à 10 mois pour la première version), est un ingrédient essentiel de la gestion du risque. Intégrer ces méthodologies itératives à la conduite des programmes d’armement paraît réalisable. A noter que, parmi les méthodes itératives, les méthodologies agiles sont de loin les plus performantes.

- Cela ne protègera pas contre un accident industriel dû à une complexité fonctionnelle sous-estimée. C’est pourquoi la conscience du risque est une composante essentielle du management de ces projets : « Seuls les paranoïaques survivent » disait Andy Grove (l’ancien CEO d’Intel) et c’est particulièrement vrai ici. Il faudra ensuite s’appuyer sur l’avis d’experts en amont, et de directeurs de projet expérimentés dans l’exécution. Et la question à leur poser sera : « l’a-t-il/elle déjà fait avant ? ».