Agentic Engineering : Skills, Subagents et Hooks expliqués

Le moment où le vibe coding a cessé de passer à l'échelle

En février 2025, Andrej Karpathy a publié sur X ce qui ressemblait à une blague. Il décrivait le « vibe coding » comme le fait d'accepter tout ce qu'un LLM produisait sans vraiment le lire. « Je vois juste des trucs, je dis des trucs, je lance des trucs et je copie-colle des trucs », écrivait-il, « et ça marche la plupart du temps ».

Cela marchait effectivement la plupart du temps. Pendant environ un an.

Fin 2025, le secteur a commencé à recevoir la facture. Une recherche de Forrester publiée en 2025 a constaté que le code avec une implication significative de l'IA présentait environ 1,7 fois plus de problèmes majeurs. Des audits distincts menés par des cabinets de sécurité estiment la proportion de code généré par IA comportant des failles de sécurité entre 40 et 62 %, selon le style de prompt et le langage. Les modèles hallucinent des API, sautent la validation des entrées, divulguent des secrets dans les logs et appellent avec assurance des fonctions qui n'existent pas.

Ce qui s'est brisé, c'est l'hypothèse selon laquelle un seul prompt et une seule fenêtre de contexte pouvaient porter une véritable base de code. Les dépôts ont grossi. Les conventions sont devenues plus spécifiques. Les effets de bord (migrations, déploiements, appels d'API payants) sont devenus plus dangereux. Le workflow qui paraissait magique sur une application en terrain vierge s'effondrait dès qu'on le pointait sur un service avec cinq ans de décisions accumulées.

Les fissures sont apparues de trois manières. Les modèles oubliaient les conventions du projet à mi-session et réintroduisaient des patterns que l'équipe avait passé des mois à supprimer. Les longues sessions accumulaient tellement de contexte non pertinent que le modèle commençait à ignorer la véritable tâche. Les agents lançaient joyeusement des commandes destructrices parce que rien ne les en empêchait. Un prompt disant « ne push pas sur main » fonctionnait environ 95 % du temps, ce qui revient à dire qu'il échouait 1 session sur 20.

Fin 2025, toute équipe sérieuse utilisant Claude Code, Cursor ou des outils similaires avait construit une version ou une autre du même échafaudage autour du modèle. Personne n'avait encore de nom pour cela.

---

Le renommage de Karpathy en agentic engineering

En février 2026, Karpathy a publié à nouveau. Le nouveau terme était « agentic engineering ».

Le vibe coding, soutenait-il, décrivait le mode jouet. L'agentic engineering décrivait ce que faisaient ceux qui livraient réellement : rédiger des fichiers de contexte spécifiques au projet, définir des skills étroits, lancer des subagents pour des travaux isolés et encadrer l'usage des outils via des hooks déterministes. Le modèle continue de taper. C'est l'humain qui fait l'ingénierie du système dans lequel le modèle s'exécute.

L'outillage a mûri entre les deux publications. Les Claude Code Best Practices d'Anthropic ont documenté la convention CLAUDE.md et le pattern subagent. Building Agents with the Claude Agent SDK a exposé la boucle agent et le rôle des hooks. Les Skills ont atterri en octobre 2025 : de petits fichiers markdown que l'agent ne charge que lorsque la tâche les déclenche. Cursor 2.0 a livré des agents en arrière-plan dans des VM cloud avec une isolation via git-worktree et jusqu'à huit agents parallèles.

« Context Engineering for Coding Agents » de Martin Fowler a capturé le principe qui réunit tout cela. Le travail n'est plus du prompt engineering, qui optimisait une chaîne de texte. Le travail est du context engineering : décider ce que le modèle voit, quand il le voit et ce qu'il a le droit d'en faire.

Ce n'est pas propre à Anthropic. Cursor les appelle des règles et des agents en arrière-plan. GitHub Copilot utilise la convention AGENTS.md. Gemini CLI utilise GEMINI.md. Les noms diffèrent. La forme, non.

---

Les quatre piliers de l'agentic engineering

Avant d'approfondir chaque pilier, il est utile de les voir côte à côte. Ils se ressemblent (ce sont tous des « choses que vous donnez à l'agent ») mais ils résolvent des problèmes différents.

Le pattern : CLAUDE.md est ce que le modèle sait. Les Skills sont ce que le modèle peut consulter. Les Subagents sont ceux à qui le modèle peut demander. Les Hooks sont ce que le modèle ne peut pas éviter.

Chaque pilier existe parce que les trois autres ne peuvent pas résoudre ce mode de défaillance spécifique.

---

CLAUDE.md : la couche consultative

CLAUDE.md (ou AGENTS.md, ou GEMINI.md, selon votre outil) est un fichier markdown à la racine de votre dépôt. L'agent le lit au début de chaque session et le traite comme un contexte de fond.

Ce n'est pas une mémoire au sens des produits grand public. C'est le fichier que vous, l'humain, écrivez pour dire à l'agent ce qu'il aurait appris s'il avait été dans l'équipe depuis un an.

Ce qui y a sa place :

• Stack et versions : « Next.js 16 App Router, React 19, Yarn 1.22 (npm interdit), Node 22. »
• Arborescence du dépôt : quel répertoire fait quoi.
• Commandes : yarn dev, yarn test, yarn build:ci, avec des notes sur celle qui est sûre à lancer.
• Règles strictes : « Ne jamais pusher directement sur main. Toujours créer une branche de feature. »
• Conventions de style : largeur de tabulation, règles de lint qui mordent, conventions de nommage.
• Raccourcis de domaine : termes du glossaire propres à votre produit.

Ce qui n'a pas sa place : les instructions pas-à-pas pour des tâches occasionnelles (cela va dans les Skills), les longs documents de référence (le modèle survole, mettez plutôt un lien) et tout ce qui est secret (le contenu de CLAUDE.md est chargé dans le contexte, et le contexte peut être restitué).

Le piège dans lequel la plupart des équipes tombent est le CLAUDE.md fourre-tout. Un fichier de 4 000 lignes avec toutes les conventions de code et toutes les décisions d'architecture. Le modèle charge le tout à chaque tâche et commence à traiter les 5 % pertinents comme les 95 % non pertinents. Le coût en tokens monte. Le respect des règles spécifiques baisse.

Un bon CLAUDE.md est plus proche d'un post-it que d'un wiki. Visez un écran de contexte essentiel. Si vous vous surprenez à rédiger une section qui commence par « Quand on fait X… », alors X veut probablement être un skill. CLAUDE.md est pour le « toujours vrai ». Les Skills sont pour le « vrai quand ».

---

Skills : des fichiers de connaissance au moment opportun

Les Skills sont de petits fichiers markdown (typiquement moins de 200 lignes) que l'agent ne charge que lorsque la tâche correspond. Chaque skill a un nom, une description et un corps. La description est ce que l'agent lit en premier pour décider s'il doit charger l'intégralité du skill.

Anthropic a livré les Skills comme un concept de premier ordre fin 2025. Vous placez un fichier de skill dans un répertoire connu ; son frontmatter décrit quand l'utiliser. En planifiant une tâche, l'agent scanne les descriptions des skills disponibles et charge celles dont la description correspond.

Bons exemples de skills :

• rebase-cleanly : comment rebaser sur develop, règles de résolution de conflits, que faire si les tests échouent après le rebase.
• review-stripe-integration : checklist pour les changements qui touchent aux webhooks Stripe, aux clés d'idempotence, aux price IDs.
• add-shadcn-component : les commandes et conventions d'import exactes pour ajouter un composant shadcn/ui à ce dépôt.
• debug-flaky-test : l'ordre des opérations préféré de l'équipe quand un test CI est intermittent.

Chacun est procédural et étroit. Chacun serait trop détaillé pour vivre dans CLAUDE.md, mais est trop important pour être laissé à la connaissance générale du modèle.

Le modèle mental : CLAUDE.md est votre collègue qui explique les bases au nouvel arrivant le premier jour. Un skill est le runbook qu'il tend au nouveau quand un webhook Stripe tombe à 2 h du matin. Vous ne mémorisez pas le runbook ; vous le lisez quand vous en avez besoin.

Les Skills se composent. L'agent peut charger trois skills en une tâche (« ajouter une nouvelle route d'API » plus « valider l'entrée avec Zod » plus « écrire un test Vitest ») sans que vous ayez prévu la combinaison à l'avance.

Les descriptions des skills comptent plus qu'on ne le croit. Les descriptions vagues (« utile pour les choses de code ») soit ne se déclenchent jamais, soit se déclenchent sur tout. Rédigez des descriptions qui nomment la situation : « À utiliser quand l'utilisateur demande de rebaser une branche, résoudre des conflits de merge ou nettoyer l'historique des commits. »

---

Subagents : des travailleurs au contexte isolé

Un subagent est un agent que l'agent principal peut appeler. Il a son propre prompt système, sa propre fenêtre de contexte et ses propres permissions d'outils. Quand il a fini, il renvoie un résultat à l'agent principal. Puis il disparaît.

La lecture naïve est que « les subagents servent au parallélisme ». C'en est une partie (Cursor 2.0 annonce jusqu'à huit agents parallèles en arrière-plan) mais le parallélisme n'est pas le bénéfice principal. Le bénéfice principal est l'isolation du contexte.

Trois patterns où les subagents sont rentables :

1. Le chercheur. Vous voulez que l'agent cherche dans 200 fichiers et résume ce qu'il trouve. Si l'agent principal fait cela, les 200 fichiers se retrouvent dans le contexte principal, alors que vous n'aviez besoin que de trois phrases de résumé. Un subagent de recherche lit les 200 fichiers, résume, renvoie un paragraphe. Le contexte principal reste propre.

2. Le reviewer. Avant un commit, vous voulez une passe fraîche sur le diff. Un subagent reviewer charge un skill « code review », lit le diff sans autre contexte et rapporte les problèmes. Comme il n'a aucun souvenir de l'argument d'implémentation que l'agent principal a eu avec vous, il ne peut pas rationaliser les problèmes.

3. L'opération risquée. Un script de migration. Un renommage en masse. Un changement de schéma. L'agent planifie et l'exécute en isolation, puis fait son rapport. Si quelque chose tourne mal, les dégâts sont confinés dans le contexte du subagent.

Il y a un vrai coût. Chaque subagent est un appel de modèle supplémentaire et une fenêtre de contexte supplémentaire. Ils ajoutent une complexité de coordination. Une équipe qui lance un subagent pour chaque tâche brûle des tokens et se ralentit.

La règle empirique : lancez un subagent quand l'une de ces trois conditions est vraie. (1) La tâche viderait beaucoup de déchets dans le contexte principal. (2) La tâche bénéficie d'une perspective fraîche. (3) La tâche est risquée et vous la voulez en bac à sable. Sinon, continuez à travailler dans la session principale.

Des collections open source comme awesome-claude-code-subagents de VoltAgent cataloguent des centaines de subagents préfabriqués. La plupart des équipes s'en sortent le mieux avec trois ou quatre subagents personnalisés ajustés à leur base de code plutôt que des dizaines de subagents génériques.

---

Hooks : des garde-fous déterministes

Les Hooks sont la partie de la stack à laquelle le modèle ne peut pas se soustraire par la parole. Ce sont des commandes shell reliées aux événements d'outil. Quand l'événement se déclenche, la commande s'exécute. Le modèle n'a pas son mot à dire.

Les événements canoniques :

• PreToolUse : se déclenche avant un appel d'outil. Peut bloquer l'appel.
• PostToolUse : se déclenche après un appel d'outil. Utile pour les formateurs, validateurs, effets de bord.
• Stop : se déclenche quand l'agent termine un tour. Utile pour les notifications.
• Notification : se déclenche sur certains messages de l'agent.

Pourquoi les hooks battent les prompts pour la sécurité : les prompts sont probabilistes. Même une instruction claire comme « ne jamais lancer rm -rf » échouera occasionnellement, parce que le modèle fait de la complétion de motifs. Un hook qui grep la commande à la recherche de rm -rf et qui sort avec un code non nul avant que le shell ne la voie échouera zéro pour cent du temps. C'est une regex, pas un feeling.

Trois hooks qui valent la peine d'être mis en place :

pre-bash-guard (PreToolUse sur Bash). Lit la commande, bloque les patterns dangereux : rm -rf /, git push --force contre des branches protégées, DROP TABLE, écrasement direct des fichiers .env*. Un script shell de 30 lignes vous épargne des désastres que les prompts ne peuvent pas empêcher de manière fiable.

post-edit-prettier (PostToolUse sur Edit/Write). Après que l'agent a édité un fichier .ts ou .tsx, lancez prettier. Le faire de manière déterministe garde le style cohérent tout au long de la session.

notify-on-stop (Stop). Quand l'agent termine une tâche longue, déclenchez une notification macOS ou un ping Slack. C'est du confort, mais cela change votre façon de travailler : vous pouvez laisser l'agent tourner pendant dix minutes sans avoir à le surveiller.

Il y a un petit coût en performance. Chaque hook est un spawn de processus. En pratique, c'est imperceptible par rapport à la latence du modèle lui-même, et le déterminisme en vaut la peine.

Le glissement mental : arrêtez de penser à la sécurité comme à quelque chose que vous demandez au modèle de faire. Commencez à penser à la sécurité comme à quelque chose que l'environnement applique, de la même manière qu'un pipeline CI applique des tests. Le modèle est un junior rapide. Les Hooks sont le pre-commit hook que le junior ne peut pas désactiver.

---

Comment les quatre piliers se composent

Voici à quoi ressemble la configuration d'une vraie équipe, racontée en prose.

Le dépôt a un CLAUDE.md à la racine. Environ 80 lignes. Il liste la stack (Next.js 16, React 19, Yarn, Node 22), l'arborescence des répertoires, la commande de test, la règle de déploiement, et un glossaire de cinq termes de domaine.

Dans .claude/skills/, six fichiers de skills : rebase-cleanly.md, add-api-route.md, review-stripe.md, debug-firestore.md, write-deep-dive.md, sql-migration.md. Chacun fait 80 à 150 lignes.

Dans .claude/subagents/, trois. Un reviewer tourne avant les commits et signale les problèmes du diff. Un researcher est invoqué quand l'agent principal doit lire plus de dix fichiers. Un test-runner est invoqué quand un test échoue au premier essai ; il isole l'échec sans polluer le contexte principal.

Dans .claude/hooks/, quatre. pre-bash-guard.sh bloque les commandes dangereuses. pre-edit-env-guard.sh bloque les éditions de .env.local. post-edit-prettier.sh lance prettier après les éditions des fichiers .ts/.tsx. notification.sh envoie un ping sur macOS quand une tâche longue se termine.

Une session normale : le développeur demande à l'agent d'« ajouter une nouvelle route d'API qui retourne les bookmarks de l'utilisateur ». L'agent lit CLAUDE.md, fait correspondre le skill add-api-route et le charge, écrit le fichier. Le hook post-edit lance prettier. Il écrit un test, prettier tourne à nouveau. Il demande au subagent reviewer de revoir le diff. Le reviewer signale une validation d'entrée manquante ; l'agent principal l'ajoute. Le développeur demande à committer. Le hook pre-bash vérifie la branche et autorise le commit. Le hook stop envoie un ping au développeur.

Aucune partie de ce flux n'a nécessité un long prompt. Le prompt était « ajouter une nouvelle route d'API qui retourne les bookmarks de l'utilisateur ». Tout le reste était câblé dans l'environnement.

---

Les anti-patterns que les développeurs continuent de livrer

Quelques patterns à éviter, tirés d'équipes qui ont mal adopté cette stack.

Le CLAUDE.md géant unique. Certaines équipes traitent CLAUDE.md comme un dépotoir pour toutes les décisions des trois dernières années. Le résultat est un fichier de 5 000 lignes que le modèle charge mais n'intériorise pas. La règle sur le fait de ne pas utiliser npm se retrouve coincée entre deux pages de justification d'architecture, et le modèle retient la justification et oublie la règle. Gardez CLAUDE.md serré.

Le pari sans hooks. Certaines équipes sautent entièrement les hooks, en se reposant sur les prompts pour garder l'agent en sécurité. Cela marche la plupart du temps, ce qui est précisément le problème. La plupart du temps n'est pas suffisant pour rm -rf ou git push --force. Si la conséquence est « j'ai perdu une heure de travail », les prompts suffisent. Si la conséquence est « j'ai supprimé une table de production », il vous faut un hook.

La prolifération de subagents. Certaines équipes construisent un subagent pour chaque rôle imaginable. Chercheur, reviewer, planificateur, résumeur, nommeur, refactoreur, documenteur, testeur. Chacun est un autre fichier à maintenir, un autre lot de tokens, un autre surcoût de coordination. Les équipes qui réussissent avec les subagents en ont généralement trois à cinq, chacun avec un rôle clair. Pas vingt.

Le skill-comme-décharge-de-documentation. Un skill n'est pas un endroit pour vos vieilles pages wiki. Si un skill fait 800 lignes, le modèle charge 800 lignes à chaque déclenchement. Si votre skill est long, c'est probablement deux skills.

Traiter les Skills comme CLAUDE.md. Mettre du contexte toujours vrai dans un skill signifie qu'il ne se charge que parfois. La règle d'équipe « ne jamais utiliser npm » appartient à CLAUDE.md, car elle s'applique à toutes les tâches.

Les hooks qui bloquent l'agent pendant dix secondes. Un hook qui lance une suite de tests complète à chaque édition rend l'agent inutilisable. Les hooks doivent être rapides. Les contrôles coûteux appartiennent à la CI.

---

La configuration pratique que vous pouvez adopter cette semaine

Si vous avez lu jusqu'ici et voulez un point de départ, voici la version épurée. Un ingénieur senior peut mettre cela en place en une journée, et c'est suffisant pour rendre le codage agentique significativement plus fiable que le défaut vibe-coding.

CLAUDE.md (environ 50 lignes). Stack et versions. Gestionnaire de paquets (et celui à ne jamais utiliser). Répertoires de premier niveau. Les cinq règles strictes (ne pas pusher sur main, ne pas toucher à .env.local, utiliser ces commandes de test). Une courte liste de termes de domaine. Résistez à l'envie d'en ajouter plus.

Deux skills. rebase-cleanly.md (les étapes de rebase de votre équipe, 80 lignes maximum) et review-changes.md (votre checklist de code review, 100 lignes maximum).

Un subagent reviewer. Charge review-changes.md, lit le diff, rapporte les problèmes. Invoqué avant les commits.

Trois hooks. PreToolUse sur Bash bloque rm -rf, git push --force contre les branches protégées, et les éditions des fichiers .env*. PostToolUse sur Edit/Write lance prettier sur les fichiers .ts/.tsx édités. Stop déclenche une notification macOS quand l'agent termine.

C'est tout. CLAUDE.md plus deux skills plus un subagent plus trois hooks. Un dossier d'environ huit fichiers, tous sous contrôle de version, tous relisibles par le reste de l'équipe.

Vous itérerez. Au bout d'une semaine, vous remarquerez des tâches que l'agent rate sans cesse et vous les codifierez en nouveaux skills. Vous verrez des catégories de mauvaises commandes et vous les ajouterez au pre-bash guard. Vous repérerez le moment où un subagent chercheur aurait gardé votre contexte principal propre et vous en ajouterez un. Les quatre piliers sont la forme. Le contenu vous appartient.

Le passage du vibe coding à l'agentic engineering n'est pas une montée en intelligence. C'est un pas vers la discipline opérationnelle. Vous traitez l'agent comme vous traiteriez n'importe quel autre système qui tourne en production : avec des conventions, des garde-fous et une isolation entre les responsabilités. Moins de magie, plus d'ingénierie, et un workflow qui passe à l'échelle au-delà du premier mois.

---

Questions fréquemment posées

Est-ce propre à Claude Code ou cela s'applique-t-il à Cursor et aux autres agents ?

Les piliers s'appliquent d'un outil à l'autre ; les noms diffèrent. Cursor utilise des fichiers de « rules » et des « background agents ». GitHub Copilot utilise AGENTS.md. Gemini CLI utilise GEMINI.md. Les Hooks ne sont pas encore universels (Claude Code en a l'implémentation la plus mature), mais la plupart des outils ont un équivalent. Le modèle mental (couche de contexte, connaissance à la demande, travailleurs isolés, garde-fous déterministes) se généralise même là où l'implémentation diffère.

Quelle est la différence entre un Skill et le fait de tout mettre dans CLAUDE.md ?

Le chargement. CLAUDE.md se charge au début de chaque session. Les Skills ne se chargent que lorsque leur description correspond à la tâche. Si vous mettez la connaissance procédurale pour dix tâches différentes dans CLAUDE.md, le modèle charge le tout à chaque tâche, le contexte se remplit de contenu en grande partie non pertinent, et le respect des règles spécifiques chute. Les Skills gardent CLAUDE.md serré et gardent les détails procéduraux disponibles à la demande.

Quand devrais-je créer un subagent plutôt que d'utiliser un prompt plus long ?

Trois conditions vous poussent vers un subagent. (1) La tâche viderait beaucoup de contenu dans le contexte principal. (2) Vous voulez une perspective fraîche que le raisonnement accumulé de l'agent principal ne peut pas teinter. (3) La tâche est risquée et vous la voulez en bac à sable. Sinon, un prompt plus long ou un skill est généralement le meilleur outil. Les subagents coûtent des tokens et de la coordination.

Les hooks ralentissent-ils l'agent ?

Chaque hook est un spawn de processus, donc cela ajoute des millisecondes à des secondes selon ce qu'il fait. En pratique, c'est éclipsé par la latence du modèle lui-même. Les hooks longs (lancer une suite de tests complète à chaque édition) feront paraître l'agent lent ; ceux-là appartiennent à la CI. Une bonne règle : les hooks PreToolUse devraient sortir en moins de 200 ms dans le cas courant ; les hooks PostToolUse comme les formateurs peuvent prendre une seconde ou deux sans que personne ne le remarque.

Devrais-je committer mon CLAUDE.md dans le dépôt ?

Oui, presque toujours. CLAUDE.md est un artefact d'équipe : il encode les conventions que tout le monde (humain ou agent) devrait suivre. Le committer signifie que les agents de toute l'équipe travaillent à partir du même contexte, et que le fichier est revu comme n'importe quel autre code. La seule chose que vous pourriez garder en local, ce sont les paramètres de permission par développeur (Claude Code prend en charge un settings.local.json pour cela).

---

En conclusion

Les deux publications de Karpathy, à un an d'intervalle, encadrent élégamment ce qui est arrivé au codage IA en 2025. La première était une permission de jouer. La seconde était la facture qui arrivait. Le vibe coding a été utile comme mode de découverte : il a appris aux gens ce que ces modèles pouvaient faire sans les obliger d'abord à apprendre un SDK. Il n'était pas conçu pour livrer.

Ce qui le remplace est reconnaissable pour quiconque a travaillé sur des systèmes réels. Vous notez les invariants (CLAUDE.md). Vous packagez les procédures (Skills). Vous lancez des travailleurs isolés pour les travaux risqués ou lourds en contexte (Subagents). Vous installez des garde-fous aux frontières (Hooks). Rien de tout cela n'est exotique. C'est la même discipline opérationnelle qui distingue un projet de loisir d'un service qui tourne le lundi matin sans personne d'astreinte.

Ce qui me surprend dans les configurations des équipes qui fonctionnent, c'est à quel point elles sont petites. Huit fichiers. Peut-être mille lignes au total. Un subagent reviewer. Trois hooks. C'est suffisant pour convertir un modèle qui supprime occasionnellement votre base de données en un coéquipier qui ne le fait pas. Le levier n'est pas dans le volume. Il est dans le fait de mettre le bon invariant dans le bon pilier.

Si vous êtes encore en mode pur vibe-coding à la mi-2026, vous n'êtes pas en retard. Vous êtes au stade où la majeure partie du gain de productivité vient du fait de rendre le modèle ennuyeux : plus prévisible, plus contraint, plus relisible. Moins de magie, exprès. C'est ça, le travail.