La plupart des démos d’agents sont convaincantes tant qu’elles ne quittent pas le laptop du développeur. L’UX s’effondre, les coûts explosent, et personne ne sait expliquer pourquoi un agent a poussé une modification cassée un vendredi à 17 h. Avec la nouvelle plateforme IA pour agents de Cloudflare qui fait la une et le retour de contrôles « niveau desktop » via des fonctionnalités façon Codex, on vous pose une question légitime : quelle est notre architecture de production pour les agents ?
Voici la réponse que nous mettons en production : traitez les agents comme des systèmes distribués, pilotés par événements, à l’edge — pas comme des chatbots monolithiques. Ci-dessous, une architecture de référence pragmatique que vous pouvez présenter à votre équipe dès aujourd’hui. Elle est agnostique vis‑à‑vis des fournisseurs, optimisée pour une latence mesurable, des politiques applicables et des coûts prévisibles. Elle monte également en charge d’une seule squad produit à l’automatisation à l’échelle de l’organisation sans réécrire la plateforme.
Des bots sur laptop aux agents edge-native
Deux évolutions clés en 2026 :
- Les runtimes edge sont devenus « agent-aware ». Cloudflare a annoncé une couche d’inférence conçue pour les agents (pensez Workers + Queues + Durable Objects + Vectorize + inférence IA), rendant réaliste la conservation de l’état et des outils au plus près des utilisateurs. Vercel, Fly.io et les hyperscalers ont suivi avec leurs déclinaisons.
- Les agents desktop sont de retour. Les fonctionnalités de type Codex, musclées, peuvent contrôler votre ordinateur en arrière-plan. C’est puissant — et dangereux — sans politique, audit et bon périmètre. Il vous faut des garde-fous côté serveur même si votre UI tourne sur un laptop.
Votre rôle de CTO n’est pas de choisir la démo la plus tape-à-l’œil, mais de concevoir un système où les décisions d’un agent sont observables, réversibles et suffisamment peu coûteuses pour tourner à l’échelle.
Exigences de production (le niveau d’exigence à viser)
- Latence : Une latence perçue <1 s pour les tours courants en Amérique du Nord ; le compute edge doit rester <100 ms par fonction, la recherche <150 ms dans la région, le raisonnement avec petits modèles 300–800 ms, grands modèles 1,5–4 s. Ne faites attendre l’utilisateur que lorsque cela a du sens.
- Sécurité : Politique explicite sur les outils que l’agent peut appeler, avec périmètre de ressources et approbation humaine pour les actions à haut risque.
- Observabilité : Traces OpenTelemetry et événements structurés pour chaque action, avec relecture. Si vous ne pouvez pas rejouer un incident, vous n’avez pas bâti une plateforme — vous avez bâti une démo.
- Contrôle des coûts : Budgets de tokens stricts par tour/session, contrôle d’admission pour les prompts longs et contre-pression pour les charges en pics. Supposez une rareté de compute IA ; concevez en conséquence.
- Portabilité : Remplacez modèles et hôtes d’outils sans refactorer la logique de l’agent. Évitez la glue qui encode les bizarreries d’un seul fournisseur d’LLM.
Une architecture de référence edge-native
Mappez ces concepts sur la stack de votre choix. J’emploierai les termes Cloudflare (et leurs équivalents AWS/GCP) pour rester concret.
1) Porte d’entrée et identité
- Edge API : Une passerelle légère à l’edge (Workers, API Gateway + CloudFront, ou Fastly Compute@Edge) termine TLS, authentifie les requêtes (OIDC/JWT) et normalise les payloads.
- Métadonnées de session : Attachez IDs utilisateur/org, niveau de risque et un budget de tokens par session. Stockez l’état de session à courte durée de vie dans un key‑value edge ou un objet de session (Durable Objects ; AWS : DynamoDB + Lambda@Edge).
2) Orchestrateur et scratchpad
- Bus d’événements : Chaque tour utilisateur émet un événement vers une file (Cloudflare Queues ; AWS SQS ; GCP Pub/Sub). Cela découple la latence UI du travail aval.
- Orchestrateur : Un worker sans état consomme les événements, exécute la boucle de contrôle (function calling, planning) et persiste un Action Graph — un DAG d’appels d’outils avec entrées/sorties — dans un objet de session (Durable Objects ; ou Redis/DynamoDB + Step Functions).
- Scratchpad : Stockez les données de type chain‑of‑thought et les plans comme état privé de l’agent, non exposé aux utilisateurs, et rédigez‑les des logs. Le modèle reçoit le plan ; les logs reçoivent le résultat et un résumé de la justification.
3) Moteur de raisonnement (abstraction de modèle)
- Routeur de modèles : Une fine abstraction pouvant cibler des modèles fermés (OpenAI/Anthropic), de l’inférence hébergée à l’edge (Cloudflare AI), ou des poids ouverts (par ex., Qwen 35B/A3B, Llama 3.x) sur GPUs serverless (Fireworks, Modal) selon la politique : sensibilité des données, coût, vitesse et exigences d’exactitude.
- Interfaces JSON uniquement : Utilisez des sorties structurées (JSON Schema) pour la sélection d’outils, les arguments et les résumés. Rejetez les réponses mal formées au niveau du routeur et re‑promptez avec un budget plus petit plutôt que de laisser des déchets passer en aval.
4) Exécution des outils et sandboxing
- Bac à sable WASM : Exécutez des outils rapides et non fiables dans WASI/WASM avec plafonds de temps et de mémoire. Pour les actions plus longues, dispatchez vers des fonctions serverless ou des jobs éphémères (Workers/Pages Functions ; AWS Lambda/Fargate Jobs ; GCP Cloud Run Jobs).
- Politique d’identifiants : Émettez des identifiants éphémères et à portée limitée par invocation d’outil via OIDC et un gestionnaire de secrets (Vault, AWS STS + Secrets Manager). Aucun token longue durée intégré dans les prompts.
- Actions desktop : Si vous laissez un agent « utiliser un ordinateur », faites-le passer par un broker qui expose une surface d’outils restreinte (par ex., ouvrir une URL dans un navigateur sandboxé, lire le texte de la fenêtre sélectionnée, simuler un clic dans une boîte englobante) et journalise chaque action avec captures d’écran pour l’audit. Ne lui donnez jamais l’OS complet.
5) Couches de mémoire
- Court terme : État par session (Durable Objects ; DynamoDB/Redis). TTL de quelques minutes à heures.
- Long terme : Corpus RAG dans un magasin vectoriel proche de l’agent (Cloudflare Vectorize ; pgvector sur Neon ; Pinecone ; Weaviate). Gardez les embeddings au plus près de l’inférence pour éviter la latence et le coût d’egress.
- Transactionnelle : Une base relationnelle (Postgres/PlanetScale) pour les droits, les approbations et l’audit durable.
6) Politique et approbations
- Moteur de politique : Évaluez chaque appel d’outil planifié contre la politique (OPA/Rego ou Amazon Cedar). Entrées : rôle utilisateur, environnement (prod/stage), sensibilité du dataset, niveau de risque de l’outil, budget de tokens restant.
- Humain dans la boucle : Pour les actions risquées (merge sur main, accès à des PII, dépense >$X), bloquez et émettez une notification Slack/Email avec un flux d’approbation en un clic. Enregistrez l’approbateur et la justification.
7) Observabilité et relecture
- Traces : Émettez des spans OpenTelemetry pour chaque étape : construction du prompt, appel modèle, retrieval, appel d’outil, contrôle de politique. Corrélez avec une session et un utilisateur.
- Journal d’événements : Persistez un flux d’événements compact et caviardé (Queue → stockage objet). Stockez entrées/sorties, version du modèle, coût et latence. C’est votre source de vérité pour la relecture.
- Rédaction : Nettoyage des PII avant toute sortie du runtime edge. Conservez un coffre non caviardé et à accès contrôlé uniquement si la loi l’exige.
8) Contrôles de coûts
- Budgets : Plafonds stricts par tour et par session. Exemple : 8K tokens en entrée + 2K en sortie par tour, plafond de 40K par session, avec une stratégie de backoff dès 80 % du plafond atteint.
- Contrôle d’admission : Rejetez les prompts >N Ko, suggérez le découpage, ou basculez vers un modèle plus petit/moins cher avec consentement explicite de l’utilisateur.
- Contre-pression : Quand les files s’accumulent, dégradez de manière gracieuse : modèles plus petits, moins d’outils, ou retrievals groupés.
Exemple concret : un agent de préparation de PR pour votre monorepo
Objectif : l’agent rédige une pull request qui clôt un ticket Jira en préparant les changements de code, les tests et un plan de migration — sans jamais pousser sur main sans approbation.
- L’utilisateur poste un lien vers le ticket. L’Edge API authentifie, alloue un budget de session de 40K tokens et écrit un objet de session.
- L’orchestrateur récupère le ticket, exécute un RAG sur les chemins de code pertinents via un index vectoriel (région edge la plus proche). Latence cible : 80–150 ms pour le retrieval.
- Le moteur de raisonnement (modèle open 14B ou fermé premium) planifie : lire les fichiers A/B, générer un patch, lancer les tests, proposer une migration DB, demander l’approbation pour ouvrir une PR.
- La couche d’outils exécute dans l’ordre : lecture des fichiers (WASM), rédaction du patch (modèle), exécution des tests (job serverless) et préparation d’une PR. Chaque appel d’outil porte un jeton à portée limitée, valable 5 minutes.
- Le moteur de politique bloque git push et envoie une carte d’approbation sur Slack avec un résumé du diff et le coût/latence à date. L’approbateur clique « Autoriser » ou « Réviser ».
- À l’approbation, l’agent ouvre la PR et publie un lien vers la trace. Toutes les actions sont capturées dans un journal d’événements rejouable.
Budget de latence (médiane) :
- Requête edge + auth : 30–60 ms
- RAG : 80–150 ms
- Planification LLM (petit modèle) : 300–600 ms
- Génération du patch (modèle) : 700–2 000 ms selon taille/modèle
- Tests (job serverless) : parallélisés ; l’utilisateur voit des mises à jour en streaming
- Temps total jusqu’à un premier résultat utile : <1 s pour l’aperçu du plan ; 2–5 s pour le premier brouillon de patch
Esquisse de coûts (mettez à jour selon le pricing de vos fournisseurs) :
- Définissez un coût par 1M de tokens pour chaque tier de modèle. Calculez par tour : (tokens entrée + tokens sortie) / 1 000 000 × prix.
- Les tours avec de petits modèles open‑weight peuvent être d’un ordre de grandeur moins chers que les modèles de pointe. Utilisez‑les pour la planification et la sélection d’outils ; réservez les modèles de pointe pour la synthèse de code ou le raisonnement difficile.
- L’egress (sortie de données) compte toujours. L’egress des clouds publics est souvent autour de $0,05–$0,09/GB. Si votre agent transfère de gros artefacts (logs, binaires), colocalisez le compute avec les données ou déplacez les artefacts vers un stockage edge.
Construire vs. acheter : que sous-traiter à la plateforme
Vous n’avez pas besoin de tout construire. Voici un partage pragmatique.
- Acheter/Capitaliser : Runtime edge, files, stockage objet ; hébergement de modèles pour au moins deux tiers (rapide/peu cher et précis/cher) ; base vectorielle avec placement régional ; logging compatible OTel ; gestion des secrets.
- Construire : Orchestrateur (votre boucle de contrôle), intégration de politique (votre risque), catalogue d’outils et politique de sandbox, rédaction, UI de relecture et contrôles de coûts. C’est là que résident vos règles métier et votre avantage.
La stack d’agents intégrée de Cloudflare réduit la glue ; AWS/GCP vous donnent un contrôle granulaire avec plus d’assemblage. Dans tous les cas, gardez le routeur de modèles et la couche de politique chez vous pour éviter le lock‑in fournisseur.
Équipe et calendrier (compatible nearshore)
- Équipe cœur : 1 ingénieur plateforme (edge/runtime/files), 1 ingénieur IA (prompting, routeur, évaluations), 1 ingénieur applicatif (outils, logique métier), 0,5 SRE/observabilité. Ajoutez un ingénieur sécurité pour le périmètre agent desktop.
- Calendrier : Un pilote gouverné en 4 semaines est réaliste avec un périmètre focalisé :
- Semaine 1 : Porte d’entrée, identité, tracing et un orchestrateur stub. Choisissez deux modèles et câblez un routeur.
- Semaine 2 : Implémentez trois outils en WASM (lecture seule), ajoutez la recherche vectorielle, et le moteur de politique en mode « report‑only ».
- Semaine 3 : Activez le blocage de politique pour une action risquée, ajoutez l’approbation Slack et la rédaction. Démarrez les dashboards de coûts.
- Semaine 4 : Livrez l’agent de préparation de PR à une squad. Définissez des SLO : réponse agent p95 <2,5 s, coût par tour <$X, zéro contournement de politique.
Les équipes nearshore au Brazil peuvent couvrir les heures de build avec 6–8 heures de recouvrement avec les fuseaux US et maintenir le rythme d’intégration pendant que votre équipe centrale se concentre sur la politique et la sélection des modèles.
Gestion des risques et arbitrages
- Exactitude vs. coût : Utilisez de petits modèles pour la planification et le routage d’outils ; n’escaladez qu’à bon escient. Vous réduirez la dépense de 30–70 % sans dégrader les résultats.
- Latence vs. portabilité : L’inférence hébergée à l’edge accélère l’UX mais peut réduire le choix de modèles. Gardez une porte de sortie vers un second fournisseur pour le failover et les vérifications de régression.
- Sécurité vs. autonomie : Plus d’approbations réduit les incidents mais pénalise le débit. Commencez strict, puis relâchez avec des métriques de confiance et des audits a posteriori.
- Périmètre de l’agent desktop : La tentation est de laisser les agents « juste le faire ». Ne le faites pas. Médiez chaque action desktop via une surface d’outils étroite et enregistrez tout.
Comment décider où exécuter chaque composant
Ne poussez pas tout aveuglément à l’edge. Utilisez cette grille simple :
- Edge : Authentification, façonnage des requêtes, planification légère, retrieval lorsque le corpus est déjà en cache ou répliqué. Règle de base : travail <100 ms et <256 Ko d’E/S.
- Régional : RAG lourd sur des données transactionnelles, longues fenêtres de contexte, et tout ce qui induirait de l’egress inter‑régions si exécuté à l’edge.
- Arrière‑plan : Outils >2 s ou nécessitant de l’isolation (tests, compilations, indexation). Toujours checkpoint vers le journal d’événements ; streamez des partiels vers l’UI.
Évaluation : prouvez que cela fonctionne avant de passer à l’échelle
- Tâches de référence : 20–50 tâches réelles représentatives de la production. Suivez le taux de succès, le nombre moyen de tours, le coût par succès et le temps jusqu’au premier résultat utile.
- Tests de garde‑fous : Simulez des prompts risqués et vérifiez que le moteur de politique les bloque. Incluez des scénarios de prompt‑injection et de tentative d’exfiltration de données.
- Charge : Test de stabilité (soak) avec une concurrence réaliste. Surveillez la profondeur des files et le comportement de contre‑pression ; vérifiez l’activation des politiques de dégradation gracieuse.
Et après : se préparer à la rareté
La demande pour les agents dépasse l’offre. Attendez‑vous à des pénuries périodiques de compute et à du throttling côté modèles. Concevez dès maintenant pour le multi‑modèle, le routage multi‑fournisseur, des fallbacks dépendants du budget et des SLA grossiers (« rapide et suffisamment bon » vs « lent mais précis »). Quand la contrainte tombera, les équipes disposant de leviers de coût et d’observabilité continueront à livrer pendant que les autres mettront leurs déploiements en pause.
Points clés
- Arrêtez de traiter les agents comme des chatbots ; traitez‑les comme des systèmes événementiels, d’abord à l’edge.
- Construisez votre propre orchestrateur, couche de politique, routeur de modèles et relecture ; achetez la plomberie.
- Atteignez une UX sous la seconde en gardant planification et retrieval à l’edge ; poussez le travail long vers des jobs.
- Utilisez de petits modèles pour la planification et n’escaladez qu’à bon escient pour maîtriser la dépense.
- Imposez des identifiants éphémères et à portée limitée, et des approbations humaines pour les actions risquées.
- Instrumentez tout avec OpenTelemetry et gardez un journal d’événements caviardé et rejouable.
- Concevez dès le premier jour pour le multi‑modèle et le multi‑fournisseur afin de résister à la rareté du compute IA.