Cahier des charges de transformation numérique : le modèle pour une PME

Pourquoi cette page n'a pas de formulaire. Le 19 septembre 2026, les huit premiers résultats sur « cahier des charges transformation numérique PME modèle » étaient des blogs de prestataires : le modèle s'obtient contre une adresse. Cette page donne le contenu. Si vous voulez un regard sur votre document une fois rédigé, écrivez-nous ; ce n'est pas une condition pour lire ce qui suit.

À quoi sert un cahier des charges quand on n'a pas de DSI ?

Il sert à une seule chose : qu'un prestataire que vous n'avez jamais rencontré puisse chiffrer le même travail qu'un autre, sans vous rappeler toutes les deux heures. Ce n'est pas un dossier de financement, ni une spécification technique, ni le contrat : celui-ci reprend ensuite les clauses du cahier, il ne les invente pas. Dans une PME, le document est souvent écrit par le dirigeant ou le DAF, entre deux réunions. C'est suffisant. Vous n'avez pas à connaître les frameworks. Vous avez à connaître vos flux : qui saisit quoi, où ça casse, ce qui doit tourner le lundi matin après la bascule. La méthode de transformation en quatre étapes décrit le chemin ; le cahier des charges est la pièce que vous envoyez aux cabinets pour qu'ils s'y engagent.

Qu'est-ce qui doit être chiffré, et qu'est-ce qui ne doit pas l'être trop tôt ?

Chiffrer, ici, veut dire donner un nombre que le prestataire peut utiliser pour dimensionner. Les volumes d'abord : 180 devis par mois, 4 sites, 12 utilisateurs simultanés, un export comptable tous les soirs. Les délais ensuite : le devis part aujourd'hui en quatre jours, la cible est un jour. Les fenêtres de bascule : pas de coupure un lundi, inventaire le 31. Ces nombres coûtent cher s'ils sont faux ; ils coûtent plus cher s'ils sont absents, parce que chaque candidat les invente.

Ce qu'il ne faut pas chiffrer trop tôt : le nombre de jours, l'architecture, le langage, le nom de l'outil cible. « Nous voulons un ERP cloud, 40 jours de paramétrage » décrit une solution copiée sur une démo. Vous fermez le marché aux cabinets qui auraient proposé moins, ou autrement. Nommez l'existant (« nous facturons dans Sage, les commandes arrivent par e-mail ») et les contraintes réelles. Laissez le comment aux candidats. Le détail de ce que coûte réellement une mission montre ensuite comment lire les montants qu'ils vous renverront.

Comment rédiger le cahier des charges, section par section

Neuf sections. Pour chacune : ce que vous y écrivez, la question à laquelle elle répond côté prestataire, l'erreur classique. Si une section n'a rien à dire, elle reste courte. Elle ne disparaît pas : une absence écrite (« pas de contrainte d'hébergement imposée ») vaut mieux qu'une absence silencieuse.

1. Contexte et objet

Deux pages, pas six. Qui vous êtes, ce qui ne tourne plus, ce que le prestataire doit avoir livré à la fin, en une phrase. « À la fin de la mission, un devis part du premier appel sans ressaisie, et la facture correspondante est dans la comptabilité le soir même. » Question du prestataire : est-ce mon métier, et à quelle échelle ? Erreur classique : raconter l'histoire de l'entreprise depuis 1987. Il s'en sert pour une slide, pas pour chiffrer.

2. Périmètre inclus et exclu

Deux listes. Inclus : les flux, les populations, les sites, les langues. Exclu : ce qui reste en l'état, ce qui sera un lot 2, ce que vos équipes feront elles-mêmes (reprise des données, formation des saisonniers, paramétrage comptable). Question du prestataire : où s'arrête mon engagement ? Erreur classique : une seule liste, celle du souhaitable. Sans hors-périmètre, chaque atelier élargit le contrat. C'est le premier réflexe à croiser avec les signaux d'un cabinet qui exécute : celui qui vous dit non sur une ligne de cette liste est souvent le plus fiable.

3. Existant

Nommer les outils, les versions si vous les avez, les fichiers qui font le vrai travail, les personnes qui les tiennent. « Les relances sont un tableur dans le dossier partagé de Marie, mis à jour le vendredi. » Joindre trois captures et un export anonymisé vaut dix pages de prose. Question du prestataire : que dois-je reprendre, et qu'est-ce qui cassera à la bascule ? Erreur classique : décrire le système cible et taire Excel. Le devis ignore alors la reprise, qui est précisément ce qui fait déraper le calendrier.

4. Objectifs et indicateurs

Un objectif a une unité, une valeur actuelle, une valeur cible, et une date. « Réduire le délai de devis de 4 jours à 1 jour, mesuré sur les demandes entrées dans le mois, d'ici la fin du trimestre qui suit la mise en service. » Trois objectifs suffisent. Question du prestataire : à quoi saurai-je que j'ai réussi, si ce n'est à la recette formelle ? Erreur classique : « gagner en visibilité », « moderniser », « mettre l'IA au cœur du métier ». Ces phrases n'ont pas d'unité. Elles ne se recettent pas.

5. Exigences fonctionnelles

C'est le cœur du document, pas le plus long. Chaque exigence décrit un comportement observable : qui fait quoi, dans quel cas, avec quel résultat. « Un commercial crée un devis à partir d'une demande e-mail en moins de cinq minutes, sans retaper l'adresse ni les lignes déjà présentes dans le fichier clients. » Regroupez par flux, pas par écran. Question du prestataire : que dois-je livrer pour que vous signiez la recette ? Erreur classique : copier le menu d'un logiciel vu en démonstration. Les termes de forfait, régie, AMOA, réversibilité employés plus bas sont définis dans le glossaire.

6. Volumes, délais, contraintes

Les nombres que le prestataire ne peut pas inventer sans se tromper. Volumes, fenêtres d'ouverture, saisonnalité. Contraintes imposées : un logiciel déjà là, une obligation sectorielle, un hébergement en Union européenne si c'est une décision de l'entreprise plutôt qu'un goût. Question du prestataire : à quelle taille dimensionner, quelles portes sont fermées ? Erreur classique : une contrainte de solution (« architecture découplée ») présentée comme une contrainte métier.

7. Données et interfaces

D'où viennent les données, où elles vont, qui en est responsable. Lister les interfaces existantes (comptabilité, banque, transporteur) et celles à créer. Préciser le format si vous le connaissez. Nommer aussi le traitement des données personnelles et, si un DPO est désigné ou à désigner, le rattacher au registre des traitements (voir les prix publiés d'un DPO externalisé et le registre CNIL). Question du prestataire : combien de tuyaux, lesquels sont déjà là ? Erreur classique : « tout doit être intégré ». Intégré à quoi, à quelle fréquence, en cas d'erreur de quel côté. Sans cela le mot ne coûte rien à écrire et beaucoup à réaliser.

8. Recette et critères d'acceptation

Écrire qui recette, sur quel jeu de données (un extrait réel anonymisé), avec quels cas nominaux et quels cas d'erreur. Un critère d'acceptation se copie depuis l'exigence : si l'exigence dit « devis en cinq minutes sans ressaisie », le test est un chronomètre et une pièce réelle. Question du prestataire : à quel moment le solde est-il dû, sur quelle preuve ? Erreur classique : « recette sur procès-verbal contradictoire ». La phrase est vide tant que les cas de test n'existent pas.

9. Propriété, réversibilité, fonctionnement, évolutions

Quatre blocs, même en une page. Ce qui est cédé, pour quelle durée et quel territoire. Ce qui est rendu à la sortie : code, données dans un format lisible sans l'outil du prestataire, documentation, accès. Ce que coûte le système chaque année : hébergement, licences, maintenance, consommation des modèles. Ce qui est une correction (incluse) et ce qui est une évolution (devis). Question du prestataire : que reste-t-il après la mission ? Erreur classique : « le client sera propriétaire des développements ». La phrase ne dit rien sur les données, ni sur le coût de sortie.

Comment formuler une exigence testable plutôt qu'un vœu ?

Le test se fait à l'écriture, pas à la recette. Prenez la phrase. Demandez : le jour de la livraison, que fait-on, concrètement, pour dire oui ou non ? S'il faut un comité, un ressenti ou une reformulation, ce n'est pas une exigence. « L'outil doit être simple et intuitif » est un vœu. « Un commercial embauché depuis moins d'un mois produit un devis conforme sans l'aide d'un collègue, sur une demande réelle, en moins de cinq minutes » est une exigence. « Le système doit gérer les cas particuliers » est un vœu. « Un avoir partiel sur une facture déjà partiellement encaissée met à jour le reste à payer et l'écriture comptable le jour même, sans double saisie » en est une.

Trois règles. Une exigence, un comportement. Pas de « etc. », pas de « notamment ». Le cas d'erreur est écrit à côté du cas nominal : client introuvable, stock à zéro, export comptable en échec. L'exigence nomme le résultat, pas l'écran. Le benchmark des familles de cabinets rappelle que l'unité vendue change : un forfait se recette sur ces phrases ; une régie s'en sert de boussole, pas de critère de paiement.

Quelles clauses évitent les litiges après la signature ?

Les litiges portent rarement sur le tarif de la première facture. Ils portent sur ce que « livré » voulait dire, sur qui possède quoi, et sur qui paie la suite. Quatre clauses, écrites avant la signature, tiennent l'essentiel. Le cahier dit ce que vous exigez. Le contrat le rend opposable.

Propriété du code et des livrables. Seuls les droits patrimoniaux se cèdent, par écrit. Chaque droit cédé (reproduction, représentation, adaptation, traduction) fait l'objet d'une mention distincte, et le domaine d'exploitation est délimité quant à son étendue, sa destination, le lieu et la durée : c'est le texte de l'article L. 131-3 du code de la propriété intellectuelle. La fiche « Contrat de cession de droits d'auteur » de Service-Public Entreprendre (3 mai 2024) y ajoute l'identité des parties, la description des œuvres, l'exclusivité ou non, le prix. Elle rappelle que la cession globale des œuvres futures est interdite, et que pour un logiciel la rémunération peut être forfaitaire. « Le client sera propriétaire » ne remplit aucune de ces conditions.

Sources : Légifrance, code de la propriété intellectuelle, article L. 131-3 (1992) ; Service-Public Entreprendre, contrat de cession de droits d'auteur (2024).

Réversibilité. Propriété et sortie sont deux sujets. La sortie, c'est : le code source des développements spécifiques, un export des données dans un format lisible sans l'outil du prestataire, la documentation d'exploitation, la restitution des accès. Écrivez le délai (trente jours après notification, par exemple) et demandez que le coût de cette sortie soit chiffré dans l'offre, pas au moment du départ.

Recette. Le solde n'est dû que lorsque les critères d'acceptation écrits à la section 8 sont tenus. Prévoyez une recette intermédiaire sur le premier flux, pas seulement une recette finale. Un projet qui ne se recette qu'à la fin se discute qu'à la fin.

Coût de fonctionnement et évolutions. L'offre indique le coût annuel après mise en service, poste par poste, pour les douze mois qui suivent. Elle indique aussi ce qui est une correction (incluse pendant la période de garantie que vous fixez) et ce qui est une évolution (devis, délai de chiffrage). Sans cette frontière, chaque demande du terrain devient un conflit sur le forfait.

Quel poids donner à chaque section du document ?

Le poids ci-dessous sert de garde-fou à une PME qui consulte sur un besoin borné. Si les exigences fonctionnelles dépassent le tiers du document, vous écrivez des écrans. Si le contexte dépasse le dixième, vous racontez l'entreprise.

Répartition indicative pour un besoin borné de PME. Total 100 %. Le tableau vise à écarter les documents qui racontent l'entreprise ou qui spécifient déjà l'outil.

Checklist de relecture avant d'envoyer le cahier des charges

Relisez le lendemain. Ce qui n'est pas coché n'est pas « à voir en atelier » : chaque candidat tranchera l'ambiguïté dans son sens.

• Le besoin est décrit avant toute solution : aucun nom d'outil cible, aucun langage, aucune architecture imposée sans contrainte métier réelle.
• Le hors-périmètre est écrit, pas seulement le souhaitable.
• L'existant nomme les outils, les fichiers et les personnes qui les tiennent, plutôt qu'une cible idéale.
• Chaque objectif a une unité, une valeur actuelle et une valeur cible.
• Chaque exigence a un test : on sait ce qu'on fera, le jour de la recette, pour dire oui ou non.
• Les cas d'erreur sont écrits à côté des cas nominaux.
• Les volumes, le nombre d'utilisateurs et les interfaces sont chiffrés ou explicitement inconnus.
• La recette nomme qui signe, sur quel jeu de données, avec quels cas.
• La cession des droits énumère les droits, la destination, le territoire et la durée, au lieu d'une phrase « le client sera propriétaire ».
• La réversibilité couvre le code, les données, la documentation et les accès, avec un délai.
• Le coût de fonctionnement annuel est demandé dans l'offre, poste par poste.
• La frontière correction / évolution est posée.
• Le même document part à tous les candidats, avec la même date limite.

Après l'envoi. Toute précision donnée à un candidat est renvoyée aux autres. Les questions orales ne comptent pas. C'est ainsi que deux devis deviennent comparables, et que les signaux lus en rendez-vous portent sur le même texte.

Vous avez un brouillon et vous voulez le faire relire avant de consulter ? Décrivez votre besoin : réponse sous 24 h. Ce n'est pas requis pour utiliser le modèle ci-dessus.