L’Ingénierie Agentique n’est pas du vibe coding avec un meilleur nom. C’est le modèle d’exploitation qui transforme le code généré par IA en système vérifiable : contexte limité, plans explicites, petites modifications, garde-fous de sécurité et preuves avant le merge.
La nuance est essentielle. Le terme « vibe coding », popularisé par Andrej Karpathy en février 2025, reste utile comme avertissement. Il décrit une manière de construire où l’on peut presque oublier le code. C’est acceptable pour une expérience. Ce n’est pas un modèle de production pour un logiciel qui touche des clients, de l’argent, la sécurité ou des données réelles.
L’épisode de David Ondrej du 17 mai 2026, Stop Vibe Coding, Start Agentic Engineering – Micky, clarifie le sujet. L’invité décrit un workflow où l’IA écrit une grande partie du code, mais où l’humain conçoit le harnais : contexte source de vérité, petites PR, boucles de revue, règles de packages et handoff. La leçon importante n’est pas le chiffre de 95% de code généré par IA. La leçon importante est la discipline autour de l’agent.
Pourquoi le slogan ne suffit pas
Le vibe coding optimise la première démo qui fonctionne. L’Ingénierie Agentique optimise le deuxième mois de maintenance.
Un prompt peut créer un écran de login, un dashboard ou un flux CRUD. La difficulté commence lorsque le code doit supporter les changements de schéma, les entrées étranges, les permissions, le déploiement, les tests, les feature flags, le rollback et le travail d’un autre développeur.
L’ancien débat comparait la vitesse de frappe humaine à la vitesse de génération du modèle. Ce débat est terminé. Les modèles génèrent plus vite. La vraie question est de savoir si l’équipe peut canaliser cette vitesse dans un système qui rend les mauvaises modifications visibles avant qu’elles coûtent cher.
L’Ingénierie Agentique garde l’humain dans le rôle crucial : intention, périmètre, architecture, politique et critères d’acceptation. L’agent devient un exécutant rapide, pas le propriétaire du problème. C’est la logique de 5 Skills Claude pour développer avec méthode : le prompt n’est pas le produit, la boucle répétable l’est.
Définition simple : l’Ingénierie Agentique est une livraison logicielle où les agents IA réalisent une part importante de l’implémentation dans des contraintes, preuves et revues conçues par des humains.
Le modèle d’exploitation de l’Ingénierie Agentique
Le modèle repose sur six éléments.
D’abord, la tâche est découpée avant l’écriture du code. Un bon brief ne dit pas « construis la fonctionnalité ». Il précise le changement, les fichiers, les interfaces, les hypothèses de données et ce qui est hors périmètre. Si la tâche ne rentre pas dans une petite PR, elle est trop grande pour un seul passage agentique.
Ensuite, la base de code reste la source de vérité. La documentation aide, mais le vrai contrat est le code qui compile, les tests qui passent, les routes qui existent et les schémas utilisés en production. L’épisode d’Ondrej insiste sur le fait de fournir à l’agent le vrai code des packages et repositories. C’est le bon réflexe : un agent progresse lorsqu’il lit le système réel au lieu de deviner depuis des docs obsolètes.
Troisièmement, le harnais décide des outils autorisés. Sans outils, un modèle prédit du texte. Dans un harnais, un agent de code peut lire des fichiers, chercher des symboles, lancer des tests, ouvrir un navigateur, appeler des API et produire des diffs. Cette puissance exige des limites.
Quatrièmement, le plan devient un objet de responsabilité. Il permet de vérifier si l’agent a compris la taille du changement. Si le plan annonce une PR de 9 000 lignes, le plan a échoué. Il faut diviser avant d’implémenter.
Cinquièmement, la revue est une boucle. Tests, checks statiques, second agent et revue humaine doivent se renforcer. Notre article sur Reviewmaxxing pour les PR d’agents détaille ce point : le volume de tokens n’est pas l’avantage, la qualité de revue l’est.
Sixièmement, le handoff est conçu. Quand un agent ou une session s’arrête, l’opérateur suivant a besoin d’un état court : fichiers modifiés, erreurs connues, commandes exécutées et décisions ouvertes. C’est pourquoi les runtimes d’agents commencent à ressembler à des systèmes d’exploitation, comme dans Hermes v0.14 : des runtimes d’agents aux OS.
Les budgets de contexte battent les prompts géants
Le context engineering est la compétence discrète derrière l’Ingénierie Agentique.
Une grande fenêtre de contexte ne signifie pas que chaque tâche doit la remplir. Plus le prompt grossit, plus l’agent doit distinguer signal et bruit. La bonne pratique consiste à fournir le code exact, le contrat, l’erreur et le test d’acceptation nécessaires à la prochaine étape.
Les équipes de production doivent être plus strictes que les démonstrations. Un bon lot de travail reste petit : une tranche de fonctionnalité, une couche de service, une interface, une migration, un test en échec, une cible de revue. Les grandes tâches deviennent une séquence de petits runs avec handoff propre.
Le billet d’OpenAI du 8 mai 2026 sur running Codex safely montre le même principe côté sécurité. Sandboxes, approbations, réseau géré, identité, règles et télémétrie existent parce qu’un agent de code agit dans un environnement de développement.
La mise à jour Codex du 14 mai 2026 ajoute un autre signal. OpenAI décrit l’état live, les approbations, les diffs, le terminal, les résultats de tests, Remote SSH, les hooks, les access tokens limités et le relais sécurisé dans Work with Codex from anywhere. Ce ne sont pas des fonctions de vibe. Ce sont des fonctions de plan de contrôle.
L’Ingénierie Agentique commence quand les équipes traitent contexte, outils et approbations comme de l’architecture.
Les boucles de revue créent le vrai gain
Le gain de productivité n’est pas « l’IA écrit 95% du code ». Le gain est que l’équipe peut revoir plus de changements utiles chaque semaine avec moins de risque.
Un mauvais workflow agentique augmente la charge de revue. Il remplit une branche de code plausible, cache les erreurs dans un gros diff et oblige les humains à reconstruire l’intention. Un bon workflow réduit cette charge en rendant intention et preuves visibles dès le départ.
Chaque tâche agentique devrait produire quatre artefacts : le plan, le diff, les preuves de validation et les risques restants. S’il en manque un, la tâche n’est pas terminée.
La preuve peut être un test, un typecheck, du lint, un check de route, une capture navigateur, un résultat de scan de sécurité ou une note d’acceptation manuelle. La forme varie. La règle ne varie pas : pas de preuve, pas de merge.
C’est pourquoi les workflows déterministes comptent. Dans Archon Workflow Marketplace : le codage IA déterministe à grande échelle, l’idée utile n’est pas un autre prompt. C’est la forme : planifier, implémenter, valider, revoir, approuver, puis créer la PR.
Les règles de sécurité doivent vivre dans le workflow
L’épisode d’Ondrej donne une règle concrète : ne pas laisser les agents installer des packages de moins de 14 jours. Ce n’est pas une loi universelle, mais c’est un bon motif de politique.
L’idée de fond est juste. Les agents IA prennent vite une dépendance qui semble résoudre le problème. Cela crée un risque supply chain lorsque le package est nouveau, obscur, typo-squatté ou peu maintenu. Un humain peut hésiter. Un agent optimisera l’achèvement si le harnais ne l’arrête pas.
L’Ingénierie Agentique transforme cette hésitation en politique. Âge de package, allowlists, domaines interdits, modes read-only, secret scanning, dependency review et approval gates doivent vivre dans le workflow, pas dans la mémoire de quelqu’un.
C’est la même leçon que Harnais de sécurité, pas instinct : Vercel deepsec. La sécurité marche lorsqu’elle est répétable : scanner, investiguer, revalider, enrichir avec le contexte d’ownership et exporter un chemin de correction.
Une politique de départ suffit : pas de nouveau package sans note d’approbation, revue humaine pour les packages jeunes, approbation pour les commandes touchant secrets, auth, billing, données de production ou déploiement, réseau allowlisté si possible, writes externes journalisés et réversibles, rapport final avec fichiers, checks et risques.
Une checklist pratique pour les équipes
Les équipes n’ont pas besoin d’une plateforme géante pour commencer. Elles ont besoin d’une petite boucle répétable.
Commencez par le brief : résultat utilisateur, surfaces touchées, contraintes, non-objectifs et tests d’acceptation. Cinq minutes de brief évitent souvent une heure de nettoyage.
Définissez ensuite le pack de contexte : fichiers pertinents, contrats source, références API, formes de données et sortie en échec. Excluez les conversations anciennes et les docs sans rapport. L’objectif n’est pas le contexte maximal, mais le contexte suffisant.
Demandez un plan avant le code. Cherchez le scope creep, les migrations cachées, les refactors trop larges et les tests manquants. Si le plan est trop grand, découpez-le.
Après implémentation, exigez des preuves. L’agent lance les checks utiles les plus petits et rapporte le résultat. Si un check ne peut pas tourner, il explique pourquoi et donne une preuve de remplacement.
Puis faites la revue en boucle : second agent, outils statiques et humain. Demandez les risques, pas les compliments. Une bonne revue dit ce qui peut casser.
Enfin, capturez le handoff : objectif, fichiers modifiés, décisions, commandes, checks passés, checks ignorés et risques ouverts. Sans handoff, l’équipe perd l’effet composé du travail agentique.
FAQ
Qu’est-ce que l’Ingénierie Agentique ?
L’Ingénierie Agentique est une livraison logicielle où les agents IA implémentent des parties significatives du travail dans des contraintes, boucles de revue et preuves conçues par des humains. Elle combine discipline de contexte, planification, permissions d’outils, validation et handoff.
Le but n’est pas de supprimer les ingénieurs. Le but est de leur permettre de diriger plus d’implémentation en sécurité.
Quelle différence avec le vibe coding ?
Le vibe coding optimise la sortie rapide depuis des prompts. L’Ingénierie Agentique optimise la livraison fiable : petits périmètres, contexte issu du code, preuves de test, politique de sécurité, revue et handoff maintenable.
Le même modèle peut faire les deux. La différence est le système autour du modèle.
Les agents doivent-ils écrire la majorité du code ?
Ils peuvent écrire une grande part du code si le périmètre, les tests, la revue et le rollback sont solides. Le pourcentage compte moins que la boucle de contrôle.
Un petit changement agentique prouvé est plus sûr qu’un grand changement non revu.
Quel premier workflow adopter ?
Commencez par une boucle bornée : brief, pack de contexte, plan, implémentation, validation, second review, approbation humaine et handoff. Utilisez-la sur des fonctionnalités internes à faible risque.
Mesurez taille de PR, findings de revue, taux de tests passés et rollbacks avant d’étendre.
Quels contrôles de sécurité inclure ?
Au minimum : approbation des packages, secret scanning, limites réseau, chemins protégés, approbation des commandes, audit logs et rapport final des fichiers modifiés. Ajoutez des règles plus strictes pour auth, billing, données de production et publications externes.
Le but est d’inscrire la prudence dans le workflow.
Conclusion : garder la vitesse, ajouter le système
L’Ingénierie Agentique ne rejette pas le vibe coding parce qu’il serait inutile. Elle rejette l’idée qu’un workflow de démonstration puisse devenir un workflow de production sans changement.
Les meilleures équipes gardent la vitesse et ajoutent le système : périmètre clair, petits packs de contexte, plans ancrés dans le code, règles de sécurité, boucles de revue, preuves de validation et handoff propre. C’est ainsi que le code assisté par IA devient une capacité d’ingénierie.
Si votre équipe passe des démos IA à une livraison fiable, Context Studios peut aider à concevoir cette boucle : agents, politiques, gates de revue et workflows de production qui livrent plus vite sans nier le risque.