La phase de cadrage est l’étape courte, menée avant tout développement, qui transforme une intention (« il nous faut un outil pour gérer les interventions ») en un projet défini et finançable. Elle fixe des objectifs mesurables, un périmètre priorisé, une solution esquissée (parcours, écrans clés, architecture), les risques et une estimation argumentée. Elle repose sur des ateliers avec les décideurs et les futurs utilisateurs, et se conclut par une décision claire : lancer, ajuster ou renoncer.
C’est la phase la moins spectaculaire d’un projet web et pourtant la plus rentable. Une erreur de compréhension corrigée sur un tableau blanc ne coûte rien ; la même erreur découverte après trois mois de développement coûte des semaines. Voici comment se déroule un cadrage sérieux, ce qu’il doit produire et comment juger sa qualité.
À quoi sert vraiment la phase de cadrage ?
Le cadrage répond à cinq questions, dans cet ordre :
- Pourquoi ? Quel problème résout-on, pour qui, et comment saura-t-on que c’est réussi ?
- Pour qui ? Quels utilisateurs, avec quelles tâches, quelles contraintes, quel environnement de travail ?
- Quoi ? Quelles fonctionnalités, priorisées selon leur contribution aux objectifs ?
- Comment ? Quelle solution : sur mesure, outil du marché, combinaison des deux ; quelle architecture, quelles intégrations ?
- Combien et quand ? Quel effort, quel calendrier, quelles étapes de livraison, quels risques ?
L’administration française a formalisé une démarche proche dans son programme d’incubation beta.gouv.fr : avant de construire un service numérique, une phase d’investigation d’un à deux mois vérifie que le problème peut être résolu par le numérique, en allant rencontrer les utilisateurs pour préciser le problème et esquisser des pistes. Le principe vaut pour une PME ou une ETI : on ne finance pas une solution avant d’avoir confirmé le problème.
Le Design Council britannique décrit la même logique avec son double diamant, introduit en 2003 : on découvre le problème réel avant de le définir, puis on développe des pistes avant de livrer. Le cadrage couvre le premier diamant et amorce le second.
Qui participe, et avec quel rôle ?
Un cadrage échoue rarement par manque de méthode. Il échoue parce que les bonnes personnes n’étaient pas dans la pièce, ou qu’aucune n’avait le pouvoir d’arbitrer.
| Rôle | Côté | Contribution attendue |
|---|---|---|
| Sponsor (DG, directeur métier) | Client | Fixe les objectifs, arbitre les priorités, engage le budget |
| Chef de projet ou product owner | Client | Disponible, coordonne les métiers, valide les livrables |
| Utilisateurs représentatifs | Client | Décrivent et montrent leur travail réel, testent les maquettes |
| Référent informatique | Client | Connaît l’existant, les données, les contraintes de sécurité |
| Chef de produit ou consultant | Prestataire | Anime les ateliers, structure le besoin, rédige la synthèse |
| Designer UX | Prestataire | Observe, cartographie les parcours, produit les maquettes |
| Architecte ou développeur senior | Prestataire | Évalue la faisabilité, les intégrations, l’estimation |
La présence d’un profil technique dès le cadrage n’est pas un luxe. C’est lui qui repère qu’une intégration supposée simple avec l’ERP n’a pas d’API, ou qu’une fonctionnalité anodine en apparence représente la moitié de l’effort.
Les ateliers d’une phase de cadrage
Le contenu varie selon le projet, mais un cadrage d’application métier comprend presque toujours les séquences suivantes.
Entretiens avec les parties prenantes
Des entretiens individuels avec la direction et les responsables métier. Le Nielsen Norman Group recommande de les structurer autour de quatre thèmes : la définition du succès, les priorités et difficultés, l’historique (contraintes, tentatives passées) et la façon dont chacun souhaite être impliqué. Sa question de clôture est précieuse : « Qui d’autre devrais-je rencontrer ? ». Ces entretiens révèlent souvent que deux directeurs n’attendent pas la même chose du projet.
Observation du terrain
Passer une demi-journée à côté d’un assistant ADV, d’un chef d’atelier ou d’un technicien vaut mieux que dix réunions. On y découvre les fichiers Excel parallèles, les post-it sur l’écran, les ressaisies, les contournements. C’est la base d’une bonne conception UX pour les applications métier.
Cartographie des processus et des irritants
Un atelier collectif pour dessiner le processus actuel de bout en bout, avec ses étapes, ses acteurs, ses outils et ses points de friction. Des formats comme l’Event Storming, où l’on colle au mur les événements métier dans l’ordre chronologique, font émerger en quelques heures des règles que personne n’avait écrites.
Carte d’impact
Une carte d’impact, popularisée par Gojko Adzic, relie chaque fonctionnalité envisagée à un changement de comportement d’un acteur, lui-même relié à un objectif de l’entreprise. Toute fonctionnalité qui ne se rattache à aucun objectif devient suspecte.
Story mapping et priorisation
La cartographie des user stories, formalisée par Jeff Patton, organise les fonctionnalités le long du parcours utilisateur, puis les découpe en tranches horizontales : la première tranche forme une version utilisable de bout en bout. C’est l’outil le plus efficace pour définir un premier lot réaliste, ou un MVP. Le détail de chaque fonctionnalité sera ensuite écrit sous forme de user stories avec critères d’acceptation.
Maquettage et tests rapides
Les écrans clés sont dessinés, d’abord en esquisses puis en maquettes cliquables, et testés avec quelques utilisateurs. Une maquette montrée en atelier provoque des réactions qu’aucun document ne suscite.
Quels livrables attendre à la fin du cadrage ?
Un cadrage doit produire des documents utilisables, et non un rapport que personne ne relira. Exigez au minimum :
| Livrable | Contenu | À quoi il sert |
|---|---|---|
| Note de cadrage | Contexte, objectifs mesurables, périmètre, hors périmètre, hypothèses, risques | Référence partagée pour toutes les décisions |
| Cartographie des processus et parcours | Processus cible, parcours par profil d’utilisateur | Aligner les métiers sur la façon de travailler demain |
| Backlog priorisé | Fonctionnalités découpées, ordonnées, regroupées en lots | Piloter le développement et arbitrer en cours de route |
| Maquettes des écrans clés | Écrans principaux testés avec des utilisateurs | Valider l’ergonomie avant le premier sprint |
| Architecture cible | Briques techniques, hébergement, intégrations, données | Anticiper les dépendances et les risques techniques |
| Plan de livraison et estimation | Lots, jalons, effort estimé, hypothèses de l’estimation | Décider et budgéter en connaissance de cause |
Le Scrum Guide définit le backlog produit comme une liste « émergente et ordonnée » de ce qui est nécessaire pour améliorer le produit, orientée vers un objectif produit qui décrit un état futur visé par l’équipe (Scrum Guide 2020). Le cadrage produit la première version de ces deux éléments ; ils évolueront ensuite à chaque sprint.
Vérifiez aussi dans le contrat que ces livrables vous appartiennent. Vous devez pouvoir les confier à une autre équipe si vous le souhaitez.
Les pièges les plus fréquents
- Cadrer sans les utilisateurs. Le projet est alors construit sur la vision du siège, et découvre le terrain au moment du déploiement.
- Confondre exhaustivité et précision. Un cadrage de deux cents pages n’est pas plus fiable ; il est seulement plus long à contredire.
- Ne rien mettre hors périmètre. Un périmètre sans frontière explicite s’étend toujours.
- Repousser les arbitrages. Si le sponsor n’est pas disponible pour trancher, les ateliers produisent des listes, pas des décisions.
- Estimer avant d’avoir compris. Une estimation donnée au premier rendez-vous est une intuition ; celle qui sort du cadrage repose sur un découpage.
- Sous-estimer l’existant. Reprise de données, intégrations, règles cachées dans un vieil outil : c’est là que se logent les dérives.
Comment juger la qualité d’un cadrage ?
À la fin, posez-vous quelques questions simples :
- Le sponsor, un utilisateur et le chef de projet du prestataire décrivent-ils le projet de la même façon ?
- Chaque fonctionnalité du premier lot se rattache-t-elle à un objectif mesurable ?
- Ce qui est hors périmètre est-il écrit noir sur blanc ?
- Les principaux risques ont-ils une parade ou une action de levée ?
- L’estimation explique-t-elle ses hypothèses, et ce qui la ferait varier ?
- Pourriez-vous lancer le développement avec une autre équipe à partir de ces livrables ?
Si les réponses sont oui, le cadrage a fait son travail. Il permet aussi de choisir le bon mode de contractualisation, forfait ou régie, et de comprendre ce qui pèsera sur le coût de l’application.
Le cadrage est la première étape de notre méthode, avant tout engagement sur le développement. Pour le préparer, vous pouvez partir de notre modèle de cahier des charges, ou décrire votre projet dans notre diagnostic en ligne : il prend deux minutes et nous aide à proposer un cadrage à la bonne taille.
