Vous avez remporté le contrat. Trois semaines après le début du projet, le client demande une deuxième série de designs que vous n'aviez jamais inclus dans le devis, et le projet que vous aviez cadré sur quatre semaines déborde discrètement sur six. Un cahier des charges est le document qui empêche cela d'arriver. Ce guide explique ce qu'est un cahier des charges, les neuf éléments que tout bon document doit contenir, un exemple complété, et comment en rédiger un qui tient la route quand le travail devient difficile.

Un cahier des charges, ou SOW (statement of work), est un document qui définit le travail dans le cadre d'un projet ou d'une prestation de services : les livrables, le calendrier, les conditions de paiement et les critères d'acceptation, ainsi que ce qui est explicitement hors périmètre. Il transforme un accord au stade de la proposition en un document précis, signable, auquel les deux parties peuvent être tenues. Un contrat établit la relation juridique. Le SOW définit le travail.

Qu'est-ce qu'un cahier des charges ?

Un cahier des charges est le document qu'un prestataire de services et un client signent pour convenir exactement de ce qui sera fait, dans quel délai, pour quel montant, et de la manière dont chacun saura que c'est terminé. Les SOW sont particulièrement courants dans les agences, les cabinets de conseil, les services professionnels, l'informatique et la construction, partout où une entreprise réalise une mission définie pour une autre.

C'est le pont entre la vente et l'exécution. La proposition indiquait ce que vous pouviez faire. Le SOW indique ce que vous ferez, avec suffisamment de détails pour que personne n'ait à deviner par la suite.

Ce niveau de détail est essentiel. Le dérapage de périmètre n'est pas rare : une étude du PMI a révélé que 52 % des projets en sont victimes, contre 43 % cinq ans plus tôt. Un SOW est l'assurance la moins coûteuse qui soit pour s'en prémunir, car un travail consigné par écrit et signé est un travail que personne ne peut étendre discrètement.

Cahier des charges, périmètre des travaux, MSA et contrat : quelles différences ?

Ces quatre termes sont souvent utilisés comme s'ils signifiaient la même chose. Ce n'est pas le cas.

  • Le périmètre des travaux (scope of work) est une section à l'intérieur du cahier des charges : la description du travail concret. On dit souvent « périmètre des travaux » pour désigner l'ensemble du SOW, mais techniquement le périmètre correspond au « quoi », tandis que le SOW est le document qui l'enveloppe avec les délais, le paiement et l'acceptation.
  • Le contrat-cadre de services (MSA, Master Service Agreement) est le contrat juridique global qui régit l'ensemble de la relation : responsabilité, confidentialité, conditions de paiement, résolution des litiges. De nombreux contrats de services reposent sur un seul MSA, puis sur un SOW distinct pour chaque mission, de sorte que les conditions juridiques sont convenues une seule fois et seul le travail change.
  • Le contrat est l'accord juridiquement contraignant. Un SOW signé constitue généralement un contrat, ou en fait partie. Si vous cherchez à comparer ces documents, la différence entre une proposition et un contrat est une lecture complémentaire utile.

Pour replacer le SOW dans son contexte : il est issu des marchés publics, où il se distingue du Performance Work Statement et du Statement of Objectives. Dans le cadre commercial, vous aurez rarement besoin de cette distinction. Ce dont vous avez besoin, c'est que le travail soit clairement consigné et signé.

Les 9 éléments d'un cahier des charges

La plupart des équipes savent qu'elles devraient documenter le périmètre, mais ne le font pas. Dans une enquête sectorielle, seulement environ la moitié des organisations déclaraient créer « la plupart du temps » ou « toujours » un document de cadrage lors de la planification. Voici la structure qui rend cela rapide. Considérez-la comme un squelette à remplir, non comme une page blanche à contempler.

  1. Contexte et objectifs. Pourquoi ce projet existe et quel résultat il vise. À quoi ressemble un bon résultat : un court paragraphe qu'un nouveau membre de l'équipe pourrait lire et comprendre l'objet du travail.
  2. Périmètre des travaux. Le travail spécifique, rédigé sous forme de tâches concrètes. À quoi ressemble un bon résultat : des verbes et des noms, pas des adjectifs. « Concevoir cinq pages de destination », pas « offrir une présence web de qualité ».
  3. Livrables. Les éléments tangibles que vous remettez, chacun défini précisément. À quoi ressemble un bon résultat : le format et la quantité sont précisés, par exemple « cinq maquettes de pages livrées sous forme de fichiers Figma ».
  4. Hors périmètre. Ce que vous ne faites explicitement pas. À quoi ressemble un bon résultat : c'est la section qui sauve le projet. Nommez les demandes adjacentes évidentes (révisions supplémentaires, rédaction, hébergement) et excluez-les par écrit.
  5. Calendrier et jalons. Dates et points de contrôle. À quoi ressemble un bon résultat : des jalons liés aux livrables, pour que la progression soit visible et ne se résume pas à un simple calendrier.
  6. Calendrier de paiement. Montants, déclencheurs et conditions. À quoi ressemble un bon résultat : des paiements liés aux jalons ou à l'acceptation, pas seulement aux dates, afin que le règlement suive l'approbation des travaux.
  7. Critères d'acceptation. Comment un livrable est jugé terminé. À quoi ressemble un bon résultat : objectif et vérifiable, afin que « terminé » soit un fait, non un sujet de discussion.
  8. Hypothèses et dépendances. Ce sur quoi vous comptez de la part du client : accès, contenus, validations dans les délais. À quoi ressemble un bon résultat : les obligations du client sont nommées, de sorte qu'un retard causé par le client lui soit imputable.
  9. Gestion des modifications. Comment une modification du périmètre est demandée, chiffrée et approuvée. À quoi ressemble un bon résultat : un processus écrit court, signé de la même façon que le SOW initial. C'est ce qui transforme un « est-ce que vous pourriez aussi... » en un avenant rapide et rémunéré, plutôt qu'en demi-journée offerte.

Exemple de cahier des charges

Voici le squelette complété pour une petite mission de création de site web, simplifié pour illustrer la structure.

Projet : Refonte du site marketing de Northwind Co.
Objectifs : Remplacer le site actuel de cinq pages par un site plus rapide, conforme à l'identité de marque, qui favorise la capture de leads.
Périmètre des travaux : Concevoir et développer cinq pages (accueil, produit, tarifs, à propos, contact). Migrer les contenus existants. Mettre en place un formulaire de contact connecté au CRM du client.
Livrables : Cinq maquettes de pages (Figma), un site développé sur le CMS du client, un formulaire de contact connecté.
Hors périmètre : Rédaction de nouveaux contenus, migration du blog, hébergement continu, travaux SEO, plus de deux cycles de révisions des designs.
Calendrier : Lancement semaine 1, maquettes semaine 3, développement semaines 4 à 5, mise en ligne semaine 6.
Paiement : 50 % à la signature, 50 % à l'acceptation du lancement. Paiement à 14 jours.
Acceptation : Chaque page correspond à la maquette approuvée et se charge en moins de deux secondes sur une connexion standard.
Hypothèses : Le client fournit les accès, les éléments de marque et les contenus avant la fin de la semaine 1.
Gestion des modifications : Toute nouvelle demande est cadrée, chiffrée et ajoutée sous forme d'avenant signé avant le début des travaux.

Remarquez comment les lignes « hors périmètre » et « acceptation » font l'essentiel du travail de protection. Ce sont elles qui font la différence entre un projet qui se termine et un projet qui dérive.

Comment rédiger un cahier des charges, étape par étape

  1. Partez de ce que vous avez déjà convenu. Reprenez le périmètre, le prix et le calendrier de la proposition ou du devis. Ne réinventez pas des conditions que vous avez déjà vendues.
  2. Rédigez le périmètre sous forme de tâches, puis précisez ce qui est hors périmètre. Les exclusions ne sont pas impolies. C'est le cadeau le plus clair que vous puissiez faire à un client, car elles définissent des attentes honnêtes.
  3. Définissez chaque livrable avec ses critères d'acceptation. Associez chaque « nous livrerons X » à un « X est terminé quand Y ». Cette seule habitude prévient la plupart des litiges en fin de projet.
  4. Associez les jalons aux paiements. Liez chaque paiement à un jalon ou à un livrable accepté, afin que la trésorerie suive l'avancement.
  5. Ajoutez des hypothèses et une clause de gestion des modifications. Précisez ce dont vous avez besoin de la part du client et le processus exact de traitement des nouvelles demandes.
  6. Envoyez-le pour signature avant le début des travaux. Un SOW non signé n'est qu'un vœu. Le faire signer en amont fait partie des raisons pour lesquelles les équipes rigoureuses réussissent : dans le secteur, seulement 31 % des projets sont livrés dans les délais, dans le budget et dans le périmètre prévu, et un périmètre non signé et flou en est l'une des principales causes.

Les erreurs qui laissent le dérapage de périmètre s'installer

La plupart des problèmes de périmètre se ramènent aux mêmes lacunes :

  • Des livrables vagues. « Un site web » ouvre la porte aux discussions. « Cinq pages, ces templates, ce CMS » n'en ouvre aucune.
  • Absence de section hors périmètre. Si vous ne précisez pas ce que vous n'incluez pas, le client supposera que vous le faites.
  • Aucun critère d'acceptation. Sans test de « fin de mission », chaque livrable peut être remis en question.
  • Aucune gestion des modifications. Sans processus écrit, chaque nouvelle demande devient une négociation, et généralement gratuite.
  • Aucune signature. Un SOW non signé ne protège personne.

Ces lacunes ont un coût. Le PMI estime que les organisations gaspillent près de 10 % de chaque dollar investi en raison de mauvaises performances de projet. Un SOW plus rigoureux est l'un des moyens les moins coûteux de récupérer une partie de ces pertes.

D'un deal conclu à un SOW signé, sans ressaisie

La plupart des SOW sont encore construits manuellement : on ouvre le document du client précédent, on remplace les noms, on ressaisit le périmètre et les chiffres, on exporte un PDF, on l'envoie par e-mail, puis on relance pour obtenir la signature. Chaque étape est une occasion d'envoyer un mauvais chiffre.

Les données dont vous avez besoin se trouvent déjà dans votre CRM. Le deal que vous venez de conclure contient le client, les lignes tarifaires, le prix et le responsable. Portant génère le statement of work à partir d'un modèle que vous utilisez déjà, le remplit avec les données de votre deal HubSpot et ses lignes tarifaires, et intègre une eSignature native, de sorte que le document signé se synchronise avec la fiche du deal en indiquant son statut. Vous conservez votre propre modèle et votre mise en forme. Personne ne ressaisit un deal qui existe déjà dans le CRM. C'est la même logique que celle qui sous-tend l'automatisation des documents en général : arrêtez de recréer des documents que vous avez déjà.

Questions fréquentes

Qu'est-ce qu'un statement of work en gestion de projet ?

En gestion de projet, le statement of work est le document qui définit le périmètre, les livrables, le calendrier et les critères d'acceptation du projet avant le début des travaux. C'est la référence à laquelle tout le monde revient lorsqu'une question de périmètre se pose.

Qui rédige le statement of work ?

C'est généralement le prestataire qui en rédige le premier jet, car il connaît le travail à effectuer, puis le client le révise et le signe. Pour les missions plus importantes, un chef de projet ou un responsable de compte en est le propriétaire, en partant souvent de la proposition déjà validée par le commercial.

Un statement of work a-t-il une valeur juridique contraignante ?

Un SOW signé est généralement contraignant, que ce soit en tant que contrat autonome ou en tant qu'ordre de travail dans le cadre d'un accord-cadre de services. Faites examiner votre modèle de contrat par un juriste au moins une fois, en particulier les clauses relatives au paiement, à la responsabilité et à la résiliation.

Quelle est la différence entre un statement of work et un bon de commande ?

Un statement of work décrit le travail à réaliser et les critères permettant de le considérer comme terminé. Un bon de commande est l'autorisation donnée par l'acheteur de dépenser un montant défini pour ce travail. Le SOW définit le travail ; le bon de commande engage le budget.

Quelle longueur doit avoir un statement of work ?

La longueur nécessaire pour éliminer toute ambiguïté, et pas davantage. Un SOW de services bien ciblé fait souvent deux à quatre pages. La clarté prime sur la longueur : un SOW concis de trois pages vaut mieux qu'un document de dix pages rempli de redondances.

Si vos SOW sont rédigés dans un Google Doc que vous copiez et modifiez pour chaque client, vous pouvez connecter ce modèle à votre CRM et l'envoyer pour signature en un seul flux. Découvrez comment Portant crée et envoie un statement of work à partir d'un HubSpot document template.