Qu'est-ce qu'un cahier des charges prestation de services ?

Qu'est-ce qu'un cahier des charges prestation de services (statement of work) ? C'est le document, souvent abrégé en SOW, qui dit exactement ce qui sera livré, pour quand, par qui et pour quel montant. Il se place sous les conditions juridiques du contrat et décrit un projet précis. Dans la pratique, c'est là que se gagnent ou se perdent la plupart des litiges du type « ce n'est pas ce que nous avions convenu ».

Que contient réellement un SOW ?

Un SOW décrit un seul chantier. Il ne cherche pas à couvrir toute la relation entre deux entreprises. Les bons modèles reprennent les mêmes blocs de base.

• Périmètre : ce que le prestataire fera, avec des verbes simples, et ce qu'il ne fera pas.

• Livrables : les résultats concrets, comme une base de données migrée, une charte graphique ou 40 heures de support.

• Calendrier et jalons : des dates ou des durées, rattachées aux livrables plutôt qu'à un vague « d'ici la fin du trimestre ».

• Honoraires et échéancier : forfait, régie ou mélange des deux, avec les déclencheurs de facturation.

• Critères de recette : la manière dont le client décide qu'un livrable est terminé.

• Rôles et dépendances : qui fournit les accès, les données, les validations ou les environnements de test, et pour quand.

• Processus de changement : comment le périmètre, le prix ou les dates peuvent être modifiés une fois le travail commencé.

Concrètement, le SOW transforme une idée née d'une poignée de main en un texte qu'un tiers peut lire et vérifier. Ce tiers est souvent un juge, un auditeur ou un nouveau collègue qui reprend le projet.

En quoi un SOW se distingue-t-il d'un MSA, d'une proposition ou d'un bon de commande ?

La confusion vient de documents qui se ressemblent et se succèdent dans une même affaire.

Un contrat-cadre de prestations (MSA, pour master services agreement) porte les conditions juridiques permanentes : responsabilité, propriété intellectuelle, confidentialité, protection des données, résiliation et droit applicable. Il se signe une fois. Chaque SOW s'y rattache ensuite et couvre un projet. Un même MSA peut porter une douzaine de SOW sur plusieurs années.

Une proposition commerciale est un document de vente. Elle décrit ce que le prestataire espère faire et pourquoi vous devriez le choisir. Elle n'est en général pas contraignante, et elle sert souvent de premier brouillon au SOW, ce qui pose problème : le langage marketing finit dans le contrat.

Un bon de commande est une autorisation de paiement. Il indique un prix et une quantité, rarement un périmètre. S'appuyer sur un bon de commande seul pour une prestation laisse le travail indéfini.

Pour une mission ponctuelle, un accord unique qui intègre le SOW en annexe peut très bien suffire. La séparation entre MSA et SOW devient utile lorsque vous achetez plusieurs fois au même prestataire.

Quelle clause l'emporte quand le MSA et le SOW se contredisent ?

C'est la question que la plupart des gens esquivent, et c'est celle qui coûte de l'argent.

La plupart des accords bien rédigés suivent un schéma simple. Le MSA régit les conditions juridiques, le SOW régit le périmètre, le calendrier et les honoraires. Une clause d'ordre de préséance le dit en une ou deux phrases et désigne le document qui prévaut en cas de conflit.

Sans cette clause, il faut s'en remettre à la manière dont un tribunal lit les documents ensemble. En droit anglais, par exemple, les documents d'un contrat sont en général lus comme un seul accord : une incohérence ne s'annule pas d'elle-même. Elle crée une discussion, et les discussions se facturent.

Voici le type de formulation à rechercher, donnée comme exemple de rédaction et non comme conseil pour votre juridiction :

§ En cas de conflit, les stipulations du MSA prévalent sur celles du SOW, sauf que le SOW prévaut pour le périmètre, les livrables, le calendrier et les honoraires du projet qu'il décrit.

Attention à un piège. Un SOW qui écarte discrètement le plafond de responsabilité ou la clause de propriété intellectuelle « pour ce seul projet » est légitime lorsque les deux parties le veulent. Il devient un problème lorsque personne ne l'a remarqué. Celui qui signe un SOW doit le lire comme un contrat, pas comme un plan de projet.

Comment un périmètre tient-il face à la pression ?

Le périmètre est là où les SOW échouent. Un périmètre flou n'est jamais neutre : il avantage celui qui est le plus prêt à argumenter plus tard, c'est-à-dire en général la partie qui a le plus de poids.

Trois habitudes rendent un périmètre solide.

D'abord, écrivez les exclusions. La liste de ce qui est hors périmètre est souvent plus utile que celle de ce qui est inclus. « N'inclut pas l'intégration avec l'ancien système de facturation du client » règle une discussion qui en aurait pris trois.

Ensuite, reliez les livrables à des noms, pas à des adjectifs. « Un site responsive » se discute. « Huit gabarits, testés sur les deux dernières versions de quatre navigateurs désignés » se vérifie.

Enfin, énoncez les hypothèses. Si le calendrier dépend d'un retour du client sous cinq jours ouvrés, dites-le, et dites ce qui arrive au planning s'il ne répond pas. Une demande de retard est bien plus facile à défendre lorsque la dépendance a été écrite.

Évitez la tentation de copier un modèle et de remplir les blancs. Un modèle vous montre les titres. Il ne peut pas vous dire quelles hypothèses sont propres à votre projet.

Comment rédiger la recette et les demandes de changement ?

Les critères de recette répondent à une seule question : quand un livrable est-il assez fini pour être payé ? « Qualité élevée » ou « à la satisfaction du client » n'y répondent pas. Un critère testable, oui. Pour une migration de données, par exemple : « tous les enregistrements sont transférés et un rapport de rapprochement ne montre aucune différence non expliquée ».

Ajoutez un mécanisme d'acceptation tacite. Une pratique courante consiste à considérer un livrable comme accepté si le client n'a pas signalé par écrit de défauts dans un délai donné, souvent d'environ dix jours ouvrés. Sans ce mécanisme, le client peut bloquer la validation, et donc la facture finale, indéfiniment. Si vous êtes le client, demandez un délai de correction clair pour le prestataire, afin que le compteur soit équitable pour les deux parties.

Les demandes de changement méritent le même soin. La dérive de périmètre n'arrive presque jamais sous la forme d'une grosse demande. Elle arrive sous forme de dix petites demandes qui semblent chacune raisonnables. Un processus de changement d'un paragraphe suffit : toute modification de périmètre, de prix ou de dates exige un ordre de changement écrit, signé par les deux parties avant le début du travail. Beaucoup de prestataires perdent de la marge sur des projets simplement parce que le SOW autorisait un accord verbal.

Forfait ou régie : lequel convient à un SOW ?

La partie tarifaire modifie la répartition des risques, il faut donc la choisir délibérément.

Le forfait fait porter le risque de livraison sur le prestataire. Il fonctionne lorsque le périmètre est bien compris et qu'il risque peu de bouger. Il fonctionne mal quand le périmètre est flou, car le prestataire intégrera une marge de sécurité ou contestera chaque changement.

La régie fait porter le risque d'effort sur le client. Elle convient aux travaux exploratoires, mais elle a besoin d'un plafond ou d'un montant maximum, sinon le budget n'est qu'une opinion.

Un hybride, avec un forfait par jalon, est souvent le compromis le plus honnête. Chaque jalon a son propre livrable, son test de recette et sa facture, ce qui rend le SOW facile à auditer et facile à arrêter si le projet dérape.

Où les erreurs apparaissent-elles à la signature ?

Après avoir lu beaucoup de ces documents, les mêmes échecs reviennent.

• Signer le SOW avant que le MSA n'existe, si bien que le projet tourne sans aucune clause de responsabilité ni de propriété intellectuelle.

• Laisser les dates « environ », sans conséquence en cas de retard.

• Décrire les livrables par activité (« assurer le support ») plutôt que par résultat (« répondre aux tickets prioritaires sous quatre heures ouvrées »).

• Oublier la protection des données lorsque le prestataire traite des données personnelles. Dans l'UE et au Royaume-Uni, cela implique en général un accord de traitement des données à côté du SOW, et les détails dépendent des juridictions concernées.

• Ne jamais mettre à jour le SOW après un changement verbal, puis s'appuyer sur sa mémoire un an plus tard.

Ce n'est pas un risque théorique : c'est ce que les juristes voient régulièrement. Aucun de ces écueils ne demande un talent juridique particulier pour être évité. Il suffit de lire le document lentement avant de le signer.

Quels outils aident à rédiger, signer et relire un SOW ?

Un outil n'écrira pas un bon périmètre à votre place, mais il peut supprimer le travail répétitif qui l'entoure.

Pour rédiger à partir de blocs réutilisables, avec validations et signature électronique dans un même flux, une plateforme documentaire est pratique.

Pour la seule signature, avec piste d'audit et large acceptation chez les contreparties, un service de signature électronique dédié suffit.

Pour les équipes qui traitent beaucoup de SOW dans l'année et doivent les rattacher à un MSA, une plateforme de gestion du cycle de vie des contrats garde le lien entre les conditions-cadres et chaque document de projet.

Pour une première passe sur le risque des clauses dans Word, un complément d'IA de relecture peut signaler les exclusions manquantes ou une clause de responsabilité contradictoire avant qu'un humain ne lise le document.

Aucun de ces outils ne remplace un juriste lorsque les enjeux sont élevés. Utilisez le logiciel pour attraper les problèmes courants, puis confiez à votre conseil tout ce qui est inhabituel, important ou transfrontalier.

Ce qu'il faut faire avant de signer votre prochain SOW

Trois actions couvrent l'essentiel du risque.

1. Vérifiez qu'un MSA existe et que le SOW indique quel document prévaut sur les conditions juridiques, d'un côté, et sur le périmètre et les honoraires, de l'autre.

2. Reformulez chaque livrable pour qu'un inconnu puisse dire, oui ou non, s'il a été livré, puis ajoutez les exclusions et les hypothèses.

3. Confirmez le délai de recette, le délai de correction et la règle de l'ordre de changement écrit, puis gardez chaque avenant attaché au SOW lui-même.

Si le projet est important, touche à des données personnelles ou franchit des frontières, faites relire le document par votre conseil. La réponse dépendra du droit applicable, et une relecture courte coûte bien moins cher qu'un litige.