Pour les équipes

Mergerie rend ce qu'un agent fait utilisable par une équipe de développement. Il tourne sur la machine de chaque développeur, avec ses jetons et son abonnement IA. L'équipe partage le résultat, par un dépôt git qui lui appartient, sur la forge qu'elle a déjà. Cette page dit ce qui voyage, ce qui ne voyage jamais, comment démarrer en trois étapes, et ce que je propose pour le faire en une journée avec vous.

Ce qui existe aujourd'hui

Une carte du code coûte des heures d'agent. La refaire sur six postes, c'est payer six fois pour six réponses légèrement différentes. Alors on pointe Mergerie sur un dépôt git, disons equipe/mergerie-data, privé, sur votre GitLab ou votre GitHub. Le travail accumulé y vit, un fichier lisible par objet : du JSON pour les lignes structurées, du Markdown pour ce qu'un humain relit. Toutes les trente secondes, chaque poste envoie ce qui est nouveau et récupère ce qui l'est ailleurs. Rien à installer, rien à administrer : la forge a déjà les permissions, les sauvegardes et l'historique. Et git log répond à « qui a décidé quoi, et quand », lu dans git, sans appel à l'IA.

Monter une équipe en trois étapes

Créer un dépôt privé sur la forge
Vide ou avec un README, peu importe : le bouton reconnaît le cas.
Le premier poste se rattache
Celui qui a déjà l'historique colle l'URL dans Réglages → Données partagées et clique Cloner / rattacher. Un récapitulatif dit ce qui va partir avant que quoi que ce soit ne bouge. Puis Mergerie pousse ce que ce poste porte déjà. C'est ça, monter une équipe.
Les autres collent la même URL
Même bouton. Le geste va dans les deux sens : le contenu de l'équipe descend, et ce que ce poste avait accumulé monte avec, dans le même commit. Personne ne laisse ses mois de reviews derrière lui en rejoignant.

Chacun vérifie que git le connaît (git config --global user.name). Cette identité signe les commits : c'est elle qui répondra plus tard à « qui a écrit ça ? ». Sans elle rien n'est commité, et l'écran le dit.

La mise en place accompagnée, en une journée

Votre équipe veut Mergerie sur les machines de ses développeurs sans y passer ses soirées ? Je viens, sur place ou à distance, une journée, et vous repartez avec :

Mergerie installé sur chaque poste, branché sur votre forge et vos CLI IA
Le dépôt de données d'équipe créé et rattaché, avec le choix de ce qui voyage
Des règles de review et des vérificateurs écrits pour vos dépôts
Une première carte du code par un agent de domaine, sur le périmètre que vous choisissez

Demander une journée de mise en place

Part à l'équipe

L'état de relecture de chaque merge request, et les merge requests elles-mêmes : titre, branches, auteur, lien
Les reviews, chaque version, chaque constat, chaque passe de convergence
Les règles de review, les vérificateurs et leurs verdicts
Les groupes de dépôts : les règles, vérificateurs, gabarits et consignes que vingt micro-services partagent, portés une fois
Les agents et leur carte du code
Les réglages d'équipe : gabarits de prompt, seuils, politiques de review, adresses des forges
Les pages de notes, sessions, questions et todos que vous cochez, une par une
Les lots : plusieurs merge requests de dépôts différents, nommées et vérifiées comme un tout, re-vérifiables d'un bouton ; et votre dépense IA en total journalier si vous cochez cette case

Reste sur ce poste

Les jetons d'API, le dossier des clones, la langue
Les dépôts que vous suivez : chaque poste garde sa propre liste et ne synchronise que ceux-là. En ajouter un ne lance ni clone ni découverte de merge requests sur le poste de chaque collègue
Les chemins absolus, les handles de session d'agent, les journaux de jobs, les sessions rangées
Les sessions, questions et todos non cochées ; et les todos créées par l'outil lui-même (une veille Jira, une question posée par un agent), jamais
Les brouillons, quoi que dise la case du parent : une remarque inline non envoyée, un suivi en cours de frappe, un profil d'agent à l'essai
Les valeurs d'environnement d'un vérificateur : seuls leurs noms voyagent, pour qu'un collègue sache quoi renseigner
Ce que chaque passe d'IA vous a coûté, et vos habitudes : le brief du matin, les cadences d'interrogation, les cases cochées par défaut sur une nouvelle session
Les onglets Git et Jira : là où vous allez travailler, pas ce que vous avez produit

Chaque colonne de la base est classée par son nom. Un contrôle automatique refuse une colonne à l'air secret qui n'est pas déclarée, parce qu'un secret commité dans git est définitif. Les chemins de poste dans les messages d'erreur sont masqués au départ.

Privé par défaut, partagé un par un

Une review, une règle, une carte du code sont des produits que l'équipe consomme : ils voyagent ensemble. Une session, une question, une todo, une page de notes décrivent comment vous avez travaillé : le prompt tel que tapé, les trois relances, la capture qui montre un autre onglet, ce que vous pensez d'une architecture avant de savoir le dire. Ceux-là portent une case Partager, décochée. Les passes et pièces jointes d'une session la suivent : elle ne peut pas être partagée à moitié. Décocher retire tout le dossier du dépôt et des postes des collègues ; votre copie reste entière. Seul l'auteur coche ou supprime ; un collègue range. Sur un poste seul, la case n'apparaît même pas.

Au quotidien

Vous ne faites rien. Le pied de page affiche ↑2 ↓0 et l'heure de la dernière synchro. Survolez-le pour le compte à rebours, cliquez pour synchroniser maintenant. Hors ligne, les commits restent locaux, l'indicateur passe orange, et le retard se rattrape au retour.
Un conflit ne bloque jamais. Un fichier par objet, nommé par un identifiant qui ne dépend d'aucun poste : deux personnes touchent rarement le même fichier. Quand ça arrive, la version distante gagne et la vôtre est gardée, avec deux boutons : Reprendre la mienne, Garder la leur. Jamais de rebase à moitié fait, jamais de marqueur de conflit, jamais de commande git à taper.
Une synchro ne peut pas vider votre base. Une passe qui retirerait plus de la moitié de ce que porte le dépôt, et au moins dix documents, est refusée d'emblée : rien n'est supprimé, l'indicateur passe rouge avec la raison, et Cloner / rattacher réécrit ce qui manque. Tout ré-envoyer sert à l'autre cas : un dépôt vidé à la main, que « Synchroniser » ne remplirait pas puisqu'il n'envoie que ce qui a changé.
Les cartes disent qui a fait le travail. « par Claire » sur une review, une session, une vérification, lu dans git. Une page de notes a un Historique : qui l'a changée, quand, et le diff.
Les automatismes ont un seul exécutant. Reviews et vérifications automatiques sont des réglages d'équipe, mais chaque poste a sa propre file. Réglages → Merge Request demande donc qui les honore : un poste désigné, ou l'auteur de la merge request. Dans ce cas, chaque poste ne prend que les merge requests de son propre compte de forge, sur son propre abonnement. Sans personne, elles ne tournent nulle part. Un agent planifié a de même un champ Exécutant, une personne : seule son instance honore l'horaire, et sans exécutant l'agent ne tourne qu'à la main. Deux postes laissés allumés ne produisent donc jamais deux reviews et deux commentaires sur la merge request.
Une session partagée se passe de main en main. Vous lancez une session sur un ticket, vous cochez Partager, un collègue la reprend avec son abonnement. Son agent n'a aucune mémoire de la vôtre : ce qui voyage, ce sont les itérations, demande et réponse, rejouées en tête de son prompt. Quand la session vous revient, votre agent est rattrapé sur ce qui s'est fait ailleurs, et sur cela seulement.
Le code qui arrive par le dépôt vous attend. Un vérificateur dont les commandes ont changé, un agent dont les permissions ou la planification ont changé, des reviews automatiques activées par un collègue : chacun est marqué à approuver et montre ce qui a changé. Rien ne tourne sur votre poste avant que vous cliquiez Approuver sur ce poste. Ce que vous créez vous-même est approuvé au passage.
Le codage hors dépôt voyage à moitié, exprès. Un collègue peut relire les passes de la session. Mais /Users/moi/projets/api ne veut rien dire sur son Linux : la carte montre le nom du dossier et son propriétaire, et « Relancer » est refusé.

Toute la section, dans le guide →

Ce qu'une édition plus large pourrait être

Rien de ce qui suit n'existe. C'est la liste de ce que des entreprises sur GitLab auto-hébergé ont demandé. Elle est écrite pour que vous puissiez dire ce qui compte pour vous.

Un serveur partagé sur votre infrastructure, jamais un SaaS : tout l'intérêt est que le code ne quitte pas l'entreprise.
SSO (OIDC / SAML) et permissions par dépôt, au-dessus de celles de la forge.
Un tableau de bord d'équipe : ce qui attend une décision, ce qui est vérifié vert, qui reviewe quoi.
Un journal d'audit au-delà de git log : quelle review a été publiée, par qui, depuis quelle version du rapport.
Un seul pool d'abonnements IA au lieu d'un par développeur.

Ni date ni promesse : l'ordre et l'existence de ces points dépendent de qui les demande. Le mail ci-dessous est tout le processus produit.

Dites-moi ce qu'il vous faudrait

Un mail, trois lignes : la taille de l'équipe, la forge et si elle est auto-hébergée, et ce qui rendrait l'outil utilisable chez vous. Je réponds à chacun.

Écrire à teams@mergerie.dev