Projet ERP Odoo : commencer par l'architecture SI, pas par l'outil

« On part sur Odoo. » La décision tombe souvent en réunion, avant qu'un seul processus n'ait été posé à plat : l'outil est choisi, le besoin suivra.

Sur un site unique et cinq utilisateurs, le raccourci passe parfois. Sur plusieurs agences, un serveur multisite et des dizaines d'utilisateurs, c'est exactement là que les projets déraillent. Ma conviction tient en une phrase : Odoo n'est pas un point de départ, c'est une réponse — et cette réponse ne vaut que si vous avez cadré votre système d'information avant de la choisir.

Voici les trois phases d'architecture SI à mener en amont, avant d'installer quoi que ce soit.

Odoo n'est pas un point de départ, c'est un choix de phase 3

Quand une organisation décide « on prend Odoo » avant d'avoir formulé son besoin, elle répond à une question qu'elle n'a pas posée.
C'est le renversement le plus courant des projets ERP : on part du moyen, puis on tord le métier pour qu'il entre dedans.

Les trois niveaux qu'on confond : entreprise, SI, logiciel

Parler d'« architecture » à propos d'Odoo entretient une ambiguïté, parce que le mot recouvre trois niveaux distincts. Les confondre, c'est sauter l'amont sans même s'en apercevoir.

La phase amont se joue au niveau du milieu : le système d'information. Ni la stratégie de l'entreprise, ni la conception interne du logiciel — l'orchestration des applications et des données entre elles.

Sur un projet d'intégration, cette structure interne vous est même donnée : Odoo l'impose, vous l'exploitez sans la refaire. Votre travail amont est un cran au-dessus — décider comment Odoo s'insère dans votre SI, pas comment Odoo est fait.

Faire l'amont, c'est trois phases avant l'outil

La conception d'une architecture SI suit une séquence ordonnée. Elle transpose une démarche éprouvée — le cycle ADM du cadre TOGAF — calibrée ici pour une organisation de taille modeste. L'essentiel tient dans un constat : Odoo n'apparaît qu'en phase 3.

Les trois premières — P0, P1, P2 — forment l'amont. Ce sont elles qui décident si Odoo est la bonne réponse, et sous quelle forme. Détaillons-les.

P0 — Cadrer le besoin métier, les principes et les exigences

Le cadrage recense ce que l'entreprise doit savoir faire, indépendamment de tout outil : ses capacités métier, ses parties prenantes, ses contraintes.
Il pose aussi des principes directeurs — par exemple « réutiliser avant d'acheter, acheter avant de développer » — et des exigences non fonctionnelles : volumétrie, disponibilité, sécurité, performance.

C'est également ici qu'un arbitrage souvent repoussé doit être tranché : le périmètre entre Odoo Community et Enterprise. Certaines capacités — comptabilité avancée, personnalisation via Studio, applications mobiles officielles — relèvent de l'édition Enterprise et de son abonnement. Le décider en P0, c'est éviter de le découvrir en plein déploiement.

P1 — Cartographier l'existant : l'état des lieux

On ne conçoit pas dans le vide. L'état des lieux dresse la carte de l'existant : quels processus tournent aujourd'hui, sur quels outils, avec quelles données, sur quelle infrastructure.
C'est un travail ingrat et révélateur. Sur plusieurs entités, il met au jour des processus qui divergent d'une structure à l'autre, des modèles de documents propres à chacune, et autant de façons de remonter l'information à la maison mère.

Une petite structure peut se contenter d'un état des lieux léger — j'en donne un exemple dans l'architecture SI d'un bureau d'études BTP sans ERP. Plus il y a de sites et d'utilisateurs, plus cette cartographie devient le socle de tout le reste.

P2 — Dessiner la cible : quatre domaines, sécurité comprise

La cible décrit le système visé, décomposé en quatre domaines. C'est le moment où l'on situe Odoo — non comme le tout, mais comme une brique de la couche applicative.

La sécurité ne se traite pas dans un cinquième domaine ajouté à la fin : elle traverse les quatre. Droits métier, confidentialité des données entre agences, cloisonnement applicatif, durcissement du serveur — tout cela se conçoit dès la cible, pas après la mise en production.

Le cas d'une entreprise multisite : ce que l'amont change vraiment

Prenons un projet que je cadre pour cette année : une entreprise de construction organisée en plusieurs entités juridiques distinctes, réparties entre les DOM-TOM et l'étranger, chapeautées par une maison mère.
Aujourd'hui, chaque structure a ses propres processus, ses propres modèles de documents et sa propre façon de remonter l'information à la maison mère. Le réflexe serait d'installer un Odoo par entité et de laisser chacune reproduire ses habitudes. C'est exactement ce que l'amont interdit — parce que le vrai sujet n'est pas d'outiller chaque agence, c'est de les faire converger.

Arbitrage 1 — Une société Odoo par entité, strictement cloisonnée

Des entités juridiques distinctes imposent une structure multi-company : une société Odoo par entité, avec sa comptabilité, sa devise et sa localisation fiscale propres.
Le cloisonnement est natif — Odoo isole les données au niveau de l'ORM, si bien qu'un utilisateur rattaché à une entité ne voit que ses enregistrements. Chaque entité garde son entrepôt, ses clients et fournisseurs, et ses séquences de numérotation, préfixées par entité pour la traçabilité légale. Réparties sur plusieurs territoires, elles tournent chacune dans leur devise et sur leur plan comptable local.

Arbitrage 2 — Le vrai point dur : un socle commun sans casser l'autonomie

Le cloisonnement réglé, reste la question qui décide de la réussite : faire fonctionner toutes les entités de la même manière sans nier leurs spécificités locales.
Aujourd'hui, chacune a forgé ses propres processus et communique à sa façon avec la maison mère. Installer Odoo sans trancher cela graverait ces divergences dans l'outil. L'amont consiste au contraire à définir un socle commun — imposé à tous — et à délimiter ce qui reste légitimement local.

Ce partage n'est pas un réglage Odoo : c'est une décision d'architecture métier, prise avant la première configuration. C'est elle qui transforme des habitudes divergentes en un modèle unique — et c'est le cœur du travail amont sur ce projet.

Arbitrage 3 — La remontée vers la maison mère : consolider, pas ressaisir

La maison mère doit lire le groupe. Aujourd'hui, elle reçoit des tableaux hétérogènes, un par entité, retravaillés à la main.
La cible : la consolidation native d'Odoo — un module de l'édition Enterprise — qui agrège les comptes des entités, gère leurs devises différentes et élimine les écritures internes au groupe. Mais elle ne produit un résultat propre qu'à une condition : un plan analytique et un mapping de comptes communs. Autrement dit, l'Arbitrage 2 conditionne l'Arbitrage 3. L'ordre n'est pas négociable — le socle commun d'abord, la consolidation ensuite — et c'est typiquement ce que l'amont révèle, là où l'installation directe fonce dans le mur.

De l'analyse d'écart à la trajectoire : par où Odoo démarre

Entre l'existant — des entités aux processus divergents — et la cible — un socle commun, des entités cloisonnées, une remontée consolidée —, l'écart se mesure entité par entité. C'est lui qui produit la trajectoire, par paliers.

Le premier palier ne bascule pas tout Odoo d'un coup : il fige le socle commun — processus, plan analytique, mapping de consolidation — sur une entité pilote, avant de le décliner sur les autres. Les spécificités locales s'ajoutent ensuite, dans un cadre déjà posé. C'est l'inverse exact du réflexe « on installe une agence, on verra pour les autres ».

L'erreur classique : configurer d'abord, cadrer ensuite

Le piège le plus fréquent ne demande aucune mauvaise volonté : on ouvre Odoo, on active les modules par défaut, et on découvre après coup que le modèle standard ne colle pas au fonctionnement multi-agences. La dette est immédiate.

Ce constat n'a rien d'anecdotique : plusieurs études convergent, plus de 70 % des échecs ERP tiennent à des facteurs humains et organisationnels, pas à la technique. J'en détaille les ressorts dans pourquoi les projets ERP échouent.
À l'inverse, tout ceci se borne : sur un site unique avec un périmètre simple, un cadrage léger suffit. C'est dès qu'il y a plusieurs sites, plusieurs métiers ou beaucoup d'utilisateurs que l'amont complet devient non négociable.

Ce qu'il faut retenir

On ne commence pas un projet par Odoo : on y arrive. Les trois phases amont — cadrer le besoin, cartographier l'existant, dessiner la cible — transforment le choix d'Odoo d'un pari en une décision défendable, alignée sur votre métier et vos données.
Sur un projet multisite, c'est l'architecture SI en amont, et elle seule, qui évite la reprise coûteuse six mois plus tard.
Une fois l'outil en place, reste l'échelle du dessous : la façon dont chacun organise ses tâches au jour le jour, que j'aborde dans la méthode GTD appliquée dans Odoo.

La méthode générique complète — phases, normes et sélection d'outils — est détaillée dans le livre blanc ci-dessous ; cet article en est l'application à un projet Odoo. Si vous lancez un ERP cette année, surtout multi-agences, le moment de cadrer l'architecture, c'est maintenant.