Note de cadrage : fixer le périmètre avant de rédiger le cahier des charges

Une note de cadrage formalise les décisions essentielles d’un projet : le besoin à satisfaire, les résultats attendus, le périmètre, les moyens et les responsabilités. Rédigée en amont du cahier des charges, elle permet au commanditaire et à l’équipe de vérifier qu’ils s’engagent sur le même projet. Sa valeur tient moins à sa longueur qu’à sa capacité à rendre les arbitrages explicites.

La note de cadrage est un document de référence partagé. Elle explique pourquoi le projet mérite d’être engagé et dans quelles limites il doit avancer. Elle sert ensuite de point de comparaison lorsqu’une demande supplémentaire, une contrainte ou un retard remet en question les engagements initiaux.

Elle se prépare dès que le besoin est suffisamment clair pour être discuté, avant de détailler les exigences de réalisation. Elle peut constituer un accord de fonctionnement entre commanditaire et chef de projet, sans devenir automatiquement un contrat juridique. Les appellations varient selon les organisations : mieux vaut préciser la fonction du document plutôt que se fier uniquement à son titre.

Document	Question centrale	Usage principal
Note de cadrage	Pourquoi ce projet et dans quelles limites ?	Aligner les attentes et valider les grandes orientations.
Lettre de mission	Qui reçoit quelle mission et quelle autorité ?	Formaliser le mandat et les responsabilités confiées.
Note de lancement	Que faut-il savoir pour démarrer ?	Communiquer le démarrage et ses modalités pratiques.
Cahier des charges	À quelles exigences le résultat doit-il répondre ?	Détailler les besoins, contraintes et critères d’acceptation.

Le chemin habituel va donc de l’expression du besoin au cadrage, puis au cahier des charges et à la réalisation. Sur un petit projet, certains documents peuvent être regroupés. L’essentiel reste de valider le besoin avant de figer la solution.

Les rubriques qui rendent le projet réellement arbitrable

Une bonne structure permet de répondre aux questions du QQOQCP : quoi, qui, où, quand, comment et pourquoi. Cette méthode sert de contrôle de complétude, pas de sommaire obligatoire. Organisez plutôt les informations pour faciliter la décision.

Le besoin, les objectifs et les limites

Décrivez le problème actuel, les personnes concernées et les conséquences de l’inaction. Distinguez ensuite l’objectif du livrable : « réduire les erreurs de saisie » exprime un résultat recherché ; « déployer un formulaire » désigne un moyen de l’obtenir. Un objectif utile précise un résultat observable, une échéance et, lorsque c’est possible, un indicateur de réussite.

Le périmètre doit indiquer les activités, utilisateurs, sites ou processus inclus, mais aussi les exclusions explicites. « Déploiement sur le site pilote, sans reprise des archives » évite davantage de malentendus qu’une formule comme « modernisation du service ».

Les engagements et leurs conditions

Livrables : résultats concrets attendus et personne chargée de les accepter.
Acteurs : commanditaire, chef de projet, contributeurs et utilisateurs consultés.
Planning : grandes phases, dates clés et dépendances.
Ressources : disponibilité des équipes, compétences, budget et moyens techniques.
Contraintes et risques : obligations, incertitudes, conséquences possibles et premières réponses.
Pilotage : modalités de suivi, communication et circuit d’arbitrage.

Pour vérifier la cohérence de ces rubriques, construisez une petite matrice de traçabilité : reliez chaque objectif à un livrable, à un critère d’acceptation et à un responsable. Un livrable sans objectif peut révéler une dépense inutile ; un objectif sans livrable signale un résultat espéré sans moyen identifié. Cette lecture croisée permet de repérer les angles morts avant même de discuter du calendrier.

Passer des échanges à une version que chacun peut valider

Le chef de projet coordonne généralement la rédaction avec le commanditaire. Les représentants métiers précisent les usages ; les équipes techniques, financières ou juridiques interviennent selon les enjeux. Il n’est pas nécessaire de faire approuver chaque phrase par tous les participants, mais les engagements doivent être vérifiés par ceux qui les porteront.

Recueillir le besoin : interroger le commanditaire et les utilisateurs, puis distinguer problème, attente et solution envisagée.
Rédiger une première version : présenter les décisions proposées et signaler les informations manquantes.
Tester la faisabilité : confronter périmètre, échéances et moyens avec les contributeurs concernés.
Arbitrer les désaccords : faire décider les priorités par la personne disposant de l’autorité nécessaire.
Faire approuver : conserver une version datée avec le nom du valideur et les éventuelles réserves.

Une information incertaine doit rester identifiable. Écrivez « enveloppe à confirmer après consultation » plutôt que de présenter une estimation comme un budget acquis. Pour chaque point ouvert, indiquez qui doit le résoudre et avant quelle décision.

La note validée est diffusée à l’équipe projet et aux parties prenantes concernées. Elle reste évolutive, mais une modification du périmètre ne doit pas devenir un simple changement de texte : ses effets sur les coûts, les délais et les ressources doivent être examinés, puis approuvés selon le circuit prévu.

Un modèle réutilisable, illustré par un projet interne

Le modèle suivant peut être copié dans un document de travail. L’exemple est fictif : il concerne la mise en place d’un formulaire de demandes internes. Les valeurs entre crochets doivent être complétées et validées avant le lancement.

Rubrique	Exemple à adapter
Identification	Centralisation des demandes internes — version [numéro], datée du [date], rédigée par [nom].
Contexte et besoin	Les demandes arrivent par plusieurs canaux ; leur attribution et leur suivi sont difficiles.
Objectif et mesure	Réduire les demandes sans responsable identifié. Situation initiale, cible et date de mesure à fixer après analyse.
Périmètre inclus	Un service pilote, un formulaire commun et un tableau de suivi des demandes.
Hors périmètre	Reprise de l’historique et extension aux autres services.
Livrables et acceptation	Formulaire testé, procédure d’attribution et support utilisateur ; acceptation par le responsable du service pilote.
Responsabilités	Commanditaire : responsable de service. Coordination : chef de projet. Contributions : référent métier et équipe informatique.
Jalons et moyens	Validation du besoin, paramétrage, test, bilan ; dates, charge et enveloppe budgétaire à confirmer.
Risques et réponses	Maintien des anciens canaux : prévoir une communication et un accompagnement des utilisateurs.
Validation	Décision du commanditaire le [date], réserves éventuelles et conditions de passage à la réalisation.

Pour un projet plus complexe, ajoutez les dépendances entre équipes, les contraintes réglementaires ou les modalités de conduite du changement. À l’inverse, évitez d’empiler les outils de gouvernance sur une mission simple : chaque rubrique doit soutenir une décision ou clarifier un engagement.

Les vérifications à faire avant de lancer le projet

Relisez la note du point de vue d’une personne absente des premières réunions. Peut-elle comprendre le problème, identifier ce qui sera livré et savoir qui décide ? Si elle doit reconstituer les discussions pour interpréter le document, le cadrage reste trop implicite.

Vérifiez surtout la compatibilité entre ambition, moyens et calendrier. Une date imposée sans disponibilité confirmée constitue une hypothèse, pas un engagement sécurisé. De même, une liste de fonctionnalités ne remplace ni un objectif métier ni un critère d’acceptation.

Enfin, rendez visibles les décisions attendues : autorisation de poursuivre, choix du périmètre, mobilisation des ressources ou demande d’étude complémentaire. Une note de cadrage réussie permet de décider de la suite, y compris de reporter ou de redimensionner le projet lorsque les conditions ne sont pas réunies.