Aller au contenu principal
Bonnes pratiques

Cahier des charges : ce qu'il doit contenir, ce qu'il ne doit pas

Un bon cahier des charges décrit des résultats attendus, pas des solutions. La confusion entre les deux est la première cause de devis incomparables.

Photo de David Patiashvili David Patiashvili 5 min de lecture
Carnet ouvert sur une page blanche, stylo posé en travers, sur une table claire.
Photo de Markus Spiske / Pexels
Sommaire

    Vous préparez un projet, vous consultez trois prestataires, et vous recevez trois propositions incomparables : des périmètres différents, des postes qui n’existent que chez l’un, et un écart de prix du simple au triple.

    Le réflexe est d’en conclure que les prestataires sont opaques. Dans la plupart des cas, ce n’est pas ce qui s’est passé. Ce qui s’est passé, c’est que le document qu’on leur a envoyé décrivait des solutions au lieu de décrire des résultats attendus — ou qu’il n’y avait pas de document du tout.

    La règle unique

    Un cahier des charges décrit ce qui doit être vrai à la fin. Il ne décrit pas comment y parvenir.

    Comparez ces deux formulations :

    « Il faut un espace client avec une connexion par adresse électronique et mot de passe, et un tableau listant les commandes. »

    « Un client doit pouvoir retrouver l’état de sa commande sans nous appeler, y compris six mois après. »

    La première est une solution. Elle a l’air précise, et elle est en réalité appauvrissante : elle interdit au prestataire de proposer un lien direct envoyé par message, une page accessible sans compte, ou toute autre réponse qui coûterait moins cher et servirait mieux. Vous avez fait son travail à sa place, en moins bien, et vous ne le saurez jamais.

    La seconde est une exigence. Elle est vérifiable, elle laisse les moyens ouverts, et elle permet aux propositions de différer sur ce qui compte : la manière.

    L’exception : les contraintes réelles. Un outil comptable déjà en place avec lequel il faut dialoguer, une politique de sécurité interne, une obligation sectorielle, un hébergement imposé. Celles-là s’écrivent, parce que ce ne sont pas des choix mais des données du problème.

    Ce que le document doit contenir

    Sept sections suffisent. Au-delà, on recopie.

    1. Le contexte, en une page. Ce que fait l’entreprise, à qui elle s’adresse, ce qui existe déjà, et surtout pourquoi ce projet maintenant. Un prestataire qui comprend l’urgence propose autre chose qu’un prestataire qui répond à une liste.

    2. Les utilisateurs. Qui va s’en servir, dans quelles conditions, avec quel niveau d’aisance, sur quel matériel. Une application utilisée sur un chantier avec des gants n’a rien à voir avec la même application utilisée au bureau.

    3. Les exigences, classées. Ce qui est indispensable, ce qui est souhaitable, ce qui peut attendre. Cette hiérarchie est ce que les prestataires attendent le plus, et ce qu’ils reçoivent le moins. Sans elle, tout est traité comme indispensable, et le prix suit.

    4. Ce qui existe et doit être repris. Données à migrer et leur volume, contenus, comptes, outils tiers en place, historique à conserver. La reprise de l’existant est le poste le plus systématiquement sous-estimé de tous les projets.

    5. Les contraintes. Techniques, réglementaires, calendaires. Les échéances réelles — un salon, une saison, une obligation légale — plutôt qu’une date choisie parce qu’elle sonnait bien.

    6. Ce qui est hors périmètre. Section courte, souvent absente, et pourtant décisive. Elle évite qu’un prestataire chiffre par précaution ce que vous ne vouliez pas.

    7. Ce qui viendra plus tard. Section distincte de la précédente, et tout aussi utile. Un prestataire qui sait qu’un module de facturation arrivera dans un an ne concevra pas la même structure — et ne vous la facturera pas aujourd’hui.

    Ce qu’il ne doit pas contenir

    Des maquettes détaillées, si vous n’êtes pas sûr de vous. Une maquette est une réponse. En la fournissant, vous transformez une consultation en devis d’exécution, et vous perdez l’apport de conception que vous vouliez acheter.

    Des noms de technologies, sans raison. Exiger un outil précis parce qu’on en a entendu parler restreint le champ des réponses et fait monter les prix. Si vous avez une vraie raison — vos équipes le maîtrisent, un autre outil du système l’impose —, écrivez la raison, pas seulement le nom.

    Des exigences invérifiables. « Le site doit être rapide », « moderne », « ergonomique », « sécurisé ». Ces mots ne se contractualisent pas. Écrivez plutôt : « la page d’accueil doit s’afficher en moins de deux secondes sur une connexion mobile moyenne », qui se mesure.

    Quarante pages recopiées. Un document long n’est pas un document précis. Il est simplement moins lu.

    Le budget : à dire, pas à cacher

    C’est le point sur lequel nous sommes le plus souvent contredits, alors autant être net : annoncer une fourchette de budget sert vos intérêts.

    Le taire ne fait pas baisser les prix. Cela produit des propositions hors sujet, dont certaines à cinq fois votre capacité — et vous fait perdre, ainsi qu’aux prestataires, plusieurs semaines. Un budget annoncé permet à chacun de dimensionner sa réponse, et de vous dire franchement si votre périmètre n’y entre pas. Cette phrase-là vaut de l’or, et vous ne l’entendrez jamais d’un prestataire qui ignore votre enveloppe.

    Nous détaillons ailleurs comment se construisent ces ordres de grandeur, par exemple pour une application métier.

    Imposez la structure de la réponse

    C’est le geste le plus efficace de tout le processus, et presque personne ne le fait.

    Demandez explicitement que chaque proposition contienne :

    • le même découpage que votre cahier des charges, section par section ;
    • un prix par lot, et non un total unique ;
    • ce qui est inclus et ce qui ne l’est pas — hébergement, maintenance, formation, reprise de données ;
    • les hypothèses retenues là où votre document était imprécis ;
    • les livrables et à qui ils appartiennent ;
    • le délai, avec les dépendances qui pèsent sur vous.

    Avec cette contrainte, la comparaison devient possible. Sans elle, vous comparez des totaux qui ne recouvrent pas les mêmes choses.

    Le dernier point mérite une attention particulière : la propriété des livrables se règle au moment du devis, pas à la livraison. Nous avons expliqué pourquoi payer ne suffit pas à posséder.

    Le cahier des charges ne remplace pas la conversation

    Un dernier mot, pour ne pas laisser croire à une méthode magique.

    Le meilleur document du monde ne remplacera pas une heure d’échange avec le prestataire avant qu’il chiffre. Le document sert à ce que cette heure porte sur les vraies questions, et non sur la reconstitution de votre contexte.

    Méfiez-vous d’ailleurs de celui qui chiffre sans poser de questions : soit il a compris quelque chose que vous n’avez pas écrit, soit il n’a pas lu. Les huit questions à poser à une agence valent pour l’autre sens aussi — ce qu’un prestataire vous demande en dit long sur ce qu’il fera.

    Partager

    Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.

    Ajouter aux sources préférées

    Questions fréquentes

    Un cahier des charges est-il vraiment obligatoire ?

    Rien ne l'impose, mais son absence a un coût mesurable : sans référentiel écrit, les devis reçus ne portent pas sur le même périmètre et ne sont donc pas comparables. Le document n'a pas besoin d'être long — quinze pages bien faites valent mieux que quatre-vingts pages de spécifications recopiées.

    Faut-il décrire les solutions techniques ?

    Non, sauf contrainte réelle à respecter — un outil déjà en place, une politique de sécurité, une obligation réglementaire. Décrire la solution revient à faire le travail du prestataire à sa place, en moins bien, et à lui interdire de proposer mieux. On décrit les résultats attendus, on laisse les moyens ouverts.

    Comment rendre les devis comparables ?

    En imposant la structure de la réponse : le même découpage que le cahier des charges, un prix par lot, ce qui est inclus et ce qui ne l'est pas, et les hypothèses retenues. Sans cette contrainte, chaque prestataire répond dans son format, et la comparaison porte sur des totaux qui ne recouvrent pas les mêmes choses.

    Que faire des besoins qu'on n'a pas encore ?

    Les écrire dans une section distincte, explicitement hors périmètre. Cela paraît inutile et c'est décisif : un prestataire qui sait qu'une fonctionnalité viendra dans un an ne concevra pas la même chose que s'il l'ignore, et il ne la facturera pas aujourd'hui.

    Faut-il indiquer son budget ?

    Oui, au moins sous forme de fourchette. Le taire ne protège de rien : cela produit des propositions hors sujet, et fait perdre du temps aux deux parties. Un budget annoncé permet au prestataire de dimensionner sa proposition et, le cas échéant, de dire franchement que le périmètre n'y entre pas.

    Qui doit rédiger le cahier des charges ?

    Le client, aidé si besoin, mais jamais le prestataire qui répondra ensuite : il écrirait alors les critères de sa propre sélection. Si vous vous faites accompagner pour la rédaction, veillez à ce que cet accompagnement soit distinct de la réalisation — ou assumez que la consultation n'en est pas une.

    En savoir plus

    Nos prestations associées

    Site web

    Site web public

    Vitrine institutionnelle, landing page, site éditorial — pensé avec vous pour porter votre marque sans dette technique.

    En savoir plus

    Audit

    Audit technique

    Évaluation indépendante de votre stack — code, sécurité, dette, scaling, coûts. Rapport actionnable, pas un PDF qui dort.

    En savoir plus

    Économiste

    Économiste technique

    Faire baisser la facture technique — cloud, SaaS, licences, sous-traitance — sans toucher à la qualité ni à l'équipe. Comme un économiste sur un chantier, on traque chaque poste et chaque euro mal placé.

    En savoir plus