Il est 16 h et trois agents de code travaillent sur le même dépôt depuis le déjeuner. L'un a corrigé l'arrondi du total du panier, un autre a ajouté un code promo, le troisième a écrit des tests. Tous les trois annoncent "done". Avant que quoi que ce soit ne touche main, vous voulez savoir deux choses : est-ce que deux d'entre eux ont réécrit la même fonction, et est-ce que les trois changements passent encore les tests une fois réunis ?
Trois écrans pour une même base de code
osFoundry est une application de bureau qui réunit chat, agents, fichiers et outils dans une seule fenêtre, et pour le code elle propose trois écrans liés. Code, c'est là où vous confiez des tâches à plusieurs agents en même temps : chaque exécution a sa propre branche Git et son propre dossier de travail (un worktree), et vous relisez, testez et prévisualisez la fusion avant de décider quoi que ce soit. Rien ne fusionne tout seul. L'IDE est un éditeur de code pour un dossier local, avec un explorateur, le contrôle de version, un terminal, des panneaux Problems et Tests, et une colonne d'assistant qui voit le fichier ouvert. Wiki lit un dépôt sur votre machine et rédige des pages de documentation qui citent path:line, puis signale une page quand le code qu'elle cite change. Code et Wiki sont des onglets à côté de Maestro, Model chat, Multi chat et Research ; l'IDE a sa propre entrée dans la barre latérale. Si vous connaissez VS Code avec son panneau Git, l'IDE vous semblera familier. Code ressemble plutôt à une boîte de réception de pull requests, sauf que les auteurs sont vos agents et que les branches n'ont jamais quitté votre portable.
Un tour de l'onglet Code
Ce que vous voyez sur cet écran (les exécutions sont des données d'exemple) :
- Le bandeau en haut de la colonne. "3 agents finished · they disagree on 1 file" nomme le fichier, ici
src/cart.js, avant même que vous ouvriez un diff. Le bouton Review together lance une relecture commune. - La colonne des exécutions. Elles sont regroupées selon ce qu'elles attendent de vous : Ready to review, Needs attention et un History replié. Chaque ligne affiche la tâche, les lignes ajoutées et supprimées, la durée de travail et la branche.
- La conversation au centre. Cliquez sur une exécution pour lire ce qu'on a demandé à l'agent et ce qu'il a dit pendant son travail.
- Le panneau de droite. Les onglets Changes, Files, Commits, Review et PR montrent le vrai diff de chaque exécution : d'abord le travail non commité, puis ce qui a été commité sur sa branche.
- La Merge station en bas à droite. Vous sélectionnez des exécutions terminées et c'est ici que vous les testez et prévisualisez leur fusion commune.
Cas d'usage : une tech lead avec trois agents sur un dépôt
Dana dirige une petite équipe web et découpe un sprint de checkout en trois exécutions d'agents : corriger l'arrondi des totaux du panier, ajouter un code promo au checkout, écrire des tests pour le formateur de prix. Chaque exécution a été lancée depuis New run avec une tâche d'une ligne et un agent choisi pour elle. Chacune a donc sa propre branche et son propre dossier, et aucune ne peut marcher sur les fichiers des autres pendant le travail.
Quand le bandeau indique qu'elles divergent, elle coche les trois exécutions et clique sur Review together. Le panneau Merge affiche "3 runs · conflicts not checked yet · 3 not yet tested", un "on ne sait pas encore" honnête plutôt qu'un feu vert. En dessous, src/cart.js est marqué contested, et les hunks de chaque branche sont listés côte à côte : la correction d'arrondi et le code promo ont tous deux réécrit total().
Elle lance ensuite test sur chaque exécution. Les tests tournent dans le worktree de l'exécution concernée, donc son propre checkout n'est jamais touché. Par défaut, "Tests must pass before a branch can merge", et cette règle se modifie dans Settings. Les trois passent, mais passer séparément n'est pas la même chose que passer ensemble, alors elle clique sur Preview combined merge. L'application fusionne d'abord les branches dans une copie jetable et rend son verdict : deux fusionnent proprement, une est en conflit.
Elle fusionne les deux branches propres dans sa branche courante. C'est seulement à ce moment que sa branche change. La branche du code promo reste en place, pour que l'agent refasse son changement par-dessus la correction d'arrondi. Si elle avait voulu le meilleur de chaque tentative plutôt que des branches entières, Combine into a branch lui permet de cocher des hunks un par un et d'en faire une nouvelle branche.
Un dernier détail qui compte les longues journées : si l'application s'arrête pendant qu'une exécution travaille, celle-ci revient en Interrupted, pas en "running", avec la mention que sa branche est conservée.
Cas d'usage : un développeur solo qui refactorise avec un assistant
Kenji maintient seul le front-end d'une boutique. Ce matin, il doit modifier formatPrice et ne sait pas trop qui l'appelle. Il ouvre le dossier du projet dans l'IDE depuis la barre latérale. La disposition de l'éditeur est classique : Explorer et Source Control à gauche, les onglets au centre, Terminal, Output, Problems et Tests en bas, et l'Assistant à droite, où il peut lancer un chat synchronisé ou un chat local qui reste sur l'appareil.
Il fait un clic droit sur formatPrice et choisit Show Code Graph. Le panneau liste Callers et Calls. Un point plein signifie que l'appel a été lu directement dans le code ; un point creux signifie qu'il a été déduit, et celui-là mérite une vérification manuelle. Impact of change remonte aussi les appelants des appelants et affiche, dans cet exemple, "15 symbols · 14 files · 3 tests". Un clic sur une ligne amène à cet endroit, et Send to chat transmet tout le graphe à l'assistant comme contexte.
Plus tard, l'assistant modifie pour lui un fichier de configuration. Dans Source Control, le fichier apparaît comme modifié, et quand il l'ouvre, une petite icône de robot et la barre d'état indiquent qu'il a été écrit en dernier par l'IA, avec le modèle et la raison donnée. Review ouvre un diff côte à côte avec la copie enregistrée juste avant cette écriture, il ne voit donc que ce changement. Ici, on voit un timeout réduit de 30 secondes à 3, juste sous un commentaire qui précise que les gros uploads prennent 20 secondes ou plus. Il le repère avant de commiter.
Si un agent écrit dans un fichier alors qu'il y a encore des modifications non enregistrées, l'éditeur signale que le fichier a changé sur le disque pendant l'édition et propose Keep mine ou Use the disk version, au lieu de choisir en silence.
Cas d'usage : une ingénieure support qui doit comprendre le code, pas le modifier
Priya travaille au support client et on lui demande souvent comment se comporte telle partie du produit. Elle sait lire du code, mais n'a pas envie de faire des grep dans un dépôt qui n'est pas le sien. Dans Wiki, elle utilise Open a folder (ou Clone a public repository avec une URL https ou git@), et l'application lit la structure du projet sur sa machine.
Avant d'écrire quoi que ce soit dans le projet, Wiki demande. Une boîte de dialogue indique le dossier exact qu'il va créer dans le dépôt, et si elle clique sur Not now, rien n'est écrit. Une fois qu'elle accepte, elle utilise Generate pages, ou Write a page pour un sujet précis. Les réglages déterminent à partir de combien de code source chaque page est rédigée (Depth : Quick, Standard ou Deep) et combien d'affirmations sont vérifiées (Verification : Off, Sample ou Full, Full doublant à peu près la facture). Le coût est affiché avant la génération d'une page.
Chaque page cite path:line, et un clic sur une citation ouvre cette ligne dans l'IDE. Un mois plus tard, une page de la colonne est signalée parce que "a file this page cites has changed since it was written", ce qui lui dit de la régénérer avant de s'y fier. Pour une question ponctuelle, elle utilise le chat à côté des pages, dont les réponses citent elles aussi path:line dans ce projet, et où elle peut aussi demander une nouvelle page en langage courant, par exemple "write a page about the retry policy". Les pages elles-mêmes sont des fichiers markdown dans le dépôt, donc l'équipe peut les relire dans les mêmes pull requests que le code.
Où Code, l'IDE et Wiki se passent le relais
Ces trois écrans se transmettent le travail entre eux et avec le reste de l'application. Une citation Wiki ouvre l'IDE à la ligne citée, et l'IDE a un bouton Wiki for this folder pour le chemin inverse. L'Assistant de l'IDE et le chat à côté des pages Wiki reposent sur Maestro, le même assistant que partout ailleurs dans osFoundry, donc poser une question là fonctionne comme dans n'importe quel chat Maestro. Pour chercher dans une base de code par le sens plutôt que par mots exacts, Indexes construit un index de recherche local que Maestro peut utiliser. Et quand une exécution Code est prête à quitter votre portable, Open PR ouvre une pull request pour sa branche.
Les pages produit proposent des démos interactives de chacun : Code et l'IDE.
Les premières questions qu'on nous pose
Ai-je besoin de l'application de bureau ?
Oui. Code, l'IDE et Wiki travaillent sur des dossiers locaux, des worktrees Git, un shell et des serveurs de langage, ils tournent donc dans l'application de bureau osFoundry.
Un agent peut-il fusionner dans ma branche tout seul ?
Non. Les exécutions travaillent sur leurs propres branches, dans leurs propres dossiers. Votre branche courante ne change que lorsque vous cliquez sur merge, et par défaut uniquement pour les branches dont les tests sont passés.
Wiki est-il un wiki d'équipe comme Notion ?
Non. Il rédige de la documentation à partir d'un dépôt de code, en citant fichier et ligne, et signale les pages quand ce code change. Il sert à la documentation du code, comme une vue d'ensemble de l'architecture ou des notes d'onboarding.
Que devient une branche en conflit ?
Elle reste où elle est. Vous pouvez fusionner les branches propres tout de suite et laisser l'agent refaire celle en conflit par-dessus, ou choisir des hunks un par un avec Combine into a branch.
L'application de bureau se télécharge gratuitement sur osfoundry.io/fr/download.
