Comment déployer un agent IA en production : guide de mise en production récupérable, observable et réversible

Feuille de route de mise en production : définir les limites, puis valider chaque point

Déployer un agent IA en production ne consiste pas principalement à ajouter des modèles ou de la complexité d’orchestration. Il s’agit de rendre les échecs de tâches identifiables et récupérables, et de permettre la validation et le retour arrière des changements. Il est recommandé de définir successivement les tâches et leurs critères d’achèvement, de choisir le mode d’exécution, de mettre en place l’environnement d’exécution et le stockage d’état, d’appliquer les limites de sécurité, d’évaluer des tâches représentatives, puis d’effectuer un déploiement progressif sur un faible volume en prévoyant une astreinte et un retour arrière.

Commencez par préciser les conditions de déclenchement, les entrées, les outils autorisés, le résultat métier final, la gestion des délais d’attente et les étapes nécessitant une confirmation humaine. Lorsqu’un processus fixe répond déjà aux besoins, il n’est pas nécessaire d’introduire plusieurs agents pour le rendre « agentique ». Pour choisir entre workflow et agent, consultez la réflexion d’Anthropic sur la conception des agents. Pour l’intégration aux interfaces système et les autorisations des outils, voir Comment connecter un agent IA aux systèmes existants de l’entreprise.

Choisir le mode de déploiement : arbitrer selon les contraintes

Le tableau ci-dessous sert à comparer les contraintes d’architecture et ne constitue pas une conclusion sur les performances ou les prix. Vérifiez les capacités, les quotas et les responsabilités d’exploitation des plateformes candidates dans leur documentation actuelle.

Lorsqu’une inférence est effectuée via l’API d’un modèle, l’objet du déploiement comprend généralement l’environnement d’exécution de l’application, les outils contrôlés et le service d’état. La décision d’auto-héberger l’environnement d’inférence doit être évaluée séparément selon les exigences en matière de latence, de périmètre des données, de disponibilité du modèle et d’exploitation. La documentation de Kubernetes Deployment peut servir de référence pour les mécanismes de mise à jour progressive et de retour à une révision précédente, sans pour autant signifier qu’un Agent doit être déployé sur Kubernetes.

Architecture de production minimale : relier les requêtes, l’exécution, l’état et l’observabilité

调用方 → 鉴权入口/请求校验 → 任务执行器（同步短任务或异步任务 ID）
      → Agent 运行逻辑 → 模型端点/受控工具 → 状态存储与结果核验
      → 日志、指标、追踪与告警

Pour les tâches courtes, il est possible d’attendre le résultat. Lorsque la durée dépasse le délai d’attente de l’appelant ou qu’une reprise entre processus est nécessaire, un identifiant de tâche peut être renvoyé afin que le client consulte l’état ou reçoive une notification d’achèvement. Il convient de définir les états des tâches, la sémantique de l’annulation, les limites de délai et les droits de lecture des résultats.

L’intégration aux systèmes existants n’est pas détaillée ici ; voir Comment connecter un AI Agent aux systèmes existants de l’entreprise. Les responsabilités liées à la permanence et à la collaboration technique peuvent être précisées à l’aide de Responsabilités de livraison technique et périmètre de collaboration du FDE ; les responsabilités concrètes doivent être définies dans le cadre du projet.

Préparer les artefacts de publication : rendre les changements reproductibles

Les modifications doivent inclure dans leur historique le code, les fichiers de verrouillage des dépendances, l’image d’exécution, la configuration de l’environnement, les modèles de prompts, ainsi que les versions de configuration du modèle et des outils. Les dépendances sont vérifiées lors de la compilation ; les environnements de développement, de test et de production sont séparés ; les identifiants sont injectés au moyen d’un mécanisme de configuration contrôlé et ne sont pas enregistrés dans le dépôt de code ni dans les journaux ordinaires. Les clés d’API des modèles, les identifiants des services d’outils et les identités métier sont gérés séparément.

La liste de contrôle de publication doit au minimum confirmer que :

• le point d’entrée d’exécution, le contrôle de santé, les limites de ressources et la gestion des signaux d’arrêt ont été vérifiés ;
• les versions des dépendances, le condensé de l’image et les modifications de configuration sont traçables ;
• les prompts, les contrats des outils, l’identifiant du modèle et les paramètres clés sont enregistrés avec leur version ;
• les échantillons de régression et les résultats d’évaluation peuvent être associés à la version publiée ;
• la version cible du retour arrière peut démarrer et lire le format d’état actuel, ou refuser explicitement de le traiter.

Reprise des tâches longues : un point de contrôle ne garantit pas une exécution exactement une fois

La capacité de reprise concerne trois niveaux : l’enregistrement de la tâche, l’état d’exécution et les effets de bord métier. Il faut savoir si la tâche est en file d’attente, en cours d’exécution ou en attente d’une intervention humaine ; jusqu’à quelles étapes l’exécution est arrivée ; et si les écritures dans les systèmes externes ont abouti. La simple sauvegarde du texte de la conversation ne suffit pas toujours à restaurer le contexte d’exécution, et la présence d’un point de contrôle ne permet pas non plus de prouver le résultat d’une opération d’écriture externe.

Prenons LangGraph comme exemple : la documentation distingue le checkpointer, qui conserve l’état d’exécution par thread, du store, qui partage les données entre les threads. La reprise après le redémarrage d’un processus nécessite un backend de persistance approprié, ainsi que la vérification de l’écriture, de la lecture, de l’isolation, de la conservation et de la récupération après incident ; un mécanisme de sauvegarde en mémoire ne peut pas servir de référence pour une persistance entre redémarrages. Voir la documentation LangGraph sur la persistance.

La stratégie de nouvelle tentative doit distinguer le délai d’expiration d’une tentative unique, les erreurs pouvant faire l’objet d’une nouvelle tentative et le traitement à appliquer une fois toutes les tentatives épuisées. Les outils qui produisent des effets de bord doivent utiliser des clés d’idempotence ou un mécanisme de déduplication. Avant une nouvelle tentative, commencez par vérifier le résultat métier : un délai d’expiration lors de l’appel ne signifie pas que l’écriture n’a pas eu lieu. En cas d’incertitude, transférez la vérification à un collaborateur ou exécutez une procédure de compensation ; les points de contrôle, les files d’attente et les nouvelles tentatives ne constituent pas, à eux seuls, une garantie exactly-once de bout en bout. Voir la documentation LangGraph sur la gestion des incidents.

Contrôles de sécurité : définir des conditions de blocage pour les actions à haut risque

Avant la mise en production, vérifiez au minimum les points suivants :

• Les documents externes, les pages web et les saisies utilisateur ne peuvent pas étendre eux-mêmes les autorisations des outils ;
• Le service d’outils vérifie à chaque appel l’identité, le périmètre des ressources et les paramètres ; les actions à fort impact nécessitent une confirmation humaine explicite ;
• Les identifiants sont isolés par environnement et peuvent être renouvelés ; les journaux sont réduits au minimum nécessaire selon leur niveau de sensibilité, sont désensibilisés et soumis à une durée de conservation définie ;
• Les enregistrements d’approbation associent la demande, l’opérateur, l’action prévue et le résultat métier final ;
• Les tests d’élévation de privilèges, d’injection de prompt, de soumission en double et d’exfiltration de données sensibles aboutissent tous au refus attendu.

Les ressources de l’OWASP sur les menaces et les mesures d’atténuation liées à l’IA agentique peuvent contribuer à établir une liste des menaces, mais ne constituent pas une preuve de la sécurité ou de la conformité de ce système.

Garde-fous d’évaluation : examiner à la fois le résultat et le processus

Ne considérez pas l’auto-déclaration d’un Agent affirmant que la tâche est « terminée » comme une validation. Pour chaque type de tâche, définissez des critères de réussite vérifiables dans l’environnement, tels que l’état de l’enregistrement cible, le format de sortie et les actions interdites ; conservez la trace d’exécution afin de localiser les échecs liés à la planification, aux appels d’outils ou à la vérification des résultats. Consultez à titre de référence la présentation d’Anthropic sur les méthodes d’évaluation des Agents.

Les échantillons doivent couvrir les saisies normales, les champs manquants, les informations contradictoires, les délais d’expiration des outils, les refus d’autorisation, les demandes en double et les contenus externes incitatifs. Les échantillons importants peuvent être exécutés plusieurs fois afin d’enregistrer la variabilité des résultats. Les critères de mise en production peuvent inclure le résultat de la tâche, les actions interdites, le traitement des anomalies, les exercices de reprise et le parcours de prise en charge humaine ; les seuils sont définis en fonction du risque métier, de la base de référence existante et des résultats des tests.

Surveillance : qualité, latence, reprise et coûts

Pour chaque indicateur, définissez la méthode de calcul, le point de collecte, les conditions d’alerte et la personne responsable :

La trace sert à localiser les écarts lors de l’exécution en plusieurs étapes, tandis que l’état métier final permet de confirmer l’achèvement de la tâche. Les champs désensibilisés des journaux, les périmètres d’accès et les durées de conservation doivent être définis pour chaque projet ; au début de la mise en production, il convient d’établir une référence d’observation, puis d’ajuster les seuils d’alerte en fonction des risques métier.

Déploiement progressif, retour arrière et gestion des tâches en cours

Avant la mise en production, effectuer une régression sur les combinaisons de code, de prompts, de configuration du modèle et de contrats des outils ; commencer par valider sur un trafic limité ou des tâches à faible risque, puis augmenter progressivement le volume. Définir des conditions d’arrêt, par exemple des anomalies dans les résultats métier, l’échec de tests de dépassement d’autorisation, ou des erreurs et des latences dépassant les limites définies par l’équipe.

En cas de panne, suspendre la réception de nouvelles tâches ou désactiver les outils à haut risque, dresser l’inventaire des tâches en cours d’exécution, en attente et terminées, puis vérifier les effets de bord externes avant de revenir à une version validée. Vérifier la compatibilité entre l’ancienne version et le format d’état existant ; les tâches qui ne peuvent pas être récupérées automatiquement doivent être transférées à une personne ou faire l’objet d’une compensation approuvée. Kubernetes Deployment peut servir de référence de déploiement lors de l’utilisation de Kubernetes ; le retour arrière de l’application n’annule pas automatiquement les écritures métier déjà effectuées.

Exercice pédagogique : valider le parcours de récupération par injection de pannes

La conception ci-dessous est un exercice pédagogique, et non un cas client ni un résultat mesuré. La tâche consiste à « générer un rapport, obtenir une confirmation humaine, puis enregistrer le résultat ». Pour chaque exécution, consigner le résultat attendu, le résultat réel et les éléments probants :

L’exercice doit vérifier la cohérence entre l’état métier, les enregistrements d’exécution et les résultats attendus, et définir clairement la personne responsable des tâches anormales ainsi que le parcours de traitement.

Liste de contrôle pour la validation de la mise en production

• Le périmètre des tâches, la définition de l’achèvement, les actions interdites et les points de confirmation humaine sont documentés.
• La forme du déploiement est adaptée à la durée des tâches, aux exigences de récupération et aux capacités d’exploitation de l’équipe.
• Les dépendances, les images, les prompts, la configuration du modèle et les contrats des outils sont traçables.
• L’état des tâches, la persistance et les effets de bord métier peuvent être vérifiés séparément ; les nouvelles tentatives sont protégées par l’idempotence.
• Les autorisations, l’injection de prompts, les journaux sensibles et les approbations humaines ont été testés.
• L’évaluation couvre les tâches représentatives, les échantillons anormaux, la vérification des résultats et les scénarios de récupération.
• La définition des indicateurs, les personnes responsables des alertes, les conditions d’arrêt du déploiement progressif et le processus d’astreinte sont confirmés.
• La version de retour arrière, les tâches en cours, la compatibilité des états et le parcours de compensation métier ont été testés.

Problèmes fréquents lors du déploiement

Q : Faut-il absolument utiliser Kubernetes ? R : Pas nécessairement. Si l’équipe dispose déjà d’une plateforme répondant aux exigences en matière de durée des tâches, de restauration de l’état, d’isolation réseau et d’exploitation, il n’est pas nécessaire d’ajouter la complexité d’un cluster pour un agent.

Q : Le déploiement d’un agent nécessite-t-il de construire son propre modèle ? R : Pas nécessairement. Lorsqu’une API de modèle est utilisée pour l’inférence, il suffit généralement de déployer le runtime de l’application, des outils contrôlés et des composants de gestion de l’état. L’inférence autohébergée doit faire l’objet d’une évaluation distincte concernant les limites des données, la latence, la disponibilité et les exigences d’exploitation.

Q : Les tâches sont-elles perdues après le redémarrage du service ? R : Cela dépend de la persistance des enregistrements de tâches et de l’état d’exécution, ainsi que de la validation du processus de restauration. La seule mémoire du processus ne permet pas une restauration après redémarrage. Il faut également vérifier que les écritures externes ont bien abouti afin d’éviter les exécutions en double.

Q : Comment éviter les écritures en double dues aux nouvelles tentatives ? R : Concevez des clés d’idempotence ou des enregistrements de déduplication pour les opérations métier, puis vérifiez l’état du système externe avant toute nouvelle tentative. En cas d’incertitude, suspendez les nouvelles tentatives automatiques, procédez à une vérification manuelle ou appliquez un processus de compensation.

Q : Quel seuil fixer pour le taux de réussite lors de la mise en production ? R : Il n’existe pas de valeur universelle. Définissez les contrôles de mise en production et les alertes en fonction des risques liés aux tâches, de la référence métier et des résultats des tests. Lors de la recette, vérifiez également les actions interdites, la reprise en main humaine, la restauration et les résultats métier.