Implementation ERP

Comment rédiger un cahier des charges ERP

Comment structurer un cahier des charges ERP efficace. Les 10 sections indispensables, les erreurs à éviter et un modèle prêt à l'emploi.

Comment rédiger un cahier des charges ERP

Le cahier des charges ERP est le document fondateur de tout projet d’implémentation. C’est lui qui traduit vos besoins en exigences compréhensibles par les éditeurs et les intégrateurs. Un cahier des charges bien rédigé réduit les malentendus, accélère les réponses des prestataires et pose les bases d’un projet maîtrisé. Un cahier des charges bâclé, au contraire, ouvre la porte aux dérives de périmètre, aux surcoûts et aux frustrations.

Cet article détaille les 10 sections indispensables d’un cahier des charges ERP, les erreurs fréquentes à éviter et un modèle structuré que vous pouvez adapter à votre contexte. Il s’inscrit dans notre guide complet implémentation ERP qui couvre l’ensemble du cycle projet.

Pourquoi le cahier des charges est indispensable

Le cahier des charges ERP remplit trois fonctions essentielles.

Aligner les parties prenantes internes. Avant de consulter le marché, il oblige les directions métier, la DSI et la direction générale à s’accorder sur les objectifs, le périmètre et les contraintes. Sans ce travail préalable, chaque interlocuteur projette sa propre vision du projet, ce qui génère des incohérences dès les premiers ateliers avec l’intégrateur.

Structurer l’appel d’offres. Le cahier des charges sert de référentiel commun pour comparer les réponses des prestataires. Sans document normalisé, vous comparez des propositions qui ne répondent pas aux mêmes questions, rendant le choix impossible sur des critères objectifs.

Protéger les deux parties. En formalisant les attentes, le cahier des charges devient une pièce contractuelle. Il protège l’entreprise contre les livrables incomplets et le prestataire contre les demandes non prévues.

Les 10 sections indispensables du cahier des charges ERP

1. Présentation de l’entreprise

Cette section donne aux prestataires le contexte nécessaire pour calibrer leur réponse. Elle doit inclure :

  • La raison sociale, le secteur d’activité et le positionnement marché.
  • Le chiffre d’affaires, l’effectif et la répartition géographique (sites, filiales, pays).
  • L’organigramme simplifié avec les directions impliquées dans le projet.
  • Les spécificités métier qui influencent le choix ERP (production à la commande, négoce, service, etc.).

Ne sous-estimez pas cette partie. Un intégrateur qui comprend votre métier dès la lecture du cahier des charges proposera une solution plus pertinente qu’un prestataire qui découvre votre activité lors du premier rendez-vous.

2. Contexte et enjeux

Expliquez pourquoi vous lancez ce projet maintenant. Les intégrateurs ont besoin de comprendre ce qui motive la démarche pour prioriser les fonctionnalités et dimensionner l’accompagnement.

Les déclencheurs classiques sont :

  • Un ERP existant en fin de vie ou dont le support arrive à échéance.
  • Une croissance qui rend les processus manuels ou les outils actuels inadaptés.
  • Une fusion, une acquisition ou une réorganisation interne.
  • Des obligations réglementaires (facturation électronique 2026, normes sectorielles).

Décrivez également le système d’information actuel : les logiciels en place, les flux entre eux, les points de douleur identifiés. Un schéma d’architecture simplifié est souvent plus parlant qu’un long texte.

3. Périmètre fonctionnel

C’est le coeur du cahier des charges. Listez les modules ou domaines fonctionnels attendus, par exemple :

  • Finance et comptabilité : comptabilité générale, analytique, gestion des immobilisations, trésorerie.
  • Achats et approvisionnements : gestion des fournisseurs, commandes, réceptions, contrôle factures.
  • Ventes et CRM : devis, commandes clients, facturation, suivi commercial.
  • Production : planification, ordres de fabrication, gestion des nomenclatures.
  • Logistique et stocks : gestion des entrepôts, inventaires, expéditions.
  • Ressources humaines : paie, gestion des temps, recrutement, formation.
  • Gestion de projet : planification, suivi budgétaire, affectation des ressources.

Pour chaque domaine, distinguez les fonctionnalités indispensables (must-have), souhaitées (nice-to-have) et hors périmètre (explicitement exclues). Cette classification aide les prestataires à dimensionner leur offre et évite les discussions tardives sur ce qui est inclus ou non.

4. Processus métier cibles

Le périmètre fonctionnel décrit le “quoi”. Les processus cibles décrivent le “comment”. Cette section est celle qui différencie un bon cahier des charges d’un document générique.

Pour chaque processus clé, décrivez :

  • Le flux de bout en bout (de l’événement déclencheur au résultat attendu).
  • Les rôles impliqués et les règles de validation.
  • Les exceptions et cas particuliers fréquents.
  • Les indicateurs de performance (KPI) associés.

Par exemple, pour le processus “commande client” : de la réception de la commande jusqu’à la comptabilisation du paiement, en passant par le contrôle de disponibilité, la préparation, l’expédition et la facturation. Précisez les règles métier spécifiques comme les remises par palier, les conditions de livraison, les retours.

Ne cherchez pas à décrire tous les processus. Concentrez-vous sur les 10 à 15 processus qui portent 80% de la valeur et des volumes. Les processus secondaires seront détaillés pendant la phase d’analyse.

5. Exigences techniques

Cette section s’adresse principalement à la DSI et aux architectes. Elle couvre :

  • Mode de déploiement : cloud (SaaS), on-premise ou hybride. Justifiez le choix si vous avez une préférence.
  • Intégrations : les systèmes tiers à connecter (e-commerce, WMS, BI, banques, EDI). Précisez les protocoles attendus (API REST, fichiers plats, webservices).
  • Infrastructure : contraintes d’hébergement, exigences de disponibilité (SLA), plan de reprise d’activité (PRA).
  • Environnements : nombre d’environnements nécessaires (développement, recette, pré-production, production).
  • Mobilité : accès mobile, travail hors connexion, postes déportés.

6. Volumétrie et performance

Les volumes conditionnent l’architecture, le dimensionnement et donc le coût. Soyez précis :

  • Nombre d’utilisateurs simultanés (par site et au total).
  • Volumes de transactions par jour, mois et pic (commandes, factures, écritures comptables).
  • Volume de données à migrer depuis les systèmes existants.
  • Temps de réponse attendus pour les transactions critiques (validation de commande en moins de 2 secondes, clôture mensuelle en moins de 4 heures, etc.).
  • Projections de croissance à 3 et 5 ans.

Un prestataire qui reçoit ces chiffres peut dimensionner une solution réaliste. Sans eux, il proposera soit une solution sous-dimensionnée qui souffrira en production, soit une solution surdimensionnée dont le coût sera injustifié.

7. Contraintes réglementaires

En 2026, deux sujets sont incontournables pour les entreprises françaises :

Le RGPD. L’ERP concentre des données personnelles (salariés, clients, fournisseurs). Le cahier des charges doit préciser les exigences en matière de :

  • Localisation des données (hébergement en UE obligatoire pour certains secteurs).
  • Durée de conservation et purge automatique.
  • Droit d’accès, de rectification et de suppression.
  • Journalisation des accès aux données sensibles.

La facturation électronique. La réforme française impose progressivement l’émission et la réception de factures au format structuré via des plateformes de dématérialisation partenaires (PDP). L’ERP doit être capable de produire des factures aux formats Factur-X, UBL ou CII et de les transmettre à la plateforme choisie.

Selon votre secteur, d’autres contraintes peuvent s’appliquer : normes FDA pour l’agroalimentaire ou la pharmacie, traçabilité pour l’aéronautique (EN 9100), piste d’audit fiable pour la comptabilité, etc.

8. Planning souhaité

Indiquez les dates clés et les contraintes de calendrier :

  • Date souhaitée de mise en production (et la raison si elle est impérative, par exemple une clôture fiscale).
  • Phases intermédiaires attendues (pilote sur un site, déploiement progressif par module ou par entité).
  • Périodes à éviter (clôtures annuelles, pics d’activité saisonniers).
  • Disponibilité des équipes internes pour le projet (temps partiel ou dédié).

Soyez réaliste. Un projet ERP pour une PME de 50 utilisateurs prend rarement moins de 6 mois entre le lancement et la mise en production. Pour une ETI multi-sites, comptez 12 à 18 mois. Afficher un planning irréaliste décourage les bons prestataires et attire ceux qui diront oui à tout pour signer.

9. Budget indicatif

La question du budget divise. Certaines entreprises refusent de communiquer une enveloppe pour “ne pas influencer les prix”. En pratique, cette stratégie est contre-productive. Un prestataire qui ignore votre budget peut proposer une Rolls-Royce là où vous attendez une Berline, ou inversement.

Communiquez au minimum :

  • Une fourchette budgétaire globale (licences + intégration + formation + maintenance année 1).
  • La répartition souhaitée entre CAPEX et OPEX si elle est contrainte.
  • Les postes de coûts que vous souhaitez voir détaillés dans la réponse.

Si vous n’avez aucune idée du budget, précisez-le. Les prestataires proposeront alors plusieurs scénarios. Pour approfondir la question des coûts, consultez notre article sur le coût total de possession d’un ERP.

10. Critères de sélection

Indiquez comment vous évaluerez les réponses. La transparence sur les critères de sélection pousse les prestataires à concentrer leurs efforts sur ce qui compte pour vous.

Les critères classiques, pondérés en pourcentage, incluent :

CritèrePondération indicative
Couverture fonctionnelle30%
Références sectorielles et expérience20%
Approche projet et méthodologie15%
Coût total sur 5 ans (TCO)15%
Qualité de la démonstration10%
Capacité d’évolution et roadmap10%

Précisez aussi le processus de sélection : nombre de tours, démonstrations sur scénarios imposés, visites de référence, proof of concept. Cela permet aux prestataires de planifier leurs ressources et de s’engager sérieusement.

Pour structurer votre grille de scoring et comparer les intégrateurs de manière rigoureuse, consultez notre article sur comment choisir un intégrateur ERP.

Les erreurs fréquentes à éviter

Le cahier des charges trop vague

“Nous voulons un ERP moderne et performant qui couvre tous nos besoins.” Ce type de formulation n’apporte aucune information exploitable. Chaque exigence doit être suffisamment précise pour qu’un prestataire puisse répondre par oui, non ou partiellement. Remplacez “gestion des achats performante” par “capacité à gérer 500 commandes fournisseurs par mois avec workflow de validation à 3 niveaux et rapprochement automatique commande-réception-facture”.

Le cahier des charges trop technique

A l’opposé, certains cahiers des charges sont rédigés exclusivement par la DSI et ressemblent à une spécification technique. Ils décrivent des architectures cibles, des choix technologiques et des protocoles sans jamais mentionner les processus métier. Résultat : les prestataires proposent une solution techniquement conforme mais fonctionnellement inadaptée. Le cahier des charges doit être un document métier avant d’être un document technique.

Le cahier des charges pas assez orienté processus

Lister des fonctionnalités sans décrire les processus dans lesquels elles s’inscrivent est une erreur classique. “Gestion des stocks” ne dit rien. “Gestion des stocks avec inventaire tournant hebdomadaire, suivi des lots avec date de péremption et réapprovisionnement automatique sur point de commande” donne une vision claire du besoin. Les processus sont le langage commun entre votre entreprise et l’intégrateur.

L’absence de priorisation

Un cahier des charges qui présente 200 exigences toutes classées “indispensables” perd sa crédibilité. Si tout est prioritaire, rien ne l’est. Utilisez la méthode MoSCoW (Must have, Should have, Could have, Won’t have) pour hiérarchiser vos besoins. Cette priorisation guidera les prestataires dans le dimensionnement de leur offre et facilitera les arbitrages pendant le projet.

Oublier les utilisateurs finaux

Rédiger le cahier des charges en chambre, entre la direction et la DSI, sans consulter les opérationnels est une erreur coûteuse. Ce sont les utilisateurs terrain qui connaissent les cas particuliers, les contournements actuels et les vrais irritants. Impliquez-les dès la phase de rédaction via des ateliers de recueil des besoins.

Modèle de structure du cahier des charges ERP

Voici un modèle de plan que vous pouvez reprendre et adapter :

CAHIER DES CHARGES ERP - [Nom de l'entreprise]
Version : [X.X] | Date : [JJ/MM/AAAA]

1. PRÉSENTATION DE L'ENTREPRISE
   1.1 Identité et chiffres clés
   1.2 Organisation et implantations
   1.3 Spécificités métier

2. CONTEXTE ET ENJEUX
   2.1 Système d'information actuel
   2.2 Déclencheurs du projet
   2.3 Objectifs stratégiques

3. PÉRIMÈTRE FONCTIONNEL
   3.1 Modules attendus (tableau Must/Should/Could/Won't)
   3.2 Fonctionnalités détaillées par domaine

4. PROCESSUS MÉTIER CIBLES
   4.1 Cartographie des processus clés
   4.2 Fiches processus détaillées
   4.3 Règles de gestion

5. EXIGENCES TECHNIQUES
   5.1 Architecture cible
   5.2 Intégrations et interfaces
   5.3 Sécurité et accès

6. VOLUMÉTRIE ET PERFORMANCE
   6.1 Utilisateurs et transactions
   6.2 Données à migrer
   6.3 Exigences de performance

7. CONTRAINTES RÉGLEMENTAIRES
   7.1 RGPD et données personnelles
   7.2 Facturation électronique
   7.3 Normes sectorielles

8. PLANNING SOUHAITÉ
   8.1 Jalons clés
   8.2 Contraintes calendaires
   8.3 Disponibilité des équipes

9. BUDGET INDICATIF
   9.1 Enveloppe globale
   9.2 Répartition attendue
   9.3 Modalités de facturation

10. CRITÈRES DE SÉLECTION
    10.1 Grille d'évaluation pondérée
    10.2 Processus de sélection
    10.3 Calendrier de consultation

ANNEXES
- Organigramme
- Schéma SI actuel
- Exemples de documents métier (bon de commande, facture, etc.)
- Glossaire métier

Conseils pour une rédaction efficace

Impliquez les bonnes personnes. La rédaction doit être un travail collectif impliquant la direction, les responsables métier et la DSI. Un consultant externe spécialisé en assistance à maîtrise d’ouvrage (AMOA) peut faciliter les ateliers et structurer le document.

Restez orienté résultat. Décrivez ce que vous voulez obtenir, pas comment le système doit fonctionner en interne. “Le système doit permettre de clôturer les comptes mensuels en J+5” est plus utile que “le système doit exécuter un batch de consolidation à 22h chaque dernier jour du mois”.

Prévoyez un glossaire. Chaque entreprise a son vocabulaire. Ce que vous appelez “affaire” est peut-être un “projet” ou un “contrat” pour l’intégrateur. Un glossaire évite les quiproquos qui se révèlent tard dans le projet.

Limitez le volume. Un cahier des charges ERP efficace fait entre 30 et 80 pages selon la taille de l’entreprise. Au-delà de 100 pages, il est probable que personne ne le lise intégralement. Mieux vaut un document concis et structuré qu’un pavé exhaustif que les prestataires survoleront.

Conclusion

Le cahier des charges ERP n’est pas une formalité administrative. C’est l’outil qui transforme une intention (“nous voulons un ERP”) en un projet structuré avec des objectifs mesurables, un périmètre défini et des critères de succès partagés. Investir du temps dans sa rédaction, c’est en gagner pendant tout le reste du projet.

Pour replacer cette étape dans le cadre global d’un projet d’implémentation, consultez notre guide complet implémentation ERP qui détaille chaque phase, de la réflexion initiale à la mise en production.