Les points à garder en tête avant de cadrer le besoin
- Le cahier des charges fonctionnel décrit ce que le projet doit permettre de faire, pas la solution technique choisie.
- Il sert à aligner la MOA, les équipes projet et, le cas échéant, un prestataire externe sur des attentes mesurables.
- Un document utile reste lisible: pour un projet simple, 5 à 10 pages suffisent souvent; au-delà, mieux vaut structurer et annexer.
- Les rubriques qui comptent vraiment sont le contexte, les objectifs, le périmètre, les fonctions attendues, les contraintes et les critères d’acceptation.
- La norme NF EN 16271, portée par l’AFNOR, reste une référence utile pour formaliser l’expression du besoin.
- Le meilleur test d’un bon document est simple: un tiers doit pouvoir comprendre le besoin sans relire chaque échange de réunion.
Ce que doit réellement couvrir un cahier des charges fonctionnel
Je le présente toujours comme un document de cadrage, pas comme un catalogue de fonctionnalités. Il répond à trois questions simples: quel problème on résout, pour qui, et avec quelles contraintes. La bonne logique est fonctionnelle avant d’être technique: on décrit les résultats attendus, puis on laisse de la marge sur la façon d’y parvenir.
Dans la pratique, je distingue toujours trois niveaux: le besoin, la fonction et la solution. Le besoin explique pourquoi le projet existe; la fonction précise ce que le produit ou le service doit permettre; la solution décrit le moyen retenu. C’est cette séparation qui évite les dérives du type “on a commandé un outil, on a reçu une usine à gaz”.Sur le plan normatif, l’AFNOR s’appuie sur la NF EN 16271 pour l’expression fonctionnelle du besoin. Cette référence est utile parce qu’elle rappelle qu’un bon CdCF doit aider à rechercher l’optimum entre le besoin exprimé et la réponse apportée, sans enfermer le projet trop tôt dans un choix de technologie ou d’architecture.
| Aspect | Cahier des charges fonctionnel | Cahier des charges technique |
|---|---|---|
| Question principale | Que doit permettre le projet ? | Comment le projet sera-t-il réalisé ? |
| Moment de rédaction | Au cadrage, avant de figer la solution | Après ou pendant la conception détaillée |
| Public cible | MOA, métiers, direction, prestataires | Équipe de conception, développement, intégration |
| Risque si mal rédigé | Besoin flou, attentes contradictoires, validation difficile | Choix techniques inadaptés, dette d’architecture |
Cette distinction paraît simple, mais elle change tout dès qu’un projet a plusieurs acteurs ou un fournisseur externe. Une fois cette base posée, le vrai enjeu devient la structure du document.
La structure que je recommande pour rester lisible
Je recommande une structure courte, lisible et stable. Pour un projet simple, 5 à 10 pages suffisent souvent; pour un projet multi-équipes, réglementé ou externalisé, on monte plutôt à 15 à 30 pages, annexes comprises. Au-delà, je conseille généralement de segmenter le contenu plutôt que d’empiler les paragraphes.
| Rubrique | Ce qu’elle doit contenir | Erreur fréquente |
|---|---|---|
| Contexte et enjeu | Pourquoi le projet existe, quel problème il traite, quels signes montrent qu’il est nécessaire | Rester vague et ne pas relier le projet à un besoin réel |
| Objectifs | Résultats attendus, idéalement formulés de manière mesurable | Écrire des intentions générales sans indicateur de succès |
| Périmètre | Ce qui est inclus, ce qui est exclu, les frontières du projet | Laisser les limites implicites et ouvrir la porte au glissement de scope |
| Utilisateurs et parties prenantes | Qui utilise, qui valide, qui pilote, qui exécute | Oublier un acteur clé et découvrir son opposition trop tard |
| Fonctions attendues | Les services rendus par le futur produit ou service, classés par priorité | Mélanger fonctions métier et choix techniques |
| Contraintes | Budget, délai, sécurité, RGPD, intégrations, accessibilité, support | Ne mentionner que les contraintes les plus visibles |
| Critères d’acceptation | Comment on saura que le besoin est satisfait | Valider “au ressenti” au lieu de critères testables |
| Livrables et gouvernance | Ce qui doit être produit, quand, et par qui les validations passent | Ne pas préciser le circuit de décision ni les jalons |
Je mets toujours en évidence ce qui est exclu du périmètre: c’est l’un des meilleurs antidotes au flou. Avec cette ossature, on peut passer à un exemple exploitable.
Un exemple concret pour un portail interne de demandes
Imaginons un projet de transformation numérique assez courant: un portail intranet pour centraliser les demandes RH et IT dans une entreprise de 250 salariés. Aujourd’hui, les sollicitations arrivent par e-mail, les validations se perdent, et les équipes passent du temps à reconstituer l’historique. Le cahier des charges fonctionnel sert ici à fixer le besoin sans imposer trop tôt l’outil ou l’architecture.
| Rubrique | Exemple de rédaction | Pourquoi c’est utile |
|---|---|---|
| Contexte | Les demandes internes sont traitées par e-mail et Excel, ce qui provoque des délais moyens de 4 jours et des pertes d’information. | On relie le projet à un problème mesurable, donc à une vraie priorité. |
| Objectif | Centraliser 90 % des demandes sur un portail unique et réduire le délai moyen de traitement de 30 % en 6 mois. | L’objectif devient vérifiable, pas seulement “amélioré”. |
| Périmètre | Inclus: dépôt de demande, validation, suivi de statut, notifications, tableaux de bord. Exclu: refonte de la paie et gestion documentaire complète. | Le projet reste pilotable et les attentes sont bornées. |
| Utilisateurs | Collaborateurs, managers, RH, support IT. | Chaque profil peut avoir des règles différentes; il faut les distinguer dès le départ. |
| Fonctions principales | Créer une demande en moins de 3 minutes, joindre une pièce, suivre le statut, recevoir une notification de changement, valider ou rejeter une demande selon les droits. | On parle en actions concrètes, donc testables. |
| Contraintes | Accès via SSO, compatibilité mobile, journalisation des actions, conformité RGPD, temps de réponse inférieur à 2 secondes pour 95 % des écrans. | On fixe les limites de qualité et de conformité avant de choisir la solution. |
| Critères d’acceptation | 90 % des cas de test validés, pilote de 30 utilisateurs, aucun bug bloquant à la mise en production. | La recette finale repose sur des preuves, pas sur une impression générale. |
Je préfère écrire les fonctions avec des verbes d’action, parce que cela force la précision. Par exemple, “permettre à un collaborateur de déposer une demande en moins de 3 minutes”, “notifier automatiquement le manager” ou “tracer chaque changement de statut” sont des formulations beaucoup plus robustes que “proposer une interface moderne”.
- À éviter “L’application doit être intuitive.”
- À écrire “Un utilisateur non formé doit pouvoir créer une demande sans assistance en moins de 3 minutes.”
- À éviter “Ajouter un module de workflow.”
- À écrire “Toute demande de congé doit être transmise au manager avec notification automatique.”
Ce niveau de précision rend la recette de validation beaucoup plus simple à la fin du projet. Quand un exemple est rédigé avec ce niveau de détail, les écarts deviennent visibles tout de suite.
Les erreurs qui font dérailler l’exercice
Les documents les plus fragiles que je vois ont souvent les mêmes défauts. Ils confondent besoin et solution, oublient les exclusions, ou mélangent des exigences métier avec des décisions techniques qui devraient rester ouvertes. Le résultat est prévisible: le prestataire suit le texte à la lettre, mais pas l’intention du projet.
- Trop vague “L’outil doit améliorer la productivité” ne dit rien de mesurable.
- Trop prescriptif “L’outil doit utiliser telle base de données” peut enfermer le projet trop tôt.
- Sans priorité toutes les demandes semblent urgentes, donc rien ne l’est vraiment.
- Sans critère de réception la validation finale devient une discussion d’opinion.
- Sans versioning les changements s’accumulent et personne ne sait ce qui a été validé.
Je conseille aussi d’ajouter un glossaire si le projet touche plusieurs métiers: trois acronymes mal compris suffisent à brouiller une revue de cadrage. Avec ces pièges en tête, il reste à organiser la validation pour que le document serve vraiment le projet.
Faire valider le document sans le rigidifier
La validation ne doit pas devenir une cérémonie administrative. Je préfère une boucle courte: atelier de collecte, V1, revue par les parties prenantes, ajustements, puis validation formelle de la version figée. Si le projet est externe ou au forfait, la précision sur le périmètre et les critères d’acceptation devient encore plus importante, parce qu’elle limite les désaccords sur ce qui est inclus ou non.- Faire relire le document par les métiers, la direction et les équipes qui vont réaliser le projet.
- Marquer clairement ce qui est prioritaire, optionnel ou hors périmètre.
- Ajouter une trace des décisions et des arbitrages.
- Garder un historique de versions avec date, auteur et changements.
Je trouve qu’un bon CdCF n’est pas un texte figé, mais une base de dialogue suffisamment précise pour faire avancer le projet sans déformer le besoin. Si vous devez en produire un maintenant, partez d’un contexte clair, d’objectifs mesurables, d’un périmètre net et de critères de validation testables: c’est ce qu’on attend d’un document utile, pas d’un dossier décoratif.
