Cadrage de projet : la méthode complète pour cadrer un projet web ou logiciel

Qu’est-ce que le cadrage de projet ?

Le cadrage de projet est la phase qui précède le développement et qui fixe ce que l’on va construire : les objectifs, les utilisateurs, le périmètre fonctionnel, les priorités et l’estimation de l’effort. Son résultat n’est pas un document de plus mais une référence commune : le client, l’équipe et le devis parlent enfin du même projet.

À quoi sert le cadrage

• Aligner le client et l’équipe sur ce qui est dans le périmètre, et sur ce qui n’y est pas.
• Fonder le chiffrage : on estime des fonctionnalités décrites, pas une intention.
• Préparer le développement : chaque fonctionnalité arrive avec ses règles et ses critères d’acceptation.
• Préparer la recette : les tests découlent directement des critères écrits au cadrage.

Ce qu’il évite

Cadrage et cahier des charges : quelle différence ?

Les deux termes sont souvent confondus. Le cahier des charges est un document : il décrit le besoin, les fonctionnalités attendues et les contraintes, et il est parfois rédigé par le client avant de consulter des prestataires. Le cadrage est une démarche : on part de ce besoin, on le questionne, on le découpe et on le priorise jusqu’à obtenir un périmètre que l’on sait estimer et tester.

Ils sont complémentaires. Un cahier des charges fourni par le client est une excellente entrée de cadrage, rarement une sortie : il contient souvent des fonctionnalités floues (« gestion des utilisateurs »), des règles implicites et aucune priorité. À l’inverse, un bon cadrage produit un cahier des charges plus précis que celui de départ : chaque fonctionnalité y est nommée, décrite, reliée aux autres et accompagnée de ses critères d’acceptation.

Une règle simple : le cahier des charges dit ce que le client demande ; le cadrage dit ce que l’on va livrer, dans quel ordre et pour quel effort.

Les 10 étapes du cadrage de projet

Voici les étapes dans l’ordre où elles se font le plus souvent. Sur un petit projet, certaines prennent dix minutes ; aucune ne doit être sautée.

1. Recueillir le contexte : objectifs, utilisateurs, contraintes

   Avant de parler fonctionnalités, notez trois choses. Les objectifs : pourquoi ce projet existe, et comment le client saura qu’il a réussi. Les utilisateurs : qui va s’en servir, avec quels rôles (visiteur, membre, administrateur…). Les contraintes : échéance, budget, technologies imposées, outils existants, obligations réglementaires. Ces éléments servent ensuite d’arbitre : face à une fonctionnalité discutable, on revient à l’objectif.

2. Découper en modules et en fonctionnalités

   Regroupez le besoin en modules (réservation, facturation, administration…), puis découpez chaque module en fonctionnalités. Une bonne fonctionnalité se décrit en une phrase du point de vue de l’utilisateur, se livre et se teste seule. Donnez-lui un code court (RES-02, ABO-01) : il servira dans la documentation, les tickets, le devis et la recette, et évitera les « le truc de la réservation ».

3. Décrire chaque fonctionnalité : description, règles, critères d’acceptation

   Pour chaque fonctionnalité, écrivez trois blocs. La description : ce que fait l’utilisateur et ce qu’il obtient. Les règles : conditions, limites et cas particuliers (délais, droits, calculs). Les critères d’acceptation : les conditions vérifiables qui permettront de dire « c’est livré ». Un critère d’acceptation se vérifie par oui ou par non : « la page est rapide » n’en est pas un, « le compteur de places se met à jour sans recharger la page » en est un.

4. Relier les dépendances

   Certaines fonctionnalités n’ont de sens que si d’autres existent : on ne réserve pas sans planning, on ne gère pas de liste d’attente sans réservation. Notez ces liens explicitement. Ils servent à ordonner le développement, à découper les lots sans créer de trous, et à mesurer l’impact d’un changement : modifier une règle de réservation touche tout ce qui en dépend.

5. Dessiner l’arborescence des écrans

   Listez les écrans de l’application et les chemins entre eux, puis rattachez chaque écran aux fonctionnalités qu’il porte. L’exercice révèle vite les oublis : un écran sans fonctionnalité est suspect, une fonctionnalité sans écran aussi. Pas besoin de maquettes à ce stade : une arborescence suffit à vérifier que le parcours tient debout.

6. Lister les questions ouvertes

   Tout ce qui n’est pas tranché doit être écrit, rattaché à la fonctionnalité concernée et confié à quelqu’un : « paiement en plusieurs fois ? », « que se passe-t-il si le coach annule ? ». Une question ouverte visible se règle en réunion ; une question oubliée se règle en recette, au pire moment.

7. Estimer en jours

   Estimez chaque fonctionnalité séparément, en jours de travail, développement et tests compris. Estimer au niveau de la fonctionnalité plutôt que du projet entier donne des erreurs plus petites, qui ont tendance à se compenser. Une fonctionnalité trop floue pour être estimée est un signal : elle retourne à l’étape 3.

8. Découper en lots : MVP, V1, V2

   Regroupez les fonctionnalités en lots livrables : un MVP qui répond à l’objectif principal, puis une V1 et une V2 qui enrichissent le produit. Chaque lot doit fonctionner seul, ce qui impose de respecter les dépendances. Le découpage en lots est votre meilleur outil de discussion avec le client : on ajuste le contenu d’un lot plutôt que de raboter les estimations.

9. Valider avec le client

   Relisez le cadrage avec le client, fonctionnalité par fonctionnalité, lot par lot. Le but n’est pas une signature de principe, mais un accord explicite sur ce qui est dedans, ce qui est dehors, et sur les questions qui restent ouvertes. Gardez la trace des décisions et de leur date : elles serviront le jour où une demande nouvelle arrivera.

10. Préparer la recette

    Transformez les critères d’acceptation en cas de test : une situation de départ, une action, un résultat attendu. La recette est alors prête avant la première ligne de code, et le client sait exactement ce qui sera vérifié. C’est aussi un bon contrôle du cadrage : un critère que l’on ne sait pas transformer en test est un critère mal écrit.

Exemple : le cadrage de FitBook, une app de réservation de cours

Pour rendre la méthode concrète, prenons FitBook : une application pour une salle de sport, où les membres réservent des cours collectifs et où les coachs gèrent leurs créneaux. Le cadrage donne trois modules et sept fonctionnalités. Le lot de chaque fonctionnalité est un choix de l’exemple.

Zoomons sur RES-02, la fonctionnalité centrale du produit. Voici sa fiche complète :

Cette seule fiche fait apparaître trois décisions. La règle « abonnement actif requis » crée une dépendance vers ABO-01 : RES-02 ne peut pas entrer dans un lot qui ne contient pas ABO-01. La règle « cours complet » renvoie à RES-03, placée en V1 : il faut décider ce que voit un membre face à un cours complet dans le MVP. Enfin, le critère « deux membres ne peuvent pas obtenir la dernière place » impose de gérer les réservations simultanées, ce qui pèse dans l’estimation. Mieux vaut découvrir ces trois points pendant le cadrage que pendant la recette.

Chiffrer un projet à partir du cadrage

Estimer fonctionnalité par fonctionnalité

Un chiffrage de projet informatique fiable part de la liste des fonctionnalités, pas d’une impression globale. Pour chacune, estimez l’effort en jours en vous appuyant sur ses règles et ses critères d’acceptation : ce sont eux qui font varier l’effort. « Réserver une place » sans contrainte, et « réserver une place » quand deux membres ne doivent jamais obtenir la même dernière place, ne coûtent pas la même chose.

Intégrer la marge d’incertitude

Une estimation n’est pas un chiffre unique. Pour les fonctionnalités incertaines, donnez trois valeurs : optimiste, probable, pessimiste. La moyenne pondérée classique, (optimiste + 4 × probable + pessimiste) / 6, donne une valeur de travail ; l’écart entre l’optimiste et le pessimiste mesure le risque. Une fonctionnalité à fort écart appelle une question de cadrage supplémentaire, une marge explicite dans le devis, ou un report dans un lot ultérieur.

Chiffrer par lots

Additionnez les estimations lot par lot : le MVP a son total, la V1 le sien. Le client peut alors arbitrer en connaissance de cause, en déplaçant une fonctionnalité d’un lot à l’autre, plutôt que de demander une remise sur un montant global.

Un devis qui suit le périmètre

Quand le devis est construit à partir du cadrage, chacune de ses lignes correspond à une fonctionnalité. Si le périmètre change, le devis change de la même façon : une fonctionnalité ajoutée apporte sa ligne, une fonctionnalité retirée l’enlève. C’est la meilleure protection contre la dérive de périmètre : chaque demande nouvelle a un coût visible, discuté avant d’être acceptée.

Cadrer un projet avec l’IA

Les agents de code comme Claude Code ou Codex écrivent vite, mais ils ne devinent pas un projet. Sans contexte, un agent à qui l’on demande « ajoute la liste d’attente » invente les règles : délais, notifications, ordre de priorité. Avec le contexte complet, il travaille à partir des décisions déjà prises.

Ce qu’un agent apporte quand il connaît le projet

• Proposer un premier découpage en modules et fonctionnalités à partir d’une description ou d’un cahier des charges existant.
• Repérer les manques : une fonctionnalité sans critère d’acceptation, une règle contradictoire, une dépendance oubliée.
• Rédiger la documentation et les cas de test à partir des critères.
• Tenir le cadrage à jour pendant le développement : avancement, fonctionnalités modifiées, tests créés.

C’est le rôle du serveur MCP de Scopenod : il donne à Claude Code ou à Codex l’accès à votre projet Scopenod, que l’agent peut lire et modifier. Il cadre, documente, met à jour l’avancement et crée les tests, dans le même fichier que vous.

Ce qui reste une décision humaine

• Les arbitrages : ce qui entre dans le MVP et ce qui attend.
• Les priorités : l’ordre de valeur pour le client et ses utilisateurs.
• La validation client : l’accord sur le périmètre, le devis et la recette engage des personnes, pas un agent.

Un bon usage de l’IA en cadrage ressemble à un binôme : l’agent propose, vérifie et rédige ; vous décidez.

Les erreurs fréquentes du cadrage de projet

1. Chiffrer avant de découper. Un montant global posé sur une intention est impossible à justifier, et encore moins à défendre quand le périmètre bouge.
2. Confondre fonctionnalité et écran. « Page profil » n’est pas une fonctionnalité : modifier son mot de passe, gérer ses moyens de paiement et consulter son historique en sont trois, avec des règles différentes.
3. Écrire des critères invérifiables. « Simple », « rapide », « intuitif » ne se testent pas. Chaque critère doit pouvoir être coché par oui ou par non.
4. Oublier les cas limites. Le cours complet, l’annulation tardive, le paiement refusé : c’est là que se cachent les jours non chiffrés.
5. Garder les questions ouvertes en tête. Ce qui n’est pas écrit est tranché par défaut par la personne qui code, souvent sans qu’elle le sache.
6. Figer le cadrage après la signature. Un cadrage qui n’est plus tenu à jour s’éloigne du code en quelques semaines. Chaque changement accepté doit y entrer, avec son effet sur le chiffrage.
7. Multiplier les sources. Le cahier des charges dans un document, les estimations dans un tableur, les règles dans les tickets : la même règle finit par avoir trois valeurs. Gardez une seule source, que tout le monde lit.

Modèle de fiche fonctionnalité

Copiez ce modèle pour chaque fonctionnalité de votre cadrage. Il contient tout ce dont le développement, le chiffrage et la recette ont besoin.

Code : [MOD-01]
Nom : [Verbe + objet, ex. Réserver une place]
Module : [Module parent]
Description :
  [Ce que fait l’utilisateur et ce qu’il obtient, en une ou deux phrases.]
Règles :
  - [Condition, limite ou cas particulier]
  - [...]
Critères d’acceptation :
  - [Condition vérifiable par oui ou par non]
  - [...]
Dépendances : [Codes des fonctionnalités nécessaires]
Estimation : [x j, ou optimiste / probable / pessimiste]
Lot : [MVP, V1 ou V2]
Questions ouvertes :
  - [Question, personne qui doit répondre]