L'orchestration d'agents IA en assurance : ce qui change, ce qui reste

Depuis quelques mois, tout le monde parle d'agents IA. La promesse est séduisante : au lieu d'un chatbot unique qui répond mal à tout, on aurait une équipe d'agents spécialisés, chacun bon sur son périmètre, coordonnés par un chef d'orchestre. Sur le papier, c'est élégant. Sur le terrain, la difficulté se déplace — elle ne disparaît pas. Je voudrais dire où, parce que c'est là que se joue la qualité d'un système multi-agents.

Le premier changement est le plus visible. Chaque agent devient plus simple à concevoir. Au lieu de demander à un même système de comprendre une demande de devis, de vérifier une conformité, de rédiger une réponse et de mettre à jour un dossier, on distribue. Chaque agent a un périmètre étroit, des données propres, un comportement testable. Cette simplification par spécialisation est réelle et bienvenue. Elle rend le système plus lisible, plus maintenable, plus corrigeable quand quelque chose dérape.

Le deuxième changement est plus subtil. La difficulté qu'on retirait à chaque agent, on la remet dans l'orchestrateur. C'est lui qui doit maintenant comprendre la demande entrante, décider quel agent activer, dans quel ordre, avec quelles informations. Il doit aussi gérer les cas où plusieurs agents doivent intervenir successivement — parce qu'une demande de devis peut nécessiter une vérification de conformité puis un routage commercial. L'orchestrateur devient le point sensible du système, celui dont la qualité conditionne tout le reste.

Cette centralisation a un coût. Elle rend l'orchestrateur difficile à évaluer isolément — ses erreurs ne sont visibles qu'en bout de chaîne, quand un dossier a été mal routé ou qu'un agent a été appelé avec de mauvaises entrées. Elle rend aussi le système plus opaque à première vue : là où un chatbot unique fait tout en un endroit, une architecture multi-agents distribue le comportement, et retracer ce qui s'est passé demande une journalisation soigneuse. Sans cette traçabilité, on hérite du pire des deux mondes : la complexité de la distribution, sans la lisibilité qu'elle promettait.

Ce qui ne change pas, en revanche, c'est l'essentiel. Un agent, seul ou en groupe, doit toujours savoir ce qu'il ne sait pas. Il doit toujours pouvoir renvoyer vers l'humain quand il touche à une décision engageante. Il doit toujours être évalué sur des cas réels, pas sur des benchmarks. Et il doit toujours documenter ce qu'il fait pour rester auditable. La distribution du travail entre plusieurs agents n'exonère de rien de tout cela — au contraire, elle l'exige à chaque niveau du système.

Un point que nous avons appris à surveiller particulièrement : la cohérence de contexte entre agents. Quand deux agents traitent successivement un même dossier, ils doivent partager suffisamment d'information pour que leurs décisions soient cohérentes, mais pas trop pour que chacun reste ciblé sur son périmètre. Trouver ce point d'équilibre est un travail continu, pas un choix d'architecture initial. C'est en observant les cas où le système se contredit qu'on comprend où affiner le partage de contexte.

Je retiens de ces derniers mois une leçon qui n'est pas spécifique à l'assurance mais qui y prend un relief particulier : une architecture d'agents n'est pas magique. Elle simplifie ce qui pouvait l'être, et elle concentre ce qui ne peut pas l'être ailleurs. Le vrai gain n'est pas d'avoir plusieurs agents plutôt qu'un seul. C'est d'avoir un système où chaque décision est prise à l'endroit où on peut le mieux la contrôler. Et ce n'est pas la même chose.