Chaque démo en conférence montre la même chose : un agent IA qui réserve des vols, écrit du code et gère le calendrier — le tout en une seule prise fluide. Le public applaudit. Le fondateur lève une Série B.

Puis quelqu'un essaie de le déployer dans une entreprise réelle, et tout s'effondre.

Nous avons déployé des agents IA au sein d'opérations Fortune 500. Pas des démos. Pas des prototypes. Des systèmes qui tournent 24/7, prennent des décisions réelles et touchent de l'argent réel. Voici ce que nous avons appris sur le fossé entre ce qui fait bonne impression sur scène et ce qui survit en production.

Le Fossé Démo-Production

Dans une démo, vous contrôlez les inputs. L'agent reçoit une requête bien formatée, accède à une API propre et renvoie une réponse soignée. Le chemin heureux est le seul chemin.

En production, les inputs sont désordonnées. Les API tombent en timeout. Les données sont obsolètes. Les utilisateurs demandent des choses pour lesquelles l'agent n'a pas été conçu. Les cas limites ne sont pas des cas limites — c'est le mardi.

Le problème fondamental est que la plupart des architectures à agents sont optimisées pour la capacité, pas pour la fiabilité. Elles peuvent faire des choses impressionnantes occasionnellement. Les entreprises ont besoin de systèmes qui font des choses prévisibles de manière consistante.

Ce Dont les Agents Ont Besoin en Production

Après avoir déployé les agents autonomes de Sentara dans des centres d'appels et des équipes opérationnelles, nous avons convergé sur cinq exigences non négociables :

1. Autonomie Délimitée

L'agent le plus dangereux est celui qui ne connaît pas ses propres limites. Chaque agent en production a besoin de frontières explicites :

  • Périmètre d'action — Que peut-il faire ? Qu'est-ce qui nécessite une approbation humaine ?
  • Seuils de confiance — En dessous de quel niveau de confiance escalade-t-il ?
  • Limites du rayon d'impact — Quel est l'impact maximal d'une seule décision ?

Nous l'implémentons comme un système de permissions, pas différent des permissions fichier Unix. Chaque agent a une matrice de capacités qui définit exactement ce qu'il peut lire, écrire et exécuter. Aucune permission implicite. Aucun "ça semblait raisonnable."

2. Fallbacks Déterministes

Quand un agent basé sur un LLM rencontre de l'ambiguïté, il a besoin d'un fallback qui ne soit pas "réessayer avec un prompt différent." Nos agents utilisent une architecture décisionnelle à niveaux :

  • Niveau 1 : Basé sur des règles — Si la situation correspond à des patterns connus, utiliser la logique déterministe. Aucun LLM nécessaire. Rapide, prévisible, auditable.
  • Niveau 2 : Assisté par le modèle — Si les règles ne couvrent pas le cas, utiliser le modèle avec un output contraint. Réponses structurées, validées par rapport à des schémas.
  • Niveau 3 : Escalade humaine — Si la confiance est sous le seuil ou l'action dépasse le périmètre, router vers un humain avec un contexte complet.

L'insight clé : la plupart des interactions des agents n'ont pas besoin d'IA du tout. Dans nos déploiements, 60 à 70 % des décisions sont gérées par les règles de Niveau 1. Le LLM gère les 30 à 40 % restants où le jugement est réellement nécessaire.

3. État Observable

On ne peut pas débugger ce qu'on ne peut pas observer. Chaque décision de l'agent doit produire une trace qui répond à trois questions :

  • Qu'a perçu l'agent ? (inputs, contexte, informations récupérées)
  • Qu'a considéré l'agent ? (actions candidates, scores de confiance, raisonnement)
  • Qu'a fait l'agent ? (action entreprise, résultat, effets de bord)

Nous loguons chaque décision à chaque niveau. Quand quelque chose tourne mal — et quelque chose tourne toujours mal — l'investigation prend des minutes, pas des jours.

4. Dégradation Progressive

Les agents en production doivent gérer des modes de défaillance que les agents de démo ne rencontrent jamais :

  • Défaillances API — L'agent ne parvient pas à atteindre un service externe. Réessayer ? Mettre en file d'attente ? Se rabattre sur des données en cache ?
  • Pics de latence du modèle — Le LLM met 30 secondes au lieu de 2. L'utilisateur attend ? L'agent utilise un modèle plus petit ?
  • Corruption du contexte — L'historique de conversation est inconsistant. L'agent hallucine en avant ou réinitialise ?

Chaque mode de défaillance nécessite une stratégie explicite. "Réessayer trois fois puis erreur" n'est pas une stratégie. C'est abandonner lentement.

5. Évaluation Continue

Les agents de démo sont testés une fois. Les agents en production sont testés en continu. Nous exécutons des suites d'évaluation sur nos agents déployés toutes les heures :

  • Scénarios synthétiques qui testent les cas limites connus
  • Tests de régression pour les défaillances précédemment rencontrées
  • Détection de la dérive sur la distribution des décisions (si l'agent commence soudainement à escalader 3 fois plus que d'habitude, quelque chose a changé)

L'Architecture Qui Fonctionne

Après de multiples itérations, nous avons convergé sur une architecture que nous appelons Autonomie Supervisée. L'agent opère indépendamment dans des limites définies, mais chaque session est évaluée par un pipeline d'évaluation asynchrone.

Requête Utilisateur → Routeur → [Moteur de Règles | Agent | File Humaine]
                                    ↓
                          Action + Log de Trace
                                    ↓
                          Pipeline d'Évaluation Asynchrone
                                    ↓
                          Score + Alerte (si anomalie)

Le pipeline d'évaluation ne bloque pas l'agent. Il s'exécute après coup, évaluant les décisions par rapport à des critères de qualité. Si une décision semble erronée, il alerte l'équipe opérationnelle. Si un pattern de décisions médiocres émerge, il peut automatiquement resserrer les seuils de confiance de l'agent — le rendant effectivement plus conservateur jusqu'à ce qu'un humain vérifie ce qui se passe.

Ce Que les Entreprises Font Mal

Trois patterns que nous voyons se répéter :

"Commençons avec un agent généraliste." Non. Commencez avec le périmètre le plus étroit possible. Un agent qui gère brillamment un seul workflow spécifique a infiniment plus de valeur qu'un agent qui gère tout de manière médiocre. Élargissez le périmètre après avoir gagné la confiance.

"Le modèle comprendra tout seul." Le modèle est un composant. Le système autour — routage, fallback, évaluation, permissions — est ce qui le rend prêt pour la production. Consacrer 80 % de l'effort au prompt engineering et 20 % à l'infrastructure, c'est exactement l'inverse de ce qu'il faut faire.

"On ajoutera les garde-fous après." Les garde-fous ne sont pas une fonctionnalité qu'on ajoute. C'est une décision architecturale qui façonne tout le reste. Ajouter de la sécurité à un système non sécurisé signifie reconstruire le système.

La Vérité Honnête

Les agents IA en production sont moins autonomes que vous ne le penseriez et plus utiles que vous ne l'attendriez. La valeur ne réside pas dans le remplacement du jugement humain. Elle réside dans la gestion des 70 % d'interactions qui ne nécessitent aucun jugement du tout, et dans la fourniture d'un support structuré pour les 30 % qui en nécessitent.

Ce n'est pas aussi excitant qu'une démo en conférence. Mais c'est ce qui fonctionne vraiment.