Conseils

À quoi sert un cahier des charges ERP, et comment le rédiger

Par Marc Adedjouma · Fondateur de We Make Smart · Lecture : 9 minutes

Le cahier des charges est le document le plus mal aimé des projets informatiques. Les dirigeants de PME le perçoivent comme un exercice administratif, un passage obligé qu'on expédie ou qu'on délègue, parfois même comme une perte de temps face à des éditeurs qui proposent de « faire simple » et de commencer directement par une démonstration.

C'est une erreur de perception, et elle coûte cher. Bien conçu, le cahier des charges n'est pas un document parmi d'autres : c'est le seul instrument de tout le projet qui travaille pour vous du premier jour au dernier. Encore faut-il comprendre à quoi il sert vraiment, parce que sa vraie fonction n'est pas celle qu'on croit.

À quoi sert vraiment un cahier des charges

Première fonction : rendre les offres comparables. Sans document commun, chaque éditeur consulté reformule votre besoin dans les termes de son produit. Vous recevez trois propositions qui répondent à trois questions différentes, avec des périmètres différents, des hypothèses différentes, des exclusions différentes. Elles sont incomparables, et c'est précisément là que les projets s'enlisent. Un cahier des charges impose la même question à tous les candidats : leurs réponses deviennent alignables ligne à ligne, les écarts de prix s'expliquent, et les silences deviennent visibles. Ce qu'un éditeur ne chiffre pas en réponse à une exigence écrite, il faudra le payer plus tard.

Deuxième fonction : permettre aux éditeurs de s'engager au forfait. Un éditeur qui répond à un besoin flou se protège, et il a raison de le faire : il chiffre en régie, ajoute des marges d'incertitude, ou truffe sa proposition d'hypothèses à valider qui deviendront des avenants. Ce n'est pas de la malhonnêteté, c'est la conséquence mécanique d'une question mal posée. Un cahier des charges précis inverse la situation : l'éditeur dispose de toutes les billes, les volumes, les cas particuliers, les interfaces, et peut s'engager sur un montant ferme et un périmètre fermé. Vous y gagnez un prix qui ne dérivera pas ; il y gagne un projet cadré qu'il peut tenir. Tout le monde part serein, et c'est le document qui a rendu cela possible.

Troisième fonction : transformer les démonstrations en épreuves. C'est la fonction la moins connue et l'une des plus puissantes. Chaque exigence du cahier des charges, si elle est bien rédigée, devient une consigne de démonstration : « montrez-moi que je peux établir ce devis, traiter ce retour client, sortir cette marge par affaire ». Au lieu d'assister à un scénario commercial rodé sur les données de l'éditeur, vous faites passer à chaque candidat la même épreuve, sur vos cas réels. La démonstration cesse d'être un spectacle pour devenir un test, et les promesses se séparent des capacités sous vos yeux.

Quatrième fonction, et c'est celle qui protège votre investissement : servir de référence de recette au déploiement. Le moment le plus dangereux d'un projet ERP n'est pas le choix, c'est la mise en œuvre, quand l'outil livré s'éloigne progressivement de ce qui a été vendu. Si votre cahier des charges décrit des cas d'usage vérifiables, il devient naturellement la grille de contrôle du déploiement : chaque exigence validée en démonstration doit fonctionner à l'identique au moment de la livraison. L'écart se constate document en main, pendant qu'il est encore corrigeable, au lieu de se découvrir au démarrage. Le même document sert donc quatre fois : pour consulter, pour obtenir un forfait, pour comparer, pour recetter. C'est ce qui en fait le meilleur investissement du projet.

Et il faut ajouter une fonction en creux : un bon cahier des charges permet aussi de conclure qu'aucun outil ne convient, ou que le besoin réel appelle autre chose qu'un ERP. Un document qui ne peut mener qu'à un achat n'est pas un outil de décision.

Ce qu'un cahier des charges n'est pas

Avant de rédiger, il faut désapprendre trois habitudes qui produisent des documents inutilisables.

Ce n'est pas une liste de souhaits. « Un outil performant, intuitif, évolutif, avec une bonne gestion commerciale » : aucun éditeur au monde ne peut échouer face à ces mots. Un document composé d'adjectifs et de généralités sera approuvé par tous les candidats et ne filtrera personne. Le test est simple : si une exigence ne peut pas recevoir de réponse binaire en démonstration, elle n'a rien à faire dans le document.

Ce n'est pas une description de solution. Beaucoup de cahiers des charges décrivent, sans le savoir, le produit de la dernière démonstration vue : ses modules, ses écrans, son vocabulaire. Ce document ne compare plus rien, il vérifie la conformité du marché à un produit déjà choisi. La règle de rédaction est stricte : décrire ce que l'entreprise doit pouvoir faire, jamais comment l'outil doit le faire. Le quoi vous appartient ; le comment appartient aux éditeurs, et c'est justement sur le comment qu'ils se départageront.

Ce n'est pas un inventaire exhaustif de mille lignes. Un document qui exige tout n'exige rien : les éditeurs cochent toutes les cases et l'essentiel se noie dans l'accessoire. Un bon cahier des charges hiérarchise, distingue ce qui est indispensable dès le démarrage de ce qui est souhaitable à terme, et assume des priorités. La hiérarchie est une information en soi : elle dit aux candidats où ils seront jugés.

Un cas vécu résume ces trois pièges en un seul document. La dirigeante d'une PME de l'événementiel me sollicite : elle cherche son outil depuis huit mois, et elle a pourtant fait le travail, puisqu'un cahier des charges existe. Soixante-six pages. À la lecture, le diagnostic saute aux yeux : le document est saturé d'acronymes internes et de vocabulaire sectoriel qu'aucun éditeur ne peut décoder, il décrit longuement le fonctionnement passé de l'entreprise plutôt que sa cible, et des dizaines de lignes n'apportent strictement rien à un candidat qui devrait chiffrer. L'essentiel existait quelque part dans ces pages, mais noyé au point d'être invisible : aucune comparaison efficace n'était possible, et huit mois de consultations n'avaient produit que des réponses floues.

Nous avons repris le travail avec les équipes, atelier par atelier, en appliquant une seule discipline : chaque ligne conservée devait être compréhensible par un lecteur extérieur et vérifiable en démonstration. Le document est passé de soixante-six pages à dix. Dix pages si précises que la consultation est devenue simple : les démonstrations se sont déroulées sur ses cas réels, la solution adaptée s'est détachée nettement, et l'éditeur retenu s'est engagé au forfait sans hésitation, parce qu'il avait, pour une fois, toutes les billes en main. Le volume du document n'avait jamais été le signe de sa qualité : c'était le symptôme du problème.

Comment le rédiger : la méthode

Commencez par les personnes, pas par les fonctions. Le besoin réel ne se trouve pas dans l'organigramme mais dans le quotidien de chaque métier. Organisez un atelier par profil utilisateur : le commercial, l'administration des ventes, la production, la comptabilité, la direction. Séparément, pas en réunion plénière, parce qu'une réunion commune fait ressortir la voix du plus bavard et écrase les cas particuliers. Dans chaque atelier, cherchez trois choses : les irritants actuels, le déroulement cible du travail, et ce qui fonctionne bien aujourd'hui et doit absolument être conservé. Ce troisième point est le plus souvent oublié, et c'est lui qui évite de régresser en changeant d'outil.

Traduisez chaque besoin en cas d'usage démontrable, avec une cible tangible. C'est le cœur de la méthode, et elle se joue en deux temps. Les irritants collectés en atelier sont le point de départ : ils disent où le quotidien fait mal. Mais l'irritant ne suffit pas, parce qu'il produit naturellement des souhaits vagues : « je veux faire mes devis plus rapidement » est un soupir, pas une exigence. Aucun éditeur ne peut échouer face à un soupir.

Le second temps consiste à transformer chaque irritant en cible mesurable : « la prise de commande doit tenir en moins de cinq minutes », « la facture doit sortir sans ressaisie à partir du bon de livraison », « la marge par affaire doit être disponible sans retraitement sur tableur ». La différence est décisive : « plus rapidement » se discutera éternellement, « moins de cinq minutes » se chronomètre en démonstration et se vérifie à la livraison. Une cible tangible sert trois fois : elle oblige l'éditeur à s'engager, elle transforme la démonstration en épreuve chiffrée, et elle devient le critère de recette au déploiement.

Un mot de prudence sur le choix des métriques : mesurez le résultat pour l'utilisateur, pas la mécanique de l'écran. Un objectif de temps ou de suppression de ressaisie décrit un besoin ; un nombre de clics décrit une ergonomie, c'est-à-dire un comment, et un éditeur pourra toujours plaider que trois clics confus valent moins que cinq clics fluides. Le temps, les ressaisies évitées et les données obtenues sans retraitement sont les bonnes unités de mesure du besoin.

Documentez ce que le système devra produire, pas seulement ce qu'il devra faire. Un ERP n'est pas qu'un outil de saisie : c'est la source des chiffres qui pilotent l'entreprise et alimentent la comptabilité. Précisez les indicateurs que la direction doit pouvoir sortir, les exports attendus, et le volet comptable : plan de comptes, écritures, fichiers réglementaires. Votre expert-comptable devrait être consulté à ce stade, avant tout choix, pas mis devant le fait accompli au premier bilan.

Décrivez l'écosystème et les volumes. Quels outils restent en place et devront être connectés, quelle donnée fait référence dans quel système, combien de commandes, de références, de factures par mois. Ces éléments paraissent techniques : ils sont surtout ce qui permet aux éditeurs de chiffrer sérieusement, donc de s'engager sur un forfait plutôt que sur une estimation qui dérivera.

Hiérarchisez, et assumez les arbitrages par écrit. Chaque exigence reçoit une priorité claire, et les arbitrages entre métiers, quand deux besoins se contredisent, sont tranchés et documentés pendant la rédaction, pas découverts pendant le déploiement. Un cahier des charges qui contient des contradictions non résolues transmet le conflit à l'intégrateur, qui le tranchera à votre place, à sa convenance.

Enfin, écrivez pour un lecteur qui découvre votre entreprise. Le document doit être compréhensible par quelqu'un qui n'a jamais mis les pieds chez vous : c'est la condition pour qu'un éditeur réponde juste, et le meilleur test de clarté qui soit. Si une exigence suppose un contexte que seul un salarié connaît, elle est incomplète.

Le test final

Un cahier des charges est prêt quand il passe trois épreuves. Chaque exigence peut recevoir une réponse binaire en démonstration. Un tiers qui découvre l'entreprise comprend le document sans explication orale. Et vous seriez prêt à en faire l'annexe contractuelle de la commande, celle sur laquelle la livraison sera jugée. Si ces trois conditions sont réunies, vous ne subirez plus les démonstrations : vous les dirigerez. Et le jour de la mise en service, vous saurez, document en main, si l'on vous a livré ce que vous avez acheté.

C'est exactement la méthode que nous appliquons chez We Make Smart : des ateliers par profil métier, des cas d'usage démontrables, un document qui sert de la consultation jusqu'à la recette. Et si le sujet vous parle mais que vous n'en êtes qu'au début de la réflexion, commencez par comprendre pourquoi les PME mettent six mois à ne pas choisir leur ERP.