L'automatisation ne protège pas la qualité de souscription

Trois piliers pour passer d’une technologie d’enregistrement à une technologie d’intelligence

L’automatisation accélère. Elle ne protège pas.

Le marché parle beaucoup d’automatisation. En matière de souscription, elle est souvent associée à la vitesse. Pourtant la vitesse et la qualité ne sont pas synonymes.

En effet, un processus automatisé peut simplement rendre une mauvaise décision plus rapide. Or dans un portefeuille P&C, une décision incomplète peut peser sur un bilan pendant plusieurs années.

Le problème n’est donc pas d’automatiser plus mais bien de concevoir un système qui protège la qualité de décision.

Mon point n’est pas de dire que l’automatisation des processus est mauvaise. Les assureurs ont connu des percées significatives d’efficacité en investissant dans l’extraction de données, le routing de dossiers, les déclenchements conditionnels.

Ma thèse est plutôt qu’elles ne suffisent pas. Ces automatisations améliorent l’organisation du travail en déplaçant ou accélérant des tâches, mais elles ne répondent pas à la question centrale du souscripteur : que dois-je faire de ce risque ?

En assurance, accélérer la prise de décisions incomplètes ne fait que précipiter la constitution d’une dette de risque.

Cette dernière est dangereuse car elle n’apparaît dans aucun rapport bilanciel. Un portefeuille peut sembler stable en volume, en prime, et en nombre de contrats, tandis que les risques dérivent sous la surface. Pour cause : un système qui exécute les étapes sans réellement nourrir les décisions.

C’est le cœur de mon propos aujourd’hui : pour protéger la qualité de souscription, le système doit être pensé comme une couche de décision.

Voici les 3 partis pris technologiques sur lesquels nous nous sommes basés pour passer d’un System of Records à un System of Intelligence.

1 . Configuration Engine : transformer les guidelines en logique exécutable

Les politiques de souscription restent souvent dans des PDF, des spreadsheets, des notes produit ou des décisions de comité. Une règle connue mais non exécutée dans le workflow n’est pas une règle opérationnelle; c’est une intention.

Le Configuration Engine transforme ce corpus de consignes en logique exécutable. Il commence par tirer des règles versionnées et reproductibles d’inputs variés et multi-modaux : documents structurés ou non, transcripts, règles produit, guidelines internes, politiques de souscription, critères d’appétit, exclusions, seuils de référence, règles de referral.

Cette logique s’applique au stock comme au flux, aux nouvelles affaires comme aux polices déjà souscrites, aux API de distribution comme aux revues internes, instantanément.

L’instantanéité est primordiale car chaque année, les comités définissent de nouvelles règles qui prennent des années à imprégner le portefeuille. Pendant ce temps, le stock continue d’être souscrit selon des règles obsolètes. Le Configuration Engine rompt ce cycle en rendant la règle exécutable immédiatement, sur l’ensemble du stock et du flux.

Une règle qui vit dans le Configuration Engine est opérationnelle dès sa publication. Elle ne dépend pas d’un diffuseur, d’un email, d’une note de comité ou d’une formation.

Le Configuration Engine permet ainsi de passer d’une stratégie déclarée à une stratégie exécutée. L’appétit de risque n’est plus un document, il devient une logique informatique vivant dans un écosystème. Un assureur qui peut modifier ses règles et les voir appliquées immédiatement peut ajuster son appétit en temps réel. Il n’attend pas la prochaine campagne de renouvellement.

Le contrôle devient continu. C’est lui qui permet la vitesse, et non le raccourci.

2. Alerting & Risk Insights : du bruit à la priorisation

Une automatisation classique peut produire beaucoup d’alertes, mais une alerte n’est pas une décision. Le souscripteur n’a pas besoin de plus de bruit. Il a besoin de signaux priorisés, expliqués et reliés à une action.

Le module Alerting & Risk Insights permet d’ingérer et harmoniser un large panel de données : données de formulaires de risques, données de sinistralité, données externes, données géographiques, informations d’activité, données de prévention, documents non structurés, données financières, informations de localisation.

A partir de là, le système doit résoudre une difficulté technique majeure : relier ces données au bon assuré, au bon site, au bon contrat et au bon périmètre. Cette étape est souvent invisible, mais elle conditionne tout le reste. Une donnée externe non rattachée au bon contrat n’est qu’un signal orphelin.

Il s’ensuit un croisement de ces données avec les règles déterministes, les modèles spécialisés assurance, les heuristiques métier, les critères d’appétit, les seuils de criticité et les règles de referral. La valeur vient du croisement.

En guise d’apparté, un LLM générique peut lire, résumer et synthétiser de vastes quantités de données mais en souscription, la lecture ne suffit pas. Il faut appliquer une stratégie, gérer des règles, tracer les sources et prioriser les risques. Le modèle seul ne fait pas le système.

Il s’agit de construire un séquençage précis pour permettre au pipeline d’être efficient. Dans l’ordre, cela nous donne :

1. Application des filtres simples et peu coûteux : un changement d’activité détecté par une règle déterministe ne nécessite pas de modèle.
2. Règles déterministes
3. Modèles spécialisés assurance : Déploiement d’un modèle entraîné sur les données du secteur en cas de pattern complexe identifié dans les données de sinistralité par exemple

NB : Un LLM n’est sollicité qu’en cas de fort signal nécessitant une lecture de documents non structurés ou une synthèse complexe.

Ce séquençage concentre les ressources computationnelles où la valeur de signal est la plus élevée. Il évite de solliciter un modèle coûteux sur un dossier qu’une règle déterministe peut déjà traiter.

Cela permet également d’éviter la lassitude des alertes (ndlr: “alert fatigue”), car l’objectif n’est pas de maximiser le nombre d’alertes mais bien de maximiser la qualité de l’action à prendre.

10 recommandations actionnables valent mieux que 10 000 alertes.

3. Decision Support : préparer et défendre la décision

Le module Decision Support transforme ensuite les signaux en recommandations compréhensibles.

Pour cela, il doit répondre à des questions simples : que voit-on ? Pourquoi est-ce important ? Quelle source le justifie ? Quelle règle métier est concernée ? Quelle action est recommandée ? Quel niveau de priorité ?

Il doit également être intégré aux opérations, qu’elles soient l’interface Continuity, le portail du courtier partenaire, le core system, l’API, ou encore le tableau de pilotage, etc.

L’information doit naturellement arriver avant la décision, au bon niveau de granularité, dans le bon système. Un signal qui arrive après la décision est un rapport. Un signal qui arrive avant est une préparation.

Le souscripteur reste l’analyste et le décideur. Le système ne fait que préparer la décision.

Ceci étant dit, préparer la décision ne suffit pas. En matière de souscription, une recommandation doit également pouvoir être défendue. Le souscripteur doit comprendre pourquoi un risque est signalé et les équipes doivent pouvoir reproduire une décision. De leur côté, les auditeurs doivent comprendre le raisonnement.

Sans cela, une automatisation opaque entame la confiance.

Or la reproductibilité est la condition de cette confiance. Si deux souscripteurs posent la même question au même moment sur le même risque, le système doit produire la même recommandation. Si une règle est modifiée, le système doit documenter la version utilisée au moment de la décision. Si un auditeur demande le raisonnement complet, le système doit pouvoir le restituer de bout en bout.

Une architecture de décision exhaustive se doit de documenter a minima :

• les données utilisées,
• les règles appliquées,
• les signaux détectés,
• les sources mobilisées,
• les actions recommandées
• les versions des règles utilisées.

Chaque recommandation peut ainsi être retracée de la donnée source à l’action proposée. Cette documentation n’est pas un rapport de conformité. Elle est le fil conducteur qui rend la décision compréhensible, reproductible et défendable.

La traçabilité n’est pas une contrainte ajoutée à la fin. Elle fait partie de la conception du produit. Une décision automatisée non traçable n’est pas une décision de souscription défendable.

L’adoption comme preuve d’architecture

J’ajouterais qu’un système de souscription ne réussit pas parce qu’il est techniquement impressionnant. Il réussit parce que les équipes l’utilisent dans leurs décisions.

Si les souscripteurs contournent l’outil, ce n’est pas seulement un problème d’adoption. C’est souvent un problème de conception. L’outil doit arriver au bon moment pour réduire la friction entre la donnée, le risque et la décision.

Chez Continuity, nous partons de cette conviction : l’automatisation ne doit pas remplacer le jugement. Elle doit le rendre plus disponible, plus rapide et plus traçable.

Nous avons donc conçu la plateforme de manière à ce qu’elle relie le stock, le flux, les règles, les données et les décisions.

L’Assistant de Souscription filtre le flux, le SCAN analyse le stock en continu, tandis que l’API permet d’embarquer cette intelligence dans les systèmes existants. Il est important que l’intelligence vienne où le souscripteur travaille, pas où le système l’envoie.

La vitesse doit venir de l’intelligence, pas du raccourci

En résumé, en souscription, la vitesse n’a de valeur que si elle protège la décision.

L’automatisation seule peut accélérer la création de dette de risque. L’architecture de décision permet d’aller vite sans perdre la maîtrise du risque.

Le futur de la souscription n’est pas l’automatisation aveugle. C’est une automatisation gouvernée, compréhensible et centrée sur la décision.

La vitesse doit venir de l’intelligence, pas du raccourci.

–

Pierre Beauhaire

CTO / Co-founder, Continuity