Cahier des charges ERP — un exemple concret
Un cahier des charges ERP (en anglais : requirements document) est la définition, par l'acheteur, de ce que le futur système doit faire : il est rédigé avant les démonstrations des éditeurs et conçu sans référence à un produit particulier. Cette page montre à quoi ressemble concrètement un tel document — les 12 chapitres que reprend le modèle éprouvé pour les PME et ETI, la discipline de priorisation MoSCoW qui empêche la liste d'exigences de se transformer en théâtre de vœux pieux, et un extrait d'un véritable catalogue d'exigences, avec le type d'entrées auxquelles les éditeurs peuvent répondre clairement.
Le modèle compagnon, que vous pouvez copier et compléter, se trouve sur /en/erp-requirements-document/. Cette page-ci est l'exemple appliqué.
La structure en 12 chapitres
Un cahier des charges complet pour un projet ERP de PME ou d'ETI couvre douze chapitres. En omettre un seul ouvre côté éditeur une occasion de trop promettre et de moins livrer par la suite.
- Contexte du projet — profil de l'entreprise, effectifs, chiffre d'affaires, sites, faits clés du modèle économique
- Objectifs du projet — les trois à cinq résultats que la migration doit atteindre, avec des critères de succès mesurables
- Périmètre et hors périmètre — les modules et processus qui relèvent du projet, et la liste explicite de ceux qui n'en font pas partie
- Cartographie des processus actuels — l'ERP en place, les systèmes périphériques, les principales interfaces, les points de douleur
- Processus cibles — la cartographie des processus futurs au niveau de détail requis par le projet
- Exigences fonctionnelles — le catalogue structuré, organisé par module
- Exigences non fonctionnelles — performance, disponibilité, sécurité, localisation des données, langues, accessibilité
- Exigences techniques — préférence de modèle de déploiement, schémas d'intégration, standards d'API, prise en charge des navigateurs
- Volumes et croissance — utilisateurs, transactions, volumes de données de base, croissance attendue sur l'horizon contractuel
- Attentes de mise en œuvre — calendrier, préférence méthodologique, formation, hypercare
- Cadre commercial — enveloppe budgétaire totale, préférence de modèle de licence, durée du contrat, clauses de sortie
- Critères d'évaluation — la grille d'évaluation pondérée au regard de laquelle les offres des éditeurs seront notées
La priorisation MoSCoW
Chaque exigence fonctionnelle porte une étiquette de priorité : Must (indispensable), Should (souhaitable), Could (optionnel), Won't (exclu).
- Must — non négociable ; un éditeur qui ne peut le satisfaire est éliminé
- Should — important, mais un éditeur disposant d'un contournement crédible ou d'un engagement de roadmap peut rester en lice
- Could — appréciable ; contribue au score mais n'élimine pas à lui seul
- Won't — explicitement hors périmètre pour cette phase, mentionné uniquement pour éviter qu'on y revienne
La répartition réaliste d'un cahier des charges mature est d'environ 15–25 % de Must, 35–45 % de Should, 25–35 % de Could et 5–15 % de Won't. Les documents affichant 60 % de Must sont des listes de vœux ; ceux qui n'ont que 5 % de Must manquent de la discipline nécessaire pour faire un vrai choix. Le seuil de Must est le levier que les acheteurs utilisent pour élargir ou resserrer la liste longue pendant la sélection.
Extrait du catalogue d'exigences
Le catalogue d'exigences lui-même est un tableau structuré, généralement tenu dans Excel ou dans un outil de gestion des exigences, avec une ligne par exigence. Les champs par ligne : identifiant, module, sous-module, énoncé de l'exigence, priorité (MoSCoW), justification, critères d'acceptation, réponse de l'éditeur, preuve fournie par l'éditeur.
Un court extrait de la section comptabilité financière d'un document type :
- FI-001 (Must) : Le système doit prendre en charge nativement le plan comptable général français (PCG) ainsi que la liasse fiscale, avec la possibilité de mapper des comptes propres à l'entreprise via une table de correspondance paramétrable. Acceptation : l'éditeur démontre le PCG actif dans un environnement bac à sable en moins de 30 minutes.
- FI-012 (Must) : Le système doit produire une piste d'audit conforme aux obligations françaises de comptabilité informatisée (FEC / contrôle fiscal), couvrant chaque écriture, avec horodatage, utilisateur, référence du document source et stockage inaltérable des enregistrements d'audit. Acceptation : la piste d'audit extraite pour une période-échantillon passe le contrôle de l'expert-comptable du client.
- FI-024 (Should) : Le système doit permettre l'export automatisé du Fichier des Écritures Comptables (FEC) au format en vigueur pour la transmission mensuelle à l'expert-comptable. Acceptation : export FEC en conditions réelles démontré lors de la démonstration de l'éditeur.
- FI-031 (Should) : Le système doit produire des factures sortantes conformes à Factur-X et transmissibles via Chorus Pro pour les scénarios B2G et grands comptes. Acceptation : facture-échantillon validée par un validateur de schéma Factur-X.
- FI-047 (Could) : Le système doit prendre en charge des grands livres parallèles multi-référentiels pour un reporting au PCG et en IFRS au sein de la même entité juridique. Acceptation : documenté dans l'architecture de référence de l'éditeur.
Chaque entrée suit la même structure : énoncé testable, priorité claire, critère d'acceptation explicite. Les exigences rédigées du type « le système doit être convivial » sont impossibles à noter et ne font qu'occuper de la place.
Erreurs typiques dans un cahier des charges
Trois schémas d'échec reviennent dans presque tous les cahiers des charges faibles. La transcription des fonctionnalités d'un éditeur : des exigences qui ressemblent à la fiche produit de l'éditeur en place plutôt qu'aux besoins métier du client. Le remède consiste à rédiger les exigences en langage métier et à laisser les éditeurs y faire correspondre leurs fonctionnalités, et non l'inverse.
La dérive des ambitions : les équipes ajoutent des exigences dont l'entreprise n'a pas besoin aujourd'hui mais qui « pourraient un jour servir » — IA, blockchain, IoT, analytique prédictive. Chacune accentue la pression de réduction de la liste longue et apporte rarement une vraie valeur métier. La discipline consiste à les rétrograder en Could ou en Won't.
La sous-spécification des processus : le chapitre sur les processus cibles reste à un niveau de détail que les éditeurs ne peuvent pas chiffrer. Le résultat est une offre de mise en œuvre à prix forfaitaire qui se transforme en régie dans les trois mois suivant le démarrage du projet. Le remède : des diagrammes de processus accompagnés d'un récit de processus, validés par les key users de chaque département concerné avant l'émission du document.
La place du cahier des charges dans le processus d'appel d'offres
Le cahier des charges est l'élément d'entrée de l'appel d'offres, pas un substitut. Après l'avoir émis, l'acheteur l'envoie (accompagné d'une lettre d'appel d'offres, des critères d'évaluation et des consignes de soumission) à la liste longue, organise une séance de questions-réponses facultative, reçoit les offres des éditeurs, les note et resserre vers une liste courte pour les démonstrations. Les mécanismes détaillés figurent dans notre guide sur le processus d'appel d'offres ERP et dans le modèle complet sur /en/erp-requirements-document/.
Le document reste un artefact vivant tout au long de la mise en œuvre : il sert de référence pour l'analyse d'écart (fit-gap), de base de référence pour la gouvernance des demandes de changement et de fondement à la recette en phase d'hypercare. Les acheteurs qui considèrent le cahier des charges comme un simple actif de sélection d'éditeur, puis le classent après signature, perdent systématiquement les batailles de maîtrise des changements.