01–07 · Environ 5 minutes
Le logiciel a désormais trois expériences à concevoir.
Les humains ont une UX. Les développeurs ont une DX. Le lecteur le plus récent a une AX — et la plupart des plateformes ne l’ont pas encore construite.
01 — Trois expériences
UX. DX. AX.
L’AX n’est pas une UX simplifiée, ni une DX automatisée. C’est un troisième lecteur, avec ses propres exigences.
02 — Concrètement
Des choses que l’on peut désormais simplement demander.
Chacune de ces phrases peut être tapée aujourd’hui, telle quelle, dans un assistant de code IA.
❭ Connecte Claude Code — ou tout assistant compatible MCP — à ton compte EigenVertex, depuis ton terminal.
Une commande et une connexion normale — puis il peut interroger tes données, en ingérer de nouvelles, et construire une intégration dans ta propre appli.
❭ Installe EigenVertex sur ce serveur Ubuntu.
L’assistant lit la connaissance de déploiement, demande ce qu’il ne sait pas, et installe.
❭ Configure EigenVertex pour un VPC privé, sans trafic externe.
L’assistant ajuste le déploiement lui-même, pas seulement une page de réglages.
❭ Intègre EVTX dans cette application Next.js.
L’assistant câble le client API, l’authentification et la gestion d’erreurs — pas un extrait générique.
❭ Construis un panneau de chat EVTX dans notre tableau de bord existant.
L’assistant génère des composants, le streaming et un style cohérents avec l’application, pas une démo.
❭ Ajoute un panneau de chat à notre appli, adossé à l’une de nos Constellations.
L’assistant monte le SDK de relais partagé côté serveur et ajoute un client de chat léger — la clé API n’atteint jamais le navigateur.
❭ Pourquoi ce déploiement EVTX est-il lent aujourd’hui ?
L’assistant lit les runbooks, vérifie l’architecture, et rapporte ce qui a changé.
Rien de tout cela n’est un tour de chatbot. Ce sont des tâches qu’un assistant peut réellement terminer.
03 — Apportez votre propre agent de code
Vos données, dans votre agent — en une commande.
EigenVertex expose désormais un serveur MCP distant, joignable par tout assistant compatible MCP avec pour seul prérequis la connexion EigenVertex de l’utilisateur — pas de serveur local, pas d’accès à l’infrastructure.
Pour la première fois, nous avons connecté Claude.ai, Claude Desktop et Claude Code à un compte EigenVertex Cloud réel de cette façon : une vraie connexion OAuth, de vrais outils, de vraies données — l’isolation entre comptes a été testée et prouvée.
Un vrai prompt, validé de bout en bout
❭ Ajoute un panneau de chat à cette appli, adossé à ma Constellation EigenVertex.
Aucun schéma d’architecture, aucun code de liaison écrit à la main — l’agent le construit.
Ce n’est pas le schéma de ce que pourrait être l’accès agent. C’est un terminal, un compte réel, et une vraie réponse.
04 — L’Agent Kit
Un second jeu de documentation — écrit pour un lecteur qui ne survole pas.
La documentation humaine est écrite pour être lue dans l’ordre, le jugement comblant les manques. Un agent ne comble pas les manques — il a besoin que le manque lui-même soit écrit.
L’Agent Kit EVTX est un ensemble structuré d’actifs de connaissance construits pour ce lecteur : précis, délimités, et faits pour être exécutés, pas seulement lus.
Deux publics, pas un seul
Les commandes ci-dessous sont celles du CLI eigen — un outil d’opérateur, pour un déploiement auto-hébergé ou en administration. Si vous êtes client Cloud, vous n’en avez besoin d’aucune : votre porte d’entrée est le Cloud Quickstart, en MCP ou via le SDK de relais, sans infrastructure requise.
Lire le Cloud Quickstart →eigen /
Chaque commande parle JSON — pensée pour être lue par un script ou un agent, pas par un humain qui plisse les yeux devant un terminal. Un fichier de compétence (skill file) indique à un assistant quand utiliser quelle commande, quels sont les modes d’échec courants, et ce qui reste une lacune connue plutôt qu’une hypothèse silencieuse. Il a été corrigé sur le vif, sous les yeux de sa propre suite de tests, chaque fois que la réalité contredisait le plan — c’est ça, la véritable expérience agent, pas le schéma qui la représente.
05 — Documentation exécutable
Une documentation que l’assistant peut exécuter, pas seulement lire.
Un humain lit install.md et fait le travail. Un assistant lit install.md et fait le travail aussi — la différence est qu’il peut demander, décider et agir dans le même mouvement.
C’est toute l’idée derrière la documentation exécutable : le document n’est pas une description de la tâche. Il est assez proche de la tâche pour qu’un agent puisse l’exécuter directement.
« Installe EigenVertex sur ce serveur Ubuntu. »
L’assistant ne devine pas à partir d’un article de blog. Il suit la même source qu’un ingénieur humain aurait utilisée.
06 — De l’API à l’agent
L’API est la fondation. L’Agent Kit est ce qui se construit dessus.
Chaque couche ci-dessous est une brique réelle et distincte — pas un simple renommage de celle au-dessus.
L’API n’a jamais été le plafond. C’était la fondation sur laquelle tout le reste ici se construit.
07 — La suite