DEV Community: tauchi Français

Comment Memory et Knowledge Base d'osFoundry conservent ce que votre IA a appris et le lui redonnent comme contexte

tauchiii — Fri, 06 Nov 2026 17:41:31 +0000

Il est 9 h 40, un lundi, et vous ouvrez un nouveau chat avec votre agent de code. Jeudi dernier, il a passé une heure à comprendre que le service de facturation tourne sur Postgres 16 et que la suite de tests complète prend quatre minutes. Aujourd'hui, il vous repose les deux questions. Vous répondez, il acquiesce, et dans un coin de votre tête vous commencez une liste de choses qu'il faudra répéter vendredi.

Ce que sont les fonctions Knowledge

osFoundry propose un ensemble de fonctions conçues pour mettre fin à cette répétition : Note, Knowledge Base, Memory avec ses Memory Groups, Lessons, Chat History et Indexed Folders. Pour faire simple, ce sont les endroits où l'on stocke ce que vous écrivez et ce que vos agents découvrent, ainsi que les réglages qui décident quelle partie en est renvoyée à l'IA comme contexte lors de l'exécution suivante. Dans l'application de bureau, ce ne sont pas un seul gros panneau mais des écrans distincts : Notes pour vos propres documents, Knowledge Base pour les articles partagés, Memory (sous-titré "What Maestro knows & reads") pour tout ce dont se souviennent l'assistant et vos agents, et Indexes pour les dossiers que vous choisissez d'ouvrir à la recherche. Si vous avez déjà utilisé un wiki à côté d'un assistant de chat, imaginez que le wiki et le carnet de l'assistant vivent dans la même application, avec sur chaque étagère un interrupteur qui indique si l'IA a le droit de la lire.

Un premier coup d'œil à l'écran Memory

Voici Memory avec Agents sélectionné, rempli de données d'exemple. Ce que l'on y voit :

La barre de gauche : Memory Groups, Memory Browser, Chat History, Agents, Sessions et Lessons. Sous "Indexing" se trouvent Chunking Station, Indexed Folders et Embeddings, qui ouvrent l'écran Indexes.
La liste des agents ("Agents with memory") : chaque agent avec le nombre de souvenirs et de leçons qu'il porte, ici @code-agent et @research-agent.
"What it knows" : des faits enregistrés à partir d'étapes terminées et d'échanges de chat, relus lors des exécutions suivantes de l'agent. Dans l'exemple : la version de Postgres, la commande de test et le fait que vous préférez les petites pull requests.
"What it learned" : des règles écrites uniquement après qu'un relecteur a rejeté le travail ou qu'une étape a échoué.
"Move what it learned" : Save to a file et Import from a file, car les souvenirs et les leçons restent sur l'appareil et ne suivent pas d'eux-mêmes un agent sur une autre machine. En haut, Settings et Turn off contrôlent la mémoire des agents dans son ensemble.

Trois façons de s'en servir

Une développeuse en solo qui réexplique sans cesse son code

Maya maintient seule une API de taille moyenne et confie la plupart des modifications à un agent. Son problème n'est pas que l'agent soit mauvais, c'est que chaque session repart de zéro.

Elle ouvre Indexes, reste sur l'onglet Sources et clique sur Add folder pour choisir le dépôt. L'analyse est gratuite et montre ce qui sera indexé avant que quoi que ce soit ne passe en embedding. Elle choisit "Index locally", qui calcule les embeddings sur sa propre machine avec un modèle local, et active "Re-index automatically when files change" pour que l'index suive ses modifications.

Désormais, quand elle demande simplement à Maestro où se trouve la logique de verrouillage des comptes, l'agent peut lancer une recherche dans le dossier qui combine mots-clés et sens, et revient avec des chemins de fichiers et des plages de lignes plutôt qu'une supposition. En quelques jours, les faits que l'agent glane au passage apparaissent dans Memory → Agents → "What it knows", si bien que la conversation suivante démarre déjà avec eux.

Ce qu'elle obtient : un agent capable de chercher dans son code par le sens, et une liste courte et lisible de ce qu'il retient de son projet, qu'elle peut consulter à tout moment.

Un chef d'équipe qui veut que l'agent arrête de refaire la même erreur

Daniel dirige une petite équipe où des agents préparent des modifications qu'une étape de revue vérifie. Il y a deux semaines, un agent a « corrigé » un test en échec en le supprimant. Le relecteur a rejeté cette exécution, et osFoundry a rédigé une leçon à partir de ce rejet.

Il ouvre Memory → Lessons. Les leçons de tous les agents y sont listées avec l'exécution dont elles proviennent, formulées sous la forme "When … : …". Il garde les utiles, comme "When a test fails after your change: fix the code. Never edit, skip or delete the test to make it pass." Une ligne porte le badge "from outside content" : elle vient d'une page de tarifs lue par l'agent de recherche et dit de toujours recommander une offre précise. L'agent traite ce genre de leçon comme une suggestion, pas comme une instruction, mais Daniel ne veut tout simplement pas la voir là, alors il clique sur Retire.

Avec "Show retired" activé, la ligne retirée reste visible, grisée, avec un bouton Restore : rien n'est perdu s'il change d'avis. Ce qu'il obtient : des agents qui lisent les leçons actives les plus récentes avant chaque exécution, et un historique consultable de chaque règle qu'ils ont apprise et de son origine.

Une consultante qui veut que l'IA utilise les documents du bon client

Aiko est consultante indépendante, pas ingénieure. Ses dossiers clients représentent quelques centaines de documents Word et de PDF rangés dans des dossiers sur son ordinateur portable, et elle veut que l'assistant réponde à partir de ces fichiers sans mélanger les clients.

Dans Notes, elle clique sur Import… et choisit "Import folder…" (le menu le présente comme destiné à un vault Obsidian ou à un export décompressé ; "Import .zip archive…" couvre un export Notion ou une sauvegarde Bear). L'application de bureau convertit les fichiers en notes hors ligne et conserve l'arborescence des dossiers dans le File Tree.

Pour les pages qu'elle réutilise d'un client à l'autre, comme sa checklist d'onboarding et ses conditions standard, elle crée une Knowledge Base : New Knowledge Base, puis New article, ou Import content depuis un PDF, un DOCX, du Markdown, un export Notion ou Confluence, ou le crawl d'un site web. Après avoir modifié un article, elle clique sur Generate chunks pour que l'IA récupère bien la dernière version ; une simple modification ne le réindexe pas.

Ensuite, elle va dans Memory → Memory Groups et crée un groupe par client. Dans le réglage "When can this be recalled?" de chaque groupe, elle laisse le client actuel sur Normal (recherché quand le projet l'autorise) et passe une mission terminée sur Never, ce qui la retire complètement de la recherche tout en la gardant stockée. Un souvenir qui doit figurer dans chaque réponse, sa grille tarifaire, reçoit "Pin (always in context)". Ce qu'elle obtient : des réponses tirées des documents du bon client, et un interrupteur explicite pour couper tout le reste.

Comment tout cela s'articule avec le reste de l'application

Les fonctions Knowledge servent surtout à alimenter d'autres parties d'osFoundry plutôt qu'à fonctionner seules. Maestro, l'assistant intégré, en est le principal lecteur : il cherche dans les memory groups quand une question l'exige et utilise les Indexed Folders via sa recherche dans les dossiers. Les agents des écrans Agent team et Single agent apportent leur propre mémoire et leurs leçons dans chaque conversation à laquelle ils participent. L'onglet Health de l'écran Indexes regroupe Chunking Station et Embeddings, où l'on voit quelles notes, quels articles et quels fichiers ont changé, ont échoué ou n'ont jamais été découpés en chunks. Chat History conserve les transcriptions écrites lorsque les longues conversations sont compactées, pour que vous puissiez retrouver les mots d'origine derrière un résumé. Et pour les conversations menées dans d'autres applications d'IA sur votre ordinateur, External agents affiche ces sessions à côté de celles d'osFoundry. Les pages consacrées aux agent memory groups et aux knowledge bases détaillent chacune d'elles.

Les questions que posent les nouveaux venus

L'assistant lit-il automatiquement toutes mes notes ?
Non. L'assistant ne lit pas les souvenirs automatiquement : il les recherche quand une question le nécessite, et le réglage de chaque memory group (Always on, Normal ou Never) détermine ce que cette recherche peut atteindre. Les dossiers ne sont indexés qu'une fois ajoutés depuis l'écran Indexes.

Où tout cela est-il stocké ?
Les souvenirs et les leçons des agents sont conservés sur votre appareil, et les leçons ne sont jamais envoyées en ligne. Les memory groups peuvent être personnels ou partagés à l'échelle du workspace, et se trouver sur cet appareil ou dans le cloud ; l'écran Memory affiche les compteurs pour les deux.

Quelle différence entre Chat History, Sessions et Lessons ?
Chat History est la transcription de ce qui a été dit, Sessions montre ce que les agents ont retenu de chaque étape, et Lessons sont les règles que les agents suivront la prochaine fois. Les deux premiers sont des éléments que vous pouvez vérifier ; les Lessons sont des consignes que vous pouvez retirer ou restaurer.

Ai-je besoin de l'application de bureau ?
Pour tout ce qui lit votre propre ordinateur, oui : l'indexation de dossiers, l'import de fichiers dans Notes, Chat History et les vues de mémoire des agents fonctionnent dans l'application de bureau, disponible sur la page de téléchargement.

Ce que fait Local Model dans osFoundry, du choix d'un modèle open source à son fine-tuning sur votre propre machine

tauchiii — Fri, 06 Nov 2026 17:26:50 +0000

Jeudi, 16 h 40, un projet de contrat est ouvert dans une fenêtre. Vous aimeriez qu'une IA resserre la formulation, mais le document ne doit pas quitter votre portable, et vous ne savez pas lequel des centaines de modèles ouverts de Hugging Face tiendrait seulement dans 16 Go de mémoire. Et vous n'avez aucune envie de passer la soirée dans un terminal pour le découvrir.

Un seul groupe dans la barre latérale pour tout ce que vous faites avec des modèles ouverts

Local Model est la partie d'osFoundry consacrée aux modèles à poids ouverts qui tournent sur du matériel que vous contrôlez. Elle apparaît dans la barre latérale de l'application de bureau comme une catégorie à part, divisée en trois sous-titres : Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks) et Measure (Eval, Benchmarks, Safety). Si vous avez déjà utilisé Ollama ou LM Studio, la partie Run vous semblera familière : trouver un modèle, le télécharger, discuter avec. La différence, c'est que le même groupe permet aussi de réduire un modèle, de le fine-tuner sur vos propres exemples et de le tester avec vos propres questions, si bien que toute la vie d'un modèle reste dans une seule application. L'inférence en local s'appuie sur un serveur llama.cpp intégré, donc rien à installer à côté. Ce guide couvre les neuf écrans que la plupart des gens utilisent : Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval et Benchmarks.

Premier aperçu d'Explore

C'est par Explore que la plupart des gens commencent, et sa disposition montre la logique de toute la catégorie : votre machine d'abord, les modèles ensuite.

Le panneau Filters à gauche regroupe les tâches Hugging Face (Text Generation, Summarization, Translation, Embeddings, plus les groupes Multimodal, Vision et Audio) et propose un champ de recherche.
Le bandeau du haut lit votre machine avant d'afficher quoi que ce soit. Dans l'exemple ci-dessus, il indique 16 Go de mémoire unifiée, environ 12 Go utilisables pour un modèle, environ 9 Go libres à cet instant, et précise que les estimations supposent Q4_K_M et un contexte de 4K.
Chaque carte de modèle porte un badge de compatibilité : vert Fits, orange Tight, rouge Too big, chacun avec une estimation de la mémoire. Rien n'est masqué ; les modèles qui tiennent sont simplement listés en premier.
Les boutons Providers et My Registry en haut à droite mènent aux fournisseurs d'API cloud et aux modèles que vous avez déjà.
Un clic sur une carte ouvre sa fiche, où Install Locally télécharge une version du modèle, généralement un GGUF quantifié correspondant au badge.

Trois personnes, trois usages

Une développeuse indépendante avec un seul portable

Maya développe des projets perso sur un MacBook de 16 Go. Elle veut un modèle local pour rédiger ses messages de commit et de courtes notes, surtout pour pouvoir travailler hors ligne dans le train.

Elle ouvre Explore, filtre sur Text Generation et ignore tout ce qui a un badge rouge. Deux candidats sont en vert, elle installe donc les deux avec Install Locally. Puis elle ouvre Playground, tape un prompt et ajoute les deux modèles comme panneaux. Playground envoie le même prompt à deux à quatre modèles en même temps et affiche les réponses côte à côte, avec le temps jusqu'au premier token et le nombre de mots sous chaque panneau.

Plus tard, elle trouve un modèle qui lui plaît mais qui n'existe qu'en fichier F16 pleine précision. Environ 15 Go, trop gros pour son portable. Dans Quantize, elle le sélectionne sous "The model to shrink", choisit Q4_K_M, le niveau que l'application recommande à la plupart des gens, et lance l'opération. Le llama-quantize intégré réécrit le fichier sur sa machine ; rien n'est envoyé.

Dans l'exemple ci-dessus, le résultat fait 4.58 GiB, soit 3.3 fois moins que l'original. Avant de s'y fier, elle clique sur Measure quality, qui compare le nouveau fichier à l'original et remplit les colonnes "same top token" et KLD moyenne du tableau Compare, puis sur Measure speed pour les tokens par seconde. Un clic sur Try it in Playground le remet à côté des deux autres. Elle termine la soirée avec un modèle qui tient, des chiffres qui montrent ce que la réduction a coûté, et aucun historique de terminal.

Une petite équipe avec un poste fixe puissant

Une agence de quatre personnes a au bureau un poste fixe avec beaucoup de mémoire et plusieurs portables légers. Les gros modèles ne tiennent que sur le poste fixe, mais tout le monde veut s'en servir.

Sur le poste fixe, quelqu'un ouvre Servers, sélectionne This Mac et va dans l'onglet Access. Il coche "Allow access from other devices on the local network (LAN)" et active Remote Access. Le panneau liste alors tous les modèles locaux que la machine va servir. Sous Device keys, il clique sur New key, lui donne le nom du portable d'un collègue et clique sur Create key ; chaque clé peut être révoquée individuellement, et une clé limitée à l'inférence peut exécuter des modèles sans accéder aux sessions d'agents.

Sur chaque portable, le collègue ouvre Servers, clique sur Add Server, saisit l'adresse du poste fixe, colle la clé et utilise Test Connection. Une fois connecté, les modèles du poste fixe apparaissent dans le sélecteur de modèles du portable comme n'importe quel autre. L'application signale elle-même que ce trafic passe en HTTP non chiffré : c'est donc prévu pour des réseaux de confiance, comme le LAN du bureau.

Quelqu'un ouvre ensuite Benchmarks, clique sur New Benchmark, choisit le modèle et garde la suite Quick. Le test enregistre les tokens par seconde, le temps jusqu'au premier token et la latence, ce qui permet à l'équipe de savoir si le modèle partagé est assez rapide pour s'en servir pendant les appels ou seulement pour des traitements de nuit. Si c'est lent, Servers propose aussi un onglet Config où l'on peut définir un petit modèle brouillon sous Speculative Decoding, puis cliquer sur Restart now et relancer le benchmark pour comparer.

L'équipe se retrouve avec une machine qui fait le gros du travail, une clé par portable qu'on peut retirer sans déranger les autres, et une réponse mesurée à la question « est-ce assez rapide ? ».

Un responsable des opérations qui ne code pas

Ken gère le service client d'une petite boutique en ligne. Il a deux questions : quel modèle lit correctement les totaux des factures, et un modèle peut-il apprendre à répondre avec le ton de la boutique ?

Pour la première, il va dans Eval et clique sur Custom Benchmark. Il le nomme, colle dix factures avec le total attendu pour chacune, garde Exact Match et clique sur Create Benchmark. Ensuite, New Eval Run : il coche deux modèles de son ordinateur, coche son benchmark et clique sur Start Evaluation. Les questions sont envoyées à chaque modèle sur sa propre machine.

Dans cet exemple, un modèle obtient 90 et l'autre 70, et la colonne Diff affiche l'écart de 20 points. C'est un résultat sur ses propres documents, pas le classement de quelqu'un d'autre.

Pour la question du ton, il rassemble quelques centaines d'anciens messages clients avec les réponses que l'équipe a réellement envoyées, une paire par ligne. Dans Datasets, il peut importer ce fichier, ou chercher des données publiques via l'onglet Hub, puis utiliser "Use for Training" pour le transmettre. Dans Training, il clique sur New Job et passe les quatre étapes : Base Model, Dataset, Config et Review. Sous Training Target, il choisit Local (This Device), que l'écran décrit comme exécuté sur le GPU de l'appareil et gratuit, avec LoRA comme méthode.

Après Start Training, la tâche affiche sa loss pendant l'exécution. Une fois terminée, l'adaptateur entraîné apparaît dans My Models à côté du modèle de base dont il est issu, et "Chat with your model" sur l'exécution terminée le prépare pour le runtime local afin qu'il puisse lui poser une question dans Playground. Il repart avec un petit modèle privé et un benchmark qu'il peut relancer chaque fois qu'il envisage un nouveau modèle.

Où Local Model passe le relais

La catégorie ne vit pas en vase clos. Les modèles que vous installez ou connectez apparaissent dans la même liste de modèles que celle du chat : un modèle local peut donc répondre à une conversation normale ou être comparé dans Playground à un modèle cloud que vous avez ajouté sous Providers. Depuis Explore, "Use in Notebook" ouvre un notebook JupyterLab configuré pour ce modèle, en local ou sur une instance hébergée. Quand un modèle a besoin d'un vrai GPU plutôt que de votre portable, Deployments et Cloud GPU prennent le relais et le placent sur un endpoint managé. Avant qu'un modèle ne soit exposé aux clients, Safety exécute des suites de tests red team contre un modèle déployé. La page sur l'inférence locale détaille le moteur embarqué, et la page sur le fine-tuning LoRA couvre la partie entraînement.

Les premières questions qu'on nous pose

Faut-il un GPU ou un PC gamer ?
Non. Un portable récent suffit pour les petits et moyens modèles ; les badges d'Explore vous disent ce que votre machine peut accueillir avant de télécharger. Un poste fixe plus puissant ou un serveur distant élargit simplement la liste.

Est-ce que quelque chose part dans le cloud ?
L'inférence locale, Quantize et l'entraînement local tournent sur votre machine. L'entraînement sur Cloud GPU, les endpoints Cloud GPU et Providers sont les parties qui font appel à des services externes, et les écrans l'indiquent, par exemple "Managed cloud GPU · needs credits" dans la boîte de dialogue d'entraînement.

Quelle différence entre Eval et Benchmarks ?
Eval note la qualité des réponses à partir de questions que vous définissez. Benchmarks mesure la vitesse et la mémoire : tokens par seconde, temps jusqu'au premier token et latence.

Où trouver l'application ?
Local Model fonctionne dans l'application de bureau, disponible sur osfoundry.io/fr/download.

Qu'est-ce qu'osFoundry et comment cet espace de travail IA pour le bureau est-il organisé ?

tauchiii — Fri, 06 Nov 2026 15:54:47 +0000

Lundi, 9 h 40, quatre onglets ouverts dans le navigateur : un chatbot pour les questions, un deuxième parce que vous ne faites pas entièrement confiance au premier, un éditeur avec un agent de code et une appli de notes qui contient les recherches de la semaine dernière. Chacun connaît une partie de votre travail, aucun ne connaît le reste. Avant midi, vous avez déjà copié le même paragraphe de contexte dans trois fenêtres différentes.

Une seule appli au lieu de cinq onglets

osFoundry est un espace de travail IA pour le bureau : une appli où vous discutez avec des modèles d'IA, confiez du travail à des agents et à des équipes d'agents, gardez des notes et des connaissances consultables, faites tourner des modèles ouverts sur votre propre ordinateur et créez de petites applis pour votre équipe. Les modèles peuvent venir de trois sources : votre propre machine, des fournisseurs cloud via vos propres clés d'API, ou des GPU cloud loués. L'appli est organisée en catégories, et chaque catégorie regroupe plusieurs écrans. Chat sert à parler aux modèles (Maestro, Multi chat, Branchspace et d'autres). Workstation, c'est là que les agents font les tâches longues (Code, Agent, Agent team, Loop, Terminal). Knowledge contient vos écrits et ce que l'IA retient. Local Model sert à trouver, installer et tester des modèles ouverts. Custom App est destiné aux outils internes, et Discover à la recherche web et à l'actualité. Si vous connaissez VS Code, la comparaison la plus proche est un éditeur avec une barre d'activité où chaque icône ouvre un outil différent, sauf qu'ici les outils sont des surfaces d'IA qui partagent les mêmes projets, la même mémoire et les mêmes modèles.

À quoi ressemble un écran type

La plupart des gens commencent par la catégorie Chat, c'est donc un bon point de départ pour comprendre comment sont construits les écrans d'osFoundry. Voici Multi chat en mode Council, avec des données d'exemple : on a posé la même question à trois modèles, puis chacun a noté les réponses des autres.

La rangée d'onglets en haut (Maestro, Model chat, Multi chat, Research, Wiki, Code) bascule entre les surfaces de l'espace Chat : l'agent Maestro complet, un chat simple de questions-réponses avec sources citées, plusieurs modèles à la fois, la recherche approfondie, la documentation de code et les agents de code.
Le sélecteur Compare / Council détermine comment les modèles travaillent ensemble. Compare affiche les réponses côte à côte pour que vous jugiez vous-même. Council les fait répondre séparément, se classer mutuellement à l'aveugle, puis rédige une synthèse.
Chaque colonne correspond à un modèle avec une étiquette de fournisseur : ici Anthropic, Ollama (en local) et OpenAI. Vous pouvez mélanger modèles cloud et modèles locaux sur le même écran.
Le panneau de droite affiche les étapes de l'exécution (Answers, Ranking, Synthesis) et la grille Peer review, pour voir qui a donné quelle note au lieu de lire seulement une réponse finale.
Le bouton Run indique combien d'appels aux modèles l'exécution va faire avant même que vous cliquiez (« Run · 7 calls » ici). Désactiver le classement par les pairs fait baisser ce chiffre.

Beaucoup d'écrans d'osFoundry suivent ce schéma : une liste à gauche, le travail au centre et, à droite, un inspecteur qui montre comment un résultat a été obtenu.

La première semaine d'un développeur solo

Ken gère seul une petite boutique en ligne. Il veut une IA qui connaisse son code et aimerait garder une partie du travail sur son portable.

Lundi, il ouvre Local Model, puis Explore. L'écran analyse d'abord sa machine (16 Go de mémoire dans cet exemple) et colle un badge sur chaque modèle ouvert : Fits, Tight ou Too big. Il installe un modèle au badge vert et lui pose quelques questions dans Playground, qui envoie le même prompt à deux modèles côte à côte et montre à quelle vitesse chacun a commencé à répondre.

Mardi, il doit modifier une fonction de formatage des prix et ne sait pas trop ce qui en dépend. Il ouvre le projet dans l'IDE, fait un clic droit sur la fonction et choisit Show Code Graph.

Le panneau liste tous les appelants, indique quels liens ont été lus directement dans le code et lesquels sont seulement déduits, et résume l'Impact of change : combien de symboles, de fichiers et de tests pourraient être touchés. Il clique sur un appelant pour sauter à la ligne concernée et utilise Send to chat pour amener le graphe dans une conversation avec Maestro.

Jeudi, il confie déjà de petites tâches à des agents de code. Dans l'écran ADE, chaque tâche a son propre worktree, et l'onglet Changes affiche le diff. Il clique dans la marge à côté d'une ligne qui ne lui plaît pas, tape une note et envoie d'un coup à l'agent toutes les notes en attente. Il termine la semaine avec un modèle local en qui il a confiance pour les questions rapides, et le réflexe de vérifier l'impact avant de refactoriser.

La première semaine d'une responsable de petite équipe

Aiko encadre quatre personnes et livre une version toutes les deux semaines. Son problème n'est pas d'écrire du code, mais de savoir ce que fait chacun, humain ou agent.

Elle commence par Message, le chat d'équipe. Les canaux et les messages privés fonctionnent comme dans Slack, à une différence près : les agents IA sont membres des canaux. Quelqu'un mentionne un agent avec @ dans #release, et sa réponse comme son exécution reviennent dans le canal, où tout le monde peut les voir.

Ensuite, elle configure une Agent team dans Workstation. Un agent leader coordonne des membres spécialisés, et l'écran range Team mail, Handoffs, Sub-agents et Proposals dans des onglets séparés, ce qui lui permet de vérifier qui a transmis quoi à qui. Pour les contrôles qui reviennent à chaque version, elle transforme cette équipe en Loop : un déclencheur (par exemple, les matins en semaine), des limites de tours et de nouvelles tentatives, et des critères de réussite. Le Loop tourne par tours jusqu'à ce que les critères soient remplis et tient un registre de ceux qui ont été validés à chaque tour.

Quand plusieurs agents travaillent sur le même dépôt, elle utilise Code. Chaque agent a sa propre branche et son propre worktree, et rien n'est fusionné automatiquement. Elle sélectionne deux exécutions terminées, clique sur Preview combined merge et voit quels fichiers entrent en conflit avant que quoi que ce soit ne touche la branche principale.

Pour la revue ligne par ligne, elle utilise les mêmes notes que Ken : une note épinglée au code, envoyée à l'agent avec le fichier, la ligne et le code joints. À la fin de la semaine, elle dispose d'un canal où apparaît le travail des agents, d'un contrôle de version qui tourne tout seul et d'une étape de revue qui a lieu avant les fusions, pas après.

La première semaine d'une chercheuse et rédactrice

Lena rédige de longs rapports sur les politiques en entreprise. Elle a besoin de sources vérifiables, et des réponses d'IA trop sûres d'elles lui ont déjà joué des tours.

Pour les questions où la réponse d'un seul modèle ne suffit pas, elle utilise Multi chat en mode Council, l'écran présenté plus haut. Quand deux évaluateurs notent mal une réponse, elle sait qu'il faut creuser.

Pour les questions plus vastes, elle ouvre Agents, clique sur New session et choisit la Deep Research Team toute prête. Le leader découpe la question en parties et confie chacune à un membre, par exemple un Data Researcher ou un Search Specialist.

Un évaluateur distinct vérifie chaque étape avant qu'elle ne lui parvienne, et une étape sans source est renvoyée et relancée. La réponse finale arrive sous forme de tableau avec une source sur chaque ligne, plus une courte note sur les points où les sources divergent et sur ce qui n'a pas été couvert (données d'exemple dans la capture).

La rédaction elle-même se passe dans Knowledge. Dans Paper, elle surligne une phrase de son brouillon et y rattache un espace de réflexion, avec des onglets comme Academic search, Browser ou une session Maestro consacrée uniquement à ce passage. Les fichiers annexes et les commentaires vivent dans une Note. Dans Discover, elle enregistre des recherches dans Browser et suit des canaux par mot-clé dans News, si bien que ce qu'elle lit pour un rapport reste disponible pour le suivant.

Comment les espaces se passent le travail

Les catégories ne sont pas des produits séparés : elles se transmettent le travail. Local Model est la couche du dessous : un modèle installé depuis Explore apparaît dans les sélecteurs de modèle de Maestro, de Multi chat et des sessions d'agents.

Knowledge alimente Chat : Memory montre ce que Maestro sait de votre travail, et Indexed Folders vous permet de choisir dans quels dossiers les agents peuvent chercher. Les sessions d'agents, les exécutions d'Agent team et les Loops remontent dans les canaux de Message. Workstation (l'écran qui porte ce nom) vous permet d'ouvrir un canal, une note, un fichier et une session d'agent côte à côte dans une même disposition. Quand quelque chose que vous avez construit avec des agents doit devenir un outil pour l'équipe, il passe dans Custom App, où une Room réunit les applis d'une équipe à côté de son propre chat Maestro. Les clés et les fournisseurs pour tout cela se trouvent dans Configuration. La vue d'ensemble de la plateforme liste tous les écrans si vous voulez la carte complète.

Les questions de la première semaine

Dois-je tout utiliser ?
Non. La plupart des gens commencent par un seul espace, généralement Maestro dans Chat ou Explore dans Local Model, et en ajoutent d'autres quand une tâche l'exige. Les catégories partagent projets et mémoire, donc rien de ce que vous faites au début n'est à refaire plus tard.

Mes données quittent-elles mon ordinateur ?
Pas avec les modèles locaux : ils tournent sur votre appareil. Les modèles cloud que vous connectez avec vos propres clés d'API voient ce que vous leur envoyez, et cet usage est facturé par le fournisseur. La page local-first explique comment les deux sont séparés.

Est-ce réservé aux développeurs ?
Non. Code, IDE et Terminal sont des outils de développeur, mais Message, Paper, Note, Research, Multi chat et Discover sont aussi conçus pour les rédacteurs, les analystes et les responsables d'équipe.

Combien ça coûte ?
L'appli de bureau se télécharge gratuitement, et faire tourner des modèles locaux n'entraîne aucun frais d'utilisation côté osFoundry. Elle est disponible sur la page de téléchargement.

Comment Code, l'IDE et Wiki d'osFoundry gardent le travail de plusieurs agents IA en parallèle facile à relire

tauchiii — Fri, 06 Nov 2026 15:30:55 +0000

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.

Comment créer et héberger de petites apps internes avec Custom App d'osFoundry

tauchiii — Fri, 06 Nov 2026 14:58:58 +0000

On est jeudi, deux heures avant une mise en production, et Dari est la seule personne à savoir quelles étapes du cutover sont déjà faites. La checklist est dans un onglet de tableur, le runbook sur un drive partagé et la discussion dans un fil de chat que personne ne retrouve. Ce dont l'équipe a vraiment besoin, c'est d'une toute petite app avec quatre cases à cocher et deux responsables, juste à côté des fichiers. L'écrire est facile. L'héberger, lui donner une base de données, protéger ses clés et lui obtenir une URL, c'est là que ça bloque d'habitude.

Ce qu'est la catégorie Custom App

osFoundry regroupe tout ce qu'il faut pour créer et faire tourner vos propres petites apps dans une seule catégorie de la barre latérale de l'app de bureau, appelée CUSTOM APP. Elle compte cinq écrans. Room est l'espace partagé où les apps vivent sous forme d'onglets. App Code est le dépôt qui se trouve derrière une app. Deployed Apps est la liste, à l'échelle du workspace, de ce qui est en ligne. Snippets rassemble les mini-apps qui n'ont jamais eu besoin de dépôt. Domains gère les adresses web depuis lesquelles ces apps sont servies. Si vous connaissez Notion, imaginez une page dont les onglets sont des apps qui fonctionnent plutôt que des documents, avec une petite couche d'hébergement façon Vercel en dessous : chaque app a sa propre base de données, ses secrets, ses tâches planifiées et un sous-domaine, comme décrit sur la page de la fonctionnalité apps internes.

Un coup d'œil à l'écran de construction

Le moyen le plus rapide de voir comment une app démarre, c'est la vue de construction de l'app de bureau. Cette capture vient du constructeur Websites (projet d'exemple « Hearth Bakery »), qui utilise la même boucle « décrire puis construire » que propose une Room avec sa zone « Describe the app you want ».

Pages, à gauche : les parties de l'app qui existent déjà, avec Add page en bas.
L'aperçu, au centre : ce que vous êtes en train de construire, avec les tailles bureau, tablette et téléphone au-dessus. Le libellé « On this computer » indique que rien n'a encore été publié.
La zone de description : vous écrivez ce que fait l'app, à qui elle s'adresse et l'impression qu'elle doit donner, puis vous cliquez sur Build my site. Maestro, l'assistant IA de l'app, écrit les fichiers.
Le panneau Maestro, à droite : la conversation qui construit et modifie l'app. Use a folder lui donne votre propre matériel au lieu de le laisser deviner.
Publish needs credits, en haut : la construction et l'aperçu se font sur votre ordinateur ; l'hébergement est l'étape qui consomme des crédits du workspace.

Dans une Room, c'est la même idée avec une autre disposition : une barre d'onglets d'apps en haut, l'app sélectionnée au centre et un panneau de droite avec deux onglets, Maestro et Details.

Cas d'usage 1 : une équipe de release garde sa checklist là où se fait le travail

Qui : une release manager et trois coéquipiers qui préparent un lancement.

La situation : les étapes du cutover, le runbook et le suivi de release sont répartis sur trois outils, et le jour J, personne ne fait confiance au tableur.

Ce qu'ils font dans osFoundry :

Créer une room appelée « Launch Ops » avec New Room, puis y ajouter le suivi de release et les fichiers du lancement sous forme d'onglets.
Cliquer sur le bouton + de la barre d'onglets. Le sélecteur New Tab liste les apps installées et un catalogue (Incident log, Retro board, On-call rota, Changelog builder), filtrable par All, Forked ou Snippets.
Dans « Describe the app you want », cliquer plutôt sur Build a snippet et demander une checklist de cutover avec un responsable par étape. Un snippet est une mini-app exécutable composée de quelques fichiers. Il n'a ni dépôt, ni version, ni déploiement, et il tourne directement dans l'onglet.
Continuer à échanger avec Maestro dans le panneau de droite pendant que la checklist est ouverte, et utiliser l'onglet Details pour voir ce qu'est la room et ce qui s'y est passé.

Résultat : une seule room où la checklist (dans la démo : Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) se trouve à côté du runbook et du suivi. Plus tard, l'écran Snippets liste tous les snippets de toutes les rooms. De là, on peut en exporter un en JSON avec Export pour un autre workspace, ou le transformer en vrai dépôt avec Promote quand il devient trop grand pour son onglet.

Cas d'usage 2 : un développeur donne un vrai backend à un outil interne

Qui : un développeur seul qui construit un outil d'inscriptions et de commandes pour l'équipe support.

La situation : la première version tournait sur un portable avec un fichier SQLite. Maintenant trois équipes en ont besoin, elle doit appeler une API de paiement et un nettoyage nocturne doit s'exécuter sans que personne ait à penser à cliquer sur un bouton.

Ce qu'il fait dans osFoundry :

Tant que l'app tourne encore en local, ouvrir le projet dans l'IDE et cliquer sur l'onglet Database. Il trouve les fichiers .db et .sqlite de l'app et ouvre une table en lecture seule, 200 lignes par page (données d'exemple ci-dessus), pour voir ce que l'app a réellement enregistré avant de déplacer quoi que ce soit.
Déplacer l'app dans une room partagée. La boîte de dialogue Move to cloud copie l'app dans une Cloud room pour que tous ses membres puissent l'utiliser, et indique quelles tables ont été copiées et lesquelles sont restées sur l'appareil. L'app et ses données restent aussi sur cet appareil.
Ouvrir les paramètres de l'onglet de l'app. Sous Secrets, App Runtime Secrets liste les clés que déclare l'app ; Add a custom secret en enregistre une nouvelle et Rotate remplace une valeur. L'app affiche alors « Secrets updated. Redeploy to apply changes. »
Déclarer le nettoyage sous container.cron dans le manifeste de l'app, puis ouvrir Scheduled jobs et cliquer sur Sync from manifest. Chaque tâche peut être mise en pause, reprise ou lancée une fois avec Run now.

Résultat : une app avec sa propre base Postgres. Sur osFoundry, chaque Room App en a une, avec pgvector et TimescaleDB installés, et la chaîne de connexion arrive sous forme de secret à l'exécution (Postgres par app). L'explorateur de base de données propose un éditeur de lignes avec filtres et une vue SQL limitée à SELECT, et Database snapshots offre New snapshot, Restore et un lien de téléchargement. Les modifications de code se font dans App Code, où le développeur peut travailler sur une version comme version/2.4 sans toucher à main, vérifier le Manifest (point d'entrée, visibilité, connecteurs requis) et suivre l'arbre Versions avant de livrer.

Cas d'usage 3 : une commerçante publie une page et garde un œil dessus

Qui : quelqu'un qui tient une petite boulangerie et ne code pas.

La situation : elle veut un site simple avec la carte et les horaires, sur sa propre adresse, et elle veut savoir combien coûte sa mise en ligne.

Ce qu'elle fait dans osFoundry :

Ouvrir Websites, cliquer sur New Website, décrire la boulangerie et cliquer sur Build my site. La première version (ci-dessus, exemple) utilise des textes provisoires, et Maestro le dit clairement.
Cliquer sur Use a folder, choisir le dossier avec la vraie carte et les photos, puis demander des changements avec des mots simples, comme « Make the headline bigger. »
Quand le résultat convient, publier. L'hébergement consomme des crédits du workspace. Who can open it propose Workspace members only, Anyone with the link ou la connexion propre à l'app ; un site de boulangerie public utilise Anyone with the link.
Dans Domains, enregistrer un domaine ou en ajouter un qu'elle possède déjà, puis modifier ses enregistrements DNS. Events montre qui a modifié quel enregistrement, et Settings regroupe le renouvellement, la confidentialité et le code de transfert.

Résultat : un site avec ses propres textes et photos, servi sur son propre domaine. Deployed Apps répond ensuite aux questions qu'une commerçante se pose vraiment. Apps montre chaque app et où elle est servie, Activity ce qui a changé, Usage le coût de build et de stockage par app, et Previews liste les versions d'aperçu encore actives.

Comment ça s'articule avec le reste d'osFoundry

Custom App fonctionne rarement seul. Maestro est l'assistant du panneau de droite de chaque Room et des vues de construction ; il écrit et modifie le code avec vous. L'IDE fournit l'onglet Database, le contrôle de version et l'éditeur pour les apps qui commencent comme un dossier sur votre ordinateur. Websites est un chemin plus rapide quand l'« app » est en réalité un site public. Les Snippets ne sont reliés à App Code que par Promote, si bien qu'un outil jetable peut devenir un dépôt maintenu sans être réécrit. Les tâches planifiées à l'intérieur d'une app sont prises en charge par les cron jobs d'app, décrits sur la page plateforme consacrée à app cron.

Les questions des nouveaux venus

Une Room, c'est un salon de discussion ?
Non. Le cœur d'une Room, ce sont ses onglets d'apps. Le chat Maestro se trouve dans le panneau compagnon à droite, à côté des Details de la room.

Quand faut-il créer un snippet plutôt qu'une app ?
Quand l'outil tient en quelques fichiers et n'a besoin de tourner que dans une seule room, comme un formateur de dates ou une vérification de webhook. Enregistrer un snippet n'installe rien et ne déploie rien. Si plus tard il lui faut des versions, des secrets ou une base de données, transformez-le en dépôt avec Promote.

Deux apps peuvent-elles partager une base de données ?
Chaque app a son propre Postgres. Le partage passe par des autorisations explicites : l'onglet Database de la room affiche Incoming Requests, Active Grants et Outgoing Access, et chaque demande peut être approuvée ou refusée.

Est-ce que l'essayer coûte quelque chose ?
Construire et prévisualiser sur votre ordinateur ne demande aucun crédit. Publier, déployer et enregistrer des domaines consomme des crédits du workspace. Vous pouvez télécharger l'app de bureau sur osfoundry.io/fr/download.

Ce que fait Agent team dans osFoundry, et quand un seul agent suffit

tauchiii — Fri, 06 Nov 2026 13:24:41 +0000

Il est 7 h 40 un mardi matin, et Priya a une question à laquelle sa directrice veut une réponse avant midi : la semaine de quatre jours maintient-elle vraiment la production ? Elle pourrait la coller dans un chatbot et récupérer un paragraphe très sûr de lui. Mais le modèle qui trouve les chiffres serait aussi celui qui juge s'ils tiennent la route, et il se contredit rarement. Ce qu'elle veut, c'est qu'une personne trouve les essais, qu'une autre extraie les chiffres, et qu'une troisième renvoie tout ce qui n'a pas de source.

Deux entrées vers le même écran

osFoundry est une application de bureau pour faire tourner du travail d'IA sur votre propre machine, et elle propose deux façons très proches de confier du travail à des agents. Agent (affiché dans la barre latérale sous le nom Single agent) est un agent nommé avec un seul objectif : vous lui donnez des instructions, il reçoit son propre identifiant, par exemple AG-0001L, et chacune de ses exécutions est enregistrée pour que vous puissiez la suivre ensuite. Agent team place un leader à la tête d'une équipe de membres spécialisés. Le leader planifie le travail, confie chaque étape à un membre, et un relecteur vérifie chaque étape avant qu'elle ne vous parvienne. Les deux se trouvent dans la barre latérale, sous Agents, l'un à côté de l'autre, et ouvrent le même écran. Ce qui change, c'est la taille de l'équipe. Si vous avez déjà participé à un chat de groupe avec un chef de projet, Agent team vous paraîtra familier. La différence, c'est que chaque message, chaque passage de relais et chaque verdict est conservé, et que vous pouvez remonter le fil.

Un tour de l'écran d'équipe

Voici une session d'équipe terminée. La question et la réponse sont des données d'exemple issues d'une exécution de démonstration.

La conversation avec le leader (au centre). L'en-tête indique "Leader · Orchestrate your team". C'est là que vous posez la question une seule fois et là qu'arrive la réponse combinée, ici sous forme de tableau avec une source sur chaque ligne, une ligne "Where sources disagree" et une ligne "Not covered".
Onglets de session (en haut du centre). Chat, Team mail, Email, Handoffs, Sub-agents, Proposals et Files. Handoffs montre qui a passé du travail à qui. Proposals regroupe les modifications que les agents suggèrent sur des fichiers ou des réglages. Une suggestion n'est appliquée qu'une fois acceptée.
Panneau Agent session (à droite). Une carte par membre, avec ce que le leader lui a demandé, les outils appelés (web_fetch, web_search) et le résultat. Sous chaque résultat, on voit le verdict du relecteur, par exemple "Approved". En haut se trouvent un sélecteur d'exécution ("Run 1 · 07:40 AM") et un bouton Cards / Graph.
Onglet Team roster. C'est la liste de qui a le droit d'agir dans cette session. Une équipe est une liste de membres, pas un workflow. L'ordre du travail vient du plan du leader.
Le rail des sessions (à gauche, masqué ici) et l'inspecteur. Le rail liste chaque session avec son identifiant. L'inspecteur a les onglets Goal, Trigger et Hooks : pour l'objectif à atteindre, ce qui a lancé l'exécution et les vérifications autour du travail.

Trois façons de s'en servir

Une chercheuse qui veut une source pour chaque chiffre

Priya ouvre Agent team et clique sur New session. Dans la boîte de dialogue New team session, elle garde "Start from a team" et choisit Deep Research Team dans la liste Team. La boîte de dialogue charge ses cinq membres (deep-research-agent, research-analyst, data-researcher, search-specialist, academic-researcher). Sous "Who leads" apparaît Orchestrator, qui "plans the work up front, then delegates the steps to the agents below". Elle pourrait cliquer sur "make leader" sur n'importe quel membre pour le mettre aux commandes.

Elle clique sur Create, tape sa question dans le chat du leader et l'envoie. Le leader la découpe en cinq parties : trouver les essais, les études, les chiffres, les contre-arguments, puis une seule réponse. Trois membres démarrent en même temps. Le Data Researcher attend la liste du Search Specialist avant d'extraire des chiffres. Quand le Data Researcher remonte un chiffre de 40%, le relecteur le marque "Sent back", au motif qu'il n'a ni source, ni date, ni indicateur. L'étape est relancée, trouve la source, et elle est approuvée.

Au final, elle obtient une seule réponse dans le panneau central, et chaque chiffre a été vérifié par quelqu'un d'autre que l'agent qui l'a trouvé. Elle a aussi une ligne "Not covered" honnête qu'elle peut coller dans sa note pour la directrice.

Un développeur indépendant qui colle toujours les mêmes instructions

Tom transforme des notes de réunion en actions à faire plusieurs fois par semaine, et à chaque fois il colle d'abord le même paragraphe de règles dans un chat. Ce travail n'a pas besoin d'une équipe. Il a besoin d'un agent qui se souvient des règles.

Il ouvre Single agent, clique sur New session et reste sur l'onglet Create in chat. Dans le champ "New agent", il écrit une ligne sur ce dont il a besoin et clique sur Start. Le chat qui s'ouvre est un agent de configuration. Il pose quelques questions, puis propose un nom, un @handle et des instructions complètes. Une carte apparaît au-dessus de la zone de saisie avec le nom, le handle, un lien Show instructions et un bouton Create agent.

Il ouvre les instructions et vérifie que la règle qui compte le plus pour lui y figure : ne jamais deviner un responsable ou une échéance. Puis il clique sur Create agent. Ce même chat devient l'agent. Quand il colle ses notes, les responsables et les dates manquants sont signalés comme manquants, jamais devinés. La session garde son Agent ID dans le rail, et la prochaine fois il n'a qu'à choisir l'agent.

Une responsable des releases qui veut savoir qui a fait quoi

Dari gère les releases d'une petite équipe produit. Sa session d'équipe comprend un leader et des membres nommés Release Drafter, Change Auditor, Docs Reviewer, QA Summarizer et Approval Prep. Chacun s'occupe d'une partie du paquet de release.

Avant l'exécution, elle ouvre l'onglet Goal et clique sur Set a goal. Le panneau explique qu'un objectif est découpé en critères de réussite qui démarrent en échec et passent au vert à mesure que les agents les remplissent. La session continue jusqu'à ce qu'ils passent tous ou qu'elle atteigne sa limite de tours. Elle écrit trois critères, le dernier étant que le dossier d'approbation soit complet. Pendant que les membres travaillent, elle consulte Handoffs pour suivre la chaîne du leader vers chaque membre et retour. Elle regarde aussi Proposals pour repérer un changement de configuration suggéré par un membre, et rien n'y est appliqué sans elle. Elle peut orienter le leader à tout moment en répondant dans son chat, et Pause, dans l'en-tête du panneau, met l'exécution en attente pendant qu'elle relit.

À la fin, elle a un paquet de release et un historique de qui a rédigé, audité et approuvé chaque partie. Elle peut le montrer à quiconque demande comment une ligne s'est retrouvée dans les notes.

Où cela mène dans le reste de l'application

Agent et Agent team, c'est là que le travail commence. Sessions, c'est là qu'on le suit. Ce tableau affiche chaque session de chat, d'agent, d'équipe et de terminal sous forme de carte, rangée dans Running, Needs you, Paused, Idle, Done et Failed selon ce que la session fait réellement.

Quand le même travail d'équipe doit tourner encore et encore, Loop enveloppe une équipe avec un déclencheur, des limites et un historique tour par tour des critères validés. Graphs sert pour le travail dont le chemin dépend de ce qui se passe en route. La conversation avec le leader est un chat Maestro, donc la réponse d'une équipe peut se prolonger dans le reste de votre travail dans Maestro. Le lien Enable sync de la session la relie à un canal de messages du projet, où personnes et agents peuvent discuter au même endroit. Pour en savoir plus, voir la page de la fonctionnalité Agents et la présentation des sessions d'agents.

Questions fréquentes des débutants

Quand utiliser un seul agent plutôt qu'une équipe ?
Utilisez un seul agent quand le travail est une tâche claire avec des règles fixes, comme remettre en forme des notes ou rédiger des réponses sur un même ton. Utilisez une équipe quand le travail comporte des parties qui demandent des outils différents, ou quand vous voulez qu'un relecteur distinct vérifie le travail avant que vous le voyiez.

Puis-je modifier l'équipe une fois la session lancée ?
Non. La boîte de dialogue New team session indique que l'équipe "is fixed for this session's life". Dans la boîte de dialogue, vous pouvez encore ajouter ou retirer des agents et choisir qui dirige avant de cliquer sur Create. Pour une autre équipe, lancez une nouvelle session.

Est-ce que quelque chose tourne dans le cloud ?
Le formulaire New session propose des exécutions Local et Isolated. Il précise que les deux tournent sur votre machine avec vos propres clés et que rien ne part dans le cloud. L'historique des chats est local par défaut.

Les agents peuvent-ils réécrire leurs propres instructions ?
Ils peuvent suggérer des modifications, qui apparaissent dans Proposals. Une proposition n'est pas une configuration acceptée. Le fait que les agents puissent toucher à leurs propres prompts est un réglage à part.

Vous pouvez télécharger l'application de bureau sur osfoundry.io/fr/download.