« On a plusieurs sociétés, on va activer le multi-sociétés dans Odoo. » C'est une phrase qu'on entend à peu près une fois par mois en mission. Souvent, c'est la bonne décision. Parfois, c'est une erreur qui coûte cher pendant trois ans.
Le multi-sociétés Odoo est un outil puissant. C'est aussi un commitment d'architecture qui change la nature du paramétrage, qui impose des règles de séparation strictes, et qui force des choix de licence côté Odoo Online. Avant de l'activer, il faut savoir ce qu'on signe.
Cet article fait le tour de ce qu'on a appris à force d'en déployer chez Nexelans et Sudokeys, sur des PME et ETI françaises, parfois avec des entités en Espagne ou en Italie.
Avant de basculer : les alternatives moins coûteuses
La première question à se poser n'est pas « comment configure-t-on le multi-sociétés ? ». C'est « a-t-on vraiment besoin du multi-sociétés ? ».
Trois alternatives méritent d'être envisagées avant.
La comptabilité analytique permet de séparer des activités qui partagent une même entité juridique. Si vous avez une seule société avec deux marques commerciales, ou deux activités distinctes en compta interne, l'analytique fait souvent l'affaire sans complication architecturale. Vous gardez un seul plan comptable, un seul journal, et vous pilotez la séparation par tags analytiques.
Les entrepôts multiples permettent de gérer plusieurs sites physiques sans créer plusieurs sociétés. Une PME avec trois sites dans des départements différents n'a pas besoin de trois sociétés Odoo si l'entité juridique est unique. Elle a besoin de trois entrepôts dans Odoo, chacun avec ses règles de réapprovisionnement et ses emplacements.
Les branches sont une fonctionnalité Odoo qui permet de créer des subdivisions sous une société parente, avec des paramétrages spécifiques par branche (logo, adresse, listes de prix) tout en partageant la comptabilité de la société parente. C'est utile pour les bureaux régionaux ou les divisions internes. La documentation Odoo est explicite sur le point suivant : une branche ne peut pas être convertie en société parente plus tard. Si l'entité que vous créez peut un jour devoir avoir son propre plan comptable, c'est une société qu'il vous faut, pas une branche.
Si aucune de ces alternatives ne couvre votre besoin, vous êtes dans un vrai cas multi-sociétés.
Le coût caché du multi-sociétés
Avant le paramétrage, un point qui surprend souvent : activer le multi-sociétés sur Odoo Online en plan Standard déclenche automatiquement un upsell vers le plan Custom. Pour un contrat annuel, un bon de commande d'upgrade est créé avec une limite de trente jours. Pour un contrat mensuel, l'abonnement bascule directement sur le tarif Custom à la prochaine facture. La documentation Odoo le précise noir sur blanc, mais beaucoup de clients le découvrent sur la première facture après bascule.
Ça change le calcul économique. Sur le papier, gérer deux entités sur la même base Odoo paraît plus économique que de payer deux licences séparées. Avec l'upsell automatique, l'écart se réduit. Sur Odoo.sh ou en on-premise, le sujet ne se pose pas, mais la complexité de paramétrage compense souvent la flexibilité gagnée.
Notre conseil : avant de basculer, faire un calcul TCO sur trois ans qui inclut le passage en plan Custom, le temps d'audit et de paramétrage, et le coût de maintenance. Pour deux entités, le multi-sociétés est généralement gagnant. Pour cinq entités, c'est presque toujours gagnant. Pour trois ou quatre, ça dépend.
L'architecture côté société et utilisateurs
Une fois la décision prise, la création de société se fait dans Settings ‣ Companies ‣ Manage Companies. On renseigne le nom, l'adresse, l'identifiant fiscal, le SIREN si applicable, le logo. Pour chaque société, on configurera ensuite ses propres journaux comptables, ses propres séquences de facturation et son propre plan comptable.
Côté utilisateurs, chaque utilisateur Odoo a deux notions distinctes qui prêtent à confusion. Le champ « Allowed Companies » liste les sociétés auxquelles l'utilisateur a accès en lecture. Le champ « Default Company » fixe la société qui est active à la connexion. Et le sélecteur de société en haut à droite de l'écran permet à l'utilisateur de cocher plusieurs sociétés actives en même temps, ce qui est stocké dans le contexte ORM sous allowed_company_ids. Un utilisateur connecté à plusieurs sociétés simultanément peut créer un devis dans la société A et y ajouter un produit propre à la société B, ce qui fait remonter une erreur de cohérence à l'enregistrement.
Sur ce point, un piège classique : l'utilisateur administrateur ignore par défaut toutes les règles multi-sociétés. Concrètement, ça veut dire que si l'admin crée des données pendant le paramétrage initial, ces données peuvent ne plus être lisibles par les utilisateurs réels une fois les règles activées. La règle qu'on applique sur les missions Nexelans est simple : pendant l'implémentation, on crée un utilisateur dédié au paramétrage avec les bons droits multi-sociétés, et on évite de faire des opérations métier en tant qu'admin.
Partager ou cloisonner : où placer le curseur
Le champ company_id sur les enregistrements détermine ce qui est partagé et ce qui est cloisonné.
Un produit avec company_id vide est partagé entre toutes les sociétés. Un produit avec company_id rempli est restreint à une société. La même logique s'applique aux contacts, aux entrepôts, aux taxes, aux plans comptables.
En pratique, les choix qu'il faut faire en amont sont les suivants. Les produits sont presque toujours partagés, car maintenir un catalogue dupliqué crée plus de problèmes qu'il n'en résout. Les contacts sont en général partagés aussi, mais avec des notes spécifiques par société sur les fiches partenaires. Les plans comptables sont systématiquement cloisonnés, parce que chaque entité juridique a sa propre comptabilité. Les journaux et séquences sont cloisonnés. Les entrepôts sont cloisonnés en multi-pays mais peuvent être partagés en multi-établissement domestique.
Un point peu connu : certains champs sont marqués company_dependent. Le coût d'un produit, par exemple, peut prendre des valeurs différentes selon la société active. C'est utile en multi-pays, où les coûts d'achat varient avec la devise et les taxes locales. C'est piégeux en monopays, parce qu'on peut croire qu'on regarde la même donnée alors qu'on en regarde plusieurs versions selon le contexte.
Inter-company transactions : ce qui est automatisé
Quand deux sociétés de la même base font des transactions entre elles, Odoo peut les synchroniser automatiquement. C'est l'objet des inter-company transactions, qui se configurent dans Settings ‣ Users & Companies ‣ Companies, en sélectionnant la société et en activant l'onglet Inter-Company Transactions (parfois accessible uniquement en mode développeur selon les versions).
Quatre options principales sont disponibles. Create Sales Orders crée automatiquement un devis dans la société B quand un bon de commande est confirmé dans la société A. Create Purchase Orders fait l'inverse. Create Bills and Refunds crée une facture fournisseur dans la société B quand une facture client est postée dans la société A. Synchronize Stock Moves synchronise les mouvements de stock physiques entre les deux sociétés.
Chaque option peut être paramétrée en mode draft (le document est créé mais pas validé) ou en mode validated (il est créé et validé automatiquement). Pour les flux entre une société de holding et ses filiales, le mode validated fait gagner un temps considérable. Pour les flux où il y a une vérification métier nécessaire, le mode draft reste le bon choix.
Là où ça coince souvent : les transferts physiques entre entrepôts de sociétés différentes nécessitent des routes d'inventaire correctement configurées avec un emplacement Inter-company transit. Sans ça, le système renvoie une erreur du type « No rule has been found to replenish ... in 'Virtual Locations/Inter-company transit' ». C'est un sujet qu'on rencontre régulièrement quand on intègre les flux logistiques tardivement après avoir mis en place le multi-sociétés. Mieux vaut le traiter dès le paramétrage initial.
Multi-pays : ce qui change vraiment
Le multi-sociétés en multi-pays ajoute une couche. Chaque société a sa devise comptable, son plan comptable localisé (PCG français, Plan general contable espagnol, Codice civile italiano), ses taxes propres, ses obligations déclaratives propres.
Sur les missions en France-Espagne ou France-Italie, les sujets qui consomment du temps de paramétrage sont toujours les mêmes. Les plans comptables localisés, qui ne se chevauchent pas et imposent un travail de mapping pour les comptes inter-sociétés. Les positions fiscales, qui doivent être configurées pour chaque flux client et fournisseur cross-border et pour appliquer les bons taux de TVA. Les rapports légaux, qui sont propres à chaque pays et qu'il faut tester avant de basculer en production.
La devise est un sujet à part entière. Si la société A facture en euros et la société B facture en euros aussi, on est tranquille. Si une des deux est dans un pays hors zone euro (Royaume-Uni, Suisse, Pologne), il faut activer le multi-devise, configurer les comptes de gain et perte de change, et accepter que les états consolidés demandent un travail de conversion régulier.
Le reporting consolidé : ce qu'Odoo fait, ce qu'il ne fait pas
C'est la question qui revient toujours en fin d'audit : « est-ce qu'on peut faire de la consolidation comptable dans Odoo ? »
Réponse courte : Odoo permet de la consolidation simple, pas de la consolidation IFRS. La fonctionnalité Consolidation native de Odoo Enterprise permet de définir un mapping de comptes entre les sociétés filles et la société consolidante, de générer des états consolidés, et de gérer les retraitements basiques. Pour les groupes qui ont besoin d'une consolidation sous IFRS avec retraitements complexes, intercos massives, élimination des résultats internes, mise en équivalence et goodwill, Odoo seul ne suffit pas. Il faut soit un outil spécialisé en aval, soit un module développé sur mesure, soit un export vers une solution dédiée.
Pour des PME et ETI, la fonctionnalité native couvre l'essentiel des besoins. Pour des groupes cotés ou avec des contraintes IFRS strictes, le sujet est à expertiser au cas par cas.
Côté code Odoo cette semaine
Sur les dix derniers jours, deux commits du repo public odoo/odoo touchent directement le sujet du multi-sociétés.
Sécurisation des accès cross-company sur le calcul des taxes
Le 23 avril, Thomas Becquevort a poussé un correctif sur le module account pour empêcher un accès cross-company sur les taxes lors du calcul des taxes par ligne commit c3b9590f. Ce type de bug est exactement ce qui rend les configurations multi-sociétés fragiles : un utilisateur connecté à plusieurs sociétés peut, dans certains cas tordus, voir Odoo aller chercher une taxe d'une autre société pour calculer la sienne. Le résultat est une ligne avec un montant correct affiché, mais une écriture comptable qui pointe sur un compte de la mauvaise société.
Pour les bases multi-sociétés en V19, ça vaut la peine de vérifier que la prochaine montée de version inclut ce correctif. Les bases qui ont eu des incohérences sur des écritures de TVA récentes peuvent avoir été touchées.
Bug sur les formules de tags TVA dans les rapports
Le 29 avril, un correctif sur les rapports comptables a corrigé un bug subtil. Quand on créait une nouvelle formule de tags TVA commençant par le signe - (qui en V19 et au-dessus signifie « négation du solde »), le tag se retrouvait avec ce - dans son nom au lieu d'être traité comme un opérateur, et le rapport calculait systématiquement zéro (commit 41ea636a.
En multi-sociétés, ce bug a une portée particulière, parce que chaque société a son propre rapport de TVA et que les tags peuvent avoir été personnalisés société par société. Si vous avez du zéro où vous attendez un solde sur l'une de vos sociétés en V19 ou V19.1, c'est un suspect sérieux.
Si vous avez un projet multi-sociétés à structurer ou si vous voulez auditer une configuration existante, on traite régulièrement ce type de sujet sur les missions Nexelans, en France comme en multi-pays. On en discute volontiers en visio.