Cadrage produit : décider quoi construire avant de développer

Une demande d’application arrive souvent sous la forme d’une liste : connexion, tableau de bord, notifications, paiement, espace administrateur. Cette liste décrit des écrans et des fonctions. Elle ne dit pas encore ce qui justifie leur développement, ni lesquels doivent exister dès la première version.

Le cadrage produit sert à prendre ces décisions. Son résultat doit permettre à la personne qui finance le projet, à celle qui le conçoit et à celle qui le développe de travailler sur le même périmètre. Voici une trame de travail pour y parvenir.

1. Décrire une situation avant de dessiner une solution

Commencez par une phrase concrète : « Quand cette personne rencontre cette situation, elle doit pouvoir accomplir cette action. » Ajoutez ce qui se passe aujourd’hui, la difficulté rencontrée et la conséquence pour l’activité.

« Nous voulons un espace client » laisse beaucoup de possibilités ouvertes. « Nos clients appellent pour savoir où en est leur demande, car ils ne reçoivent aucune information entre son dépôt et sa résolution » permet déjà de discuter d’options : meilleure notification, page de suivi ou modification du traitement interne.

Cette démarche rejoint un principe du Service Manual britannique : comprendre le problème, les utilisateurs et les contraintes avant d’engager la construction du service. Source : phase de découverte, GOV.UK.

Pour votre projet, rassemblez les éléments disponibles : demandes au support, échanges commerciaux, observation du travail réel et limites de l’outil actuel. Distinguez dans vos notes ce qui est observé, ce qui est rapporté et ce qui reste supposé.

2. Choisir un parcours prioritaire complet

Prenons un exemple pédagogique : une entreprise souhaite une application de réservation de matériel. Ce n’est pas un cas client Black Tide.

Le premier parcours peut être : trouver un équipement adapté, connaître sa disponibilité, demander une réservation et recevoir une confirmation. Ce parcours oblige aussi à traiter une indisponibilité, un refus et une annulation. Il implique probablement une personne qui valide la demande côté entreprise.

Décrivez donc le début, les étapes, la fin et les principales exceptions. Une première version peut couvrir peu de situations, tout en permettant d’accomplir une tâche jusqu’au bout. Le nombre d’écrans ne suffit pas à définir ce périmètre.

3. Mettre les incertitudes au premier plan

Toutes les questions ouvertes n’ont pas le même effet sur la suite. Dans notre exemple, l’accès fiable aux disponibilités peut conditionner tout le parcours. Le choix d’une animation de confirmation peut attendre.

Utilisez une grille courte :

Associez à chaque question un responsable et une prochaine action. Vous obtenez un plan d’investigation utile au produit, au design et à l’ingénierie.

4. Choisir ce que le prototype doit permettre d’apprendre

Un prototype peut servir à examiner l’ordre des étapes, la compréhension d’un libellé ou la capacité à retrouver une information. Une maquette de réservation ne démontre cependant pas que les disponibilités seront exactes en production.

Préparez une tâche réaliste, observez le parcours suivi et notez les hésitations. Pour une incertitude d’intégration, réalisez plutôt un essai technique limité. Le choix de la méthode doit suivre la question à résoudre ; le Service Manual propose aussi cette logique pour planifier la recherche utilisateur. Source : planifier la recherche, GOV.UK.

Consignez ce que vous avez appris, ses limites et la décision qui en découle. Une préférence exprimée pendant un entretien ne suffit pas à établir que la fonctionnalité sera utilisée régulièrement.

5. Définir le premier lot et ses limites

Dans l’exemple de réservation, une équipe pourrait retenir une demande validée manuellement avant d’automatiser l’allocation du matériel. Ce choix dépend de son volume, de son organisation et du délai de réponse acceptable. Il n’est pas universel.

Pour chaque élément du premier lot, précisez :

• l’action que l’utilisateur pourra accomplir ;
• les règles et les principales situations d’échec ;
• les données, accès et intégrations nécessaires ;
• les critères permettant d’accepter la livraison ;
• ce qui est explicitement reporté.

Un critère exploitable serait : « Si la demande est refusée, le client voit son nouvel état et reçoit l’information prévue ; le matériel n’est pas bloqué. » Il donne une base commune à la conception, au développement et à la recette.

6. Préparer une estimation avec ses hypothèses

Une estimation doit préciser ce qu’elle couvre : interface, backend, reprise de données, intégrations, tests, mise en service et préparation de l’exploitation selon le projet. Les comptes nécessaires, la disponibilité des interlocuteurs et les dépendances externes doivent aussi apparaître.

Gardez les inconnues visibles. Si l’accès à un système tiers n’est pas confirmé, indiquez l’hypothèse utilisée et la manière dont une conclusion différente modifierait le périmètre. Fixez également qui décide lorsqu’une nouvelle demande entre en concurrence avec le premier lot.

Le cadrage prépare un engagement compréhensible. Il ne supprime ni les imprévus ni le besoin de revoir certaines décisions après usage.

Ce que vous devez avoir à la fin

Le support peut rester court : situation à résoudre, utilisateurs concernés, parcours prioritaire, enseignements recueillis, périmètre retenu, exclusions, dépendances, critères d’acceptation et questions restantes. Chaque élément doit aider à prendre une décision ou à réaliser le travail.

À partir de là, les choix techniques peuvent être examinés dans leur contexte. Notre article Flutter ou natif iOS/Android développe notamment les critères propres à une application mobile.

Vous préparez un nouveau produit ou une évolution importante ? Découvrez notre accompagnement en création et évolution de produits, ou parlons du périmètre à cadrer.