Sommaire
Maîtriser la rédaction d'un cahier des charges : définition, objectifs, structure type (contexte, périmètre, exigences fonctionnelles et non fonctionnelles, contraintes, planning, budget), méthodes de recueil des besoins et pièges à éviter.
🎯 Objectifs de la fiche
- Définition et objectifs du cahier des charges — Document contractuel entre le maître d'ouvrage et le maître d'œuvre
- Structure type d'un cahier des charges — Présentation, contexte, périmètre, objectifs, exigences, contraintes
- Recueil et analyse des besoins — Interviews, questionnaires, ateliers, diagrammes de cas d'usage
- Exigences fonctionnelles vs non fonctionnelles — Ce que le système doit faire vs ses qualités (performance, sécurité, maintenabilité)
- Contraintes et critères d'acceptation — Techniques, budgétaires, juridiques, planning, validation
- Erreurs fréquentes et bonnes pratiques — Ambiguïté, oublis, absence de priorisation, manque de précision
Prérequis
Aucun prérequis technique spécifique, mais une familiarité avec le vocabulaire de base de la gestion de projet est utile (planning, ressources, livrables).
1. Qu'est-ce qu'un cahier des charges ?
Le cahier des charges (CDC) est un document de référence qui formalise l'ensemble des besoins, des contraintes et des objectifs d'un projet. Il sert à la fois de contrat entre le maître d'ouvrage (MOA – celui qui exprime le besoin) et le maître d'œuvre (MOE – celui qui réalise), et de guide pour l'équipe de réalisation. Ses principaux objectifs : - Clarifier et fixer le périmètre du projet. - Servir de base à la réponse (appel d'offres) ou à la planification. - Éviter les malentendus et les dérives (gloutonnement des exigences). - Constituer un référentiel pour la recette et la validation finale.
2. Structure type d'un cahier des charges
Bien qu'il n'existe pas de modèle unique, un cahier des charges complet comporte généralement les sections suivantes :
| Section | Contenu typique |
|---|---|
| 1. Présentation | Nom du projet, auteurs, destinataires, historique des versions. |
| 2. Contexte et enjeux | Raison du projet, problèmes à résoudre, opportunités. |
| 3. Objectifs du projet | Objectifs stratégiques, opérationnels et critères de réussite. |
| 4. Périmètre | Ce qui est inclus / exclu (fonctionnalités, utilisateurs, sites). |
| 5. Exigences fonctionnelles | Détail des fonctionnalités attendues (cas d'usage). |
| 6. Exigences non fonctionnelles | Performances, sécurité, disponibilité, évolutivité, maintenabilité. |
| 7. Contraintes | Techniques, budgétaires, légales, réglementaires, temporelles. |
| 8. Livrables et jalons | Liste des livrables et échéances principales. |
| 9. Planning prévisionnel | Calendrier, ressources, étapes clés. |
| 10. Budget et modalités financières | Coût estimé, pénalités, conditions de paiement. |
| 11. Critères de validation / recette | Tests de conformité, procédures d'acceptation. |
3. Recueil des besoins – méthodes et outils
Avant de rédiger, il faut recueillir et analyser les besoins des parties prenantes. Les techniques les plus courantes : - Entretiens individuels : approfondis, permettent de comprendre les attentes implicites. - Questionnaires / sondages : utiles pour recueillir des avis nombreux et standardisés. - Ateliers de co-conception : réunissent MOA et MOE pour prioriser les fonctionnalités. - Observation terrain : comprendre les processus réels (parfois différents des processus décrits). - Analyse documentaire : examiner les procédures existantes, les cahiers des charges précédents. Une fois les besoins collectés, on les structure en exigences claires, non ambigües, vérifiables et traçables.
Exemple d'expression d'un besoin (approche SMART) : ❌ Ambigu : "L'application doit être rapide." ✅ Précis : "Le temps de réponse moyen pour une requête de recherche doit être inférieur à 200 ms en condition de charge nominale (100 utilisateurs simultanés)."
4. Exigences fonctionnelles et non fonctionnelles
La distinction entre ces deux types d'exigences est fondamentale : - Fonctionnelles : décrivent ce que le système doit faire (actions, traitements, interactions utilisateur). Exemple : « Le système doit permettre la création d'un compte utilisateur avec email et mot de passe. » - Non fonctionnelles : décrivent les qualités du système (comment il le fait). Exemple : « Le système doit supporter 500 connexions simultanées avec une disponibilité de 99,9 %. »
| Catégorie | Exemples d'exigences |
|---|---|
| Fonctionnelles | Authentification, gestion de panier, export PDF, recherche avancée, workflow de validation. |
| Performance | Débit, latence, temps de réponse, temps de chargement. |
| Sécurité | Chiffrement des données, gestion des rôles, journalisation (logs), protection contre les injections. |
| Disponibilité | Taux de disponibilité (SLA), temps de reprise (RTO), temps de restauration (RPO). |
| Évolutivité | Capacité à monter en charge, à ajouter de nouvelles fonctionnalités. |
| Maintenabilité | Modularité, documentation, tests unitaires, facilité de correction et d'évolution. |
| Ergonomie / UX | Temps d'apprentissage, nombre de clics pour une tâche, conformité aux normes d'accessibilité (RGAA). |
5. Contraintes et critères d'acceptation
Les contraintes sont des limites imposées au projet, indépendantes du besoin fonctionnel. Elles peuvent être : - Techniques : langage de programmation imposé, environnement (Windows/Linux), compatibilité avec des systèmes existants. - Budgétaires : enveloppe maximale pour le développement, le matériel, les licences. - Réglementaires : RGPD (protection des données), normes sectorielles (ex: santé, banque). - Temporelles : date butoir, jalons intermédiaires obligatoires. Les critères d'acceptation définissent les conditions précises pour que le livrable soit validé par le client. Ils doivent être objectifs et mesurables (ex: « Tous les cas de test du plan de recette doivent passer sans anomalie bloquante. »).
6. Planning, ressources et budget
Le cahier des charges doit esquisser le planning et les ressources nécessaires, même si les chiffres seront précisés dans la réponse du prestataire : - Planning : diagramme de Gantt, étapes clés (kick-off, recette, déploiement), dépendances. - Ressources humaines : profils requis (chef de projet, développeurs, testeurs, administrateurs système). - Infrastructure : serveurs, bases de données, réseau, hébergement. - Budget : coût estimé, décomposition par poste (études, développement, tests, formation, maintenance).
7. Erreurs fréquentes et bonnes pratiques
Erreurs à éviter : - Exigences trop vagues ou non vérifiables (« interface intuitive », « système robuste »). - Oublier des parties prenantes (utilisateurs finaux, services supports). - Négliger les contraintes techniques ou légales. - Confondre solution technique et besoin métier (« il nous faut une base de données Oracle » au lieu de « il nous faut un stockage fiable et performant »). - Absence de priorisation (tout est « urgent » ou « prioritaire »). Bonnes pratiques : - Impliquer les utilisateurs finaux dès le début. - Utiliser des cas d'usage ou des user stories pour décrire les fonctionnalités. - Hiérarchiser les besoins (MoSCoW : Must have, Should have, Could have, Won't have). - Faire relire le document par différentes personnes pour détecter les incohérences. - Versionner le document et gérer les évolutions (amendements).
Exemple de priorisation MoSCoW pour un site e-commerce : - M (Must) : Catalogue, panier, paiement sécurisé. - S (Should) : Système de recommandation, avis clients. - C (Could) : Chat en ligne, programme de fidélité. - W (Won't) : Interface en réalité virtuelle (hors périmètre initial).
Quelle est la principale différence entre une exigence fonctionnelle et une exigence non fonctionnelle ?
✅ Réponse : La première décrit une action, la seconde décrit une qualité
Qui est le maître d'œuvre (MOE) dans un projet ?
✅ Réponse : L'équipe qui réalise le projet (prestataire, service interne)
Parmi ces exigences, laquelle est non fonctionnelle ?
✅ Réponse : Le temps de réponse moyen doit être inférieur à 300 ms
Que signifie l'acronyme MoSCoW utilisé dans la priorisation ?
✅ Réponse : Must, Should, Could, Won't
Quelle section du cahier des charges décrit ce qui est inclus et ce qui est exclu ?
✅ Réponse : Le périmètre
Quelle est l'une des meilleures pratiques pour rédiger une exigence ?
✅ Réponse : Rendre l'exigence vérifiable et mesurable
À quoi sert le plan de recette dans un cahier des charges ?
✅ Réponse : À décrire les critères d'acceptation et les tests de validation
Quel document sert de référentiel tout au long du projet ?
✅ Réponse : Le cahier des charges
Quelle méthode de recueil des besoins est la plus adaptée pour comprendre en profondeur les attentes d'un petit groupe de parties prenantes ?
✅ Réponse : Entretiens individuels semi-directifs
Quelle erreur est fréquemment commise lors de la rédaction d'un cahier des charges ?
✅ Réponse : Oublier de définir les critères de validation