Cahier des charges ERP — Le document d'expression des besoins
Le cahier des charges — ou document d'expression des besoins — est l'artefact central de toute sélection d'ERP menée avec rigueur. Il formalise ce dont l'entreprise a besoin de son nouvel ERP, avec un niveau de détail et de structure suffisant pour piloter l'évaluation des éditeurs, la notation de l'appel d'offres, la conception des démonstrations et, à terme, le périmètre du déploiement. Faire l'impasse sur le cahier des charges, ou le bâcler, reste la cause la plus fréquente des renégociations de périmètre et des dépassements de budget que connaissent ensuite les projets ERP des PME et ETI.
Structure d'un cahier des charges
Un cahier des charges opérationnel comporte six parties. (1) Contexte de l'entreprise — modèle économique, structure organisationnelle, indicateurs clés, sites, langues, environnement réglementaire. 5 à 10 pages. (2) Vue d'ensemble des processus — processus opérationnels de bout en bout (order-to-cash, procure-to-pay, plan-to-produce, record-to-report) à un niveau compréhensible par tout éditeur. 10 à 25 pages. (3) Exigences fonctionnelles — la partie la plus volumineuse, découpée en sous-sections par module ERP (finance, ventes, achats, stocks, production, etc.). 30 à 80 pages. (4) Exigences non fonctionnelles — objectifs de performance, disponibilité, sécurité, conformité réglementaire (obligations comptables et fiscales françaises, RGPD, NIS-2, règles sectorielles). 5 à 10 pages. (5) Cartographie des intégrations — systèmes existants auxquels le nouvel ERP doit se connecter, flux de données, API. 5 à 15 pages. (6) Contraintes et préférences — cloud ou on-premise, préférences technologiques, contraintes de calendrier, enveloppe budgétaire, considérations géographiques. 2 à 5 pages. Total : 60 à 150 pages pour une PME ou ETI type.
Niveau de détail
Le bon niveau de détail équilibre la clarté et le risque de paralysie par l'analyse. Pour chaque domaine fonctionnel, documentez : le déroulé du processus (description d'une demi-page ou diagramme BPMN), les exigences clés (5 à 30 points listant les éléments indispensables, souhaitables et facultatifs), les volumes et fréquences de données (milliers de transactions par mois, périodes de pointe), les points d'intégration (quels autres systèmes interviennent à cet endroit), les considérations réglementaires (pertinence des obligations comptables, données personnelles au sens du RGPD, règles sectorielles). À éviter : rédiger les exigences comme une reproduction écran par écran du comportement du système actuel — cela arrime le nouveau système à l'ancien et bride la créativité des éditeurs. À éviter également : les formulations vagues du type « doit être moderne » ou « doit être convivial », qui ne peuvent pas être évaluées.
Comment le cahier des charges est utilisé
Le cahier des charges pilote quatre phases. (1) Pré-qualification des éditeurs : filtrer une long-list de 8 à 15 éditeurs au regard d'une adéquation de haut niveau, pour la ramener à 4 à 6 candidats pour l'appel d'offres. (2) Appel d'offres : convertir les exigences INDISPENSABLES et SOUHAITABLES en un questionnaire structuré auquel les éditeurs répondent. (3) Conception des démonstrations : construire des scénarios de démonstration scriptés qui mettent à l'épreuve les exigences prioritaires dans les systèmes des éditeurs. (4) Contractualisation du déploiement : le cahier des charges devient la base contractuelle du périmètre. Les écarts significatifs survenant pendant le déploiement sont suivis comme des demandes de changement par rapport au cahier des charges initial. Le même document accompagne le projet, de l'analyse préliminaire jusqu'à la mise en production.
Recommandations pratiques
(1) Laissez les opérationnels métier rédiger les sections opérationnelles. La finance pilote la partie financière, les opérations commerciales pilotent la partie ventes, etc. Le cahier des charges n'est pas un artefact informatique — la DSI joue le rôle d'éditeur et d'architecte, pas d'auteur. (2) Appliquez tout au long du document la priorisation INDISPENSABLE / SOUHAITABLE / FACULTATIF. La règle des 80/20 s'applique : 20 % des exigences déterminent 80 % de la différenciation entre éditeurs. (3) Gardez le document sous gestion de version et faites-le relire par le comité de pilotage à chaque itération majeure. (4) Traduisez-le dans les langues de travail des éditeurs si nécessaire — pour le marché français, le français complété de l'anglais couvre généralement l'ensemble des éditeurs pertinents, y compris les acteurs internationaux comme SAP, Oracle, Microsoft ou Odoo aux côtés des éditeurs français tels que Cegid, Sage ou Divalto. (5) Prévoyez 30 à 90 jours d'effort concentré. En deçà de 30 jours, les exigences restent superficielles ; au-delà de 90 jours, elles deviennent sur-analysées et plus aucun éditeur ne parvient à les cartographier proprement.