IA embarquée

Pourquoi

Donner à un dirigeant, ou à une banque premium, un accès conversationnel à ses propres données a une vraie valeur d'usage — mais seulement si le modèle de langage ne peut jamais écrire une requête libre ni franchir une frontière de tenant, de rôle ou de type d'accès. Ce processus rend cet accès possible sans jamais l'ouvrir sur une fuite de données.

Comment dans l'application

Le requêteur conversationnel ne laisse jamais le modèle générer du SQL : il ne peut choisir que parmi un catalogue fermé d'outils typés, un par type d'accès (ERP et financement, financement seul, ou investisseur), un seul catalogue étant chargé en mémoire pour une session donnée. Chaque appel d'outil passe par un point de passage unique qui refuse tout nom d'outil inconnu, rejette tout paramètre de portée que le modèle tenterait d'envoyer lui-même (identifiant de tenant, d'utilisateur, rôle), valide le reste contre un schéma strict, exécute la requête sur une connexion en lecture seule dédiée, puis vérifie que chaque ligne retournée appartient bien au tenant appelant — toute ligne étrangère fait échouer le lot entier, pas seulement la ligne fautive. Chaque appel est audité à ce même point de passage, jamais par le code métier qui traite la requête.

La connexion en base dédiée au requêteur ne dispose que du droit de lecture, sur une liste fermée de tables, avec un délai d'exécution strictement limité — aucune table sensible (utilisateurs, configuration de paiement, signature, journaux d'audit, dossiers KYB) n'y est jamais accessible.

Le catalogue investisseur continue d'anonymiser ce qu'il restitue — identité du fournisseur et de l'acheteur exclues, montants et durées regroupés par palier, secteur anonymisé par k-anonymat — bien que le marché public destiné aux investisseurs ait été fermé par ailleurs : ce catalogue interroge directement les données historiques, indépendamment des écrans fermés, et reste donc soumis à cette même anonymisation.

Garde-fous

• Un rôle d'administration plateforme ne peut jamais utiliser le requêteur — l'accès est explicitement bloqué avant même d'envisager un appel au modèle de langage, de même qu'un profil aux rôles contradictoires.
• L'accès est soumis à un contrôle d'abonnement premium, vérifié avant toute dépense d'appel au modèle — chaque refus, qu'il soit de rôle ou d'abonnement, est audité avant que l'erreur ne soit renvoyée.
• La liste des tables accessibles existe en double, une fois au niveau du rôle de base de données et une fois au niveau applicatif — les deux doivent concorder, et l'une agit avant même que l'autre ne soit sollicitée.