Mergerie rend ce qu'un agent fait utilisable par une équipe.
Reviews notées, codage et agents IA sur ta machine, avec le CLI claude ou copilot que tu paies déjà, pour GitLab et GitHub. L'IA note, corrige et converge. C'est toi qui merges.
Essayer en 30 secondes
npx mergerie demoNi jeton ni compte : une démo avec des données fictives.
★ Voir le code sur GitHub Lire le guide
- AGPL-3.0, open source
- GitLab et GitHub
- Claude, Copilot, Codex ou Gemini
- Aucune clé API
- Zéro télémétrie
Local.
Un serveur Node + SQLite sur ta machine. Les seuls appels réseau sont ceux que tu configures : ta forge, ton Jira.
Ton abonnement.
Mergerie pilote le CLI claude ou copilot que tu as déjà, tous deux éprouvés ; codex et gemini sont écrits d'après leur documentation. Aucune facture Mergerie : chaque passe consomme le quota de ton abonnement.
C'est toi qui merges.
L'IA note, explique, corrige, converge. Publier et merger restent tes clics. Pousser aussi, sauf si tu actives la boucle de convergence, dans les seuils que tu fixes.
Au quotidien
Ce que ça change pour toi
- « Je ne relis pas toute la MR après chaque correction. »La re-review ne porte que sur ce qui a changé depuis la version précédente du rapport.
- « Je sais ce qui est nouveau, ce qui traîne et ce qui est vraiment résolu. »Chaque constat est suivi de version en version, et résolu veut dire disparu du diff.
- « Trois semaines plus tard, je retrouve pourquoi on a décidé ça. »Les reviews, leurs versions et les questions posées sont gardées, et « par Claire » est lu dans git.
- « J'adopte l'outil sans imposer un nouveau SaaS à l'équipe. »Tout tourne sur chaque poste avec le CLI déjà payé ; le partage passe par un dépôt git que l'équipe possède.
Reviews
À quoi ressemble une review
Une merge request atterrit dans ta file. Un clic : l'IA lit le diff, pas tout le dépôt, et rend un rapport structuré. Des constats classés bloquant / important / mineur, chacun pointant un fichier et une ligne. Une note sur 10, calibrée sur des repères nommés. Ce qui est bien, et une checklist de merge. Le sujet n'est pas le tien ? Demande une explication en langage clair. Tes propres remarques s'ancrent sur la ligne concernée, restent en attente le temps de ta lecture, puis partent sur la merge request d'un bloc.
- Reviews notées et versionnées ; la re-review est incrémentale : seulement ce qui a changé depuis
- Constats suivis jusqu'à résolution, avec un garde-fou git : résolu veut dire disparu du diff
- Règles d'équipe qui se déclenchent sur un chemin (
**/migrations/**) et posent un badge sur la MR avant la review - Contexte par MR : la règle métier, l'incident de l'an dernier, une capture. Envoyé avec le diff, gardé pour la review suivante
- Une question sur un constat reçoit sa réponse sous le rapport, sans le régénérer. La note et les versions ne bougent pas
- Publie le rapport sur la merge request, ou seulement son lien quand l'équipe partage un dépôt de données : trois lignes, avec le nombre de constats bloquants, au lieu de six cents lignes
- Le verdict que la forge lit elle-même : Approuver depuis le rapport, Résoudre sur chaque fil de discussion, et la CI de la forge (pipeline, checks) en badge sur chaque merge request de ta file. Jamais une rafale de commentaires inline
- Groupes de dépôts : vingt micro-services partagent les mêmes règles, vérificateurs, gabarits de prompt et consignes. Ils les portent une fois, sur un groupe qui voyage avec l'équipe
Convergence
Review → correction → re-review, jusqu'à ce que ça passe
La boucle autonome reviewe, laisse l'IA corriger ce qu'elle a trouvé, commite, pousse, puis reviewe à nouveau. Elle s'arrête au seuil de note que tu fixes, ou au nombre maximal de tours. Quand l'IA ne peut pas trancher une décision, elle te pose la question au lieu de deviner : la boucle se met en attente, tu reçois une notification, tu réponds, puis tu relances Converger, qui reprend la même session. Après chaque passe, le vérificateur de la merge request tourne et son verdict s'affiche sur le panneau. C'est une information à côté de la note, jamais une condition de sortie : des tests verts ne disent pas que la modification est juste.
- ReviewNote et constats sur le diff.
- CorrectionL'agent corrige, commite et pousse sur la même branche.
- Re-reviewSeulement ce qui a changé. Arrêt au seuil.
Un verdict qui n'est pas une opinion
Un vérificateur, c'est une simple liste de commandes attachée à une merge request (npm ci, npm test). Il lui donne un verdict objectif : ✓ vérifié, ✗ 2 tests cassés, ⚠ base déjà rouge. Les noms des tests cassés sont lus directement dans la sortie TAP ou JUnit. Des merge requests de plusieurs dépôts qui ne tiennent qu'ensemble sont vérifiées ensemble. Les commandes du vérificateur tournent sur ta machine. Le formulaire propose des lignes exactes d'après ce que le clone déclare (npm, pnpm, yarn, composer, Makefile, pytest, Go, Rust, Maven, Gradle, .NET), et leur variante docker compose run --rm quand un fichier compose est là.
Agents
Une IA qui connaît tes vingt dépôts, pas seulement celui où tu es
Une session lancée dans un clone a déjà le code, son CLAUDE.md et ses skills. Ce qu'elle n'a pas, Mergerie l'a : les dix-neuf autres clones, ce qui vient d'être mergé ce matin, et la connaissance qui vit entre les dépôts. Un agent est un profil de session : un rôle, un périmètre de dépôts, des outils, des skills, une sortie, parfois une planification. Un lancement est une session ordinaire : mêmes suivis, mêmes questions, mêmes passes archivées, même coût. Trois règles tiennent partout. Un agent ne pousse et ne publie jamais de lui-même. Il ne devine jamais un dépôt. Il ne gère jamais les conversations entre humains.
- « Où gère-t-on les notifications, ici ? »Un agent de domaine cherche dans les dépôts que tu as cochés, et seulement ceux-là. Puis il écrit la carte : points d'entrée, mécanismes, types, configuration, tests, pièges. Chaque chemin qu'il cite est ouvert dans le clone ; celui qui n'existe pas est marqué (non vérifié) et compté.
- Puis l'interroger, ou coder avecLa carte devient le contexte : pose une question à l'agent, ou ouvre une session de codage avec ses dépôts déjà cochés. S'il trouve une erreur dans sa propre carte, il la signale au lieu de la corriger en silence.
- Un incident, jusqu'à la ligneL'enquêteur livré avec l'outil prend une trace, un log ou un extrait de ticket, et cherche dans tous les clones. Il nomme le dépôt, le fichier et la cause probable. S'il ne trouve rien, il le dit, plutôt que de proposer un dépôt plausible.
Tu sais quand une carte a vieilli, sans appel à l'IA
La connaissance enregistre le SHA de chaque dépôt et les chemins qu'elle cite. Mergerie compte les commits qui ont touché ces chemins-là depuis, 7 commits depuis la carte, sans aucun appel à l'IA. Un clic les liste avec leur date, leur auteur et leur message. Mettre à jour relance le cartographe avec la carte précédente, les manques qu'il a signalés et ces commits. Le résultat t'attend avec un diff lisible, et l'agent continue de travailler sur l'ancienne carte jusqu'à ce que tu valides. Les agents tournent aussi sur un rythme si tu veux, chaque jour, chaque semaine ou chaque mois, et le brief du matin dit ce qui a tourné pendant la nuit.
Équipe
Partage le travail. Garde les secrets.
Pointe Mergerie sur un dépôt git, celui de ton équipe sur la forge que tu as déjà, et le travail accumulé y vit, un fichier lisible par objet. Chacun garde son instance, ses jetons et son abonnement IA : les requêtes partent de son poste, c'est le résultat qui est partagé. Pas de serveur, pas de compte, rien à administrer : la forge a déjà les permissions, les sauvegardes et l'historique.
Part à l'équipe
- Les règles de review, les vérificateurs et les groupes de dépôts
- Les agents et leur carte du code
- Les reviews, chaque version, chaque constat
- L'état de relecture de chaque merge request
- Les réglages d'équipe et les gabarits de prompt
- Les pages de notes, sessions et todos que tu coches
Reste sur ce poste
- Les jetons d'API, le dossier des clones, les chemins absolus
- Les dépôts que tu suis : chaque poste garde sa propre liste
- Les sessions, questions et todos, tant que tu ne les coches pas
- Les brouillons, toujours : une remarque non envoyée, un suivi en cours de frappe
- Ce que chaque passe d'IA t'a coûté
- Les onglets Git et Jira
- Privé par défaut, partagé par choixUne session, c'est ta façon de travailler : le prompt tel que tu l'as tapé, les trois relances, la capture qui montre un autre onglet. Elle porte une case Partager, décochée. Ses passes et pièces jointes la suivent : elle ne peut pas être partagée à moitié. Décoche-la, et tout le dossier quitte le dépôt.
- Prévenu de ce qui part, avant que ça parteRattacher ouvre d'abord un récapitulatif : ce qui part, ce qui reste, et fichier par fichier combien seront ajoutés, modifiés ou supprimés. Supprimés : aucun. Envoyer écrit, n'efface jamais. Et une synchro qui retirerait plus de la moitié de ce que porte le dépôt (et au moins dix documents) est refusée, pas appliquée : Cloner / rattacher réécrit alors ce qui manque.
Monter une équipe en trois étapes Partager avec une équipe, dans le guide →
Et le reste
Des raisons de rester, une fois entré
- Sessions de codage depuis un ticketPars d'un ticket Jira : la modale de session liste les tiens à la frappe. La branche, le prompt et le message de commit arrivent préremplis. L'IA code, commite, pousse, ouvre la MR.
- Une précision technique par ticketDécris un ticket Jira à l'IA, coche les dépôts et la branche de chacun : le code vit souvent sur une branche de release. L'onglet Analysés liste les tickets déjà précisés, et Mes tickets se filtre dessus.
- Planifier d'abord, puis approuverCoche Planifier d'abord : la première passe lit et rend un plan : fichiers, étapes, risques. Tu le lis sur la carte, tu ajoutes une remarque, et Approuver et coder reprend la même session d'agent pour le réaliser. Pendant qu'une session tourne, Stopper et reprendre avec cette consigne la redirige sans perdre son fil.
- Sessions multi-dépôtsUn prompt, cinq dépôts, cinq merge requests créées ensemble, et vérifiées ensemble. D'autres dépôts peuvent être liés en lecture seule : l'IA lit leur API et leur schéma pour coder juste, sans pouvoir y toucher.
- Des sessions qui restent, ou qui attendentRetrouve une session d'il y a trois jours par son prompt et envoie un suivi d'une phrase : l'agent reprend sa session. Ou planifie une session, ou un suivi, à une date et une heure : ton poste la lance, et se rattrape s'il était éteint.
- Git, avec les conflits à l'écranFusion de branches avec résolution côte à côte et vue plein écran. Un bouton demande à l'IA une résolution de chaque conflit d'un coup, chacune avec sa raison, chacune validée par toi. Sur une merge request en conflit ou en retard sur sa cible, Mettre à jour avec l'IA ouvre une session déjà remplie qui rebase sans pousser : tu relis le diff, puis tu pousses en
--force-with-lease. - Une sécurité qui se litUn mode sécurisé, un clic, demandé une fois au démarrage. Reviews et explorations lancent l'agent en lecture seule ; les sessions de codage tournent dans la sandbox du CLI une fois que Tester le sandbox l'a prouvée sur ta machine, sur une liste blanche sinon. Sans lui, l'agent a exactement les droits de ton CLI, comme dans ton terminal. Dans les deux cas, un vérificateur ou un agent reçu de l'équipe attend ton approbation, et exposer le serveur sur le réseau exige un jeton.
- Des plugins, depuis la 3.0Un dossier avec un
plugin.jsonet unindex.js, des permissions déclarées, un contexte fermé : réglages, tables préfixées, routes, événements, un onglet, une section du brief. Jenkins, Docker et Liens sont devenus des plugins dans leur propre dépôt. Réglages → Plugins installe depuis une adresse git, active sans redémarrer, met à jour d'un clic. Un SDK (@mergerie/plugin-sdk) donne les types et un générateur. - Plusieurs binaires d'agent, un par défautRéglages → Sessions IA liste tes binaires : le défaut pour la review et la convergence, d'autres à choisir par session. Chacun porte ses arguments et ses variables d'environnement, transmises à l'agent seul, jamais à ton terminal. Un Claude Code branché sur un Ollama local à côté de ton abonnement : ton code ne sort pas.
- Des notes que tes agents tiennent à jourUn agent de documentation écrit la page générale et décide lui-même combien de sous-pages le détail réclame. Elles sont appariées par leur titre d'un lancement à l'autre : un agent hebdomadaire les met à jour au lieu d'empiler des copies.
- Un brief du matin, pas un tableau de bordCe que les agents de la nuit ont produit, les merge requests prêtes à merger, les sessions arrêtées sur une question, les remarques écrites et jamais envoyées.
Installer
Essayer, puis brancher
- La démo, sans jeton
Données fictives, IA en dry-run, une équipe fictive de trois. Explore chaque écran.
npx mergerie demo - En vrai, une fois le CLI connecté
Le CLI de l'étape du dessous installé et connecté, lance Mergerie, puis Réglages → ton jeton GitLab ou GitHub, et le dossier où vont les clones.
npx mergerie
Mergerie pilote le CLI claude avec ton abonnement existant. Documentation Claude Code.
npm install -g @anthropic-ai/claude-code && claudeMergerie pilote le CLI copilot avec ton abonnement existant. Documentation Copilot.
npm install -g @github/copilot && copilotNécessite Node 22.9+ et git. macOS, Linux, Windows (WSL). Le premier lancement écrit un court .env dans ~/.mergerie, pointé sur l'agent qu'il trouve. L'agent, ses arguments et son délai se règlent ensuite à l'écran, sans redémarrer. Claude Code et Copilot CLI sont éprouvés ; Codex CLI et Gemini CLI sont écrits d'après leur documentation et marqués « non vérifiés » dans Réglages → Sessions IA, où le backend se choisit.
Comparer
Pourquoi pas un relecteur hébergé ?
Les autres outils produisent une review. Mergerie garde le chemin entre la review, la correction et la décision de merge. Les relecteurs hébergés sont bons. Mais ils lisent ton code sur leurs serveurs et facturent au siège. Mergerie tourne sur ta machine, pour GitLab comme pour GitHub, avec l'abonnement IA que tu paies déjà, et garde ce chemin de bout en bout. Et la connaissance de ton équipe vit dans un dépôt git qui t'appartient.
| Critère | Mergerie | CodeRabbit | Copilot code review | GitLab Duo |
|---|---|---|---|---|
| Tourne sur ta machine | ✓ oui | ✗ non | ✗ non | ✗ non |
| Support GitLab | ✓ oui | ✓ oui | ✗ non | ✓ oui |
| Coût en plus par siège | aucune facture Mergerie ; chaque passe consomme le quota de ton abonnement Claude / Copilot / Codex / Gemini | au siège | au siège | au siège |
| Boucle de convergence (review → correction → re-review) | ✓ oui | ✗ non | ✗ non | ✗ non |
| Connaissance d'équipe en fichiers dans un dépôt git à toi, sans serveur | ✓ oui | ✗ non | ✗ non | ✗ non |
FAQ
Ce qu'on demande avant d'installer
Mon code passe-t-il par des serveurs Mergerie ?
Non. Il n'y a pas de serveur Mergerie. Mergerie tourne sur ta machine et ne parle qu'à ta forge (GitLab ou GitHub) et au CLI IA que tu as configuré, selon les conditions de ce fournisseur. Et si ton code ne doit pas sortir du tout, Réglages → Sessions IA accepte plusieurs binaires d'agent : un Claude Code branché sur un Ollama local, à côté de ton abonnement. Voir ce qui quitte ta machine.
Dois-je payer un abonnement Mergerie ?
Non. L'édition open source ne demande aucun abonnement Mergerie. Il te faut tes propres accès à la forge, et un CLI Claude Code, Copilot, Codex ou Gemini déjà installé et payé, facturé par ce fournisseur.
Que coûte une review, concrètement ?
Aucune facture Mergerie. Chaque passe consomme le quota de l'abonnement que tu pilotes : les limites d'usage de Claude Code, les premium requests de Copilot. Le rapport dit lui-même ce qu'il a coûté en tokens, et l'onglet Stats donne le coût moyen par merge request reviewée et les reviews les plus coûteuses. Ce coût reste sur ton poste : il ne part pas dans le dépôt d'équipe, sauf en total journalier si tu coches la case.
Quels CLI d'IA peut-il piloter ?
Claude Code et GitHub Copilot CLI, éprouvés. OpenAI Codex CLI et Gemini CLI sont écrits d'après leur documentation, sans avoir été essayés par le mainteneur, et les Réglages les disent « non vérifiés ». Le backend est reconnu d'après le binaire que tu lui indiques. Chacun est branché avec la garantie qu'il sait prouver : reviews en lecture seule, sandbox pour les sessions de codage. Un CLI inconnu tourne quand même, à un niveau allégé que le journal annonce en première ligne.
Mergerie fonctionne-t-il avec GitLab ?
Oui, GitLab et GitHub côte à côte, dépôt par dépôt. Voir la comparaison sourcée.
GitLab auto-hébergé, proxy d'entreprise, CA interne ?
Oui. Une instance GitLab ou GitHub Enterprise derrière une autorité de certification interne se déclare par GITLAB_CA_CERT ou GITHUB_CA_CERT (la chaîne complète jusqu'à la racine) ; GITLAB_INSECURE_TLS=1 existe pour le dépannage, et GIT_CLONE_SSH=1 clone avec ta clé SSH. Les variables de proxy de ton shell sont transmises à l'agent, dont l'environnement est une liste blanche. Voir la section du guide.
L'IA peut-elle pousser ou merger seule ?
Pas par défaut. Pousser, publier et merger restent des actions séparées et explicites. Une fois activée, la boucle de convergence autonome peut commiter et pousser seule, avec les seuils que tu fixes. Publier et merger restent les tiens.
Mergerie remplace-t-il ma CI ?
Non. Il lance tes propres commandes de test et affiche leur verdict sur la merge request. Il ne remplace ni tes pipelines CI ni tes règles de protection de branche.
Jira est-il obligatoire ?
Non. Reviews, convergence, vérificateurs, agents et partage d'équipe n'en ont pas besoin. Jira sert aux fonctions qui partent d'un ticket : la session de codage depuis un ticket, la précision technique, l'onglet Jira avec tes tickets, et les clés comme PROJ-720 qui deviennent des liens. Réglages → Jira : URL, email, jeton d'API.
Et sur Windows ?
Mergerie tourne via WSL. Les chemins, les identifiants et les performances suivent les règles de WSL, pas celles de Windows natif.
L'AGPL m'engage à quoi, en entreprise ?
À rien de plus que l'usage. Tu installes Mergerie sur les postes de ton équipe et tu l'utilises en interne : rien à publier. Tu le modifies et gardes la modification sur tes postes : rien non plus. L'obligation de fournir ton code source sous AGPL ne joue que si tu redistribues ta version modifiée, ou si tu la mets à disposition d'utilisateurs par le réseau, comme un SaaS. Voir LICENSE.
Un seul mainteneur : et s'il s'arrête ?
Le code est AGPL et forkable : il te reste tel quel, et tu peux le faire vivre sous un autre nom. Tes données sont des fichiers lisibles, JSON et Markdown, dans un dépôt git qui t'appartient, et une base SQLite sur chaque poste. Aucun serveur Mergerie ne s'éteint, aucun compte ne se ferme.
Qui maintient Mergerie, et puis-je contribuer ?
Un seul mainteneur et un seul ayant droit, exprès : la licence et la responsabilité du code restent claires. Les pull requests extérieures sont fermées, et un patch collé dans une issue n'est pas fusionné non plus. Les rapports de bug et les idées, décrits en mots, sont bienvenus en issues : la correction est alors réécrite depuis zéro. Forker est permis, en gardant la licence et sous un autre nom. Voir CONTRIBUTING.md.
Équipes
Ton équipe, sur ta forge, aujourd'hui.
Il te faut plus qu'un dépôt partagé : un serveur sur ton infrastructure, du SSO, un journal d'audit, ou une mise en place en une journée ? Écris-moi : un mail, trois lignes.