Le piège de l'abstraction
Lorsque nous construisons des outils pour les agents IA, 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.
# 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.
# 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 :
# 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 :
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.
