Déterministe, probabiliste ou génératif : choisir la bonne brique pour chaque décision d’assurance

Ce qu’il faut retenir

• Déterministe, probabiliste et génératif ne sont pas trois niveaux d’une même échelle. Ils produisent des objets différents : résultat de règle, estimation assortie d’incertitude et contenu construit sous contraintes.
• Le bon découpage commence par l’autorité de chaque sortie. Une brique générative peut préparer une formulation ; elle ne doit pas devenir implicitement le moteur de décision parce que son texte paraît convaincant.
• Une architecture hybride rend les frontières visibles : données d’entrée, résultat, preuve, validation, droit de modifier le dossier et voie d’exception.
• La recette suit les erreurs par conséquence. Elle teste séparément exactitude des règles, calibration et discrimination des scores, support factuel et format des sorties générées.
• Les changements sont versionnés par composant. Une règle, un seuil ou un prompt peut revenir en arrière sans imposer le remplacement simultané de toute la chaîne.

Nommer l’objet produit avant la technologie

Une « décision IA » peut désigner des réalités incompatibles : vérifier qu’une date précède une autre, estimer une probabilité, retrouver une clause, résumer une pièce ou rédiger un brouillon. Choisir un modèle avant d’avoir distingué ces objets crée une architecture où le même composant calcule, interprète et explique sans frontière testable.

La fiche de fonction commence par un verbe précis et un objet : calculer un montant selon une table, estimer la probabilité d’une classe, extraire une valeur présente, sélectionner une source, produire une synthèse à partir de faits fournis. Elle décrit ensuite qui consomme la sortie, quelle action elle peut déclencher et quelle preuve permet de la contester.

Une interface peut présenter ensemble plusieurs sorties, mais elle conserve leur nature. Un montant issu d’une règle n’est pas une suggestion linguistique. Un score n’est pas un fait sur une personne. Une phrase générée n’est pas une justification de la décision antérieure. Les libellés, les types de données et les journaux empêchent ces glissements.

Objet	Brique candidate	Preuve attendue	Interdiction
Calcul contractuel	règle déterministe versionnée	entrées, règle, version et résultat rejouable	laisser un texte généré fixer la valeur
Estimation	modèle probabiliste calibré pour la tâche	score, population, version et performance par segment	présenter le score comme une certitude
Recherche de preuve	index, filtres et classement	document, version, passage et critères	citer une source non récupérée
Rédaction	modèle génératif sous schéma	faits autorisés, sources et validations	inventer une donnée absente
Décision humaine	interface et procédure	identité, éléments consultés et motif	transformer une validation nominale en clic automatique

Attribuer l’autorité et le droit d’agir

L’autorité d’une sortie décrit ce qu’elle peut modifier. Une règle de présence peut bloquer l’envoi d’un formulaire. Un score peut seulement ordonner une file. Une synthèse peut préparer l’écran d’un gestionnaire. Une décision contractuelle peut nécessiter une règle approuvée ou une personne compétente. Ces droits sont appliqués par le système, pas seulement écrits dans une charte.

Le contrat comporte quatre niveaux : information, recommandation, préparation d’action et exécution. Le passage d’un niveau à l’autre exige une condition explicite. Une sortie générative ne gagne pas de droit parce qu’elle ressemble à un courrier fini. Un score élevé ne devient pas une décision si la fonction autorisée est le tri.

La séparation des tâches réduit le risque d’automatisation implicite. Le composant qui produit une estimation ne rédige pas sa propre preuve. Le générateur reçoit les résultats autorisés et les sources, mais il ne réinterprète pas silencieusement la table de décision. Le validateur contrôle les invariants sans demander au même modèle de s’auto-approuver.

Réserver le déterministe aux invariants explicites

Une fonction déterministe retourne le même résultat pour les mêmes entrées et la même version. Elle convient aux calculs, validations de format, correspondances exactes, droits, calendriers et tables de décision exprimables. Sa reproductibilité ne garantit toutefois pas que la règle métier soit juste, complète ou actuelle.

La table de décision est un artefact gouverné. Elle porte une date d’effet, une source, un propriétaire, des exemples et un chemin pour les cas non couverts. Les priorités sont explicites lorsque plusieurs règles s’appliquent. Les valeurs manquantes ne sont pas remplacées par une hypothèse commode ; elles déclenchent une erreur typée ou une file d’exception.

Les tests comprennent les limites, les dates charnières, les valeurs nulles, les unités, les arrondis, les chevauchements et les contradictions. Un jeu de caractérisation fige le comportement existant avant une refonte. Les résultats attendus sont relus avec la source métier, puis exécutés à chaque changement.

Le déterministe atteint sa limite quand la variable utile doit être inférée à partir d’un signal bruité ou d’un langage libre. Multiplier des expressions régulières peut créer un faux sentiment de contrôle. Dans ce cas, une brique probabiliste ou générative prépare une observation structurée, puis une règle valide sa forme et décide ce qu’elle peut alimenter.

Interpréter un score comme une estimation située

Un modèle probabiliste estime une distribution ou un score à partir de données. Un score de 0,8 n’a de sens qu’avec une définition de la cible, une population, une période, une méthode de mesure et une calibration observée. Il ne signifie pas automatiquement « 80 % de certitude » pour chaque dossier.

La discrimination répond à la capacité d’ordonner ou séparer des classes. La calibration compare les probabilités annoncées aux fréquences observées sur une population. Une bonne discrimination peut coexister avec une mauvaise calibration. Le choix du seuil dépend ensuite du coût des faux positifs, faux négatifs et abstentions, pas seulement de la courbe globale.

Les travaux sur la calibration des réseaux neuronaux modernes montrent, dans leurs expériences, que des réseaux peuvent être mal calibrés et étudient notamment le temperature scaling. Ce résultat n’établit ni la calibration d’un modèle assurance ni l’efficacité universelle d’une correction. Chaque artefact, population et période doivent être mesurés.

Un score est conservé avec la version du modèle, les caractéristiques admissibles, la date et le statut du seuil. L’interface évite les décimales trompeuses lorsque la précision réelle ne les justifie pas. Elle affiche la fonction du score : priorisation, contrôle supplémentaire ou information, ainsi que le chemin prévu hors domaine.

Test probabiliste	Question	Découpage utile	Signal d’arrêt
Discrimination	les cas ciblés sont-ils mieux ordonnés ?	classe, produit, canal et période	segment critique sous la baseline
Calibration	les scores correspondent-ils aux fréquences ?	tranches de score avec volume	écart instable ou volume insuffisant
Couverture	quelle fraction respecte le seuil d’usage ?	cas acceptés, refusés et inconnus	reprise humaine non absorbable
Gravité	quelles conséquences ont les erreurs ?	matrice métier, pas seulement classe	erreur interdite observée
Dérive	les entrées et issues changent-elles ?	temps, source et population	référence devenue non comparable

Borner la génération par un contrat de contenu

Un modèle génératif construit une séquence. Il est utile pour reformuler, résumer, transformer un contenu vers un schéma ou préparer une communication. Cette souplesse ne garantit ni fidélité, ni exhaustivité, ni respect d’une règle. Le contrat précise les faits qu’il peut employer, ceux qu’il doit citer, les champs obligatoires et le comportement quand l’information manque.

Le système sépare contenu source, instruction et données calculées. Les résultats d’une règle sont injectés sous forme structurée et ne peuvent pas être recalculés par la prose. Les passages documentaires possèdent des identifiants. La sortie relie les affirmations vérifiables à ces identifiants ou indique qu’aucune preuve admissible n’a été fournie.

Le schéma de sortie réduit l’ambiguïté : champs, types, valeurs autorisées, longueur et statut d’abstention. Un parseur vérifie la syntaxe ; des contrôles déterministes vérifient les références, unités, identifiants et contraintes métier. La réussite du parseur ne prouve pas la véracité. Un JSON parfaitement valide peut contenir un montant inventé.

L’évaluation générative sépare fidélité aux entrées, couverture des points requis, absence d’affirmations non soutenues, sécurité, ton et utilité. L’article sur l’attribution des citations dans un RAG assurance détaille le passage de la récupération à la preuve. Une note de style ne compense pas une affirmation critique sans source.

Assembler sans diluer les responsabilités

Une architecture hybride fonctionne comme une suite de contrats. Chaque composant reçoit un objet typé, produit un objet typé et n’exerce qu’une autorité définie. L’orchestrateur conserve les versions et décide du chemin ; il ne cache pas les transformations dans un prompt monolithique.

1. Entrée : droits, complétude et format contrôlés par règles.
2. Observation : extraction ou classification produit valeurs, provenance et incertitude.
3. Décision : table et seuils versionnés déterminent le chemin autorisé.
4. Preuve : recherche localise les documents et passages applicables.
5. Rédaction : génération emploie uniquement faits et preuves autorisés.
6. Validation : schéma, invariants, citations et règles sont contrôlés avant affichage.
7. Action : personne ou service autorisé accepte, corrige ou escalade.

Le guide sur l’architecture RAG vérifiable montre comment tracer document, fragment, contexte, affirmation et citation. La même discipline vaut pour les autres briques : un résultat probabiliste conserve sa population de référence ; une règle conserve sa source ; un brouillon conserve les données et preuves utilisées.

Les échecs sont des états, pas des textes libres : entrée incomplète, hors domaine, score non fiable, contradiction documentaire, format invalide ou contrôle bloquant. Chaque état possède une voie. Cette taxonomie permet de mesurer la qualité réelle et d’éviter les nouvelles tentatives identiques.

Scénario synthétique : préparer une réponse sur une pièce manquante

Exemple pédagogique, sans client ni résultat de production. Un service reçoit un message lié à un dossier et doit préparer l’écran du gestionnaire. L’objectif est de reconnaître si le client annonce une pièce, de vérifier si cette pièce figure déjà au dossier, de retrouver la liste documentaire applicable et de proposer un brouillon. Le système ne décide ni garantie ni indemnisation.

Une extraction probabiliste repère l’intention et le type de pièce avec une provenance textuelle. Si le message est hors domaine, ambigu ou sous le seuil du segment, la chaîne s’arrête. Une règle compare ensuite le type normalisé au registre du dossier et à la liste de pièces autorisée pour le produit et la version.

La recherche documentaire localise la notice ou la procédure applicable. Le générateur reçoit le statut calculé, les passages autorisés et un modèle de communication. Il peut expliquer que la pièce semble absente et demander une vérification ; il ne peut ni changer le statut du dossier ni affirmer une obligation qui n’apparaît pas dans les sources.

Le validateur contrôle l’identité du dossier, les références, la présence de la pièce dans le texte, les citations et les formulations interdites. Le gestionnaire voit séparément le fait observé, le résultat de règle, les passages et le brouillon. Une correction porte sur l’objet concerné : taxonomie, règle, corpus ou rédaction.

Étape	Erreur injectée en recette	Comportement attendu
Extraction	le client cite une pièce sans dire qu’il l’envoie	incertitude ou abstention, provenance visible
Règle	deux versions documentaires se chevauchent	contradiction bloquante et file d’exception
Recherche	seule une ancienne procédure est retrouvée	source exclue par version, aucune compensation générative
Génération	le contexte ne contient aucun délai	aucun délai inventé dans le brouillon
Validation	référence de dossier modifiée dans le texte	rejet déterministe avant affichage

Tester chaque contrat avec la bonne mesure

La recette commence par des tests unitaires de règles et de schémas, puis évalue les modèles sur des jeux séparés. Elle se termine par des scénarios de bout en bout. Un bon score global ne remplace pas les tests de frontières : mauvaise version documentaire, score absent, contradiction, outil indisponible ou personne non autorisée.

1. Décrire la fonction. Objet, autorité, entrées, sortie, preuve et état d’échec.
2. Geler la référence. Règles actuelles, processus humain ou artefact existant avec ses limites.
3. Constituer les cas. Cas nominaux, limites, exceptions, négations, données manquantes et segments rares.
4. Tester isolément. Exactitude des règles, score et calibration, fidélité et citations génératives.
5. Tester les interfaces. Types, versions, droits, unités, timeouts et échecs de dépendance.
6. Rejouer la chaîne. Relier toute sortie aux artefacts exacts et au comportement attendu.
7. Observer silencieusement. Comparer sans influencer le dossier, faire relire les désaccords.
8. Ouvrir un périmètre réversible. Volume plafonné, groupe de référence, seuils et coupe-circuit.

Les jeux de mise au point et de mesure finale sont distincts. Les cas ajoutés après un échec rejoignent une suite de non-régression, mais ne sont pas présentés comme une preuve indépendante de généralisation. Les volumes et périodes accompagnent toujours les pourcentages.

La revue du système documente également les interactions : une extraction fausse peut déclencher une règle correcte sur une mauvaise valeur ; une bonne recherche peut alimenter une génération infidèle ; un brouillon fidèle peut être envoyé par la mauvaise personne. Le score de bout en bout est donc expliqué par les erreurs d’étage.

Choisir avec une matrice d’impact et de preuve

Le choix de brique ne dépend pas uniquement de la complexité apparente. Une fonction simple à fort impact peut exiger une règle et une double validation. Une tâche linguistique complexe mais sans action directe peut accepter une génération supervisée. L’équipe positionne chaque fonction selon variabilité des entrées, formalisation possible, conséquence de l’erreur, disponibilité d’une preuve et besoin d’explication.

Situation	Brique dominante	Complément	Condition de passage
règle stable et exhaustive	déterministe	interface d’exception	source et tests de frontière
signal bruité, cible définie	probabiliste	seuil et abstention par impact	jeu indépendant et dérive suivie
transformation linguistique	génératif	faits structurés et validateur	fidélité, format et preuve
parcours à étapes	hybride	orchestrateur typé	responsabilité de chaque frontière
cas rare ou impact élevé	humain	outils de préparation	compétence, délai et traçabilité

Le model routing en assurance peut sélectionner une route après cette décomposition. Il ne doit pas servir à masquer une autorité mal définie. Le routeur choisit parmi des procédures déjà admissibles ; il ne décide pas qu’une brique devient soudain autorisée sur un cas sensible.

Versionner, surveiller et revenir en arrière

Le registre associe chaque exécution aux versions de règles, modèles, seuils, prompts, corpus, schémas et validateurs. Une modification de table de décision ne se confond pas avec une mise à jour de génération. Cette granularité permet une analyse d’incident et un rollback ciblé.

Les indicateurs restent alignés sur la fonction : erreurs de règle et exceptions, distribution et calibration des scores, affirmations sans support, rejets de schéma, corrections humaines, délais et actions effectivement déclenchées. Les données de suivi sont segmentées sans créer un nouvel entrepôt de documents sensibles.

Le monitoring recherche aussi les changements de composition. Une moyenne stable peut cacher une hausse d’une langue, d’un produit ou d’un format mal couvert. Une dérive déclenche l’analyse de la brique concernée ; elle ne provoque pas automatiquement un réentraînement ou un changement de seuil.

Le NIST AI RMF propose les fonctions Govern, Map, Measure et Manage pour structurer le risque. Les orientations NIST AI 600-1 ciblent l’IA générative. Ces cadres n’attribuent pas eux-mêmes l’autorité métier : l’organisation doit traduire ses usages en responsabilités, mesures et réponses.

La réversibilité est testée avant le pilote. Une règle revient à sa version précédente, un seuil repasse en observation, la génération est désactivée au profit d’un modèle de texte fixe, ou le parcours rejoint une file humaine. Les dossiers en cours gardent leur état et les décisions déjà prises restent attribuables.

Sources et références primaires

• On Calibration of Modern Neural Networks — étude primaire de calibration ; résultats circonscrits aux expériences publiées.
• Model Cards for Model Reporting — proposition primaire de documentation des modèles et de leurs usages.
• Datasheets for Datasets — proposition primaire pour documenter composition, collecte et usages des jeux de données.
• NIST AI Risk Management Framework et profil Generative AI — documents officiels.
• Règlement (UE) 2024/1689 — texte officiel ; aucune qualification juridique individuelle n’est formulée ici.