Deux agents IA qui collaborent sans se marcher dessus : Mercure & Jenkins
Comment deux assistants IA auto-hébergés partagent un même coffre de notes, se répartissent les tâches, et communiquent via Matrix — sans doublons ni conflits.
Introduction
J’ai deux assistants IA auto-hébergés qui travaillent sur les mêmes données : mon coffre de notes Obsidian, synchronisé entre plusieurs machines. Le risque, c’est le chaos : deux agents qui écrivent la même note, se disputent le même domaine, ou se marchent dessus sur un fichier partagé.
Cet article décrit comment ils coopèrent concrètement : la répartition des tâches, les règles anti-conflit, et l’utilisation de Matrix comme canal de coordination. C’est un retour d’expérience sur un problème que beaucoup de gens qui automatisent avec plusieurs agents vont finir par rencontrer.
Les deux agents :
- Mercure — tourne sur mon homelab (LXC Proxmox). Gère l’infra, le RAG, la mémoire durable, l’email.
- Jenkins — tourne sur un VPS. Gère la veille RSS, la collecte, le blog.
Le problème : deux agents, un seul coffre
Les deux agents travaillent sur le même vault Obsidian (/root/obsidian-jenkins), synchronisé par Syncthing entre le VPS, mes laptops et le NAS. C’est un coffre partagé : notes, veille, projets, documentation.
Le danger est double :
- Doublons — deux agents créent chacun une note sur le même sujet.
- Conflits d’écriture — les deux éditent le même fichier en même temps. Syncthing crée alors des copies
conflicted copy, et on se retrouve avec des fichiers dupliqués et incohérents.
Sans règles, c’est la porte ouverte au désordre. La solution a été de formaliser une note de répartition qui sert de source de vérité pour tout le monde.
La règle d’or : pas de doublon, pas de conflit
La note de coordination fixe une règle simple :
Pas de doublon, pas de conflit. Si l’un des deux agents couvre déjà un domaine, l’autre n’intervient que si :
1. il n’y a pas de conflit d’écriture sur les mêmes données, ET
2. ce n’est pas un doublon inutile (apport réel).
C’est le principe fondateur. Avant d’agir, chaque agent se demande : est-ce que l’autre le fait déjà ? Est-ce que je vais écraser quelque chose ?
La répartition des tâches
La note de répartition attribue chaque domaine à un propriétaire clair :
| Domaine | Mercure (homelab) | Jenkins (VPS) |
|---|---|---|
RAG maison (Qdrant, pipeline, /recherche) |
✅ Propriétaire | — |
| Memory Kernel (mémoire durable) | ✅ Propriétaire | — |
| Mission Engine (vérif d’étapes + reprise) | ✅ Propriétaire | — |
| Gouvernance / audit (hook audit-actions, Curator) | ✅ Propriétaire | — |
| Email jean-paul@rouze.eu | ✅ (watchdog mail) | — |
| Infra homelab (Proxmox, LXC, Docker) | ✅ | — |
| Veille / RSS / blogwatcher | — | ✅ Jenkins |
| Veille permanente échanges Matrix | — | ✅ Jenkins |
| Coffre Obsidian — maintenance structurelle | ⚠️ Partagé (annoncer avant d’écrire) | ⚠️ Partagé (annoncer avant d’écrire) |
Chaque domaine a un seul propriétaire. L’autre agent n’y touche pas, sauf accord explicite. C’est ce qui évite les doublons : si Jenkins couvre la veille RSS, Mercure ne la refait pas.
La frontière du coffre
Pour le coffre Obsidian, on a défini une frontière claire :
- Jenkins = veille + karakeep + collecte RSS
- Mercure =
30_Projets/assistant-perso+ RAG + infra - Le reste (maintenance structurelle) = annoncer avant d’écrire
C’est le point le plus délicat : le coffre est partagé, donc on a besoin d’une règle pour les zones grises. La solution : annoncer avant d’écrire dans les zones non attribuées.
Les précautions sur le coffre partagé
Concrètement, quatre règles protègent le coffre :
- Ne jamais écrire dans le dossier de l’autre sans accord.
- Une seule note par sujet — vérifier l’existence avant de créer.
- Syncthing : les deux agents voient les mêmes fichiers ; un conflit d’écriture simultanée crée des doublons
conflicted copy. Éviter d’éditer le même fichier en même temps. - Coordination : toute création/modification majeure est annoncée sur le canal inter-agents Matrix.
La règle 3 est cruciale. Syncthing est un outil de synchronisation P2P, pas un système de verrouillage. Si deux agents écrivent le même fichier en même temps, il ne « choisit » pas — il crée des copies en conflit. La discipline d’écriture est donc essentielle.
Matrix comme canal de coordination
La communication entre les deux agents passe par Matrix, sur un salon inter-agents dédié. C’est le canal officiel de coordination.
Pourquoi Matrix (et plus MQTT) ?
Au départ, l’infrastructure inter-agents utilisait MQTT (Mosquitto) comme canal principal. Mais on a abandonné MQTT au profit de Matrix. Pourquoi ?
- Matrix est déjà là : les agents sont déjà connectés à Matrix pour discuter avec moi. Pas besoin d’une infra supplémentaire.
- Salons persistants : l’historique des échanges est conservé, consultable, relisible.
- Simplicité : un seul canal pour tout, au lieu d’un broker MQTT séparé.
- Veille intégrée : Jenkins surveille en permanence le salon inter-agents (veille permanente des échanges Matrix).
C’est un bon exemple de simplification : on a remplacé une brique technique (MQTT) par un canal existant (Matrix), plutôt que d’ajouter de la complexité.
Le protocole de coordination
Le salon inter-agents sert à :
- Annoncer les créations/modifications majeures du coffre.
- Négocier en cas de conflit de domaine.
- Valider les décisions de répartition.
- Consigner les accords (avec date).
Toute décision importante est datée et consignée dans la note de répartition, avec les deux agents comme validateurs.
Un exemple concret : l’accord de répartition
Le 8 août 2026, on a formalisé l’accord de répartition. Le déroulé montre bien le processus :
- Mercure a créé la note de répartition et envoyé une proposition initiale à Jenkins.
- Jenkins a confirmé l’accord : veille/RSS = Jenkins, frontière coffre = Jenkins veille+karakeep, Mercure assistant-perso+RAG+infra.
- Jenkins a confirmé qu’il ne dupliquait pas les domaines de Mercure (RAG, Memory Kernel, Mission Engine).
- L’accord a été consigné et daté dans la note, validé par les deux agents.
Ce qui est intéressant : quand Jenkins a proposé de mettre à jour la note lui-même, Mercure a vérifié et constaté qu’elle était déjà à jour — ce qui a évité un conflit d’écriture Syncthing sur le même fichier. C’est exactement le genre de situation que les règles sont censées prévenir.
Les leçons
1. Une source de vérité unique
La note de répartition est la référence. Tout le monde s’y réfère avant d’agir. Sans elle, chaque agent improvise et les doublons apparaissent.
2. Un propriétaire par domaine
C’est la règle la plus efficace : chaque domaine a un seul responsable. L’autre n’intervient que sur accord. Ça élimine la majorité des conflits à la source.
3. Annoncer avant d’écrire
Dans les zones partagées, la discipline est de dire avant de faire. Un message sur le salon Matrix avant une modification majeure évite les surprises.
4. Utiliser ce qui existe déjà
On a remplacé MQTT par Matrix parce que c’était déjà là. Moins de briques = moins de pannes. La simplicité est une force.
5. La discipline d’écriture avec Syncthing
Syncthing ne verrouille pas les fichiers. La prévention des conflits repose sur la discipline des agents : ne pas éditer le même fichier en même temps, vérifier l’existence avant de créer.
Et la suite ?
La coopération est en place, mais elle va évoluer :
- Veille permanente : Jenkins surveille en continu le salon inter-agents.
- Nouveaux agents : le modèle (note de répartition + canal Matrix) est réutilisable si j’ajoute d’autres agents.
- Affinage : la frontière du coffre et les zones grises seront ajustées au fil des besoins.
Si vous faites tourner plusieurs agents IA sur les mêmes données, je vous recommande de formaliser ce genre d’accord : une note de répartition, un canal de coordination, et la règle d’or pas de doublon, pas de conflit.
Cet article a été rédigé avec l’aide de mes deux assistants, Mercure et Jenkins, qui coopèrent exactement comme décrit. La note de répartition et la documentation complète sont dans mon coffre Obsidian.