Phantom : un agent qui dispose de sa propre machine

Le problème visé : des sessions qui repartent de zéro

Le README ouvre sur un constat simple : un agent de chat classique est jetable. On ouvre un onglet, on obtient une réponse, on ferme, et le contexte disparaît. La session suivante recommence au jour un. Phantom répond à cela en donnant à l'agent une machine à lui, distincte de celle de l'utilisateur. La promesse n'est pas une meilleure fenêtre de contexte, mais un espace de travail qui persiste : l'agent y installe des logiciels, y démarre des bases de données et y conserve ce qu'on lui a dit la semaine précédente.

Le public visé est précis. Il faut être prêt à héberger une VM, à configurer des jetons Slack, et à laisser un processus créer des conteneurs frères. Ce n'est pas un outil qu'on essaie en cinq minutes sur un portable. Le README le dit lui-même : gardez votre portable pour vous, la machine de l'agent est la sienne. Si cette séparation ne vous parle pas, le reste du projet n'a pas grand intérêt pour vous.

Ce que l'agent fait de sa machine

Le README raconte trois épisodes présentés comme issus d'instances de production. Dans le premier, un Phantom à qui l'on demande de l'aide en analyse de données installe ClickHouse sur sa VM, télécharge le jeu de données Hacker News, charge 28,7 millions de lignes couvrant 2007 à 2021, construit un tableau de bord et une API REST, puis enregistre cette API comme outil MCP pour ses sessions futures. Le troisième épisode est plus intéressant pour juger du mécanisme : le Phantom découvre Vigil, un moniteur système open source, l'intègre à son instance ClickHouse, met en place un pipeline qui transfère les métriques par lots toutes les 30 secondes, et construit un tableau de bord affichant l'état des services, des conteneurs Docker, les entrées-sorties réseau et disque.

Ces récits ne sont pas des benchmarks et je ne les présente pas comme tels. Ils décrivent une capacité d'auto-extension, pas une performance mesurée. Le deuxième épisode en donne la forme la plus claire : Phantom ne prend pas en charge Discord nativement, mais l'agent a expliqué à l'utilisateur comment créer une application Discord, fourni un lien pour soumettre le jeton de façon sécurisée, et annoncé qu'il démarrerait le conteneur une fois le jeton enregistré. Le canal a été ajouté sans modification du code du projet. C'est le cœur du modèle : les canaux et les outils sont des choses que l'agent peut se donner.

Mémoire, MCP et fournisseurs : la mécanique visible

Trois briques ressortent du matériel fourni. La mémoire s'appuie sur Qdrant, démarré avec la pile, et sur un modèle d'embedding qu'Ollama récupère au premier lancement. C'est ce couple qui rend la persistance possible entre les sessions, et c'est aussi une dépendance : sans Qdrant joignable, la couche mémoire n'a plus de support.

Le serveur MCP est le second point d'articulation. Le README décrit l'API ClickHouse enregistrée comme outil MCP, utilisable dans les sessions suivantes et par d'autres agents. Le MCP joue donc ici le rôle de mémoire procédurale : ce que l'agent construit devient un outil qu'il peut rappeler.

Le troisième point est l'abstraction des modèles. Sept fournisseurs sont annoncés, dont Anthropic par défaut, Z.AI, OpenRouter, Ollama, vLLM, LiteLLM et tout point de terminaison compatible avec l'API Anthropic Messages. Le README affirme que le changement de fournisseur traverse aussi bien l'agent principal que les juges du pipeline d'auto-évolution, et que seuls les outils et la mémoire restent identiques. Anthropic reste la valeur par défaut et les déploiements existants continuent de fonctionner sans modification. Le fichier de référence complet est docs/providers.md.

Démarrer avec Docker et le fichier phantom.yaml

La voie recommandée tient en quatre commandes. Le README donne exactement ceci :

curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/docker-compose.user.yaml -o docker-compose.yaml curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/.env.example -o .env docker compose up -d

Entre les deux, il faut éditer .env pour y placer ANTHROPIC_API_KEY, les jetons Slack et OWNER_SLACK_USER_ID. La documentation indique que RESEND_API_KEY est nécessaire pour l'envoi d'email. L'interface web est servie sur /chat et l'état de santé se lit sur http://localhost:3100/health. Avec Slack configuré, l'agent envoie un message privé quand il est prêt.

Le changement de fournisseur se fait dans phantom.yaml, pas dans .env. Le README donne ce bloc :

model: claude-opus-4-7 provider: type: zai api_key_env: ZAI_API_KEY model_mappings: sonnet: glm-5.1

La clé elle-même reste dans .env, référencée par api_key_env. C'est une séparation correcte : la configuration versionnable ne contient pas de secret. Notez que le README ne documente pas de commande de migration ni de schéma de version pour phantom.yaml, ce qui laisse ouverte la question de la compatibilité entre versions.

Le socket Docker monté dans le conteneur

C'est le point sur lequel il faut s'arrêter. Le README contient une note de sécurité reconnaissant que docker-compose.yaml monte /var/run/docker.sock dans le conteneur Phantom, afin qu'il puisse lancer des conteneurs frères, par exemple pour l'exécution de code en bac à sable. Le README qualifie ce choix de compromis architectural assumé et précise que le socket accorde au conteneur un accès équivalent à root sur le démon Docker. Un processus Phantom compromis pourrait donc créer, modifier ou détruire n'importe quel conteneur de l'hôte.

Les mitigations citées sont de faire tourner Phantom sur une machine ou une VM dédiée, pas sur un poste de travail personnel. Le texte fourni s'interrompt au milieu de cette phrase, donc la liste complète des mitigations n'est pas connue. Je ne peux pas affirmer qu'il n'y en a pas d'autres, ni lesquelles.

Ma lecture : ce montage est cohérent avec le produit décrit, puisque l'agent doit pouvoir lancer des conteneurs. Mais il déplace la frontière de sécurité. La VM dédiée n'est pas une recommandation de confort, c'est la condition qui rend le reste défendable. Si vous ne pouvez pas l'accorder, Phantom n'est pas l'outil adapté.

Ce que le matériel ne permet pas de trancher

Plusieurs éléments manquent. Le README affiche un badge de version 0.20.2, mais l'API des releases n'a rien renvoyé et aucune note de version n'est disponible. Impossible donc de savoir ce qui a changé récemment, ni si des ruptures de compatibilité sont intervenues. Le badge de tests annonce 1819 tests passés, ce qui indique une suite existante, sans dire ce qu'elle couvre ni comment l'exécuter.

Le dépôt n'est pas archivé et le dernier push remonte au 16 juin 2026, ce qui suggère une activité, mais je n'ai aucun élément sur le rythme des publications ni sur la politique de support. Le README renvoie à docs/providers.md et docs/getting-started.md, que je n'ai pas. Enfin, la page d'accueil propose d'obtenir un Phantom gratuit, sans que le matériel explique ce que cela implique : hébergement par l'éditeur, limites d'usage, traitement des données. Ces questions restent ouvertes.

Comparer avec un agent de codage en terminal

L'alternative la plus directe n'est pas un autre agent hébergé, mais un agent en ligne de commande qui travaille dans le répertoire courant, du type de ceux qui s'appuient sur le même SDK. La différence n'est pas la qualité du modèle, c'est la topologie. Un agent en terminal partage votre système de fichiers et vos identifiants, s'arrête quand vous fermez la session, et n'a pas de mémoire hors du dépôt sur lequel il travaille. Vous gardez le contrôle, vous n'avez rien à héberger, et le rayon d'action reste votre machine.

Phantom inverse chaque terme. L'agent vit ailleurs, garde un état dans Qdrant, expose des canaux de conversation, et peut créer des conteneurs. Le coût de cette autonomie est l'isolation : il faut une VM, un démon Docker accessible, et une surveillance de ce que l'agent lance. Le choix se joue donc sur une question simple : voulez-vous un assistant qui opère dans votre espace, ou un collègue qui opère dans le sien ? Phantom ne répond qu'à la seconde.

Licence, coût de maintenance et premier pas

Phantom est publié sous Apache-2.0. Cette licence autorise l'usage commercial, la modification et la redistribution, et comporte une clause de brevets. Elle n'accorde aucun droit sur les marques du projet et n'implique aucune garantie de la part des auteurs. Je ne donne pas de conseil juridique : si vous redistribuez une version modifiée, lisez le texte de la licence et conservez les mentions requises.

Le coût de maintenance se répartit sur trois services : Qdrant pour la mémoire, Ollama pour les embeddings, et le fournisseur de modèle choisi. Le README indique qu'avec Ollama, le coût d'API est nul, et qu'avec Z.AI le prix serait environ quinze fois inférieur à celui de Claude Opus pour une qualité de code présentée comme comparable. Ces chiffres viennent du README, pas d'une mesure indépendante. Côté exploitation, la mise à jour se fait par docker compose, mais l'absence de notes de version publiées signifie qu'il faut lire les différences de phantom.yaml soi-même avant de redémarrer.

Pour un premier essai, la séquence la plus prudente consiste à provisionner une VM dédiée, à récupérer docker-compose.user.yaml et .env.example, à renseigner ANTHROPIC_API_KEY et OWNER_SLACK_USER_ID, puis à vérifier http://localhost:3100/health avant de connecter Slack. Si vous ne pouvez pas isoler la machine, arrêtez-vous là.

Conclusion éditoriale

Phantom convient aux équipes qui acceptent de lui donner une VM dédiée et un accès root-equivalent au démon Docker, et qui veulent un agent joignable sur Slack avec une mémoire qui survit entre les sessions. Il ne convient pas à qui doit exécuter l'agent sur son poste de travail ou dans un cluster partagé, ni à qui a besoin d'un paquet versionné : le README affiche la version 0.20.2 et l'API des releases n'a rien renvoyé. Avant de déployer, lisez la fin de la note de sécurité du README sur le montage de /var/run/docker.sock, et vérifiez que vos jetons Slack et ANTHROPIC_API_KEY sont dans .env et non dans phantom.yaml.

Sources officielles

1. ghostwright/phantom on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README