Agents IA en production : isolation, sécurité et conformité (2026)

Seulement 5 % des entreprises ont déployé des agents IA en production. Ce n’est pas un problème de capacité des modèles, mais d’infrastructure. L’injection de prompts, l’exfiltration de données, l’escalade de privilèges : ces risques ne sont pas théoriques. Deux ans après le boom de l’IA générative, l’isolation du code, la gouvernance et la conformité restent les goulots d’étranglement critiques. Ce guide consolide la pile technique qui émerge en 2026 — technologies de sandboxing, plateformes, frameworks de conformité, patterns opérationnels — pour transformer ces 5 % en stratégie reproductible.

Pourquoi seulement 5 % des entreprises déploient des agents en production

Le paradoxe est flagrant. Les modèles de langage génèrent du code avec une précision impressionnante. Les frameworks orchestrent des workflows complexes. Pourtant, 95 % des projets d’agents restent bloqués en phase pilote, et 47 à 53 % de ceux déployés fonctionnent sans supervision active.

La raison n’est pas technique au sens classique. C’est un trilemme : sécurité vs performance vs simplicité opérationnelle. Choisissez deux. Vous sacrifierez le troisième.

La sécurité d'abord

Un agent IA peut générer et exécuter du code arbitraire. Pas du code prévisible. Du code que vous ne pouvez pas anticiper au moment du déploiement. Donner à un processus non supervisé la permission d’accéder à une base de données de production, à un système de fichiers, ou au réseau revient à confier un terminal root à un apprenti.

Les conteneurs classiques offrent une isolation au niveau du processus — insuffisant si l’agent s’échappe via une vulnérabilité du noyau. Les microVMs Firecracker isolent au niveau du matériel avec un démarrage en 150 ms, mais ajoutent 20 à 30 % de latence. gVisor offre un compromis à 100–150 ms avec 10 à 20 % d’overhead — acceptable, mais pas gratuit.

La performance ensuite

Les clients attendent des réponses en secondes, pas en minutes. Un agent qui met 5 secondes à démarrer son bac à sable, 10 secondes à initialiser son environnement d’exécution, et 2 secondes pour chaque appel d’outil finit par sembler lent même s’il résout le problème correctement.

À cette latence s’ajoute le coût : une microVM par requête, c’est une instance CPU dédiée multiplié par le trafic concurrent. Les conteneurs sont plus rapides et moins chers. Mais ils vous ramènent au problème de sécurité.

La simplicité enfin

Déployer un agent sécurisé implique des décisions architecturales imbriquées : choix de la technologie d’isolation, configuration du réseau (deny-by-default pour les sorties ?), audit des outils autorisés, vérification des modèles d’accès, définition des escalades, validation de la conformité (GDPR, HIPAA, EU AI Act, SOC2).

Chaque couche ajoutée requiert expertise. Les équipes startup manquent de bandwidth. Les grandes organisations se noient dans les cycles d’approbation.

Résultat : les entreprises restent en pilot. Elles font fonctionner des agents sur des données synthétiques, dans des environnements contrôlés, sans accès réseau, et cherchent un moyen d’évoluer sans prise de risque. Cette fragmentation du marché de l’infrastructure — avec une dizaine de plateformes de sandboxing concurrentes, chacune avec sa propre API, ses propres limites, ses propres tarifs — a ralenti l’adoption. Jusqu’à maintenant.

Landscape des menaces : injection de prompts, supply chain, exfiltration

La sécurité des agents n’est pas une menace abstraite. L’OWASP a publié son Top 10 pour applications agentic en janvier 2026. Deux CVE récentes illustrent la réalité de production.

Injection de prompts : le risque principal

L’injection de prompts ne ressemble pas aux injections SQL classiques. Avec SQL, les syntaxes d’attaque et légitime sont distinguables. Vous pouvez filtrer, échapper, valider.

Avec les prompts, l’attaque est du langage naturel. L’agent ne peut pas mathématiquement différencier une instruction d’un utilisateur autorisé d’une instruction cachée dans un document qu’on lui demande de traiter.

Cas réel : GitHub Copilot (CVE-2025-53773). Une page web publique contenait du texte blanc sur fond blanc : des instructions d’attaque que l’utilisateur ne voyait pas. Copilot, scrappant la page pour du contexte, lisait le texte invisible, l’exécutait, et renvoyait des réponses compromises.

Cas réel : Vanna.AI (CVE-2024-5565). Un agent SQL générait du code Python exécuté directement contre une base de données. Un utilisateur injectait un prompt malveillant dans sa requête. Vanna.AI le traitait comme une instruction légitime, générait du Python contenant du code d’exfiltration, et l’exécutait. Pas de bac à sable. Pas de validation. Données perdues.

L’OWASP cite un taux de succès de 84 % pour les injections de prompts via la framework Hackode. Dans 84 % des cas testés, l’injection contournait ou modifiait le comportement attendu de l’agent.

Fuite de données : supply chain et exfiltration réseau

Les agents IA utilisent des outils — appels d’API, requêtes de base de données, accès au système de fichiers. Chaque outil est un vecteur potentiel de fuite.

Supply chain. Quel package npm, PyPI, ou crate le générateur de code du LLM utilise-t-il ? Les modèles hallucinent — ils inventent des références de packages qui n’existent pas. Selon IKANGAI, 19,7 % des références de packages mentionnées par les LLMs sont hallucinations. L’agent télécharge un package requests-secure-auth au lieu de requests ? C’est une vraie vulnérabilité de typosquatting, générée par le LLM lui-même.

Exfiltration réseau. Un agent non supervisé avec accès réseau peut lancer des requêtes sortantes n’importe où. DNS, HTTP, WebSocket — tous les canaux de sortie constituent des vecteurs d’exfiltration.

Trust entre agents

Dans les systèmes multi-agents, les agents parlent les uns aux autres. 82,4 % des LLMs vont exécuter un appel d’outil malveillant si demandé par un autre agent, même si ce même appel aurait été rejeté s’il provenait d’un utilisateur direct.

Implication directe : isoler chaque agent n’est pas suffisant si les agents se font confiance mutuellement. Vous devez établir des limites de confiance explicites entre agents, signer les appels d’outils, et conserver des traces d’audit immuables.

OWASP Top 10 Agentic : les dix risques majeurs

L’OWASP énumère dix risques majeurs pour les agents. Les quatre premiers — injection de prompts, fuite d’information sensible, mauvais usage d’outils, surcharge de ressources — sont directement atténués par le sandboxing. Les autres requièrent des contrôles applicatifs en plus.

Isolation technology 101 : Firecracker vs gVisor vs conteneurs vs WebAssembly

Pour comprendre comment choisir, il faut d’abord comprendre ce que chaque technologie offre.

Conteneurs Docker classiques

Un conteneur Docker n’isole que au niveau du processus. Il utilise les namespaces Linux pour créer l’illusion de machines séparées, mais partage le noyau hôte. Si un attaquant échappe à l’application via une CVE du noyau, il compromet tous les conteneurs sur cette machine.

Métrique	Performance
—	—
Cold start	~50 ms
Overhead	2–5 %
Isolation	Faible (kernel shared)
Écosystème	Extrêmement mature

gVisor (Google Sandbox)

gVisor est une couche d’application qui intercepte les appels système du conteneur et les exécute de manière sécurisée. Au lieu de transmettre directement l’appel au noyau hôte, gVisor implémente sa propre version Linux compatible mais isolée.

Métrique	Performance
—	—
Cold start	100–150 ms
Overhead	10–20 % CPU
Isolation	Moyen-élevée (résiste CVE noyau)
Écosystème	Google Cloud Run, Modal, Vercel Functions

Firecracker microVMs

Firecracker est un hyperviseur allégé créé par AWS pour les fonctions Lambda. Chaque exécution lance une microVM entière — son propre noyau Linux, son propre système de fichiers, son propre PID 1 — isolée au niveau du matériel via KVM.

Métrique	Performance
—	—
Cold start	~150 ms
Overhead	20–30 %
Isolation	Très élevée (hardware KVM)
Écosystème	E2B, AWS Lambda, AWS Fargate

Kata Containers

Kata combine les avantages de Firecracker et de gVisor. Elle utilise des hyperviseurs allégés pour isoler les conteneurs au niveau du matériel, tout en restant compatible avec Docker et Kubernetes.

Métrique	Performance
—	—
Cold start	~200 ms (dépend du pull d’image)
Overhead	15–25 %
Isolation	Très élevée (hardware KVM)
Écosystème	Kubernetes-native, CNCF

WebAssembly (Wasm)

WebAssembly n’isole pas au niveau du système d’exploitation. C’est une sandbox au niveau du langage — le code Wasm s’exécute dans une machine virtuelle qui contrôle la mémoire, l’accès aux outils, les appels système.

Métrique	Performance
—	—
Cold start	<10 ms
Overhead	Minimal
Isolation	Élevée (VM-level)
Écosystème	Wasmtime, Wasmer, Deno (émergent)

Tableau comparatif

Technologie	Cold Start	Overhead	Isolation	Agents untrusted
—	—	—	—	—
Conteneurs	~50 ms	2–5 %	Faible	Non
gVisor	100–150 ms	10–20 %	Moyen-élevé	Oui (SaaS)
Firecracker	~150 ms	20–30 %	Très élevée	Meilleur choix
Kata	~200 ms	15–25 %	Très élevée	Oui (K8s)
WebAssembly	<10 ms	Minimal	Élevée	À venir

Comparaison des plateformes : E2B, Modal, Daytona, Northflank

Le marché converge sur une liste courte de fournisseurs. Chacun a un positionnement différent.

E2B : Firecracker optimisé pour agents

Positionnement : Plateforme spécialisée pour exécuter du code d’agents IA. Démarrage ultra-rapide.

E2B utilise Firecracker microVMs avec cold start de 150 ms. Elle propose des SDK pour Python et JavaScript avec intégrations natives LangChain, OpenAI, Anthropic. Tarification : $0.05/vCPU-heure, usage-based, sessions jusqu’à 1 heure gratuitement, 24 heures en payant.

Forces : Démarrage ultra-rapide, intégrations par défaut avec frameworks agent populaires, tarification transparente.

Faiblesses : Limite de session 24 heures en payant, BYOC non mature.

Modal : gVisor + GPU, approche serverless

Positionnement : Plateforme serverless pour workloads ML et agents. GPU inclus. Scaling automatique.

Modal utilise gVisor avec cold start <100 ms. Elle est Python-first et permet de déployer directement depuis Jupyter. GPU H100 disponible à $3.95/hr. Scaling automatique géré en backend.

Forces : GPU intégré, scaling automatique transparent, intégration Jupyter rapide.

Faiblesses : Tarification additive (coûteux CPU+RAM+GPU), gVisor vs. Firecracker = overhead légèrement supérieur.

Northflank : Kata Containers + BYOC, multi-tenant

Positionnement : Plateforme d’exécution d’entreprise. Isolation Kata (hardware KVM). Support BYOC.

Northflank utilise Kata Containers pour isolation hardware-level. Elle autorise BYOC (Bring Your Own Container) pour contrôle image. Sessions illimitées. Tarification all-in ~$2.74/hr H100. Orientée entreprise avec SOC2, SLA.

Forces : BYOC, isolation Kata (hardware KVM), tarification all-in plus claire, audit trail SOC2.

Faiblesses : Cold start plus lent (dépend du pull d’image), moins d’automatisation que Modal.

Daytona : Kata + session persistante

Positionnement : Agents long-lived. Sessions stateful réutilisables.

Daytona combine Kata Containers avec sessions persistantes. Cold start ~90 ms malgré Kata. Sessions restent actives tant que besoin.

Forces : Idéal agents multi-étapes, cold start court malgré Kata.

Faiblesses : Moins mature, transparence pricing/SLA inférieure.

Matrice décisionnelle

Besoin	Menace	Latency	Priorité	Recommandation
—	—	—	—	—
Agents court-lived ultra-rapides	Élevée	<150ms	Performance	E2B
ML inference + agents	Moyenne	Flexible	GPU	Modal
Multi-tenant enterprise	Élevée	Acceptable	BYOC	Northflank
Agents stateful long-lived	Moyenne	Flexible	État	Daytona

MCP : standardisation et interopérabilité cross-platform

Jusqu’en 2024, chaque plateforme d’exécution avait son propre SDK, son propre modèle d’intégration d’outils. Vous codiez un agent pour Modal ? Vous redéployez entièrement pour E2B.

En janvier 2025, la Linux Foundation a lancé l’Agentic AI Foundation. Anthropic a donné à la Fondation le Model Context Protocol (MCP) — un standard ouvert pour les agents à déclarer et invoquer des outils, accéder aux données, gérer le contexte.

Qu'est-ce que MCP ?

MCP est un protocole transport-agnostique (JSON-RPC sur stdio, HTTP, WebSocket). Un agent dit : « Je dois lire des fichiers. Je dois appeler une API Stripe. Je dois interroger une base de données. » Le protocole standardise comment décrire ces besoins et comment exécuter les outils.

Avant MCP : Redéploiement complet, réécriture agent.

Après MCP : Même code. Changez le transport (E2B vs. Modal vs. Northflank). Pas de réécriture.

Avantages

Interopérabilité. Un agent écrit pour E2B peut migrer vers Modal en changeant une variable d’environnement.

Écosystème décentralisé. Tiers peuvent publier des serveurs MCP pour leurs services (Stripe, Salesforce, Slack). Les agents les découvrent sans SDK propriétaire.

Prévention du vendor lock-in. Vous ne dépendez pas d’une plateforme d’exécution unique. Vous négociez tarifs, SLA, isolation — sachant rester portable.

Adoption 2026

Anthropic Claude est MCP-native depuis janvier 2025. LangChain et LlamaIndex intègrent le support MCP. Modal et Northflank commencent à publier des serveurs MCP. Stripe, GitHub, Linear, Salesforce ont annoncé ou lancé serveurs MCP.

Impact stratégique : Le marché fragmenté converge autour d’un standard. Les PME peuvent enfin changer de fournisseur sans réécriture.

Gouvernance et conformité : OWASP, NIST, GDPR, EU AI Act

Un agent techniquement isolé n’est pas un agent conforme. La conformité émerge d’une pile réglementaire multidimensionnelle.

OWASP Top 10 Agentic Applications 2026

L’OWASP identifie les risques critiques. Pour les agents, elle recommande des contrôles : sandboxing, allowlist stricte des outils, masquage de PII en logs, audit trail immuable, rétention policy.

L’OWASP ne prescrit pas une solution. Elle propose une matrice risques × contrôles. Vous taillez les contrôles au profil de risque.

NIST AI Risk Management Framework 1.0

NIST structure la gouvernance IA en quatre piliers : Govern → Map → Measure → Manage.

Govern : Créer une charte d’agents approuvés, définir les rôles, publier les policies.
Map : Cataloguer chaque agent : inputs, outputs, outils, accès données, modèles.
Measure : Tester prompt injection, monitorer anomalies.
Manage : Escalader incidents, retirer agents dériving, corriger et redéployer.

NIST est prescriptif mais non obligatoire aux USA. Il devient le baseline de facto pour SOC2 Type II.

GDPR et données de l'UE

Déployez un agent en UE ou traitant des données d’UE-residents ? GDPR s’applique.

Les logs d’agent sont des données de traitement. Vous devez : accepter consentement, chiffrer les logs, appliquer rétention, offrir droit d’accès et oubli.

Implication : Les résidents UE peuvent demander une copie de toutes les données traitées ; ils peuvent demander suppression.

EU AI Act et classification high-risk

L’EU AI Act (2024, en vigueur 2025) classe les systèmes IA en fonction du risque. Les agents autonomes déterminant l’accès au crédit, l’emploi, les allocations sociales sont high-risk. Les amendes montent jusqu’à €35M ou 7 % du chiffre d’affaires global.

Pour les high-risk agents, l’UE impose :

Risk assessment documentation : Preuve que vous avez évalué les risques.
Testing & validation : Test des décisions ; red-teaming.
Human-in-the-loop oversight : Un humain approuve les décisions impactantes.
Incident notification : Signaler les incidents graves sous 72 heures.

SOC2 Type II pour agents

Tout audit SOC2 Type II couvre maintenant les systèmes IA. Les auditeurs vérifient : RBAC strict, monitoring, incident response, audit trail immuable.

Les fournisseurs d’exécution d’agents produisent des rapports SOC2 ; c’est un facteur de sélection critique pour acheteurs enterprise.

Patterns Human-in-the-Loop : gouvernance et escalade

Aucun agent ne devrait être 100 % autonome dès le jour 1. L’escalade humaine n’est pas une régression. C’est une architecture saine.

Les quatre phases d'autonomie

Phase 1 : Read-Only + Approval du tout

L’agent accède à des données, les lit, génère des rapports, mais ne modifie rien sans approbation. Coût humain : élevé. Time-to-value : long. Transparence : maximale.

Phase 2 : Actions sûres autonomes, riskées approuvées

Catégoriser en “safe” (réversibles) et “risky” (irréversibles). Safe exécute directement. Risky escalade. Coût humain : modéré. Équilibre : contrôle + rapidité.

Phase 3 : Autonomie de routine, supervision événementielle

L’agent fonctionne entièrement autonome, mais envoie des digests et alerte sur anomalies. L’humain revoit et peut intervenir proactivement. Coût humain : bas. Time-to-value : très rapide.

Phase 4 : Autonomie complète, audit rétroactif

L’agent décide et agit sans humain. L’audit rétroactif capture l’activité. Coût humain : minimal. Risque : dérive sans supervision. Seulement pour agents low-risk.

Critères de décision

Réversibilité : L’action peut-elle être annulée ?
Fréquence : Combien de fois par jour ?
Impact business : Si l’agent se trompe, quel coût ?
Trace audit : Pouvez-vous tracer qui a ordonné quoi ?

Patterns techniques

Escalade webhook : Agent génère action → envoie webhook à système d’approbation. Approver valide → agent procède/rejette.

Fallback mode : Si approver non-respond dans N secondes, escalade à autre approver. Jamais de deadlock.

Audit trail immuable : Chaque décision = log signé (hash cryptographique) incluant : décideur, timestamp, raison, approbation/rejet, validateur.

Observabilité et monitoring : sept outils pour la télémétrie des agents

Les agents non supervisés ne sont pas seulement une menace sécurité. Ils sont une menace commerciale. Un agent qui dépense 10× le budget d’API prévu — ces problèmes ne sont pas des CVE. Ce sont des anomalies comportementales.

L’observabilité capture : latency, throughput, cost per request, tool call patterns, output anomalies, input anomalies.

Outils disponibles

Arize — ML observability specialisé. Détecte data drift, prediction drift, tool call patterns, cost monitoring, red-teaming intégrée. Idéal pour : orgs avec many deployed agents.

Splunk — Ingère logs, recherche temps réel, alertes. Module Splunk AI Observability dédié agents. Idéal pour : enterprise Splunk existant.

Datadog — APM + logs + traces. Support agents IA émergent. Idéal pour : infra Kubernetes multi-tenant.

Vellum — Plateforme end-to-end agents. Gestion versions prompts, A/B testing, observabilité. Idéal pour : PME/startup, une pane of glass.

Azure AI Foundry — Suite Microsoft agents. Monitoring auto, HITL workflows, audit trail. Idéal pour : enterprise Microsoft stack.

CloudWatch — Native AWS. Logs structurés, métriques custom, alertes. Idéal pour : infrastructure AWS-native.

Dynatrace — APM + observabilité généraliste. Support agents émergent. Idéal pour : enterprise observability consolidation.

Signaux critiques

Signal	Seuil alerte	Action
—	—	—
Latency (p95)	>5s (agent-specific)	Bottleneck, optimize
Cost per request	>2x budget	Audit coûts, vérifier boucles
Tool call volume	>100 appels/request	Recursive loop possible
Error rate	>5%	Debug agent
Injection attempts	>10/jour (spike)	Possible attack, monitor
PII exposure	ANY	Remediate, disable

Orchestration multi-agents cross-platform

Un seul agent, c’est simple. Plusieurs agents coordonnés, c’est l’architecture d’entreprise future.

Architecture de référence

Un orchestrateur (Kubernetes, n8n, Temporal, Airflow) coordonne plusieurs agents déployés sur différentes plateformes. Agents communiquent via MCP. L’orchestrateur arbitre, retry, error handling. Monitoring centralisé capture activité cross-platform.

Patterns d'orchestration

Sequential : A → B → C. Linéaire, simple.

Parallel : A et B en parallèle, puis C agrège. Réduit latency.

Conditional : Si A retourne ERROR, run B (fallback).

Loop : Tant que A retourne “continue” : repeat. Contrôle boucle (max itérations, timeout global).

Choix orchestrateur

Outil	Complexité	Serverless	MCP-aware
—	—	—	—
n8n	Faible (visual)	Partiellement	Émergent
Temporal	Moyenne (code)	Non	Non
Airflow	Moyenne (DAG)	Partiellement	Non
AWS Step Functions	Faible	Oui	Non

Recommandation MVP : n8n (lowcode, visual, rapide).

Production scale : Temporal ou Airflow (workflow-as-code, observabilité).

Checklist de déploiement : sécurité, tests, gouvernance

Avant de passer un agent en production.

Pré-déploiement

Architecture & Isolation

[ ] Isolation technology justifiée (threat model → tech choice).
[ ] Firewall & network segmentation : agent isolé (egress default-deny).
[ ] Credential management : secrets en vault, rotation régulière.
[ ] Logs chiffrés, immuables, pas de PII/credentials en clair.

Agent & Modèle

[ ] Model selection documentée (taille, fine-tuning, version).
[ ] System prompt review : pas de data sensibles hardcodées.
[ ] Tool catalog : stricte allowlist ; chaque outil expliqué.
[ ] Tool calls signés (signature cryptographique).

Tests

[ ] Prompt injection testing : 20+ payloads attaque.
[ ] Tool misuse testing : paramètres mauvais ; gestion erreur ?
[ ] Output validation : code exécuté en sandbox.
[ ] Load test : X requêtes concurrentes ; latency, cost, error rate.

Governance

[ ] NIST risk assessment : menaces, mitigations, ownership.
[ ] Compliance matrix : GDPR/HIPAA/SOC2 applicable ? Conforme ?
[ ] Incident response plan : agent compromis → escalade.
[ ] Audit trail baseline : logs ingérés, immuable.

Déploiement : 4 phases

Phase 1 : Pilot (1 week, 1 % traffic)
Phase 2 : Canary (1–2 weeks, 5–10 % traffic)
Phase 3 : Rollout (1–2 weeks, 50 % traffic)
Phase 4 : GA (100 % traffic)

Post-déploiement

Monitoring & Response

[ ] Cost anomaly (>2x baseline) → auto alert + escalade.
[ ] Error rate spike (>5%) → auto alert + rollback possible.
[ ] Injection attempt → log, alert, investigate.
[ ] Compliance audit : logs reviewés mensuellement.

Framework de sélection de vendeur : menace model → tech choice

Pas un seul vendeur optimal pour toutes les organisations. Définissez d’abord votre menace model.

Étapes

Étape 1 : Définir le menace model

Quel code l’agent exécute-t-il ? Qui accède ? Impact si compromis ? Données sensibles ?

Étape 2 : Isolation min par menace

Menace	Isolation min	Exemples
—	—	—
CRITIQUE	Firecracker + network segmentation + HITL	E2B
ÉLEVÉE	Firecracker ou Kata	E2B, Northflank
MOYENNE	gVisor ou containers	Modal, Google Cloud Run
FAIBLE	Containers + RBAC	Docker

Étape 3 : Évaluer vendeur sur 5 axes

Performance, coûts, écosystème (MCP, LangChain), conformité (SOC2), BYOC.

Table de décision

Menace	Performance	BYOC	Budget	Recommendation
—	—	—	—	—
CRITIQUE	Ultra-fast	Non	PAYG	E2B
CRITIQUE + contrôle	Fast	Oui	Mixed	Northflank
ÉLEVÉE	Fast	Oui	Fixed	Daytona
ÉLEVÉE	Flexible	Non	PAYG	Modal
MOYENNE	Flexible	Non	PAYG	Modal / Cloud Run
FAIBLE	Any	Flexible	Any	Internal containers

Mythes et réalités de la sécurité des agents (8 points)

Mythe 1 : Les conteneurs suffisent. Réalité : Conteneurs partagent le noyau hôte. Une CVE du noyau = escape. Pour code LLM-généré, il faut microVM ou gVisor.

Mythe 2 : Les guardrails en prompt suffisent. Réalité : Guardrails n’enferment rien. Sandboxing pour sécurité. Les deux nécessaires.

Mythe 3 : L’air-gapping = sécurisé. Réalité : Prévient exfiltration réseau mais pas escape local. Combinez avec isolation + policy.

Mythe 4 : Propriétaire = plus sûr. Réalité : Sécurité dépend architecture, pas ownership. Choisissez sur capacité. Ajoutez sandboxing indépendamment.

Mythe 5 : MCP = résout tous les problèmes. Réalité : MCP standardise outils. Migration E2B → Modal requiert 80 % réingénierie infra.

Mythe 6 : HITL = toutes actions approuvées. Réalité : HITL peut être asynchrone, échantillonnage, ou rétroactif. Taillez au risk level.

Mythe 7 : Compliance = checkboxes. Réalité : Compliance = processus continu. Intégrez-la en opération.

Mythe 8 : Open-source = moins sûr. Réalité : Open-source (Firecracker, gVisor) audité mondialement. Choisissez sur architecture.

Étude de cas : cto.new, déploiement production en 8 semaines

Contexte : cto.new est une plateforme d’assistant technique. Idée : agent recommandant outils infra basé sur contexte utilisateur. Agent accède à questions sensibles, exécute code test, génère rapport.

Phase 1 : Architecture (semaines 1–2)

Agent Claude 3.5 Sonnet fine-tuned. Tools Terraform generator + cloud pricing API (allowlist stricte). Transport n8n. Isolation Kata Container on Northflank (microVM dédiée/request). Monitoring Datadog + Splunk (logs chiffrés, PII masking).

Phase 2 : Testing (semaines 3–4)

Red-teaming : 100+ payloads injection ; 80% bloqués sandbox, 20% tool validation. Load test : 500 requêtes concurrentes → p95 = 3.2s (acceptable). Cost test : $0.15/request.

Phase 3 : Governance (semaines 5–6)

NIST risk assessment document signé. GDPR : données pseudonymes, rétention 30 jours. SOC2 : audit trail immuable, incident SLA <1 heure. HITL approval : actions → Slack notif + 15-min veto.

Phase 4 : Pilot (semaines 7–8)

5 % users (1 % traffic). A/B : agent vs. human. Résultat : 76 % satisfaction agent vs. 81 % human. Cost $0.12/request (meilleur).

Post-launch

Canary + rollout per checklist. Cost anomaly : si >$0.25/req → escalade. Incident : hallucinated Terraform code. Audit = validation tool error. Fix + redeploy.

Learnings

Cold start Northflank (2–3s) acceptable pour recommendation. BYOC = packaging une fois, reproductible. HITL 15-min window naturel. Observabilité critique : cost spike détecté <5 min, escalade, résolu.

Résultat : 2 mois concept → production. 30K users beta. Zéro incidents sécurité.