Se rendre au contenu

Le cahier des charges ERP : un outil d'acheteur déguisé en outil métier

Pourquoi la méthode reine de la consultation ERP ne comprend jamais l'entreprise qu'elle prétend équiper — et ce qu'on devrait faire à la place.
26 juin 2026 par
Le cahier des charges ERP : un outil d'acheteur déguisé en outil métier
ANOR, Cyrille de LAMBERT
| Aucun commentaire pour l'instant

À chaque fois qu'on me confie un cahier des charges avec ses centaines de lignes d'exigences, j'ai la même envie : répondre « moi aussi je vous aime ».

Parce que c'est une déclaration, un tableau d'exigences. Des semaines de travail, une colonne « souhaitée / attendue / indispensable », une case à cocher en face de chacune. On y a mis tout son cœur. Et je vais y répondre « oui » presque partout, un peu moins que les autres parce que j'ai la faiblesse de mettre « non » là où c'est non. Mais l'effet est le même pour tout le monde : Odoo dit oui, SAP dit oui, Oracle dit oui, Cegid dit oui, Sage dit oui, Business Central dit oui. À la fin, le client tient un magnifique classeur signé où chacun est d'accord sur tout. L'équivalent ERP du premier rendez-vous où, comme par hasard, on adore tous les deux la randonnée et les sushis.

Cela fait quinze ans que je vois passer ces tableaux. Ils viennent des grands cabinets, tout le monde les reproduit, et personne ne remet en cause une méthode qui rassure autant qu'elle est inefficace. Cet article, c'est ma tentative de dire tout haut ce que beaucoup d'intégrateurs pensent tout bas, et de proposer autre chose.

Une grille qui ne distingue rien

Commençons par le plus gênant : le tableau d'exigences ne sépare pas les bons des mauvais. Il les confond.

Demandez à dix éditeurs s'ils savent gérer des devis, des commandes, de la facturation, des notes de frais, des congés, un peu d'analytique. Ils répondront tous oui. Et ils auront raison. Le socle fonctionnel d'un ERP moderne est aujourd'hui un acquis : le « quoi » est commun à tout le marché. Coché ou non, cela ne dit rien de la qualité du projet qui va suivre.

Pire : plus il y a de lignes, plus on a l'impression d'avoir tout prévu. Des centaines d'exigences, cela impressionne le comité de pilotage, cela donne le sentiment du devoir accompli, cela remplit une réunion. Mais une longue liste n'est pas une compréhension. On peut cocher trois cents cases (ou sept cents, j'en ai vu) et n'avoir toujours aucune idée de la façon dont l'entreprise gagne réellement sa vie. La longueur n'est pas de la profondeur. C'est juste de la longueur.

Tout se joue dans le « comment »

Prenons une ligne au hasard, de celles qu'on retrouve dans tous les cahiers des charges : « gestion des notes de frais : indispensable ».

Tout le monde sait faire. Vraiment tout le monde. Mais posez les vraies questions :

  • Qui saisit la note, le collaborateur, son assistante, le comptable ?
  • À quel moment, et avec quelle pièce justificative ?
  • Sur quel projet, quel centre de coût, quel axe analytique l'impute-t-on ?
  • Qui valide, dans quel ordre, avec quel seuil de délégation ?
  • Sous combien de jours le remboursement tombe-t-il, et via quelle remontée vers la paie et la comptabilité ?

Aucune de ces questions n'apparaît dans le tableau. Or c'est exactement là que se joue la différence entre une intégration qui fait gagner du temps et une autre qui en fait perdre. Le « quoi » est identique partout ; la valeur vit dans le « comment ». Et c'est précisément la seule chose qu'une case à cocher est structurellement incapable de capturer.

Multipliez cela par trois cents lignes. À chaque ligne, on a écrasé la richesse du réel sous un oui/non. On a confondu « l'outil sait le faire » avec « l'outil le fera comme vous en avez besoin ». Ce ne sont pas du tout les mêmes projets.

La photographie figée d'un fonctionnement subi

Voici le vice le plus profond, et le plus coûteux.

Un cahier des charges, c'est la photographie du fonctionnement actuel, transformée en engagement contractuel. On prend la manière dont l'entreprise travaille aujourd'hui, on la découpe en exigences, on la fait signer. Sauf que ce fonctionnement actuel n'est que très rarement un choix réfléchi. C'est une sédimentation. Une accumulation de contournements et de cicatrices : le client qu'on a perdu un jour et qui a fait ajouter une étape de contrôle, le redressement fiscal qui a imposé un double archivage, le gros chèque jamais recouvré qui a engendré une procédure de validation à rallonge.

Et puis il y a mes préférés : les processus de contournement. Ces petits bijoux d'ingéniosité que les équipes ont inventés parce que le vieil outil était trop rigide. Le fichier Excel parallèle que personne n'ose supprimer. La double saisie « en attendant » qui dure depuis six ans. Le tampon qu'on garde « au cas où ». L'export manuel du vendredi soir. Ce sont des chefs-d'œuvre de débrouille qui ont sauvé l'entreprise au quotidien, mais ils n'existent que pour compenser les limites d'un logiciel qu'on s'apprête, justement, à remplacer.

Et que fait le cahier des charges ? Il demande religieusement de reproduire tout cela à l'identique dans le nouvel outil. On déménage dans une maison neuve en prenant soin d'emporter les fuites.

Personne, à aucun moment, ne pose la seule question qui compte : pourquoi faites-vous comme cela, et est-ce que cela doit encore exister demain ?

L'occasion de la décennie, ratée par méthode

C'est tout le paradoxe, et c'est ce qui me désole le plus.

Changer d'ERP, c'est la plus belle occasion qu'une entreprise rencontre en dix ans. L'occasion de faire le tri. De supprimer les doubles saisies, de mettre au rebut les rustines, de questionner les étapes qui n'existaient que pour compenser la rigidité d'hier. C'est le moment idéal pour revoir les processus en profondeur, pas seulement les remettre au propre, mais les optimiser :

  • Au niveau opérationnel : éliminer les ressaisies, fluidifier la circulation de l'information, automatiser ce qui était manuel par défaut, redonner de l'autonomie aux équipes.
  • Au niveau financier : regarder enfin où la marge se construit et où elle se détruit, où la trésorerie se bloque, où le besoin en fonds de roulement se dégrade, où le temps des équipes part en fumée.

Bref, se servir du projet ERP comme d'un levier de transformation, et non comme d'un simple remplacement de tuyauterie.

Le tableau d'exigences fait exactement l'inverse. Il sacralise le fonctionnement d'hier, contournements compris, avant même qu'on ait pris le temps de comprendre comment l'entreprise tourne. Il fige le besoin au pire moment : trop tôt, alors que rien n'a encore été questionné.

À quoi sert vraiment ce tableau, alors ?

Soyons honnêtes jusqu'au bout. Le cahier des charges a une fonction réelle, mais ce n'est pas celle que l'on croit. Il sert à deux choses : comparer des fournisseurs sur une grille homogène, et se couvrir juridiquement.

C'est un outil d'achat et un outil de procès. Son usage le plus concret, au fond, c'est de servir de pièce à conviction le jour où le projet dérape et finit en contentieux : la preuve écrite et signée de qui avait coché quoi. Excellent dans cette fonction-là, d'ailleurs.

Mais sur le plan métier (comprendre l'entreprise, choisir le bon partenaire, préparer un projet qui réussit), il ne sert à rien. On a pris un instrument d'achat et on l'a déguisé en instrument de compréhension métier. Le déguisement tient parce que c'est la méthode des grands cabinets et que cela rassure tout le monde dans la salle.

L'absurdité du remplissage de masse

Allons un cran plus loin dans le gâchis. On demande aux candidats de remplir ces tableaux avant même de leur avoir montré l'outil.

Faites le calcul une seconde. Une consultation sérieuse, c'est facilement quinze sociétés qui répondent. Chacune y passe d'un à plusieurs jours de travail. On a donc mobilisé, à l'échelle du marché, entre quinze et quarante-cinq jours-homme, en pure perte, pour produire quinze classeurs qui diront tous « oui » aux mêmes lignes. Quinze à quarante-cinq jours d'expertise brûlés à cocher des cases que personne ne lira vraiment.

Personne ne se dit qu'il y aurait sûrement quelque chose de plus intelligent à faire de ce temps-là ? Quelque chose comme, au hasard, comprendre l'entreprise ?

Le grand spectacle de la soutenance

Et comme tout cela n'a, au fond, rien éclairci, on passe à l'étape suivante du rituel : on convoque les finalistes pour la grande soutenance.

Là, on demande au commercial de l'intégrateur de faire sa danse du vendeur. La démonstration qui brille, les écrans qui s'enchaînent sans accroc, les diapositives qui claquent, le scénario rodé au cordeau. Tout ce cinéma sert à une seule chose : faire illusion. Masquer le fait que, aux étapes précédentes, personne n'a vraiment compris comment l'entreprise fonctionne. On a remplacé la compréhension par du spectacle.

Et c'est ainsi que l'on choisit l'ERP qui structurera l'entreprise pour les dix prochaines années : sur la qualité d'un numéro de claquettes.

On se trompe sur le consultant

Au milieu de tout cela, il y a une figure que l'on emploie mal : le consultant.

On l'appelle, et on lui demande de nous aider à… rédiger le cahier des charges. À fabriquer le tableau. On paie quelqu'un dont le métier est précisément de comprendre les entreprises, et on le met à produire une liste à cocher. C'est du gâchis de talent.

Ce qu'il faudrait lui demander, c'est l'inverse exact : aidez-nous à revoir notre façon de fonctionner, et à trouver la solution qui colle vraiment à ce que nous sommes. Le bon consultant ne remplit pas des cases. Il pose les bonnes questions. Il bouscule les évidences. Il remonte les flux jusqu'à la source.

Et la bonne nouvelle, parce qu'il y en a une, c'est que cela arrive de plus en plus. Il nous arrive régulièrement de tomber sur des projets où le consultant a vraiment pensé métier en amont : il a creusé les flux, bousculé les processus, compris comment l'entreprise tourne avant même de parler outil. Et cela se voit immédiatement. On a entre les mains de véritables schémas de flux, pas une liste de fonctions. Ces projets-là partent avec dix longueurs d'avance, parce que le vrai travail, celui de comprendre, a déjà été fait, et bien fait. Quand le consultant joue ce rôle-là, on n'est plus en train de remplir un tableau : on est en train de construire quelque chose.

La méthode ANOR : suivre une affaire, pas cocher des cases

Chez ANOR, notre méthode repose sur cette manière de concevoir les choses. Elle est moins reluisante qu'un classeur de trois cents lignes, je l'admets volontiers.

Concrètement : on s'assoit une journée dans vos bureaux, et on suit une vraie affaire de bout en bout. Une commande que l'on accompagne jusqu'à ce qu'elle devienne une facture encaissée. On regarde comment elle naît, par où elle passe, qui la touche, où elle se bloque, quelles exceptions occupent 80 % du temps des équipes. Parce qu'une affaire suivie en conditions réelles vous en apprend plus que trois cents lignes d'Excel. Et chez un négociant, par exemple, c'est une marge qui se construit ou se détruit à chaque étape. Aucune case à cocher ne vous racontera cela.

Pas de classeur signé, pas de colonne « indispensable ». À la sortie, vous repartez avec deux choses concrètes :

  1. Le schéma de l'ensemble de vos processus : la véritable cartographie de la vie de votre entreprise, celle qu'aucun tableau ne contient.
  2. Les optimisations que nous préconisons : opérationnelles et financières, étape par étape, avant qu'une seule décision d'outillage ne soit prise.

Et si un consultant a déjà fait ce travail de fond en amont ? Tant mieux. On construit dessus, on gagne du temps, on va plus loin. Sinon, on le fait. Dans les deux cas, nous refusons de démarrer un projet qui vous engage pour dix ans sur la base d'une liste à cocher que personne n'a vraiment lue.

C'est moins rassurant qu'un document de trois cents lignes.

C'est infiniment plus utile.

Et accessoirement, cela fait de bien meilleurs premiers rendez-vous.

Vous préparez un projet ERP et vous sentez que la phase amont mérite mieux qu'un tableau à cocher ? Parlons-en. Chez ANOR, nous commençons toujours par comprendre votre métier avant de parler outil.

Le cahier des charges ERP : un outil d'acheteur déguisé en outil métier
ANOR, Cyrille de LAMBERT 26 juin 2026
Partager cette publication
Archiver
Se connecter pour laisser un commentaire.