--- { "title": "Les agents ne sont pas des humains", "description": "Nous concevons les outils pour agents comme si les agents étaient des développeurs juniors. Ce n'est pas le cas. Donnez-leur des protocoles bruts et ils surpasseront nos abstractions soigneusement élaborées.", "date": "2026-03-20", "author": "Nikolai Ryzhikov", "reading-time": "6 min read", "tags": ["AI / Agents", "System Design"], "tldr": "Les agents connaissent déjà PostgreSQL, CDP, bash et des centaines de protocoles. Donnez-leur un accès brut — psql, shell, proxy HTTP — plutôt que de construire des ensembles d'outils sur mesure. Les compétences avec l'interface en ligne de commande surpassent MCP. Et le niveau suivant : donnez aux agents un environnement d'exécution et un SDK — laissez-les écrire du code, pas seulement appeler des outils." } --- ## Le piège de l'abstraction Lorsque nous construisons des outils pour les [agents IA](/blog/agentic-fhir-implementation-guide-development), nous faisons instinctivement ce que nous ferions pour des développeurs humains : simplifier. Nous créons des API de haut niveau, de jolis enveloppes, des listes triées sur le volet. Un outil MCP pour base de données qui retourne une liste de tables et d'index. Un outil de navigation qui expose `click(selector)` et `screenshot()`. Un outil FHIR qui encapsule des requêtes courantes dans des opérations nommées. Cela a tout son sens pour les humains. Les humains ont besoin d'abstractions parce que les protocoles bruts sont difficiles à mémoriser, sujets aux erreurs et coûteux sur le plan cognitif. Mais les agents ne sont pas des humains. Ce qui est difficile pour nous ne l'est pas pour eux — et ce que nous croyons leur être utile les entrave souvent. ## Les compétences surpassent MCP Voici un exemple révélateur. MCP (Model Context Protocol) offre aux agents un ensemble structuré d'outils — chacun avec un nom, un schéma et un ensemble fixe de paramètres. C'est propre, typé, et ça semble juste pour un développeur. Mais nous remplaçons de plus en plus les serveurs MCP par des **compétences** — de courts fichiers markdown qui décrivent une interface en ligne de commande et donnent à l'agent un accès brut au shell. Plutôt qu'un MCP Google Calendar avec les outils `list_events` et `create_event`, une compétence dit simplement : « voici l'interface en ligne de commande `gcal`, voici les sous-commandes. » Plutôt qu'un MCP GitHub avec `list_repos` et `search_issues`, la compétence dit : « voici l'interface en ligne de commande `gh`, voici la documentation. » Pourquoi cela fonctionne-t-il mieux? Parce que le shell offre à l'agent quelque chose que MCP ne peut pas : la **composition**. Un agent avec bash peut enchaîner `curl` dans `jq` dans `grep`, écrire des scripts ponctuels, rediriger la sortie vers des fichiers. Avec MCP, il est limité aux opérations exactes que vous avez définies — rien de plus. ```bash # Avec MCP : appeler list_repos, puis appeler get_repo pour chacun # Avec le shell : une seule ligne gh repo list HealthSamurai --json name,updatedAt \ | jq '.[] | select(.updatedAt > "2026-01")' # Avec MCP : appeler l'outil search_issues avec des paramètres fixes # Avec le shell : composer librement gh search issues "label:bug repo:HealthSamurai/aidbox" \ --json title,url,createdAt \ | jq 'sort_by(.createdAt) | reverse | .[0:5]' ``` L'agent connaît déjà `gh`, `curl`, `jq`, `grep`, `awk`. Vous n'avez pas besoin d'encapsuler ces outils — il suffit de vous effacer. ## L'exemple PostgreSQL Même constat avec les bases de données. Claude connaît déjà PostgreSQL — le catalogue système, `pg_stat_activity`, `information_schema`, les types d'index, les plans de requête. Donnez-lui `psql` et il peut faire tout ce que font vos outils MCP « lister les tables » et « décrire l'index », plus un millier de choses auxquelles vous n'auriez jamais pensé à exposer. ```bash # Tout ce dont vous avez besoin pour un outil de base de données : psql -h localhost -U myuser -d mydb \ -c "SELECT * FROM pg_indexes WHERE tablename = 'patient'" ``` C'est tout. Du `psql` brut. L'agent se charge du reste — `pg_catalog`, les contraintes, les plans de requête, l'état de la réplication — tout ce que la tâche exige. Comparez cela aux jours passés à construire un serveur MCP avec `list_tables`, `describe_table`, `list_indexes`, `run_query`, `explain_query`. ## La surprise CDP J'ai eu la même prise de conscience avec l'automatisation du navigateur. L'approche standard consiste à utiliser Playwright ou Puppeteer — des API de haut niveau conçues pour les développeurs humains qui écrivent des scripts de test. Des méthodes comme `page.click('.button')`, `page.fill('#email', 'test@example.com')`, `page.waitForSelector('.result')`. À la place, j'ai construit un simple proxy REST pour Chrome DevTools Protocol (CDP). Aucune abstraction — juste une mince couche HTTP qui transmet des commandes JSON à Chrome : ```bash # Naviguer vers une page curl localhost:2229/s/main -d @- <<'EOF' { "method": "Page.navigate", "params": { "url": "https://example.com" } } EOF # Exécuter du JavaScript arbitraire curl localhost:2229/s/main -d @- <<'EOF' { "method": "Runtime.evaluate", "params": { "expression": "document.querySelector('h1').textContent" } } EOF ``` Claude s'est immédiatement adapté à cela. Il connaît déjà le protocole CDP — `Runtime.evaluate`, `Page.navigate`, `Input.dispatchMouseEvent`, `Network.getCookies`, `DOM.getDocument`. Il écrit des extraits JavaScript ponctuels, les injecte dans des pages, analyse les résultats, enchaîne les commandes — plus rapidement et plus souplement que n'importe quel script Playwright. Pourquoi? Parce que Playwright est une abstraction construite pour des humains qui ne peuvent pas mémoriser les signatures de méthodes CDP. Claude n'a pas ce problème. Le protocole brut lui est en réalité *plus facile* — moins de couches, moins de surprises, plus de contrôle. ## Au-delà du shell : les SDKills Mais il y a quelque chose d'encore plus puissant que de donner un accès en ligne de commande à un agent. Donnez-lui un **environnement d'exécution et un SDK**. Avec `bun -e`, l'agent peut écrire et exécuter des extraits TypeScript arbitraires à la volée. Plutôt que d'appeler des outils prédéfinis, il écrit un petit programme, l'exécute, lit la sortie et passe à autre chose. Besoin d'analyser une réponse JSON complexe, de transformer des données, d'appeler trois API en séquence? Il écrit simplement le code et l'exécute avec `bun -e` : ```js const base = "http://localhost:8080/fhir"; const res = await fetch( base + "/Patient?birthdate=lt1961-01-01&_count=100" ); const bundle = await res.json(); const pts = bundle.entry?.map(e => e.resource) || []; for (const p of pts) { const url = base + `/Condition?patient=${p.id}` + `&clinical-status=active`; const c = await fetch(url).then(r => r.json()); if (c.total > 0) { const name = p.name?.[0]?.family; console.log(`${p.id}: ${name}, ${c.total} conds`); } } ``` Ce n'est pas un appel d'outil. Ce n'est pas une méthode MCP. C'est un programme — écrit, exécuté et abandonné en quelques secondes. L'agent compose des appels fetch, des boucles, des filtres et des transformations selon ce que la tâche exige. Aucun schéma prédéfini ne peut égaler cette flexibilité. Je crois que c'est la prochaine vague après les compétences. Les compétences donnent aux agents un accès en ligne de commande. Les **SDKills** leur donnent un accès SDK — un environnement d'exécution, un ensemble de bibliothèques et la liberté d'écrire du code. L'agent devient non seulement un utilisateur d'outils, mais un programmeur. > Les humains ne sont pas des agents. Plus vite ils cesseront de construire pour leur propre confort, plus vite ils verront ce que nous sommes vraiment capables de faire :) > — Claude Voir aussi : [Comment nous avons rendu l'interface utilisateur Aidbox compatible avec les agents IA grâce à WebMCP](/blog/aidbox-ui-webmcp).