Ce que Meta a annoncé

Selon le blog de recherche de Meta, Muse Code est un agent de programmation en terminal, encore en bêta, qui prend en charge des tâches d’ingénierie logicielle complexes sur de grands dépôts : planifier les changements, écrire le code et valider les résultats. Il s’appuie sur un ensemble d’agents d’arrière-plan asynchrones qui restent actifs pendant chaque session.

Le modèle sous-jacent, Muse Spark 1.2, est présenté comme une mise à jour orientée code de Muse Spark 1.1, entraînée avec une puissance de calcul nettement accrue sur des tâches de programmation et des environnements d’entraînement plus variés. Il est disponible dans Muse Code et dans la Meta Model API. L’annonce ne détaille ni les tarifs, ni le fonctionnement des permissions de l’agent : ce sont précisément des points à vérifier avant tout usage professionnel.

Un marché d’agents de code qui se densifie

Muse Code arrive au terme d’un été chargé. Le 2 juin, lors de sa conférence Build, Microsoft présentait MAI-Code-1-Flash, l’un des modèles par défaut de Visual Studio Code. Le 30 juin, Claude Sonnet 5 devenait disponible dans GitHub Copilot (voir notre article). Le 9 juillet, GPT-5.6 arrivait dans Codex (voir notre article). Pour un développeur ou une petite équipe, le problème n’est plus de trouver un agent, mais d’en choisir un — et de pouvoir en changer.

Pouvoir en changer suppose de ne pas enfermer son savoir-faire dans un outil : des missions écrites dans un format neutre, des conventions de dépôt décrites dans des fichiers que plusieurs agents savent lire, des tests qui disent objectivement si le travail est fait. Avec ces trois éléments, passer d’un agent à un autre prend une après-midi d’essais au lieu d’une migration.

Six critères pour choisir un agent de code

  1. Permissions : que peut-il exécuter sans demander ? Lecture seule, écriture de fichiers, commandes shell, accès réseau.
  2. Isolement : où s’exécute-t-il ? Sur votre poste, dans un conteneur, dans le cloud de l’éditeur.
  3. Traçabilité : produit-il des commits, des pull requests et des journaux lisibles par un humain ?
  4. Coût par tâche : mesuré sur vos propres tâches, essais ratés compris.
  5. Confidentialité du code : où part votre code, combien de temps est-il conservé, sert-il à l’entraînement ?
  6. Qualité mesurée : sur une dizaine de tâches réelles de votre dépôt, pas sur un classement public.

Le terminal, un environnement puissant et risqué

Un agent qui travaille dans le terminal peut tout ce que vous pouvez y faire : installer des paquets, lancer des scripts, modifier ou supprimer des fichiers, se connecter à des services. C’est ce qui le rend efficace sur de grands dépôts, et c’est aussi ce qui impose des précautions. Trois réglages font la différence : l’environnement (un conteneur ou une machine de travail sans accès à vos secrets de production), la liste des commandes autorisées sans confirmation, et le réseau (autoriser seulement les registres de paquets et le dépôt, pas tout Internet). Un agent qui demande avant chaque commande sensible est plus lent ; un agent qui ne demande jamais est un risque.

Une première mission pour tester un agent de code

Pour évaluer un nouvel agent sans risque, confiez-lui d’abord une tâche bornée et vérifiable : « ajouter un test pour la fonction de calcul de remise, sans modifier le code existant, puis faire passer toute la suite ». Observez s’il respecte le périmètre, s’il montre les sorties réelles des tests, s’il demande avant d’installer quoi que ce soit, et si son rapport final dit clairement ce qui n’a pas été vérifié. Ces quatre observations en disent plus sur un agent que n’importe quel classement.

Les règles communes, quel que soit l’agent

Quel que soit l’outil, les mêmes règles évitent la plupart des mauvaises surprises : travailler sur une branche dédiée, faire passer les tests avant et après chaque modification, garder une revue humaine avant la fusion, ne jamais laisser de secret dans le dépôt ni dans les instructions, et décrire les conventions du projet dans un fichier AGENTS.md, que de plus en plus d’outils savent lire (voir notre article sur GitHub).

La mission elle-même compte autant que l’agent : un objectif clair, ce qu’il ne faut pas casser, les tests à faire passer et les critères de fin. C’est ce qu’écrit Prompt OS, dans un format utilisable avec Codex, Claude Code, Copilot ou un autre agent. Si votre application a été construite en « vibe coding » et doit maintenant tenir en production, notre offre de maintenance reprend ce travail de fond.

Conclusion

L’arrivée de Meta confirme que les agents de code sont devenus une catégorie à part entière, avec des acteurs majeurs dans chaque camp. Pour les utilisateurs, c’est une bonne nouvelle à condition de garder la main : des missions écrites, des droits limités, des tests et une revue humaine. Ces règles rendent aussi le changement d’outil beaucoup plus facile.