Cahier des charges ERP : écrire des exigences testables

Un cahier des charges ERP doit permettre de vérifier une réponse, pas seulement de reconnaître des mots. Décrivez les opérations, les données et les exceptions, puis associez chaque exigence importante à un test. Le document peut rester court si le périmètre est clair. Il doit surtout rendre visibles les contraintes et les responsabilités qui influencent le devis.

Décrire le contexte sans dicter la solution

Présentez l’activité, les équipes, les systèmes conservés et les difficultés actuelles. Donnez les volumes utiles à la conception, en séparant ce qui est mesuré de ce qui est estimé. Évitez d’imposer un mécanisme technique simplement parce que l’ancien logiciel le faisait ainsi. Décrivez plutôt le résultat attendu et les contraintes non négociables. Le fournisseur peut proposer une autre manière de travailler, mais il doit expliquer les changements nécessaires. Un bon contexte permet de comprendre pourquoi une exigence existe et de discuter sa pertinence sans la supprimer implicitement.

Écrire une exigence observable

Au lieu de « gestion complète des achats », décrivez un parcours : créer une demande, appliquer une règle de validation, générer une commande et rapprocher la réception. Précisez les rôles et les exceptions. Ajoutez le résultat attendu, comme la traçabilité de l’accord ou le blocage d’une étape. Une exigence trop générale encourage une réponse affirmative difficile à contester. Une exigence testable permet une démonstration et une recette. Attribuez un identifiant stable pour retrouver la réponse, le test et l’éventuelle réserve tout au long du projet.

Classer les priorités avec les métiers

Séparez indispensable au lancement, souhaitable et différable. Une priorité doit correspondre à une conséquence opérationnelle, pas au niveau hiérarchique de la personne qui demande. Décrivez ce qui se passe si l’exigence n’est pas couverte : arrêt d’activité, procédure manuelle acceptable ou simple inconfort. Cette analyse aide à éviter un cahier où tout serait obligatoire. Faites arbitrer les contradictions, par exemple une validation très stricte et un besoin d’autonomie immédiate. Consignez la décision afin que le prestataire ne choisisse pas seul l’interprétation la plus commode.

Prévoir une grille de réponse homogène

Demandez au fournisseur d’indiquer pour chaque exigence le mode de couverture, les limites, le composant nécessaire et la preuve proposée. Les catégories peuvent distinguer standard, paramétrage, extension, développement et non couvert. Une réponse « oui » sans précision n’est pas suffisante. Exigez que les coûts d’un composant complémentaire apparaissent dans la proposition. Reliez également les exigences aux livrables de mise en œuvre. Une fonction disponible mais non paramétrée dans le devis ne doit pas être considérée comme livrée au démarrage.

Gérer les versions et les changements

Le cahier évoluera lorsque des inconnues seront levées. Conservez un historique des modifications, une date réelle de validation et la personne qui arbitre. Si le périmètre change après réception des offres, demandez une réponse actualisée à tous les candidats encore étudiés. Sinon, les prix ne reposent plus sur la même base. Pendant l’intégration, reliez les nouvelles demandes à l’exigence initiale ou classez-les comme changement explicite. Cette discipline ne supprime pas les ajustements ; elle permet de comprendre leur effet sur le coût, le calendrier et la recette.

Exemple de travail

Exemple d’exigence illustratif : « Lorsqu’un acheteur crée une commande dépassant la limite interne définie dans le jeu d’essai, elle reste non transmissible tant que le responsable n’a pas validé. Le journal indique l’auteur et l’heure de la décision. En cas d’absence, un remplaçant autorisé peut agir. » Ce texte ne fixe aucune règle légale ; il décrit un besoin d’organisation. Le fournisseur doit montrer le mécanisme, préciser les droits requis et indiquer si le paramétrage est inclus. La recette peut alors reprendre le même scénario avec une commande en dessous puis au-dessus de la limite.

Fiche de vérification

Élément	Question à documenter	Preuve ou responsable
Identifiant	Référence stable	ACH-01, par exemple illustratif
Résultat	Comportement observable	Blocage avant accord
Exception	Situation inhabituelle	Remplacement du valideur
Preuve	Test et document	Compte rendu signé

À faire dans votre équipe

Prenez cinq demandes présentes dans vos échanges internes et réécrivez-les avec un sujet, une action et un résultat. Demandez à un collègue qui ne connaît pas le projet d’imaginer comment les tester. S’il doit inventer une règle importante, votre texte reste ambigu. Ajoutez alors les données nécessaires et les limites, sans multiplier les détails décoratifs. Présentez cette version au futur utilisateur pour vérifier qu’elle correspond au travail réel. Enfin, réservez un champ pour la réponse du fournisseur et un autre pour le résultat de test. Votre document devient ainsi un outil de consultation et de validation, plutôt qu’un inventaire abandonné après la signature.

Questions fréquentes

Combien de pages faut-il prévoir ?

Aucun volume universel n’est pertinent. Le document doit être assez précis pour comparer et tester, tout en restant utilisable par les équipes qui décideront et valideront.

Faut-il exiger toutes les fonctions existantes ?

Non. Examinez leur utilité et les possibilités d’adapter les procédures. Toute simplification importante doit cependant être acceptée par le métier concerné.

Peut-on partager des données réelles ?

Limitez les données transmises et privilégiez un jeu anonymisé ou fictif représentatif. Faites examiner les conditions de partage si des informations personnelles ou confidentielles sont nécessaires.

Pour poursuivre

Sources et portée

CNIL — rôles des acteurs du cloud — référence officielle consultée le 30 octobre 2026.

Les démarches, tableaux et scénarios sont des propositions de méthode propres à ce guide. La référence officielle permet de vérifier les conditions ou notions mentionnées ; elle ne valide pas les hypothèses chiffrées illustratives et ne constitue pas un classement de produits.