Jeudi, 4 h 40, et Priya a demandé à un assistant IA d'ajouter un bouton « Supprimer le compte » à la page de réglages de son app. La réponse dit « C'est fait, 4 fichiers modifiés. » Avant de livrer, elle veut savoir quels sont ces quatre fichiers, ce que l'assistant a lu pour en décider, et s'il s'est approché du code de facturation. Une fenêtre de chat classique ne lui donne que le dernier paragraphe.

Maestro en un paragraphe

Maestro est l'espace de travail IA avec tous les outils dans l'application de bureau osFoundry. Vous tapez votre demande comme dans n'importe quel chat, mais la réponse arrive avec son cheminement : chaque fichier listé, chaque recherche lancée, chaque fichier lu ou modifié et chaque commande de terminal, chacun sur sa propre ligne avec une durée que vous pouvez déplier. Maestro peut travailler dans un dossier de votre machine, proposer des modifications au lieu de les écrire en silence, et s'arrêter pour vous montrer un plan avant de toucher à quoi que ce soit. Vous le trouvez sous Maestro dans la barre latérale. Si vous avez déjà utilisé ChatGPT ou Claude dans un navigateur, imaginez la même conversation, avec le journal d'activité de l'agent et quelques freins à côté.

Tour d'horizon de l'écran

L'écran de Maestro avec une demande et les premières lignes de processus : TOOL, GREP et READ, chacune avec sa durée (exemple)

  • Les onglets de surface en haut. Maestro, Model chat, Multi chat, Research, Wiki et Code se trouvent tous sur ce même écran. Maestro est l'onglet qui dispose de tous les outils.
  • Les onglets de détail au-dessus de la conversation : Chat, Sources, Files, Changelog, Tools, Pipeline et Logs. Ce sont plusieurs vues d'une même exécution. Sources conserve ce sur quoi la réponse s'appuie, Changelog liste les fichiers écrits par ce chat, et Logs montre les étapes et, sous Costs, le coût de chaque requête.
  • Les lignes de processus dans la transcription. Ici, Maestro a listé src/ (38 fichiers), fait un grep sur deleteUser, trouvé 0 résultat, puis lu account.ts et users.ts. Cliquez sur une ligne et elle s'ouvre pour montrer l'entrée et la sortie exactes de cet appel d'outil.
  • La barre de contrôle au-dessus de la zone de saisie : l'interrupteur de sandbox, Plan OFF/ON, Tools et Goal. Sous la zone se trouvent les sélecteurs de dossier, projet, repo, Router et modèle.
  • Le panneau d'aperçu à droite, où un fichier, un diff ou une page web s'ouvre à côté de la conversation au lieu de la remplacer (Open File / App / Page, Browse Files, Browser).

Trois façons de s'en servir

Une développeuse solo qui veut le plan avant la modification

Le cas de Priya, celui du début. La modification touche aux comptes et aux sessions, elle préfère donc lire un plan plutôt que relire un diff surprise.

  1. Elle clique sur Plan dans la barre de contrôle pour afficher Plan ON.
  2. Elle tape « Add a Delete account button to settings » et l'envoie.
  3. Maestro lit six fichiers et n'en modifie aucun. Tant que le mode plan est actif, l'application de bureau elle-même refuse tout outil qui écrirait un fichier ou lancerait une commande : la « lecture seule » n'est pas une simple consigne polie dans le prompt.
  4. Une carte Plan arrive avec la mention « Awaiting approval » et les boutons Approve et Cancel.

La carte Plan : quatre fichiers à modifier, src/billing/ laissé de côté, six fichiers lus et rien de modifié pour l'instant (exemple)

Le plan de l'exemple nomme quatre fichiers, précise que src/billing/ reste intact parce que Stripe tient ses propres enregistrements, et se termine par « Nothing has been changed yet. » Le mode plan se désactive tout seul à l'arrivée du plan. Priya clique sur Approve, et c'est seulement là que Maestro modifie les quatre fichiers et lance les tests (npm test -- account, 3 passed), le tout visible sous forme de lignes EDIT et TERMINAL. Si le plan ne lui avait pas plu, Cancel aurait laissé le dossier exactement dans son état d'origine.

Ce qu'elle obtient : une modification validée à l'avance, et une transcription qui montre où l'agent a regardé et ce qu'il a exécuté.

Un nouveau coéquipier qui découvre une base de code

Dan a rejoint l'équipe lundi. Il doit trouver où se trouve le blocage après échecs de connexion, mais personne ne l'appelle « lockout » dans le code, donc une recherche textuelle ne donne rien.

  1. Dans Indexes, il ajoute une fois le dossier du projet pour pouvoir le chercher par le sens.
  2. Dans un chat Maestro sur ce dossier, il demande où l'app bloque les utilisateurs après des connexions ratées.
  3. Il suit les lignes de processus : une recherche dans le dossier qui renvoie 2 résultats, puis un READ de throttle.ts.

Maestro répond avec des chemins de fichiers et des plages de lignes après une recherche dans le dossier et un READ de throttle.ts (exemple)

La réponse pointe vers src/auth/throttle.ts (lignes 1–46) et src/routes/session.ts (lignes 22–61), et explique que le code ne dit jamais « lock out » : après cinq tentatives échouées, il fixe un délai d'attente de 15 minutes et renvoie 429 avant même de vérifier le mot de passe. Comme la réponse donne les chemins de fichiers et que les lignes montrent ce qui a été lu, Dan peut ouvrir ces mêmes lignes dans le panneau d'aperçu et vérifier lui-même au lieu de se fier à un résumé. Rien n'est écrit sur le disque dans ce cas, il peut donc laisser Approval Mode sur sa valeur par défaut.

Ce qu'il obtient : les deux fichiers qui comptent, la raison pour laquelle la recherche par mot-clé les a ratés, et un chat qu'il peut retrouver depuis la liste des chats.

Une marketeuse qui modifie des textes dans un repo qui n'est pas le sien

Sammy rédige les textes de la page de lancement, mais la page est un fichier React dans le repo de l'équipe technique. Elle veut que le nouveau texte respecte le guide de ton de docs/, et ne veut rien voir commité sans l'avoir relu.

  1. Elle ouvre le menu Approval Mode du composeur et choisit Permission & Approve, qui demande avant chaque appel d'outil. Les autres choix sont Auto Accept (par défaut, les outils s'exécutent tout de suite), Plan First (planifier avant d'exécuter) et Bypass (aucune validation, y compris pour un push ou l'envoi d'un formulaire).
  2. Elle active la sandbox, pour que les écritures soient préparées sur une branche au lieu d'atterrir dans le dossier de travail.
  3. Elle demande à Maestro de rédiger la page de lancement en restant cohérent avec la doc. Il lit docs/tone.md, cherche dans le code source et propose une modification de src/Launch.tsx.
  4. Le diff s'ouvre dans le panneau d'aperçu. Elle l'accepte, puis utilise Export to branch pour qu'un développeur puisse le relire comme n'importe quelle autre modification.

Ce qu'elle obtient : un texte qui cite le guide de ton suivi (l'onglet Sources le garde), un diff relu, et une branche plutôt qu'une surprise sur main.

La place de Maestro à côté de Model chat, Chat et Multi chat

Maestro partage son écran avec des outils plus simples, et choisir le bon fait gagner du temps et de l'argent.

  • Model chat est un onglet du même écran qui envoie chaque tour à un seul modèle de votre choix. C'est une conversation en lecture seule : pas de dossier, pas d'outils qui agissent, pas de validations. Parfait pour une question rapide.
  • Chat a sa propre place dans la barre latérale. Il répond lui aussi avec un modèle choisi pour toute la conversation, mais garde les capacités sur les fichiers : il peut proposer une modification que vous acceptez (Accept) ou rejetez (Reject), classée dans Changelog. Utilisez-le quand vous voulez qu'un modèle précis fasse le travail, sans router qui choisit à votre place.
  • Multi chat pose la même question à plusieurs modèles à la fois. En mode Compare, vous lisez les réponses côte à côte ; en mode Council, les modèles répondent, classent à l'aveugle les réponses des autres, et un modèle rédige une synthèse.

Multi chat en mode Council : trois modèles répondent, se classent mutuellement, et une synthèse liste les désaccords (exemple)

Depuis Maestro, le travail passe souvent vers d'autres parties de l'app. Research transforme une question en rapport sourcé, Code fait tourner un agent de code sur sa propre branche, Indexes rend un dossier cherchable par le sens (comme pour Dan), et Version → Merge Station est l'endroit où l'on fusionne les modifications de la sandbox. Si un tour tourne mal, taper /rewind dans le chat restaure les fichiers modifiés par ce tour. Pour aller plus loin, la page sur l'orchestration Maestro détaille les onglets de détail, et la page sur le mode plan couvre le processus de validation.

Les premières questions qu'on se pose

Le mode plan, c'est juste une consigne dans le prompt ?
Non. Tant que Plan est sur ON, tout outil absent de la liste en lecture seule est refusé au moment où l'app le déclenche : l'agent peut lire, chercher et naviguer, mais ne peut ni modifier ni lancer de commandes tant que vous n'avez pas validé le plan.

Plan ON dans la barre de contrôle pendant que Maestro lit encore des fichiers (exemple)

Quelle différence entre l'interrupteur Plan et Plan First dans Approval Mode ?
Plan est un interrupteur ponctuel pour la prochaine demande : enquêter, présenter un plan, attendre. Approval Mode est la règle permanente du chat pour les appels d'outils, d'Auto Accept à Bypass. Plan First est l'un de ses quatre réglages.

Ça fait beaucoup de lignes de processus. Je peux les masquer ?
Oui. Le réglage Process Detail bascule entre Full et Compact. Il change seulement l'affichage des étapes, pas le déroulement du tour.

Quel modèle Maestro utilise-t-il ?
Par défaut, le Router choisit un modèle à chaque tour, et les lignes de processus indiquent lequel a tourné. Vous pouvez changer le mode de modèle (cloud, local ou auto-hébergé) depuis le composeur, ou utiliser Chat si vous voulez un seul modèle fixé pour toute la conversation.

L'application de bureau est disponible sur osfoundry.io/fr/download.