Regards complémentaires

Pourquoi tant de projets informatiques échouent¶

Adaptation française d’un article publié sur LinkedIn. La date de publication n’est pas établie de façon fiable dans la source.

Les projets informatiques ont une réputation, et elle n’est pas flatteuse. Demandez autour de vous, et vous entendrez la même histoire : dépassements de budget, retards, résultats en deçà des attentes.

Une étude de Bent Flyvbjerg, de l’université d’Oxford, confirme ce que beaucoup pressentent : les projets informatiques sont singulièrement risqués. Selon cette étude, une minorité d’entre eux, de l’ordre de quarante pour cent, dépassent leur budget, un taux meilleur que celui des Jeux olympiques ou des centrales nucléaires. Mais lorsqu’ils dérapent, le dépassement est massif, de l’ordre de quatre cent cinquante pour cent en moyenne, soit le pire profil de tous les types de projets. Je rapporte ces chiffres tels que l’étude les avance.

Qu’est-ce qui ne va pas ? Plusieurs causes se cumulent. De faibles barrières à l’entrée d’abord : contrairement à l’ingénierie, l’informatique manque de normes universelles et de formation formelle, là où nul ne laisserait un ingénieur non formé concevoir un pont. L’immatérialité ensuite : on peut inspecter un pont, pas une ligne de code, et cette abstraction invite la dérive de périmètre et les attentes irréalistes. La profondeur organisationnelle aussi : l’informatique touche toutes les parties de l’entreprise, souvent pilotée par des décideurs non techniciens. La résistance au changement enfin : les projets informatiques redessinent la façon de travailler, ce qui appelle résistances, jeux politiques et désordre.

Comment faire mieux ? Préférer la standardisation au sur-mesure, car des frontières claires préviennent l’inflation des fonctionnalités. Planifier plus longtemps et plus finement, là où les projets informatiques sont souvent menés dans la précipitation. Et rester prudent avec l’IA, qui est stimulante mais amplifie tous les pièges classiques de l’informatique, la nouveauté, la disruption et les attentes démesurées.

L’informatique peut être transformatrice, mais à condition de la traiter avec la même rigueur que l’ingénierie traditionnelle. Construire plus intelligemment, pas seulement plus vite. C’est, dit autrement, la thèse du livre : un projet échoue rarement sur la seule technique.

Référence dans le livre

Le chapitre 14, « Le rôle concret du dirigeant dans le pilotage du système d’information », observe que les grands programmes qui échouent ne manquent presque jamais de compétences techniques, mais de portage dirigeant, et fait de la capacité à arrêter un programme le marqueur le plus net d’une gouvernance mature. Page à préciser à la parution.