J’écris cet article en partie sur mon temps de CFI, au sujet d’un livre acheté grâce à mon CFI, liberté que je peux m’octroyer grâce à Shodo Nantes ♥️

Temps de lecture : environ 10 min

La centrale nucléaire de Monju au Japon n’a jamais produit un seul watt d’électricité. Soixante ans de travaux, quinze milliards dépensés, pour rien. Ce fiasco n’est pas isolé : Scribe pour la police nationale, Louvois pour la paie des militaires, et des dizaines d’autres projets informatiques ou industriels racontent la même histoire. Le livre How Big Things Get Done de Bent Flyvbjerg et Dan Gardner analyse ces échecs, leurs causes et propose des solutions pour éviter ce qui semble inéluctable.
Le titre du livre pourrait laisser penser que les auteurs s’adressent uniquement aux responsables de très gros projets (industriels, gouvernementaux). Ce n’est pas le cas, il s’adresse à toute personne confrontée à des problèmes complexes. Et donc cela englobe aussi les particuliers qui mènent des projets comme une rénovation intérieure (il prend l’exemple d’une rénovation de cuisine). Cette approche large laisse de côté certaines spécificités des grands projets, mais elle rend l’ouvrage accessible à un public plus large, tout en abordant des sujets importants. Je vous partage quelques idées qui m’ont marqué.

Centrale de Monju
Centrale nucléaire de Monju - Source

Peu de projets complexes sont des succès

Les auteurs ouvrent par un constat chiffré : la plupart des projets complexes échouent. Bent Flyvbjerg a construit au fil du temps une base de données avec 16 000 projets. Les résultats sont édifiants : seuls 8,5% des plus grands projets aboutissent dans les temps et le budget prévus. Et seuls 0,5% si on prend en compte les bénéfices attendus. Parmi les échecs, une grande partie d’entre eux échouent très violemment. La distribution des données suit une queue épaisse (fat tail) : les échecs violents ne sont pas des anomalies rares, mais des événements fréquents. Ce sont ces “cygnes noirs” qui peuvent couler une entreprise. D’où viennent ces échecs ?

Un projet se divise généralement en deux phases : planification et livraison (ou exécution selon les contextes). La phase de planification est moins coûteuse. Les problèmes détectés à ce stade ont un impact limité. En revanche, plus un projet va durer longtemps dans sa phase de réalisation, plus les risques de complications augmentent. Par exemple une construction d’un bâtiment qui s’étire dans le temps. Ou un logiciel qui est construit dans un long cycle en V. De nombreux événements peuvent survenir : un choc externe comme le Covid, ou un incident direct comme une fuite lors du percement d’un tunnel. Même une accumulation de petits incidents peut faire dérailler un projet. Les auteurs citent un proverbe médiéval pour illustrer cette fragilité :

For want of a nail, the shoe was lost. For want of a shoe, the horse was lost. For want of a horse, the rider was lost. For want of a rider, the battle was lost. For want of a battle, the kingdom was lost.

Il faut donc réduire au maximum la durée de la phase de livraison, et pour cela éviter de s’y lancer prématurément. Hélas, la précipitation est fréquente, comme un besoin irrépressible de passer au concret. Pourquoi ? Le livre détaille différentes raisons psychologiques ou politiques. Le biais d’optimisme par exemple. Ou alors notre tendance à foncer sur la première solution qui nous semble acceptable.
Agir rapidement permet aussi de dissimuler les difficultés prévisibles, une pratique courante pour remporter des contrats. Et une fois les problèmes apparus, il est trop tard pour faire marche arrière.
Au démarrage, tout le monde est satisfait. Mais très vite les désillusions arrivent : on bascule dans le mode “casse / répare” où chacun court dans tous les sens.

Penser lentement, agir vite

Ce que nous faisons habituellement se résume à Think Fast, Act Slow. L’exacte l’inverse de ce qu’il faut faire. Un projet complexe ne se résout pas dans la précipitation. Il faut prendre le temps de la planification, pour réduire les risques et la fenêtre d’exécution. Cette phase coûte bien moins cher. Une bonne phase de réflexion implique exploration, imagination, analyses, tests, itérations et esprit critique.

Commencer par la finalité

Pour commencer, il faut définir le “pourquoi”. Cadrer le besoin. Trop souvent, le but paraît évident, donné d’avance. Il n’est pas remis en question. Or il devrait l’être, par curiosité, ouverture d’esprit, volonté d’approfondir. Il y a toujours des choses que l’on ne sait pas. Challenger le but permet d’éviter de s’engager sur un mauvais objectif. Un projet est un moyen, pas une fin. Quel objectif sert-il ?

Les auteurs illustrent ce point par deux pratiques en vigueur chez Amazon. Avant de lancer un nouveau produit, l’équipe doit rédiger un communiqué de presse fictif décrivant ce qu’il apportera aux clients, accompagné d’une FAQ résumant fonctionnalités et coûts. Tout doit y être expliqué simplement. Ces documents servent de support à la réunion de pitch. Pas de Powerpoint. Ils sont examinés, questionnés, puis retravaillés. Nouvelle réflexion, mise à jour des documents, nouvelle réunion. Ce processus itératif garantit une vision partagée et précise tout au long de la préparation. Dans le développement logiciel, on retrouve souvent ce problème : des fonctionnalités sont produites sans que leur valeur ait été challengée. Résultat : elles ne servent pas. Et plus la fonctionnalité est importante, plus les risques sont élevés.

Itérer

Une fois le “pourquoi” clarifié, on prend le temps d’élaborer (préparer mûrement, par un lent travail de l’esprit). Dans le cadre d’une startup, par exemple, on itère à la recherche du produit qui trouvera sa cible. On apprend avant de passer à l’échelle. Chez Pixar le processus passe par plusieurs étapes. D’abord un pitch d’une douzaine de pages. Puis le script, puis le story board. Avec des itérations à chaque étapes. Pour “Vice-versa” c’est la neuvième version du storyboard qui a été mise en image numérique. Chaque domaine adapte cette phase de réflexion à ses spécificités, mais la finalité reste identique : découvrir les problèmes au plus tôt, quand leur résolution coûte le moins cher.

Les bonnes personnes, la bonne équipe

L’équipe constitue un autre facteur déterminant. C’est même le seul critère qui a été mentionné par tous les chefs de projet que les auteurs ont interviewés. Si cela est possible, on engage une équipe déjà constituée et ayant fait ses preuves. Par exemple un architecte avec tous ses collaborateurs. Il faut anticiper ce besoin au plus tôt. Si ce n’est pas possible, alors il faut la créer de toute pièce. C’est le rôle du chef de projet, que l’on aura donc pris le soin de sélectionner en premier.

Pour illustrer l’impact, les auteurs donnent l’exemple du terminal T5 à l’aéroport de Heathrow. La deadline était fixée. Si le projet avait suivi les performances moyennes du secteur, il aurait dépassé les délais — ce qui aurait pu couler l’entreprise mandatée. Tout a été bien fait en amont. L’équipe a innové en décidant de préparer tous les éléments hors site avant assemblage, une approche révolutionnaire à l’époque, devenue depuis la norme. Elle a évité les conflits entre prestataires en alignant leurs intérêts : des bonus en cas de réussite. Les prestataires ont moins rivalisé, plus coopéré. L’entreprise a privilégié les partenaires avec lesquels elle avait déjà travaillé et qui délivraient la meilleure qualité, même s’ils n’étaient pas les moins chers.
Un esprit d’équipe global a été instauré. Tout le monde travaillait pour le T5. Sa propre compagnie venait après. Une culture a été créée, rendant fiers les travailleurs, des bureaux au chantier. Mais rien n’est pire qu’un discours contredit par les actes. Tout a donc été fait en cohérence : conditions de travail excellentes, équipements de qualité, sécurité physique au plus haut niveau, écoute du personnel. Une sécurité psychologique permettait à chacun de s’exprimer. Les gens étaient fiers d’y travailler, certains gardaient même leurs vêtements de chantier pour sortir le soir. Et cela a porté ses fruits : quand des milliers de personnes donnent leur meilleur car ils sont bien, l’impact sur la performance est massif. Cela a coûté beaucoup d’argent. Mais c’était un investissement indispensable pour l’entreprise pour espérer finir dans les délais et les coûts.
Dans le développement logiciel, on retrouve cette logique aussi dans le Domain Driven Design : affecter la meilleure équipe sur les projets les plus critiques pour l’entreprise, son core domain.

Lego

Le livre aborde aussi la modularisation comme levier de succès. Les données de Bent Flyvbjerg révèlent que cinq types de projets échappent aux échecs catastrophiques. Leur point commun : ils sont modularisables, au moins en partie. Ces projets sont plus rapides, moins coûteux et moins risqués. L’énergie éolienne en est un exemple : de nombreux éléments identiques assemblés. On évite le sur-mesure. On peut ainsi expérimenter, apprendre de ses erreurs, progresser plus vite.

Repetition is the mother of learning

La question à se poser : quel est mon Lego ?
Quelques exemples pour les grands projets d’infrastructure :

Remplacer les méga-barrages par de multiples petites turbines réparties géographiquement (le tout formant un réseau puissant).
Assembler en usine des éléments montés ensuite sur site (comme pour le T5 de Heathrow), ce qui permet aussi de poursuivre le travail par mauvais temps.
Les conteneurs maritimes standardisés
Dans le bâtiment : l’hôtel Mariott de Manhattan, construit en usine et assemblé sur place.

Pour les auteurs, transformer nos méthodes pourrait avoir un impact considérable sur l’économie mondiale, et notre capacité à affronter le réchauffement climatique. Face à l’urgence, les échecs massifs ne sont plus tolérables. La modularisation devient une nécessité. J’ajoute à ce sujet qu’en développement logiciel, la modularisation est un sujet complexe. Vouloir modulariser ne suffit pas : il faut savoir quand et comment. Sans cette maîtrise, on se retrouve avec des « monolithes distribués », des modules fortement interdépendants, peu autonomes.

Conclusion

Pourquoi le projet de Monju, la centrale nucléaire qui n’a jamais produit d’électricité, a échoué ? C’était un projet pharaonique. Un énorme tout, non modulaire. Il était donc très compliqué d’expérimenter. La phase de livraison s’est éternisée. Et une multitude de problèmes se sont enchaînés. Monju s’est retrouvé exposé à des événements imprévisibles majeurs. Le coup de grâce fut la catastrophe de Fukushima en 2011. Cet événement a retourné l’opinion publique japonaise contre le nucléaire au moment même où le gouvernement envisageait de dépenser 6 milliards de dollars supplémentaires pour redémarrer Monju.

Vous voulez des clés pour éviter votre moment Monju ? Lisez ce livre. Il est facile à lire, et les concepts sont illustrés par de nombreux exemples de réussites et d’échecs. De nombreux domaines peuvent bénéficier des conseils. Je vous recommande sa lecture (j’ai découvert ce livre grâce à la recommandation d’Alistair Cockbburn).

Bonus - Aide mémoire

A la fin du livre, les auteurs partagent onze heuristiques que tout chef de projet devrait avoir dans sa poche. Et pas seulement les chefs de projet, à mon avis. En voici une version condensée :

Engager un maître d’oeuvre avec l’expertise du domaine. C’est l’idéal. Sinon se tourner vers les autres heuristiques.
Constituer la bonne équipe. C’est le rôle du maître d’oeuvre. Dans l’idéal il a son équipe.
Demander “pourquoi ?”
Construisez avec des Lego
Réfléchir lentement, agir vite
Adoptez un point de vue extérieur (votre projet n’est pas unique, regardez les projets de la même catégorie)
Surveiller les risques, ils peuvent tuer votre projet (dans les projets à queue épaisse, les anticiper et éliminer autant que possible)
Savoir dire non au projet si nécessaire
Faire de la diplomatie
Intégrer la lutte contre le réchauffement climatique dans votre projet
Votre plus grand risque, c’est vous (et vos biais)