Piège 2 - Le périmètre

Le navire qui a navigué 1 300 mètres

Le 10 août 1628, une foule s’est rassemblée sur les quais de Stockholm pour voir le Vasa partir pour son voyage inaugural. C’était la fierté de la marine suédoise : 64 canons de bronze sur deux ponts d’artillerie, des centaines de sculptures peintes, un navire construit pour impressionner un roi et effrayer ses ennemis.

Quelques semaines plus tôt, sa stabilité avait été testée. Trente marins avaient couru d’un bord à l’autre du pont. Après trois passages, il roulait si fort que l’amiral a arrêté le test. Personne n’a arrêté le lancement.

Il a navigué environ 1 300 mètres. Une rafale de vent l’a fait gîter, l’eau s’est engouffrée par les sabords ouverts, et le Vasa a sombré dans le port, devant toute la ville.

La légende dit que le roi n’a cessé d’ajouter des canons et des ponts pendant la construction. Les historiens en doutent aujourd’hui ; même l’histoire a vu son périmètre grossir au fil des ans. Ce que personne ne conteste est plus simple : il a été construit pour porter plus que sa coque ne pouvait supporter, et le test qui le disait a été expliqué et écarté.

Une cabine de plus, un canon de plus

Chaque programme commence par un problème qui mérite d’être résolu. Puis les demandes arrivent. Le marketing veut un nouveau modèle de consentement depuis des années. Les risques aimeraient que le moteur de scoring soit remplacé tant qu’on y est. Un concurrent vient de lancer une fonctionnalité ; il nous la faut aussi.

Chaque demande est raisonnable. Chacune vient de quelqu’un d’important. Et chacune rend le programme plus gros et plus stratégique, ce qui le rend plus facile à financer. Alors personne ne s’y oppose. Un programme qui a commencé comme un correctif devient une transformation, avec le budget, le calendrier et le nombre de parties prenantes d’une transformation.

Personne n’ajoute un pont exprès. On ajoute une cabine, un canon, une sculpture. Une à la fois, le centre de gravité monte. L’équipe continue de construire, le plan reste au vert, et le premier vrai test est le voyage inaugural : la mise en production, devant toute la ville.

C’est cela, le piège du périmètre : laisser un programme grossir pour porter tout ce que tout le monde veut, jusqu’à ce qu’il ne puisse plus porter ce pour quoi il a été construit.

Les dix visages du piège

En 25 ans, je l’ai vu prendre dix formes, en trois familles : comment le périmètre entre, comment il grossit, et pourquoi il ne ressort jamais. La plupart des programmes surchargés en présentent au moins la moitié.

Comment le périmètre entre

La solution comme exigence. Le programme est lancé comme « un nouveau portail », « une plateforme de données » ou « un agent », pas comme un problème à résoudre. Une fois que la réponse est le périmètre, personne ne peut demander si une réponse plus modeste suffirait.
La liste de souhaits de chacun. Pour faire signer le business case, chaque partie prenante reçoit un élément en échange de son soutien. Le périmètre devient un traité de paix, pas une conception.
La plateforme avant le produit. Le programme construit de l’infrastructure pour des besoins que personne n’a encore : le moteur générique, le framework réutilisable, l’API que chaque équipe consommera un jour. Les utilisateurs d’aujourd’hui attendent ceux de demain.

Comment le périmètre grossit

« Tant qu’on y est. » Les trois mots les plus chers de l’informatique. L’équipe touche déjà au système, alors le changement d’à côté semble gratuit. Il ne l’est jamais : il apporte ses propres tests, données, dépendances et parties prenantes.
S’aligner sur le rival. Un concurrent livre quelque chose, et cela entre dans la liste sans que personne ne vérifie si vos clients le veulent.
Le parapluie de la conformité. Certaines exigences sont vraiment obligatoires. Mais une fois que « réglementaire » devient un mot de passe, tout s’abrite dessous, et personne n’ose demander quel article de quel texte exige réellement cette fonctionnalité.
Des changements sans prix. Le nouveau périmètre est accepté en atelier, consigné dans un backlog, et n’apparaît jamais dans la date ni dans le budget. Le plan reste au vert. Le navire s’alourdit.

Pourquoi le périmètre ne ressort jamais

Pas de non-objectifs. Le programme dit ce qu’il fera, jamais ce qu’il ne fera pas. Tout ce qui n’est pas explicitement exclu est permis, et chaque comité de pilotage le rouvre.
Réduire le périmètre comme un échec. Retirer une fonctionnalité ressemble à rompre une promesse faite à son sponsor, alors personne ne le propose. Les programmes ajoutent du périmètre facilement et n’en retirent qu’en cas de crise, quand le retrait coûte le plus cher.
Le test qu’on explique et qu’on écarte. Le test de performance échoue, les utilisateurs pilotes peinent, la répétition de migration prend trois fois plus de temps que prévu. Chaque résultat reçoit une explication, et aucun n’a le droit de changer le plan. L’amiral arrête le test, et le navire part quand même.

Le poids que personne ne pèse

La dérive du périmètre est si courante que nous avons cessé de la remarquer. Dans le Pulse of the Profession 2018 du PMI, environ la moitié des projets signalaient des changements non maîtrisés de leur périmètre. Et le coût est rarement là où on le cherche.

Le poids grossit plus vite que le périmètre. Chaque nouvelle fonctionnalité doit fonctionner avec chacune des existantes. Dix fonctionnalités font 45 paires possibles à concevoir, tester et maintenir. Vingt fonctionnalités en font 190. Doublez le périmètre, et vous quadruplez à peu près les interactions. C’est pourquoi les derniers 20 % du périmètre prennent si souvent la moitié du temps.

Une grande partie de la cargaison n’est jamais utilisée. L’analyse de Pendo sur l’usage des produits a montré que 80 % des fonctionnalités d’un logiciel moyen sont rarement ou jamais utilisées. Chacune d’elles a été un jour la priorité de quelqu’un. Chacune d’elles est encore maintenue, sécurisée et migrée.

Plus le navire est gros, plus il rate. Le rapport 2026 du PMI a montré que 31 % des projets complexes ne délivrent pas la totalité des bénéfices prévus, plus du double du taux de l’ensemble des projets.

Il y a aussi une asymétrie discrète. Chaque ajout a un sponsor qui le veut. Un retrait n’en a aucun, alors le périmètre ne bouge jamais que dans un sens, jusqu’à ce que la coque décide pour vous.

Signaux précoces

On peut sentir le navire commencer à gîter bien avant qu’il ne chavire :

Personne ne peut énoncer le problème en une phrase sur laquelle le sponsor et l’équipe sont tous deux d’accord.
La liste des parties prenantes ne cesse de s’allonger, et chaque nouvelle arrive avec ses exigences.
Le périmètre a grossi depuis le business case, et la date comme le budget n’ont pas bougé.
Il n’existe aucune liste écrite de ce que le programme ne fera pas.
« Tant qu’on y est » revient dans chaque atelier.
Les fonctionnalités sont justifiées par ce qu’ont les concurrents, pas par ce que font les clients.
Chaque exigence est étiquetée « réglementaire », et personne ne sait citer l’article.
En deux ans, rien n’a jamais été retiré du périmètre.
Un test ou un pilote a échoué, et la réponse a été une explication plutôt qu’une décision.

Garder le navire droit

La réponse n’est pas de refuser chaque demande. Les programmes doivent s’adapter à mesure qu’ils apprennent. C’est de rendre le périmètre visible, chiffré et réversible, pour que le navire soit conçu pour la charge qu’il porte réellement.

Partir du problème et du résultat. Écrivez le résultat comme un changement mesurable pour de vraies personnes : « un nouveau client peut ouvrir un compte en moins de dix minutes », pas « une nouvelle plateforme d’onboarding ». Chaque élément du périmètre doit pouvoir s’y rattacher.
Écrire les non-objectifs. Une liste courte et explicite de ce que le programme ne fera pas, signée par le sponsor. C’est le contrôle de risque le moins cher qu’un programme aura jamais, et il clôt un nombre surprenant de débats avant même qu’ils ne commencent.
Donner un budget au périmètre. Traitez le périmètre comme de l’argent : quelque chose de nouveau entre, quelque chose de taille similaire sort, ou bien la date et le budget changent ouvertement. Rien n’entre gratuitement.
Chiffrer chaque changement au moment de la décision. Montrez son effet sur la date, le coût et les risques dans la réunion même qui l’approuve. La plupart des dérives de périmètre ne survivent que parce que leur coût est invisible au moment où elles sont acceptées.
Livrer la plus petite chose qui prouve le résultat. Mettez tôt une tranche fine et réelle devant de vrais utilisateurs. Les données d’usage tranchent des débats que les ateliers ne trancheront jamais.
Le produit avant la plateforme. Construisez pour des besoins qui existent aujourd’hui, et laissez la plateforme grandir à mesure qu’arrivent le deuxième et le troisième produit. Généralisez à partir de cas réels, pas imaginaires.
Questionner le parapluie. Pour chaque exigence « réglementaire », nommez le texte et l’article. Gardez ce qui est vraiment exigé, au niveau où c’est exigé, et traitez le reste comme du périmètre ordinaire.
Rendre le retrait normal. Revoyez le périmètre chaque trimestre avec la même énergie que les ajouts. Retirez les fonctionnalités que personne n’utilise, et remerciez ceux qui proposent de retirer des choses : ils rendent au programme sa stabilité.
Donner à vos tests le pouvoir d’arrêter un lancement. Un test de stabilité qui ne peut pas retarder le voyage est du théâtre. Décidez à l’avance quels résultats arrêtent ou remodèlent une version, rendez-les visibles au sponsor, et protégez ceux qui apportent les mauvaises nouvelles. L’amiral avait besoin de quelqu’un à qui il avait le droit de le dire.

Ce qu’il faut éviter

Lancer un programme qui porte le nom d’une solution.
Acheter le soutien des parties prenantes avec du périmètre.
Accepter un changement sans montrer son coût en temps et en argent.
Construire une plateforme avant qu’un seul produit n’en ait besoin.
Traiter « réglementaire » comme une raison que personne ne peut questionner.
Célébrer les ajouts tout en traitant les retraits comme des échecs.
Expliquer et écarter un test échoué au lieu de décider ce qu’il change.

Le tournant de l’IA

L’IA rend chaque canon supplémentaire moins cher à couler. Une fonctionnalité qui prenait un sprint prend désormais un après-midi, alors « tant qu’on y est » n’a jamais semblé aussi raisonnable. Mais l’IA réduit le coût de construction, pas le poids à porter. Chaque fonctionnalité interagit toujours avec toutes les autres, doit toujours être sécurisée, maintenue, migrée et expliquée aux utilisateurs. Des ajouts bon marché signifient que le centre de gravité monte plus vite que jamais.

L’IA apporte aussi un nouveau visage à la première famille : la solution comme exigence, sous une nouvelle marque. Les programmes lancés sur le mode « il nous faut un agent » plutôt que « il nous faut résoudre ce problème » sont les Vasa de cette décennie. Gartner prévoit que plus de 40 % des projets d’IA agentique seront annulés d’ici fin 2027, en invoquant la hausse des coûts et une valeur métier peu claire.

Bien utilisée, en revanche, l’IA est une excellente ingénieure du lest. Elle peut construire un prototype jetable pour vérifier si les utilisateurs veulent une fonctionnalité avant que quiconque ne s’y engage. Elle peut analyser les données d’usage et lister les fonctionnalités que personne ne touche. Elle peut estimer en quelques minutes l’impact d’un changement sur la base de code, pour que chaque demande arrive avec son prix. Et elle peut faire remonter une exigence « réglementaire » jusqu’au texte, ou montrer que le texte ne dit pas ce que tout le monde supposait.

Construit pour sa charge

Le Vasa a été renfloué en 1961, remarquablement intact, et il se dresse aujourd’hui dans un musée de Stockholm. Les visiteurs en font le tour pendant des heures. Il est magnifique : chaque sculpture, chaque sabord, chaque ambition des hommes qui l’ont construit. Un navire parfait qui ne pouvait pas naviguer.

Les meilleurs programmes sur lesquels j’ai travaillé n’étaient pas les plus ambitieux sur le papier. C’étaient ceux qui avaient un sponsor capable de dire, calmement, « pas dans cette version », et une équipe remerciée aussi chaleureusement pour avoir retiré des choses que pour en avoir ajouté.

Alors, à votre prochaine revue de périmètre, posez une question en douceur : si nous devions lancer le mois prochain, que laisserions-nous sur le quai ? La réponse est généralement le périmètre que vous auriez dû avoir depuis le début.

Avez-vous déjà vu un programme embarquer un pont de trop ? J’aimerais sincèrement entendre votre histoire.

Toutes les situations décrites ici sont des composites, tirés de nombreux programmes sur 25 ans.