Les dépassements budgétaires surprennent rarement. C’est un choix de gouvernance.

Je n’ai jamais vu un dépassement sérieux arriver comme un éclair. Il arrive comme la rouille. Lentement. En silence. Puis, d’un coup, vous découvrez que le chiffre était verrouillé depuis des mois.

Les critiques autour de l’Energy Island de Bornholm, telles que décrites dans l’article d’ing.dk sur les problèmes de budget et le débat sur les responsabilités, renvoient à un schéma que j’ai vu dans de nombreux programmes industriels : la vérité des coûts arrive trop tard, les interfaces restent floues, des contrats sont signés sous pression de calendrier et, plus tard, tout le monde peut dire de bonne foi : « Je n’étais pas au courant. »

C’est pour cela que je considère que les dépassements budgétaires surprennent rarement. C’est un choix de gouvernance. Pas un choix malveillant. Un choix structurel. Dès que vous laissez « on clarifiera plus tard » s’installer dans le périmètre, les interfaces ou la gestion des changements, vous choisissez un futur où la réalité financière arrivera trop tard pour agir.

Quand je dirigeais des opérations en électrification et stockage d’énergie en tant qu’ancien COO, les risques d’ingénierie étaient rarement le premier point de rupture. Le premier échec, c’était de laisser des dépendances de delivery entre organisations sans propriétaire unique. Le travail avançait, mais pas la responsabilité sur les délais et les coûts.

Le dépassement est souvent contracté avant d’être reporté

Les dirigeants parlent souvent de « visibilité » comme si le problème venait des dashboards. En réalité, la mécanique des dépassements est bien plus concrète.

• Les interfaces se définissent trop tard. Des interfaces figées tardivement imposent redesign, reprises et achats en urgence. Le coût existe, même s’il n’est pas encore comptabilisé.
• Les stratégies fournisseurs se décident par politique ou par habitude. Au final, soit vous avez un fournisseur prime qui n’est pas réellement accountable, soit un écosystème modulaire où personne ne porte l’intégration.
• Les contrats deviennent des engagements irréversibles. Une fois les jalons, pénalités et long-lead items lancés, vous pouvez discuter les chiffres ; vous ne pouvez pas « dé-signer » l’engagement sans le payer.
• Les changements sont « absorbés » jusqu’au moment où ce n’est plus possible. Les équipes veulent aider. Elles entretiennent l’élan. Elles acceptent discrètement le glissement de périmètre. Plus tard, cela ressort sous la forme d’un gros chiffre et d’une « surprise ».

Voilà pourquoi une découverte tardive n’est pas une découverte. C’est une annonce. La décision a déjà été prise, simplement pas de manière explicite.

La kill-chain : quatre leviers de gouvernance pour éviter une ambiguïté coûteuse

Voici la leçon d’opérateur à laquelle je reviens sans cesse. Ce n’est pas glamour, mais c’est efficace. Si vous voulez moins de dépassements ce trimestre, traitez le sujet comme une kill-chain et cassez-la tôt.

1) Geler le périmètre tôt, mais le geler correctement

« Geler le périmètre » ne veut pas dire interdire tout changement. Cela veut dire définir ce qui peut bouger et comment.

• Établir un périmètre de référence au niveau système (quels résultats doivent exister) et au niveau des interfaces (quoi doit se connecter à quoi, et sous quelles contraintes).
• Chiffrer chaque demande de changement au moment où elle est proposée, pas au moment où elle est mise en œuvre.
• Définir l’autorité de changement : qui peut approuver en dessous d’un seuil et qui doit approuver au-dessus.

Quand je dirigeais une business unit smart-building en tant qu’ancien CEO, avec des capteurs connectés et des systèmes de contrôle de bâtiments vendus dans plusieurs pays, la dérive de périmètre venait rarement d’un « mauvais product management ». Elle venait de l’urgence commerciale confrontée à la réalité de l’intégration. Les ventes voulaient une variante de plus. Le service voulait un contournement de plus. L’ingénierie voulait une amélioration de plus. Sans une autorité de changement stricte, chaque bonne intention devient un passif non chiffré.

2) Choisir une stratégie fournisseurs à la hauteur du risque d’intégration réel

Dans les programmes industriels complexes, il n’y a que deux stratégies honnêtes. Tout le reste, ce sont des hybrides conçus pour éviter l’accountability.

• Single throat to choke : un fournisseur prime porte la responsabilité end-to-end, intégration comprise. Vous payez pour cela. En contrepartie, vous savez où placer le risque.
• Modular multi-supplier : plusieurs fournisseurs livrent des modules, mais vous attribuez explicitement la responsabilité d’intégration et vous la financez comme un workstream à part entière.

Le modulaire peut aller plus vite et être plus compétitif. Il peut aussi devenir un piège si vous faites comme si l’intégration n’était qu’un « overhead de gestion de projet ». L’intégration, c’est de l’ingénierie, des opérations et un design contractuel. Si vous ne payez pas au départ, vous payez ensuite, intérêts compris.

Si vous voulez un angle plus approfondi sur la relation fournisseurs, j’ai écrit The Fastest Way to Lose Quality Is to Treat Suppliers Like a Contract Problem. La version courte : les contrats répartissent les torts, mais ce sont les mécanismes opérationnels qui produisent les résultats.

3) Attribuer un owner par interface, et rendre cette responsabilité mesurable

Les grands programmes échouent le plus souvent aux coutures. Pas dans les composants.

J’applique donc une règle simple : une interface, un owner, un test d’acceptation. Pas de comités. Pas de responsabilité partagée. Si deux personnes « possèdent » une interface, alors personne ne la possède quand cela devient difficile.

• Owner : une personne nommée, responsable de la définition, de l’alignement et de l’acceptation.
• Définition : une spécification d’interface vivante, incluant contraintes de performance, modes de défaillance et responsabilités d’exploitation.
• Test d’acceptation : un gate fondé sur des preuves, qui démontre que l’interface fonctionne dans des conditions réalistes.

C’est aussi vrai en électrification industrielle que dans le SaaS. Quand je construis des produits dans mes propres ventures comme Shopeno et IBHQ, les « interfaces » apparaissent sous forme de contrats d’API, de propriété des données et de handoffs opérationnels. La forme change. Le principe de gouvernance reste le même.

4) Tenir des stage gates exigeants où le financement suit les preuves, pas les annonces

Les stage gates ne sont pas de la bureaucratie. C’est, à ma connaissance, la seule manière scalable d’éviter que l’optimisme devienne une politique financière.

Je préfère des gates binaires et pilotés par les preuves :

1. Gate 0 : le périmètre et les interfaces sont baselinés. Si vous ne pouvez pas définir les coutures, vous ne pouvez pas chiffrer le système.
2. Gate 1 : la stratégie fournisseurs est choisie et la responsabilité d’intégration est explicite. Prime ou modulaire, mais avec un owner réel et un budget d’intégration.
3. Gate 2 : les risques critiques ont un plan de mitigation financé. Pas « on regardera ». Un plan avec des owners et des dates.
4. Gate 3 : les preuves existent. Tests passés, prototypes validés ou simulations opérationnelles réalisées. Le financement est débloqué sur preuve, pas sur narration.

C’est aussi là que les « calendriers politiques » font le plus de dégâts. Quand les délais deviennent non négociables, l’organisation échange discrètement de la certitude contre de la vitesse. Si vous acceptez cet arbitrage, vous avez besoin de gates plus durs, pas plus souples.

Le premier vrai échec, c’est d’accepter « on clarifiera plus tard » dans le plan

Je l’ai compris tôt dans ma carrière, pendant onze ans dans l’électronique de puissance et l’automatisation industrielle. Les systèmes étaient concrets. Ils tournaient dans des usines de traitement des eaux, des environnements HVAC et des lignes d’automatisation. Les modes de défaillance étaient tangibles.

Pourtant, les premiers échecs ressemblaient déjà à des sujets de management, pas à des sujets techniques : une clarification tardive des exigences, une décision manquante sur la responsabilité du commissioning, un fournisseur convaincu que quelqu’un d’autre validerait un cas limite. Pris isolément, chaque point semblait mineur. Ensemble, ils devenaient une réalité de coût et de planning.

Dans les programmes impliquant des acteurs publics et privés, l’ambiguïté devient encore plus dangereuse, car la responsabilité se fragmente naturellement. Chacun agit de bonne foi dans son périmètre. Personne ne porte le chiffre global.

Quand le chiffre appartient à tout le monde, il n’appartient à personne.

Si vous voulez un complément pratique, côté organisation, CEO-led transformation, the operator way: five mechanisms that prevent silo theater détaille les mécanismes internes qui empêchent que les handoffs deviennent des alibis.

Une checklist applicable dès ce trimestre

Si vous pilotez un programme complexe en ce moment, voici ce que je ferais dans les 30 prochains jours. Sans réorganisation.

• Publier le registre des interfaces. Listez chaque interface majeure (technique, commerciale, opérationnelle). Mettez un seul nom en face. Si vous ne pouvez pas nommer l’owner, vous venez d’identifier un futur dépassement.
• Baseliner le périmètre avec des règles de « changement autorisé ». Définissez les types de changements acceptables sans escalade et ceux qui doivent passer par une autorité de changement formelle.
• Choisir explicitement votre stratégie fournisseurs. Un fournisseur prime avec une responsabilité d’intégration réelle, ou un modèle modulaire avec un workstream d’intégration financé. Ne faites pas comme si vous pouviez obtenir les deux bénéfices sans en payer un.
• Transformer votre prochain stage gate en evidence gate. Fixez trois éléments de preuve qui doivent être vrais avant le prochain déblocage de financement : tests, prototypes, readiness au commissioning ou BOM chiffrée et validée. Les preuves l’emportent sur le récit.
• Installer une cadence de vérité des coûts. Un point hebdomadaire où l’estimation à terminaison (estimate at completion) est discutée, owners présents. Pas pour blâmer. Pour forcer la réalité tôt.

C’est la gouvernance comme système d’exploitation. Il ne s’agit pas d’être strict. Il s’agit d’être explicite tôt, pour ne pas être « surpris » plus tard.

Mon point de vue : la prévisibilité s’achète au départ

On entend souvent : « Il faut être agile. » Très bien. Mais l’agilité sans responsabilité, c’est de l’improvisation financée par quelqu’un d’autre.

Quand je regarde des programmes d’ampleur comme celui évoqué dans les critiques sur l’Energy Island de Bornholm, je ne vois pas l’histoire d’une personne qui échoue. Je vois une gouvernance qui laisse la vérité des coûts arriver après la vérité contractuelle.

Les dépassements budgétaires surprennent rarement. Ils surviennent quand on laisse les interfaces flotter, quand on laisse le périmètre dériver sans le chiffrer, et quand on laisse le financement suivre des annonces plutôt que des preuves. La solution n’est pas plus de reporting. La solution, c’est de décider tôt qui possède quoi, comment les changements sont chiffrés et quand la preuve devient non négociable.