Exemple : un agent IA pour accélérer le traitement des sinistres d'un courtier

Exemple de situation. Cet article décrit une situation type, construite pour illustrer la démarche d'un agent IA de traitement de sinistres chez un courtier en assurance. Ce n'est pas un projet client : les chiffres de résultat ne sont pas publiés, parce qu'ils dépendent de chaque cabinet.

#1. Contexte : le problème du délai de traitement

Prenons un cabinet de courtage indépendant, multi-branches (auto, habitation, RC professionnelle, garantie décennale), partenaire de plusieurs compagnies. Son problème : le délai entre la déclaration d'un sinistre par le client et la transmission du dossier qualifié à la compagnie est long.

La cause est identifiée depuis longtemps mais jamais traitée : la saisie manuelle. Chaque dossier entre dans le cabinet sous trois formes simultanées — un formulaire de déclaration papier ou PDF, un ou plusieurs emails du client avec des explications libres, et des photos de l'incident. Ces trois sources doivent être lues, réconciliées, et re-saisies manuellement dans le CRM par un gestionnaire.

Le coût de cette inefficacité est double. Économique d'abord : plusieurs gestionnaires occupés à une tâche de saisie à faible valeur ajoutée. Commercial ensuite : la satisfaction client (NPS) est plombée par les délais. Dans un secteur où le bouche-à-oreille est la première source de nouveaux mandats, c'est un manque à gagner structurel.

La direction pose une contrainte claire dès le lancement : aucune réduction d'effectif. L'objectif est de rediriger les gestionnaires vers des tâches à plus haute valeur (conseil client, fidélisation, développement du portefeuille), pas de les remplacer.

---

#2. Diagnostic : cartographier les types de sinistres et leur complexité

Avant de coder une seule ligne, il faut cartographier l'existant. Ce diagnostic structuré est la première étape de la méthodologie en 7 étapes pour déployer un agent IA — et il détermine le périmètre du projet.

L'analyse des dossiers historiques révèle plusieurs types de sinistres distincts, avec des profils de complexité très différents. On les classe en trois groupes :

Groupe A — Automatisables : sinistre auto bris de glace (sans responsabilité tierce), dégât des eaux habitation simple (fuite identifiée, pas de tiers), vol simple (déclaration police jointe), sinistre RC pro mineur (responsabilité non contestée), accident auto tiers identifié et non contesté.

Groupe B — Semi-automatisables : sinistre auto avec litige de responsabilité partielle, dégât des eaux avec plusieurs parties (copropriété), garantie décennale avec réserves contradictoires, RC pro avec mise en cause juridique potentielle.

Groupe C — Non automatisables : catastrophe naturelle (arrêté CatNat requis, procédure réglementée), litige en cours avec avocat engagé, sinistre corporel, fraude suspectée (signalement interne requis).

Cette cartographie définit le périmètre : automatiser le Groupe A, assister le Groupe B, laisser le Groupe C entièrement en traitement humain.

Deuxième enseignement du diagnostic : les formulaires entrants sont structurellement incohérents. Certains dossiers arrivent par le formulaire web du cabinet (données structurées), d'autres par email libre (texte non structuré, PDF joints), d'autres combinent les deux. L'enjeu technique principal est donc l'extraction d'informations depuis des sources hétérogènes, avant même la question de la qualification et du routage.

---

#3. Architecture envisagée : LLM + OCR + orchestration + CRM

L'architecture repose sur cinq composants principaux, choisis pour leur fiabilité en production et leur compatibilité avec l'infrastructure existante du cabinet.

Composant 1 — LLM central (par exemple Claude de chez Anthropic). Choisi pour sa capacité à raisonner sur des documents assurantiels complexes, à appliquer des règles métier multi-conditions, et à produire des sorties JSON structurées. Un DPA conforme RGPD doit être signé avant go-live.

Pour mieux comprendre ce qu'est un agent IA et comment il diffère d'un chatbot, la distinction centrale est que cet agent orchestre des outils (OCR, CRM, classification) — il ne se contente pas de répondre à des questions.

Composant 2 — OCR (par exemple Mistral OCR). Pour l'extraction de texte depuis les photos de sinistres, les formulaires PDF scannés et les documents joints. Le choix de l'OCR se fait par benchmark sur des documents réels du cabinet, en séparant formulaires imprimés et manuscrits. Les meilleurs outils OCR IA pour factures et contrats en 2026 comparent les alternatives disponibles.

Composant 3 — Orchestration (Make, Zapier ou n8n). Make gère les workflows complexes (dossier multi-documents, escalade conditionnelle), Zapier les cas simples (email entrant → création de ticket). Pour que les gestionnaires puissent comprendre et modifier les règles de routage sans assistance technique, la lisibilité des scénarios est un critère de choix.

Composant 4 — CRM (par exemple Salesforce Service Cloud). Point central de toutes les données dossier. L'agent écrit dans le CRM (création de case, enrichissement des champs, mise à jour du statut, assignation au gestionnaire), mais ne prend aucune décision financière — aucun montant d'indemnisation n'est calculé ni validé automatiquement. C'est un choix délibéré, à confirmer avec le conseil juridique du cabinet avant le lancement.

Composant 5 — Base vectorielle RAG (par exemple Qdrant). Indexation de dossiers historiques dépersonnalisés, des procédures de traitement par type de sinistre, des règles de délégation des compagnies partenaires et des grilles de référence. L'architecture RAG pour connecter l'agent aux données métier internes permet à l'agent de retrouver des précédents similaires pour qualifier correctement les cas ambigus.

---

#4. Phase 1 : préparer les données

Les premiers mois sont consacrés à la préparation des données — phase souvent sous-estimée mais déterminante pour la qualité en production.

Dépersonnalisation et labellisation du corpus. Les dossiers historiques sont dépersonnalisés (suppression des noms, adresses, numéros de police) par un script, puis labellisés selon le schéma de classification défini lors du diagnostic : type de sinistre, groupe d'automatisabilité (A/B/C), informations présentes ou manquantes, résolution finale. Ce travail mobilise des gestionnaires séniors du cabinet, en parallèle de leur activité normale.

Construction du pipeline OCR. Workflow : email entrant → extraction des pièces jointes → OCR sur chaque pièce → consolidation du texte extrait dans un objet JSON normalisé → transmission au LLM pour classification. Les principales erreurs attendues viennent des photos prises dans de mauvaises conditions lumineuses et des formulaires très anciens.

Configuration du prompt système principal. Le prompt système de l'agent encode les types de sinistres, les règles de classification A/B/C, les champs obligatoires à extraire pour chaque type, les règles de délégation par compagnie et les conditions d'escalade. Sa rédaction demande plusieurs itérations, chacune testée sur un échantillon du corpus labellisé.

Intégration CRM. Configuration de l'API du CRM pour permettre la création et l'enrichissement de cases depuis l'agent. Règle stricte : l'agent peut créer et enrichir, jamais supprimer ni modifier le statut final (clôturé, refusé, accepté) — ces actions restent exclusivement humaines.

---

#5. Phase 2 : pilote sur les sinistres auto simples

Le pilote cible un sous-ensemble du Groupe A : les sinistres auto bris de glace et accidents non contestés. Trois raisons à ce choix : procédure la plus standardisée, documents les plus homogènes (constats, devis vitrier, rapport carrossier), et conséquences financières les plus prévisibles en cas d'erreur de classification.

Configuration du pilote. Dans un premier temps, l'agent traite les dossiers en parallèle du gestionnaire humain (mode shadow). Les deux classifications sont comparées. Le gestionnaire reste décisionnaire — l'agent propose, l'humain valide.

Lire le shadow mode. On mesure la concordance entre l'agent et le gestionnaire sur la classification du type de sinistre, et on étudie les divergences : fraude suspectée classée à tort en Groupe A (le gestionnaire s'appuie sur des signaux non documentés comme l'ancienneté du client ou l'historique), véhicules de société classés à tort en Groupe B. Ces divergences enrichissent le prompt système avec des règles supplémentaires.

Passage en mode autonome. Une fois la concordance jugée suffisante, l'agent traite les sinistres du périmètre pilote sans validation humaine préalable. Le gestionnaire reçoit une notification avec le dossier pré-rempli et dispose d'une fenêtre pour invalider la classification avant transmission à la compagnie.

---

#6. Phase 3 : extension multi-branches et téléphonie

Fort des résultats du pilote, le périmètre s'étend à l'ensemble du Groupe A, avec un canal entrant supplémentaire : la téléphonie.

Extension multi-branches. Les sinistres habitation dégât des eaux simples et RC pro mineurs sont intégrés. Les documents de référence diffèrent (rapport de plombier, devis de réparation, attestation de tiers) et les règles de délégation varient selon les compagnies : il faut configurer des prompts spécifiques à chaque branche.

Incident technique type. L'OCR peut présenter des erreurs systématiques sur les rapports manuscrits (format libre, écriture cursive). Solution : détecter automatiquement les documents « manuscrit probable » et les re-router vers un gestionnaire humain pour saisie manuelle.

Intégration téléphonie (DTMF/Twilio). Les déclarations par téléphone sont un canal à part. Architecture possible : Twilio Studio pour le serveur vocal interactif avec menus DTMF, collecte vocale des informations clés (numéro de contrat, type de sinistre, description libre), transcription, puis injection dans le même pipeline agent que les canaux texte.

Le déploiement d'un callbot vocal IA pour le service client détaille les choix techniques sur la couche de transcription — l'enjeu principal en assurance est la précision sur les montants et les noms propres.

---

#7. Ce qu'on mesure

Nous ne publions pas de résultats chiffrés pour cet exemple : il est construit pour illustrer la démarche. Dans un vrai projet, on relève les indicateurs ci-dessous avant le projet, puis régulièrement après la mise en production.

#Indicateurs globaux

• Délai moyen de traitement d'un sinistre
• Taux d'automatisation (dossiers traités sans intervention humaine)
• Coût par dossier traité
• Satisfaction client (NPS)
• Temps gestionnaire consacré à la saisie

#Par groupe de sinistres

• Groupe A (automatisés) : le délai doit nettement baisser.
• Groupe B (assistés) : le traitement humain est raccourci par la pré-qualification.
• Groupe C (non automatisés) : le délai reste inchangé, et c'est normal ; il ne doit pas s'allonger du fait du tri.

La baisse globale du délai s'explique par l'effet volume : les sinistres du Groupe A, traités en peu de temps, tirent la moyenne vers le bas, compensant les groupes B et C.

---

#8. Ce qui peut ne pas fonctionner : catastrophes naturelles, litiges juridiques

Tout projet honnêtement documenté inclut ses zones d'échec. Deux sont typiques, plus une troisième plus technique.

#Zone d'échec 1 : sinistres catastrophe naturelle (CatNat)

Les sinistres CatNat se concentrent sur des périodes courtes et intenses (orages de grêle, inondations). La réglementation impose un cadre procédural strict : déclaration dans un délai fixé après la publication de l'arrêté CatNat, expertise obligatoire, franchise légale non modulable.

Une tentative d'automatisation sur les CatNat simples donne un taux de classification correcte nettement inférieur à celui des sinistres standard. Causes : la multiplicité des arrêtés (chaque commune a son périmètre et ses dates), la nécessité de croiser la commune de l'assuré avec la liste officielle des communes reconnues, et des formulations très variables dans les déclarations.

Décision recommandée : exclure les CatNat du périmètre d'automatisation. L'agent filtre et route ces dossiers vers une équipe dédiée avec un statut « CatNat — traitement prioritaire » dans le CRM, mais ne les traite pas. La valeur ajoutée reste réelle (identification rapide), même si l'automatisation complète n'est pas au niveau requis.

#Zone d'échec 2 : litiges juridiques en cours

Lorsqu'un assuré mentionne un avocat, une mise en demeure ou une procédure judiciaire, l'agent est configuré pour escalader immédiatement sans traitement. Ce comportement est intentionnel — toute classification ou commentaire de l'IA sur un dossier juridiquement contesté pourrait constituer une prise de position engageant la responsabilité du cabinet.

Problème typique : la détection des signaux juridiques. Une mention d'avocat peut se trouver en post-scriptum d'un email, hors du corps principal du message.

Correction : analyse systématique de l'intégralité du texte (corps, pièces jointes, P.S.) avec détection d'une liste de termes juridiques (« avocat », « mise en demeure », « tribunal », « huissier », « assignation »...), puis vérification sur un jeu de dossiers de test.

#Problème technique : qualité OCR sur photos basse résolution

Une partie des photos de sinistres reçues par email a une résolution insuffisante pour l'OCR (photos prises de nuit, trop loin, floues). Si le pipeline tente quand même l'extraction, il produit des données erronées. Correction : détection de la qualité d'image en amont (résolution, netteté), avec message automatique à l'assuré lui demandant une photo de meilleure qualité si le seuil minimal n'est pas atteint.

La sécurité des agents IA : checklist OWASP LLM Top 10 doit être appliquée point par point, notamment sur les vecteurs d'injection de prompt via les champs libres des formulaires de déclaration — un risque réel dans un contexte assurantiel où les assurés peuvent avoir intérêt à influencer la classification.

---

#9. Mesurer le retour sur investissement

La méthode de calcul et justification du ROI d'un projet agent IA doit rester conservative : seuls les gains directement mesurables sont retenus, sans projection sur des gains indirects difficiles à quantifier.

#Les coûts à compter

• Développement et déploiement des phases pilote et extension
• Formation de l'équipe et accompagnement au changement
• Licences logicielles supplémentaires (orchestration, téléphonie)
• Ajustements du CRM (nouveaux champs, workflows)
• Coûts récurrents : infrastructure IA (API LLM, OCR, base vectorielle, orchestration, téléphonie), maintenance et évolutions mineures

#Les gains à mesurer

• Temps de gestionnaire libéré : le temps de saisie est redirigé vers la gestion de comptes stratégiques et le développement commercial, sans réduction d'effectif.
• Satisfaction et rétention client : un meilleur NPS peut se traduire par moins de résiliations.
• Coût par dossier : à croiser avec le gain précédent pour éviter le double compte.

On applique ensuite un facteur d'attribution prudent (une partie seulement des gains est attribuée à l'agent), et on calcule le payback en neutralisant les coûts récurrents.

Pour nos services agent IA sur mesure pour le secteur assurantiel, l'architecture est reproductible ; la configuration métier est systématiquement sur mesure. Chaque cabinet a ses branches, ses compagnies partenaires, ses procédures. Un MVP d'agent IA démarre à 11 000 € HT, et un audit IA express d'une journée coûte 990 € HT (déduit du projet s'il est lancé dans les trois mois).

La IA dans la souscription et la détection de fraude en assurance ouvre d'autres perspectives complémentaires pour les cabinets ayant franchi le cap de l'automatisation du traitement des sinistres.

Photos : fauxels sur Pexels.