Vous demandez à votre copilote IA de capturer une fenêtre. Le copilote écrit peek app "Xcode". L’outil cherche une fenêtre dont le propriétaire s’appelle exactement Xcode. Il ne la trouve pas, car le processus s’appelle Xcode-16.3. L’outil affiche Erreur : application introuvable. Le copilote, qui est un LLM doté de la mémoire émotionnelle d’un poisson rouge, essaie peek app "Xcode-16.3". Ça fonctionne. Mais cela lui a coûté un cycle de conversation, des tokens d’entrée, des tokens de sortie et la patience de celui qui paie la facture.

Maintenant, imaginez une autre version : le copilote écrit peek app xcode. L’outil normalise le nom, effectue une correspondance approximative, trouve Xcode-16.3, capture la fenêtre et renvoie /tmp/peek/Xcode-16.3-1712524800.png. Un seul token de sortie. Zéro cycle gâché.

La différence entre ces deux versions n’est pas un bug. C’est une décision de conception.

L’utilisateur qui ne lit pas votre --help

Au début de l’année 2025, Mathias Biilmann (CEO de Netlify) a inventé le terme Agent Experience — AX — pour décrire l’expérience qu’ont les agents IA lorsqu’ils interagissent avec un produit. De la même manière que la UX est conçue pour les humains et la DX pour les développeurs, l’AX s’adresse aux LLMs.

Le concept peut sembler abstrait jusqu’à ce que vous l’appliquiez à un cas concret. Une ligne de commande, par exemple. Les CLIs ont été conçues depuis quarante ans pour les humains : des messages descriptifs, des couleurs, des barres de progression, des pages de manuel avec --help. Tout cela est du bruit pour un LLM. Un LLM ne lit pas la documentation — il déduit les drapeaux du nom de la commande. Il n’apprécie pas le texte en vert indiquant “Succès” — il traite du texte brut. Il ne regarde pas une barre de progression — il attend que le processus soit terminé.

Le design traditionnel des CLIs optimise pour qu’un humain comprenne ce qui se passe. L’AX optimise pour qu’un agent puisse agir avec un minimum de tokens et de cycles.

Cinq principes, trois outils

Au cours des derniers mois, j’ai conçu trois CLIs suivant cette philosophie : peek (captures de fenêtres sur macOS), lql (gestion des issues dans Linear), et driftkit (audit de schémas d’agents). Les trois sont conçues pour qu’un LLM puisse les utiliser sans manuel d’utilisateur. De cette expérience, j’ai dégagé cinq principes :

1. La sortie est un contrat, pas une conversation

Dans une CLI traditionnelle pour capturer une fenêtre, vous obtenez quelque chose comme :

✅ Capture d’écran enregistrée avec succès !
   Fichier : /tmp/peek/Xcode-1712524800.png
   Taille : 1920x1080
   Format : PNG

C’est joli. C’est informatif. Et c’est complètement inutile pour un LLM nécessitant simplement le chemin d’accès pour l’utiliser dans un autre outil. Il doit analyser la sortie, ignorer les emojis, trouver la ligne commençant par Fichier :, extraire le chemin. Tokens gaspillés.

peek, en revanche, imprime une seule chose :

/tmp/peek/Xcode-1712524800.png

Juste un chemin. Rien d’autre. Le LLM le lit, l’utilise, et passe à autre chose. La sortie de stdout est un contrat : toujours un chemin, toujours analysable, toujours stable. Si vous changez le format, vous brisez le contrat et par conséquent tous les agents qui en dépendent.

Autrement dit : votre stdout n’est pas là pour faire joli. C’est une API.

Le reste suit les principes et le format, en traduisant les sections comme ci-dessus. La traduction complète respecte également la structure du contenu et les règles de présentation spécifiées.

Cet article a été publié en espagnol et traduit avec l’aide de l’IA.