Un produit métier IA pour une profession réglementée
Un conseiller en gestion de patrimoine remplissait huit documents réglementaires à la main après chaque rendez-vous. Vous faites peut-être la même chose, sous une autre forme d’ailleurs ? L’application capte le rendez-vous à la voix ou à l’écrit et les remplit, sans qu’aucune donnée client ne quitte sa machine en clair, j’en ai à la fois fait une solution pérenne, mais un argument marketing fort pour cette société de courtage en assurance.
- Compétence
- Outillage technique
- Ce que ça prouve
- Prouve la construction d’un produit métier réel avec l’IA, pour une profession réglementée, avec des contraintes de confidentialité qui ne sont pas négligeables
- Utile à
- celles et ceux qui veulent à la fois résoudre des problématiques fortes et capitaliser sur ce travail réalisé d’un point de vue commercial et marketing
Huit documents réglementaires, remplis pendant que le client parle
Chaque document mal rempli, chaque champ oublié, chaque incohérence entre deux dossiers peut coûter bien plus à un courtier en assurance qu’une simple remontrance : les documents produit engagent la responsabilité de la société. Chaque client en génère huit, remplis à la main à partir d’un rendez-vous. Les mêmes informations ressaisies huit fois, dans huit fichiers.
Mesure faite sur un dossier réel pendant le projet : soixante-six champs demandés, dont une large majorité pour des documents qui ne concernaient probablement pas la cliente. Le problème n’était pas seulement la saisie, c’était aussi qu’on demandait beaucoup trop. Vous demandez peut-être, vous aussi, plus que ce dont vous avez vraiment besoin.
L’entrée se fait donc par la parole. Simple. Vraiment. Dictée transcrite en local, dépôt d’un transcript, ou texte collé. Il sort d’un rendez-vous, raconte, et l’application range. Puis elle dit ce qui manque, document par document, en langage clair.
La machine retranscrit, elle ne conseille pas
Il retranscrit. Rien de plus. L’outil remplit les modèles officiels réels du cabinet : pointillés, cases à cocher, tableaux variables. Il n’invente aucun contenu réglementaire et ne compose aucune recommandation. La responsabilité reste celle du conseiller. Si vous construisez ce genre d’outil pour votre métier, posez-vous la même question avant d’écrire la moindre ligne de code.
Les données clients sont chiffrées : phrase de passe dérivée au lancement, clé en mémoire uniquement, aucune clé sur le disque, noms de fichiers opaques. Conséquence directe : ni l’hébergeur ni le fournisseur de modèle ne peuvent savoir de quel client il s’agit. Vous imaginez la même exigence sur vos propres dossiers clients ? C’est possible.
Une vingtaine de scripts de vérification gardent le produit, dont un qui refuse de laisser partir une donnée client en clair.
Montrer le produit avant l’architecture
La première démonstration a été faite sous forme d’application finie, pas de schéma technique, parce qu’un professionnel qui n’a jamais écrit une ligne de code de sa vie ne peut pas se projeter dans un diagramme d’architecture, aussi propre soit-il, alors qu’il comprend immédiatement une application qu’il peut cliquer, remplir et casser lui-même en cinq minutes.
Le marché du courtage a déjà des CRM et des comparateurs génériques. Ce produit épouse la façon de travailler d’un professionnel précis. Voilà ce qui le rend utile, pas une fonctionnalité de plus.
Ce qui n’est pas encore prouvé
Le produit est fonctionnel : les huit documents se génèrent, le chiffrement tient, le comparateur de solutions fonctionne. Mais il n’a pas encore été utilisé sur un dossier client réel de bout en bout. Le test en conditions réelles est prévu.
Tant qu’il n’a pas eu lieu, ce cas raconte ce qui a été construit et comment, pas un gain de temps chiffré. Un chiffre inventé ici coûterait plus cher que l’absence de chiffre, et je préfère vous le dire franchement plutôt que d’inventer une statistique qui vous rassure sur le moment.