Exemple de cahier des charges fonctionnel : modèle rempli à copier dans Word

Un site de services doit permettre à un prospect de comprendre l’offre, de vérifier qu’elle correspond à son besoin et d’envoyer une demande exploitable. Un exemple de cahier des charges fonctionnel montre comment traduire cet objectif en fonctions attendues, en règles et en tests, sans décider trop tôt de la solution technique. La limite pratique reste simple : chaque objectif, seuil, budget et responsable doit être adapté puis validé par les parties prenantes du projet.

Pas le temps de lire ?

• Le cahier des charges fonctionnel décrit les besoins, les fonctions attendues, les contraintes et les conditions de validation, pas la solution technique détaillée.
• Chaque exigence doit posséder un identifiant, une priorité, un responsable et un critère d’acceptation vérifiable.
• Le périmètre et le hors-périmètre doivent être écrits explicitement pour éviter les interprétations et comparer correctement les offres.
• La trame peut être copiée dans Word, maintenue comme document vivant puis exportée en PDF au moment de la consultation ou de la validation.

Du besoin métier au test de recette : un exemple en quatre lignes

Le cahier des charges fonctionnel, ou CdCF, décrit ce qu’une solution doit accomplir pour répondre à un besoin métier. Il précise le périmètre, les utilisateurs, les fonctions de service, les fonctions de contrainte et les conditions de validation. Il ne doit pas imposer prématurément comment le site sera développé, hébergé ou connecté aux autres outils.

Voici la chaîne minimale à conserver :

• Objectif métier : augmenter le nombre de demandes qualifiées reçues depuis le site.
• Fonction attendue : permettre à un visiteur de décrire son besoin et de transmettre ses coordonnées.
• Priorité : indispensable avant la mise en ligne.
• Critère d’acceptation : une demande valide est enregistrée, transmise au responsable et confirmée à l’utilisateur.

Le niveau de détail dépend du risque, du nombre d’intervenants et de la complexité du projet. Une refonte simple peut tenir dans un document concis. Un projet connecté à un CRM, un ERP, une API ou un SSO exige davantage de règles, de données et de scénarios de recette.

Le modèle de cahier des charges Word proposé plus bas sert de trame. La prochaine action consiste à le copier, à supprimer les rubriques inutiles et à remplacer chaque formulation générale par une information propre au projet.

Le cas rempli : cadrer la refonte d’un site de services

Prenons le cas d’une entreprise de services qui souhaite remplacer un site devenu difficile à administrer et peu efficace pour générer des contacts.

Contexte et problème constaté

Le site présente l’activité, mais l’offre reste difficile à distinguer. Les visiteurs ne savent pas toujours quel service choisir ni quelles informations transmettre. Les demandes reçues sont parfois incomplètes, ce qui impose des échanges supplémentaires. La mise à jour des contenus dépend par ailleurs d’un intervenant technique.

L’étude d’opportunité confirme l’intérêt d’une refonte. L’étude de faisabilité doit ensuite vérifier les dimensions économiques, techniques et organisationnelles, notamment la reprise des contenus, la connexion éventuelle au CRM et la disponibilité des personnes chargées de valider le projet.

Objectifs, utilisateurs et parcours

Les objectifs sont formulés comme des objectifs SMART dès que la situation de départ et la cible ont été renseignées :

• augmenter les demandes qualifiées, avec un KPI de référence et une cible à compléter ;
• rendre les principales pages administrables par l’équipe ;
• réduire les demandes incomplètes ;
• garantir un parcours utilisable sur mobile et accessible au public visé.

Les utilisateurs finaux sont les prospects, les clients qui cherchent une information pratique et les collaborateurs qui administrent le CMS. Le parcours principal relie la page d’accueil, une page de service, une preuve de confiance, le formulaire et la confirmation d’envoi. Des cas d’usage secondaires couvrent la recherche d’une information, la consultation des mentions obligatoires et la mise à jour d’un contenu.

Fonctions, données et règles

Les exigences fonctionnelles retenues sont les suivantes : présenter les services, orienter le visiteur vers l’offre pertinente, publier des contenus, recueillir une demande, transmettre les informations au bon responsable et conserver une trace de traitement.

Les données concernées comprennent les coordonnées, le service recherché, le message, le consentement requis et les informations techniques strictement nécessaires au fonctionnement. Un dictionnaire de données devra indiquer pour chaque champ son format, son caractère obligatoire, sa destination, sa durée de conservation à définir et ses droits d’accès.

Les règles métier précisent notamment qu’une demande ne peut être envoyée sans les champs obligatoires, qu’elle doit être dirigée vers le responsable concerné et qu’une confirmation doit être affichée sans révéler d’information sensible. Les règles relatives au RGPD, aux habilitations RBAC et à la sécurité seront validées par les responsables compétents.

Contraintes, livrables et organisation

Les contraintes couvrent le mobile, l’accessibilité selon le référentiel applicable, la performance, la sécurité, la conformité, la compatibilité avec les outils existants et l’autonomie éditoriale. Si un niveau de service est attendu, le SLA doit être défini plutôt que supposé.

Les livrables comprennent l’arborescence, les wireframes, le mock-up validé, le site configuré, les contenus repris, le plan de redirection, la documentation d’administration, les preuves de test et le procès-verbal de recette fonctionnelle.

Le calendrier indicatif suit des phases sans dates inventées : cadrage, conception, production, intégration des contenus, tests, corrections, validation et mise en ligne. Le budget, ses hypothèses et sa marge de changement restent à renseigner. La MOA porte le besoin et l’acceptation. La MOE réalise la solution. Selon l’organisation, un Business Analyst formalise les exigences, un Product Owner arbitre leur priorité et la DSI valide les contraintes du système d’information.

Matrice de traçabilité remplie

Cette matrice évite qu’un objectif reste isolé du livrable et de sa preuve. Elle relie la décision métier à la recette, au responsable et au statut de validation.

Le périmètre fixe la frontière entre le projet et les demandes futures

Le périmètre, ou scope, indique ce qui sera effectivement conçu, produit, testé et livré. Pour la refonte étudiée, l’in-scope peut comprendre les pages institutionnelles, les pages de services, le formulaire, l’espace d’administration, la migration des contenus validés, les redirections et les intégrations explicitement retenues avec le CRM ou une API.

Les comptes utilisateurs ne doivent être inclus que si leur rôle est défini. Un accès d’administration éditoriale n’implique pas automatiquement un espace client, un paiement en ligne ou une authentification SSO. De même, une migration doit préciser les contenus repris, leur format, leur qualité attendue et la répartition des corrections.

L’out-of-scope peut inclure la production continue d’articles, la refonte d’un logiciel tiers, le nettoyage illimité des données, la création d’un ERP, les campagnes publicitaires et toute évolution non validée. Ces éléments ne sont pas interdits : ils relèvent d’un lot futur ou d’une demande de modification.

Cette frontière donne un cadre aux spécifications fonctionnelles et empêche qu’une phrase générale soit interprétée différemment par le métier, la MOA, la MOE et les prestataires. Elle limite les surcoûts et permet de comparer des offres fondées sur une même liste de livrables, plutôt que sur des périmètres implicites incompatibles.

Transformer une demande vague en exigence mesurable

Une exigence utile suit la chaîne « pourquoi, quoi, preuve ». Le pourquoi correspond au besoin métier. Le quoi décrit l’action réalisable par un acteur. La preuve indique le résultat observable qui permettra d’accepter ou de refuser le livrable.

La demande « le formulaire doit être simple » est trop subjective. Une formulation exploitable devient : « EF-04 : le prospect peut envoyer une demande après avoir renseigné les champs déclarés obligatoires. » La règle métier précise les contrôles applicables, les données concernées et le destinataire. Les critères d’acceptation vérifient que l’envoi aboutit avec des données valides, qu’une erreur compréhensible apparaît lorsqu’un champ obligatoire manque et qu’aucune demande incomplète n’est transmise.

Même problème avec « le site doit être rapide ». Cette phrase ne définit ni les pages concernées, ni les conditions de mesure, ni le seuil accepté. Il faut renseigner ces éléments avec les responsables compétents, sans inventer une cible. L’exigence non fonctionnelle reste indépendante du choix du CMS, du serveur ou du framework tant que l’étude de faisabilité n’a pas déterminé le comment.

Autre exemple : « le site doit être sécurisé » devient une série d’exigences distinctes concernant les droits d’accès, la protection des échanges, les sauvegardes, la journalisation et le traitement des incidents. Chacune reçoit un identifiant, une priorité MoSCoW, un propriétaire et une preuve.

Pour mener une analyse fonctionnelle des besoins, il est utile de distinguer l’analyse fonctionnelle du besoin, ou AFB, de l’expression fonctionnelle du besoin, ou EFB. La première recherche les fonctions nécessaires et les contraintes. La seconde les formule afin qu’elles puissent être comprises, évaluées et testées. L’analyse de la valeur aide ensuite à rapprocher l’utilité de chaque fonction de son coût et de sa contribution au résultat.

La trame à copier dans Word puis à exporter en PDF

Le modèle ci-dessous peut être collé dans Word ou dans un autre traitement de texte, complété, puis exporté en PDF. Il ne s’agit pas d’un fichier téléchargeable. Les intitulés entre crochets signalent les informations à renseigner.

• Version du document : titre, identifiant, version, date, auteur, approbateurs et état.
• Synthèse : projet, problème à résoudre, décision attendue et principaux résultats.
• Contexte : activité, situation actuelle, difficultés, opportunité et dépendances.
• Objectifs et KPI : objectif SMART, indicateur, valeur de départ, cible, méthode de mesure et responsable.
• Parties prenantes : direction, métiers, utilisateurs, MOA, MOE, DSI, prestataires et autorités de validation.
• Utilisateurs : profils, besoins, droits, contexte d’usage et difficultés rencontrées.
• Périmètre du projet : éléments in-scope, exclusions out-of-scope, interfaces et hypothèses.
• Cas d’usage : acteur, déclencheur, parcours nominal, variantes, erreurs et résultat attendu.
• Exigences fonctionnelles : identifiant, formulation, justification, priorité, propriétaire et dépendances.
• Règles métier : conditions, exceptions, calculs, autorisations et décisions.
• Données : définition, source, format, qualité, accès, conservation, migration et suppression.
• Exigences non fonctionnelles : performance, disponibilité, sécurité, charge, accessibilité, conformité et écoconception.
• Contraintes : budget, calendrier, organisation, réglementation, outils existants et compétences disponibles.
• Maquettes : arborescence, wireframes, mock-ups, états d’interface et validation associée.
• Livrables : contenu, format, niveau de finition, responsable et condition d’acceptation.
• Planning : phases, jalons, dépendances, validations et disponibilités requises.
• Budget : enveloppe à renseigner, hypothèses, postes inclus, exclusions et procédure d’arbitrage.
• Recette : scénarios, données de test, résultat attendu, preuve, anomalie et décision.
• Validation : personnes autorisées, ordre des approbations et conditions de signature.
• Annexes : glossaire, SIPOC, diagrammes BPMN ou UML, dictionnaire de données et documents de référence.
• Registre des changements : identifiant, demande, motif, impacts, auteur, décision, date et version.

Dans Word, les styles de titres facilitent la navigation et la génération du sommaire. Le versionnage doit rester visible dans le document lui-même, même si le fichier est conservé dans Confluence, SharePoint, un README Git ou une plateforme documentaire. Une seule version doit être désignée comme référence.

BRD, cahier des charges et spécifications ne répondent pas à la même question

Le BRD, ou Business Requirements Document, est un document d’exigences métiers. Il explique pourquoi le projet existe, quels résultats sont recherchés et quels indicateurs permettront d’en apprécier la valeur. Un business requirements document template ne remplace donc pas automatiquement un CdCF.

Le CDC fonctionnel répond principalement à la question « quoi ? ». Il décrit les fonctions attendues, les utilisateurs, le périmètre, les contraintes, les priorités et les conditions de réception. Il sert d’interface entre les parties prenantes et peut soutenir un appel d’offres.

Une spécification fonctionnelle descend à un niveau plus précis. Elle détaille les comportements, le workflow, les règles métier, les données, les cas d’erreur et les interactions. Une spécification technique répond ensuite à la question « comment ? » : architecture, composants, protocoles, hébergement, API et choix d’implémentation.

Enfin, une exigence fonctionnelle décrit un service rendu, par exemple transmettre une demande au bon interlocuteur. Une exigence non fonctionnelle qualifie le fonctionnement attendu : performance, disponibilité, sécurité, accessibilité selon le RGAA ou les WCAG applicables, conformité RGPD, capacité de charge ou écoconception. Cette distinction évite de réduire la qualité à une liste de fonctionnalités.

Priorités, responsabilités et changements maintiennent le document exploitable

La méthode MoSCoW classe les exigences en Must, Should, Could et Won’t pour la version concernée. Une variante en français utilise indispensable, important et optionnel. La priorité ne reflète pas seulement une préférence : elle combine valeur métier, risque, dépendances, obligations et conséquences d’un report. Tout classer comme indispensable rend l’arbitrage impossible.

Les responsabilités varient selon la taille du projet. Une petite structure peut confier plusieurs rôles à la même personne, à condition de distinguer les décisions. Le Business Analyst ou le chef de projet rédige et consolide. Les représentants métier contribuent. Le Product Owner arbitre le backlog. La MOA approuve le besoin et la recette. La MOE évalue et réalise. La DSI contrôle les contraintes d’intégration et de sécurité. En Agile, le Scrum Master facilite le fonctionnement de l’équipe, mais ne décide pas à la place du métier.

Une matrice RACI simplifiée clarifie cette organisation :

Cette gouvernance aide à organiser la conception en équipe sans multiplier les validations informelles.

Chaque change request doit entrer dans un registre unique avec son identifiant, son motif, ses impacts sur le coût, le délai et le périmètre, son auteur, la décision, la date et la version concernée. Une demande acceptée modifie les exigences, les tâches ou les jalons associés. Une demande refusée reste tracée afin d’éviter qu’elle réapparaisse comme si elle n’avait jamais été arbitrée.

La recette et l’appel d’offres donnent une portée concrète aux exigences

La recette fonctionnelle transforme les exigences en scénarios vérifiables. Chaque scénario précise un état initial, le profil utilisateur, les données de test, les actions, le résultat attendu et la preuve à conserver. Les anomalies sont qualifiées, affectées, corrigées puis retestées. La décision finale distingue ce qui est accepté, refusé ou accepté avec réserves.

La matrice de traçabilité joue ici un rôle central. L’exigence EF-01, par exemple, doit conduire à un ou plusieurs tests de formulaire. Si aucun test ne correspond à une exigence, sa validation reste subjective. Si un test ne renvoie à aucune exigence, il faut vérifier s’il révèle un besoin oublié ou un contrôle sans justification.

Les mêmes éléments rendent les réponses à un appel d’offres comparables. Chaque prestataire doit pouvoir indiquer ce qui est inclus, les hypothèses retenues, les exclusions, les dépendances, les livrables et les conditions de réalisation. Un choix multicritère peut ensuite pondérer l’adéquation fonctionnelle, la méthode, le calendrier, le coût, les risques, la maintenance et la qualité des preuves, avec des pondérations décidées avant l’examen des offres.

Repère normatif daté : la NF X50-151 a été remplacée en février 2013 par la NF EN 16271.

La NF EN 16271 fournit un cadre lié à l’expression fonctionnelle du besoin et à l’établissement d’un cahier des charges fonctionnel. Sa mention ne dispense pas de vérifier le texte applicable ni les pratiques AFNOR pertinentes au projet.

Un cahier des charges signé ou annexé à un contrat peut devenir une référence contractuelle selon les documents et les clauses applicables. Sa portée dépend notamment de la hiérarchie des pièces, des réserves, de la procédure de modification et des engagements réellement acceptés. Ce point doit être vérifié avec un professionnel compétent plutôt que déduit du seul titre du document.

En Agile, conserver le cadre et alléger le niveau de détail

Agile ne signifie pas avancer sans cadrage. Un cahier des charges lean conserve la vision, les objectifs, les exclusions, les contraintes communes et les décisions structurantes. Le détail évolutif se trouve dans le backlog, les user stories, les maquettes et les tests d’acceptation préparés au fil des sprints.

Une user story décrit un besoin du point de vue d’un acteur. Elle ne remplace pas les règles transversales, le dictionnaire de données, les contraintes RGPD ou les exigences d’accessibilité. Inversement, un document exhaustif rédigé une fois puis oublié ne protège pas le projet. La documentation doit rester vivante, versionnée et reliée aux décisions.

Avant de valider le document et de consulter des prestataires, effectuer ce contrôle final :

• les objectifs sont mesurables et reliés à des KPI ;
• le besoin métier et les bénéfices attendus sont explicités ;
• le périmètre et les exclusions sont compréhensibles sans explication orale ;
• chaque exigence possède un identifiant unique ;
• les fonctions de service sont séparées des fonctions de contrainte ;
• les priorités ont été arbitrées selon la valeur, le risque et les dépendances ;
• les critères sont observables et testables ;
• les données, interfaces, règles métier et contraintes réglementaires sont couvertes ;
• les responsables de rédaction, de décision et de recette sont nommés ;
• les maquettes n’introduisent pas de fonction absente du document ;
• les livrables, le budget à renseigner et les étapes du planning sont cohérents ;
• une version unique fait référence ;
• les demandes de modification sont tracées ;
• l’approbation métier a été obtenue.

Si un point essentiel reste inconnu, il doit apparaître comme une décision ouverte avec un responsable, et non être masqué par une formulation vague. Cette discipline suffit souvent à rendre le document plus utile qu’une accumulation de détails techniques. Pour prolonger ce travail et mieux arbitrer les choix liés au site, vous pouvez découvrir nos conseils web.