TL;DR : quand deux entreprises travaillent sur le même projet, l'une finit par ouvrir un accès à l'autre. Un compte de plus, un mot de passe de plus, un outil qui n'est pas le sien : ça s'ouvre le premier jour et plus jamais ensuite. Quand les deux entreprises roulent Odoo, chacune le sien, la fédération renverse le geste. Les deux Odoo se jumellent une fois, puis la tâche que vous partagez apparaît chez votre partenaire, dans son Odoo à lui, et sa réponse revient dans le vôtre. Personne n'ouvre de compte nulle part. Ce qui voyage est une liste fermée : le nom, la description en texte, le jour d'échéance, la priorité, l'état, les messages et les petites pièces jointes. Ce qui ne voyage jamais l'est tout autant : vos heures, vos feuilles de temps, le dossier de votre client, vos notes internes. Le module est publié sous LGPL-3.
Dans cet article
- Le compte qu'on ouvre au partenaire, et que personne n'ouvre : un accès portail est gratuit et natif, mais un outil qui n'est pas le sien ne devient jamais une habitude.
- Fédérer, ça veut dire quoi au juste? : trois propriétés, chacun garde son système, les deux parlent un protocole convenu, et l'échange est borné d'avance.
- La fédération n'est pas une idée de laboratoire : ActivityPub au W3C, Matrix dans l'administration française et l'armée allemande, Open Cloud Mesh en normalisation à l'IETF.
- Deux Odoo qui se font confiance : le module nomme le lien de confiance entre deux Odoo, pas la copie de la tâche qui l'emprunte.
- Ce qui traverse, et ce qui ne traverse jamais : une liste fermée dans les deux sens, d'où les heures, les feuilles de temps et le dossier client sont exclus.
- L'état se retourne en chemin : « Attente - Client » chez vous devient « En cours » chez lui, et son « Terminé » vous rend la tâche.
- Partager une tâche, c'est communiquer à un tiers : la liste fermée protège le dossier de votre client, pas le nom que vous donnez à la tâche.
- Le cadenas qui garde une phrase chez vous : un message qui commence par 🔒 ou [privé] reste chez son auteur, et la règle joue dans les deux sens.
- Ce que votre partenaire voit de votre maison : les tâches reçues vivent dans un projet fermé, sans dossier client, invisible des clients de votre partenaire.
- Quand l'autre bout ne répond pas : chaque envoi est rejoué pendant quatorze jours, et retirer un partage archive le miroir au lieu de l'effacer.
- Le jumelage se fait une fois, entre administrateurs : un code d'invitation de 48 heures, deux moitiés de secret, puis chaque message signé et horodaté.
- Ce que ça ne résout pas : les deux côtés doivent rouler Odoo 18, l'historique d'avant le partage ne voyage pas, les heures jamais.
- Les autres façons de faire : ce que règlent vraiment le partage natif, les sièges d'invités des suites en ligne et les cadres de l'OCA.
- Notre position : publié sous LGPL-3, facturé à l'hébergement et au soutien, jamais au droit d'usage.
Un mandat qui se joue à deux entreprises, c'est la règle plus que l'exception : un sous-traitant qui porte la moitié des livrables, un comptable externe qui attend trois réponses, un client qui a lui aussi une équipe et un système. Le travail est commun, les outils ne le sont pas. Et la question qui revient chaque fois est la même : où est-ce qu'on suit ça?
Il y a un cas où cette question a une réponse neuve : celui où les deux entreprises roulent Odoo, chacune sur son propre serveur ou hébergeur. C'est celui-là qu'on démonte ici.
Le compte qu'on ouvre au partenaire, et que personne n'ouvre
La réponse par défaut, c'est d'inviter l'autre chez soi. Odoo le fait nativement et gratuitement : on partage le projet, on ajoute la personne comme collaboratrice, et on choisit entre trois niveaux, « Lecture », « Édition avec accès limité » et « Édition ». La personne reçoit un courriel, se crée un mot de passe, et elle voit les tâches qu'elle suit. Techniquement, c'est réglé.
Humainement, c'est autre chose. Votre partenaire a déjà un endroit où il regarde sa journée le matin. Ce n'est pas votre écran. Lui demander d'ajouter une deuxième fenêtre, c'est lui demander d'ajouter une deuxième habitude, et les habitudes ne se dédoublent pas sur demande. Le portail s'ouvre avec enthousiasme la première semaine, puis il devient le lien qu'on ne clique plus dans un courriel qu'on ne lit plus. Le travail, lui, retourne là où il a toujours été : dans les courriels, avec un fichier en pièce jointe et trois versions qui se croisent.
Et quand le partenaire a son propre système de gestion, le problème change de nature. Vous ne lui demandez plus un effort d'attention, vous lui demandez de sortir de son outil pour entrer dans le vôtre, sur un mandat qui n'est qu'une partie de sa semaine. Ça ne tient pas, et ça n'a pas à tenir.
Fédérer, ça veut dire quoi au juste?
Le mot circule beaucoup et se définit rarement. Un système fédéré tient sur trois propriétés, et il suffit qu'une seule manque pour que ce n'en soit plus un. Chaque partie garde son propre système, avec ses données, ses comptes et ses règles. Les deux parlent un protocole convenu d'avance, au lieu de partager une base de données. Et ce qui s'échange est défini d'avance : le reste ne sort pas.
L'exemple que tout le monde utilise vingt fois par jour sans le nommer, c'est le courriel. Votre fournisseur n'est pas celui de votre client, aucun des deux n'a ouvert de compte chez l'autre, et le message part quand même et arrive. Personne n'appelle ça de la fédération parce que ça fonctionne depuis quarante ans, mais c'est exactement ça.
Trois choses que la fédération n'est pas, et qui se confondent souvent avec elle. Ce n'est pas un espace partagé dans le nuage : il n'y a pas de troisième endroit où les deux parties déposeraient leurs affaires, il n'y a que deux endroits qui se parlent. Ce n'est pas une synchronisation totale : l'échange est borné, et la borne fait partie du contrat. Et ce n'est pas une passerelle propriétaire entre deux produits : c'est un protocole que les deux côtés implantent, ce qui veut dire qu'un troisième peut s'y joindre sans demander la permission à personne.
L'inverse de la fédération, c'est le silo. Une plateforme tient la salle, et les deux entreprises y sont invitées. Ça marche très bien jusqu'au jour où il faut partir, où les prix changent, ou où l'une des deux n'a pas le droit d'y mettre ses données.
La fédération n'est pas une idée de laboratoire
C'est le point qui surprend le plus : les endroits où la fédération tourne à grande échelle aujourd'hui sont des endroits sérieux, et souvent réglementés.
Le web social. ActivityPub est une norme du W3C depuis janvier 2018. C'est le protocole du fédivers, celui de Mastodon et de ses milliers de serveurs indépendants. En mars 2024, Meta a commencé à fédérer Threads avec ce même protocole. La nuance est instructive : la première mouture était partielle et à sens unique, les réponses venues d'ailleurs ne remontaient pas dans Threads. Une fédération se borne, et la borne se déclare. C'est une leçon de conception, pas un reproche.
La messagerie d'État. Le protocole Matrix porte Tchap, la messagerie de l'administration française, avec environ 350 000 comptes actifs. Il porte le BwMessenger de l'armée allemande, plus de 100 000 personnes. Il portera le TI-Messenger du système de santé allemand, à l'échelle de millions de citoyens. Dans les trois cas, l'argument est le même : chaque organisme tient son propre serveur, et les serveurs se parlent.
Les fichiers. Open Cloud Mesh est le protocole de serveur à serveur qui permet à un Nextcloud de partager un dossier avec un ownCloud ou un CERNbox, déployé depuis 2016. Il est en cours de normalisation à l'IETF, l'organisme qui a normalisé le courriel et le web.
Le point commun de ces trois mondes, c'est une situation que vous connaissez : personne n'accepte de confier ses données à la maison d'en face, et le travail commun doit quand même se faire. C'est exactement la position de deux PME qui partagent un mandat.
Deux Odoo qui se font confiance
C'est ce modèle qu'on a repris, à l'échelle d'un ERP. Le module s'appelle Fédération, le mot est emprunté au partage fédéré de Nextcloud, et l'objet qu'il nomme n'est pas la copie de la tâche : c'est le lien de confiance entre deux Odoo. Une fois ce lien établi, ce qui l'emprunte est un détail d'implantation. Aujourd'hui ce sont des tâches de projet, demain ce seront des comptes rendus de rencontre, et la route sera la même.
Concrètement, l'Atelier Vermeille et le Studio Boréal roulent chacun son Odoo, sur son propre serveur, avec ses propres clients dedans. Les deux administrateurs jumellent leurs instances une fois. Ensuite, l'Atelier Vermeille coche une case sur une tâche, « Fédérée avec Studio Boréal ». Deux minutes plus tard, la tâche existe dans l'Odoo du Studio Boréal, dans un projet du Studio Boréal, assignée à une personne du Studio Boréal, avec l'échéance et la description. Personne n'a créé de compte, personne n'a changé d'écran, et les deux entreprises continuent de travailler chacune dans la sienne.
La même tâche, vue de l'autre Odoo : son projet, son assigné, ses colonnes.
Ce qui traverse, et ce qui ne traverse jamais
La question qui suit immédiatement, c'est celle-là : qu'est-ce qu'il voit exactement? La réponse est une liste fermée, écrite à l'avance. Ce n'est pas « tout sauf ce qu'on aura pensé à cacher », c'est « rien sauf ce qui est nommé ici ».
| Ce qui traverse | Ce qui reste chez vous |
|---|---|
| Le nom de la tâche | Les heures allouées, consommées, restantes |
| La description, réduite en texte simple | Les feuilles de temps et la banque d'heures |
| Le jour d'échéance et la priorité | Le dossier client rattaché à la tâche |
| L'état d'avancement | Les étiquettes et le reste du projet |
| Les messages écrits dans « Envoyer un message » | Les notes internes, sauf si vous décidez d'envoyer les vôtres |
| Les pièces jointes sous un plafond que vous fixez | Les pièces jointes au-dessus du plafond : leur nom part, pas le fichier |
La colonne de droite mérite une phrase de plus. Les heures ne traversent pas, et ce n'est pas une limite technique : c'est une décision. Le temps que vous passez sur un mandat et ce que vous en facturez sont votre affaire, même quand le mandat est partagé. La même logique vaut pour le dossier client : votre partenaire voit une tâche, pas votre fiche de client, pas votre historique avec lui, pas le reste de votre portefeuille.
La description, elle, arrive en texte simple. Le gras, les couleurs et le balisage ne traversent pas : les puces deviennent des puces en texte, un lien devient son texte suivi de son adresse, une image devient la mention qu'il y avait une image. C'est moins joli et c'est voulu : du balisage qui voyage entre deux systèmes, c'est une porte d'entrée, pas une fonctionnalité.
L'état se retourne en chemin
Voici le détail qui a demandé le plus de réflexion, et c'est celui qui décide si l'outil est utilisable un mardi matin. Une tâche en « Attente - Client » chez vous veut dire : c'est à l'autre de jouer. Si elle arrivait chez lui avec la même étiquette, elle lui dirait exactement le contraire de ce qu'elle doit lui dire. Alors elle se retourne en chemin.
| Chez vous | Chez votre partenaire |
|---|---|
| Attente - Client | En cours, dans la colonne « À faire » |
| En cours | Attente - Externe, dans la colonne « En attente de… » |
| En cours, avec une note « la tâche vous revient » | Terminé |
La dernière ligne se lit de droite à gauche, et c'est la plus utile. Quand votre partenaire glisse sa carte dans « Terminé », il ne ferme pas votre tâche : il finit sa part. Chez vous, la tâche redevient active avec une note qui dit qu'elle vous revient. Personne ne clôt le dossier de quelqu'un d'autre, et rien ne disparaît d'un écran parce que l'autre a fini.
Même chose pour l'échéance : elle voyage dans les deux sens, en jour et pas en heure. Si votre partenaire repousse une date chez lui, elle suit chez vous avec une note. Si vous la déplacez, son miroir suit. Un seul côté bouge par passage, et quand les deux ont bougé, c'est celui qui a partagé la tâche qui l'emporte.
Partager une tâche, c'est communiquer à un tiers
Envoyer une tâche à une autre organisation, c'est une communication à un tiers, et ce genre de chose se règle en amont ou pas du tout. La liste fermée protège beaucoup : le dossier de votre client ne part pas, ses coordonnées non plus, votre historique non plus. Mais elle ne décide pas à votre place de ce que vous écrivez dans le nom de la tâche.
« Rappeler madame Tremblay au sujet de son retard de paiement » en dit plus long que ce que vous vouliez partager. Les obligations de la Loi 25 ne s'arrêtent pas à la frontière de votre serveur, et la règle simple est celle-ci : une tâche fédérée se nomme comme si elle allait être lue par quelqu'un d'autre, parce qu'elle va l'être. Le partage se décide d'ailleurs tâche par tâche, jamais projet par projet en bloc, précisément pour que ce choix reste un geste conscient.
Quatre questions à se poser avant de fédérer un premier projet :
- Est-ce que les noms de mes tâches sont écrits pour être lus par l'extérieur? Sinon, c'est le premier ménage à faire.
- Qui, chez le partenaire, reçoit ce que j'envoie? La fédération assigne à une personne nommée, pas à une file anonyme.
- Est-ce que je veux que mes notes internes partent aussi? La réponse par défaut est non, et elle se change côté par côté.
- Quels projets ont le droit d'être fédérés? Tant qu'un projet n'a pas nommé le partenaire, la case n'apparaît même pas sur ses tâches.
Le cadenas qui garde une phrase chez vous
Une conversation partagée avec un partenaire reste une conversation où on a parfois besoin de se parler entre soi. Un message ou une note qui commence par 🔒 ou par [privé] reste chez son auteur, et la règle joue dans les deux sens : ce qu'il marque ainsi ne vous parvient pas non plus.
Ça paraît anodin, c'est ce qui rend l'usage soutenable. Sans marqueur explicite, on hésite avant chaque phrase, on ouvre un canal parallèle « pour les vraies affaires », et le fil partagé se vide de son contenu en deux semaines. Avec un marqueur, la règle est visible : tout part, sauf ce qui porte le cadenas. L'en-tête du projet fédéré et celui de chaque tâche le rappellent aux deux équipes.
Ce que votre partenaire voit de votre maison
Rien, et c'est le but. Les tâches reçues atterrissent dans un projet dédié, fermé, visible de ses seuls abonnés, avec trois colonnes : « À faire », « En attente de… » et « Terminé ». Ce projet n'est rattaché à aucun dossier client chez lui, ce qui a une conséquence pratique importante : si votre partenaire donne lui-même des accès portail à ses propres clients, aucun d'eux ne peut tomber sur une tâche qui vient de chez vous.
Dans l'autre sens, votre tâche d'origine ne change pas de propriétaire. Elle porte l'adresse de son miroir et une note qui dit avec qui elle est partagée, rien de plus. Et un miroir ne peut pas être re-partagé vers un troisième pair : ce que vous confiez à une entreprise ne repart pas vers une autre par ricochet.
Quand l'autre bout ne répond pas
Deux systèmes qui se parlent par Internet, c'est deux systèmes qui vont finir par ne pas se parler : une mise à jour, une panne, un certificat expiré un dimanche soir. La question n'est pas de l'éviter, elle est de savoir ce qui arrive à votre message pendant ce temps-là.
Chaque envoi est mis en file et rejoué tant qu'il n'est pas passé, avec un délai qui s'allonge à chaque essai, pendant quatorze jours. La file est tenue par tâche, ce qui évite le scénario classique où une réponse arrive avant la question qu'elle commente. Et rien ne se supprime jamais de l'autre côté : retirer une tâche du partage archive son miroir avec une note, il ne s'évapore pas. Un partenaire qui fait le ménage chez lui ne touche pas non plus à votre tâche d'origine : il vous prévient, et le lien se ferme.
Le jumelage se fait une fois, entre administrateurs
Deux entreprises qui se fédèrent, ça commence par une poignée de main, et elle est réservée aux administrateurs des deux côtés. L'un génère un code d'invitation valable 48 heures et utilisable une seule fois, l'autre l'accepte en donnant l'adresse du premier. Chacun apporte sa moitié du secret partagé, de sorte qu'aucune des deux entreprises ne le choisit seule. Un bouton « Tester la connexion » vérifie que le lien répond avant qu'une seule tâche ne parte.
Le pair une fois le jumelage fait : ce qu'on reçoit de lui, et qui reçoit quoi.
Ensuite, chaque message est signé, horodaté, et refusé s'il a plus de cinq minutes ou s'il a déjà été présenté une fois. Les adresses en clair sont refusées. Ce n'est pas un luxe : dès qu'une porte accepte des instructions venues d'ailleurs, c'est la signature qui décide si celui qui frappe est bien celui qu'il prétend être. Pour l'utilisateur, tout ça est invisible : il coche une case sur une tâche.
Ce que ça ne résout pas
Les deux côtés doivent faire tourner Odoo 18 et le module, c'est la condition de départ. Ce n'est pas une passerelle vers Teams, Asana ou Jira, et ça ne le deviendra pas : le jour où votre partenaire n'a pas de système du tout, le partage de projet natif reste la bonne réponse, il est gratuit et il est déjà là.
L'historique d'avant le partage ne voyage pas. Seuls les messages écrits après que la case a été cochée traversent : ce qui s'est dit avant, votre partenaire l'a déjà reçu autrement. Les grosses pièces jointes non plus : au-delà du plafond que vous fixez, le nom part et le fichier reste, parce que vous ne voulez pas que deux systèmes se renvoient des vidéos de 300 Mo toutes les deux minutes.
L'échéance voyage en jour et pas en heure, ce qui suffit pour un mandat et pas pour un horaire de production. Les colonnes, les étiquettes et la structure du projet restent propres à chaque maison : c'est une fédération de tâches, pas une fusion de projets. Et il faut une personne nommée de l'autre côté, ce qui est une contrainte assumée : une tâche qui arrive sans destinataire est une tâche qui n'arrive nulle part.
Les autres façons de faire
Le partage de projet d'Odoo, décrit plus haut, est gratuit, natif et suffisant quand l'autre n'a pas d'outil : il faut simplement accepter qu'il vienne chez vous. Les suites en ligne vendent la même chose sous le nom d'invité ou de collaborateur externe, avec deux nuances : le siège se compte, et vos données de projet vivent chez leur éditeur.
Du côté du logiciel libre, le cadre connector de l'OCA et sa file de travaux sont des fondations solides pour bâtir une passerelle entre Odoo et un autre système. Ce sont des fondations, justement : rien qui relie deux Odoo l'un à l'autre sans qu'on écrive le connecteur. Odoo sait aussi émettre et recevoir des messages automatiques sur événement, ce qui fait une belle démonstration en une heure et ne fait pas un pont : la porte d'entrée native s'exécute avec les pleins pouvoirs et son seul secret est l'adresse elle-même.
Reste la méthode que tout le monde connaît : le courriel, avec un tableau en pièce jointe. Elle a un vrai mérite, elle marche partout. Son coût se paie ailleurs, en versions qui divergent et en « je pensais que tu t'en occupais ».
Notre position
La fédération fait partie de Symbifox, notre suite de modules qui s'ajoutent à Odoo Community. Le code est publié sous LGPL-3, il est lisible par n'importe qui, et vous pouvez le faire tourner sur votre propre serveur sans nous. Ce qu'on facture, c'est l'hébergement et le soutien, jamais le droit d'usage : c'est la même règle pour tous nos modules.
Un partenaire qui roule déjà Odoo, ça se fédère en une demi-journée, jumelage compris. Un partenaire qui n'a rien, ça se règle autrement, et parfois mieux : on regarde les deux options avec vous et on vous dit franchement laquelle tient dans votre cas. Écrivez-nous.
Le prochain passager de la même route, ce sont les comptes rendus de rencontre : un ordre du jour préparé chez vous, la rencontre tenue à deux entreprises, et les éléments d'action qui atterrissent chez chacun dans son propre système. Le module Rencontres emprunte déjà le même lien de confiance.
Vous coordonnez un mandat avec une autre entreprise qui a son propre système? Explorons ça ensemble.
Sources
- Gestion de projet, documentation Odoo 18 : le partage de projet natif, les trois niveaux d'accès des collaborateurs et les réglages de visibilité.
- Webhooks, documentation Odoo 18 : la porte d'entrée native déclenchée par un système externe, et la façon dont son adresse tient lieu de secret.
- Partage fédéré, manuel Nextcloud : l'identifiant fédéré et le partage de dossiers entre deux serveurs indépendants.
- La fédération comme concept fondateur de la souveraineté numérique : pourquoi chaque organisation garde son infrastructure tout en restant reliée aux autres.
- Spécification Matrix : le protocole fédéré de messagerie, et le modèle de serveurs qui se parlent sans autorité centrale.
- ActivityPub, recommandation du W3C : le protocole du fédivers, normalisé le 23 janvier 2018, et son modèle de serveur à serveur.
- Threads entre dans le fédivers : l'annonce technique de Meta du 21 mars 2024, et les limites déclarées de la première mouture.
- Matrix, les déploiements publics en chiffres : Tchap et ses 350 000 comptes actifs, le BwMessenger de l'armée allemande, le TI-Messenger de la santé allemande.
- Groupe de travail Open Cloud Mesh de l'IETF : la charte du protocole de serveur à serveur pour le partage de fichiers fédéré, déployé depuis 2016.
- OCA connector : le cadre libre pour bâtir un connecteur entre Odoo et un système tiers, avec sa file de travaux asynchrones.
- Loi sur la protection des renseignements personnels dans le secteur privé : le texte qui encadre la communication de renseignements personnels à un tiers.
- Code source du module Fédération : le dépôt public, la licence LGPL-3 et le mode d'emploi du jumelage.