AX de Google : le « Kubernetes des agents IA » est-il vraiment un standard ?

Le 21 septembre 2026, Google a déposé sur GitHub un projet baptisé AX et, en quelques heures, Hacker News s’est enflammé : plus de 600 points et près de 300 commentaires, de quoi grimper au deuxième rang de la page d’accueil. La question qui circule partout est séduisante : « AX va-t-il devenir LE standard pour faire collaborer plusieurs IA ? » La réponse est plus nuancée, et plus intéressante, que le titre ne le laisse croire. On démonte le mécanisme ensemble.

AX, c’est quoi exactement ?

Présenté sur sa page GitHub comme un « orchestrateur agentique » open source, AX est un outil qui sert à lancer, surveiller et mettre en pause des agents IA en grand nombre. Un agent IA, pour rappel, est un programme piloté par un modèle de langage (un Claude, un Gemini, un GPT…) qui ne se contente pas de répondre : il agit, exécute du code, consulte des sites, modifie des fichiers.

Définition express : orchestrateur Imaginez un chef de gare. Il ne conduit aucun train lui-même, mais il décide quel train part, sur quelle voie, à quelle heure, et il fait patienter ceux qui attendent. Un orchestrateur, c’est ça pour les programmes : il répartit le travail, surveille l’état de chacun et garde la situation sous contrôle.

Précision capitale : AX n’est pas un nouveau « langage commun » entre IA, comme l’est par exemple le protocole MCP qui permet à un modèle de se brancher à des outils. AX se situe un étage plus bas, côté infrastructure : c’est la salle des machines qui héberge les agents, pas la langue qu’ils parlent entre eux.

Pourquoi Google compare-t-il ça à Kubernetes ?

Kubernetes est le logiciel, également né chez Google, qui pilote des milliers d’applications dans des centres de données. AX reprend sa philosophie dite déclarative : au lieu de dicter chaque geste, on rédige un fichier de description (en YAML) qui dit « voici ce que je veux », puis le système se débrouille pour y arriver. Les commandes ressemblent d’ailleurs à celles d’un administrateur système : ax apply pour enregistrer une demande, ax watch pour la suivre en direct, ax ssh pour entrer dans l’environnement d’un agent, ax suspend et ax resume pour le mettre en sommeil ou le réveiller.

Les briques de base : Task, Workspace, Gateway, Model

Selon la documentation et la presse spécialisée, AX repose sur quelques « primitives » :

• Task : la mission confiée à un agent, exécutée dans un bac à sable isolé avec des plafonds de processeur et de mémoire.
• Workspace : l’établi préparé avant le départ (dépôts Git, serveurs MCP, bibliothèques de compétences).
• Gateway : le portier réseau, qui décide vers quels sites l’agent a le droit de sortir et qui injecte les mots de passe à sa place.
• Model : la fiche qui indique quel modèle de langage utiliser, avec quels réglages et quelles clés secrètes.

Note : Le README GitHub ne cite que trois briques (Task, Workspace, Model) ; la quatrième, Gateway, apparaît dans l’article d’InfoQ et celui d’ExplainX. Le projet évolue vite, d’où cette différence.

Le vrai tour de force : des agents qui dorment

Voici l’idée la plus fine du projet. Un agent passe l’essentiel de sa vie à attendre : que le modèle réponde, qu’une API renvoie des données, qu’un humain valide une étape. Laisser tourner tout ce petit monde sur des machines dédiées, c’est payer une chambre d’hôtel à des clients endormis.

AX fait donc l’inverse : quand un agent est inactif, il photographie son état (mémoire et fichiers) puis libère la place ; au moment où une réponse arrive, il le réveille. Les concepteurs annoncent une reprise en moins d’une seconde, sans « démarrage à froid ». Comme un ordinateur portable qui passe en hibernation, mais pour des milliers de sessions partagées sur les mêmes serveurs.

Exemple concret : Une équipe lance 500 agents chaque nuit pour trier des tickets clients. Chacun ne travaille réellement que quelques secondes par minute. Sans mise en veille, il faudrait 500 « places » réservées en permanence. Avec un système de type AX, une poignée de serveurs suffit, parce que les agents se relaient.

Sécurité : faire tourner du code qu’on ne maîtrise pas

Un agent peut écrire et exécuter du code. Donc il peut se tromper, ou être manipulé par un site piégé. AX place chaque agent dans une cage étanche (les sources évoquent la technologie gVisor) et contrôle les sorties réseau via la Gateway. Objectif : limiter le rayon d’explosion si un agent dérape.

Attention : un bac à sable n’est pas une garantie absolue Le projet est explicitement marqué « en plein développement », avec de probables changements majeurs avant une version stable. Ne confiez pas de données sensibles à AX en production sans audit sérieux.

À qui s’adresse AX (et à qui il ne s’adresse pas)

Si vous utilisez ChatGPT ou Claude dans votre navigateur, AX ne vous concerne pas. L’installation suppose un cluster Kubernetes équipé de la couche « Agent Substrate », plus Go, kubectl et l’outil ko. La commande d’entrée ressemble à ceci :

go install github.com/google/ax/cmd/ax@latest

Profil	AX est-il utile ?	Pourquoi
Particulier / curieux	Non	Aucun besoin d’infrastructure ; les assistants grand public suffisent.
Développeur solo, quelques agents	Probablement excessif	Une simple machine virtuelle bien verrouillée fait le travail.
Équipe technique, dizaines ou centaines d’agents	Oui, à tester	Mise en veille, contrôle réseau, secrets centralisés.
Labos et entreprises (évaluations, apprentissage par renforcement)	Oui	Lancer énormément de sessions isolées, reproductibles.

Les réserves de la communauté

Sur Hacker News, le camp des ingénieurs d’infrastructure salue les économies liées aux agents inactifs ; le camp des développeurs grince devant la lourdeur de maintenir un cluster Kubernetes et des définitions sur mesure. D’autres se demandent si Google poursuivra le projet sur la durée, l’entreprise ayant déjà abandonné quelques produits en chemin. Enfin, des alternatives existent : les offres hébergées (comme l’API Agents d’OpenAI) évitent d’administrer quoi que ce soit, au prix d’un contrôle moindre.

Alors, un standard ?

Pas à ce stade. AX est un projet prometteur et très regardé, pas une norme adoptée par l’industrie. Il pourrait néanmoins faire école : l’idée de traiter un agent comme un être dormeur et réveillable plutôt que comme un serveur allumé en continu est de celles qui changent les factures cloud. À surveiller, donc, sans s’emballer.

💬 Et vous, qu’en pensez-vous ?

1. Faire dormir ses agents IA pour économiser : révolution ou simple optimisation de cloud ?
2. Feriez-vous confiance à un bac à sable pour laisser une IA exécuter du code sur vos données ?
3. Préférez-vous un outil à héberger soi-même comme AX, ou un service clé en main hébergé par un éditeur ?

Dites-le nous en commentaire !