gptme : un agent en terminal qui écrit du code, garde son contexte et tourne sur un serveur sans interface

Le problème : un agent qui vit là où l'on travaille déjà

La plupart des agents de code supposent un environnement graphique : un éditeur, un panneau latéral, une fenêtre de conversation. gptme part d'une contrainte inverse. Le README affirme que l'agent tourne partout où tourne un terminal, et cite explicitement les sessions ssh, tmux, les serveurs sans écran et les pipelines CI. C'est le public visé : quelqu'un qui est déjà dans un shell, souvent sur une machine distante, et qui ne veut pas ouvrir un second outil pour demander à un modèle d'écrire un fichier ou de lancer une commande.

Le projet ne se limite pas au code. Le README le décrit comme un agent de codage correct mais assez général pour d'autres tâches de knowledge-work. Cette formulation est volontairement large, et il faut la prendre comme telle : la documentation ne fournit pas de liste de tâches non liées au code qui seraient validées par des tests. Ce qui est concret, c'est le jeu d'outils embarqué, décrit plus bas.

Un point de chronologie compte pour situer le projet. Le README date le premier commit à mars 2023 et le présente comme l'un des premiers agents en ligne de commande. Cette ancienneté relative explique la présence de fonctionnalités tardives dans d'autres projets : compression de contexte, plugins, serveur MCP. Elle n'est pas un gage de qualité en soi, seulement un indice sur la maturité du modèle de conception.

Architecture : des outils locaux, un fournisseur interchangeable

Le mécanisme central est simple à énoncer. L'agent reçoit une demande, choisit un outil parmi ceux que le projet expose, l'exécute localement, puis réinjecte le résultat dans la conversation. Le README cite le shell, Python, le web et la vision comme outils fournis. C'est ce qui distingue gptme d'un simple client de chat : le modèle ne se contente pas de proposer du code, il dispose d'un accès à la machine sur laquelle l'agent tourne.

La couche fournisseur est séparée. Le README liste Anthropic, OpenAI, Google, xAI, DeepSeek et OpenRouter, avec une exécution entièrement locale via llama.cpp. Cette séparation a une conséquence pratique : changer de modèle ne devrait pas changer les outils disponibles. Elle a aussi une conséquence moins agréable, que le README n'aborde pas : la qualité de l'appel d'outils varie fortement d'un modèle à l'autre, et un petit modèle local qui produit du texte correct peut échouer à produire un appel d'outil exploitable. Le projet laisse le choix, il ne garantit pas l'équivalence.

Le reste de l'architecture visible dans le matériel est un empilement de mécanismes ajoutés par versions successives. La v0.30.0 introduit le système de plugins, la compression de contexte et un mode planificateur par sous-agents. La v0.31.0 ajoute les tâches en arrière-plan, un outil de formulaire, le suivi des coûts et un stockage adressé par contenu. La v0.29.0 apporte le système de leçons pour le guidage contextuel et la découverte MCP. Ce ne sont pas des détails cosmétiques : la compression de contexte et le stockage adressé par contenu répondent tous deux au même problème, la taille finie de la fenêtre de contexte et le coût de la relecture.

Installation et configuration : ce que le README donne réellement

Le matériel fourni ne contient pas la section Getting Started complète. Le README renvoie vers la page https://gptme.org/docs/getting-started.html pour l'installation, et le paquet est publié sur PyPI sous le nom gptme. Toute commande d'installation précise que j'écrirais ici serait une supposition : je ne l'ai pas vérifiée et elle n'apparaît pas dans les extraits disponibles. La seule voie que je peux affirmer est celle du paquet PyPI, puisque le badge de version pointe vers https://pypi.org/project/gptme/.

Ce que le README documente, en revanche, c'est l'existence de plusieurs surfaces d'extension. Les plugins et les skills sont regroupés sous une même section, aux côtés des leçons. Le dépôt gptme-contrib est décrit comme le lieu des plugins communautaires, avec des exemples nommés : Twitter/X, bot Discord, outils email, et un composant consortium pour le multi-agent. Les intégrations MCP et ACP sont annoncées comme un point d'entrée vers des outils externes, la découverte MCP dynamique étant datée de la v0.29.0.

Pour un lecteur qui veut évaluer le projet, la conséquence est directe : la configuration se fait largement par ajout de plugins et de leçons, pas par un unique fichier de réglages. C'est plus souple et plus difficile à auditer. Un agent qui charge dynamiquement des outils externes via MCP exécute du code que l'on n'a pas forcément lu. Le README ne traite pas ce point de sécurité, et je le signale comme une lacune documentaire plutôt que comme un défaut du logiciel.

Agents autonomes : le mode qui change la nature du risque

Le README consacre une section aux agents autonomes et renvoie au dépôt gptme-agent-template, dont la v0.4 est datée de janvier 2026. Le texte mentionne des boucles d'exécution autonomes, une génération de contexte enrichie, et cite un agent nommé Bob qui aurait tourné de façon extensive. Ces éléments sont des affirmations du projet, pas des mesures indépendantes. Je les rapporte comme telles.

Ce mode déplace le centre de gravité. En usage interactif, une personne valide chaque étape ; le pire cas est une commande ratée que l'on annule. En boucle autonome, l'agent enchaîne les appels d'outils sans validation humaine entre deux. Le README mentionne une section Guardrails, donc le projet a prévu quelque chose, mais le matériel fourni ne détaille ni les mécanismes ni leur portée. Impossible de dire depuis ces extraits si les garde-fous bloquent les commandes destructrices, limitent les chemins accessibles, ou se contentent d'une confirmation textuelle.

C'est le point que je vérifierais en premier avant tout déploiement autonome. La documentation d'un projet qui revendique des boucles autonomes doit expliquer ce qui se passe quand le modèle se trompe, pas seulement ce qui se passe quand il réussit. Sur ce sujet précis, l'extrait disponible reste en dessous du niveau de détail nécessaire.

Limites et cas où gptme n'est pas le bon outil

La première limite est la dépendance au modèle pour l'appel d'outils. gptme fournit le cadre, pas la compétence. Un modèle local modeste, exécuté via llama.cpp, peut très bien tenir une conversation et échouer systématiquement à produire un appel structuré. L'utilisateur qui choisit le local pour des raisons de confidentialité doit accepter cette variabilité, que le README ne quantifie pas.

La deuxième limite tient au rythme de publication. Les versions récentes listées sont toutes des versions de développement : v0.33.1.dev20260903, v0.33.1.dev20260831, v0.33.1.dev20260827. Le suffixe dev indique des publications intermédiaires, pas des versions stables. Sur un intervalle de quelques jours, trois publications. Cela signifie que suivre la branche principale demande de la discipline, et qu'épingler une version précise est plus prudent que de suivre le fil.

La troisième limite est la nature du produit. Le README le dit lui-même : l'agent vit dans le terminal. Si le travail se fait dans un éditeur avec complétion en ligne et diff visuel, gptme ajoute une couche au lieu d'en retirer une. Les captures d'écran du README sont datées de 2023 et le texte précise que le projet a beaucoup évolué depuis, ce qui laisse la démonstration visuelle en retard sur le code. Enfin, l'absence de section de sécurité détaillée dans les extraits disponibles est un vrai manque pour un outil qui exécute des commandes shell.

Alternatives : la différence n'est pas le modèle, c'est l'interface

Le README se positionne explicitement comme une alternative à Claude Code, Codex, Cursor et Warp. La différence n'est pas la qualité du modèle, puisque gptme peut utiliser les mêmes fournisseurs. Elle porte sur trois axes concrets.

Le premier est l'indépendance du fournisseur. Un outil adossé à un seul fournisseur impose son modèle et son tarif. gptme laisse le choix, y compris celui d'un modèle local. Le prix de cette liberté est la variabilité de qualité déjà évoquée.

Le deuxième est la surface d'exécution. Un IDE comme Cursor vit dans une fenêtre graphique et suppose un poste de travail. gptme se lance dans un terminal, donc dans une session ssh, dans tmux, ou dans une étape de CI. Pour un serveur headless, ce n'est pas un détail de confort : c'est la différence entre un outil utilisable et un outil impossible.

Le troisième est l'extensibilité. Le système de plugins, les leçons et le support MCP permettent d'ajouter des outils sans modifier le cœur. Un outil fermé impose son catalogue. Cette ouverture a un coût de maintenance : chaque plugin ajouté est du code tiers qui s'exécute avec les mêmes droits que l'agent. Le dépôt gptme-contrib existe précisément pour héberger ces extensions, ce qui déplace la question de la confiance vers un second dépôt.

Coût de maintenance, licence et ce qu'il reste à vérifier

La licence est MIT, indiquée dans les métadonnées du dépôt. C'est une licence permissive : elle autorise la modification, la redistribution et l'usage commercial, avec conservation de l'avis de copyright. Elle n'impose aucune obligation de publication des modifications. Je ne donne pas de conseil juridique : pour un usage en entreprise, la conformité dépend aussi des licences des dépendances Python et des modèles utilisés, qui ne sont pas décrites dans le matériel fourni.

Le coût de maintenance se lit dans le calendrier. Le dépôt n'est pas archivé, le dernier envoi est daté du 9 septembre 2026, et les publications de développement s'enchaînent sur quelques jours. Un projet à ce rythme demande soit de suivre régulièrement, soit de figer une version et de gérer les mises à jour manuellement. Les notes de version mentionnent un suivi des coûts depuis la v0.31.0, ce qui donne un moyen de mesurer la dépense par session, information utile quand on laisse tourner un agent en arrière-plan.

Deux vérifications restent impossibles depuis ces extraits. D'abord le contenu réel des garde-fous, annoncés mais non détaillés. Ensuite la procédure d'installation exacte, qui se trouve sur la page Getting Started et non dans le README fourni. Ces deux points sont accessibles dans le dépôt et dans la documentation ; ils conditionnent l'adoption plus que la liste des fournisseurs compatibles.

Conclusion éditoriale

gptme convient aux développeurs qui travaillent en SSH, dans tmux ou sur une machine sans interface graphique et qui veulent un agent capable d'appeler un shell et Python sans quitter le terminal. Il ne convient pas à qui cherche un IDE intégré ou une interface graphique pilotée à la souris : le projet se présente comme un agent en terminal, et l'application de bureau n'apparaît qu'à partir de la version v0.32.1. Avant d'adopter, vérifier deux choses dans le dépôt : la liste des outils activés par défaut et le contenu du dossier de configuration, car c'est là que se joue la différence entre un agent qui se contente de répondre et un agent qui écrit sur le disque.

Sources officielles

1. gptme/gptme on GitHub
2. License: MIT
3. Project website
4. README
5. Releases