AX : l’orchestrateur open-source de Google pour les agents IA

Les agents IA, c’est devenu le buzzword qui a avalé tous les autres. Un modèle qui raisonne, planifie, appelle des outils et itère sur ses propres résultats — la promesse est solide. Le problème, c’est que la plupart des frameworks censés permettre ça ressemblent à un spaghetti de callbacks mal documenté. LangChain a conquis le terrain en premier, et tout le monde passe 2025 à se plaindre de sa complexité tout en continuant à l’utiliser, faute de mieux.

AX — Agent Executor — débarque avec une promesse plus sobre : un orchestrateur TypeScript open-source, lisible, composable, indépendant du fournisseur LLM. Il a fait surface cette semaine sur Hacker News avec 478 points et plus de 200 commentaires — pas anodin pour un framework. Le score seul ne dit pas grand-chose, mais la densité technique des discussions autour mérite qu’on s’y arrête sérieusement.

Le fait que ça vienne de l’écosystème Google mérite attention — et quelques nuances. Google a misé gros sur l’IA agentique : Gemini, Agent Builder, le protocole A2A. AX s’inscrit dans cette mouvance, mais en mode open-source et framework, pas en mode service managé. C’est une différence qui compte pour quiconque veut garder le contrôle de son stack et ne pas se retrouver prisonnier d’une API propriétaire.

« Agentique » : le mot qui veut tout dire, et parfois rien

On abuse du mot depuis qu’AutoGPT a fait sensation en 2023. Remettons les choses à plat : un système agentique, c’est un système où un LLM décide lui-même de la séquence d’actions à effectuer pour atteindre un objectif. Il ne suit pas un script fixe — il raisonne, choisit ses outils, interprète les résultats, et itère. La clé, c’est l’autonomie de la boucle de décision.

La nuance avec un simple pipeline de prompts enchaînés — ce que font 90 % des « agents » en prod — c’est justement cette boucle de raisonnement. Le modèle peut décider de recommencer, changer d’approche, ou déléguer à un sous-agent. C’est le pattern ReAct (Reason + Act) ou ses variantes avec Chain-of-Thought couplé à des appels de fonctions. Sans ça, tu as juste des prompts séquentiels avec une belle brochure marketing.

AX implémente ce pattern de façon explicite. L’abstraction centrale est un Agent qui embarque un LLM configuré, un ensemble d’outils (des fonctions TypeScript que le modèle peut décider d’appeler), et une boucle d’exécution qui tourne jusqu’à ce que l’agent décide qu’il a terminé — ou jusqu’à ce qu’un maxSteps configurable te sauve de la ruine financière en tokens. Ce petit détail de conception dit beaucoup sur la philosophie du projet.

L’architecture d’AX, vue de l’intérieur

Ce qui distingue AX des autres frameworks, c’est la sobriété de ses abstractions. Trois concepts centraux : AI (le wrapper autour d’un fournisseur LLM avec interface unifiée), Agent (l’entité qui combine un AI, un prompt système, et un set d’outils), et Program (l’approche déclarative pour définir des pipelines optimisables). Pas de sur-ingénierie, pas de dix couches d’abstractions pour faire un appel HTTP.

import { AxAI, AxAgent } from '@ax-llm/ax';

const ai = new AxAI({ name: 'openai', apiKey: process.env.OPENAI_APIKEY! });

const agent = new AxAgent({
  name: 'researcher',
  description: 'Searches the web and summarizes findings',
  ai,
  tools: [webSearchTool, summarizerTool],
});

const result = await agent.forward({
  question: 'Quels sont les risques de déployer en prod un vendredi ?'
});

Le support multi-LLM est natif, pas une surcouche bricolée. Tu peux faire tourner différents agents avec différents modèles dans le même pipeline — un modèle rapide et cheap pour les tâches simples de classification, un modèle plus costaud pour le raisonnement complexe. AX supporte OpenAI, Anthropic, Google Gemini, Mistral et d’autres, avec une interface cohérente qui abstrait les différences d’API sous-jacentes.

La partie qui a suscité le plus de réactions sur HN concerne justement la robustesse de la boucle d’exécution. AX impose un maxSteps par défaut, des timeouts configurables, et une gestion explicite des erreurs dans la boucle agent. Ce n’est pas glamour, mais c’est exactement le genre de détail qui sépare un framework pensé pour la production d’un proof-of-concept qui fonctionne parfaitement dans le notebook de démo.

L’influence DSPy : la partie la plus sous-estimée

Le truc qu’on voit peu dans les présentations d’AX, c’est son approche DSP (Declarative Self-improving Programs). Inspirée de DSPy (Stanford), cette partie du framework permet de définir des pipelines d’IA de façon déclarative avec des signatures typées entrée/sortie, puis de les optimiser automatiquement à partir d’un dataset d’exemples de référence.

En pratique, ça veut dire que tu n’optimises plus tes prompts à la main, en mode « je change une virgule et je vois si ça améliore le résultat ». Tu définis ce que ton pipeline doit produire, tu fournis des exemples attendus, et AX peut ajuster les prompts pour maximiser la performance mesurée. C’est une approche qui rapproche le développement IA du développement logiciel classique : testable, versionnable, reproductible.

Pour les équipes qui construisent des applications sur mesure avec des composants IA, c’est une différence non négligeable. Tu passes de « j’optimise mes prompts à l’intuition et je croise les doigts » à un pipeline d’amélioration systématique. Ce n’est pas magique, mais c’est nettement plus scalable quand le projet grossit et que cinq personnes touchent au même pipeline.

AX face à LangChain et LlamaIndex : le match honnête

La comparaison est inévitable. LangChain reste la référence absolue en termes d’écosystème : des centaines d’intégrations, une communauté massive, des tutorials partout. LlamaIndex s’est imposé sur la partie RAG (Retrieval-Augmented Generation). AX n’essaie pas de les battre sur ces terrains. Il n’a pas 200 connecteurs de bases de données, et il ne propose pas de RAG intégré clé en main.

Ce qu’il propose, c’est une architecture plus propre pour le cas d’usage agentique pur. La codebase TypeScript est légère, les types sont corrects (pas de any partout), et le mental model est cohérent d’un bout à l’autre. Sur HN, plusieurs développeurs pointent que LangChain.js est devenu « ingérable » sur des projets de taille moyenne — trop d’abstractions, des breaking changes réguliers, une documentation constamment en retard sur le code.

La vraie question n’est pas « quel framework a le plus d’étoiles sur GitHub », mais « lequel je serai encore capable de déboguer dans six mois à 3h du matin ».

AX joue exactement sur ce terrain : la lisibilité et la cohérence comme arguments de vente techniques. C’est un positionnement risqué face à un écosystème aussi établi que LangChain, mais cohérent. Et honnêtement, pour du développement TypeScript pur orienté agents, les arguments tiennent la route.

Les angles morts à connaître avant de se lancer

AX n’est pas parfait, et les commentaires HN ne s’en privent pas. Premier point : la maturité de l’écosystème. Comparé à LangChain, les intégrations tierces sont encore limitées. Pour brancher une base vectorielle moins courante ou un provider SaaS spécifique à ton métier, tu risques d’écrire le connecteur toi-même. Ce n’est pas forcément un problème — parfois c’est même préférable — mais ça change l’estimation du temps de développement.

Deuxième point : la documentation. Le README est solide, les exemples de base fonctionnent, mais les cas d’usage avancés — orchestration multi-agents avec état partagé, gestion des erreurs en boucle longue, optimisation du budget tokens — sont encore sous-documentés. Normal pour un projet de moins de deux ans, mais à prendre en compte quand tu estimes une livraison.

Troisième point, et c’est le plus critique pour du déploiement sérieux : l’observabilité. AX offre des hooks de logging, mais pas encore une solution d’observabilité comparable à ce que LangSmith apporte à LangChain. Pour des projets où chaque décision de l’agent doit être traçable et auditable — ce qui concerne de plus en plus les startups qui scalent et passent leurs premiers audits techniques — tu devras intégrer un outil tiers comme Langfuse ou Helicone. C’est faisable, mais ça ajoute une couche à concevoir et à maintenir.

Mon verdict après 478 points de débat

Mon avis sur AX penche vers l’enthousiasme mesuré. C’est un framework qui fait les bons choix architecturaux : TypeScript strict, abstractions fines, boucle d’exécution robuste, inspiration DSPy pour aller au-delà du simple « prompt + outils ». À clarifier cependant : AX n’est pas un projet Google officiel. C’est un projet open-source qui vient de l’écosystème gravitant autour de Google. Nuance importante quand on évalue la pérennité et le support à long terme.

Ce qui me retient de le recommander sans réserve pour des projets critiques en ce moment, c’est l’observabilité et la maturité de la documentation sur les cas avancés. Les agents en prod coûtent cher en tokens, plantent de façon non déterministe, et exigent des outils de debug solides pour ne pas naviguer à l’aveugle. Sur ce point précis, LangChain garde encore une longueur d’avance, à défaut d’en avoir une sur la lisibilité du code et la santé mentale du développeur qui le maintient.

Mon pari pour les 12 prochains mois : si la communauté s’étoffe, que les aspects observabilité et documentation s’améliorent, AX peut devenir la référence TypeScript pour les architectures agentiques sérieuses. Le score HN et la qualité des discussions suggèrent que l’intérêt est réel et que les bons profils s’y intéressent. La vraie question, c’est si les contributeurs tiendront la distance face à un LangChain qui ne restera pas inerte. Dans le doute : teste AX sur ton prochain side-project agentique. C’est le meilleur moyen de se forger un avis qui vaut quelque chose.