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

Faire travailler plusieurs agents sur un même projet semble extrêmement efficace. L’un planifie le travail, un autre s’occupe du design et un troisième écrit le code. Cela fonctionne, jusqu’au moment où cela ne fonctionne plus. Et les échecs surviennent plus souvent qu’on ne le voudrait.

Pour éviter ces échecs, il faut une ingénierie rigoureuse des flux de travail. Examinons donc ce qui rend les flux de travail orchestrés peu fiables et explorons les bonnes pratiques d’orchestration pour garantir la fiabilité en production.

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

L’orchestration d’agents IA coordonne plusieurs agents, modèles et outils d’IA 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 fait office de gestionnaire, ou une couche d’exécution piloté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 agents appropriés, gère le contexte partagé et rassemble les résultats.

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

Agrandir

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

Prenons un exemple tiré de l’atelier Computer de Perplexity : la création d’un tableau de bord de veille sur les comptes à partir d’informations issues de Salesforce, de Snowflake, des e-mails, du calendrier et de l’actualité récente.

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, cela implique de collecter des informations provenant de différentes sources et de les transformer en un livrable final. Le planificateur détermine quelles étapes dépendent d’autres étapes et lesquelles peuvent s’exécuter indépendamment.
2. Acheminer les tâches vers les agents appropriés. L’orchestrateur identifie les tâches dont les dépendances sont satisfaites et délègue le travail à des agents ou modèles spécialisés. Les tâches dépendantes attendent que leurs prérequis soient remplis. Perplexity Computer utilise plusieurs modèles de pointe et achemine les différentes parties du flux de travail vers les systèmes 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 par le biais 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 entre agents. Lorsqu’un agent termine sa tâche, l’agent suivant en aval a besoin du résultat pertinent pour poursuivre. Un enregistrement de transfert peut 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. Point important : les agents n’ont pas à conserver dans leur propre fenêtre de contexte tout l’historique du travail de chacun des autres agents.
5. Enregistrer l’état d’exécution séparément du contexte des agents. À mesure que les agents démarrent des tâches, les terminent ou y échouent, le moteur d’exécution met à jour un enregistrement persistant du flux de travail avec le statut des tâches, les tentatives d’exécution, les références des résultats et le travail restant. Cet enregistrement 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 renvoie un résultat, la couche d’orchestration vérifie si sa sortie respecte le contrat attendu et si les dépendances de la tâche suivante sont remplies. 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 ressemble à 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 engendre une surcharge. Elle n’en vaut donc pas toujours la peine.

Quand utiliser l’orchestration d’agents IA ?

Envisagez l’orchestration multi-agents lorsque différentes parties de la tâche nécessitent des expertises distinctes, que des travaux indépendants peuvent 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 cas de figure :

• Les tâches requièrent différentes spécialisations. Un projet de programmation, par exemple, peut tirer parti d’agents distincts pour la planification, le design, le développement et la revue.
• 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 peuvent avoir besoin d’explorer différentes approches, de prendre des décisions et de 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 tokens potentiellement plus élevés.

« Je commence généralement par l’option la plus simple et je construis à partir de là. Si nous connaissons 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 sur les moteurs de recherche chez AirOps.

Même dans ce cas, mettez en balance les avantages et le surcroît d’appels aux modèles, de transferts, de latence et de 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 rassemble leurs résultats.

Agrandir

Le compromis : La coordination centralisée facilite le suivi de l’exécution et l’application de règles communes à partir d’un point de contrôle unique. Cependant, l’orchestrateur peut devenir un goulot d’étranglement, et sa défaillance peut interrompre l’ensemble du flux de travail si le système ne prend pas en charge la reprise.

Orchestration décentralisée

Dans l’orchestration décentralisée, les agents se coordonnent plus directement au lieu de dépendre d’un seul gestionnaire pour prendre chaque décision. Ils peuvent échanger des messages, lire un état partagé et déterminer de manière autonome leurs prochaines étapes.

Agrandir

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 aboutir à 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.

Imaginez un flux de travail d’entreprise impliquant les équipes commerciales, financières et juridiques. Un orchestrateur de niveau supérieur pourrait déléguer chaque chantier à un coordinateur spécialisé dans le domaine concerné. Ces coordinateurs géreraient ensuite leurs propres agents spécialisés et rendraient compte de résultats consolidés.

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

Agrandir

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 branches individuelles. Elles introduisent toutefois des transferts supplémentaires, une gestion d’état plus complexe et une charge opérationnelle accrue. La reprise locale dépend aussi de la manière dont les points de contrôle et l’état d’exécution sont implémentés.

Comparaison de ces architectures :

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

Il existe une autre distinction qu’il vaut la peine de comprendre. L’architecture détermine qui coordonne les agents. Le modèle d’exécution détermine comment leurs tâches progressent.

Voici trois modèles 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 équipé pour gérer l’étape suivante, mais chaque transfert doit préserver les informations nécessaires pour continuer.

Ces modèles 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 IA

Tout peut mal tourner avec l’orchestration, des simples oublis aux blocages complexes. Parfois, un agent peut même sembler faire correctement son travail alors que le flux de travail global é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 — gardez-les à l’œil :

• Transferts entre agents avec perte d’informations. 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 d’implémentation.
• Exécution 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 manière dont le framework gère les mises à jour, cela peut entraîner des écritures perdues, des données dupliquées, une sortie dépendante de l’ordre ou des modifications conflictuelles.
• Divergence entre points de contrôle et effets de bord. Une tâche effectue une opération externe, mais son exécution réussie n’est pas enregistrée de manière durable avant la défaillance du worker. Lors de la reprise, l’orchestrateur voit une tâche inachevée et la réexécute.
• Conditions de concurrence lors de la reprise après approbation humaine. La mise en pause et la reprise de l’exécution introduisent leurs propres problèmes de synchronisation.
• Boucles de délégation et amplification des nouvelles tentatives. Les agents se renvoient le travail à plusieurs reprises parce que leurs responsabilités se chevauchent, que les 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 du modèle n’appliquent 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 sont différentes. Une transition prématurée du planificateur ou une écriture externe ambiguë peuvent toutes produire un résultat incorrect, mais elles prennent naissance dans différentes parties du cycle de vie de l’exécution. C’est pourquoi une orchestration fiable exige davantage que l’amélioration des prompts ou l’ajout de nouvelles tentatives.

7 bonnes pratiques d’orchestration d’agents 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é » floue aboutissent souvent à des résultats décevants de la part des agents. La solution est un contrat de prompt (un périmètre de travail 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 de manière intermittente :

• Objectif : identifier et corriger la cause d’un test d’intégration instable de l’API de paiement.
• Entrées : code source des tests, journaux d’échec de la CI, commits récents et code applicatif pertinent.
• Contraintes : ne pas désactiver de tests, ne pas assouplir les assertions et ne pas modifier le comportement de l’application sans rapport avec le problème.
• Sortie attendue : un patch de code, une explication de la cause racine et les résultats de l’exécution des tests.
• Critères d’acceptation : le test qui échouait auparavant réussit sur 10 exécutions consécutives, et la suite de régression pertinente réussit.
• Conditions d’échec : la cause racine ne peut pas être établie, le correctif introduit des régressions ou l’environnement de test requis n’est pas disponible.

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

Un agent ne doit 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 renvoyer 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ération ou des budgets d’exécution afin que les tâches non résolues ne se transforment pas en boucles sans fin.

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

• Succès : le correctif réussit 10 exécutions de test consécutives ainsi que la suite 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 au bout de 60 minutes, même si le problème n’est pas résolu.
• Limite de délégation : l’agent peut déléguer du travail à un agent spécialisé, sans autre délégation à des sous-agents.
• Achèvement partiel : si les deux tentatives échouent ou si le délai expire, l’agent renvoie ses conclusions, 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 le blocage au lieu de prétendre avoir réussi.

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

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

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

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

3. Persister l’état du flux de travail et contrôler la croissance du contexte

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

Par exemple, si l’agent de codage génère un patch puis plante, le worker suivant doit récupérer l’artefact enregistré et reprendre à partir de l’état du flux de travail consigné. Mais si l’agent a également déclenché une exécution de CI externe, l’orchestrateur doit réconcilier séparément cette exécution avant de répéter l’action

Séparez donc l’état d’exécution du contexte de travail de l’agent. Enregistrez les statuts 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 des outils récupérable

Imaginons que votre agent de 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 de CI l’a-t-il mise en file d’attente avant de perdre la réponse ?

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

• Erreurs transitoires (429, 503) : réessayez avec un backoff exponentiel borné et une gigue (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 (délai d’expiration après une possible écriture) : vérifiez si l’opération a réussi avant de la retenter.

Remarque : même les erreurs pouvant faire l’objet d’une nouvelle tentative nécessitent des limites. Définissez un délai d’expiration pour chaque appel d’outil, plafonnez le nombre de tentatives et la durée totale des nouvelles tentatives, et imposez une échéance globale au flux de travail afin que les agents imbriqués ne puissent pas relancer indéfiniment la même opération. Si une dépendance échoue à plusieurs reprises, 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. Dans le cas contraire, interrogez le système externe à l’aide d’un ID 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 nouvelle tentative pour notre agent de CI, exprimé en pseudocode :

Note sur le code : l’exemple suppose que l’API de CI permet de rechercher des exécutions par ID de requête. Le request_id n’empêche les doublons que si le fournisseur garantit explicitement l’idempotence. bounded_retry() est un pseudocode illustratif. En production, les nouvelles tentatives doivent être limitées à la fois par un budget de nouvelles 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 couvrant plusieurs services, envisagez le modèle Saga pour coordonner des actions de compensation lorsque des étapes ultérieures échouent. N’oubliez pas que la compensation n’équivaut pas toujours à un rollback complet. Vous pouvez annuler une mise à jour de base de données, mais vous ne pouvez pas annuler l’envoi d’un e-mail.

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

Il y a deux éléments à équilibrer ici : le niveau de 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 ne s’appuient que sur des 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 vous-même des règles de routage et évaluer les modèles, soit utiliser une plateforme d’orchestration qui gère la sélection du modèle pour vous.

Par exemple, le mode Effort 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 d’orchestration 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 termes de qualité et de coût, en privilégiant les options moins onéreuses qui offrent des résultats comparables. Vous pouvez également utiliser les contrôles personnalisés (Custom) si vous préférez choisir vous-même le modèle et le niveau de raisonnement.

Pour le parallélisme, la limite doit dépendre de votre infrastructure et de vos dépendances externes. Vérifiez les limites de débit en requêtes et en tokens des API partagées, puis effectuez des tests de charge de votre flux de travail avec une concurrence croissante. Observez si le débit s’améliore ou si les requêtes commencent à être mises en file d’attente, à ralentir ou à renvoyer des erreurs 429.

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

• Contrôlez la concurrence et les débits de requêtes : plafonnez les appels en cours par service et mettez en file d’attente le travail excédentaire. N’oubliez pas qu’un plafond de concurrence ne suffit pas à lui seul à imposer des limites de requêtes par minute ou de tokens par minute.
• Suivez les budgets de tokens et de coûts : tenez compte de l’utilisation sur 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 possible.
• Respectez les dépendances : ne démarrez 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 autorisations selon le principe du moindre privilège et appliquez des règles d’approbation fondées sur les risques 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 à l’égard des systèmes multi-agents trop complexes, surtout lorsque des agents examinent et approuvent le travail les uns des autres. Vous pouvez vous retrouver avec plusieurs agents qui se transmettent avec assurance la même erreur, sans que personne ne la détecte réellement », met en garde Spilker.

Agrandir

Pour les actions nécessitant 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 également ce qui se passe si l’approbation est rejetée, expire ou nécessite une escalade. C’est essentiel pour les frameworks permettant la reprise, car la reprise d’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 clôturée. Si le commit cible, les paramètres ou les autorisations 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 de bout en bout entièrement autonomes constitueraient l’objectif. « Pour moi, la meilleure approche consiste à créer quelques agents ciblés avec des responsabilités claires, des autorisations définies et une revue humaine aux moments opportuns. Vous gagnez toujours en efficacité sans renoncer au contrôle total », conclut-il.

7. Vérifier les sorties de manière indépendante et tester le comportement de reprise

Avez-vous déjà vu un agent signaler Succès alors qu’il avait en réalité échoué ? C’est 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 manière indépendante. Prenons donc le temps d’isoler et de résoudre le problème.

Tracer le flux de travail pour identifier ce qui n’a pas fonctionné

Avant de déboguer les prompts d’un agent, capturez l’intégralité du chemin d’exécution. Vous avez besoin d’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 un moyen standardisé de décrire ces opérations. Par exemple, invoke_workflow identifie l’exécution d’un flux de travail, invoke_agent une invocation d’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 fournit une trace du chemin d’exécution, ce qui vous permet d’identifier où un agent a rencontré un accroc.

Exemple de trace d’exécution.

Examiner la sortie de manière indépendante

Utilisez des vérifications programmatiques dans la mesure du possible. Validez les sorties 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 abouti.

Pour les sorties qui nécessitent un jugement subjectif — et qui ne peuvent donc pas être évaluées par des vérifications programmatiques —, faites intervenir un agent réviseur indépendant. Une approche consiste à utiliser une boucle implémenteur–réviseur–résolveur, dans laquelle un agent produit un artefact, un réviseur disposant d’un contexte neuf identifie les problèmes et un résolveur les traite avant que la validation ne soit relancée.

Vous devez tout de même valider les conclusions du réviseur dans la mesure du possible et, si vous utilisez des évaluateurs basés sur des LLM pour des évaluations répétées, calibrer leurs jugements par rapport à des 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 dépasse son délai d’expiration après avoir accepté une requête ? Étonnamment, votre flux de travail peut se comporter parfaitement 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 dépassements de délai d’API
• Faites planter des workers entre les écritures externes et les points de contrôle
• Renvoyez des sorties d’outils malformées
• 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 dépasse le délai d’expiration. L’agent réessaie, reçoit une réponse positive et signale Success. Tout semble normal 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 doit réussir que si 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.

En fin de compte, la réussite signifie que le flux de travail a satisfait à ses vérifications obligatoires et que ses résultats externes ont été vérifiés.

FAQ sur l’orchestration d’agents IA

Pourquoi les agents IA cloisonnés atteignent-ils leurs limites à l’échelle de l’entreprise ?

Des agents cloisonnés peuvent accomplir correctement leurs tâches individuelles tout en produisant ensemble des résultats incohérents. Imaginez un agent commercial qui récupère les conditions d’un client à 10 h 00, un agent de tarification qui calcule un devis à partir de prix mis à jour à 10 h 05, et un agent juridique qui vérifie un contrat modifié à 10 h 07. Chaque agent travaille sur un instantané différent de l’entreprise, si bien que leurs résultats peuvent se contredire.

Le problème s’accentue à l’échelle de l’entreprise, car les agents interagissent avec de multiples 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 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 délai global du flux de travail. Classez les défaillances avant de réessayer. Pour les réponses 429 transitoires, respectez l’en-tête Retry-After lorsqu’il est fourni. Sinon, utilisez un backoff exponentiel borné avec gigue (jitter).

Cessez de réessayer des requêtes inchangées après des erreurs de validation ou d’autorisation. Si un service en aval échoue de manière répétée, 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 IA après un plantage ?

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

Si l’application est redéployée alors que des flux de travail sont encore en cours d’exécution, l’état enregistré et les historiques d’exécution peuvent ne plus être compatibles. Temporal résout ce problème grâce au Worker Versioning et au patching des 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 sur les états enregistrés existants avant de déployer des modifications incompatibles.

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

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

Mesurez les résultats par catégorie de tâche et par version de flux de travail plutôt que de vous fier à un taux de réussite agrégé unique. Suivez la réussite au premier essai, 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 cas nécessitant une intervention humaine. Indiquez la taille des échantillons et les intervalles d’incertitude des taux de réussite.