Un projet ERP ne se juge pas au jour de la mise en production. Il se juge trois ans plus tard, quand l'outil est devenu une évidence, quand les équipes l'utilisent sans y penser, quand la comptabilité sort ses clôtures sans drame et que la direction pilote son activité avec des chiffres fiables. Entre le cadrage initial et cette maturité, il s'est écoulé plusieurs années et (c'est là le point qu'on sous-estime plusieurs relais.
Le décideur qui a porté la migration — DAF, directeur général, directeur des opérations, responsable SI, selon les organisations — a quitté l'entreprise. Son successeur est arrivé avec sa propre culture, ses propres convictions, son propre parcours. Le chef de projet historique a été promu ou a changé d'employeur. Le responsable comptabilité qui connaissait les rouages est à la retraite. Côté intégrateur, l'équipe a tourné elle aussi — les consultants qui ont cadré le projet ne sont plus ceux qui l'ont déployé, ni ceux qui en assurent le support aujourd'hui.
Un projet ERP n'est pas un sprint porté par une équipe stable. C'est un marathon avec des passages de relais. Et chaque passage de relais est un moment de fragilité, souvent invisible, mais bien réel.
Ce qui se joue à chaque changement d'interlocuteur
Un nouveau décideur arrive. Il découvre l'outil. Il pose des questions. Il voit des adaptations spécifiques qui ne ressemblent pas au standard qu'il connaît ou qu'il imaginait. Il demande pourquoi. Et là, une scène se joue dans la plupart des entreprises que je croise.
Personne ne sait vraiment répondre. Le consultant qui avait cadré cette fonction n'est plus disponible. Le chef de projet qui avait validé la décision est parti. Le compte rendu de la réunion où la décision a été prise n'a jamais été retrouvé. Les tickets de support parlent de correctifs, pas d'intentions. L'utilisateur qui s'en sert au quotidien se contente de dire « c'est comme ça que ça marche, je ne sais pas pourquoi ».
Face à ce vide, trois réactions possibles de la part du nouveau décideur.
La première — la plus saine mais la plus rare — consiste à suspendre son jugement, à écouter les utilisateurs, à comprendre le contexte d'origine avant de décider. Elle suppose une posture humble et du temps pour enquêter. Elle suppose aussi que quelqu'un dans l'organisation puisse raconter l'histoire.
La deuxième consiste à s'en accommoder sans chercher à comprendre, à utiliser l'outil tel qu'il est, à ne pas ouvrir le sujet. C'est la voie de la tranquillité apparente. Le problème, c'est qu'elle laisse prospérer des adaptations qui sont peut-être devenues inutiles, redondantes avec le natif, ou même contre-productives. L'ERP s'alourdit, personne ne le challenge, et à la prochaine montée de version, la migration devient un cauchemar.
La troisième — la plus fréquente, la plus dangereuse — consiste à remettre en cause par défaut tout ce qui a été fait par le prédécesseur. Parfois avec l'argument technique : « ce n'est pas standard, il faut revenir au natif ». Parfois avec l'argument politique implicite : « je marque ma gouvernance en effaçant les choix du précédent ». Parfois par simple méconnaissance : le nouveau décideur ne comprend pas le contexte métier qui avait justifié l'adaptation, et puisqu'il ne le comprend pas, il le rejette.
Les ravages d'un projet remis en cause sans inventaire
J'ai vu cela se produire plusieurs fois, sur des projets que nous avons repris. Et je dois dire quelque chose qui va peut-être à rebours de ce qu'on attend d'un intégrateur qui reprend un dossier : en creusant l'existant, je me suis souvent rendu compte que le précédent intégrateur avait très bien travaillé. Les choix faits étaient cohérents avec le besoin métier du moment, les adaptations avaient une logique, les processus étaient structurés. Ce qui avait manqué, ce n'était pas la qualité du travail technique — c'était la continuité de la mémoire entre les équipes successives.
Dire cela, ce n'est pas faire de la complaisance envers un confrère. C'est reconnaître que les projets ERP se font rarement sur table rase et que l'honnêteté consiste d'abord à comprendre ce qui a été fait avant de le défaire. Quand un nouveau décideur et un nouvel intégrateur se précipitent pour tout reprendre sans inventaire, ils jettent souvent ce qui marchait avec ce qui ne marchait plus. Le client paie deux fois : une première pour le travail initial, une seconde pour sa destruction et sa reconstruction.
Les conséquences concrètes sont visibles. Des développements qui avaient coûté des mois de travail et plusieurs dizaines de milliers d'euros, abandonnés sans qu'on sache à quoi ils servaient. Des processus métier qui s'étaient stabilisés au fil des années, remis à plat parce qu'un nouveau décideur voulait imposer sa vision sans mesurer ce qu'il défaisait. Des équipes comptables qui ont dû réapprendre à manipuler leur outil, non parce qu'il était mauvais, mais parce qu'on leur en avait fait une version « plus simple » qui leur faisait perdre des fonctions qu'elles utilisaient tous les jours.
Et le pire : des relations client-intégrateur qui se détériorent. Le nouveau décideur, frustré de ne pas comprendre, se défie de tout ce qui existe — y compris du partenaire historique. L'intégrateur, lui, vit comme une injustice le fait de devoir justifier des choix qu'il avait validés avec le précédent décideur. La confiance s'érode. Les relations se tendent. Le projet s'enlise dans une renégociation permanente de ses fondations, au lieu de progresser.
Dans certains cas, cela va jusqu'à la rupture. Un appel d'offres pour changer d'intégrateur. Une remise à plat complète. Des coûts masqués qui s'additionnent. Et trois ans plus tard, le nouveau projet souffre exactement des mêmes maux — parce que personne n'a pris la peine d'écrire non plus la nouvelle histoire.
Le paradoxe de la documentation
Il faut poser ici un paradoxe que tous les intégrateurs connaissent et que peu osent nommer.
Quand on produit de la documentation, elle est souvent peu lue. Les PDF dorment dans des espaces partagés, les wikis internes ne sont plus à jour depuis dix-huit mois, les liens SharePoint renvoient vers des versions obsolètes. Les utilisateurs apprennent en faisant, demandent à leurs collègues, ouvrent des tickets de support. La documentation existe, mais elle ne vit pas.
Quand on ne produit pas de documentation, elle manque cruellement. Au moindre changement d'interlocuteur, au moindre départ, au moindre projet de migration, l'absence se fait sentir. On cherche, on ne trouve pas, on reconstitue dans l'urgence avec ceux qui restent, on perd du temps et de la confiance.
Les deux postures échouent. Trop documenter crée de l'inertie et un faux sentiment de maîtrise. Ne rien documenter crée de la fragilité et des coûts cachés. Le bon geste se trouve dans un juste milieu qu'il faut apprendre à viser.
Ce juste milieu tient en trois principes.
- Documenter seulement ce qui sert. Pas chaque écran, pas chaque champ, pas chaque bouton d'Odoo — cela existe déjà dans la documentation officielle. Ce qui mérite d'être documenté, c'est ce qui est spécifique à l'entreprise : les adaptations, les règles de gestion, les points de vigilance identifiés à l'usage, les décisions prises à des moments clés du projet. Le reste est du bruit.
- Documenter dans la langue du lecteur. Un document écrit par un développeur pour un développeur ne sera pas lu par une comptable. Un document lisible par une comptable sera aussi utile au directeur financier, au chef de projet, et au successeur qui arrivera dans deux ans sans connaître le contexte. C'est le critère de l'accessibilité qui fait la différence entre une documentation qui dort et une documentation qui vit.
- Et surtout — et c'est le point le plus important — ne jamais laisser la documentation servir de parapluie. C'est le travers dans lequel tombent beaucoup d'organisations : on produit un document épais, on le fait valider par le client, et on considère que le sujet est clos. Si le client ne comprend pas plus tard, ce sera sa faute : « c'était pourtant dans la documentation ». Cette posture est toxique. La documentation n'est pas un moyen de se couvrir. C'est un moyen de transmettre. Et cela se mesure à un critère simple : est-ce que le lecteur a compris ? Pas : est-ce que c'était écrit ?
La bonne documentation n'est pas celle qui est la plus complète. C'est celle qui est la plus utile.
Ce que doit contenir une documentation qui fait mémoire
Concrètement, une documentation utile à la continuité d'un projet ERP répond, pour chaque adaptation, à quatre questions :
- Que fait cette fonction ? Dans un langage accessible, sans jargon. Écrit pour le comptable, le chef de projet, le commercial — pas pour un développeur.
- Où la trouve-t-on ? Le chemin dans les menus, les endroits où elle se manifeste, les écrans concernés. Pour qu'un nouvel utilisateur puisse retrouver la fonction sans avoir à demander à un collègue.
- Comment s'en sert-on étape par étape ? Des procédures courtes, numérotées, avec les cas particuliers et les points de vigilance. Pour que l'outil soit utilisable par quelqu'un qui arrive sans historique.
- Pourquoi cette adaptation existe ? C'est le point le plus souvent oublié et pourtant le plus précieux. Quel besoin métier elle couvre, dans quel contexte elle a été décidée, pourquoi ce choix-là plutôt qu'un autre. C'est ce paragraphe qui fait la différence entre un document de mise en service et un document qui fait mémoire.
À cela, nous ajoutons une perspective d'évolution : chaque adaptation mentionne, quand c'est pertinent, les fonctions natives qui pourraient la remplacer dans les versions à venir. Cela prépare la revue qui doit accompagner chaque montée de version.
Le texte ne suffit pas — les flux se dessinent
Un projet ERP est fait de processus qui traversent plusieurs modules, plusieurs services, plusieurs mains. Une commande client part de la vente, passe par l'approvisionnement, déclenche un achat, génère une livraison, alimente une facture, met à jour une ventilation analytique. Tout raconter par des phrases est possible, mais épuisant à lire et difficile à retenir.
C'est pourquoi une bonne documentation inclut des schémas de flux. Un organigramme qui montre l'enchaînement des étapes. Un diagramme de séquence qui montre qui fait quoi à quel moment. Un schéma d'architecture qui montre comment les modules se parlent entre eux. Ces éléments visuels font en une image ce qu'un paragraphe met plusieurs lignes à expliquer — et surtout, ils restent en mémoire.
L'enjeu n'est pas esthétique. Un schéma n'est pas une décoration. C'est un outil de compréhension, qui permet au lecteur de se repérer dans une mécanique qui peut sembler complexe. Un comptable qui voit le flux d'une écriture analytique depuis la facture jusqu'au rapport de rentabilité comprend immédiatement pourquoi une étape de paramétrage est importante — alors que la même information noyée dans trois pages de texte n'aurait produit aucun déclic.
Chez ANOR, nous intégrons systématiquement des schémas dans nos guides pour les processus transverses et pour les enchaînements multi-modules. Nous évitons en revanche les schémas purement techniques — le but n'est pas d'impressionner, c'est de faire comprendre. Un bon schéma tient sur une page, utilise un vocabulaire métier, et répond à une question que le lecteur se pose vraiment.
Là où nous documentons : le module Connaissance d'Odoo
La question du support de la documentation est souvent négligée. Où stocke-t-on le guide utilisateur ? Dans un PDF déposé sur un serveur de fichiers ? Sur un wiki interne qui n'est plus maintenu depuis deux ans ? Dans un espace SharePoint où les liens se cassent au fil des réorganisations ? Chaque choix a ses limites — et la plupart aboutissent au même résultat : une documentation qui existe, mais que personne ne trouve au moment où on en a besoin.
C'est pourquoi nous utilisons massivement le module Connaissance d'Odoo. Pour un client qui travaille déjà dans Odoo au quotidien, c'est l'endroit le plus évident pour déposer sa documentation : au même endroit que l'outil, accessible d'un clic, structuré en articles hiérarchisés, recherchable par mots-clés.
Le module est redoutablement efficace. Les articles s'écrivent dans un éditeur riche, supportent les images, les tableaux, les schémas intégrés, les liens entre articles. La mise à jour est immédiate — pas de chaîne de validation lourde, pas de PDF à regénérer. Les autorisations s'ajustent finement : certains articles sont accessibles à toute l'entreprise, d'autres réservés à la comptabilité, d'autres encore au seul intégrateur. Les modifications sont tracées, l'historique est consultable, les articles peuvent être liés à des enregistrements Odoo précis — une fiche produit, un projet, une commande. La documentation vit à côté de l'objet qu'elle documente.
Pour nous, intégrateur, c'est aussi un gain de temps considérable. Nous rédigeons une fois, nous mettons à jour au fil du projet, et le client a en permanence la dernière version sous les yeux. Pas de « je vous envoie le PDF à jour », pas de « regardez la version 3.2 cette fois ». Une seule source, maintenue vivante.
C'est un détail qui n'en est pas un. Beaucoup de projets ont une documentation qui existe quelque part et personne ne sait plus où. Ce n'est pas un problème de contenu — c'est un problème de lieu. Mettre la documentation dans l'outil même, c'est supprimer ce problème.
Le rôle de l'intégrateur dans cette continuité
On pourrait penser que l'intégrateur, ayant la mémoire technique du projet, suffit à assurer cette continuité. C'est une illusion. L'intégrateur aussi voit ses équipes tourner. Le consultant qui a cadré l'adaptation il y a quatre ans est peut-être parti. Celui qui l'a développée travaille aujourd'hui sur un autre client. Même celui qui assure le support actuel n'a qu'une partie de l'histoire.
La mémoire d'un projet ne peut pas reposer sur les personnes. Elle doit reposer sur l'écrit. Et cet écrit doit être partagé entre le client et l'intégrateur, validé par les deux parties, entretenu au fil du temps.
Pour l'intégrateur, documenter le projet de son client est une forme de protection — contre les remises en cause infondées, contre les procès d'intention au changement d'interlocuteur. À condition de ne jamais l'utiliser comme parapluie. Un document produit pour se couvrir ne protège personne : ni le client qui ne le lira pas, ni l'intégrateur dont la relation se détériorera malgré tout.
Pour le client, c'est une assurance. Contre la dépendance à un intégrateur unique, contre la perte de savoir quand une équipe interne change, contre les décisions impulsives d'un successeur trop pressé de marquer son territoire.
Ce que nous faisons chez ANOR
Sur le papier, la documentation utilisateur est souvent de la responsabilité du client. C'est à lui de produire et de maintenir la référence de ses propres processus. Dans les faits, cela se fait rarement. Les équipes métier n'ont pas le temps, les priorités opérationnelles passent avant et le document promis dans le cadrage ne se fait jamais. Nous l'acceptons comme une réalité.
Pour autant, nous produisons de plus en plus souvent un guide utilisateur orienté métier sur les projets que nous accompagnons. D'abord pour nos propres besoins internes. Quand une équipe ANOR change, quand un nouveau consultant reprend le dossier, quand un point de support demande de retrouver le contexte d'une adaptation — la documentation est ce qui nous permet de rester cohérents dans la durée, sans dépendre de la mémoire individuelle. C'est un outil de travail avant d'être un livrable.
Mais nous avons constaté que ce document, écrit pour nous, devient naturellement utile au client. Nous le partageons, il circule, il aide les équipes à s'approprier leur outil, il rassure les successeurs, il prépare les montées de version. Ce qui partait d'un besoin interne est devenu, dans plusieurs projets, un repère partagé — et dans certains cas, un outil de réassurance au moment le plus critique : un changement de décideur.
Nous n'en faisons pas un dogme. Ce n'est pas toujours nécessaire, ce n'est pas toujours attendu. Mais quand le contexte le justifie — une migration importante, une reprise de projet, un changement d'équipe prévisible — nous le proposons. À condition d'assumer ce qu'il implique : être lu, être utile, être remis en cause. Jamais servir de parapluie.
Un ERP n'appartient ni au décideur qui l'a lancé, ni au chef de projet qui l'a déployé, ni à l'intégrateur qui l'a construit. Il appartient à l'entreprise, dans la durée. La documentation — la bonne, celle qui vise juste — c'est ce qui rend possible cette appropriation collective. Pas pour se couvrir. Pour transmettre.
Un projet bien documenté peut traverser plusieurs générations de décideurs. Un projet sans mémoire peut être défait par un seul changement d'interlocuteur. Entre les deux, il y a le juste geste documentaire — ni trop, ni trop peu, et toujours au service du lecteur.
À propos de ce texte — Cet article s'appuie sur notre expérience d'intégration et d'accompagnement Odoo. Si vous préparez une montée de version, un changement d'équipe projet ou la reprise d'un ERP existant, et que la question de la mémoire de votre projet se pose, nous serons heureux d'en discuter avec vous.