Agents en production : quatre études de cas réels

Les démos d’agents sont impressionnantes. Les déploiements d’agents sont chaotiques. L’écart entre « ça marche sur mon ordinateur » et « ça tourne en production » est rempli de cas limites, de mauvaises surprises de coûts et de modes d’échec qu’aucun tutoriel ne vous a préparés à affronter.

On a tous vu la démo bien léchée : un agent réserve un vol, rédige un rapport et soumet un bug — le tout en deux minutes de capture d’écran. Ce qu’on ne voit pas, c’est le taux d’escalade de 40 % lors de la première semaine, la facture d’API à 12 $ par requête, ou l’agent qui a « corrigé » un problème de corruption de données en l’aggravant.

Ces quatre études de cas comblent cet écart. Elles couvrent de vraies architectures, de vrais chiffres et de vraies erreurs issues de déploiements d’agents en production. Chaque étude de cas est autonome — lisez les quatre ou passez directement à celle qui correspond à votre cas d’usage.

Ce que vous apprendrez :

• Comment chaque système a été conçu et pourquoi
• Ce qui a fonctionné et ce qui a échoué de façon spectaculaire
• Des métriques concrètes : précision, coût, latence et taux de supervision humaine
• Des leçons apprises applicables dans tous les domaines

Étude de cas 1 : agent de triage du support client

Le problème

Une entreprise SaaS (Software as a Service) de taille moyenne reçoit plus de 500 tickets de support par jour. Les réponses de niveau 1 — réinitialisations de mot de passe, questions de facturation, contournements de bugs connus — accaparent environ 60 % du temps de l’équipe support. Des ingénieurs qui devraient résoudre des problèmes complexes font des copier-coller pour répondre aux mêmes dix questions.

L’objectif métier était clair : automatiser la résolution de niveau 1 sans dégrader la satisfaction client.

Architecture

┌─────────────────────────────────────────────────┐
│                 Incoming Ticket                  │
└──────────────────────┬──────────────────────────┘
                       │
                       ▼
              ┌────────────────┐
              │  Router Agent  │
              │ (Intent Class.)│
              └──┬───┬───┬──┬─┘
                 │   │   │  │
        ┌────────┘   │   │  └────────┐
        ▼            ▼   ▼           ▼
   ┌─────────┐ ┌────────┐ ┌──────┐ ┌──────────┐
   │ Billing │ │Technical│ │Account│ │ Feature  │
   │ Handler │ │ Handler │ │Handler│ │ Request  │
   └────┬────┘ └───┬────┘ └──┬───┘ └────┬─────┘
        │          │         │           │
        └──────────┴────┬────┴───────────┘
                        ▼
              ┌──────────────────┐
              │ Confidence Check │
              │  ≥ 0.85 → Reply │
              │  < 0.85 → Human │
              └──────────────────┘

Outils et intégrations :

• API du système de tickets (Zendesk) pour lire les tickets et y répondre
• Recherche dans la base de connaissances (vector store sur les articles d’aide)
• Consultation des données client (statut du compte, niveau d’abonnement, interactions récentes)

Configuration principale :

router_agent:
  model: gpt-4o-mini
  system_prompt: |
    You are a support ticket classifier. Classify into exactly one category:
    billing, technical, account, feature_request.
    Return JSON: {"category": "...", "confidence": 0.0-1.0, "summary": "..."}
  temperature: 0.0

handler_agents:
  escalation_threshold: 0.85
  max_knowledge_base_results: 5
  response_tone: "professional, empathetic, concise"

Résultats

Ce qui a échoué

Sur-escalade lors de la première semaine. Le taux d’escalade initial était de 40 %. L’agent routeur était trop prudent — tout ticket formulé de façon ambiguë était transmis à un humain. La solution : abaisser le seuil de confiance de 0,95 à 0,85 et ajouter des exemples few-shot de tickets limites dans le prompt du routeur.

Cas limites en facturation. Les remboursements partiels, les contestations de paiement et la facturation multi-comptes nécessitaient un jugement humain nuancé. L’agent proposait parfois un remboursement total alors que la politique n’autorisait qu’un remboursement partiel. La solution : des règles codées en dur pour les actions de facturation impliquant de l’argent. L’agent peut expliquer la politique, mais ne peut pas exécuter d’actions financières supérieures à 20 $ sans approbation humaine.

Base de connaissances obsolète. L’agent a cité un article d’aide décrivant un flux d’interface qui avait changé deux mois plus tôt. Le client a suivi les instructions, s’est retrouvé bloqué et a escaladé avec colère. La solution : des vérifications automatisées de fraîcheur — les articles non mis à jour depuis 90 jours sont signalés, et l’agent ajoute une mise en garde lorsqu’il cite du contenu ancien.

Leçons apprises

• Commencez par la catégorie la plus simple. Les questions de compte de type FAQ avaient le taux d’automatisation le plus élevé. La facturation est venue en dernier.
• Mesurez la satisfaction client, pas seulement le taux de résolution. Un ticket résolu avec un client frustré n’est pas un succès.
• La fraîcheur de la base de connaissances est aussi importante que la qualité de l’agent. Le meilleur agent du monde ne peut pas compenser une documentation obsolète.

Étude de cas 2 : agent de recherche et de génération de rapports

Le problème

Une équipe de conseil consacre 8 à 12 heures par semaine à la compilation de rapports d’études de marché à partir de plusieurs sources de données : APIs d’actualités, bases de données financières et documents internes. Les rapports suivent une structure cohérente, mais la collecte de données est fastidieuse et sujette aux erreurs. Les analystes passent la majeure partie de leur temps à collecter — et non à analyser.

Architecture

┌────────────────────────────────────┐
│         Research Brief (User)      │
└──────────────────┬─────────────────┘
                   ▼
         ┌──────────────────┐
         │ Orchestrator Agent│
         │ (Task Decomposer)│
         └──┬──────┬──────┬─┘
            │      │      │
     ┌──────┘      │      └──────┐
     ▼             ▼             ▼
┌──────────┐ ┌──────────┐ ┌───────────┐
│  News    │ │ Financial│ │ Internal  │
│  Worker  │ │  Worker  │ │ Doc Worker│
└────┬─────┘ └────┬─────┘ └─────┬─────┘
     │             │             │
     └──────┬──────┴─────────────┘
            ▼
    ┌───────────────┐
    │Synthesis Agent│
    │(Report Writer)│
    └───────┬───────┘
            ▼
    ┌───────────────┐
    │ Review Agent  │
    │(Verification) │
    └───────┬───────┘
            ▼
    ┌───────────────┐
    │ Final Report  │
    │ (w/ Citations)│
    └───────────────┘

Outils et intégrations :

• API d’actualités (NewsAPI, Google News) pour les événements récents et la couverture sectorielle
• API de données financières (Alpha Vantage, entrepôt de données interne) pour les données de marché
• Recherche dans les documents internes (vector store sur les rapports passés et les briefs clients)
• Génération de sorties structurées (pipeline Markdown → PDF)

Configuration principale :

orchestrator:
  model: gpt-4o
  decomposition_strategy: "parallel_by_source"
  max_sub_tasks: 8

synthesis_agent:
  citation_requirement: "Every factual claim MUST include [Source: ...] inline"
  output_format: "structured_markdown"
  sections:
    - executive_summary
    - market_overview
    - competitive_landscape
    - financial_highlights
    - risks_and_opportunities
    - appendix_sources

review_agent:
  checks:
    - contradiction_detection
    - citation_verification
    - data_recency (max_age_days: 30)
    - completeness (all_sections_present: true)

Résultats

Ce qui a échoué

Affirmations hallucinations. Les premières versions de l’agent de synthèse généraient des statistiques de marché qui semblaient plausibles mais sans aucune source réelle. Un rapport affirmait qu’un marché « croissait à un TCAC de 14,3 % » — un chiffre qui n’apparaissait dans aucune donnée source. La solution : faire de la citation une exigence stricte dans le prompt de synthèse et ajouter l’agent de révision comme étape de vérification indépendante.

Données financières obsolètes. L’agent financier renvoyait des données de chiffre d’affaires trimestriel du trimestre précédent alors que l’utilisateur attendait des estimations pour le trimestre en cours. La solution : des contraintes de fraîcheur explicites dans le prompt de l’agent et une vérification de date dans l’agent de révision

Articles Connexes

• Récupération d’Erreurs pour Agents : 5 Patrons pour la Fiabilité en Production
• Patterns Multi-Agents : Orchestrateurs, Workers et Pipelines
• Débogage et Observabilité dans les Systèmes d’Agents Autonomes
• Stratégies de mise en cache pour les agents IA : réduire les coûts sans compromis
• Patterns d’Utilisation des Outils : Interfaces Agent-Outil Fiables