Pratiques exemplaires d’orchestration d’agents d’IA : gérer les défaillances, les approbations et les nouvelles tentatives

Ce guide explique le fonctionnement de l’orchestration d’agents d’IA, compare les architectures centralisées, décentralisées et hiérarchiques, et présente sept pratiques exemplaires pour gérer les défaillances, les approbations et les nouvelles tentatives en production.

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

Faire travailler plusieurs agents sur le même projet semble extrêmement efficace. L’un planifie le travail, un autre s’occupe de la conception et un troisième écrit le code. Ça fonctionne… jusqu’à ce que ça ne fonctionne plus. Et les défaillances surviennent plus souvent qu’on le voudrait.

Prévenir ces défaillances exige une ingénierie rigoureuse des flux de travail. Voyons donc ce qui rend les flux de travail orchestrés peu fiables et explorons les pratiques exemplaires d’orchestration qui assurent la fiabilité en production.

Qu’est-ce que l’orchestration d’agents IA?

L’orchestration d’agents IA coordonne plusieurs agents IA, modèles et outils pour accomplir une tâche en plusieurs étapes. Mais quelqu’un — ou quelque chose — doit tout de même décider quel agent s’exécute en premier, quelles informations il reçoit et ce qui se passe une fois qu’il a terminé. C’est le rôle de l’orchestrateur — un agent IA qui agit comme gestionnaire, ou une couche d’exécution contrôlée par logiciel.

En termes simples, une couche d’orchestration décompose un objectif en tâches plus petites, suit les dépendances, délègue l’exécution aux bons agents, gère le contexte partagé et regroupe les résultats.

Comment fonctionne l’orchestration d’agents IA : au cœur du moteur d’exécution

Voyons ce qui se passe une fois que vous confiez une tâche à un orchestrateur.

Prenons un exemple tiré de l’atelier Computer de Perplexity : la création d’un tableau de bord de renseignements sur les comptes à partir d’informations provenant de Salesforce, de Snowflake, des courriels, du calendrier et des nouvelles récentes.

  1. Comprendre l’objectif et planifier le travail. L’orchestrateur part du résultat demandé et le décompose en tâches aux dépendances explicites. Dans notre exemple de tableau de bord, il s’agit de recueillir des informations de différentes sources et de les transformer en un livrable fini. Le planificateur détermine quelles étapes dépendent d’autres étapes et lesquelles peuvent s’exécuter de façon indépendante.
  2. Acheminer les tâches vers les agents appropriés. L’orchestrateur repère les tâches dont les dépendances sont satisfaites et délègue le travail à des agents ou à des modèles spécialisés. Les tâches dépendantes attendent leurs prérequis. Perplexity Computer utilise plusieurs modèles de pointe et achemine les différentes parties du flux de travail vers les systèmes les mieux adaptés à ces tâches. Cela permet aussi d’exécuter en parallèle le travail indépendant.
  3. Exécuter les appels d’outils dans des environnements contrôlés. Les agents interagissent avec leur environnement au moyen d’outils, comme la recherche Web, les API, les applications connectées, les opérations sur les fichiers ou l’exécution de code. La couche d’exécution effectue ces actions et renvoie les résultats aux agents.
  4. Transmettre les résultats et le contexte d’un agent à l’autre. Lorsqu’un agent termine sa tâche, l’agent suivant en aval a besoin du résultat pertinent pour continuer. Un registre de transfert pourrait contenir un identifiant de tâche, une référence de résultat, une version de schéma et des métadonnées sur la source. L’orchestrateur coordonne ces transferts tout en conservant le contexte nécessaire aux étapes suivantes. Fait important, les agents n’ont pas à conserver l’historique complet du travail de tous les autres agents dans leur propre fenêtre de contexte.
  5. Consigner l’état d’exécution séparément du contexte des agents. À mesure que les agents commencent, terminent ou échouent des tâches, le moteur d’exécution met à jour un registre persistant du flux de travail contenant l’état des tâches, les tentatives d’exécution, les références des résultats et le travail restant. Ce registre permet à l’orchestrateur de suivre la progression et de reprendre après une interruption sans dépendre d’un LLM pour reconstituer le flux de travail à partir de l’historique de conversation.
  6. Valider les résultats et décider de la suite. Lorsqu’une tâche se termine, la couche d’orchestration vérifie si son résultat respecte le contrat prévu et si les dépendances de la tâche suivante sont satisfaites. Si un problème est détecté, le flux de travail peut revenir à une étape antérieure pour correction ou être mis en pause. Sinon, il progresse vers son achèvement.

Derrière ce qui semble être une simple orchestration d’agents IA se cachent de nombreux rouages. La façon dont vous organisez la coordination des agents détermine le degré de contrôle dont vous disposez sur l’exécution. Et bien sûr, toute cette coordination ajoute une charge supplémentaire. Elle n’en vaut donc pas toujours la peine.

Quand faut-il utiliser l’orchestration d’agents IA?

Envisagez l’orchestration multiagent lorsque différentes parties de la tâche exigent des expertises distinctes, que du travail indépendant peut s’exécuter en parallèle ou que vous ne pouvez pas déterminer l’étape suivante à l’avance.

L’orchestration est donc utile dans trois scénarios :

  • Les tâches exigent différentes spécialisations. Un projet de programmation, par exemple, pourrait tirer avantage d’agents distincts pour la planification, la conception, le développement et la révision.
  • Des tâches indépendantes peuvent s’exécuter en parallèle. Au lieu qu’un seul agent accomplisse tout de manière séquentielle, plusieurs agents peuvent travailler simultanément et renvoyer leurs résultats à un orchestrateur.
  • Le problème est ouvert. Les agents pourraient devoir explorer différentes approches, prendre des décisions et collaborer plutôt que de suivre une séquence prédéfinie.

En dehors de ces cas, l’orchestration n’est qu’une tendance coûteuse. Plus d’agents signifie aussi plus de coordination et des coûts en jetons potentiellement plus élevés.

« Je commence habituellement par l’option la plus simple et je construis à partir de là. Si on connaît les étapes et qu’elles sont reproductibles, il s’agit probablement d’un flux de travail. Je ne vois de raison d’introduire plusieurs agents que lorsqu’ils ont des responsabilités, des autorisations ou des utilisateurs différents », explique Josh Spilker, responsable du marketing de recherche chez AirOps.

Même dans ce cas, mettez en balance les avantages et les appels de modèle supplémentaires, les transferts, la latence et les points de défaillance.

Architectures d’orchestration d’agents IA et leurs compromis

Il existe trois façons courantes de structurer la coordination des agents : l’orchestration centralisée, décentralisée et hiérarchique. Le choix de la bonne architecture se résume à une question : qui contrôle le travail, et comment les agents se coordonnent-ils entre eux?

Orchestration centralisée

Dans l’orchestration centralisée, un seul orchestrateur gère le processus. Il décompose la tâche, délègue le travail à des agents spécialisés, suit leur progression et regroupe leurs résultats.

Le compromis : la coordination centralisée facilite le suivi de l’exécution et l’application de règles communes à un point de contrôle unique. Toutefois, l’orchestrateur peut devenir un goulot d’étranglement, et sa défaillance peut interrompre l’ensemble du flux de travail, à moins que le système permette la reprise.

Orchestration décentralisée

Dans l’orchestration décentralisée, les agents se coordonnent plus directement au lieu de compter sur un seul gestionnaire pour prendre chaque décision. Ils peuvent échanger des messages, lire un état partagé et déterminer de façon indépendante leurs prochaines étapes.

Le compromis : les agents peuvent fonctionner sans attendre un planificateur central, ce qui rend cette approche utile pour le travail exploratoire et les contributions indépendantes. Mais la coordination se complique lorsque les agents sont en désaccord, mettent à jour des informations partagées ou doivent parvenir à un résultat cohérent.

Orchestration hiérarchique

L’orchestration hiérarchique étend l’approche du gestionnaire à plusieurs niveaux. Un orchestrateur de niveau supérieur délègue des responsabilités à des orchestrateurs subordonnés, qui coordonnent leurs propres groupes d’agents spécialisés.

Pensez à un flux de travail d’entreprise impliquant les équipes des ventes, des finances et des affaires juridiques. Un orchestrateur de niveau supérieur pourrait déléguer chaque chantier à un coordonnateur propre à un domaine. Ces coordonnateurs géreraient ensuite leurs propres agents spécialisés et feraient état de résultats consolidés.

Cette structure peut être utile lorsque les flux de travail sont trop vastes pour qu’un seul orchestrateur puisse les gérer efficacement.

Le compromis : les hiérarchies permettent aux équipes de répartir les responsabilités de coordination et, potentiellement, de gérer les défaillances au sein de chaque branche. Toutefois, elles introduisent des transferts supplémentaires, une gestion de l’état plus complexe et une charge opérationnelle accrue. La reprise locale dépend aussi de la façon dont les points de contrôle et l’état d’exécution sont mis en œuvre.

Comparaison de ces architectures :

Critères

Centralisée

Décentralisée

Hiérarchique

Responsabilité de l’exécution

Un seul orchestrateur contrôle la délégation

Les agents se coordonnent entre pairs ou au moyen d’un état partagé

La responsabilité est répartie entre les niveaux d’orchestration

Cohérence de l’état

Plus facile à coordonner grâce à un point de contrôle unique

Exige une synchronisation explicite et une gestion des conflits

Exige une coordination au sein des branches et entre elles

Isolation des défaillances

Le contrôleur central peut devenir une dépendance critique

Chaque agent peut échouer de façon indépendante, mais l’infrastructure partagée demeure critique

Les défaillances peuvent être circonscrites aux branches si le système est conçu pour la reprise

Application des politiques

Les contrôles communs peuvent être appliqués de façon centralisée

Les politiques doivent être appliquées uniformément à tous les participants

Les contrôles peuvent être appliqués à l’échelle globale et à celle des domaines

Complexité opérationnelle

Généralement plus faible

Complexité de coordination plus élevée

Complexité accrue due aux multiples couches d’orchestration

Exécution séquentielle, parallèle et par transfert

Il reste une autre distinction à bien comprendre. L’architecture détermine qui coordonne les agents. Le schéma d’exécution détermine comment leurs tâches progressent.

Voici trois schémas d’exécution :

  • Flux de travail séquentiels : Les agents travaillent dans un ordre prédéfini, le résultat d’un agent devenant l’entrée d’un autre.
  • Exécution parallèle : Des agents indépendants travaillent simultanément.
  • Exécution par transfert : Le contrôle passe d’un agent spécialisé à l’autre à mesure que la tâche progresse. C’est utile lorsqu’un autre agent est mieux outillé pour gérer l’étape suivante, bien que chaque transfert doive préserver l’information nécessaire pour poursuivre.

Ces schémas ne s’excluent pas mutuellement et ne correspondent pas un à un aux architectures d’orchestration. L’objectif est de choisir la structure la plus simple qui prend en charge les dépendances de votre flux de travail, ses exigences de coordination et une charge opérationnelle acceptable.

Défaillances courantes de l’orchestration d’agents d’IA

Tout peut mal tourner dans une orchestration, des simples oublis aux blocages complexes. Parfois, un agent peut même sembler faire correctement son travail alors que l’ensemble du flux de travail échoue. En nous appuyant sur l’expérience de praticiens, nous avons recensé certaines des erreurs courantes à l’origine de flux de travail orchestrés peu fiables — restez à l’affût :

  • Transferts entre agents avec perte d’information. Un orchestrateur transmet un plan résumé à un agent spécialisé, mais le résumé omet des contraintes, des dépendances ou des détails de mise en œuvre.
  • Agrégation (fan-in) prématurée. Un agent en aval commence à agréger les résultats avant que toutes les tâches en amont soient terminées.
  • Mises à jour non déterministes de l’état partagé. Des agents parallèles écrivent dans les mêmes clés d’état sans sémantique de fusion bien définie. Selon la façon dont le cadriciel gère les mises à jour, cela peut entraîner des écritures perdues, des données dupliquées, des résultats dépendant de l’ordre ou des modifications contradictoires.
  • Divergence entre points de contrôle et effets de bord. Une tâche effectue une opération externe, mais sa réussite n’est pas enregistrée de façon durable avant la défaillance du processus de traitement. Lors de la reprise, l’orchestrateur voit une tâche inachevée et la réexécute.
  • Situations de concurrence lors de la reprise après approbation humaine. Mettre en pause puis reprendre l’exécution entraîne ses propres problèmes de synchronisation.
  • Boucles de délégation et amplification des nouvelles tentatives. Les agents se renvoient le travail à répétition parce que leurs responsabilités se chevauchent, que leurs dépendances sont circulaires ou que les conditions d’achèvement sont ambiguës.
  • Contrôles au niveau des instructions confondus avec la sécurité d’exécution. Un orchestrateur peut demander aux agents de ne pas accéder à certaines ressources ou de ne pas effectuer d’actions sensibles, mais les instructions données au modèle n’imposent pas les permissions du système d’exploitation, les restrictions réseau ni les limites d’autorisation. Les recherches en ingénierie de la sécurité de Perplexity montrent pourquoi des agents peuvent franchir des limites de sécurité tout en poursuivant des objectifs légitimes, même sans instructions malveillantes

Remarquez à quel point ces défaillances diffèrent. Une transition prématurée du planificateur ou une écriture externe ambiguë peuvent toutes deux produire un résultat incorrect, mais elles prennent naissance dans des parties différentes du cycle de vie de l’exécution. C’est pourquoi une orchestration fiable exige plus que d’améliorer les invites ou d’ajouter des nouvelles tentatives.

7 pratiques exemplaires d’orchestration d’agents d’IA pour la fiabilité en production

1. Définir des contrats de tâche explicites, des critères d’acceptation et des conditions d’arrêt

Des objectifs vagues et une définition de terminé imprécise mènent souvent à des résultats décevants de la part des agents. La solution est un contrat d’invite (un énoncé des travaux pour un agent) : convenez de l’objectif, des contraintes, du format de sortie et des conditions d’échec avant le début de l’exécution.

Par exemple, voici comment vous pourriez définir un contrat pour un agent chargé de corriger un test d’intégration qui échoue par intermittence :

  • Objectif : Déterminer et corriger la cause d’un test d’intégration instable de l’API de paiement.
  • Entrées : Code source du test, journaux d’échec de la CI, commits récents et code d’application pertinent.
  • Contraintes : Ne pas désactiver de tests, assouplir les assertions ni modifier un comportement de l’application sans rapport.
  • Résultat attendu : Un correctif de code, une explication de la cause profonde et les résultats de l’exécution des tests.
  • Critères d’acceptation : Le test qui échouait réussit lors de 10 exécutions consécutives, et la suite de tests de régression pertinente réussit.
  • Conditions d’échec : La cause profonde ne peut pas être établie, le correctif introduit des régressions ou l’environnement de test requis n’est pas disponible.

Mais il y a un autre élément important : quand l’agent doit-il s’arrêter?

Un agent ne devrait pas continuer à itérer indéfiniment parce qu’il n’a pas produit de résultat satisfaisant. Définissez ce qui constitue un achèvement réussi, quand retourner une tâche partiellement terminée et quand s’arrêter parce qu’une exigence ne peut pas être satisfaite. Fixez une profondeur de délégation maximale et des limites d’itérations ou des budgets d’exécution afin que les tâches non résolues ne deviennent pas des boucles sans fin.

Revenons à notre exemple de CI. Vous pourriez définir les conditions d’arrêt suivantes :

  • Réussite : Le correctif réussit 10 exécutions de test consécutives ainsi que la suite de tests de régression pertinente.
  • Limite d’itérations : L’agent ne peut pas tenter plus de deux correctifs candidats.
  • Budget d’exécution : L’agent doit s’arrêter après 60 minutes, même si le problème n’est toujours pas résolu.
  • Limite de délégation : L’agent peut déléguer du travail à un seul agent spécialisé, sans autre délégation à des sous-agents.
  • Achèvement partiel : Si les deux tentatives échouent ou que le délai expire, l’agent retourne ses constatations, les modifications tentées et les résultats des tests.
  • Exécution bloquée : Si l’environnement de test n’est pas disponible, l’agent s’arrête et signale l’obstacle au lieu de prétendre avoir réussi.

2. Garder les orchestrateurs légers et imposer des transferts structurés

Il arrive que les développeurs confient trop de responsabilités à un orchestrateur : au lieu de coordonner des agents spécialisés, il se met à écrire du code, à déboguer ou à effectuer lui-même des révisions détaillées. Cela crée un goulot d’étranglement : l’orchestrateur consacre son budget de contexte aux détails de mise en œuvre, retarde la délégation et brouille la responsabilité des résultats.

Laissez donc les orchestrateurs faire leur travail et imposez des transferts qui renvoient à des artefacts concrets : la tâche d’origine, les entrées pertinentes, les artefacts de sortie, l’état d’exécution et tout problème non résolu.

Prenons cet exemple : status: completed renvoie au travail assigné à l’agent, et non à l’ensemble du flux de travail. Comme les tests sont toujours à l’état pending, l’orchestrateur ne devrait pas approuver le résultat final.

json
{ "task_id": "fix-42", "status": "completed", "artifact_ref": "patch-17", "test_status": "pending", "blockers": [] }

3. Rendre persistant l’état du flux de travail et maîtriser la croissance du contexte

L’historique de conversation d’un agent n’est pas un registre fiable de la progression du flux de travail. Lorsque sa fenêtre de contexte se remplit, la compaction automatique peut faire disparaître des détails importants. Et si un processus de traitement plante, l’agent suivant doit savoir quelles étapes ont réellement été effectuées.

Par exemple, si l’agent de programmation génère un correctif puis plante, le processus de traitement suivant devrait récupérer l’artefact enregistré et poursuivre à partir de l’état du flux de travail consigné. Mais si l’agent a aussi déclenché une exécution CI externe, l’orchestrateur doit rapprocher cette exécution séparément avant de répéter l’action

Gardez donc l’état d’exécution séparé du contexte de travail de l’agent. Enregistrez les états des tâches, les tentatives d’exécution, les étapes terminées et les références aux artefacts dans un stockage durable. Parallèlement, ne chargez que les instructions, les entrées et les résultats pertinents pour la tâche en cours de l’agent, au lieu d’entasser tout l’historique d’exécution dans sa fenêtre de contexte.

4. Concevoir des nouvelles tentatives tenant compte des défaillances et une exécution d’outils récupérable

Supposons que votre agent CI déclenche une exécution de tests, mais que la requête API expire. L’exécution des tests n’a-t-elle pas pu démarrer, ou le service CI l’a-t-il mise en file d’attente avant de perdre la réponse?

Une expiration ne signifie pas nécessairement qu’une opération a échoué. C’est pourquoi vous devez distinguer les types d’erreurs avant de décider de la suite :

  • Erreurs transitoires (429, 503) : Réessayez avec un délai d’attente exponentiel borné et une variation aléatoire (jitter), en respectant Retry-After lorsqu’il est fourni.
  • Erreurs de validation ou d’autorisation (400, 403) : Arrêtez ou corrigez le problème sous-jacent plutôt que de répéter la même requête.
  • Résultats ambigus (expiration après une écriture possible) : Vérifiez si l’opération a réussi avant de la tenter de nouveau.

Remarque : Même les erreurs qui permettent une nouvelle tentative nécessitent des limites. Définissez un délai d’expiration pour chaque appel d’outil, plafonnez le nombre de nouvelles tentatives et leur durée totale, et imposez une échéance globale au flux de travail afin que les agents imbriqués ne puissent pas relancer sans cesse la même opération. Si une dépendance échoue à répétition, utilisez un disjoncteur (circuit breaker) pour suspendre temporairement les requêtes.

Pour les opérations ayant des effets de bord externes, attribuez une clé d’idempotence stable à chaque action logique et réutilisez-la d’une tentative à l’autre. Si l’API prend en charge la déduplication côté serveur, elle peut reconnaître les requêtes répétées sans effectuer l’action deux fois. Sinon, interrogez le système externe à l’aide d’un identifiant de corrélation ou d’une autre référence faisant autorité.

Lorsque vous ne pouvez pas établir ce qui s’est passé, arrêtez-vous et faites remonter le problème.

Voici un exemple de logique de nouvelles tentatives pour notre agent CI, exprimé en pseudocode :

python
op_id = get_or_create_operation_id( task_id=task_id, patch_id=patch_id, action="start_ci_run" ) try: return ci.start_run(commit, request_id=op_id) except TimeoutError: run = ci.find_by_request_id(op_id) if run: return run if ci.supports_idempotency: return bounded_retry( lambda: ci.start_run(commit, request_id=op_id) ) raise NeedsReconciliation(op_id)

Remarque sur le code : L’exemple suppose que l’API CI permet de rechercher des exécutions par identifiant de requête. Le request_id n’empêche les doublons que si le fournisseur garantit explicitement l’idempotence. bounded_retry() est du pseudocode à titre d’illustration. En production, les nouvelles tentatives devraient être limitées à la fois par un budget de tentatives par opération (nombre maximal de tentatives ou temps écoulé) et par l’échéance globale du flux de travail.

Pour les flux de travail plus longs qui couvrent plusieurs services, envisagez le patron Saga pour coordonner des actions compensatoires lorsque des étapes ultérieures échouent. Rappelez-vous simplement que la compensation n’équivaut pas toujours à une annulation complète. Vous pouvez annuler une mise à jour de base de données, mais vous ne pouvez pas « désenvoyer » un courriel.

5. Acheminer et paralléliser le travail avec des budgets de ressources explicites

Il y a deux choses à équilibrer ici : la capacité de modèle dont chaque tâche a besoin et le nombre de tâches que vous pouvez exécuter simultanément. Si vous vous trompez sur l’un ou l’autre, vous risquez que des agents se disputent des quotas d’API partagés ou qu’ils dépendent uniquement de modèles de raisonnement coûteux.

Pour la sélection du modèle, adaptez la capacité du modèle et l’effort de raisonnement à la complexité de la tâche — c’est simple, mais souvent négligé. Notez que vous pouvez soit configurer des règles d’acheminement et évaluer les modèles vous-même, soit utiliser une plateforme d’orchestration qui gère la sélection du modèle pour vous.

Par exemple, la fonctionnalité Effort Mode de Perplexity Computer vous permet de choisir le niveau d’effort que mérite une tâche sans sélectionner manuellement de modèle. Choisissez Light, Standard, High ou Ultra, et Perplexity sélectionne automatiquement le modèle orchestrateur et son niveau de raisonnement. Cet orchestrateur délègue ensuite des sous-tâches à des agents de soutien, qui peuvent utiliser des modèles de différents fournisseurs.

Perplexity évalue les configurations de modèles en fonction de la qualité et du coût, en privilégiant les options moins coûteuses qui offrent des résultats comparables. Vous pouvez aussi utiliser les contrôles Custom si vous préférez choisir vous-même le modèle et le niveau de raisonnement.

Pour le parallélisme, la limite devrait découler de votre infrastructure et de vos dépendances externes. Validez les limites de débit de requêtes et de jetons des API partagées, puis soumettez votre flux de travail à des tests de charge avec une concurrence croissante. Observez si le débit s’améliore ou si les requêtes commencent à s’accumuler en file d’attente, à ralentir ou à renvoyer des erreurs 429.

Pour que la consommation de ressources reste prévisible, imposez des limites de ressources et des contrôles de planification :

  • Contrôlez la concurrence et le débit des requêtes : Plafonnez les appels en cours par service et mettez le travail excédentaire en file d’attente. N’oubliez pas qu’un plafond de concurrence, à lui seul, n’imposera pas de limites de requêtes par minute ni de jetons par minute.
  • Suivez les budgets de jetons et de coûts : Tenez compte de l’utilisation dans l’ensemble du flux de travail, y compris les sous-agents, et cessez de lancer de nouveaux travaux lorsque le budget restant est insuffisant.
  • Imposez des échéances d’exécution : Fixez des limites de temps pour les tâches et le flux de travail, et propagez l’annulation aux agents en cours d’exécution lorsque c’est pris en charge.
  • Respectez les dépendances : Ne lancez les tâches en aval que lorsque leurs entrées requises sont disponibles, plutôt que de lancer tous les agents simultanément.

6. Imposer des approbations et isoler l’exécution des agents

Ne demandez jamais au modèle de décider si ses propres actions sont sûres. Accordez plutôt aux agents des permissions selon le principe du moindre privilège et appliquez des règles d’approbation fondées sur le risque dans le code de l’application. Si des agents exécutent du code, isolez cette exécution de votre environnement hôte et restreignez l’accès aux fichiers, aux réseaux et aux identifiants. Cela limite les dégâts si l’agent commet une erreur ou exécute du code dangereux.

« Je suis sceptique face aux systèmes multiagents trop compliqués, surtout lorsque des agents révisent et approuvent le travail les uns des autres. Vous pouvez vous retrouver avec plusieurs agents qui se transmettent en toute confiance la même erreur, sans que personne ne la repère réellement », prévient Spilker.

Pour les actions qui nécessitent une approbation humaine, mettez l’exécution en pause et enregistrez l’opération exacte proposée :

  • ses paramètres
  • sa ressource cible
  • son commit ou sa version d’état
  • la décision du réviseur

Définissez aussi ce qui se passe si l’approbation est rejetée, expire ou doit être transmise à un niveau supérieur. C’est essentiel pour les cadriciels qui permettent la reprise, car reprendre un nœud interrompu réexécute le code depuis le début de ce nœud. Tout effet de bord survenu avant l’interruption peut se reproduire.

Ainsi, si l’approbation est rejetée ou expire, la demande est fermée. Si le commit cible, les paramètres ou les permissions changent avant l’exécution, invalidez l’approbation et demandez-en une nouvelle.

Spilker n’adhère pas non plus à l’idée selon laquelle des agents entièrement autonomes, de bout en bout, constitueraient l’objectif. « Pour moi, la meilleure approche consiste à créer quelques agents ciblés, avec des responsabilités claires, des permissions définies et une révision humaine aux bons moments. Vous gagnez quand même en efficacité sans renoncer au plein contrôle », conclut-il.

7. Vérifier les résultats de façon indépendante et tester le comportement de reprise

Vous est-il déjà arrivé qu’un agent signale Réussite alors qu’il avait en fait échoué? Agaçant, voire exaspérant, et la correction n’est pas rapide, car le message final de l’agent ne vous dira pas forcément où les choses ont mal tourné.

Pour enquêter, retracez ce qui s’est passé pendant l’exécution et vérifiez les résultats de façon indépendante. Prenons donc le temps d’isoler et de résoudre le problème.

Retracer le flux de travail pour déterminer ce qui a mal tourné

Avant de déboguer les invites d’un agent, capturez l’ensemble du chemin d’exécution. Il vous faut une trace qui relie les invocations d’agents, les appels d’outils, les erreurs et les nouvelles tentatives au sein d’une même exécution du flux de travail.

Les conventions sémantiques GenAI d’OpenTelemetry offrent une façon normalisée de décrire ces opérations. Par exemple, invoke_workflow désigne l’exécution d’un flux de travail, invoke_agent l’invocation d’un agent et execute_tool un appel d’outil. Chaque opération peut être enregistrée sous forme de span avec sa durée, son statut et les métadonnées pertinentes.

Cette étape vous donne une trace du chemin d’exécution, ce qui vous permet de repérer l’endroit où un agent a eu un pépin.

plaintext
invoke_agent generate_patch OK execute_tool start_ci_run OK run_id=9812 execute_tool get_ci_result TIMEOUT agent_response: "Success"

Exemple de trace d’exécution.

Examiner les résultats de façon indépendante

Utilisez des vérifications programmatiques dans la mesure du possible. Validez les résultats par rapport à des schémas JSON, exécutez des tests unitaires et d’intégration, vérifiez que les artefacts requis existent et interrogez les systèmes externes pour confirmer que les actions ont réellement réussi.

Pour les résultats qui exigent un jugement subjectif — et qui ne peuvent donc pas être évalués au moyen de vérifications programmatiques —, faites appel à un agent réviseur indépendant. Une approche possible est une boucle exécutant–réviseur–résolveur, dans laquelle un agent produit un artefact, un réviseur au contexte vierge relève les problèmes et un résolveur les corrige avant que la validation soit relancée.

Vous devez tout de même valider les constatations du réviseur lorsque c’est possible et, si vous utilisez des évaluateurs basés sur des LLM pour des évaluations répétées, calibrer leurs jugements à l’aide d’exemples révisés par des humains.

Injecter des défaillances pour tester la reprise

Jusqu’ici, vous avez retracé ce que les agents ont exécuté et vérifié si leurs résultats étaient corrects. Mais que se passe-t-il lorsqu’un worker plante au milieu d’une tâche ou qu’une API expire après avoir accepté une requête? Étonnamment, votre flux de travail peut se comporter parfaitement bien dans des conditions normales, mais échouer lors de la reprise.

Pour le vérifier, injectez délibérément des pannes dans un environnement de test :

  • Simulez des expirations de délai d’API
  • Faites planter des workers entre les écritures externes et les points de contrôle
  • Renvoyez des résultats d’outils mal formés
  • Faites expirer des approbations

Après chaque test, examinez la trace d’exécution pour voir quelles étapes ont été exécutées, où le flux de travail a repris et si des actions ont été répétées ou ignorées. Examinez ensuite les résultats réels.

Supposons que votre agent de CI envoie une requête pour lancer une exécution de tests, mais que la réponse de l’API expire. L’agent réessaie, reçoit une réponse positive et signale Success. Tout semble correct jusqu’à ce que vous consultiez le service de CI et découvriez que deux exécutions de tests ont été créées au lieu d’une.

C’est pourquoi vous devez vérifier à la fois l’état enregistré du flux de travail et les modifications réelles dans les systèmes externes. Un test de reprise ne devrait réussir que lorsque le flux de travail atteint l’état attendu sans effets secondaires indésirables.

Ajoutez les défaillances que vous découvrez à vos tests de régression afin que les modifications futures ne les réintroduisent pas.

Au bout du compte, la réussite signifie que le flux de travail a réussi les vérifications requises et que ses résultats externes ont été vérifiés.

FAQ sur l’orchestration d’agents d’IA

Pourquoi les agents d’IA cloisonnés échouent-ils à l’échelle de l’entreprise?

Les agents cloisonnés peuvent accomplir correctement leurs tâches individuelles, mais produire ensemble des résultats incohérents. Imaginez un agent des ventes qui récupère les conditions d’un client à 10 h, un agent de tarification qui calcule une soumission à partir de prix mis à jour à 10 h 05 et un agent juridique qui vérifie un contrat modifié à 10 h 07. Chaque agent travaille avec un instantané différent de l’entreprise, de sorte que leurs résultats peuvent se contredire.

Le problème s’accentue à l’échelle de l’entreprise, car les agents interagissent avec plusieurs systèmes qui se mettent à jour indépendamment, fonctionnent avec des autorisations différentes et ne partagent pas nécessairement le contexte ou l’état d’exécution.

Comment éviter les boucles infinies de nouvelles tentatives dans les agents d’IA?

Fixez des limites à plusieurs niveaux : nombre maximal de nouvelles tentatives d’appel d’outil, nombre maximal d’itérations de l’agent, profondeur de délégation et échéance globale du flux de travail. Classez les défaillances avant de réessayer. Pour les réponses 429 transitoires, respectez Retry-After lorsqu’il est fourni. Sinon, utilisez une temporisation exponentielle bornée avec gigue.

Cessez de relancer des requêtes inchangées après des erreurs de validation ou d’autorisation. Si un service en aval échoue à répétition, un disjoncteur (circuit breaker) peut empêcher les agents de générer une charge supplémentaire.

Comment reprendre un flux de travail d’agent d’IA après un plantage?

Le mécanisme de reprise dépend de votre environnement d’exécution. Avec LangGraph, un checkpointer persistant comme PostgresSaver stocke l’état du graphe sous un thread_id, ce qui permet de poursuivre l’exécution à partir de l’état persistant. Avec Temporal, un autre worker peut reconstruire un flux de travail en rejouant son historique d’événements. Pendant la relecture, il réutilise les résultats d’activités enregistrés précédemment.

Si l’application est redéployée alors que des flux de travail sont encore en cours, l’état enregistré et les historiques d’exécution risquent de ne plus être compatibles. Temporal règle ce problème grâce à Worker Versioning et à l’application de correctifs aux flux de travail. Pour les systèmes basés sur des points de contrôle, planifiez les migrations de schéma et testez la reprise avec les états enregistrés existants avant de déployer des modifications incompatibles.

Comment tester la fiabilité de l’orchestration d’agents d’IA?

Exécutez plusieurs fois les mêmes tâches représentatives et distinguez pass@k (au moins une des k tentatives réussit) de pass^k (les k tentatives réussissent toutes)

Mesurez les résultats par catégorie de tâche et par version du flux de travail plutôt que de vous fier à un seul taux de réussite global. Suivez la réussite à la première tentative, la cohérence entre les exécutions répétées, la latence p95, le coût par tâche accomplie et la proportion de tâches nécessitant une intervention humaine. Indiquez la taille des échantillons et les intervalles d’incertitude des taux de réussite.