Agent, harnais, skills, hooks : quatre concepts qu'on confond

On parle beaucoup d'agents IA en ce moment, mais on confond souvent quatre concepts bien distincts : l'agent, le harnais qui l'orchestre, les skills chargés à la demande et les hooks déclenchés sur événement. Les séparer clairement aide à comprendre ce qui relève du probabiliste et ce qui relève du déterministe dans un système agentique, et évite des erreurs de conception coûteuses.
┌──────────────────────── harnais (déterministe) ────────────────────────┐
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ agent (boucle, probabiliste) │ │
│ │ │ │
│ │ observer ──▶ décider ──▶ agir ──▶ observer le résultat │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ skill chargé si le modèle juge utile (probabiliste) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ hook ── s'exécute systématiquement sur un événement (déterministe) │
└──────────────────────────────────────────────────────────────────────────┘
L'agent : la boucle
L'agent, c'est la boucle elle-même : le modèle observe un contexte, décide d'une action (répondre, appeler un outil, s'arrêter), observe le résultat, et recommence. Cette boucle est probabiliste par nature : à contexte identique, le modèle peut choisir des chemins différents. C'est cette propriété qui rend l'agent utile sur des tâches ouvertes, et qui le rend inadapté aux tâches qui exigent une garantie stricte.
Le harnais : ce qui orchestre l'agent
Le harnais est la couche logicielle autour de l'agent : il gère le contexte (quelles informations sont visibles par le modèle), le format des outils disponibles, la mémoire entre les tours, la reprise après erreur. Claude Code, par exemple, est un harnais : il ne « pense » pas à la place du modèle, mais il détermine ce que le modèle peut voir et faire à chaque étape.
Le choix du harnais a plus d'impact sur la qualité perçue d'un agent que le choix du modèle lui-même : un excellent modèle mal outillé produit des résultats médiocres, alors qu'un harnais bien conçu peut compenser une partie des limites du modèle en lui fournissant exactement le contexte dont il a besoin, au bon moment.
Les skills : du probabiliste chargé à la demande
Un skill est une capacité que l'agent peut choisir de charger quand il juge que c'est pertinent. C'est le modèle qui décide : rien ne garantit qu'un skill disponible sera effectivement utilisé pour une tâche donnée. C'est un mécanisme probabiliste, au même titre que le reste du raisonnement de l'agent.
Cette nature probabiliste n'est pas un défaut, c'est une caractéristique recherchée : elle permet d'avoir des dizaines de skills disponibles sans surcharger systématiquement le contexte de l'agent avec des instructions qui ne serviront pas à la tâche en cours.
Les hooks : du déterministe déclenché sur événement
Un hook, à l'inverse, s'exécute systématiquement quand un événement précis se produit (avant un appel d'outil, après une réponse, à l'échec d'une action). Il ne dépend pas du jugement du modèle : c'est du code classique, prévisible, qui s'exécute à chaque fois que la condition est remplie, sans exception et sans que le modèle ait voix au chapitre.
Les quatre concepts, en un tableau
| Concept | Nature | Qui décide de son déclenchement | Exemple concret |
|---|---|---|---|
| Agent | Probabiliste | Le modèle, à chaque tour de la boucle | Le raisonnement qui choisit d'appeler un outil de recherche plutôt qu'un autre |
| Harnais | Déterministe | Le code qui entoure l'agent | Claude Code décidant quels fichiers sont visibles dans le contexte |
| Skill | Probabiliste | Le modèle, s'il juge le skill pertinent | Un skill de revue de code, chargé seulement si la tâche ressemble à une revue |
| Hook | Déterministe | Un événement précis, sans jugement du modèle | Un hook qui bloque systématiquement un rm -rf avant exécution |
Le tableau se lit surtout par sa troisième colonne : dès qu'une garantie ne doit jamais dépendre du jugement du modèle, seule la colonne « déterministe » (harnais ou hook) peut l'offrir. Un skill, aussi bien écrit soit-il, reste par nature une invitation, jamais une obligation.
Pourquoi cette distinction compte
Dès qu'on a besoin d'une garantie, d'une validation systématique ou d'une règle de sécurité qui ne doit jamais être contournée, un hook est le bon outil : il est déterministe. Dès qu'on a besoin d'étendre les capacités de l'agent sans l'alourdir en permanence, un skill est le bon outil : il n'est chargé que si l'agent en a besoin.
Confondre les deux mène à des architectures fragiles, où l'on attend d'un mécanisme probabiliste (un skill) une garantie qu'il ne peut pas offrir, ou où l'on rend rigide (via des hooks) ce qui devrait rester adaptatif. J'ai vu les deux erreurs en pratique : une règle de sécurité critique confiée à un skill, qui fonctionnait la plupart du temps mais pas systématiquement, et un hook si rigide qu'il bloquait des cas légitimes que son auteur n'avait pas anticipés. Dans les deux cas, le problème n'était pas l'implémentation, mais le choix du mauvais mécanisme dès le départ.