MéthodeCahier des chargesPrototypeApplication métier
Cadrage d'un projet logiciel : étapes, ateliers, livrables et durée
10 min de lecture
Le cadrage d'un projet logiciel est la phase qui précède le développement : en quelques jours ou quelques semaines, il transforme une intention (« il nous faut un outil pour suivre les interventions ») en décisions écrites. Pourquoi ce logiciel, pour qui, avec quelles règles, connecté à quoi, ce qui entre dans la première version et ce qui attend. Il se déroule en entretiens et en ateliers avec un décideur, des utilisateurs et l'équipe de développement, et se termine par des livrables concrets : une note de cadrage, des parcours, un prototype, une liste priorisée et une estimation.
Un cadrage réussi ne se mesure pas à l'épaisseur du document. Il se mesure au nombre de questions tranchées avant que le développement commence.
Cadrage, cahier des charges, prototype : qui fait quoi
Les trois mots sont souvent confondus. Ils ne répondent pas aux mêmes questions.
| Élément | Question principale | Forme | Qui le produit |
|---|---|---|---|
| Cadrage | Pourquoi, pour qui, quoi d'abord ? | Ateliers et note de cadrage | Client et prestataire ensemble |
| Cahier des charges | Que doit faire le logiciel, exactement ? | Document détaillé | Le client, souvent aidé |
| Prototype | À quoi cela ressemblera, et est-ce le bon parcours ? | Écrans cliquables | Le prestataire, validé par les utilisateurs |
Le cadrage est la démarche ; le cahier des charges et le prototype en sont deux produits possibles. Pour un outil interne, un prototype validé et une liste de règles métier remplacent souvent avantageusement un long cahier des charges. Notre guide pour rédiger le cahier des charges d'une application interne explique quand le document reste indispensable.
Les sept questions qu'un cadrage doit trancher
Un cadrage est terminé quand chacune de ces questions a une réponse écrite, même provisoire.
- Quel problème résout-on, et comment saura-t-on qu'il est résolu ? Un objectif mesurable : moins de ressaisies, un délai de traitement raccourci, des erreurs de facturation évitées.
- Pour qui ? Les profils d'utilisateurs, leur contexte (bureau, terrain, mobile), leur aisance avec l'outil.
- Quelles règles métier ? Les circuits de validation, les calculs, les statuts, et surtout leurs exceptions.
- Avec quels outils existants ? ERP, comptabilité, CRM, messagerie, tableurs : ce qu'on lit, ce qu'on écrit, quel outil reste maître de chaque donnée.
- Sous quelles contraintes ? Données personnelles, sécurité, hébergement, accessibilité, obligations sectorielles.
- Quoi en premier ? Le périmètre de la première version, et la liste explicite de ce qui en est exclu.
- Combien, quand, et qui décide ? Une enveloppe, une échéance, un décideur nommé pour les arbitrages.
La sixième question est celle qui économise le plus d'argent. Notre article sur ce qu'il faut développer dans un MVP aide à tracer cette frontière.
Le déroulé d'un cadrage, étape par étape
Le format varie selon la taille du projet, mais on retrouve presque toujours les mêmes temps.
1. L'entretien de lancement
Une réunion avec le décideur et le référent métier. On y pose le contexte, l'objectif, l'enveloppe et l'échéance, et on dresse la liste des personnes à rencontrer et des documents à réunir : exports de données, modèles de documents, captures des outils actuels. Il en sort une liste de questions ouvertes, qui servira de fil rouge.
2. L'observation du terrain
C'est l'étape la plus souvent sautée, et la plus rentable. Regarder un utilisateur travailler une heure apprend plus qu'une journée de réunion : le tableur annexe que personne n'a mentionné, la double saisie du vendredi, le contournement que tout le monde pratique. Quelques entretiens courts avec les futurs utilisateurs suffisent souvent.
3. Les ateliers de cadrage
Ce sont des séances de travail courtes, chacune sur un sujet :
- l'atelier parcours : dérouler, étape par étape, ce que fait chaque profil, du déclencheur au résultat ;
- l'atelier règles : pour chaque étape, les conditions, les calculs, les cas particuliers, les erreurs possibles ;
- l'atelier données et intégrations : d'où vient chaque information, où elle doit aller, dans quel format ;
- l'atelier priorisation : classer chaque besoin en indispensable, utile plus tard ou confort, puis tracer la ligne de la première version.
Un atelier efficace a un objectif écrit, un animateur, un preneur de notes et se termine par la liste des décisions prises et des questions restantes, avec un responsable pour chacune.
4. L'inventaire technique
En parallèle, l'équipe de développement examine l'existant : API des outils à connecter, qualité des données à reprendre, contraintes d'hébergement et de sécurité. C'est ici qu'on découvre l'ERP sans API ou l'export qui tronque les accents. Notre article sur l'intégration à un ERP existant liste les points à vérifier.
5. Le prototype
Les décisions prises en atelier deviennent des écrans. Un prototype cliquable, montré aux utilisateurs, fait apparaître ce qu'aucun compte rendu ne révèle : un champ manquant, un écran inutile, un ordre d'étapes qui ne correspond pas au terrain. Une ou deux itérations suffisent généralement à stabiliser les parcours principaux.
6. La restitution
Une dernière séance présente les livrables au décideur, qui valide le périmètre de la première version, l'estimation et le planning, ou demande des arbitrages. Le cadrage se termine sur une décision : lancer, ajuster, ou renoncer.
Qui participe, et avec quel rôle
| Participant | Rôle dans le cadrage | Ce qui se passe s'il manque |
|---|---|---|
| Décideur (dirigeant, directeur métier) | Fixe l'objectif, tranche les arbitrages | Les décisions restent en suspens |
| Référent métier | Connaît le processus et ses exceptions | Les règles sont incomplètes |
| Futurs utilisateurs | Décrivent le terrain, testent le prototype | Le logiciel est conçu pour un processus théorique |
| Référent des outils existants | Connaît les accès, exports et API | Les intégrations sont chiffrées au jugé |
| Profil produit (prestataire) | Anime, formalise, prototype | Les ateliers tournent en réunions |
| Développeur (prestataire) | Évalue la faisabilité et les risques | L'estimation repose sur des suppositions |
Deux remarques. Le décideur n'a pas besoin d'assister à tous les ateliers, mais il doit être joignable et trancher vite. Et un cadrage mené sans aucun futur utilisateur produit presque toujours un logiciel que les équipes contournent.
Les livrables d'un cadrage
À la fin d'un cadrage, vous devriez disposer de :
- une note de cadrage : contexte, objectif mesurable, périmètre et exclusions, acteurs, contraintes, risques, enveloppe et calendrier visés ;
- les parcours utilisateurs par profil ;
- la liste des règles métier, exceptions comprises ;
- l'inventaire des intégrations et des données à reprendre, avec l'outil maître de chaque donnée ;
- un prototype validé par les utilisateurs ;
- une liste priorisée des fonctions, avec la ligne de la première version ;
- une estimation en fourchette et ses hypothèses ;
- un planning macro et les jalons de validation ;
- un registre des risques et des questions encore ouvertes.
Sur les contraintes, un point mérite d'être traité dès ce stade : le RGPD impose, à son article 25, la protection des données dès la conception. Le cadrage est le bon moment pour lister les données personnelles traitées, leur durée de conservation et les droits d'accès par profil. Notre article sur le RGPD dans une application métier détaille la démarche.
Combien de temps dure un cadrage
La durée dépend moins de la technique que de deux facteurs : l'étendue du périmètre et la disponibilité des personnes qui décident. À titre d'orientation :
| Type de projet | Profondeur de cadrage adaptée |
|---|---|
| Outil interne simple, un ou deux profils | Quelques jours d'échanges et un prototype |
| Application métier avec intégrations | Une série d'ateliers, un inventaire technique et un prototype itéré |
| Produit ouvert à des clients (SaaS, portail) | Plusieurs semaines, avec entretiens utilisateurs et tests du prototype |
Un cadrage qui s'allonge sans produire de décisions est un signal : soit le décideur n'est pas disponible, soit l'objectif n'est pas partagé. Mieux vaut le constater pendant le cadrage que pendant le développement.
Cadrage gratuit ou payant ?
Les deux existent. Un cadrage léger, intégré à l'avant-vente, convient aux projets au périmètre clair. Un cadrage rémunéré se justifie quand les règles sont nombreuses, les intégrations incertaines ou les utilisateurs dispersés : il mobilise plusieurs personnes pendant plusieurs jours.
Dans les deux cas, vérifiez trois points avant de commencer :
- Les livrables sont-ils lisibles par une autre équipe ? Un cadrage n'a de valeur que s'il reste utilisable sans son auteur.
- À qui appartiennent-ils ? Les droits sur les documents, maquettes et prototypes sont définis au cas par cas dans le contrat : lisez la clause.
- Quelle décision permet-il ? Le cadrage doit déboucher sur une estimation exploitable. Notre article sur l'estimation d'un projet logiciel explique comment la lire.
Les erreurs de cadrage les plus fréquentes
- Cadrer la solution au lieu du problème. Arriver avec une liste de fonctionnalités empêche de découvrir qu'une partie du besoin se règle autrement, parfois sans développement.
- Oublier les exceptions. Le cas général tient en une phrase ; les exceptions font le coût. Un atelier règles qui n'en trouve aucune n'a pas creusé.
- Exclure les utilisateurs. Un cadrage entre dirigeants et prestataire décrit le processus tel qu'on l'imagine, pas tel qu'il se pratique.
- Ne rien exclure. Une note de cadrage sans liste d'exclusions laisse la porte ouverte à toutes les attentes implicites.
- Confondre exhaustivité et précision. Un document de cent pages ne remplace pas dix décisions claires.
- Laisser le cadrage se périmer. Un périmètre validé puis laissé de côté pendant des mois doit être revu avant le lancement.
Quand un cadrage lourd est inutile
Tous les projets n'ont pas besoin d'une série d'ateliers. Pour un outil simple, utilisé par une seule équipe, dont le processus est stable et connu, un entretien approfondi suivi d'un prototype suffit : chaque semaine de cadrage supplémentaire coûte plus que l'erreur qu'elle évite. À l'inverse, pour un produit nouveau dont personne ne connaît encore les bonnes fonctions, aucun cadrage ne remplace la mise entre les mains d'utilisateurs réels : cadrez une première version courte, livrez, mesurez, puis cadrez la suivante.
Les signes d'un cadrage réussi
- Le décideur peut expliquer l'objectif et ses indicateurs en deux phrases.
- Les utilisateurs se reconnaissent dans les parcours du prototype.
- La liste des exclusions existe et a été validée.
- Chaque intégration a été vérifiée, pas seulement nommée.
- L'estimation est une fourchette dont les hypothèses sont écrites.
- Les questions ouvertes restantes ont un responsable et une date.
Par où commencer
- Écrivez une page : le problème, les utilisateurs, les outils en place, l'enveloppe et l'échéance.
- Nommez un décideur disponible pour trancher.
- Réunissez des exemples réels : exports, documents, captures d'écran.
- Rendez le besoin visible le plus tôt possible.
Pour cette dernière étape, nous construisons un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés à partir d'un premier échange de cadrage : vous voyez vos parcours sous forme d'écrans avant d'engager quoi que ce soit. Notre article voir son logiciel avant de le payer explique ce que ce prototype contient, et ce qu'il ne remplace pas.