Applications & SaaS 
La réponse en bref
Un cadrage produit doit permettre de décider quel problème traiter, pour quels utilisateurs, avec quel premier périmètre et sous quelles conditions. Il rend visibles les faits, les hypothèses, les risques et les responsabilités qui déterminent la suite. Ses livrables servent à choisir entre engager une première réalisation, mener un essai complémentaire ou revoir l’orientation du projet.
Trois résultats à rechercher
- 01Un problème et un parcours prioritaire compris par les équipes métier, design et technique.
- 02Un périmètre explicite, avec ses exclusions et les incertitudes encore ouvertes.
- 03Une décision argumentée sur la prochaine étape, ses validations et ses responsables.
01
Mettre une décision précise au centre du cadrage
Au début d’un projet, une demande peut sembler claire : créer une application, remplacer un outil ou ajouter de l’IA à un processus. Pourtant, ces formulations laissent ouvertes les questions qui orientent la réalisation. Quel problème faut-il résoudre en premier ? Qui le rencontre ? Quelle amélioration attend-on et comment l’observer ?
Le cadrage produit rassemble le travail nécessaire pour préparer ces décisions. Son périmètre dépend de ce que l’équipe sait déjà et des inconnues qui peuvent modifier le projet. Dans cet article, il couvre la compréhension du besoin et la préparation de la suite ; un prototype ou un essai technique peut prolonger ce travail lorsque son objectif est défini.
Le Service Manual britannique présente la phase de discovery comme un moyen de comprendre le problème avant de décider de poursuivre. Pour votre projet, formulez de la même manière une question de départ et la décision attendue à la fin de la mission. Cela aide à choisir les investigations utiles.
Trois questions de départ possibles
- 01
Quel usage traiter d’abord ?
Choisir un parcours qui apporte une utilité identifiable à un public défini.
- 02
Faut-il construire ou adapter ?
Examiner les outils disponibles, l’existant et le travail réellement nécessaire.
- 03
Quelle incertitude lever ?
Identifier l’information manquante qui peut changer le périmètre ou la décision de poursuivre.
02
Comprendre les usages et distinguer les faits des hypothèses
Décrivez comment le travail se déroule aujourd’hui : ce qui déclenche une demande, les personnes impliquées, les informations utilisées et le résultat attendu. Les fichiers, les échanges, les outils et les incidents donnent des éléments concrets à examiner. Incluez les personnes qui utilisent le produit et celles qui assurent le service autour de lui.
La documentation GOV.UK recommande d’observer ou d’interroger des utilisateurs réels ou probables et de traiter les opinions non vérifiées comme des hypothèses. Dans votre dossier, indiquez donc l’origine d’un constat et les limites de ce qui a été observé. Un besoin exprimé en réunion peut ouvrir une question de recherche plutôt que devenir immédiatement une fonctionnalité.
Rendez les désaccords visibles. Un responsable peut chercher une meilleure vue d’ensemble alors qu’un utilisateur souhaite réduire une ressaisie. Ces objectifs peuvent se rejoindre, mais il faut expliquer comment. Définissez aussi les situations particulières : mobilité, connexion limitée, besoin d’assistance ou exigences d’accessibilité.
Qualifier les informations recueillies
- 01
Fait observé
Un comportement, un document ou une mesure dont l’origine et le contexte sont connus.
- 02
Hypothèse
Une explication ou une attente qui demande encore une vérification.
- 03
Contrainte
Une condition à respecter, avec son responsable et sa possibilité d’évolution.
- 04
Question ouverte
Une information manquante, son effet possible sur le projet et la façon de l’obtenir.
03
Transformer les idées en un premier périmètre utilisable
Une liste d’idées doit être reliée à un parcours complet. Pour une première version, précisez qui commence une action, avec quelles données, quelles validations et quelle issue. Incluez les états d’attente, les erreurs et les situations où une personne doit reprendre la main. Le périmètre devient alors plus compréhensible qu’un simple nombre d’écrans.
Choisissez ce qui est nécessaire pour rendre ce parcours utilisable et ce qui pourra attendre. Si une étape reste manuelle au départ, décrivez qui la réalise et comment elle s’articule avec le produit. Une première version limitée peut être cohérente ; une succession d’écrans sans résultat complet reste difficile à évaluer.
Consignez les exclusions avec leur raison et les conditions qui pourraient conduire à les réexaminer. La priorisation devient une décision partagée, plutôt qu’une liste de souhaits dont chacun conserve une interprétation différente. Le cahier des charges pourra ensuite formaliser ce périmètre et les critères attendus.
Quatre destinations pour chaque idée
- 01
Dans la première version
L’élément est nécessaire au parcours prioritaire et ses critères de validation sont décrits.
- 02
Dans une évolution future
L’utilité est identifiée, mais l’élément peut attendre sans bloquer le premier usage.
- 03
À vérifier
Une hypothèse ou une dépendance doit être examinée avant de décider.
- 04
Hors périmètre
L’élément est écarté de la mission, avec une explication compréhensible par l’équipe.
Formaliser les décisions dans un brief
04
Choisir la bonne preuve pour les incertitudes importantes
Classez les questions selon leur effet possible sur la décision. Si un besoin est encore incertain, examinez les usages. Si un parcours semble difficile à comprendre, testez une représentation adaptée. Si le produit dépend d’une connexion à un service externe, vérifiez cette intégration dans des conditions pertinentes. Chaque essai doit répondre à une question explicite.
Le Service Manual réserve la phase alpha à l’exploration de solutions par des prototypes et des essais centrés sur les hypothèses les plus risquées. Ces essais ne constituent pas un service prêt pour la production. Cette distinction aide à préciser ce qu’une maquette ou une démonstration permet réellement de conclure.
Une maquette cliquable peut éclairer la compréhension d’un parcours sans prouver la faisabilité d’une synchronisation. Un essai technique peut valider un échange de données sans démontrer que les utilisateurs adopteront le service. Notez les conditions, les observations, les limites et la décision qui en découle.
Relier une question à un essai
- 01
Question
Quelle incertitude peut modifier le projet ?
- 02
Essai
Quelle observation, maquette ou vérification peut y répondre ?
- 03
Résultat
Qu’a-t-on constaté, dans quelles conditions et avec quelles limites ?
- 04
Décision
Que conserve-t-on, que change-t-on et que reste-t-il à examiner ?
05
Relier le périmètre au budget, aux dépendances et aux responsabilités
Le cadrage doit permettre de comprendre ce qu’une estimation couvre. Examinez les parcours, les rôles, les données à reprendre, les connexions, les contenus, les tests et le fonctionnement après lancement. Précisez les hypothèses encore ouvertes et la manière dont elles peuvent modifier le travail prévu.
Le calendrier dépend aussi de contributions extérieures au développement : accès à un outil, disponibilité d’un expert métier, préparation de contenus ou validation d’un choix. Identifiez le responsable de chaque dépendance et le moment où elle devient nécessaire. Une échéance souhaitée doit être confrontée à ces conditions avant de devenir un engagement.
Enfin, répartissez les décisions. Qui arbitre le périmètre, valide un parcours, confirme une règle métier et accepte une livraison ? Associez les sujets de sécurité, d’accessibilité et d’exploitation aux personnes capables de les traiter. Le budget et le planning deviennent plus utiles lorsque cette organisation est visible.
Ce qui doit accompagner une estimation
- Un périmètre et des livrables identifiés
- Les inclusions, exclusions et hypothèses
- Les données, accès et services dont dépend la réalisation
- Les contributions attendues de chaque équipe
- Les validations et les responsables des arbitrages
- Le suivi, la maintenance et les dépenses récurrentes à prévoir
06
Produire des livrables qui conservent les décisions
Un livrable doit être réutilisable par les personnes qui vont concevoir, développer et suivre le produit. Il peut prendre la forme d’un document, d’un parcours annoté ou d’un ensemble de fichiers partagés. Son intérêt tient à ce qu’il rend explicite et à la façon dont l’équipe peut le maintenir à jour.
Conservez un journal des décisions : question posée, éléments disponibles, choix retenu, conséquences et condition de réexamen. Cela permet à une nouvelle personne de comprendre le raisonnement et évite de rouvrir un sujet sans information nouvelle. Les points encore incertains doivent rester identifiables.
L’exemple ci-dessous est fictif. Il illustre le niveau de précision attendu dans une décision de cadrage et ne décrit ni un projet ni un résultat client de Gaspa.
Six livrables à adapter à la mission
- 01
Problème et objectifs
Public concerné, situation actuelle, changement attendu et manière de l’observer.
- 02
Parcours prioritaire
Actions, rôles, informations, exceptions et issue attendue.
- 03
Périmètre initial
Fonctions retenues, exclusions et priorités pour la suite.
- 04
Risques et essais
Hypothèses, vérifications réalisées, résultats et inconnues restantes.
- 05
Cadre de réalisation
Dépendances, responsabilités, hypothèses d’estimation et validations.
- 06
Décisions et prochaine étape
Choix argumentés, conditions de réexamen et actions attribuées.
07
Savoir quand engager la prochaine étape
Le cadrage peut se terminer quand l’équipe dispose des informations suffisantes pour prendre la décision prévue, avec des incertitudes restantes comprises et attribuées. Il ne demande pas de dessiner chaque écran ou de résoudre à l’avance toutes les évolutions futures. En revanche, une inconnue capable de remettre en cause le premier usage doit être traitée explicitement.
Trois suites sont possibles : engager un premier lot défini, réaliser une investigation complémentaire ou réorienter le projet. Précisez pourquoi cette suite est retenue, qui la valide et quels éléments pourront la faire évoluer. Les prochaines vérifications doivent avoir un objectif et un responsable.
Après lancement, distinguez la validation d’une livraison et l’évaluation de son utilité. Un parcours peut fonctionner comme prévu tout en demandant des ajustements d’usage. Prévoyez les observations et retours nécessaires pour décider des versions suivantes, avec un état de référence lorsque celui-ci est disponible.
Les questions de sortie du cadrage
- Le problème et les utilisateurs prioritaires sont-ils compris ?
- Le premier parcours permet-il d’obtenir un résultat complet ?
- Les exclusions et les critères de validation sont-ils explicites ?
- Les incertitudes importantes ont-elles une réponse ou une prochaine vérification ?
- Les dépendances et les responsabilités sont-elles attribuées ?
- La prochaine étape et les conditions de sa réévaluation sont-elles partagées ?
08
Comment Gaspa organise cette continuité
Chez Gaspa, la méthode relie cadrage, design, développement et suivi. Un interlocuteur principal centralise les informations et les experts concernés participent aux décisions de leur domaine. Le périmètre, les livrables et les responsabilités sont précisés avec votre équipe avant la mission.
Les validations et le suivi partagé servent à conserver le contexte lorsque le projet avance. Si un changement affecte le périmètre, le budget ou le calendrier, son impact est présenté avant sa réalisation. Une mission peut commencer par le cadrage ou la conception, avec des objectifs et des livrables convenus avant de poursuivre.
Pour préparer un premier échange, rassemblez la situation actuelle, les personnes concernées, les outils existants et les questions qui empêchent de décider. Ces éléments permettront de définir un travail de cadrage proportionné au besoin, puis une suite compréhensible pour les équipes métier, design et technique.
Préparer la suite avec Gaspa
- Découvrir la méthode GaspaSuivi partagé, démonstrations, décisions et validations au fil du projet.
- Product design et conception de prototypesClarifier le besoin, les priorités et les parcours avant la réalisation.
- Comment choisir une agence pour son projet digital ?Comparer l’équipe, les références, les livrables et les modalités de collaboration.
- Reprendre ou réécrire une application existante ?Examiner les options lorsque le cadrage porte sur un produit déjà en service.