Empryo : un agent de codage qui travaille sur les symboles, pas sur les chaînes de caractères

Le problème visé : un agent qui modifie sans savoir ce qu'il casse

Le README pose le diagnostic sans détour : la plupart des agents de codage font du grep, lisent des fichiers entiers et patchent des chaînes, et ne savent jamais ce qui dépend du code qu'ils viennent de changer. C'est un problème de contexte, pas de modèle. Un agent qui ignore le graphe d'appels doit relire large pour se rassurer, ce qui consomme des tokens et produit des modifications qui compilent mais cassent un appelant situé deux répertoires plus loin. Empryo cible donc deux populations distinctes. D'un côté les développeurs qui travaillent sur des bases de code où une modification locale a des répercussions non locales, typiquement du TypeScript ou du Python avec beaucoup d'imports croisés. De l'autre, ceux qui paient à l'usage et pour qui chaque relecture inutile se retrouve sur la facture. Le README résume la promesse en une phrase : le graphe fait la navigation que les modèles brûlent habituellement en contexte. Le public visé n'est pas le débutant qui veut générer un script, c'est quelqu'un qui a déjà un dépôt et veut y faire des changements structurels.

Le génome de code : tree-sitter, PageRank et co-changement git

Le mécanisme central est décrit en trois temps dans le README. Au lancement, tree-sitter analyse le dépôt et le transforme en graphe vivant : chaque symbole, chaque import, chaque site d'appel. Ce graphe est ensuite classé par PageRank et par co-changement git, c'est-à-dire que les fichiers qui changent historiquement ensemble remontent dans le classement. Enfin, les requêtes sur ce graphe répondent en millisecondes et, précise le README, coûtent zéro token LLM. C'est le point architectural à retenir : la partie la plus utile du travail d'exploration ne passe pas par le modèle. Le README mentionne aussi des étiquettes de rayon d'impact (blast radius), qui répondent à la question "qu'est-ce qui casse si je touche à ceci" avant la première frappe. Je note une limite documentaire ici. Le README affirme que tree-sitter couvre plus de 30 langages, mais ne donne pas la liste. Pour un dépôt dans un langage exotique, il faut vérifier soi-même la couverture avant de compter sur le graphe. Le classement par co-changement git a lui aussi une conséquence non dite : sur un dépôt avec un historique réécrit ou très jeune, ce signal est faible ou absent, et le classement retombe sur le seul PageRank.

L'édition par l'AST et le rollback tout-ou-rien

La deuxième moitié du mécanisme concerne l'écriture. Le README annonce plus de 65 opérations au niveau symbole, des lots atomiques avec rollback tout-ou-rien, des éditions structurelles dans plus de 30 langages, et un typecheck qui sert de porte de sortie. L'idée est qu'une modification qui ne passe pas le typecheck ne doit pas être validée. Le rollback tout-ou-rien est la partie qui compte en pratique : un agent qui applique dix modifications et échoue à la septième laisse normalement un dépôt dans un état intermédiaire incohérent. Le README affirme que ce cas est traité. Je ne peux pas le vérifier ici, et c'est exactement le genre d'affirmation qu'il faut tester sur son propre dépôt avant de faire confiance à l'outil en CI. Autre point : le typecheck comme porte suppose qu'un typecheck existe et soit configuré. Sur un dépôt JavaScript sans types, ou sur un langage sans vérificateur branché, cette garantie tombe. Le README ne détaille pas ce qui se passe dans ce cas, et c'est une zone d'ombre réelle.

Installation : hors npm, hors Homebrew, hors GitHub Releases

L'installation est volontairement hors des canaux habituels, et le README insiste lourdement sur ce point. Sur macOS et Linux, la commande donnée est un script distant : curl -fsSL https://empryo.com/install.sh | bash. Sur Windows, c'est irm https://empryo.com/install.ps1 | iex. Ensuite, la configuration de la clé se fait avec empryo --set-key anthropic sk-ant-..., ou sans clé du tout en local via Ollama. Le lancement se fait par cd your-project puis empryo. Le README précise qu'Empryo n'est distribué ni par Homebrew, ni par WinGet, ni par npm, et demande de ne pas télécharger les binaires depuis GitHub Releases ou des gestionnaires tiers. C'est un choix assumé, mais il a un coût concret : pas de version épinglée dans un package.json, pas de lockfile, pas de mise à jour gérée par l'outillage existant. Pour un poste de développement individuel, c'est acceptable. Pour une flotte de machines en entreprise, cela signifie construire soi-même la distribution et la vérification d'intégrité. Le contraste avec SoulForge est net : l'ancien nom reste installable via brew tap proxysoul/tap && brew install soulforge ou bun install -g @proxysoul/soulforge, et le README indique qu'il ne reçoit plus que des correctifs de bugs et de problèmes critiques.

Routage multi-modèles : dix rôles, un cache à préserver

Empryo ne fait pas tourner un seul modèle en boucle. Le README décrit dix rôles routables (brain, spark pour le scout, ember pour le code, explore, verify pour la revue, goal review, desloppify, summarize, compact, web search), chacun pouvant recevoir n'importe quel modèle parmi 22 fournisseurs annoncés. Le routage se fait par onglet, par configuration globale et par projet, avec surcharge depuis l'onglet. La justification économique est explicite : des modèles bon marché explorent, des modèles forts écrivent, les relecteurs jugent avec un contexte propre. Le détail technique qui rend cela viable plutôt que gadget est la gestion du cache. Le README affirme que le routage maintient les préfixes de cache stables et que les sous-agents héritent de la ligne de cache de leur parent, si bien que le contexte répété est facturé au tarif de lecture de cache. C'est une contrainte de conception réelle : mal choisir ses modèles par rôle peut casser ces préfixes et faire remonter la facture. Le suivi de dépense est annoncé par modèle, par sous-agent, par onglet, par session et par jour. Le README mentionne aussi une compaction structurelle sans appel LLM, ce qui évite le résumé par le modèle sur les longues sessions. Trois surfaces partagent le même génome : application de bureau native, interface terminal complète, CLI sans interface pour scripts et CI.

Les benchmarks publiés et ce qu'ils ne disent pas

Le README avance une comparaison face à pi, à modèles et dépôts identiques. En manche 1, trois bugs sur trois modèles : 8/9 corrigés contre 7/9, coût 28 pour cent inférieur (1,13 dollar contre 1,58), temps mural 57 pour cent plus rapide, et 5,7 fois moins de tokens d'entrée (1,09M contre 6,21M). En manche 2, cinq bugs réels sur hono, zod et ky : 7/10 contre 6/10, coût 23 pour cent inférieur (7,08 contre 9,19 dollars), 32 pour cent plus rapide, 28 pour cent d'étapes en moins. Le README indique que la manche 2 utilise des bugs issus de PR fusionnées, postérieurs à la date de coupure des modèles, avec historique nettoyé et tests de régression injectés après chaque exécution, et renvoie vers proxysoul/pi-vs-empryo-bench pour reproduire. Ces chiffres sont publiés par l'éditeur de l'outil, sur son propre site. La méthodologie est décrite et le dépôt de reproduction est nommé, ce qui est mieux que la moyenne, mais un benchmark interne reste un benchmark interne. Le point à surveiller est la taille des échantillons : 9 et 10 bugs, ce qui est très petit. Un écart de 8/9 contre 7/9 tient à un seul bug. La réduction de tokens d'entrée en manche 1 est le résultat le plus intéressant parce qu'il découle directement de l'architecture du graphe, pas d'un choix de modèle. Il mérite d'être reproduit sur votre dépôt, pas cru sur parole.

Licence et maintenance : ce que le dépôt ne dit pas

Le champ licence du dépôt porte la valeur NOASSERTION, ce qui signifie que GitHub n'a pas su rattacher le fichier LICENSE à un identifiant SPDX connu. Le README renvoie vers ce fichier en indiquant que le code source de SoulForge reste archivé ici sous sa licence existante. Autrement dit, la licence d'Empryo n'est pas lisible depuis les métadonnées du dépôt, et je ne peux pas vous dire ici quelles sont les conditions de redistribution ou d'usage commercial. C'est le premier point à vérifier avant toute adoption en entreprise, et je ne peux que vous renvoyer au fichier lui-même. Sur la maintenance, les données disponibles montrent un rythme serré : trois versions publiées en juillet 2026 (2.20.23, 2.20.24, 2.20.25), et un dernier push sur main daté du 9 septembre 2026. La numérotation 2.20.x suggère des incréments fréquents, ce qui implique de suivre les changements de près. Le coût de mise à jour est accru par le mode de distribution : sans gestionnaire de paquets, chaque montée de version passe par le script d'installation ou par le téléchargement manuel depuis empryo.com/download. Le dépôt lui-même n'est pas un dépôt de code mais un tracker d'issues et de discussions, ce qui limite ce qu'on peut auditer depuis GitHub. Le README mentionne enfin une intégration LSP avec plus de 576 serveurs de langage via Mason, tout serveur MCP, et 13 hooks de cycle de vie.

Conclusion éditoriale

Empryo convient aux équipes qui travaillent sur de gros dépôts multi-langages où le coût en tokens des agents classiques devient visible, et qui acceptent d'installer un binaire hors gestionnaire de paquets. Il ne convient pas à qui veut un paquet npm versionné, un dépôt clonable avec sources et licence lisible, ou un outil dont la licence est vérifiable avant déploiement en entreprise. Avant d'aller plus loin, vérifiez trois choses : le fichier LICENSE du dépôt, la liste des 22 fournisseurs de modèles annoncée dans le README, et le contenu de empryo.com/download puisque le README interdit explicitement GitHub Releases et les gestionnaires tiers comme sources de binaires.

Sources officielles

1. Issues
2. Project website
3. proxysoul/Empryo on GitHub
4. README
5. Releases