Cahier des charges fonctionnel : le guide pour DSI et directions générales
- Ce qu’est réellement un cahier des charges fonctionnel et ce qu’il n’est pas
- Les sections indispensables pour un document exploitable
- Les erreurs les plus fréquentes dans sa rédaction
- Comment le faire valider correctement par les parties prenantes
Ce qu’est un cahier des charges fonctionnel : ce qu’il n’est pas
Le cahier des charges fonctionnel (CdCF) décrit ce que le système doit faire, du point de vue des utilisateurs et des métiers. Il ne décrit pas comment le système doit le faire techniquement : c’est le rôle du cahier des charges technique, produit ensuite par les équipes IT ou les prestataires.
Cette distinction est fondamentale. Quand une institution rédige elle-même ses spécifications en mélangeant les deux niveaux, elle confie implicitement les choix fonctionnels aux développeurs, qui vont naturellement privilégier les solutions techniques qu’ils maîtrisent. Le résultat est un système qui fonctionne techniquement mais qui ne sert pas les pratiques métier.
Règle simple : Si votre cahier des charges mentionne des technologies, des frameworks ou des bases de données, vous avez glissé dans le technique. Revenez au fonctionnel : « le système doit permettre à l’utilisateur de… »
Les sections indispensables d’un CdCF exploitable
1. Le contexte et les objectifs
Pas une présentation de l’institution : une description précise du problème que le système doit résoudre, des objectifs mesurables attendus et du périmètre couvert. Cette section est souvent bâclée, ce qui conduit les prestataires à interpréter librement les priorités.
2. La cartographie des parties prenantes
Qui utilise le système ? Dans quelles conditions ? Avec quelle fréquence ? Quelles contraintes spécifiques (accessibilité, langue, niveau technique) ? Un système hospitalier utilisé simultanément par des chirurgiens, des infirmières et des administratifs n’a pas les mêmes exigences d’interface pour chaque profil.
3. Les cas d’usage
Pour chaque fonctionnalité, un cas d’usage décrit le scénario complet : qui fait quoi, dans quelle condition, avec quel résultat attendu, et que se passe-t-il en cas d’erreur. C’est la section la plus longue et la plus importante. Elle transforme des besoins vagues (« le système doit être facile à utiliser ») en exigences vérifiables (« l’utilisateur doit pouvoir compléter la saisie en moins de 3 étapes »).
4. Les exigences non fonctionnelles
Performance, disponibilité, sécurité, conformité réglementaire, accessibilité. Ces contraintes sont souvent omises du CdCF parce qu’elles semblent évidentes. Elles ne le sont pas pour un prestataire externe qui optimise son développement. En milieu hospitalier et bancaire, les exigences LPD, FINMA et les normes de continuité de service doivent figurer explicitement.
5. La matrice de traçabilité des exigences
Chaque exigence reçoit un identifiant unique, une priorité (obligatoire/souhaitable/optionnel) et une référence au besoin métier qu’elle couvre. Cette matrice est l’outil qui permet de vérifier que rien n’a été oublié, et de justifier les arbitrages lors de la recette.
En pratique : Dans un projet de refonte documentaire conduit dans une institution sociale cantonale couvrant 50 sites, la matrice de traçabilité a permis d’identifier que 23% des exigences initiales étaient redondantes et que 18% de besoins critiques n’avaient pas été formalisés. Sans cet outil, ces écarts n’auraient été détectés qu’en phase de recette.
Les erreurs les plus fréquentes
Rédiger seul, sans les utilisateurs terrain
C’est l’erreur la plus coûteuse. Les responsables IT et les directeurs connaissent les processus officiels. Les utilisateurs terrain connaissent les processus réels, qui divergent souvent des premiers. Un CdCF rédigé sans entretiens avec les utilisateurs opérationnels produit des spécifications qui correspondent à ce que la direction pense que les équipes font, pas à ce qu’elles font réellement.
Confondre solution et besoin
Écrire « le système doit avoir un tableau de bord Power BI » au lieu de « le système doit permettre à la direction de visualiser les indicateurs de performance en temps réel ». La première formulation ferme la porte à d’autres solutions potentiellement plus adaptées. La seconde laisse la liberté de choisir le meilleur outil en phase technique.
Ne pas définir les critères d’acceptance
Chaque exigence doit s’accompagner d’un critère de validation objectif : comment saura-t-on que cette fonctionnalité est livrée correctement ? Sans ce critère, la recette devient une négociation entre le prestataire et le client sur ce que « livré correctement » signifie. Ce débat, au moment de la recette, coûte du temps et génère des tensions.
Attention : Un CdCF validé par signature sans relecture approfondie n’est pas un CdCF validé. C’est un document que personne n’a lu mais dont tout le monde portera la responsabilité en cas de litige.
Comment organiser la validation par les parties prenantes
La validation d’un CdCF n’est pas un événement ponctuel. C’est un processus structuré en plusieurs étapes :
- Revue par les utilisateurs clés : chaque cas d’usage est présenté aux utilisateurs qui vont le vivre au quotidien. Leurs retours alimentent une version révisée.
- Validation technique par la DSI : vérification que les exigences non fonctionnelles sont réalistes et conformes aux contraintes d’infrastructure existantes.
- Arbitrage direction : les exigences en conflit ou les choix à impact budgétaire remontent à la direction pour décision explicite, documentée dans le CdCF.
- Signature formelle avec liste de présence : le document final est signé par les représentants de chaque partie prenante identifiée, avec la liste des personnes ayant participé aux revues.
Checklist de complétude d’un CdCF
- Contexte et objectifs mesurables définis
- Parties prenantes cartographiées avec leurs contraintes spécifiques
- Cas d’usage rédigés avec scénarios nominaux et alternatifs
- Exigences non fonctionnelles explicites (performance, sécurité, conformité)
- Matrice de traçabilité avec identifiants et priorités
- Critères d’acceptance pour chaque exigence obligatoire
- Glossaire des termes métier utilisés
- Validation formelle avec signatures des parties prenantes
Questions fréquentes
Combien de temps faut-il pour rédiger un CdCF ?
Entre deux semaines et deux mois selon la complexité du projet et le nombre de parties prenantes. Un CdCF pour un système multi-services hospitalier nécessite plus de cycles de validation qu’un CdCF pour une application interne à périmètre unique. L’étape la plus longue est généralement le recueil des besoins terrain, pas la rédaction elle-même.
Le CdCF est-il directement utilisable pour un appel d’offres ?
Oui, c’est son usage principal. Un CdCF bien structuré permet aux prestataires de comprendre précisément le périmètre fonctionnel, d’estimer avec réalisme et de proposer une architecture technique adaptée. Il protège également l’institution en cas de litige : les exigences sont formalisées et validées avant le début du développement.
Qui doit rédiger le CdCF dans une institution ?
Idéalement un Business Analyst qui fait l’interface entre les métiers et l’IT. Les équipes IT seules tendent à glisser vers le technique. Les équipes métier seules tendent à produire des listes de souhaits sans cohérence fonctionnelle. La valeur du BA est précisément dans cette capacité à structurer les deux dimensions de façon cohérente.
Le CdCF peut-il évoluer en cours de projet ?
Oui, mais selon un processus contrôlé. Toute modification doit être documentée, validée par les mêmes parties prenantes que le document initial, et son impact sur le planning et le budget doit être évalué explicitement. Un CdCF qui change sans traçabilité cesse d’être un document de référence.
Quelle est la différence entre un CdCF et un cahier des charges général ?
Un cahier des charges général mélange souvent les dimensions fonctionnelles, techniques, contractuelles et organisationnelles. Le CdCF se concentre exclusivement sur les exigences fonctionnelles : ce que le système doit faire pour les utilisateurs. Cette spécialisation le rend plus exploitable par les équipes techniques et plus facile à valider par les métiers.
Vous devez rédiger un cahier des charges pour un projet SI ?
Un premier échange permet de définir le périmètre, le niveau de détail nécessaire et la méthode adaptée à votre contexte institutionnel.
Prendre rendez-vous