Le premier périmètre n’est pas une version réduite du produit final.

Pourquoi la réduction uniforme échoue

Imaginons un portail destiné à des partenaires : consultation de dossiers, dépôt de documents, suivi des demandes, messagerie, tableaux de bord, gestion des accès. Le devis dépasse l’enveloppe. On retire donc un peu partout : la messagerie devient un formulaire, les tableaux de bord perdent leurs filtres, la gestion des accès se réduit à deux rôles.

Le résultat est un produit qui touche à tout et ne termine rien. Un partenaire peut déposer un document mais pas savoir s’il a été reçu. Il peut consulter un dossier mais pas obtenir de réponse. Chaque parcours s’interrompt avant son point d’utilité, ce qui laisse l’organisation sans preuve : l’usage faible ne dira pas si le besoin était mal ciblé ou si le produit était simplement inachevé.

L’alternative n’est pas de livrer moins, mais de livrer entièrement une portion plus étroite. Un seul parcours, mené jusqu’au bout, produit un usage réel et une information exploitable.

Partir de la question, pas de la liste

Un premier périmètre utile répond à une question dont la réponse changera la suite du projet. Cette question s’écrit en une phrase, et elle est rarement technique.

• Les partenaires déposeront-ils leurs documents eux-mêmes, ou continueront-ils à les envoyer par courriel ?
• Les équipes internes accepteront-elles de traiter les demandes dans un nouvel outil plutôt que dans leur boîte de réception ?
• Les données existantes sont-elles assez propres pour être montrées telles quelles à un client ?

Chacune de ces questions dicte un périmètre différent, et aucune ne se réduit à « faire une version simplifiée de tout ». La troisième, par exemple, peut se trancher avec un écran en lecture seule, sans authentification élaborée ni interface soignée — et elle évite parfois de construire un produit sur des données inutilisables.

Une première livraison ne se juge pas à ce qu’elle contient, mais à ce qu’elle permet de décider ensuite.

Cadrer par l’appétit plutôt que par l’estimation

L’estimation part de la portée et en déduit une durée. La méthode décrite par Basecamp dans Shape Up inverse la logique : on fixe d’abord l’appétit — le temps qu’on accepte de consacrer au problème — puis on conçoit une solution qui tient dans cette contrainte. Une estimation répond à « combien de temps faut-il ? » ; un appétit répond à « combien de temps cela mérite-t-il ? ».

Le renversement a un effet pratique immédiat : la contrainte devient un instrument de conception plutôt qu’une mauvaise nouvelle. Quand six semaines sont fixées d’avance, la discussion porte sur ce qui rentre dedans en étant complet, pas sur la manière d’étirer le calendrier.

Cette discipline rejoint un principe formulé de longue date par Martin Fowler sous le nom de YAGNI : ne pas construire une capacité tant qu’elle n’est pas réellement demandée, parce que le coût d’une fonctionnalité anticipée n’est pas seulement son développement — c’est aussi ce qu’elle complique tant qu’elle existe.

Écrire ce qu’on écarte

La partie la plus souvent négligée d’un cadrage est la liste de ce qui n’est pas fait. Sans elle, chaque comité rouvre le même débat, et chaque nouvelle partie prenante réintroduit une exigence déjà tranchée.

Les équipes produit expérimentées, comme celles que décrit le Silicon Valley Product Group dans ses travaux sur la découverte produit, consacrent une part importante de leur travail à cette élimination : la valeur d’une phase de cadrage se mesure autant aux idées écartées qu’aux fonctionnalités retenues.

Un premier périmètre réussi ne ressemble donc pas à une miniature du produit cible. Il ressemble à un segment complet, volontairement étroit, accompagné d’une liste assumée de ce qui viendra plus tard — et d’une réponse claire à la question qui justifiait de commencer.