Une entreprise en croissance crée une seconde entité juridique dans Odoo, filiale, coentreprise ou simple immatriculation pour un nouveau marché, et en quelques jours, un dysfonctionnement apparaît sans qu’aucun utilisateur n’y ait touché. Un collaborateur met à jour les coordonnées bancaires d’un fournisseur, et cette modification se retrouve mystérieusement sur une facture émise par une autre société du groupe. Une commande passée sous une entité atterrit dans la file d’approbation d’une autre. Rien n’a été mal configuré. Le code personnalisé n’a simplement jamais été conçu pour gérer le cas où « société » pouvait désigner autre chose qu’une seule entité.
Pourquoi le code mono-société craque en premier
La plupart des modules Odoo sur mesure naissent dans un contexte mono-société, parce que c’est la seule réalité que connaît le client au départ. Les développeurs ajoutent des champs, surchargent les méthodes create et write, et construisent des logiques de récupération de données sans appliquer de filtre sur company_id, après tout, il n’y a qu’une seule société, et tout semble fonctionner. Les applications standard d’Odoo (ventes, achats, comptabilité) intègrent bien des règles de gestion multi-sociétés, mais les modules personnalisés ne les héritent pas automatiquement. Dès qu’une seconde société est créée dans la base, chaque lecture ou écriture non filtrée devient une fuite silencieuse entre entités : coordonnées bancaires partagées à tort, budgets ou commandes qui s’affichent sous la mauvaise société, fiches partenaires ou produits qui héritent de valeurs destinées à une autre entité du groupe.
La solution : corriger, pas tout réécrire
Bonne nouvelle : il est rarement nécessaire de tout reprendre de zéro. La correction consiste à ajouter les filtres company_id et les règles de gestion là où ils manquent : les champs hérités doivent être associés à des domaines explicitement liés à une société, les requêtes de recherche doivent intégrer un filtre société au lieu de s’appuyer sur le contexte par défaut, et chaque modèle personnalisé doit disposer de ses propres règles multi-sociétés, au-delà des règles standard. La difficulté réside dans l’identification exhaustive des lacunes, car le bug ne se manifeste qu’une fois que des données multi-sociétés réelles existent, et à ce stade, le client exploite déjà deux entités sur la même instance.
Notre position
Ce scénario est si fréquent qu’il mérite d’être anticipé dès la conception : tout développement Odoo sur mesure devrait partir du principe qu’une seconde société finira par arriver, même si le client est convaincu du contraire. Un audit rapide des logiques personnalisées avant le lancement d’une nouvelle entité coûte bien moins cher que le nettoyage de données déjà mélangées entre sociétés. Si votre équipe s’apprête à ajouter une entité juridique à une instance Odoo existante, c’est précisément ce type de problème à aborder avec Majorbird avant qu’il ne se manifeste de lui-même.