La plupart des organisations jugent la réussite d'un projet ERP le jour de la bascule : les flux passent, la facturation sort, les stocks sont corrects, le pilotage fonctionne. Si ces quelques jours critiques se déroulent sans catastrophe, le projet est réputé gagné, on remercie les équipes, on passe à autre chose.
C'est un verdict prématuré. Le vrai test arrive plus tard, et dans un contexte très différent : le jour où quelqu'un qui n'a pas participé au projet en devient responsable. Un nouveau DAF. Un nouveau directeur général. Un successeur à la DSI. Un repreneur qui intègre l'entreprise à son groupe. À ce moment-là, le projet cesse d'être évalué par ceux qui l'ont construit — il est évalué par un héritier.
Cet héritier ne connaît ni le cahier des charges initial, ni les arbitrages pris, ni les raisons des adaptations spécifiques. Il ne connaît que ce qu'il trouve en arrivant : un outil en production, des utilisateurs plus ou moins à l'aise, une documentation souvent lacunaire, et un intégrateur qu'il n'a pas choisi. Ce qu'il fait de cet héritage dans les six mois qui suivent sa prise de fonction décide, largement, de la durée de vie réelle du projet.
Le turnover, ennemi silencieux du projet ERP
Entre le cadrage et la maturité opérationnelle d'un ERP, trois à cinq ans s'écoulent. En trois à cinq ans, dans une entreprise vivante, presque tout a bougé — sauf l'outil.
Le porteur métier qui avait déclenché la démarche — on le trouve sous des titres variés selon les organisations : DAF, directeur général, directeur des opérations, responsable des systèmes d'information, parfois un directeur de filiale — a souvent quitté l'entreprise, évolué en interne, ou été remplacé lors d'une réorganisation. Le chef de projet interne qui pilotait au quotidien a été promu ou recruté ailleurs. Les utilisateurs clés qui avaient validé les maquettes et conduit les recettes ne sont plus aux mêmes postes. Le responsable comptable qui connaissait les subtilités de paramétrage est parti à la retraite.
Côté partenaire d'intégration, la situation est symétrique. Les consultants qui ont mené la conception travaillent aujourd'hui sur d'autres dossiers, peut-être dans une autre structure. Les développeurs ayant produit les spécifiques ont pu quitter la société. L'équipe de support actuelle ne détient qu'une partie de la mémoire du projet — celle des tickets récents, pas celle des arbitrages fondateurs.
Ce phénomène est banal, continu, et terriblement sous-estimé. À chaque départ, une part du savoir tacite disparaît. Pourquoi tel champ a été ajouté. Pourquoi telle règle d'arrondi a été paramétrée ainsi. Pourquoi ce processus de validation à trois étages plutôt que deux. Les réponses vivaient dans les têtes. Elles s'en vont avec elles. L'héritier qui arrive ensuite n'hérite pas seulement d'un outil — il hérite d'une énigme.
Les trois réactions de l'héritier
Face à cet outil qu'il n'a pas choisi, le nouvel arrivant peut emprunter trois voies.
La première, la plus constructive, consiste à reconnaître son déficit de contexte et à enquêter avant de juger. Elle suppose de demander à l'intégrateur de restituer l'histoire technique et fonctionnelle, d'écouter les opérationnels, de lire ce qui existe comme documentation, de suspendre ses réflexes le temps de comprendre. Cette posture est minoritaire. Elle exige une maturité professionnelle que l'urgence d'un poste nouvellement occupé facilite rarement.
La deuxième est celle du statu quo. Le décideur ne comprend pas toutes les adaptations mais ne les remet pas en question. Il laisse l'outil tourner tel quel. Cette paix apparente a un coût caché : des spécifiques devenus obsolètes prolongent leur existence, des fonctions désormais couvertes par le standard Odoo continuent à être maintenues dans une version personnalisée, et la dette technique s'accumule en silence jusqu'à rendre toute future montée de version coûteuse, voire traumatique.
La troisième, la plus fréquente et la plus destructrice, c'est la remise en cause par ignorance. Ne comprenant pas l'historique, l'héritier décrète que ce qui existe est mal fait. L'argument est souvent technique en apparence — « ce n'est pas conforme aux bonnes pratiques », « cela ne suit pas le standard éditeur », « les choix faits sont dépassés » — mais la raison réelle est plus humaine : on ne défend pas ce qu'on n'a pas construit, et on existe politiquement en effaçant ce qu'on trouve. Cette dynamique est d'autant plus forte que personne dans l'entreprise n'a d'éléments pour contredire l'analyse.
Reconnaître le travail qu'on nous demande de refaire
Sur plusieurs dossiers repris en sortie d'une rupture client-intégrateur, nous avons fait la même observation : le travail du confrère précédent était souvent de bonne facture. Les choix d'architecture étaient cohérents avec le besoin exprimé à l'époque. Les développements spécifiques avaient une logique métier défendable. Les processus tenaient la route.
Ce qui avait fait défaut, ce n'était pas la qualité d'exécution — c'était la capacité à se transmettre à l'héritier. La rupture n'a pas été technique. Elle a été narrative.
Le dire, c'est un engagement d'honnêteté professionnelle. Les projets ERP se succèdent rarement sur des terrains vierges. Quand nous arrivons après un autre cabinet, notre travail commence par comprendre ce qui a été fait et pourquoi — pas par effacer pour réinstaller. Quand un client et son nouveau décideur se précipitent à tout refaire sans inventaire préalable, ils réduisent en cendres un capital qui méritait d'être réévalué posément. La facture est double : le budget d'origine, puis celui de la reconstruction.
Les dégâts visibles sont nombreux. Des développements anciens abandonnés alors qu'ils couvraient un vrai besoin. Des processus métier stabilisés depuis des années, déstabilisés parce que le successeur voulait sa marque sur l'outil. Des équipes contraintes de réapprendre un système qu'elles maîtrisaient. Les dégâts invisibles sont pires encore : la relation entre l'entreprise et son intégrateur se dégrade, la confiance s'étiole, le dialogue se tend, jusqu'à la rupture. Trois ans plus tard, le nouveau projet souffre des mêmes faiblesses que l'ancien, parce que personne n'a pris la précaution d'écrire l'histoire cette fois non plus.
Documenter : le faux ami
Tous les intégrateurs connaissent une vérité qu'ils énoncent rarement à voix haute : la documentation telle qu'on la pratique habituellement ne sert pratiquement à rien.
Quand elle est produite en volume, elle n'est pas lue. Les PDF épais dorment dans des espaces partagés que personne ne visite. Les wikis d'entreprise n'ont pas été mis à jour depuis dix-huit mois. Les liens vers SharePoint, Notion ou Teams pointent vers des versions obsolètes dès qu'une réorganisation a renommé un espace. Les utilisateurs apprennent par imitation, demandent à leur voisin, ou ouvrent un ticket. La documentation existe administrativement, mais elle ne circule pas.
Quand elle n'est pas produite, son absence se paie cash. Un départ, une migration, un audit, l'arrivée d'un héritier — et il faut reconstituer en urgence un savoir qu'on n'avait pas pris le temps de poser. Les coûts cachés s'additionnent, la confiance s'érode, les décisions se prennent sans les données qui permettraient de les éclairer.
Trop documenter fabrique de l'inertie et une illusion de maîtrise. Ne pas documenter fabrique de la fragilité et des coûts différés. Le geste juste se situe entre les deux, et il ne s'improvise pas.
Nous le résumons en trois principes:
- Documenter seulement ce qui ne s'apprend pas dans la documentation officielle d'Odoo. Les écrans standards, les parcours natifs, les fonctions d'usage courant — tout cela est déjà couvert par les ressources de l'éditeur et par d'abondantes contributions communautaires. Ce qui mérite d'être consigné dans le référentiel interne de l'entreprise, c'est exclusivement ce qui est propre à son installation : les adaptations, les règles de gestion particulières, les vigilances identifiées à l'usage, les décisions prises à des moments clés.
- Documenter dans la langue de ceux qui vont lire — à commencer par l'héritier. Un document rédigé par un développeur pour un développeur ne sera pas lu par un comptable, et encore moins par un successeur qui découvre le dossier. Un document compréhensible par un comptable est aussi utile au DAF, au contrôleur de gestion, au chef de projet et au décideur qui arrivera dans trois ans. Le critère d'accessibilité n'est pas un détail cosmétique : c'est lui qui fait la différence entre une documentation vivante et une documentation morte.
- Refuser la logique du parapluie. C'est le piège le plus insidieux. Produire un document épais, le faire viser par le client, considérer que si une incompréhension survient plus tard, elle relève de la responsabilité du lecteur — « c'était pourtant écrit ». Cette posture est un aveu d'échec déguisé en assurance professionnelle. La documentation ne sert pas à se couvrir. Elle sert à transmettre. Le seul test valide est celui de la compréhension réelle du lecteur — pas celui de l'existence du texte.
Une bonne documentation n'est pas la plus complète. C'est la plus utile à celui qui hérite.
Les quatre questions auxquelles l'héritier doit pouvoir répondre seul
De façon très concrète, une documentation qui assure la continuité d'un projet ERP répond à quatre questions sur chaque adaptation significative :
- Que fait-elle ? Une description en langue naturelle, sans vocabulaire technique, accessible à l'utilisateur qui va s'en servir — et non à celui qui l'a codée.
- Où la trouve-t-on ? Le chemin dans les menus, les écrans concernés, les endroits où elle se manifeste. Pour qu'un arrivant puisse la localiser sans avoir à interroger un collègue.
- Comment l'utilise-t-on ? Des étapes numérotées, des cas particuliers identifiés, des points de vigilance notés. Pour que l'outil reste utilisable par quelqu'un qui n'a pas participé à sa conception.
- Pourquoi existe-t-elle ? C'est le paragraphe que l'on omet presque toujours, et qui vaut pourtant plus que les trois autres réunis. Quel besoin métier était en jeu. Dans quel contexte la décision a été prise. Pourquoi cette solution plutôt qu'une autre. C'est cette quatrième réponse qui permet à l'héritier de juger — plutôt que de jeter par défaut.
Nous y ajoutons, quand c'est pertinent, une perspective d'évolution : quelles fonctions natives d'Odoo pourraient, dans une version future, remplacer tout ou partie de l'adaptation. Cette projection prépare la revue critique qui doit accompagner chaque montée de version, au lieu de la subir.
Un schéma vaut mieux qu'un paragraphe
Un ERP fait circuler des flux à travers plusieurs modules, plusieurs services, plusieurs responsabilités. Une commande née au commercial déclenche un approvisionnement, mobilise le magasin, génère une livraison, produit une facture, alimente une ventilation analytique. Décrire cet enchaînement par un paragraphe continu est techniquement faisable, mais pratiquement illisible — surtout pour un lecteur qui n'a pas l'historique.
Un schéma résout cette difficulté en un coup d'œil. Un organigramme d'étapes, un diagramme de séquence entre acteurs, une vue d'architecture des modules connectés — chacun de ces formats fait tenir sur une page ce qu'un long texte dilue en plusieurs écrans. Et surtout, un schéma se retient. Un paragraphe, beaucoup moins.
Ce n'est pas une question graphique. Un schéma n'est pas là pour décorer un document ni pour impressionner un lecteur. C'est un instrument pédagogique : il positionne le lecteur dans un mécanisme qu'il pourrait trouver confus, il rend lisible ce qui est transverse, il ancre une compréhension structurelle que la prose ne produit pas.
Nos guides comportent systématiquement des schémas pour les processus multi-modules et pour tout flux qui traverse plusieurs services. Nous évitons en revanche les représentations purement techniques — UML complet, modèles de données détaillés — inutiles au lecteur métier. Un bon schéma parle la langue du métier et répond à une question que quelqu'un se pose vraiment.
Odoo Connaissance : la documentation là où elle est lue
Le choix du support pèse autant que le contenu. Beaucoup de documentations meurent sur ce détail apparent. Où la range-t-on ? Dans un PDF posé sur un serveur ? Sur un wiki d'entreprise qu'on ouvre deux fois par an ? Dans un espace collaboratif dont les URL se brisent à chaque réorganisation ? À chaque choix correspond un même défaut : la documentation existe, mais personne ne la retrouve quand elle est nécessaire — et surtout pas l'héritier qui débarque.
Nous recommandons et utilisons massivement le module Connaissance d'Odoo. Pour un client qui manipule Odoo au quotidien, c'est l'évidence : la documentation réside dans le même outil que le travail. Aucune bascule à faire, aucun nouveau compte à créer, aucun réflexe à installer — il suffit d'ouvrir une application que l'on utilise déjà.
Le module propose un éditeur riche, structure les articles en arborescence, permet la recherche plein texte, supporte les images, les tableaux, les schémas intégrés et les liens croisés entre articles. La mise à jour est instantanée, sans chaîne de validation lourde et sans PDF à régénérer. Les droits d'accès se règlent finement : certains articles sont publics dans l'entreprise, d'autres réservés à un service, d'autres encore partagés entre le client et son intégrateur. L'historique des modifications est conservé, les articles peuvent être rattachés à des enregistrements précis — une fiche produit, un projet, une commande — de sorte que la documentation accompagne l'objet documenté.
Pour l'intégrateur, le gain opérationnel est considérable. Nous rédigeons une fois, nous mettons à jour au fil du projet, et le client consulte toujours la version actuelle. Plus de « je vous envoie le PDF à jour », plus de versions multiples circulant par mail. Une seule source, vivante, au même endroit que l'outil.
Beaucoup de documentations souffrent moins d'un problème de contenu que d'un problème de localisation. En installant la mémoire du projet à l'intérieur de l'outil qu'elle décrit, on supprime ce problème d'un coup — et le jour où l'héritier arrive, il trouve la documentation là où il regarde naturellement.
Ce que l'intégrateur doit porter
On pourrait imaginer que l'intégrateur, détenteur de la mémoire technique, suffit à lui seul à garantir la continuité. C'est une fausse sécurité. Le cabinet d'intégration vit lui aussi du mouvement de ses équipes. Le consultant qui a cadré la solution il y a quatre ans n'est peut-être plus dans la maison. Celui qui a développé le module spécifique sert d'autres clients aujourd'hui. Même celui qui assure le support courant ne détient qu'un fragment de l'histoire.
La mémoire d'un projet ERP ne peut reposer ni sur les personnes du côté client, ni sur les personnes du côté intégrateur. Elle doit reposer sur un écrit partagé, validé par les deux parties, entretenu sur la durée. Cet écrit est le socle de la continuité — tout le reste est circonstanciel.
Documenter le projet d'un client est, pour un intégrateur, une forme d'autoprotection légitime. Contre les remises en cause infondées. Contre les procès d'intention au changement d'interlocuteur. Contre la tentation du successeur trop pressé d'effacer l'existant. Mais cette protection ne fonctionne qu'à une condition stricte : ne jamais utiliser la documentation comme parapluie. Un document produit pour se couvrir ne couvre personne. Il abîme la relation au lieu de la consolider.
Pour le client, c'est une assurance d'un autre ordre. Contre la dépendance excessive à un prestataire unique. Contre l'évaporation du savoir interne lors de mouvements d'équipe. Contre les décisions impulsives d'un arrivant trop pressé de marquer son territoire.
Notre pratique chez Auguria
En théorie, la documentation utilisateur relève du client. C'est son outil, ce sont ses processus, c'est à lui d'en tenir la référence. En pratique, cela se fait rarement. Les équipes opérationnelles n'ont pas le temps, les priorités courantes écrasent les chantiers de fond, et le document promis dans le cadrage reste le plus souvent à l'état de promesse. Nous avons cessé d'en vouloir à nos clients pour cela — c'est une constante.
Sur les projets que nous accompagnons, nous produisons donc de plus en plus systématiquement un guide utilisateur orienté métier. D'abord pour notre propre usage. Quand nos équipes tournent, quand un consultant prend la suite d'un dossier, quand un ticket de support demande de retrouver le contexte d'une adaptation, la documentation nous permet de rester cohérents sur la durée sans dépendre de mémoires individuelles. C'est un outil de travail interne avant d'être un livrable.
Nous avons observé, au fil des années, que ce document écrit pour nous devient naturellement utile au client. Partagé, il circule. Lu, il rassure les successeurs, aide les équipes à s'approprier l'outil, prépare les montées de version. Dans plusieurs projets, il est devenu un repère commun — et parfois, l'élément qui a évité une rupture au moment d'un changement d'interlocuteur.
Nous n'en faisons pas une règle. Ce n'est pas toujours nécessaire, ni toujours attendu. Mais quand le contexte l'impose — migration de version majeure, reprise d'un projet existant, changement d'équipe anticipé — nous le proposons. En gardant à l'esprit ce qu'il implique : être lu, être utile, être contesté. Jamais servir à se défausser.
Un ERP n'appartient pas au décideur qui l'a commandé. Pas au chef de projet qui l'a livré. Pas à l'intégrateur qui l'a construit. Il appartient à l'entreprise, sur le long terme — et à la succession de ceux qui en hériteront. La documentation, la bonne, celle qui est juste, est ce qui permet à cet héritage de se transmettre sans se perdre. Pas comme un bouclier. Comme un relais.
Un projet qui se transmet traverse plusieurs générations de responsables. Un projet qui ne se transmet pas peut s'effondrer à la première succession. Entre les deux, il y a le geste documentaire juste — ni trop, ni trop peu, toujours orienté vers celui qui lira après nous.
À propos de ce texte — Cet article s'appuie sur l'expérience accumulée par Auguria sur les projets Odoo. Si vous héritez d'un ERP dont l'historique vous échappe, préparez une montée de version, ou anticipez un changement d'équipe projet, nous sommes disponibles pour en discuter avec vous.