Agentic Engineering : construire du code IA fiable en production

Après avoir inventé le terme « vibe coding » en février 2025, Andrej Karpathy introduit officiellement « agentic engineering » un an plus tard. La différence ? Le vibe coding accepte aveuglément tout ce que génère une IA. L’agentic engineering confie aux agents IA autonomes la tâche d’écrire, tester et affiner le code — mais sous une orchestration et une révision humaines rigoureuses. Ce guide traduit cette nouvelle discipline en workflows opérationnels concrets.

• L’agentic engineering requiert une orchestration humaine rigoureuse et continue, contrairement au vibe coding
• Trois prérequis non-négociables : tests robustes, spécification écrite, CI/CD opérationnel
• Quatre phases clés : discovery, planification, orchestration, exécution et validation
• Les tests deviennent des validation gates que l’agent doit franchir pour réussir
• Circuit breaker sur les coûts et monitoring continu pour éviter les hallucinations LLM

Vibe Coding vs. Agentic Engineering : la distinction critique

Depuis fin 2024, deux termes circulent dans les équipes tech. Ils sonnent proches. Ils désignent des univers opposés.

Qu'est-ce que le vibe coding ?

Le vibe coding repose sur un postulat simple : un humain prompt une IA, reçoit du code, l’accepte sans révision substantielle et le déploie. C’est rapide. C’est commode. C’est dangereux en production.

Addy Osmani, ingénieur chez Google Cloud, le dit crûment : « Vibe coding means going with the vibes and not reviewing the code. That’s the defining characteristic. »

Le vibe coding a ses cas d’usage légitimes — scripts personnels, prototypes MVP, apprentissage. Il s’arrête là.

Qu'est-ce que l'agentic engineering ?

L’agentic engineering, c’est l’inverse. Les agents IA ne reçoivent pas d’ordre du type « génère-moi une feature ». Ils reçoivent un cahier des charges précis, une architecture cible, des tests à passer. Ils écrivent du code, le testent, itèrent jusqu’à ce que les tests passent. Un humain — architecte, reviewer, décideur — reste maître du navire à chaque étape critique.

Osmani résume : « Agentic engineering isn’t easier than traditional engineering — it’s a different kind of hard. You’re trading typing time for review time. »

Comparaison directe

**Critère**	**Vibe Coding**	**Agentic Engineering**
**Autorité**	Acceptation humaine ponctuelle	Orchestration humaine continue
**Révision**	Optionnelle, souvent nulle	Obligatoire, structurée
**Processus**	Prompt → Code → Deploy	Spec → Plan → Discovery → Orchestration → Validation
**Risque production**	Élevé	Contrôlé
**Compétence requise**	Minimal	Ingénierie solide

Le piège courant

Certaines équipes pensent pratiquer l’agentic engineering en écrivant un prompt ambitieux et en croisant les doigts. C’est du vibe coding peint en noir.

Prérequis : fondations avant d'engager les agents

Avant de confier la moindre tâche critique à un agent IA, trois éléments non-négociables doivent déjà être en place.

1. Des tests robustes

Osmani appelle ça « le pivot » : transformer un agent non fiable en système fiable. Sans suite de tests solide, vous ne saurez jamais si l’agent a réellement réussi ou s’il hallucine.

Les tests servent de validation gate. L’agent itère jusqu’à ce qu’ils passent, point final. Visez 60–70 % de couverture minimum.

2. Une spécification écrite

Pas un message Slack. Pas une note Figma. Un document : architecture, interfaces, contraintes, conditions de succès.

L’agent doit savoir exactement ce qu’il cherche à accomplir. Si vous improvisez, il improvise aussi — et ses improvisations sont imprévisibles.

3. Un CI/CD opérationnel

Si votre pipeline de déploiement est manuel, branlant ou documenté sur Post-it, les agents vont pourrir le système. Ils accélèrent le processus existant, ils ne le créent pas.

Checklist d'infrastructure préalable

• ✓ Suite de tests étendue (>60 % couverture)
• ✓ Design docs à jour, lus par l’équipe
• ✓ CI/CD automatisé, fiable, testé en échec
• ✓ Logging centralisé (ELK, Datadog, etc.)
• ✓ Git branching strategy solide
• ✓ Monitoring production
• ✓ Runbooks pour incidents critiques

Si vous cochez moins de 5 cases, le problème n’est pas l’agent — c’est votre infrastructure.

Mise en garde : développeurs junior et agents

Enrôler des développeurs junior dans un processus agentic alors qu’ils ne maîtrisent pas les fondamentaux pose un risque majeur. Osmani relève : « AI didn’t cause the problem; skipping the design thinking did. »

Obligation absolue : chaque diff généré par un agent doit être révisé, compris et validé par un développeur senior.

Phase 1 : discovery — cartographier le système

Avant que l’agent n’exécute quoi que ce soit, il faut qu’il comprenne le terrain.

La discovery phase est une exploration méthodique de l’architecture cible. L’agent inspecte le dépôt Git (structure, dépendances, patterns), questionne le système en live (configuration, services, stockage, réseau), génère une baseline quantifiée, puis centralise tout dans un document opérationnel.

Cas pratique : migration multi-conteneurs

Patrick McCanna, ingénieur ops, a documenté une migration de services d’un Raspberry Pi 3 vers un serveur AMD Ryzen. La discovery a révélé :

• 6 conteneurs Docker en production
• 7 volumes montés (données, configs, logs)
• Configuration Cloudflare Tunnels (pas d’IP publique)
• Playbooks Ansible existants (incomplets)
• Contraintes disque : `/home` à 75 %
• Services réservés sur la cible : Ollama, Open WebUI, n8n

Sans cette discovery, l’agent aurait échoué à la première étape.

Étapes concrètes de discovery

1. Exploration repo. L’agent scrape le dépôt Git. Il cartographie : arborescence, dépendances, patterns d’infra.

2. Inspection live. L’agent fait de la reconnaissance en direct :
docker ps -a # conteneurs
docker volume ls # volumes
df -h # espace disque
curl http://localhost:8080/health # services vivants

3. Baseline counts. Avant toute mutation, photographier l’état initial :
– Posts créés : 1024
– Brouillons : 47
– Images uploadées : 3200
– Cartes générées : 892

4. Centralisation. Tout rentre dans un seul document.

L’output de cette phase n’est pas élégant. C’est un document brut, presque ennuyeux. Exactement ce qu’il faut.

Phase 2 : planification — construire le playbook

Maintenant, l’agent prend ces découvertes et construit un plan d’exécution en phases.

McCanna a codécidé avec son agent une 10-phase migration.

Phases read-only :
1. Valider les scripts de backup officiels
2. Exécuter un backup complet
3. Générer des baseline counts

Phases de setup :
4. Provision la cible
5. Restore le backup en staging
6. Tester fonctionnellement

Phase critique :
7. Freeze écriture en production
8. Backup final + cutover DNS
9. Valider post-cutover

Phase de nettoyage :
10. Cleanup ancien système après 48h observation

Enrichissements humains

À chaque phase, trois ajouts humains que l’agent aurait omis :

• Health check loops, pas `sleep(30)` bête
• Barres de progression, pas `scp` muet
• Go/No-Go checkpoints — validation humaine avant saut critique
• Rollback procedures — si phase 8 échoue, retour immédiat
• Staging DNS — tester en staging avant prod

Cette planification itérative — l’agent propose, l’humain affine — est le cœur de l’agentic engineering.

Phase 3 : orchestration — piloter les agents

Une fois le plan approuvé, l’agent l’exécute. Mais pas librement. Il reçoit des prompts structurés :

Objectif : Exécuter phase 4 (provision target).

Constraints :
– Ne pas toucher Ollama, WebUI, n8n
– Allocate au moins 25 GB de RAM
– Utiliser /opt/ pour 650 GB de données

Success condition : docker ps affiche 6 conteneurs, tous running

Fallback : si un conteneur crash, rollback phase, log erreur, signal humain.

Cet ordre est explicite, borné, validable.

Tests comme validation gates

Les test suites deviennent des validation gates. L’agent n’a pas terminé la phase 5 tant que les tests fonctionnels ne passent pas :

assert post_count == 1024
assert draft_count == 47
assert image_count == 3200
assert curl(http://staging:8080/health).status == 200

Tant que les tests échouent, l’agent itère.

Parallélisation d'agents

Shannon, un agent de pentesting autonome créé par Keygraph HQ, montre comment orchestrer plusieurs agents en parallèle :

Phases séquentielles :
1. Recon — cartographier la cible

Phases parallèles :
2. Vuln Analysis — 3 agents analysent en parallèle
3. Exploitation — chaque agent teste sa classe de faille

Phase finale :
4. Reporting — centraliser les preuves

Cette orchestration réduit le temps de 4–6 heures à 1–1,5 heure.

Circuit breaker

Si un agent consomme >$100 en tokens, borne l’exécution automatiquement. Si un conteneur entre en CrashLoop, kill le workflow.

Phase 4 : exécution & validation — déployer en confiance

L’agent exécute. Vous validez après.

Baseline counts comparison

L’agent génère un rapport :

BEFORE AFTER DELTA
posts: 1024 posts: 1024 ✓
drafts: 47 drafts: 47 ✓
images: 3200 images: 3199 ✗ -1 (investigate)
cards: 892 cards: 892 ✓

Vous voyez aussitôt : 1 image manquante. Enquête rapide, puis action.

Tests fonctionnels

Créer un post, uploader une image, générer une carte. Vérifier que tout marche.

Vérifications d'intégrité

Checksum avant/après ; vérifier que la base de données n’est pas corrompue.

Monitoring post-déploiement

Activer les sondes de readiness, observer les logs 30 min. Pas d’erreur 5xx ? Pas de latence dégradée ? Bon.

Documentation finale

L’agent génère un rapport final : timeline d’exécution, diffs appliqués, logs importants, checklist post-migration validée. Conservez-le pour la prochaine migration.

Pièges courants et solutions

Piège 1 : accepter le rapport sans preuve

Shannon a résolu ça avec une règle simple : « No exploit, no report. » Chaque vulnérabilité déclarée doit être prouvée par une exploitation réelle.

Dans votre contexte : Pas de changement déclaré sans vérification par baseline counts et tests fonctionnels.

Piège 2 : hallucinations LLM

L’agent affirme « 6 conteneurs migrés ». Vérifiez : `docker ps` en dit quoi ? Si le chiffre ne match pas, enquête immédiate.

Piège 3 : scope creep

L’agent était censé migrer 6 conteneurs. Il en crée 7 « pour optimiser ». Interdire. L’agent suit le spec, point final.

Piège 4 : coûts token imprévisibles

Shannon coûte ~$50 USD par run. Budgetez large. Fixez un circuit breaker en coûts : limite avant chaque workflow.

Piège 5 : production sans staging

Cutover directement en prod sans tester en staging est suicidaire. McCanna a utilisé une DNS temporaire pour tester l’exécution complète en staging avant prod.

Copiez ce pattern.

Atrophie de compétences junior

Un développeur junior qui passe un prompt et merge sans comprendre ne développe aucune intuition. Osmani l’a observé : « Disproportionately risky pour junior (can prompt but can’t debug). »

Solution obligatoire : Pour chaque diff généré par agent, revue + compréhension + explication écrite avant merge.

❌ Agent génère 300 lignes. Junior merge.

✓ Agent génère 300 lignes.
Junior : lit, comprend, explique par écrit.
Senior : valide compréhension et qualité.
Merge.

Outils et ressources

Pour autonomous security testing

Shannon — GitHub `KeygraphHQ/shannon`. Open-source, utilise Claude Sonnet 4.5. Déploiement benchmarké (96,15 % success XBOW).

Pour orchestration workflows

LangGraph — Framework Anthropic pour workflows multi-agents. Gratuit, open-source.

Temporal.io — Moteur de workflow durable. Gère retries, timeouts, patterns saga.

Pour agent development

Anthropic Agent SDK — Recommandé pour le raisonnement structuré.

Références pratiques

• Addy Osmani : « Beyond Vibe Coding » — distillation des bonnes pratiques
• Simon Willison : « LLM for Code » — patterns pour génération fiable
• Patrick McCanna : « Using Custom AI Agents to Migrate Services » — cas d’usage reproductible

Conclusion

L’agentic engineering n’est pas une alternative au développement traditionnel. C’est une discipline qu’on superpose à une infrastructure déjà rigoureuse. Si votre équipe n’a pas tests robustes, pas specs écrites, pas CI/CD fiable, les agents vont accélérer le chaos, pas la productivité.

Mais si vous avez ces fondations, les agents deviennent des force multipliers. Ils exécutent des plans. Ils itèrent rapidement. Ils s’arrêtent aux checkpoints que vous définissez. Les humains gardent l’autorité.

Le vrai challenge n’est pas technique. C’est organisationnel : valider chaque diff, maintenir la compréhension, refuser la tentation de faire confiance aveuglément. C’est du travail. Mais c’est du vrai travail d’ingénierie.

FAQ

Quelle est la différence entre vibe coding et agentic engineering ?

Le vibe coding accepte aveuglément tout ce que génère une IA sans révision substantielle. L’agentic engineering confie aux agents IA autonomes la tâche d’écrire, tester et affiner le code — mais sous une orchestration et une révision humaines rigoureuses. L’agentic engineering n’est pas plus facile ; c’est un échange entre le temps de rédaction et le temps de révision.

Quels sont les prérequis avant de déployer des agents IA en production ?

Trois éléments non-négociables : une suite de tests robuste (visant 60–70 % de couverture minimum), une spécification écrite détaillée (architecture, interfaces, contraintes), et un CI/CD opérationnel et fiable. Si vous cochez moins de 5 cases dans la checklist d’infrastructure, le problème n’est pas l’agent — c’est votre infrastructure.

Quelles sont les 4 phases clés de l'agentic engineering ?

Phase 1 : Discovery — cartographie méthodique du système cible et des contraintes. Phase 2 : Planification — construction d’un plan d’exécution en phases avec enrichissements humains. Phase 3 : Orchestration — pilotage des agents avec prompts structurés et tests comme validation gates. Phase 4 : Exécution & Validation — vérification de baseline counts, tests fonctionnels et monitoring post-déploiement.

Comment éviter les hallucinations LLM lors d'une migration d'agents ?

Générez des baseline counts avant toute mutation (posts, images, données). L’agent affirme « 6 conteneurs migrés » ? Vérifiez avec `docker ps`. Utilisez des tests fonctionnels comme validation gates que l’agent doit franchir. Comparez baseline counts avant/après. Si le chiffre ne match pas, enquête immédiate. Maintenez un circuit breaker sur les coûts tokens pour limiter les hallucinations longues.

Quels outils utiliser pour orchestrer des workflows multi-agents autonomes ?

LangGraph — Framework Anthropic pour workflows multi-agents, gratuit et open-source. Temporal.io — Moteur de workflow durable gérant retries, timeouts et patterns saga. Anthropic Agent SDK — Recommandé pour le raisonnement structuré. Shannon (GitHub `KeygraphHQ/shannon`) — Agent de pentesting autonome déjà déployé en production avec benchmarks publiés.