Cahier des charges projet : le template qui évite 80% des dérapages

Un projet sur trois dépasse son budget. Un projet sur deux dépasse ses délais. Dans la majorité des cas, la cause n'est pas technique — c'est un manque de clarté sur ce qui devait être livré. Le cahier des charges est la réponse à ce problème, à condition d'être rédigé correctement.

Ce guide vous donne la structure complète, les sections indispensables et les pièges à éviter.

---

Pourquoi les projets dérapent : les chiffres

Le Standish Group publie depuis 1994 le "Chaos Report", qui suit les résultats des projets informatiques. Les données 2023 montrent :

• 66 % des projets IT dépassent le budget ou les délais initiaux
• 19 % des projets sont abandonnés avant la livraison
• 17 % seulement sont livrés dans les temps, le budget et le périmètre prévus

Les 3 causes principales :

1. Exigences mal définies ou incomplètes (39 % des cas)
2. Changements de périmètre non contrôlés (33 % des cas)
3. Manque d'implication des utilisateurs finaux (13 % des cas)

Ces trois causes sont directement adressées par un cahier des charges bien rédigé et validé.

---

Cahier des charges fonctionnel vs technique

| Critère | Fonctionnel (CDCF) | Technique (CDCT) | |---|---|---| | Rédigé par | Commanditaire + chef de projet | Équipe technique | | Destinataire | Toutes les parties prenantes | Développeurs, architectes | | Langage | Métier, fonctionnel | Technique, précis | | Contenu | Besoins, fonctionnalités, contraintes | Architecture, stack, API, schémas | | Moment | Avant la consultation / le devis | Après validation du CDCF | | Évolution | Peu (périmètre stable) | Fréquente (précisions techniques) |

En pratique, pour les projets de moins de 6 mois, un document unique combinant fonctionnel et technique est suffisant.

---

La structure type d'un cahier des charges

Section 1 — Présentation du projet (1 page)

1.1 Contexte et enjeux

Décrivez en 3 à 5 paragraphes : qui est l'organisation commanditaire, quelle est la situation actuelle, pourquoi ce projet est lancé maintenant, et quels problèmes il doit résoudre.

1.2 Objectifs du projet

Listez les objectifs SMART (Spécifiques, Mesurables, Atteignables, Réalistes, Temporels) :

• Objectif 1 : Réduire le temps de traitement des commandes de 48h à 4h d'ici au 31/12/2025
• Objectif 2 : Augmenter le taux de satisfaction client de 72 % à 85 % en 12 mois

1.3 Périmètre du projet

Définissez explicitement ce qui est IN SCOPE et ce qui est OUT OF SCOPE. L'out of scope est aussi important que l'in scope — c'est ce qui empêche les demandes de dernière minute.

---

Section 2 — Analyse des besoins (2-3 pages)

2.1 Parties prenantes

| Partie prenante | Rôle | Intérêt dans le projet | |---|---|---| | Direction générale | Commanditaire | ROI, image | | Responsable marketing | Utilisateur principal | Efficacité quotidienne | | Équipe IT | Réalisateur | Faisabilité technique | | Clients finaux | Utilisateurs indirects | Expérience d'achat |

2.2 Personas utilisateurs

Pour chaque type d'utilisateur principal :

• Prénom fictif et rôle
• Compétences techniques (débutant / intermédiaire / expert)
• Tâches principales dans le système
• Contraintes (mobile only, contexte bruyant, connexion faible)
• Frustrations actuelles

2.3 User stories prioritaires

Format standard : "En tant que [persona], je veux [action] afin de [bénéfice]"

Classées par priorité (MoSCoW : Must Have / Should Have / Could Have / Won't Have).

---

Section 3 — Fonctionnalités (le coeur du document)

3.1 Liste des fonctionnalités

Pour chaque fonctionnalité, documentez :

| Réf | Fonctionnalité | Priorité | Complexité | Critères d'acceptation | |---|---|---|---|---| | F01 | Authentification email | Must | Faible | Connexion < 3 sec, réinitialisation MDP | | F02 | Tableau de bord | Must | Moyenne | Affichage des 5 KPIs définis en J+2s | | F03 | Export PDF | Should | Faible | Export < 5 sec, fidèle à l'affichage | | F04 | Mode sombre | Could | Faible | Bascule en 1 clic, mémorisée |

3.2 Wireframes et maquettes (si disponibles)

Annexes avec les écrans principaux. Même des croquis papier photographiés valent mieux que des descriptions textuelles.

---

Section 4 — Contraintes (non négociables)

4.1 Contraintes techniques

• Compatibilité navigateurs (Chrome 120+, Firefox, Safari, Edge)
• Compatibilité mobile (responsive, ou application native)
• Intégrations obligatoires (ERP, CRM, systèmes existants)
• Performance (temps de chargement max, capacité utilisateurs simultanés)

4.2 Contraintes réglementaires et légales

• RGPD : traitement des données personnelles
• Accessibilité : WCAG 2.1 niveau AA (obligatoire pour les organismes publics)
• Sécurité : authentification à deux facteurs, chiffrement des données sensibles

4.3 Contraintes budget et délais

• Budget maximum : X € HT
• Date de livraison impérative : JJ/MM/AAAA
• Jalons intermédiaires obligatoires

---

Section 5 — Critères de succès et recette

5.1 Critères d'acceptation globaux

Définissez AVANT le projet comment vous saurez si le projet est réussi. Exemples :

• 100 % des fonctionnalités Must Have livrées
• 0 bug bloquant à la recette
• Temps de chargement de la page principale < 2 secondes (mesuré sur 3G)
• Score de satisfaction utilisateur (test avec 5 utilisateurs) > 7/10

5.2 Procédure de recette

Définissez qui valide, comment, et dans quel délai :

• Période de test : X jours ouvrés
• Remontée des anomalies via [outil]
• Niveaux de criticité des bugs (bloquant / majeur / mineur)
• Délai de correction selon criticité

---

Section 6 — Modalités de collaboration

6.1 Gouvernance du projet

• Chef de projet côté commanditaire : [nom + contact]
• Chef de projet côté prestataire : [nom + contact]
• Fréquence des réunions de suivi : hebdomadaire / bimensuelle
• Outil de gestion de projet : Jira / Notion / Trello

6.2 Processus de validation des changements

Toute modification du périmètre doit :

1. Être formalisée par écrit (email ou ticket)
2. Faire l'objet d'une estimation d'impact (délai + budget)
3. Être validée par les deux parties avant implémentation

---

Section 7 — Annexes

• Glossaire des termes métier
• Maquettes et wireframes
• Exemples de données (fichiers d'import/export)
• Documentation des systèmes à intégrer
• Contraintes d'infrastructure

---

Checklist de validation du cahier des charges

Avant de transmettre votre CdC à un prestataire ou une équipe interne, vérifiez :

Clarté et complétude :

• [ ] Le contexte et les enjeux sont compréhensibles par quelqu'un qui ne connaît pas l'organisation
• [ ] Les objectifs sont mesurables (avec des chiffres, pas des "améliorer" ou "optimiser")
• [ ] Le périmètre IN et OUT SCOPE est explicite
• [ ] Chaque fonctionnalité a des critères d'acceptation vérifiables

Faisabilité :

• [ ] Le budget est cohérent avec le périmètre (vérification préliminaire avec un prestataire)
• [ ] Les délais sont réalistes
• [ ] Les contraintes techniques sont vérifiées avec l'équipe IT

Gouvernance :

• [ ] Les interlocuteurs côté commanditaire sont identifiés et disponibles
• [ ] Le processus de validation des changements est défini
• [ ] Les critères de recette sont établis

Validation formelle :

• [ ] Le document a été relu par toutes les parties prenantes clés
• [ ] Les corrections ont été apportées
• [ ] Une version "finale" est signée ou validée par écrit par le commanditaire

---

Les dérapages courants et comment les éviter

Dérapage 1 — Le "c'est évident"

Situation : le commanditaire n'a pas spécifié que le site devait être en français ET en anglais. L'agence a développé uniquement en français.

Cause : ce qui semble évident au commanditaire ne l'est pas pour le prestataire.

Solution : tout documenter, même l'évident. Une phrase de plus dans le CdC évite 20 heures de refactorisation.

---

Dérapage 2 — Le scope creep silencieux

Situation : en cours de projet, le commanditaire ajoute "juste un petit rapport" et "juste un export Excel". Après 6 "petits ajouts", le projet est en retard de 3 semaines.

Cause : absence de processus formel de gestion des changements.

Solution : clause de change management dans le contrat et dans le CdC, avec chiffrage systématique de tout nouveau besoin.

---

Dérapage 3 — La validation par défaut

Situation : "Je t'envoie le CdC" — pas de réponse — "OK je suppose que c'est validé" — 4 mois plus tard : "Ce n'est pas du tout ce que je voulais".

Cause : validation implicite, pas de processus de relecture formalisé.

Solution : validation écrite explicite obligatoire, avec date et version du document.

---

Dérapage 4 — Les critères d'acceptation absents

Situation : "Le site doit être rapide" — le développeur livre un site qui charge en 4 secondes — le client attendait moins de 1 seconde. Qui a tort ?

Cause : objectif non chiffré, non vérifiable.

Solution : systématiquement chiffrer les critères de performance ("< 2 secondes sur 4G, mesuré avec GTmetrix").

---

Dérapage 5 — Le CdC rédigé sans les utilisateurs

Situation : le CdC est rédigé par la direction, sans consultation des utilisateurs finaux. À la livraison, les utilisateurs refusent l'outil car il ne correspond pas à leurs habitudes de travail.

Cause : décalage entre les besoins supposés et les besoins réels.

Solution : impliquer 3 à 5 utilisateurs représentatifs dans la phase de rédaction via des interviews et tests de validation des maquettes.

---

Passer à l'action avec les bons templates

La structure décrite dans ce guide est documentée dans le Kit de spécifications projet, qui inclut les templates Word et Notion prêts à compléter, les exemples par type de projet (application web, site e-commerce, outil interne) et la checklist de validation complète — pour ne rien oublier et valider le périmètre avant que les premiers euros soient engagés.