API, auto-hébergé ou hybride : comment une entreprise réglementée peut faire traiter ses documents par un LLM, et qui le mène jusqu'en production

Une entreprise réglementée peut faire traiter ses documents par un LLM via l'API d'un fournisseur sous contrat, sur ses propres serveurs ou avec un dispositif hybride qui combine les deux. Prenez l'API si chaque classe de documents peut sortir sous contrat, et l'auto-hébergement si aucune ne le peut. Un dispositif hybride n'est rentable que s'il y a beaucoup de documents de chaque côté, car vous exploitez deux systèmes et la table de routage est à votre charge. Pour savoir quels prestataires ont mené un tel système jusqu'en production, demandez les traces qu'il laisse derrière lui.

Comment les trois approches se comparent-elles ?

L'article sur le périmètre fermé, dont le lien figure plus haut, les compare en détail. Avec l'API d'un fournisseur, vos données sont couvertes par le contrat et par les contrôles de données auxquels le fournisseur s'engage. La page d'OpenAI sur les contrôles de données, consultée le 8 octobre 2026, indique que les données envoyées à son API depuis le 1er mars 2023 ne servent pas à l'entraînement, sauf si vous y consentez explicitement (opt-in).

La même page indique que les logs de surveillance des abus, qu'OpenAI utilise pour détecter les usages abusifs et qui peuvent contenir des prompts et des réponses, sont conservés par défaut jusqu'à 30 jours. Ils sont conservés plus longtemps si la loi l'exige ou si c'est raisonnablement nécessaire pour protéger les services d'OpenAI ou des tiers contre un préjudice. Exclure votre contenu de ces logs nécessite l'approbation préalable d'OpenAI.

Dans le service de modèles managé d'une plateforme cloud, le fournisseur cloud fait tourner le modèle pour vous, et certains de ses modèles sont vendus dans le cadre d'un contrat cloud que vous détenez peut-être déjà. La documentation de Microsoft indique que, pour les modèles vendus par Azure, vos prompts et les réponses du modèle ne sont pas accessibles à OpenAI ni aux autres fournisseurs de ces modèles. La documentation d'Amazon Bedrock indique que les fournisseurs de modèles n'ont pas accès aux prompts des clients ni aux réponses du modèle. Le modèle tourne malgré tout sur les serveurs du cloud, et c'est votre équipe risques qui décide si cela compte comme l'intérieur de votre périmètre, c'est-à-dire du réseau et des systèmes que votre entreprise contrôle.

Un modèle à poids ouverts auto-hébergé, c'est-à-dire un modèle que son éditeur publie pour que chacun puisse le télécharger et le faire tourner, fonctionne sur des serveurs que vous contrôlez : aucun document ne part donc vers un fournisseur de modèles. En contrepartie, l'exploitation des serveurs et du modèle revient à votre équipe.

À quoi ressemble un dispositif hybride en pratique ?

Un dispositif hybride réunit dans un même pipeline une route externe (l'API d'un fournisseur ou un service managé dans le cloud) et une route interne. La logique qui décide où va chaque document s'appelle le routeur. Il existe trois schémas de base, qui peuvent se combiner :

• Les documents publics ou à faible risque, comme les règles et les guides publiés, vont à l'API, et les dossiers d'identité des clients restent à l'intérieur
• Chaque document passe d'abord par le modèle auto-hébergé, et ceux sur lesquels il échoue ne sortent que si leur classe le permet
• Les identifiants, comme les noms, sont remplacés par des marqueurs à l'intérieur du périmètre avant que le texte parte vers l'API

Qui décide quels documents peuvent aller vers une API ?

C'est l'équipe risques ou la protection des données qui décide, et l'ingénierie traduit la décision en code. Mettez-la d'abord sur papier sous la forme d'un court tableau, appelé ici table de routage. Pour chaque classe de documents, elle indique les routes autorisées, si le masquage est obligatoire et combien de temps le fournisseur peut conserver le texte.

Le pipeline doit ensuite déterminer la classe de chaque document. Les signaux que vous maîtrisez sont plus sûrs que le jugement d'un modèle : le canal par lequel le document est arrivé, l'expéditeur, le type de document. Quand les signaux divergent, la classe la plus stricte l'emporte, et un document que personne ne sait classer reste à l'intérieur.

Ce contrôle s'exécute à l'intérieur du périmètre. Un contrôle qui demande à l'API externe si un document peut sortir l'a déjà envoyé. Une modification de la table de routage passe en revue et reçoit un numéro de version et une date, comme toute modification de code.

Peut-on masquer le texte et l'envoyer quand même à l'API ?

Parfois, dans certaines limites. Des outils open source comme Presidio remplacent les noms, les numéros de compte et les autres identifiants par des marqueurs, ou les chiffrent avec une clé. Si vous gardez la clé à l'intérieur, l'étape de déchiffrement de Presidio remet les vraies valeurs en place au retour de la réponse ; avec des marqueurs, vous tenez votre propre table indiquant quel marqueur correspond à quelle valeur. Les données masquées de cette façon sont dites pseudonymisées.

Le Comité européen de la protection des données a adopté les lignes directrices 01/2025 sur la pseudonymisation le 16 janvier 2025, dans une version soumise à consultation publique. Selon ces lignes directrices, de telles données restent des données à caractère personnel si des informations supplémentaires permettent de les rattacher à une personne. Elles ajoutent qu'il en va ainsi même lorsque le texte masqué et ces informations sont détenus par des parties différentes, par exemple quand le fournisseur détient le texte et vous la table ou la clé.

La Cour de justice de l'UE s'est penchée sur la même question en septembre 2025, dans l'affaire C-413/23 P, au titre des règles de protection des données applicables aux organes de l'UE. Elle a jugé que les données pseudonymisées ne sont pas des données à caractère personnel dans tous les cas et pour toute personne : selon les circonstances, le masquage peut empêcher toute personne autre que l'entreprise qui a masqué les données d'identifier les personnes concernées. Pour vous, qui détenez la table ou la clé, les données restent des données à caractère personnel. Demandez à votre conseil en protection des données ce qui en découle pour vos contrats.

La détection est la deuxième limite. Presidio repère les données personnelles avec un modèle qui reconnaît les noms de personnes, de lieux et d'organisations, et avec des règles qui reconnaissent des formats connus, comme les numéros de compte. Sa documentation indique que, la détection étant automatisée, « il n'y a aucune garantie que Presidio trouve toutes les informations sensibles ». Les ratés typiques dans le travail sur les documents :

• La reconnaissance optique de caractères (OCR), l'étape qui transforme les scans en texte, lit mal un nom, et le détecteur n'y voit plus de nom
• Une personne est identifiée sans aucun nom, par un intitulé de poste dans une petite société ou par un montant unique à une date donnée
• Le champ masqué est justement celui dont vous avez besoin : si la tâche consiste à extraire le nom de la contrepartie, le texte masqué ne le contient plus

Avant que quiconque approuve une route avec masquage, faites marquer à la main chaque identifiant dans un échantillon de vos propres documents, puis comptez ce que le détecteur a manqué.

Que se passe-t-il quand un document prend la mauvaise route ?

Dans un dispositif hybride, une fuite est un bug de routage. Un passeport scanné joint à un avis de routine, ou le message d'un client cité en bas d'un e-mail transféré, peut faire passer du contenu restreint sur la route externe. Classez chaque pièce jointe séparément, et traitez l'historique cité dans un fil comme faisant partie du contenu.

Concevez le système pour qu'une mauvaise décision arrête le document au lieu de l'envoyer à l'extérieur. L'article sur le périmètre fermé, dont le lien figure plus haut, traite du volet réseau : la route interne n'a ni clés ni mots de passe pour le fournisseur externe, ni chemin réseau vers lui. Ajoutez une règle : quand le modèle auto-hébergé est indisponible, sa file attend ou passe à des personnes, et ne bascule jamais vers l'API.

Si un document sort malgré tout par erreur, le journal des routes indique quels documents sont sortis, quand et vers quel fournisseur. Le contrat du fournisseur indique combien de temps il peut les conserver. Traitez-le comme un incident avec votre équipe protection des données, qui décide s'il doit être notifié.

Comment tester la qualité quand deux modèles font le travail ?

Un jeu de recette est un ensemble de documents réels accompagnés de la bonne réponse pour chacun, qui sert à décider si le système passe. Les deux modèles d'un dispositif hybride répondent différemment : une seule note pour tout le pipeline masque donc la route la plus faible.

Vous ne pouvez pas non plus tester le modèle de l'API sur des documents restreints, puisqu'ils n'ont pas le droit d'y aller. Le jeu de recette commun que l'article sur le périmètre fermé recommande pour chaque route ne peut donc contenir que des documents autorisés sur les deux routes. Utilisez-le pour comparer les deux modèles, et donnez à chaque route son propre jeu, plus large, tiré des classes qu'elle traite. Quand le fournisseur retire le modèle de l'API, cette route est notée à nouveau avant la bascule.

Que faut-il pour exploiter les deux routes ?

Un dispositif hybride double les contrats : les conditions du fournisseur et son accord de traitement des données, plus le contrat de matériel ou de cloud sur lequel repose le modèle auto-hébergé. L'Autorité bancaire européenne rappelle que DORA, le règlement de l'UE sur la résilience opérationnelle numérique, s'applique depuis le 17 janvier 2025. Les entités financières de l'UE relevant de son champ d'application doivent tenir un registre de leurs accords contractuels avec des prestataires tiers de services TIC (technologies de l'information et de la communication). L'ajout d'un fournisseur de modèles externe est une question qui concerne ce registre, et c'est votre équipe conformité qui y répond.

L'exploitation double aussi. Le fournisseur plafonne le nombre de requêtes que vous pouvez envoyer par minute et retire des modèles selon son propre calendrier : quelqu'un doit donc surveiller l'un et l'autre. Vos propres serveurs demandent une planification de capacité et quelqu'un d'astreinte la nuit. Le routeur et la couche de masquage, vous êtes seul à les exploiter.

Suivez chaque jour la part des documents sur chaque route, par classe. Quand le modèle auto-hébergé voit chaque document en premier, une part croissante envoyée à l'API signifie que davantage de documents sortent et que la facture de l'API augmente. La cause est souvent un nouveau template de document que le modèle interne ne sait pas lire.

Que doit montrer la piste d'audit pour chaque document ?

Conservez sa classe et les signaux qui l'ont déterminée, la version de la table de routage et la route empruntée. Ajoutez s'il a été masqué et avec quelle version du détecteur, ainsi que le fournisseur et la version exacte du modèle qui a répondu. Avec cet enregistrement, « afficher tous les documents de cette classe sortis du périmètre au trimestre dernier » tient en une seule requête en base de données.

Quand un dispositif hybride est-il le mauvais choix ?

Une seule route suffit quand tous vos documents relèvent d'une seule classe de données. Avec un faible volume, une deuxième route coûte plus cher qu'elle ne fait économiser, et une personne peut traiter ce que le modèle auto-hébergé ne sait pas lire. Un dispositif hybride hérite aussi de toute lacune dans la couverture de nuit des serveurs auto-hébergés. Et quand un service managé dans le cloud de votre région respecte les règles pour toutes les classes, il vous offre un seul contrat et une seule exploitation.

Comment vérifier qu'un prestataire a mené ce type de système du pilote à la production ?

Cet article ne classe aucun prestataire, car n'importe quelle société peut écrire « IA en production » sur son site. Un système en production laisse des traces qu'un pilote ne laisse pas : demandez donc les suivantes, sans les informations relatives aux clients.

• La table de routage sous forme de document versionné, et le nom de la personne qui approuve les modifications
• Quelques lignes du journal des routes, avec la classe, la route, la version de la table de routage et la version du modèle pour chaque document
• La dernière exécution d'un test qui envoie un document restreint vers le fournisseur externe et montre qu'il est bloqué
• Les notes de recette par route et par release, y compris la release faite quand un fournisseur a retiré un modèle
• Si la conception prévoit du masquage, les ratés mesurés du détecteur sur les propres documents d'un client
• Le runbook (instructions écrites pour les opérateurs) en cas de panne de chaque route, et qui est d'astreinte
• Un appel avec la personne qui exploite le système aujourd'hui

Quels sont les signaux d'alerte ?

• Le masquage est présenté comme la réponse complète à la question de la confidentialité, sans taux de ratés mesuré
• Le contrôle qui décide de ce qui peut sortir interroge l'API externe elle-même
• Le trafic bascule vers l'API quand le modèle interne est indisponible, ce qui fait sortir avec lui des documents restreints
• Aucune note par route, seulement un chiffre de précision pour tout le pipeline

Où se situe amBrain ?

Le seul projet de modèle de langage qu'amBrain décrit publiquement est le suivant : « Nous avons mené une intégration de LLM jusqu'en production dans le périmètre FinTech d'un client : extraction et normalisation d'avis non structurés de courtiers et de places de marché — opérations sur titres, changements d'instruments et de marges — en enregistrements structurés consommés par le système de trading. »

Cet article n'est pas une étude de cas : le client n'est pas nommé, et l'endroit où tournait le modèle dans ce projet n'est pas divulgué. Il n'affirme pas qu'amBrain a construit un dispositif hybride, une couche de masquage ou un routeur pour un client, quel qu'il soit, et il ne donne ni prix ni délais.

amBrain reprend des projets restés bloqués avec une autre équipe et les mène jusqu'en production.

amBrain développe des logiciels depuis 2019. Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception des composants réutilisables d'amBrain.

Si vous pesez ces options, apportez vos classes de documents et la liste des traces ci-dessus à chaque prestataire que vous rencontrez, y compris amBrain.

Questions fréquentes

• Le masquage nous permet-il d'envoyer tous les documents à l'API ? Non. Un texte masqué que vous pouvez rattacher à une personne reste pour vous une donnée à caractère personnel, et les détecteurs manquent certains identifiants. Utilisez le masquage pour réduire l'exposition sur les classes déjà autorisées à sortir
• Un modèle auto-hébergé peut-il égaler le modèle de l'API en qualité ? Sur certains types de documents, oui. Notez les deux sur le jeu commun de documents autorisés sur les deux routes avant de décider comment répartir le travail
• Peut-on commencer avec une route et ajouter la seconde plus tard ? Oui, et c'est souvent la voie la moins chère. Construisez le routeur et le journal des routes dès le premier jour, pour qu'ajouter la seconde route plus tard n'oblige pas à reconstruire le pipeline