Saisie automatique du CRM assurance depuis les emails clients, méthode IA

Dans un cabinet de courtage de taille moyenne, une assistante traite entre 150 et 300 emails par jour. Demandes de devis, déclarations de sinistre, modifications de contrat, demandes d'attestation. Pour chaque email, il faut ouvrir le CRM, retrouver la fiche client, saisir les informations, attacher les pièces jointes, créer une tâche de suivi. Cette séquence prend entre 4 et 12 minutes selon la complexité. Répétée deux cents fois par jour, elle représente 40 à 60 % du temps d'un poste assistant.

Ce n'est pas un problème technologique récent. C'est un problème structurel du métier de courtier, que ni les CRM actuels ni les workflows email standards n'ont réellement résolu. Ce que les outils récents permettent, c'est d'y répondre autrement : en lisant les emails avec un LLM, en extrayant les données structurées, et en les injectant directement dans le CRM via API. Sans saisie manuelle, sans perte d'information.

Cet article détaille la méthode, l'architecture, les résultats attendus par type d'email, les CRM compatibles, et les conditions RGPD à respecter. Avec un cas pratique chiffré sur un cabinet de 6 collaborateurs traitant 250 emails par jour.

La ressaisie, ce travail invisible qui mange le cabinet

Demandez à n'importe quelle assistante de courtage ce qu'elle fait le plus dans la journée. La réponse est presque toujours la même : elle lit des emails, ouvre le CRM, retrouve la fiche, copie des informations, crée des tâches, ferme le CRM, répond à l'email. Puis recommence.

Ce cycle n'est pas mesuré comme une perte, parce qu'il s'appelle "traitement des emails" dans les fiches de poste. Mais si on le chronomètre sur une semaine réelle, dans un cabinet de courtage multi-risques de taille moyenne, on obtient en général ceci :

• Temps moyen de traitement par email impliquant une saisie CRM : entre 4 et 12 minutes selon la complexité
• Proportion d'emails nécessitant une action CRM : environ 60 à 70 % du flux entrant
• Taux d'erreur de ressaisie manuelle : estimé entre 3 et 8 % sur les champs alphanumériques (numéros de contrat, IBAN, immatriculations)
• Nombre d'emails traités par assistant par jour : entre 80 et 150 en cabinet généraliste

Sur un cabinet de 6 personnes dont 2 assistants à temps plein, la ressaisie représente facilement 1,5 ETP récurrent consacré à de la copie d'informations d'un support à un autre. Ce n'est pas de la gestion de relation client. Ce n'est pas du conseil. C'est de la saisie.

La ressaisie génère également un risque opérationnel souvent sous-estimé. Une erreur sur un numéro de contrat dans le CRM peut entraîner une déclaration de sinistre mal rattachée, une relance de renouvellement envoyée au mauvais assuré, ou une modification de contrat appliquée sur la mauvaise fiche. Ces erreurs coûtent du temps à corriger et dégradent la confiance du client. Pour approfondir les enjeux de conformité opérationnelle en cabinet de courtage, l'article sur la conformité DDA et l'IA pour les courtiers donne des repères utiles.

Les cinq typologies d'emails en courtage et leur schéma d'extraction

Tous les emails entrants dans un cabinet de courtage n'ont pas la même structure, ni le même degré de complexité d'extraction. Identifier les typologies est la première étape de tout projet d'automatisation sérieux, parce que le schéma d'extraction, les champs à cibler et la précision attendue diffèrent sensiblement d'une catégorie à l'autre.

Demande de devis

C'est souvent le flux le plus volumineux et le plus standardisé. Un particulier ou un chef d'entreprise demande une couverture pour un véhicule, un local, une responsabilité civile professionnelle. Les champs à extraire sont :

• Identité du demandeur (nom, prénom ou dénomination sociale, coordonnées)
• Type de risque souhaité (RC pro, multirisque habitation, automobile, etc.)
• Informations techniques du risque (SIRET, surface assurée, usage du local, immatriculation)
• Budget indicatif ou niveau de franchise souhaité, si mentionné
• Délai ou date de prise d'effet souhaitée

Ce type d'email se prête bien à l'extraction automatique avec des taux de précision élevés sur les champs structurés. La comparaison de garanties en aval peut s'appuyer sur l'article dédié au comparateur de garanties IA pour courtier, qui détaille comment exploiter ces données extraites dans l'étape de conseil.

Déclaration de sinistre

C'est le flux à plus fort enjeu opérationnel et réglementaire. L'assuré déclare un événement en langage naturel, souvent sous stress. Les champs cibles sont :

• Numéro de contrat ou police (parfois absent, à retrouver par rapprochement)
• Date et heure du sinistre
• Nature du dommage (incendie, dégât des eaux, accident, vol, etc.)
• Tiers impliqués et leurs coordonnées si mentionnées
• Description des circonstances (texte libre, à conserver tel quel)
• Existence de pièces jointes (photos, constat, rapport de police)

La précision est bonne sur les champs structurés, plus variable sur la description libre. L'automatisation du workflow sinistre en aval est traitée dans l'article sur l'analyse de sinistre IA et workflow courtier.

Modification de contrat

L'assuré demande un changement de véhicule, un avenant, une modification d'adresse, un ajout de conducteur. Les champs à extraire sont la nature de la modification, le contrat concerné, les nouvelles données (nouvel IBAN, nouvelle adresse, nouvelle immatriculation), et la date souhaitée de prise d'effet. Ce flux est sensible : une erreur d'extraction sur le contrat cible entraîne un avenant appliqué sur la mauvaise fiche.

Demande d'attestation

Flux court et très standardisé. L'assuré ou un tiers (bailleur, banque, administration) demande une attestation de couverture. Champs à extraire : identité du demandeur, numéro de contrat ou de police, type d'attestation demandé, destinataire si différent de l'assuré, délai souhaité. C'est le flux le plus simple à automatiser complètement, y compris la génération et l'envoi automatique de l'attestation.

Question administrative

Demandes de délai de paiement, questions sur une cotisation, contestations de facture, changement de coordonnées. Ces emails sont hétérogènes et leur extraction est moins standardisable. La classification est essentielle pour les router vers le bon interlocuteur dans le cabinet, même si l'extraction structurée est limitée. Pour les questions liées au renouvellement, le lien avec l'article sur les relances de renouvellement automatisées est direct.

Architecture du pipeline IA, de la boîte mail au CRM

Le pipeline se décompose en cinq étapes séquentielles. Chacune peut être optimisée indépendamment, ce qui facilite le déploiement par phases.

Étape 1 : connexion IMAP et ingestion des emails

Le système se connecte à la boîte email du cabinet via le protocole IMAP (compatible Gmail, Outlook, Exchange, OVH Mail). Les emails entrants sont collectés en temps quasi-réel (toutes les 2 à 5 minutes selon la configuration). Corps de l'email, métadonnées (expéditeur, date, objet) et pièces jointes sont extraits séparément pour être traités en parallèle. Aucune modification n'est apportée à la boîte originale.

Étape 2 : classification par LLM

Chaque email est envoyé à un LLM avec un prompt de classification qui lui demande d'identifier la catégorie (demande de devis, déclaration de sinistre, modification de contrat, demande d'attestation, question administrative) et un niveau de confiance associé. Les emails qui ne correspondent à aucune catégorie connue, ou dont le score de confiance est inférieur à un seuil défini, sont routés vers une file humaine sans traitement automatique.

Étape 3 : extraction structurée

Le LLM reçoit le corps de l'email et un schéma JSON qui décrit les champs à extraire pour cette catégorie. Il produit une sortie structurée avec, pour chaque champ, la valeur extraite et un score de confiance. Les champs obligatoires manquants déclenchent une demande de complément automatique à l'assuré. Un schéma de déclaration de sinistre ressemble à ceci :

{
  "categorie": "declaration_sinistre",
  "confiance_classification": 0.97,
  "champs": {
    "numero_contrat": { "valeur": "RC-2024-00847", "confiance": 0.94 },
    "date_sinistre": { "valeur": "2026-05-12", "confiance": 0.99 },
    "nature_sinistre": { "valeur": "degat_des_eaux", "confiance": 0.91 },
    "description_libre": { "valeur": "Fuite au niveau du lave-vaisselle...", "confiance": null },
    "tiers_impliques": { "valeur": null, "confiance": 0.88 }
  }
}

Étape 4 : enrichissement et rapprochement client

Avant injection dans le CRM, le système tente de rapprocher les données extraites avec les fiches existantes. Si le numéro de contrat est absent, il recherche par nom, email, SIRET ou immatriculation. Si un SIRET est présent, il peut être vérifié via l'API Sirene de l'INSEE pour confirmer la dénomination sociale. Un RIB peut être validé par vérification de la clé IBAN. Ces étapes d'enrichissement réduisent le nombre de doublons créés et la charge de dédoublonnage manuel.

Étape 5 : injection CRM via API et file de validation

Les champs dont le score de confiance dépasse le seuil configuré sont injectés directement dans le CRM via son API. Les champs sous le seuil, ou les emails de catégories sensibles (modification de contrat, déclaration de sinistre), sont présentés dans une interface de validation où l'assistant voit l'email original et les données extraites côte à côte, et peut valider ou corriger en un clic. Cette interface réduit le temps de traitement d'une déclaration de sinistre de 8 à 12 minutes à 45 secondes à 2 minutes.

Cette logique d'automatisation avec validation humaine ciblée est proche de ce que nous décrivons dans l'article sur l'automatisation de saisie de commandes email CRM par IA, qui couvre un cas d'usage similaire dans le secteur commercial.

WebCourtage, Otto Cube, Bagheera : les degrés d'ouverture API

L'intégration avec le CRM est souvent le point de blocage pratique des projets d'automatisation en courtage. Le niveau d'effort varie considérablement selon la solution utilisée.

WebCourtage

WebCourtage dispose d'une API REST documentée permettant la lecture et l'écriture sur les fiches clients, contrats et sinistres. L'intégration est la plus directe des solutions du marché français. Les endpoints pour la création d'un sinistre, la mise à jour d'une fiche client et l'attachement de documents sont stables et maintenus. Délai d'intégration estimé pour un extracteur email : 2 à 4 semaines de développement.

Otto Cube

Otto Cube offre des webhooks sortants et une API partenaire accessible sur demande. L'intégration est possible mais nécessite un accord partenaire avec l'éditeur. Les fonctionnalités d'import en masse via fichier structuré sont également disponibles comme option de secours. Délai estimé : 3 à 6 semaines, dont une partie pour l'obtention des accès API.

Bagheera (April Technologies)

Bagheera dispose d'interfaces d'import et de connecteurs en développement continu. L'accès programmatique dépend de la version et du niveau de contrat souscrit avec April Technologies. Pour les cabinets sur des versions récentes, un accès API est possible. Pour les versions plus anciennes, l'import via fichier CSV reste l'option la plus fiable. Délai estimé : 4 à 8 semaines selon la version déployée.

+Simple et solutions cloud récentes

Les solutions cloud de nouvelle génération comme +Simple sont construites autour des APIs dès leur conception. L'intégration est généralement la plus rapide et la plus maintenue. Ces plateformes exposent souvent des webhooks entrants qui facilitent l'injection de données depuis des systèmes tiers. Délai estimé : 1 à 3 semaines.

AS400 et systèmes legacy

L'AS400 n'expose pas d'API REST native. Deux approches sont possibles : l'import batch via fichier CSV déposé sur un répertoire FTP à intervalles définis (toutes les heures par exemple), ou un connecteur RPA qui simule la saisie dans l'interface graphique du logiciel. La première option est plus robuste et moins coûteuse à maintenir. La seconde est nécessaire si le système ne supporte pas l'import structuré. Dans les deux cas, le traitement n'est pas temps-réel mais reste compatible avec les contraintes opérationnelles d'un cabinet.

Ce qu'on extrait avec plus de 95 % de fiabilité et ce qui demande validation

La précision de l'extraction n'est pas uniforme. Elle varie selon la nature du champ, la façon dont l'information est formulée dans l'email, et la catégorie du message. Comprendre ces nuances évite de déployer une automatisation totale là où une validation humaine reste nécessaire.

Ce qui s'extrait avec une fiabilité supérieure à 95 %

• Adresses email de l'expéditeur : toujours disponibles dans les métadonnées, précision parfaite
• Dates formulées explicitement : "le 12 mai 2026", "pour le 1er juin", 96 à 99 % de précision
• Numéros de contrat mentionnés en objet ou en corps : 93 à 97 % si le format est reconnaissable
• Immatriculations de véhicule (format AA-000-AA) : 97 à 99 % grâce au format normé
• SIRET mentionné explicitement : 95 à 98 % sur les 14 chiffres
• Type de risque principal (auto, habitation, RC pro, etc.) : 92 à 96 % par classification sémantique

Ce qui demande une validation humaine systématique

• Descriptions libres de sinistre : à conserver textuellement, ne pas interpréter automatiquement
• Montants chiffrés sans unité explicite : "300" peut être des euros, une surface, une quantité
• Rapprochement client sans numéro de contrat : plusieurs homonymes possibles dans le CRM
• Modifications de contrat complexes (multi-avenants, résiliation-souscription simultanée)
• Emails en langue étrangère ou avec des fautes d'orthographe importantes sur les données clés

Ce que l'IA ne peut pas faire seule

L'IA n'a pas accès à l'historique de la relation client, aux engagements pris oralement, aux notes internes du cabinet. Elle ne peut pas évaluer si une demande est urgente sur la base d'une connaissance contextuelle du client. Elle ne détecte pas la fraude potentielle. Ces dimensions restent humaines, et c'est normal. La valeur ajoutée de l'IA est de libérer du temps pour qu'un courtier expérimenté puisse se concentrer sur ces jugements à valeur réelle.

Pour aller plus loin sur ce que l'IA peut apporter côté commercial dans un cabinet, l'article sur les prompts IA pour l'étude de besoin et l'argumentaire commercial développe les cas d'usage en phase de conseil.

Pièces jointes et classement automatique en GED courtage

Les emails en courtage arrivent rarement seuls. Une déclaration de sinistre est accompagnée de photos ou d'un constat amiable. Une demande de souscription contient un KBIS, un RIB, parfois une attestation d'assurance précédente. Une modification de carte grise s'accompagne du document original. Traiter l'email sans traiter ses pièces jointes, c'est automatiser à moitié.

Les pièces jointes les plus fréquentes et leur extractibilité

Voici les documents courants en courtage classés par facilité d'extraction automatique :

• RIB : extraction IBAN et BIC avec validation de la clé, fiabilité supérieure à 97 %. Le format est suffisamment normé pour une extraction quasi-automatique.
• Carte grise : extraction immatriculation, marque, modèle, date de mise en circulation, titulaire. Fiabilité de 90 à 95 % sur les cartes au format électronique récent.
• KBIS : extraction SIRET, dénomination sociale, code APE, adresse. Fiabilité de 92 à 96 %. Le SIRET peut être vérifié en temps-réel via l'API Sirene publique.
• Attestation d'assurance existante : extraction numéro de police, compagnie, dates de validité, garanties souscrites. Fiabilité variable (85 à 95 %) selon le format de l'assureur d'origine.
• Constats amiables : documents semi-structurés à fort enjeu. Extraction partielle des champs structurés (noms, coordonnées, immatriculations), description des circonstances conservée en texte brut pour validation humaine.
• Photos de sinistre : la vision artificielle peut catégoriser le type de dommage (dégât des eaux, carrosserie, incendie) mais pas l'évaluer. Classement automatique en GED possible, évaluation humaine obligatoire.

Classement automatique en GED

Chaque pièce jointe identifiée peut être automatiquement classée dans la GED du cabinet selon une arborescence définie : dossier client, puis sous-dossier par contrat, puis par type de document. Le nommage automatique des fichiers (KBIS_SIRET_DATE.pdf, RIB_CLIENT_DATE.pdf) évite l'accumulation de fichiers "attestation.pdf" non identifiables dans six mois. Cette logique de classement est cohérente avec celle décrite pour d'autres secteurs dans l'article sur l'automatisation des saisies email CRM.

Cas pratique chiffré sur un cabinet de 6 personnes traitant 250 emails par jour

Voici un cas représentatif d'un cabinet de courtage généraliste en Occitanie : 6 collaborateurs dont 2 assistants de gestion, 1 800 contrats actifs en portefeuille, 250 emails entrants par jour en moyenne.

Répartition du flux email avant automatisation

Avec deux assistants à temps plein (soit environ 16 heures de capacité quotidienne au total, hors réunions et téléphone), la charge de traitement des emails seuls dépasse de 70 % la capacité disponible. Le solde est absorbé par des heures supplémentaires implicites, des délais de réponse allongés, et des tâches de suivi renvoyées au lendemain.

Résultats après 6 mois d'automatisation

• Demandes d'attestation : automatisation complète à 94 %, incluant génération et envoi. Temps de traitement humain restant : moins de 5 minutes par jour pour les 6 % d'exceptions.
• Demandes de devis : création automatique de la fiche prospect et pré-remplissage du formulaire de recueil de besoins. Temps de traitement réduit de 8 à 2,5 minutes en moyenne.
• Déclarations de sinistre : extraction et pré-remplissage du dossier sinistre, validation humaine conservée pour la description et l'évaluation. Temps de traitement réduit de 12 à 3,5 minutes.
• Modifications de contrat : pré-remplissage de l'avenant avec validation humaine obligatoire. Temps de traitement réduit de 7 à 3 minutes.
• Questions administratives : routage automatique et réponses types pour 40 % des questions récurrentes. Temps de traitement réduit de 5 à 3,2 minutes en moyenne.

Conformité RGPD et Code des assurances

L'extraction automatique de données depuis des emails clients touche directement aux obligations RGPD et aux dispositions spécifiques du secteur assurantiel. Ce n'est pas un obstacle au projet, mais un cadre à intégrer dès la conception.

Base légale du traitement (article 6 du RGPD)

Dans le contexte d'un cabinet de courtage, le traitement automatisé des emails clients s'appuie généralement sur deux bases légales : l'exécution du contrat (article 6.1.b du RGPD) pour les emails liés à la gestion d'un contrat existant (déclaration de sinistre, modification, renouvellement), et l'intérêt légitime (article 6.1.f) pour les demandes de devis de prospects. La base légale doit être documentée dans le registre des traitements pour chaque type d'email traité.

Durées de conservation

L'article L.612-2 du Code des assurances fixe des obligations de conservation spécifiques pour les pièces contractuelles. Les données extraites depuis les emails doivent respecter ces durées dans le CRM, mais les données transitant dans le pipeline IA (copies temporaires pendant le traitement) ne doivent pas être conservées au-delà du temps nécessaire à l'extraction. Une politique de purge automatique des données dans le pipeline, typiquement dans les 24 à 72 heures suivant l'extraction, est la pratique recommandée.

Droits des assurés

Les assurés disposent de droits d'accès, de rectification et d'effacement sur leurs données personnelles. Le fait que ces données aient été extraites automatiquement d'un email ne modifie pas ces droits. Le cabinet doit être en mesure de produire, sur demande, la liste des données détenues et leur origine. La traçabilité du pipeline (log des extractions, source de chaque champ dans le CRM) est indispensable pour répondre à ces demandes.

Information des assurés

La politique de confidentialité du cabinet doit mentionner le traitement automatisé des emails entrants. Une clause courte dans les conditions générales de mandat ou sur le site du cabinet suffit généralement, à condition qu'elle soit intelligible et accessible. Mentionner le recours à des LLMs tiers (OpenAI, Anthropic, Mistral) pour le traitement des données est recommandé si ces modèles sont utilisés en API.

Pour un traitement plus approfondi de la conformité réglementaire en courtage, l'article sur la conformité DDA et les obligations du courtier complète utilement ce point, notamment sur les obligations de traçabilité du conseil.

Comment démarrer concrètement

La méthode la plus efficace n'est pas de déployer d'emblée l'ensemble du pipeline sur les cinq catégories d'emails. C'est de démarrer par une seule catégorie, de mesurer, et d'élargir progressivement.

Phase 1 : audit du flux email réel (1 à 2 semaines)

Avant toute ligne de code, il faut mesurer ce que vous avez vraiment. Cela signifie analyser un échantillon de 400 à 600 emails historiques pour identifier la distribution réelle par catégorie, le volume par catégorie, les champs les plus fréquemment saisis manuellement, et les pièces jointes les plus courantes. Cette phase révèle souvent des surprises : la catégorie que le cabinet pense traiter le plus n'est pas toujours celle qui consomme le plus de temps.

Phase 2 : POC sur la catégorie à plus fort impact (3 à 5 semaines)

On choisit la catégorie qui combine volume important et temps de traitement élevé. Pour la plupart des cabinets, c'est soit les demandes de devis, soit les demandes d'attestation (volume plus simple, automatisation plus rapide à valider). Le POC traite 200 à 400 emails historiques déjà gérés manuellement. On compare les extractions IA aux données réellement saisies dans le CRM pour mesurer la précision réelle sur vos propres emails, pas sur des benchmarks génériques.

Phase 3 : connexion CRM et mise en production sur une catégorie (4 à 6 semaines)

Le POC validé, on connecte le pipeline au CRM, on déploie l'interface de validation humaine pour les cas limites, et on met en production sur la catégorie choisie. Les deux premières semaines permettent d'affiner les prompts et les seuils de confiance sur des données réelles. Pendant cette phase, la saisie manuelle reste active en parallèle pour permettre la comparaison.

Phase 4 : généralisation progressive (2 à 4 mois)

Chaque catégorie supplémentaire s'ajoute après validation de la précédente. La généralisation sur les cinq catégories prend en général 2 à 4 mois selon la complexité du CRM et le volume d'emails traités. Les pièces jointes et le classement GED sont intégrés lors de cette phase.

Tensoria accompagne les cabinets de courtage en Occitanie et partout en France sur ce type de projet. Basés à Toulouse, nous intervenons en présentiel pour l'audit et la phase de POC, puis à distance pour le déploiement. Si votre cabinet traite plus de 100 emails par jour avec des saisies CRM répétitives, un audit d'automatisation permet de cadrer précisément ce qui est automatisable, le gain attendu et l'investissement nécessaire.

Pour comprendre l'écosystème complet des solutions IA disponibles pour les courtiers d'assurance, la page expertise courtage et assurance de Tensoria présente les cas d'usage par enjeu métier. Notre agence IA à Toulouse accompagne également des PME d'autres secteurs sur des problématiques de ressaisie similaires, avec des méthodes transposables au courtage.

Questions fréquentes

Pour aller plus loin

• Comparateur de garanties IA pour courtier : une fois les demandes de devis extraites automatiquement, comment l'IA aide à comparer les offres et à argumenter le conseil.
• IA et conformité DDA pour les courtiers : obligations réglementaires, traçabilité du conseil, et comment l'automatisation peut renforcer la conformité plutôt que la fragiliser.
• Prompts IA pour l'étude de besoin et l'argumentaire courtier : exploiter les données extraites des emails dans la phase commerciale et de conseil.
• Renouvellement de contrats et relances automatisées par IA : le prolongement naturel de l'extraction email vers l'automatisation du cycle de vie du contrat.
• Analyse de sinistre IA et workflow courtier : de la déclaration extraite automatiquement au workflow de traitement du dossier sinistre.
• Automatiser la saisie de commandes email CRM par IA : même architecture technique appliquée au secteur commercial, avec des points de comparaison utiles.
• Expertise IA pour le courtage et l'assurance : vue d'ensemble des cas d'usage disponibles pour les cabinets de courtage.