Modèle de cahier des charges ERP — Structuré pour les acheteurs en France
Un cahier des charges ERP est le fondement de toute sélection d'ERP structurée. Bien réalisé, il resserre la longlist, affine les réponses des éditeurs et produit une piste d'audit défendable pour le choix final. Mal réalisé, il produit des check-lists de cent pages auxquelles les éditeurs répondent par un code couleur optimiste et que plus personne ne lit après la signature. La différence ne tient pas à la longueur mais à la rigueur : un document concis, priorisé selon MoSCoW et ancré dans les processus métier surpasse de loin une check-list de fonctionnalités tentaculaire.
Ce modèle couvre une structure en douze chapitres utilisée pour les sélections d'ERP dans les ETI, y compris le catalogue d'exigences sous Excel que les éditeurs renseignent durant la phase d'appel d'offres (RFP). Il s'appuie sur les schémas issus de sélections réussies dans les ETI (50 à 3 000 salariés), mais la structure se généralise aux sélections de PME (en élaguant certaines sections) et aux sélections de grands comptes (avec des chapitres d'intégration et d'architecture plus approfondis). Le modèle est éditorial et indépendant de toute plateforme — les préférences d'éditeur ne devraient pas figurer dans un cahier des charges, et un document bien rédigé devrait pouvoir être traité par au moins cinq éditeurs candidats sans favoritisme.
La structure en douze chapitres
Un cahier des charges ERP bien structuré couvre douze chapitres. Les chapitres sont ordonnés de façon à accompagner un éditeur qui les lit dans l'ordre :
- Profil de l'entreprise (3 à 5 pages). Effectif, chiffre d'affaires, sites, actionnariat, bref historique, secteur d'activité, positionnement sur le sous-segment, ambition de croissance sur les cinq prochaines années. Cadre la compréhension de l'adéquation par les éditeurs.
- Processus métier (10 à 25 pages). Processus métier de bout en bout par domaine fonctionnel : order-to-cash, procure-to-pay, plan-to-produce, hire-to-retire, record-to-report. Cartographies de processus là où elles sont utiles. Volumes de processus (transactions par jour, pics d'activité).
- Exigences fonctionnelles (catalogue Excel, 200 à 600 lignes). Le catalogue d'exigences détaillé, ventilé par module, avec priorité MoSCoW et brève description. Excel est le format standard ; Word et Confluence fonctionnent mais sont plus difficiles à scorer.
- Exigences non fonctionnelles (3 à 6 pages). Performance (temps de réponse, fenêtres de traitement par lots), disponibilité (attentes en matière de SLA), scalabilité (croissance du nombre d'utilisateurs, des transactions), accessibilité, multilinguisme.
- Architecture et intégration (5 à 10 pages). Paysage applicatif actuel, intégrations à conserver, préférences de modèle de déploiement (cloud, hybride, on-premise), exigences de localisation des données.
- Conformité et réglementation (3 à 5 pages). Spécificités de conformité françaises : Factur-X et Chorus Pro pour la facturation électronique, normes comptables (PCG), TVA et obligations de la DGFiP. Obligations sectorielles spécifiques. Considérations liées au RGPD et à la CNIL. Exigences du comité social et économique (CSE).
- Migration des données (2 à 4 pages). Volumes de données de référence, exigences de conservation de l'historique transactionnel, systèmes hérités à migrer, problèmes connus de qualité des données.
- Approche de mise en œuvre (2 à 4 pages). Préférence pour un déploiement big-bang ou progressif, échéance cible de mise en production, disponibilité des ressources internes, attentes en matière de formation.
- Support et exploitation (2 à 3 pages). Attentes en matière de TMA (tierce maintenance applicative), SLA de temps de réponse, couverture linguistique du support, préférences concernant un interlocuteur dédié.
- Cadre commercial (2 à 3 pages). Préférences de modèle tarifaire (abonnement vs licence perpétuelle), préférences de modèle de licence (utilisateur nommé vs concurrent), attentes d'indexation, clauses de sortie.
- Processus de sélection et calendrier (1 à 2 pages). Étapes du processus de sélection, pondération des critères de décision, date de décision cible, coordonnées.
- Critères d'évaluation et notation (1 à 2 pages). La méthodologie de notation qui sera appliquée aux réponses des éditeurs. La transparence sur ce point améliore sensiblement la qualité des réponses.
La longueur totale du document se situe entre 40 et 80 pages pour les sélections d'ETI typiques, auxquelles s'ajoute le catalogue d'exigences Excel. Les documents de plus de 120 pages contiennent généralement des redites et du bruit ; ceux de moins de 30 pages manquent en général de la précision nécessaire à des réponses honnêtes des éditeurs.
Priorisation MoSCoW
Chaque exigence devrait porter une priorité MoSCoW. Les quatre niveaux :
- Must have (indispensable). Le système ne peut être retenu sans cette exigence. Environ 20 à 30 % du total des exigences. Les éditeurs qui ne peuvent satisfaire une exigence Must-have, ni dans le standard ni via une feuille de route engagée, sont éliminés.
- Should have (souhaitable). Important mais non rédhibitoire. Des contournements sont acceptables, mais les écarts Should-have réduisent sensiblement le score de l'éditeur. Environ 30 à 40 % du total des exigences.
- Could have (optionnel). Agréable à avoir, sans impact si absent. Environ 25 à 35 % du total des exigences.
- Won't have (pas cette fois). Explicitement hors périmètre. Documenter ces points empêche les éditeurs de gonfler leur réponse avec des capacités non pertinentes.
La rigueur est essentielle. Les équipes de sélection qui classent 80 % des exigences en Must-have produisent des documents qu'aucun éditeur ne peut entièrement satisfaire, et finissent par procéder à des disqualifications arbitraires. Celles qui n'en classent que 10 % en Must-have produisent des documents incapables de départager les candidats. La distribution cible — environ 25 / 35 / 30 / 10 entre Must / Should / Could / Won't — ne s'atteint qu'en passant en revue chaque exigence et en se demandant : « Renoncerais-je vraiment à un éditeur par ailleurs parfait qui ne dispose pas de cette fonctionnalité ? »
Exemples d'entrées du catalogue d'exigences
Le catalogue d'exigences Excel contient l'essentiel du détail fonctionnel. Exemples d'entrées tirées du cahier des charges d'un constructeur de machines de taille ETI :
| ID | Module | Exigence | Priorité |
|---|---|---|---|
| FIN-001 | Finance | Interface native de facturation électronique pour l'export du plan comptable et des écritures, conforme à Chorus Pro | Must |
| FIN-002 | Finance | Piste d'audit conforme aux obligations fiscales françaises, avec écritures comptables inaltérables et historique des modifications horodaté | Must |
| FIN-008 | Finance | Gestion des factures clients et fournisseurs au format Factur-X et via Chorus Pro | Must |
| SAL-014 | Ventes | Configurateur de variantes pour la gamme de machines, avec jusqu'à 80 attributs configurables par article | Must |
| SAL-022 | Ventes | Workflow quote-to-cash avec validation à plusieurs niveaux selon des seuils de marge et de remise | Should |
| PROD-003 | Production | Comptabilité analytique par affaire avec suivi mensuel du coût restant à engager | Must |
| PROD-019 | Production | Intégration MES via OPC-UA pour la collecte de données en atelier | Should |
| INV-007 | Stocks | Gestion de stock multi-entrepôt avec suivi des numéros de série pour les produits finis | Must |
| INV-012 | Stocks | Prise en charge des inventaires tournants avec lecture de codes-barres mobile | Should |
| SVC-001 | Service après-vente | Gestion du parc installé avec historique des équipements et suivi des garanties | Must |
Chaque entrée doit être suffisamment précise pour appeler une réponse oui/non/contournement/pas de feuille de route. Les entrées vagues (« Bonne interface utilisateur », « Facile à utiliser ») produisent des réponses vagues ; les entrées précises produisent des données de comparaison utiles. Un catalogue d'exigences typique d'ETI compte de 200 à 600 lignes réparties sur l'ensemble des modules.
Ce qui n'a pas sa place dans un cahier des charges
Six catégories apparaissent régulièrement dans les cahiers des charges mais ne devraient pas y figurer :
Les noms d'éditeurs. Un cahier des charges doit pouvoir être traité par tout éditeur candidat. Nommer des éditeurs précis dans les exigences fonctionnelles (« comme S/4HANA Cloud de SAP ») signale un biais et provoque des réponses défensives de la part des éditeurs non favoris.
Les préférences de méthodologie de mise en œuvre. Choisir le logiciel et choisir la méthodologie sont deux décisions distinctes. Les mêler restreint la capacité des éditeurs à proposer ce qui fonctionne le mieux sur leur plateforme.
Les redites excessives d'un module à l'autre. « Le système doit disposer d'une interface utilisateur » répété dans chaque section de module n'est que du bruit. Les exigences transverses ont leur place dans le chapitre non fonctionnel.
Les détails techniques de mise en œuvre pour les cas standard. « L'écran de saisie de commande doit comporter un champ pour le nom du client » est implicite dans « La saisie de commande est prise en charge ». Le détail technique relève du dossier de spécifications fonctionnelles, après la sélection.
Les exigences aspirationnelles sans justification métier claire. Prévision de la demande pilotée par l'IA, vérification des fournisseurs par blockchain, préparation de commandes à commande vocale — si ces éléments ne répondent pas à un besoin métier actuel, ils relèvent de la catégorie Could-have ou Won't-have, voire pas du tout.
Les critères d'évaluation des éditeurs présentés comme des exigences. « L'éditeur doit compter au moins 50 clients de référence en France » est un critère d'éditeur, pas une exigence. Cela relève du chapitre des critères de sélection, pas du catalogue d'exigences.
Diffuser le document aux éditeurs
Le cahier des charges est l'intrant principal de la phase d'appel d'offres. La diffusion suit généralement ce rythme :
- Présélection pré-RFI (semaine 0). Un bref résumé d'une page de la sélection (entreprise, segment, effectif, date cible de mise en production) est partagé avec la longlist de 8 à 15 éditeurs. Les éditeurs confirment leur intérêt et leur adéquation de base sous une semaine.
- Diffusion du RFI (semaines 1 à 3). Une version condensée du cahier des charges (15 à 25 pages) accompagnée du catalogue d'exigences Excel. Les éditeurs répondent par écrit sous deux à trois semaines.
- Constitution de la shortlist (semaine 4). Sur la base des réponses au RFI, 3 à 5 éditeurs sont retenus pour l'appel d'offres complet.
- Diffusion du RFP complet (semaines 5 à 9). Cahier des charges complet, catalogue et cadre commercial. Les éditeurs répondent sous quatre à six semaines, avec une fenêtre de questions-réponses de deux semaines.
- Phase de démonstration et de POC (semaines 10 à 16). Le cahier des charges sert d'ancrage à l'agenda des démonstrations — les éditeurs font la démonstration sur les propres scénarios de l'acheteur, tirés du document.
Traiter le cahier des charges comme un document vivant — mis à jour à mesure que le processus de sélection affine la compréhension de l'acheteur — produit de meilleurs résultats que de le considérer comme un document figé d'emblée. La version finale du document, après les démonstrations et le POC, devient la base de l'annexe « périmètre des travaux » du contrat de mise en œuvre.