Rédiger un cahier des charges que les prestataires comprennent

Nous lisons beaucoup de cahiers des charges, et nous en rédigeons aussi pour nos clients. Les moins utiles ont un point commun : ils décrivent une solution que leur auteur a en tête, écran par écran, bouton par bouton, souvent inspirée d’une démonstration vue chez un éditeur. Les prestataires y répondent « conforme » ligne par ligne, et le projet découvre les vrais besoins en cours de route.

Les plus utiles décrivent un besoin, un contexte et des contraintes, et laissent les prestataires proposer. Ils obtiennent des réponses différentes, donc comparables, et un projet qui démarre sur de bonnes bases. Voici comment les écrire.

Décrire le besoin, pas la solution

La différence tient à une question : « qu’est-ce que cela doit permettre ? » plutôt que « comment cela doit fonctionner ? ».

• Solution : « Un écran de saisie des heures avec un menu déroulant des chantiers et un bouton valider. »
• Besoin : « Les chefs d’équipe doivent pouvoir déclarer les heures de leur équipe, par chantier, depuis le terrain, en moins de cinq minutes par jour, sans ressaisie en paie. »

La seconde formulation laisse de la place à de meilleures idées que la vôtre, et elle donne un critère de recette : cinq minutes, sans ressaisie. Elle dit aussi pourquoi : c’est ce qui permet au prestataire de proposer des compromis intelligents quand un point coûte trop cher.

Les six parties d’un cahier des charges utile

1. Le contexte

Qui vous êtes, en une page : activité, taille, sites, organisation. Pourquoi ce projet maintenant : ce qui ne fonctionne pas, ce que cela coûte, ce qui se passe si rien ne change. Cette page est souvent sautée ; c’est pourtant celle qui permet au prestataire de comprendre ce qui compte pour vous. Si vous avez fait un diagnostic de maturité numérique, ses conclusions ont leur place ici.

2. Les processus concernés

Décrivez les processus tels qu’ils fonctionnent aujourd’hui, avec leurs acteurs, leurs documents et leurs outils, y compris les fichiers Excel et les e-mails. Un schéma simple vaut mieux qu’un long texte. Signalez ce qui doit changer et ce qui doit rester. Cartographier les processus avant d’écrire est le meilleur investissement du projet.

3. Les besoins

C’est le cœur du document. Pour chaque besoin : une formulation en résultat attendu, le ou les acteurs concernés, un critère vérifiable. Et surtout un classement :

• Indispensable : sans cela, le projet n’a pas de sens.
• Important : attendu, mais négociable en délai ou en forme.
• Souhaitable : apprécié si le budget le permet.

Ce classement est ce qui permet aux prestataires de proposer un périmètre réaliste et à vous d’arbitrer. Un cahier des charges où tout est indispensable n’aide personne.

4. Les contraintes

Tout ce qui s’impose au prestataire :

• les outils existants avec lesquels la solution doit échanger (ERP, comptabilité, messagerie), et ce qu’ils savent faire ;
• les données à reprendre, leur volume et leur état ;
• la sécurité et la confidentialité : qui accède à quoi, données personnelles, exigences de vos clients ;
• l’hébergement : sur vos serveurs, chez un hébergeur, en France ou en Europe ;
• la réversibilité : comment vous récupérez vos données si vous changez de prestataire ;
• le calendrier et l’enveloppe budgétaire, ou au moins une fourchette.

5. La recette

Comment vérifierez-vous que la solution est conforme ? Listez les scénarios de test les plus importants, tirés des besoins indispensables : « Un chef d’équipe déclare les heures de cinq personnes sur deux chantiers depuis un téléphone, et la paie les retrouve sans ressaisie. » Écrire la recette avant de consulter vous oblige à préciser les besoins, et donne au prestataire une idée claire de ce qu’on attend de lui.

6. Ce que vous attendez de la réponse

Un format de réponse commun rend les offres comparables : un chiffrage par lot, les hypothèses retenues, le planning, l’équipe, la maintenance et son coût annuel, deux ou trois références comparables, et une démonstration sur l’un de vos cas. Précisez aussi la date de réponse et vos critères de choix, avec leur poids.

Les erreurs les plus fréquentes

• Décrire l’outil d’un éditeur vu en démonstration, ce qui exclut les autres réponses.
• Tout rendre indispensable, donc rien de priorisé.
• Oublier la reprise des données et l’intégration avec l’existant, qui représentent souvent une part importante du coût.
• Ne rien dire de la maintenance, alors que l’outil vivra des années.
• Écrire seul, sans les équipes qui utiliseront l’outil : elles connaissent les cas particuliers qui font échouer les projets.

Ces erreurs sont à l’origine de beaucoup des échecs que nous avons décrits, avec un peu d’ironie, dans comment rater un projet de transformation.

Avant d’écrire

Un cahier des charges se rédige après avoir compris le besoin, pas pour le découvrir. Si vous n’êtes pas sûr de ce qu’il faut changer, un atelier avec les équipes sur le processus concerné, ou un prototype rapide, donnera plus que des pages de spécifications. Et si vous souhaitez un appui pour recueillir les besoins, les formaliser et mener la consultation, c’est le travail d’assistance à maîtrise d’ouvrage que nous faisons pour nos clients. Parlons de votre projet