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.
Aucun prérequis technique spécifique, mais une familiarité avec le vocabulaire de base de la gestion de projet est utile (planning, ressources, livrables).
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.
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. |
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)."
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). |
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. »).
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).
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).
✅ Réponse : La première décrit une action, la seconde décrit une qualité
✅ Réponse : L'équipe qui réalise le projet (prestataire, service interne)
✅ Réponse : Le temps de réponse moyen doit être inférieur à 300 ms
✅ Réponse : Must, Should, Could, Won't
✅ Réponse : Le périmètre
✅ Réponse : Rendre l'exigence vérifiable et mesurable
✅ Réponse : À décrire les critères d'acceptation et les tests de validation
✅ Réponse : Le cahier des charges
✅ Réponse : Entretiens individuels semi-directifs
✅ Réponse : Oublier de définir les critères de validation