1. Pourquoi activer le multi-société dès le départ

Odoo 19 supporte le multi-société de façon native, en édition Community comme en Enterprise. Une base Odoo peut héberger plusieurs sociétés indépendantes — chacune avec son nom légal, son adresse, sa devise comptable, son pays de référence, son logo, son numéro de TVA. Chaque société possède son propre plan comptable, ses propres séquences de numérotation, ses propres taxes par défaut.

Côté ergonomie, l'utilisateur final voit toujours une seule société active à la fois. Il bascule de l'une à l'autre via un menu déroulant en haut à droite — le switcher topbar. Côté données, les enregistrements métier (factures, commandes, ordres de fabrication, contrats) portent un champ company_id qui les rattache à une et une seule société. Le filtrage est automatique : un utilisateur dont la société active est Démo SARL Algérie ne voit que les factures de Démo SARL Algérie, jamais celles d'Démo SARL France ou de Démo SARL Holding. Ce filtrage automatique vaut pour tous les flux métier — voir par exemple Les ventes dans Odoo 19 ou Facturation et paiements dans Odoo 19, où le champ company_id joue le même rôle de cloison.

Trois cas typiques justifient le multi-société :

• Holding et filiales — une société mère détient une ou plusieurs filiales opérationnelles. Chaque filiale a son plan comptable, sa fiscalité, sa devise. La consolidation comptable se fait hors d'Odoo CE (réservée à l'édition Enterprise et à des modules tiers).
• Multi-marques — une même équipe gère deux ou trois marques commerciales distinctes, chacune avec sa propre image, ses propres factures, son propre site web. Le multi-société isole proprement les communications client par marque.
• Cabinet de gestion — un consultant pilote la comptabilité de plusieurs PME dans une seule base. Chaque dossier client = une société.

Pour cette série, l'exemple file rouge est une PME du Maghreb qui se structure en groupe : une holding marocaine, une filiale opérationnelle marocaine, et une société sœur algérienne avec une devise différente. La base démo de référence contient déjà une société historique (Démo SARL France) — elle reste en place et servira de point de comparaison.

Cet article suppose qu'Odoo 19 CE est installé et fonctionnel. Si l'environnement n'est pas encore prêt, voir l'article Prise en main d'Odoo 19 — interface, vues et paramétrage qui pose les bases avant toute configuration avancée.

2. Premier réflexe — activer le mode développeur

Avant toute opération d'administration sérieuse, l'admin active le mode développeur. Sans lui, certains champs techniques restent invisibles, certaines actions de configuration n'apparaissent pas dans les menus, et le diagnostic en cas d'erreur devient pénible. Ce mode est une recommandation universelle pour tout article de cette série.

Le chemin est : Paramètres → Activer le mode développeur (lien tout en bas de la page Paramètres généraux). Une fois actif, un petit bug-icon apparaît dans la topbar à droite — c'est l'indicateur visuel que le mode est en route.

Le menu d'administration des sociétés est désormais accessible sans détour : Paramètres → Utilisateurs & Sociétés → Sociétés. C'est de là que tout part.

3. Créer une 2^e société — les champs qui comptent vraiment

Le bouton Nouveau en haut de la liste des sociétés ouvre un formulaire compact. Il y a une dizaine de champs visibles, mais cinq seulement structurent la suite. Ce sont les champs à renseigner avec soin dès la création — les autres se règlent plus tard sans douleur.

Nom de la société (name) — c'est aussi le nom du partner Odoo lié à la société (champ partner_id en arrière-plan, créé automatiquement). Conseil de nommage : choisir un nom qui se distingue clairement dans une liste — éviter les sigles trop génériques (« Société 1 », « Filiale ») au profit d'un nom commercial parlant (« Démo SARL Holding », « Démo SARL Algérie »).

Adresse complète (rue, ville, code postal, pays) — apparaît sur les factures, devis, bons de commande émis par cette société. Le pays détermine indirectement plusieurs choses : la localisation comptable proposée à l'install, le format d'adresse, les libellés fiscaux par défaut (TVA, ICE pour le Maroc, NIF pour la France, etc.).

Devise (currency_id) — c'est la décision irréversible. La devise de la société est utilisée pour le plan comptable, les rapports financiers, les valorisations de stock. Une fois que des écritures comptables sont passées dans cette devise, la changer est un chantier majeur (re-livraison du plan comptable, conversion des soldes). Choisir avec attention.

E-mail et téléphone — apparaissent sur les documents émis et sur les notifications automatiques. Utiliser une adresse e-mail générique par société (contact@demo-sarl.dz), pas une adresse personnelle.

Site web (optionnel) — si la société publie un site Odoo Website distinct (multi-website), c'est le champ qui le rattache. En CE sans multi-website, à laisser vide.

4. Hiérarchie parent / filiale — la règle de la devise

Le modèle res.company expose deux champs de hiérarchie en v19 :

• parent_id — Many2one vers une autre res.company. Désigne la société mère.
• child_ids — One2many vers les sociétés filles (champ libellé Branches dans l'interface).

Pour faire d'une société la filiale d'une autre, il suffit de renseigner le champ parent_id de la filiale avec la référence à la société mère. La hiérarchie devient alors visible dans la liste, dans le formulaire de chaque société (onglet Branches), et dans le switcher topbar qui affiche les filiales en retrait sous leur parent.

Mais — et c'est la règle d'or v19 — une filiale doit avoir la même devise que sa société mère. Tenter de rattacher une filiale en DZD à une mère en MAD provoque cette erreur :

The Currency of a subsidiary must be the same as it's root company.

La raison technique est solide : la consolidation des écritures comptables ne peut se faire qu'en une devise commune dans la branche. Si une vraie séparation de devise est nécessaire (mère marocaine MAD, fille algérienne DZD), il faut renoncer à la hiérarchie et créer les deux sociétés en sœurs indépendantes, sans relation parent/enfant.

Concrètement, le plan de structuration ressemble à ceci :

• Démo SARL Holding (Maroc, MAD) — société mère.
• Démo SARL Maroc (Maroc, MAD, parent_id = Démo SARL Holding) — filiale opérationnelle marocaine. Devise identique à la mère ✅.
• Démo SARL Algérie (Algérie, DZD, pas de parent_id) — société sœur, devise différente. Séparée hiérarchiquement.

Pour des séparations internes à une même société (par département, par mission, par centre de coût), ce n'est pas le multi-société qu'il faut activer mais la comptabilité analytique avec ses plans analytiques. Multi-société = plusieurs entités juridiques. Analytique = plusieurs axes de lecture à l'intérieur d'une seule entité.

5. Le switcher topbar — basculer entre sociétés

Une fois plusieurs sociétés créées et au moins un utilisateur affecté à plus d'une (voir section 6), un petit menu déroulant apparaît dans la barre supérieure d'Odoo, à droite du nom d'utilisateur. C'est le switcher multi-société. Sans lui, l'utilisateur ne se rendrait même pas compte qu'il existe d'autres sociétés.

Le switcher affiche la liste des sociétés autorisées pour l'utilisateur connecté, avec :

• Une case à cocher par société — coche = société active, données filtrées sur celle-ci.
• Une indentation visuelle pour les filiales — la filiale s'affiche en retrait sous sa mère.
• La société par défaut (company_id) est cochée à la connexion. L'utilisateur peut cocher d'autres sociétés pour travailler en multi-société simultané.

Cocher plusieurs sociétés en même temps active un mode appelé multi-company simultané : l'utilisateur voit alors les données des sociétés cochées dans une vue agrégée. Utile pour un dirigeant qui pilote toutes les entités du groupe et veut un tableau de bord consolidé. Attention cependant : créer un enregistrement nouveau dans ce mode rattache l'objet à la première société cochée, ce qui peut surprendre. La règle prudente est de basculer sur une seule société pour la saisie, et d'activer le multi-coché uniquement pour la lecture.

6. Affecter un utilisateur à plusieurs sociétés — company_id vs company_ids

Le modèle res.users expose deux champs distincts pour la gestion multi-société :

• company_id (Many2one) — la société active par défaut à la connexion. C'est celle qui sera cochée dans le switcher. Une seule valeur.
• company_ids (Many2many) — l'ensemble des sociétés autorisées pour cet utilisateur. C'est la liste qui apparaît dans le switcher. Plusieurs valeurs possibles.

La contrainte v19 imposée par le code est nette : company_id doit toujours faire partie de company_ids. Sinon Odoo lève une erreur de validation au write :

The chosen company is not in the allowed companies for this user

Concrètement, sur le formulaire utilisateur (Paramètres → Utilisateurs & Sociétés → Utilisateurs) :

• Le champ Sociétés (company_ids) accepte plusieurs tags. C'est là qu'on coche toutes les sociétés que l'utilisateur a le droit de voir.
• Le champ Société par défaut (company_id) est un Many2one classique. C'est la société sélectionnée à l'ouverture de session.

Trois profils types d'affectation existent en pratique :

• Utilisateur opérationnel monosociété — company_ids = [société-X]. Le switcher ne lui apparaît pas. Il travaille comme avant l'activation du multi-société. C'est le profil par défaut à conserver pour les utilisateurs métier qui n'ont aucune raison de voir les autres sociétés.
• Manager bi-société — company_ids = [filiale-1, filiale-2], company_id = filiale-1. Le switcher apparaît avec deux entrées. Profil typique du responsable RH ou comptable qui gère deux entités.
• Dirigeant du groupe — company_ids = [toutes], company_id = société-mère. Vue complète, tableau de bord consolidé en multi-coché. À réserver à un cercle restreint.

7. Pièges & bonnes pratiques v19

• Devise société = devise plan comptable. Changer la devise après écritures = chantier majeur. Décider à la création.
• Filiale = même devise que parent. Sinon, créer en sociétés sœurs sans hiérarchie.
• Contrainte company_id ∈ company_ids sur l'utilisateur. La société active doit appartenir à la liste autorisée.
• Mode multi-coché ≠ mode de saisie. Cocher plusieurs sociétés en même temps est confortable pour lire et consolider, mais piège à la création de nouveaux enregistrements (rattachement à la 1^re cochée).
• Branches affichées repliées dans la liste des sociétés (vue v19). Les filiales apparaissent comme tags sous leur parent, pas comme lignes séparées — surprenant la première fois, propre une fois compris.
• « Tout admin partout » = anti-pattern. Affecter company_ids au strict besoin du rôle, jamais à toutes les sociétés par défaut.

Aller plus loin

Ce qui n'a pas été traité ici et qui mérite un approfondissement dédié :

• La matrice ACL fine par société et par app (qui voit quoi, qui modifie quoi, qui valide quoi).
• Les règles de partage (record rules) complexes inter-sociétés — partage de contacts, de produits, de catalogues.
• La consolidation comptable (multi-société agrégée) — réservée à l'édition Enterprise et à des modules tiers en CE.
• Les valeurs dépendantes de la société sur les champs métier, qui permettent à un même produit d'avoir un prix différent selon la société active sans dupliquer la fiche.
• Les intercompany rules qui propagent une commande d'une société à l'autre (Enterprise).

Ces sujets sont approfondis dans les articles suivants de cette série S12 — utilisateurs et droits d'accès (ADM2), plan comptable par société (ADM3), modèles de rapports et format d'impression (ADM4).