Définition · Expression du besoin et cahier des charges
Cahier des charges fonctionnel : définition, contenu et exemple
En bref
Le cahier des charges fonctionnel exprime le besoin en fonctions attendues : ce que la solution doit permettre à ses utilisateurs, sans décrire la technique ni désigner un produit. Chaque fonction est numérotée, priorisée et vérifiable. Les fournisseurs restent libres de proposer leur solution, et leurs offres se comparent fonction par fonction.
Définition
Le cahier des charges fonctionnel (CDCF) est la partie du cahier des charges qui décrit le besoin du point de vue de l'utilisateur. Il répond à une seule question : que doit permettre la solution ? Il ne dit ni avec quelle technologie, ni avec quel produit. « Le manager valide une note de frais depuis son téléphone » est une fonction ; « l'application mobile développée en natif » est un choix technique, qui appartient au fournisseur ou au volet technique.
Ce parti pris a une raison simple. En décrivant le résultat attendu plutôt que le moyen, vous laissez chaque candidat proposer sa meilleure réponse, y compris celle à laquelle vous n'aviez pas pensé. Et vous gardez un document qui se vérifie : une fonction est rendue ou ne l'est pas, quel que soit le produit choisi.
Le cahier des charges fonctionnel arrive après l'expression du besoin, qui pose le problème avec les mots du demandeur, et avant les spécifications détaillées, que le fournisseur retenu rédige pour décrire comment il va réaliser chaque fonction.
Que contient un cahier des charges fonctionnel
Quatre rubriques forment le socle. Selon l'achat, on y ajoute une description des utilisateurs, des volumes et des processus actuels, mais ces quatre-là ne devraient jamais manquer.
Contexte et objectifs
Le contexte présente la situation actuelle et ce qui ne va pas, avec des chiffres : combien de personnes, combien de transactions, quels délais, quelles erreurs. Les objectifs disent ce qui doit avoir changé. Ils sont peu nombreux et mesurables : « rembourser une note de frais en moins de dix jours » fixe un cap que tous les candidats comprennent de la même façon.
Ajoutez une description des utilisateurs par profil : qui ils sont, combien ils sont, ce qu'ils font avec la solution. Un outil utilisé par 350 salariés une fois par mois et par trois comptables toute la journée n'a pas les mêmes exigences d'un écran à l'autre.
Fonctions attendues
C'est la partie qui pèse le plus. Chaque fonction s'écrit sur une ligne, avec un sujet (l'utilisateur), un verbe d'action et un résultat : « Le salarié saisit une indemnité kilométrique à partir d'un trajet ». Elle reçoit un identifiant (F-01, F-02…), une priorité et, idéalement, un critère de validation.
| Élément | Rôle | Exemple |
|---|---|---|
| Identifiant | Permet aux candidats de répondre ligne à ligne | F-04 |
| Fonction | Ce que l'utilisateur doit pouvoir faire | Le manager valide ou refuse depuis son téléphone, avec un commentaire |
| Priorité | Bloquant, Important ou Bonus | Bloquant |
| Critère de validation | Comment on vérifiera, en démonstration puis en recette | Validation en moins de trois actions |
Regroupez les fonctions par processus ou par profil plutôt que dans une liste unique de soixante lignes. Un candidat comprend mieux un parcours (saisir, valider, contrôler, rembourser) qu'un inventaire.
Contraintes
Les contraintes encadrent les fonctions sans en être : une date de mise en service, une règle de conservation des documents, une localisation des données, une connexion avec les comptes existants. Elles restent formulées en termes de résultat. Leur traduction technique détaillée (protocoles, architecture, sécurité) relève du volet technique.
Critères de réussite
Les critères de réussite reprennent les objectifs et fixent une échéance : à quoi verra-t-on, six mois après le démarrage, que l'achat a tenu ses promesses ? Ils ne servent pas seulement à choisir. Repris dans le contrat ou le plan de recette, ils deviennent la mesure du résultat, et une base solide le jour où il faut discuter avec le fournisseur d'un écart.
Qui le rédige
Le cahier des charges fonctionnel est porté par le métier, celui qu'on appelle la maîtrise d'ouvrage dans les projets informatiques : le service qui a le besoin et utilisera la solution. C'est lui qui sait ce que doit faire l'outil. Les Achats l'aident à structurer, à prioriser et à rendre chaque fonction vérifiable ; ils veillent aussi à ce qu'aucune fonction ne désigne un produit.
Sur un projet important, une assistance à maîtrise d'ouvrage (interne ou externe) anime les ateliers et tient la plume. La DSI relit pour repérer ce qui aura une conséquence technique, et le responsable du budget valide la version finale. Une seule personne coordonne et tient la version de référence, sinon deux versions circuleront, et les candidats recevront la mauvaise.
Comment le rédiger, étape par étape
- Partir de l'expression du besoin validée : contexte, objectifs, contraintes, critères de réussite.
- Décrire les utilisateurs par profil, avec leur nombre et leur usage.
- Dérouler les processus concernés, étape par étape, tels qu'ils devront fonctionner demain.
- Écrire une fonction par action utile à un utilisateur, sur une ligne, sans nom de produit.
- Numéroter chaque fonction et lui attribuer une priorité : Bloquant, Important ou Bonus.
- Ajouter un critère de validation aux fonctions bloquantes et importantes.
- Rassembler les contraintes et les critères de réussite.
- Faire relire par un utilisateur qui n'a pas participé, puis par la DSI.
Deux tests en relecture. Le test du produit : si une fonction ne peut être satisfaite que par un seul logiciel du marché, réécrivez-la. Le test de la recette : si personne ne sait dire comment on vérifiera une fonction, elle est trop vague. « L'outil est intuitif » échoue au second test ; « un nouvel utilisateur saisit sa première note sans formation » le passe.
Côté priorités, comptez : si presque toutes les fonctions sont bloquantes, le classement n'a pas été fait. Les fonctions bloquantes écartent les offres, les importantes pèsent dans la note, les bonus départagent deux offres proches.
Exemple commenté
Notre exemple de cahier des charges fonctionnel porte sur un outil de gestion des notes de frais, pour une entreprise fictive. Il tient en deux pages et cinq rubriques. Pour recevoir le document Word complet, remplissez le formulaire en haut de page. Voici ce qu'il contient, et pourquoi.
Le contexte tient en quatre chiffres : 350 salariés, dont 120 se déplacent régulièrement, un remboursement en 34 jours en moyenne, une note sur cinq renvoyée pour correction. Il décrit aussi le circuit actuel (tableur, impression, signature, ressaisie comptable). Un candidat sait immédiatement où se trouvent les pertes de temps. Les trois objectifs en découlent : rembourser en moins de dix jours, supprimer la ressaisie, faire appliquer automatiquement la politique de voyages.
Le tableau des utilisateurs distingue quatre profils : salariés, managers (40), comptables (3) et un administrateur. Il dit à chaque fournisseur combien de licences chiffrer, et pour quel usage.
| Fonction de l'exemple | Priorité | Ce qu'il faut remarquer |
|---|---|---|
| F-01 : le salarié photographie un justificatif ; montant, date et TVA sont proposés automatiquement | Bloquant | Le résultat est décrit, pas la technologie de lecture. Le critère est chiffré : 18 justificatifs justes sur 20. |
| F-02 : indemnité kilométrique calculée selon le barème en vigueur | Bloquant | La règle de calcul est externe et publiée : le critère consiste à comparer cinq trajets au barème. |
| F-03 : alerte sur une dépense hors politique avant l'envoi | Important | Elle sert l'objectif de politique de voyages, sans en faire une condition d'éligibilité. |
| F-05 : export des écritures au format du logiciel comptable | Bloquant | Le critère est concret : importer un mois test sans retouche. |
| F-07 : dépenses en devises étrangères | Bonus | Utile à quelques salariés, elle départage deux offres proches. |
Deux fonctions manquent à ce tableau. F-04, la validation par le manager depuis son téléphone, est bloquante : elle sert directement l'objectif de délai. F-06, le suivi de la note par le salarié, est importante : elle épargne à la comptabilité les relances du type « où en est mon remboursement ? », un gain que le contexte ne chiffrait pas mais que tout comptable reconnaîtra.
Les contraintes tiennent en une phrase : une date de mise en service, une conservation des justificatifs conforme aux règles comptables et fiscales, des données hébergées dans l'Union européenne, une connexion avec les comptes existants. Les critères de réussite, enfin, reprennent les objectifs avec une échéance de six mois : moins de dix jours de délai, moins d'une note sur vingt renvoyée, plus aucune ressaisie.
Ce que l'exemple ne contient pas est aussi instructif : ni nom de produit, ni architecture, ni grille de prix. L'architecture relève du volet technique, les conditions de la consultation d'une autre rubrique du cahier des charges, et la grille de prix de ses annexes : l'ensemble forme le dossier de consultation. Notez enfin la boucle : un objectif chiffré en tête, des fonctions qui le servent, et un critère de réussite qui le mesure.
Fonctionnel ou technique
Le volet fonctionnel dit ce que la solution doit permettre ; le cahier des charges technique dit dans quel cadre elle doit fonctionner chez vous : hébergement, sécurité, intégrations, performances. Un test pratique pour trier une exigence : si l'utilisateur peut la constater lui-même, elle est fonctionnelle ; si seule la DSI peut la vérifier, elle est technique.
- « Le salarié retrouve ses notes des douze derniers mois » : fonctionnel.
- « Les sauvegardes sont conservées trente jours » : technique.
- « La comptabilité exporte les écritures vers son logiciel » : fonctionnel, avec un pendant technique (le format et la fréquence de l'échange).
- « Les utilisateurs se connectent avec leur compte d'entreprise » : à cheval ; placez-la une seule fois, en général dans le volet technique, où la DSI la vérifiera.
Pour un achat modeste, les deux volets tiennent dans un même document. Pour un ERP ou une GED, mieux vaut deux documents relus par les bonnes personnes : voir nos exemples de cahier des charges (ERP, GED, site web), qui suivent cette séparation.
Publié le 6 octobre 2026