Guide · Expression du besoin et cahier des charges
Cahier des charges : le guide complet, avec modèle et exemples
En bref
Le cahier des charges décrit le besoin, le contexte, les exigences et les contraintes d'un achat. Il sert de base à la consultation des fournisseurs, à la comparaison de leurs offres, puis souvent au contrat. Notre modèle de cahier des charges, au format Word, reprend les dix rubriques à remplir et impose aux candidats une réponse comparable.
À quoi sert un cahier des charges
Un cahier des charges a trois usages. Il permet d'abord d'obtenir des offres qui répondent toutes au même besoin. Il permet ensuite de les comparer, parce que chaque fournisseur a répondu aux mêmes questions dans le même format. Il sert enfin de référence : annexé au contrat, il dit ce qui était attendu, et c'est contre lui qu'on vérifiera la livraison. Sans cahier des charges, chaque fournisseur chiffre sa propre lecture du besoin, et les offres ne se comparent plus.
Il a aussi un usage interne, souvent sous-estimé. Le rédiger oblige le demandeur, la DSI, les Achats et parfois le juridique à se mettre d'accord avant d'aller voir le marché. Les désaccords qui surgissent pendant la rédaction auraient surgi de toute façon ; mieux vaut qu'ils apparaissent avant que les fournisseurs aient chiffré.
Gardez en tête qui le lit. Un commercial, un avant-vente et un chef de projet chez chaque candidat, qui ne connaissent ni votre entreprise ni votre jargon interne. Tout ce qui vous paraît évident mérite une phrase ; tout sigle maison, une définition.
Faut-il un cahier des charges pour chaque achat ? Non. Pour une fourniture standard, achetée sur catalogue, une demande de prix suffit. Il devient nécessaire dès que l'achat est complexe (plusieurs fonctions, plusieurs utilisateurs, une intégration), engageant (un contrat de plusieurs années) ou disputé (plusieurs fournisseurs crédibles). C'est-à-dire, en informatique, presque toujours.
Dans les marchés publics, la partie technique porte un nom précis, le CCTP (cahier des clauses techniques particulières), et la partie administrative un autre, le CCAP. Entre entreprises privées, aucune forme n'est imposée. Dans une consultation formelle, le dossier d'appel d'offres, ou RFP, réunit le cahier des charges, règles de la consultation comprises, et ses annexes : voir comment rédiger un RFP.
Les rubriques d'un cahier des charges
Que doit contenir un cahier des charges ? Le sommaire type tient en dix rubriques. Toutes ne pèsent pas autant selon l'achat, mais aucune ne devrait manquer sans raison.
| N° | Rubrique | Ce qu'on y trouve |
|---|---|---|
| 1 | Présentation de l'entreprise | Activité, taille, organisation : ce qu'un fournisseur doit savoir pour comprendre le besoin |
| 2 | Contexte et objectifs | La situation actuelle, le problème, les objectifs, chiffrés si possible |
| 3 | Périmètre et volumétrie | Ce qui est inclus, ce qui est exclu, et les chiffres : utilisateurs, sites, volumes |
| 4 | Exigences fonctionnelles | Ce que la solution doit permettre, exigence par exigence |
| 5 | Exigences techniques | L'environnement, la sécurité, les intégrations, les performances |
| 6 | Contraintes | Délais, réglementation, contraintes internes |
| 7 | Prestations attendues | Déploiement, reprise de données, formation, support, maintenance |
| 8 | Niveaux de service | Les engagements attendus et leur mesure |
| 9 | Conditions de la consultation | Calendrier, questions, format de réponse, critères de choix |
| 10 | Annexes | Grille de prix, description de l'existant, projet de contrat |
Quelques rubriques méritent une attention particulière. Les objectifs, d'abord : « moderniser notre outil » ne dit rien, « ramener le délai de traitement d'une commande de cinq jours à deux » donne un cap et un critère de réussite. La volumétrie, ensuite : nombre d'utilisateurs par profil, volumes de transactions, nombre de sites, avec leur évolution prévue. Ce sont ces chiffres qui fondent les prix.
Les prestations attendues sont souvent les grandes oubliées. Une solution ne vaut que par son déploiement : qui paramètre, qui reprend les données, qui forme, qui assure le support une fois le projet terminé ? Enfin, les conditions de la consultation fixent les règles du jeu pour tous : calendrier, interlocuteur unique, date limite des questions, plan de réponse et critères. Un candidat qui connaît les règles répond mieux, et plus vite.
La longueur suit l'enjeu. Quelques pages suffisent pour un achat simple, plusieurs dizaines sont normales pour un ERP. Le bon test : un fournisseur qui ne vous connaît pas peut-il chiffrer sans vous appeler ? Si oui, le document est assez long. S'il fait 80 pages et que personne ne l'a lu jusqu'au bout chez vous, il est trop long.
Comment rédiger un cahier des charges ? Dans cet ordre :
- Recueillir l'expression du besoin du demandeur, et la compléter par les questions qu'il n'a pas posées.
- Réunir les contributeurs (métier, DSI, Achats, juridique si besoin) et se mettre d'accord sur le périmètre et les objectifs.
- Rédiger les exigences fonctionnelles et techniques, numérotées et priorisées.
- Ajouter la volumétrie, les contraintes et les prestations attendues.
- Fixer le format de réponse, la grille de prix et les critères de choix.
- Faire relire par quelqu'un qui n'a pas participé : s'il ne comprend pas le besoin, un fournisseur non plus.
Fonctionnel ou technique
Un cahier des charges complet a deux parties complémentaires. La partie fonctionnelle décrit ce que la solution doit permettre à ses utilisateurs ; la partie technique décrit le cadre dans lequel elle doit fonctionner chez vous.
| Fonctionnel | Technique | |
|---|---|---|
| La question | Que doit permettre la solution ? | Dans quel cadre doit-elle fonctionner ? |
| Rédigé par | Le métier, avec les Achats | La DSI |
| Exemple | « Le manager valide une note de frais depuis son téléphone » | « Les utilisateurs se connectent avec leur compte d'entreprise » |
| Si on l'oublie | Une solution qui ne sert pas le métier | Une solution inutilisable dans votre système |
Pour un achat modeste, les deux tiennent dans un même document, en deux sections. Pour un projet important, on rédige souvent un cahier des charges fonctionnel et un cahier des charges technique distincts, chacun relu par les bonnes personnes.
Certaines exigences sont à cheval sur les deux. « Les factures validées sont envoyées au logiciel comptable chaque nuit » décrit à la fois un besoin (ne plus ressaisir) et une contrainte technique (une intégration). Rédigez le besoin côté fonctionnel, le format et la fréquence de l'échange côté technique, avec un renvoi de l'un à l'autre : chaque exigence n'apparaît qu'une fois, et un seul responsable la valide.
Décrire le besoin, pas la solution
C'est l'erreur la plus fréquente, et la plus coûteuse : recopier la fiche produit d'un fournisseur qu'on a déjà rencontré. Le cahier des charges décrit alors une solution au lieu d'un besoin. Les autres candidats ne peuvent pas proposer mieux, la concurrence disparaît, et le fournisseur dont on a recopié la fiche le sait très bien au moment de fixer son prix.
Comparez deux formulations. « Le logiciel doit comporter un module de validation mobile version 12 » décrit un produit. « Un manager doit pouvoir valider une facture en moins de trois actions depuis son téléphone » décrit un besoin, que plusieurs solutions peuvent satisfaire, et qui se vérifie en recette.
Le besoin se travaille en amont, avant même le cahier des charges : c'est le rôle de l'expression du besoin, rédigée par le demandeur avec ses mots, puis complétée par les questions des Achats. Les vraies contraintes techniques restent légitimes : s'il faut s'intégrer à votre logiciel comptable, dites-le, avec la raison. Une contrainte justifiée n'est pas une solution imposée.
Pensez aussi à autoriser les variantes. Un candidat qui propose une autre manière d'atteindre vos objectifs vous apporte parfois la meilleure idée de la consultation. Demandez-lui simplement de répondre d'abord à votre cahier des charges tel qu'il est écrit, puis de présenter sa variante à part, chiffrée séparément.
Exigences, critères et format de réponse
Une exigence bien écrite tient sur une ligne, porte un numéro, une priorité, et se vérifie. « L'outil doit être ergonomique » n'est pas une exigence : personne ne peut prouver le contraire. « Un nouvel utilisateur crée seul une demande après quinze minutes de prise en main » en est une.
| Formulation vague | Exigence vérifiable |
|---|---|
| L'outil doit être rapide. | Une recherche dans l'ensemble des documents affiche ses résultats en moins de deux secondes. |
| Le prestataire doit être réactif. | Un incident bloquant est pris en charge en moins d'une heure ouvrée. |
| La solution doit être sécurisée. | Les données sont hébergées dans l'Union européenne et l'accès se fait avec une double authentification. |
Trois niveaux de priorité suffisent :
- Bloquant : l'offre est écartée si l'exigence n'est pas couverte.
- Important : l'exigence pèse dans la note.
- Bonus : elle départage des offres proches.
Le format de réponse fait le reste. Imposez un tableau des exigences à compléter (conforme, partiel, non conforme, avec un commentaire), un plan de réponse et une grille de prix détaillée par poste : sans ces trois éléments, vous passerez plus de temps à remettre les offres en forme qu'à les analyser. Annoncez aussi vos critères de choix et leur poids avant de recevoir les offres, et demandez un coût complet sur la durée du contrat plutôt qu'un prix de départ.
La grille de prix mérite le même soin que les exigences : une ligne par poste (licences ou abonnements, mise en œuvre, reprise de données, formation, support, maintenance), une unité, une quantité que vous fixez vous-même. Les candidats ne remplissent que les prix unitaires, et les totaux se comparent ligne à ligne. Pour noter les réponses, une grille d'analyse des offres pondérée reprend vos critères dans le même ordre.
Les erreurs fréquentes
- Recopier la plaquette d'un fournisseur, et écarter tous les autres sans le vouloir.
- Tout classer en Bloquant. Quand tout est prioritaire, plus rien ne l'est, et soit toutes les offres sont écartées, soit aucune.
- Oublier la volumétrie : sans chiffres, chaque candidat chiffre ses propres hypothèses.
- Laisser le périmètre flou et ne pas écrire les exclusions.
- Oublier l'après : formation, support, maintenance, réversibilité.
- Ne pas imposer de format de réponse.
- Rédiger seul, sans le métier ni la DSI, puis découvrir les vrais besoins en soutenance.
- Modifier le cahier des charges en cours de consultation sans prévenir tous les candidats en même temps.
- Fixer une date limite de remise trop courte : les meilleurs candidats, qui ont d'autres consultations en cours, renoncent ou bâclent.
- Garder pour soi le budget ou les contraintes de calendrier, puis rejeter toutes les offres qui ne les respectent pas.
La plupart de ces erreurs ont le même coût : des offres impossibles à comparer, puis des avenants une fois le contrat signé. Le cahier des charges coûte quelques jours de travail ; un avenant signé faute de l'avoir écrit coûte souvent davantage.
Télécharger le modèle
Le modèle, au format Word, reprend les dix rubriques ci-dessus. Il contient un tableau d'exigences fonctionnelles et techniques avec leur priorité et une colonne de réponse pour le candidat, un tableau de niveaux de service, le calendrier et les conditions de la consultation. Pour le recevoir par e-mail, remplissez le formulaire en haut de page.
Si vous utilisez Naigo, l'agent de rédaction de consultation produit un premier jet du cahier des charges en Word, avec les annexes en Excel, à partir du besoin validé et de vos propres modèles. Vous gardez la main sur chaque modification.
Le modèle est un point de départ, pas un formulaire à remplir mécaniquement. Supprimez les rubriques sans objet, ajoutez celles que votre achat impose (une exigence réglementaire propre à votre secteur, par exemple) et faites-le relire par ceux qui l'utiliseront : le demandeur pour le fond, la DSI pour la technique.
Exemples par type de projet IT
La structure reste la même d'un achat à l'autre ; ce qui change, ce sont les exigences propres à chaque type de projet. Nous proposons des exemples de cahier des charges (ERP, GED, site web), la plupart avec leur modèle Word :
| Projet | Ce qui lui est propre | Page |
|---|---|---|
| ERP | Processus couverts, reprise de données, intégrations, rôle de l'éditeur et de l'intégrateur | Cahier des charges ERP |
| GED | Documents et volumes, plan de classement, droits, conservation | Cahier des charges GED |
| Site web | Objectifs, arborescence, référencement, propriété du site | Cahier des charges site web |
| Infogérance, TMA | Périmètre, volumétrie, niveaux de service, réversibilité | Cahier des charges d'infogérance |
| Logiciel SaaS | Hébergement, sécurité, intégrations, sortie des données | Exemple technique pour un SaaS |
Un conseil pour bien utiliser ces exemples : partez du modèle le plus proche de votre projet, puis retirez tout ce qui ne vous concerne pas. Un cahier des charges recopié en entier, avec des exigences que personne chez vous n'a demandées, fait monter les prix et brouille les priorités.
Publié le 6 octobre 2026