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.

La même exigence vaut pour l'aide à l'usage du produit, pour l'assistante du site public, pour l'Assistant Marchés et pour l'apprentissage du modèle de risque : à chaque fois, l'IA explique, prépare ou mesure ; elle ne décide, ne valide, ne crée ni n'envoie rien. Chaque accès à une donnée passe par une règle appliquée par le serveur, jamais par le texte de la question.

Comment dans l'application

Le moteur des questions sur les données

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.

Qui a accès à quoi

La règle d'accès est portée par le compte, jamais par la question posée. Une même bulle, « Assistant Tauraco », sert deux modes ; l'icône ✨ « Assistant IA — vos données » est l'entrée dédiée aux questions chiffrées ; l'Analyse IA est le bouton de synthèse des tableaux de bord et du cockpit banque.

Un interrupteur de configuration côté serveur permet de réserver la bulle à l'offre Pro : la question d'une entreprise sans offre Pro reçoit alors un refus (402, offre Pro requise) et la bulle affiche l'invitation à passer Pro. Il n'est pas activé par défaut. L'Analyse IA suit strictement l'offre Pro : le dirigeant d'une entreprise de l'offre Gratuit n'en reçoit pas, côté serveur comme dans l'application.

La bulle : mode produit et mode données

Mode produit. Le serveur compose un savoir produit tiré du guide intégré (modules, écrans, offres lues dans le catalogue des offres, programme fondateurs, aide) et le transmet avec le profil de la personne (rôles, offre, langue — jamais un identifiant d'entreprise ni d'utilisateur). Aucun outil, aucune donnée : l'assistant explique, donne le chemin dans l'application et renvoie vers la documentation ; ce qu'il ne sait pas, il le dit.

Mode données. Quand l'entreprise est Pro, que l'assistant sur les données est en service sur le serveur (interrupteur ouvert, connexion en lecture seule configurée) et que le rôle dérive un type d'accès, la bulle interroge les données par le moteur du requêteur : un catalogue fermé d'outils typés en lecture seule (13 pour le profil entreprise : ventes, impayés et retards, historique de paiement d'un client, dettes et principaux fournisseurs, position et prévision de trésorerie, factures finançables, demandes de financement, offres reçues, décaissements et échéancier de remboursement). Le chemin est identique à celui de l'icône ✨ : paramètres de portée refusés, schéma strict, connexion en lecture seule, filtrage des lignes par tenant, audit de chaque appel. Un refus de rôle n'écrit aucune trace dans la bulle, qui reste simplement en mode produit. Les outils de l'ERP renvoient des montants dans la devise de chaque facture, une ligne par devise quand l'entreprise facture en plusieurs devises, sans jamais les additionner.

La bulle garde en mémoire les 10 derniers messages réels de la conversation (ni l'accueil, ni les erreurs HTTP ; un message de problème technique ou de refus du modèle, rendu comme une réponse normale, y reste) pour comprendre une question de suivi ; elle accepte jusqu'à 20 messages, 8 000 caractères par message et 24 000 au total, le premier et le dernier message venant de l'utilisateur. La conversation n'est pas enregistrée.

Plafonds, budgets et refus

Le jour est le jour UTC : compteurs et budgets repartent à minuit UTC. Le budget est vérifié avant chaque appel au fournisseur et consommé après ; il peut donc être dépassé d'au plus un appel au fournisseur par requête en cours : des requêtes simultanées passent toutes la vérification avant d'être comptées. Une valeur négative coupe l'assistant concerné — c'est l'interrupteur d'urgence — et 0 garde le défaut. Si le compteur est indisponible, les assistants authentifiés restent servis (le plafond cède, l'erreur est journalisée) ; l'assistante publique ne l'est plus, puisque son plafond global à échec fermé borne la dépense du jour quelle que soit l'adresse de connexion.

Les refus sont des phrases, pas des erreurs techniques : plafond ou budget atteint, conversation trop longue, offre Pro requise, service indisponible. Un refus du modèle lui-même (« je ne peux pas répondre à cette demande ») et une réponse coupée par la longueur (« réponse incomplète ») sont rendus tels quels, sans texte inventé.

Escalade : parler à quelqu'un

Aucun assistant ne transmet une conversation : aucune n'est conservée. Dans l'application, la bulle renvoie vers l'écran « Aide et support » et l'adresse de l'équipe, quand elle ne peut pas répondre ou qu'on le lui demande. Sur le site public, l'assistante renvoie vers le formulaire de contact, seul canal humain qu'elle propose.

L'assistante du site public (Aïssa)

Aïssa, présentée comme une assistante IA, répond aux visiteurs de tauraco.io sur les offres et les tarifs, le programme fondateurs, les appels d'offres, le financement et l'inscription, à partir d'un savoir recopié des pages publiques et du catalogue des offres. Elle n'accède à aucun compte, aucun dossier ni aucune donnée d'entreprise, et ne conserve aucune conversation. Elle dit explicitement que Tauraco n'est pas prêteur, ne collecte pas les capitaux et que le décaissement est effectué par l'institution. Le widget n'est monté que sur cinq pages de tauraco.io (accueil, financement, support, à propos, contact) : jamais sous tauraco.ai, ni sur l'inscription, la connexion, l'espace cabinet ou les pages légales. Elle accepte 12 messages au plus (le widget en envoie 10), 1 500 caractères par message, 12 000 au total, en français ou en anglais.

L'Assistant Marchés : les droits des modules

Cinq assistants à un coup (avis d'appel d'offres, opportunité CRM, candidature, dossier Collateral, recherche) préparent des éléments à valider, avec sources citées et incertitudes ; aucun ne crée ni n'envoie rien. À partir d'un objet enregistré (opportunité, candidature, dossier), l'assistant exige ce qu'exige la route de lecture du module source : le drapeau du module pour l'entreprise (sinon 404) et l'accès au module (sinon 403), les administrateurs de l'entreprise passant d'office la seconde porte ; un utilisateur de l'assistant ne lit donc pas par l'IA ce que le module lui refuse en direct. Le mode « texte collé » ne lit aucun autre module. Avant tout envoi au fournisseur, e-mails, téléphones, IBAN, identifiants légaux et noms de personnes connus sont masqués par des jetons stables, restaurés dans la réponse ; ce masquage repose sur des règles, et non sur une garantie. Le journal des appels de l'entreprise garde les identifiants, les compteurs de jetons et les passages cités sous leur forme masquée. Le budget quotidien de l'entreprise est vérifié avant chaque appel ; un appel abandonné au délai y compte une estimation prudente de ses jetons, faute de réponse à mesurer. Le fournisseur par défaut du module est un simulacre hors ligne ; le moteur réel se règle par configuration, et la ligne « Moteur » de l'écran dit lequel répond.

L'apprentissage du modèle de risque

Ce que le canari apprend : un seuil sur une seule variable, le montant TTC, à partir des factures d'un tenant que l'équipe a étiquetées « à risque » ou non (étiquette de risque). Le seuil est le milieu des moyennes des deux classes ; le sens (montant élevé ou faible = risqué) en découle. Les mesures — exactitude, précision, rappel, F1 et AUC — sont calculées sur les jeux de validation et de test. Ce n'est ni un modèle de langage, ni du fine-tuning, et il n'apprend rien des conversations des assistants. Le seuil ne vaut que dans une devise : un jeu en plusieurs devises est arrêté avec son motif, et un modèle ne note pas une facture d'une autre devise.

La barrière : un modèle produit est inscrit « expérimental » ; chaque promotion est manuelle et le passage à « actif » exige AUC ≥ 0,65, F1 ≥ 0,60 et précision ≥ 0,55. L'activation directe, réservée aux administrateurs de la plateforme, ne passe pas par cette barrière mais est tracée.

La provenance : seule une provenance « production », déclarée par le personnel à la création du jeu, rend un canari promouvable. Sans déclaration, ou pour le tenant de démonstration — quoi que dise sa configuration —, le job finit SYNTHETIC_NON_PROMOTABLE avec son motif : aucun modèle n'est produit. Ce résultat est attendu sur les données de démonstration, et il met la santé au jaune, pas au rouge. Tant que le chemin pour déclarer « production » le jeu d'un tenant client n'est pas décidé, aucun modèle appris sur des données réelles n'est promouvable.

Le cloisonnement : un jeu ne retient que les factures de son propre tenant ; un modèle ne note que les factures du tenant dont le jeu l'a appris (les autres reçoivent la règle déterministe de repli) ; les prédictions d'une facture ne sont lisibles que par son tenant ; le registre des modèles n'est lisible que par le personnel (ADMIN, OPS, SUPER_ADMIN) ; l'entraînement est une fonction de plateforme, que seuls ADMIN et SUPER_ADMIN lancent (OPS crée et suit les jobs). Les actions de lancement, de fin, de promotion et de retour arrière sont auditées sous le tenant de l'acteur.

La supervision : le processus d'entraînement donne régulièrement signe de vie, lu par la santé du système ; au démarrage, il reprend les lancements restés sans issue ; il n'entraîne que les jobs lancés et en attente (une demande qui vise un job déjà terminé, annulé ou inconnu est classée sans être rejouée, de sorte qu'un historique n'est jamais réécrit) ; et il marque en échec tout job « en cours » sans signe de vie depuis cinq minutes. La santé du « dernier entraînement » est verte pour REAL_CANARY_PASSED, jaune pour un job en attente, en file, en cours ou SYNTHETIC_NON_PROMOTABLE, rouge pour FAILED, BLOCKED_NO_DATA et CANCELLED.

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 aux données est soumis à un contrôle d'abonnement premium, vérifié avant toute dépense d'appel au modèle — chaque refus de l'icône ✨, qu'il soit de rôle ou d'abonnement, est audité avant que l'erreur ne soit renvoyée ; il ne consomme pas le quota.
• 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.
• Le client ne peut envoyer que des messages d'utilisateur et d'assistant, le premier et le dernier de l'utilisateur, sans message vide : aucune consigne ne passe par la conversation, et un dernier tour d'assistant ne peut pas souffler la réponse.
• Le savoir produit ne contient aucune donnée d'entreprise : il est identique pour tous, et le profil transmis ne porte aucun identifiant. Les résultats des outils repartent chez le fournisseur sans identifiant de tenant.
• Aucun assistant ne lit de fichier du serveur à l'exécution : leur savoir est recopié dans le code et vérifié par des tests contre les sources (guide, offres, pages publiques, garde-fous éditoriaux).
• Le service d'intelligence artificielle est un fournisseur externe, Anthropic (modèles Claude), appelé avec une clé principale puis, si elle est refusée, une clé de secours. Chaque appel écrit une ligne d'usage (route, modèle, jetons, durée) sans le contenu des questions ni des réponses et sans adresse IP.
• Leurs consignes interdisent aux assistants de donner un taux, de classer des offres ou de promettre un financement : ces conditions viennent de la banque, jamais de la plateforme.