L'IA au service de l'assurance
Optimiser l'analyse de risques grâce à l'Open Data et au Machine Learning.
Rendre lisibles des millions de points de données
La problématique
Le processus de souscription pour les entreprises est traditionnellement lent, manuel et basé sur des données souvent incomplètes ou obsolètes. Les souscripteurs perdent un temps précieux à croiser manuellement des sources d'informations éparpillées : Siren, bilans, vues satellites, réseaux sociaux.
La mission de Continuity
Utiliser l'IA et l'Open Data pour offrir une vision à 360° des risques professionnels, instantanément.
L'enjeu UX : « Complexity to Simplicity »
Comment rendre digestibles et actionnables des millions de points de données pour permettre une prise de décision en quelques secondes ?
Cinq nœuds de conception, cinq décisions
Trois produits, deux marchés, trois ans. Voici les cinq problèmes que j'ai eu à défaire, et ce que j'ai tranché à chaque fois.
Entrer par une recherche, pas par un formulaire
Un souscripteur qui ouvre l'outil ne connaît qu'une chose : le nom de l'entreprise à analyser. Le parcours démarre donc sur une recherche libre, et non sur un formulaire d'identification à remplir.
Tout le reste (SIREN, bilans, vues satellites, présence en ligne) est rapatrié derrière, sans qu'il ait à le demander. C'est la première décision qui fait tenir la promesse : une vision du risque en quelques secondes, pas en une demi-journée de recoupements manuels.
Faire tenir l'analyse d'un risque sur un seul écran
Un souscripteur ne décide pas à partir d'une donnée, mais à partir d'un ensemble : l'identité de l'entreprise, son contexte commercial, ses activités, ses finances et sa zone de risques. Tant que ces cinq blocs vivent dans cinq outils différents, la décision coûte une demi-journée.
L'Assistant réunit identification, contexte commercial, activités, finances et zone de risques dans une seule interface de décision. C'est ce que l'équipe appelait « complexity to simplicity » : rendre digestibles et actionnables des millions de points de données, sans les diluer.
Passer de l'analyse ponctuelle à la surveillance continue
Une étude de risque ne vaut que pour un instant T. Le Scan de portefeuille reprend périodiquement des milliers de contrats pour suivre leur évolution.
La difficulté n'était pas de calculer les alertes, mais de les rendre triables : une bibliothèque d'alertes hiérarchisées, et deux entrées de lecture, par contrat ou par alerte, selon qu'on gère un client ou qu'on traque un risque.
Ouvrir un deuxième marché sans alourdir l'interface
L'internationalisation ne s'arrête pas à la traduction. Il fallait passer du SIRET français au CIF espagnol, et adapter les algorithmes à l'Open Data local.
J'ai travaillé avec les Sales, le Marketing et la Data pour identifier les besoins des assureurs espagnols, puis adapté les interfaces de l'assistant de souscription aux règles d'un second marché, de façon à absorber ces variables sans ajouter d'étape au parcours existant. Les prototypes haute-fidélité ont permis de sécuriser les premiers partenaires en Espagne.
Rendre tangible la distance aux secours
Les assureurs évaluent la vulnérabilité d'un site à la proximité et à la rapidité d'intervention des secours : pompiers, police, SAMU. Un chiffre de distance ne suffit pas à le faire sentir.
J'ai conçu une carte interactive intégrée à l'Assistant : les centres de secours dans un rayon de 20 km, le temps de trajet et la distance calculés en temps réel, le tracé du parcours et une pulsation sur le centre le plus proche. La preuve de concept a été montée sur Figma Make à partir de mes maquettes, sur les données publiques des centres de secours et OpenStreetMap, sans dépendre de l'API Google Maps.
Rendre les équipes Ops autonomes
Le projet où la conception ne portait pas sur l'écran d'un client, mais sur le délai entre deux équipes.
Le problème
Personnaliser l'outil pour un nouveau client passait par ses fichiers de configuration, que seule l'équipe technique savait modifier. Les équipes Ops recueillaient le besoin dans un tableur, ouvraient un ticket, puis attendaient.
Le délai allait de plusieurs semaines à un mois par environnement. Non pas parce que la tâche était longue, mais parce qu'elle entrait en concurrence avec le développement produit dans la file d'une autre équipe.
Ce que j'ai fait
J'ai observé le quotidien des deux équipes avant de dessiner quoi que ce soit. Elles décrivaient la même chose dans deux langues : besoin métier d'un côté, paramètres techniques de l'autre. J'ai identifié côté Ops les personnes capables de faire le pont, et un atelier avec les développeurs a posé la contrainte : le format des fichiers de configuration ne bougerait pas à court terme.
J'ai produit deux versions. Une version longue, qui abandonnait la logique de fichier pour celle du tableur déjà utilisé par les Ops. Une version courte, qui gardait le fichier mais l'encadrait : droits par rôle, garde-fous à la saisie, validation avant application. J'ai tranché pour la version courte et gardé l'autre comme cap, documentée pour les évolutions suivantes. La réticence des Ops portait moins sur l'interface que sur le risque de casser un environnement client : détailler les sécurités d'édition a plus fait pour l'adhésion que les maquettes.
Le résultat
Un client assureur a fait paramétrer une dizaine de ses entités régionales, chacune avec ses propres règles de souscription, en quatre jours et par une seule personne de l'équipe Ops. Le même travail mobilisait auparavant deux équipes et plusieurs semaines par environnement.
J'ai conduit un retour d'expérience une semaine après la mise en production. Ce qui en ressort : « intuitive, visuelle, technique », « donne beaucoup plus de réactivité », « pour mettre à jour, c'est beaucoup plus rapide ». L'interface reste technique, et c'était assumé.
Ce que je referais autrement
J'ai évalué l'interface de paramétrage par un retour d'expérience une semaine après son lancement, c'est-à-dire par des impressions. Le plan de suivi analytique est arrivé plus tard dans l'année, et je n'ai jamais su combien d'environnements avaient réellement été configurés en autonomie six mois après. Aujourd'hui, les événements à mesurer font partie de la spécification, pas d'une étape ultérieure.
Les personnes que j'avais identifiées comme passerelles entre les Ops et la technique étaient aussi les plus à l'aise avec le paramétrage. Elles ont validé une interface qui reste technique, de leur propre aveu. Je testerais maintenant avec les profils les moins outillés, qui sont ceux pour qui l'autonomie change le plus de choses.
Les prototypes internationaux servaient des rendez-vous commerciaux : ils devaient convaincre autant qu'informer. Certaines fonctionnalités prospectives y sont apparues avant d'avoir été confrontées à un utilisateur. C'est efficace en prospection, et risqué quand ces écrans remontent ensuite dans la roadmap comme s'ils avaient été éprouvés.
Ce que j'en retire
Transformer des millions de points de données brutes en un outil de décision qui tient sur un écran : c'est ça que les souscripteurs achètent, pas la donnée elle-même.
Aligner les besoins stratégiques (ventes, expansion) et les contraintes techniques (R&D, algorithmes) fait partie du métier, pas de sa périphérie.
Penser les identifiants légaux, les sources de données et les règles locales dès le départ coûte bien moins cher que de les rattraper. C'est ce passage du designer d'interface au Product Thinker que je retiens de ces trois ans.