Tu as construit un agent. Tu l'as testé sur ton laptop. Ça marchait — magnifiquement, même. Alors tu l'as mis en prod comme on déployait des sites web en 2003 : modifier le fichier sur le serveur, sauvegarder, prier.

Puis à 2h du matin, ton agent se met à halluciner des appels d'outils, à envoyer des emails à des gens qui n'ont rien demandé, et à cramer ton budget API comme un marin en permission. Tu cherches le bouton rollback. Il n'y a pas de bouton rollback. Il n'y a pas de version précédente. Ton agent n'a pas de versions — c'est un system prompt dans un champ texte, une poignée de configs d'outils, et ce qui reste dans ta tête.

Bienvenue dans le déploiement d'agents en avril 2026.

Les plateformes sont sorties. Les pipelines, non.

Entre le 8 et le 22 avril, les trois hyperscalers ont sorti leurs plateformes d'agents en rafale : les Managed Agents d'Anthropic (8 avril) avec des sandboxes hébergées et un CLI ant, le SDK Agents v0.14 d'OpenAI (15 avril) avec six point releases en dix jours, et l'ADK 1.0 de Google présenté au Cloud Next (22 avril) avec des SDKs multi-langages et un dashboard de monitoring. On a déjà couvert les comparaisons de fonctionnalités ici. Ce qu'aucun d'entre eux n'a livré : la discipline de déploiement.

Comme l'a résumé la comparaison de xpander.ai le 24 avril : « Ce qu'ils ne proposent pas : la portabilité multi-cloud, le CI/CD natif pour agents, le versioning, le rollback, ni les déploiements canary. » Chaque hyperscaler a reçu la note "DIY" pour le cycle de vie des agents.

Soyons justes, Anthropic s'en est le mieux sorti — le CLI ant promet une promotion staging-vers-production. Mais leur propre article de blog engineering ne contient zéro mention de rollback, de déploiement canary, ou de blue-green switching. Le versioning existe ; la discipline de déploiement, non.

Pourquoi les agents ont cassé le CI/CD

CI/CD — intégration continue et déploiement continu — c'est comme ça que le logiciel normal est livré. Tu as un artefact déployable (une image Docker, un binaire compilé), tu le testes en staging (une copie sécurisée de la prod), tu fais un canary (5% du trafic vers la nouvelle version), et si ça casse, tu rollback en une commande.

Les agents n'ont pas d'artefact unique. Le comportement d'un agent vit sur au moins quatre surfaces :

# Surface 1 : Code (versionné dans git)
agent = Agent(model="claude-sonnet-4", tools=[search, email, calendar])

# Surface 2 : System prompt (souvent édité dans un dashboard, pas dans git)
SYSTEM_PROMPT = "Tu es un assistant de planification qui..."

# Surface 3 : Configs d'outils (permissions, rate limits, clés API)
# Surface 4 : Mémoire / contexte appris (vit... quelque part)

Le system prompt et les descriptions d'outils sont les composants les plus critiques pour le comportement, mais ils vivent en dehors du contrôle de version par défaut. Simon Willison l'a démontré le 18 avril en construisant manuellement un historique Git avec de fausses dates de commit juste pour tracer les changements de prompt — du reverse-engineering de versioning qui devrait être une fonctionnalité native de la plateforme.

Comme Anthropic eux-mêmes l'ont reconnu : « Déployer un agent de qualité production exige des équipes qu'elles construisent non seulement l'agent lui-même, mais aussi une quantité significative d'échafaudage. »

L'ère du ruban adhésif

Des solutions de fortune existent. Tu peux versionner tes fichiers de prompt dans git. Tu peux faire du blue-green swap manuellement. Tu peux feature-flagger ta liste d'outils. Voici le minimum viable de "versioning d'agent" :

# Artefact d'agent du pauvre
agent_config = {
    "version": "1.4.2",
    "prompt_sha": "a3f8c1d",  # hash git du fichier prompt
    "tools": ["search_v2", "email_v1"],
    "permissions": {"email": {"max_per_hour": 10}},
    "model": "claude-sonnet-4",
}
# Déployer : charger config → valider → basculer le trafic
# Rollback : charger config précédente → rebasculer

Mais c'est du ruban adhésif qui exige une discipline qu'aucune plateforme n'impose. Et ça s'effondre dès que la mémoire de l'agent — le contexte accumulé au fil des sessions — entre en jeu. Tu ne peux pas rollback ce dont un agent se souvient.

Jusqu'où ça peut dégénérer ? Un post-mortem de Reworkd de mars 2026 a documenté un seul mauvais déploiement de prompt qui a déclenché 14 000 appels API erronés en 47 minutes — 2 300 $ de tokens cramés avant que quiconque ne s'en aperçoive. Pas de canary. Pas de rollback. Juste une alerte Slack arrivée trop tard. Multiplie ça par les milliers d'équipes qui construisent des agents sans garde-fous de déploiement, et tu commences à voir l'ampleur du problème.

Ce que tu devrais faire maintenant

Si tu construis des agents aujourd'hui : traite chaque prompt, config d'outil et politique de permissions comme de l'infrastructure-as-code. Mets tout sous contrôle de version. Ne mets jamais à jour un agent en production sans tester une copie staging d'abord. Prévois du temps pour construire la plomberie de déploiement que ton fournisseur de plateforme a zappée. Ce n'est pas optionnel — c'est la différence entre une démo et un produit.

La couche qui manque

Rappelle-toi, tu as commencé ce parcours en éditant un fichier sur un serveur. C'est exactement là où en sont les agents aujourd'hui — l'ère pré-Docker du "ça marche sur ma machine". La plateforme qui livrera le CI/CD d'agents comme primitive par défaut — staging, canary, rollback, avec l'agent comme artefact versionnable — capturera la couche opérationnelle qui se situe au-dessus de la qualité du modèle et du nombre d'outils. C'est le vrai graal, et au 26 avril 2026, personne ne l'a encore décroché.