IA à Monaco : quelle architecture pour garder le contrôle de vos données ?

Avant le modèle, cartographier la donnée

Une banque veut accélérer la lecture de dossiers. Un cabinet juridique souhaite comparer des clauses. Un family office prépare une synthèse patrimoniale. Une équipe RH cherche à retrouver une procédure. Derrière ces demandes, le besoin peut sembler identique : donner des documents à une IA et obtenir une réponse utile. Pourtant, les informations manipulées et les conséquences d’une exposition sont très différentes.

Dans un même dossier, on peut trouver des éléments publics, des données personnelles, des secrets commerciaux et des informations couvertes par des obligations professionnelles. La première décision consiste donc à identifier les données réellement nécessaires à la tâche. Pour reformuler une clause, le modèle a-t-il besoin du nom du client ? Pour expliquer une procédure RH, doit-il recevoir un dossier salarié ? Souvent, une partie de la matière peut être retirée avant tout traitement.

La cartographie doit suivre toute la chaîne : document source, outil d’OCR qui le lit, index de recherche, requête envoyée au modèle, réponse, historique de conversation, journaux et sauvegardes. Un modèle installé dans les locaux n’empêche pas un service de transcription ou de supervision d’envoyer ailleurs une copie du contenu. Le périmètre de confiance concerne l’ensemble du système.

• Finalité : quelle tâche précise veut-on améliorer et quel résultat doit être vérifié ?
• Données : quels champs et quels extraits sont indispensables, et lesquels peuvent être exclus ?
• Circulation : quels composants, personnes et prestataires peuvent recevoir ces informations ?
• Responsabilité : qui autorise le traitement, contrôle la réponse et gère une exception ?

À Monaco, la localisation ne suffit pas à qualifier le risque

La loi monégasque n° 1.565 du 3 décembre 2024 encadre la protection des données personnelles. Son chapitre VIII traite des transferts hors de la Principauté : l’article 96 pose le cadre général, puis les articles suivants prévoient les conditions et garanties applicables. La question ne se résume donc pas à choisir une région d’hébergement dans un menu.

Il faut distinguer trois périmètres : la frontière du SI, le territoire d’hébergement et les entités qui peuvent accéder aux données. Un service hébergé dans l’Union européenne peut rester extérieur au SI de l’entreprise. Un contrat avec un fournisseur doit également permettre de comprendre ses sous-traitants, ses accès de support et les éventuels transferts ultérieurs. L’architecture choisie doit être examinée avec les responsables compétents, en tenant compte du secteur et des traitements concernés.

Dans ce guide, les catégories « critique », « sensible » et « non sensible » servent à organiser une politique interne. Elles ne remplacent pas les qualifications juridiques, notamment celles des catégories particulières de données. Les sources françaises citées pour expliquer des notions techniques ne se substituent pas au droit monégasque. Notre propos porte sur le choix et la gouvernance d’une architecture, pas sur une validation juridique individuelle.

Références : APDP — Loi n° 1.565, notamment le chapitre VIII sur les transferts

Cloud et API : accéder rapidement à des modèles performants

Avec une API cloud, l’application envoie une requête à un modèle exploité par un fournisseur, par exemple OpenAI, Anthropic ou Mistral. L’entreprise n’a pas à dimensionner ni à maintenir l’infrastructure de calcul du modèle. Cette approche permet de commencer avec un investissement matériel limité et d’ajuster l’usage à la demande. Le coût complet inclut cependant l’intégration, la recherche documentaire, les appels aux outils et le contrôle des résultats.

Les données transmises quittent le périmètre d’exécution interne. Cela ne rend pas le cloud inadapté par principe, mais oblige à qualifier précisément l’offre utilisée. Une interface grand public, un abonnement professionnel et une API peuvent relever de conditions différentes. Les garanties doivent être vérifiées sur le produit, le modèle, les fonctions et le contrat effectivement retenus.

Il faut notamment séparer l’utilisation pour l’entraînement, la conservation des requêtes, le stockage des fichiers et la localisation du traitement. Une promesse de non-entraînement n’implique pas une absence de conservation. La documentation d’Anthropic illustre cette granularité : les modalités de rétention dépendent des fonctions et de l’éligibilité des modèles. Un dispositif de zéro rétention ne doit donc jamais être supposé actif pour tous les appels.

Le cloud est un candidat naturel pour reformuler du contenu public, traiter une documentation autorisée ou absorber un besoin variable. Pour un dossier confidentiel, la décision doit partir du flux réel et des garanties applicables. Un simple bouton « envoyer à l’IA » masque trop souvent ces différences.

• À vérifier avant déploiement : destinataires, régions, sous-traitants, conservation et modalités de suppression.
• À prévoir en exploitation : quotas, budget, qualité mesurée, disponibilité et solution de repli autorisée.
• À garder réversible : les données, les instructions et les évaluations utiles pour changer de fournisseur.

Références : Anthropic — Conservation des données et conditions du Zero Data Retention

AI Bridge : contrôler ce qui est envoyé au modèle

Nous appelons ici AI Bridge une passerelle de contrôle placée entre les outils de l’entreprise et les modèles externes. Ce terme désigne un schéma d’architecture, pas une certification ni une garantie de conformité. Son rôle est d’appliquer une politique avant qu’une requête ne sorte : vérifier l’utilisateur, sélectionner les informations nécessaires, transformer certains champs et autoriser une destination précise.

Un Bridge peut retirer les pièces inutiles, masquer des identifiants, remplacer un nom par un alias et appliquer des règles de prévention des fuites de données, souvent appelées DLP. Il peut aussi interdire certains modèles pour certaines catégories d’informations. La table qui permet de relier un alias à une identité doit rester dans le périmètre autorisé, avec des droits distincts et une durée de conservation définie.

La distinction entre pseudonymisation et anonymisation est décisive. Remplacer « Marie Dupont » par « CLIENT_042 » ne rend pas nécessairement le dossier anonyme : l’identité peut être retrouvée avec une table de correspondance ou déduite d’autres éléments. Une fonction rare, une opération particulière ou un patrimoine singulier peuvent aussi identifier une personne. La CNIL rappelle que la pseudonymisation reste réversible, contrairement à l’objectif d’une anonymisation effective.

Le Bridge doit être testé sur les vrais formats du métier : tableaux, scans, notes libres, pièces jointes et documents multilingues. Les règles peuvent rater une information ou supprimer un détail nécessaire à la réponse. Il faut mesurer ces deux erreurs. En cas de doute, le comportement attendu est un blocage, une revue ou un traitement dans un environnement approuvé, pas un envoi par défaut.

Enfin, le Bridge traite lui-même la donnée avant filtrage. Son hébergement et ses prestataires entrent donc dans l’analyse. Une passerelle externe qui reçoit le document complet a déjà créé un transfert. Pour un filtrage réellement préalable à toute sortie, ses opérations doivent s’exécuter dans le périmètre de confiance défini.

Références : CNIL — Anonymisation et pseudonymisation : deux notions distinctes

IA locale : garder la maîtrise implique d’exploiter le système

L’IA locale exécute le modèle sur une infrastructure contrôlée par l’entreprise : poste de travail, serveur interne ou environnement dédié dont le périmètre est explicitement défini. Un cloud privé reste un hébergement externe si le calcul n’est pas réalisé sur site. L’expression « local » mérite donc d’être précisée dans chaque projet.

Ollama et vLLM sont des logiciels permettant d’exécuter des modèles ; ce ne sont pas des modèles en eux-mêmes. Ollama documente un fonctionnement local ainsi que des fonctions cloud, qui peuvent être désactivées. vLLM documente ses propres exigences de sécurisation. Installer l’un de ces outils ne prouve donc ni l’absence de flux externes ni la sécurité de l’ensemble de l’application.

Le dimensionnement dépend de la taille du modèle, du contexte documentaire, du nombre d’utilisateurs simultanés et du délai acceptable. Certains usages modestes peuvent fonctionner sans serveur GPU dédié ; d’autres demandent une capacité importante. Les compromis de compression ou de quantification doivent être évalués sur la tâche réelle, plutôt que supposés neutres pour la qualité.

Le coût porte aussi sur les accès, les correctifs, la supervision, les sauvegardes, la reprise après incident et les mises à jour des modèles. Les licences des modèles à poids ouverts doivent être vérifiées : la disponibilité des poids ne garantit pas une liberté d’usage sans condition. Le local peut se justifier par une exigence de contrôle forte ou par un volume stable, mais sa rentabilité ne se déduit pas du seul prix d’un serveur.

• Vérifier les sorties réseau de toute la chaîne, y compris OCR, embeddings, recherche web et télémétrie.
• Protéger les interfaces d’administration et d’inférence ; limiter les accès au réseau et aux utilisateurs autorisés.
• Prévoir la disponibilité, les compétences d’exploitation et une procédure de mise à jour testée.

Références : Ollama — Exécution locale et désactivation des fonctions cloud · vLLM — Sécurisation des déploiements

Hybride : une politique de routage plutôt qu’un compromis improvisé

Une architecture hybride combine plusieurs modes de traitement. Elle peut réserver certains dossiers à une infrastructure interne, transmettre des extraits filtrés à une API et utiliser directement un modèle cloud pour du contenu public. Son intérêt est de faire correspondre le niveau de contrôle à l’usage, sans imposer partout la même infrastructure.

La règle « critique vers local, sensible vers Bridge, non sensible vers cloud » constitue un repère, pas une autorisation automatique. Certaines informations sensibles ne doivent pas être externalisées même après filtrage. À l’inverse, un environnement externe dédié peut être autorisé pour un usage précisément encadré. La décision dépend des obligations, du contrat, du risque résiduel et de la qualité requise.

La classification et le routage doivent être contrôlés par l’application. Il serait fragile de demander au seul modèle de décider si un dossier peut lui être transmis. Les règles doivent s’appuyer sur les permissions, les catégories de données, les sources et les destinations approuvées. Si un dossier contient plusieurs niveaux de sensibilité, la politique doit définir le traitement le plus restrictif ou une séparation vérifiée.

Le fonctionnement dégradé est un test important : que se passe-t-il lorsque le serveur local est saturé ? Le système ne doit pas basculer silencieusement vers une API externe. La solution de repli peut être une file d’attente, une autre infrastructure déjà autorisée ou une reprise manuelle. C’est là que la gouvernance devient observable.

Comparatif : quatre architectures, quatre arbitrages

Ce tableau compare des schémas de déploiement. Les niveaux réels de performance, de confidentialité et de coût dépendent du modèle, du contrat et de la configuration. Le Bridge utilise généralement un modèle cloud en aval ; l’hybride organise plusieurs de ces options plutôt que de constituer une cinquième technologie.

Trois situations concrètes pour une entreprise monégasque

Les situations suivantes sont des exemples de conception, pas des références clients ni des résultats annoncés par Quanta. Elles montrent comment un même objectif peut conduire à des architectures différentes.

Cabinet juridique : comparer des clauses. Si la comparaison porte sur deux modèles de contrat non confidentiels, une API autorisée peut suffire. Si les versions contiennent des noms, des montants négociés et une stratégie contentieuse, il faut d’abord déterminer quels passages sont indispensables. Un Bridge peut préparer un extrait pseudonymisé lorsque ce transfert est autorisé ; sinon, le traitement reste dans l’environnement approuvé. Le professionnel vérifie toujours les différences et leur portée.

Family office : préparer une note de synthèse. La recherche sur des informations publiques peut être séparée de l’analyse d’un dossier familial. Le système conserve les éléments patrimoniaux dans le périmètre retenu et n’envoie pas automatiquement le contexte privé à un moteur de recherche. Une synthèse finale relie les faits à leurs sources et passe par une validation humaine avant diffusion.

Équipe RH : répondre à une question de procédure. Une recherche dans des politiques internes générales peut fonctionner sans données individuelles. L’ajout d’un dossier salarié change le niveau de risque et les permissions nécessaires. Le système doit distinguer une réponse documentaire d’une décision concernant une personne. Une conversation commencée sur une question générale ne doit pas rendre possible l’envoi ultérieur d’une pièce confidentielle sans nouveau contrôle.

Les contrôles à prévoir, quelle que soit l’architecture

Un assistant documentaire, souvent appelé système RAG, retrouve des extraits avant de les fournir au modèle. Ce mécanisme ne remplace pas les droits d’accès. Un collaborateur ne doit retrouver que les documents auxquels il est autorisé à accéder ; cette règle doit s’appliquer à la recherche et pas seulement à l’affichage final. L’index, les embeddings et les caches font partie des actifs à protéger.

Les documents et pages consultés peuvent aussi contenir des instructions malveillantes. L’OWASP décrit ce risque sous le nom d’injection de prompt. Une instruction cachée dans une pièce jointe peut chercher à détourner un agent de sa tâche ou à lui faire divulguer des informations. Les permissions et les autorisations d’action doivent donc être imposées par le système, sans reposer uniquement sur une consigne adressée au modèle.

La journalisation doit permettre de comprendre une décision sans devenir un nouvel entrepôt de données sensibles. Il est souvent préférable d’enregistrer un identifiant de traitement, la règle appliquée, la destination, la version du modèle et l’état de validation. La conservation du contenu intégral des requêtes doit être justifiée, protégée et limitée. Les traces techniques, les sauvegardes et les outils de suivi doivent être inclus dans la politique de suppression.

• Identités et droits : authentification, permissions par source et séparation des rôles d’administration.
• Entrées et sorties : données minimisées, pièces contrôlées, résultats vérifiés avant utilisation.
• Actions : périmètre limité, validation humaine pour les opérations engageantes et possibilité d’arrêt.
• Évaluation : cas représentatifs, documents ambigus, tentatives de fuite et comportement en panne.
• Exploitation : responsable identifié, suivi des incidents, versions connues et procédure de retour arrière.

Références : OWASP — Risques d’injection de prompt

Comparer le coût d’une tâche réussie, pas seulement celui du modèle

Le prix de l’API ou du GPU est une ligne du budget. Le coût total comprend la préparation des données, l’intégration aux logiciels, la sécurité, l’exploitation, les appels aux outils et le temps humain passé à vérifier ou corriger les réponses. Une solution apparemment économique peut devenir coûteuse si elle multiplie les reprises.

Un indicateur utile consiste à rapporter les coûts d’infrastructure, de traitement, d’exploitation et de contrôle humain au nombre de tâches dont le résultat est accepté. Il permet de comparer des options qui n’ont ni la même structure de dépenses ni le même taux de réussite. Les incidents graves restent cependant des contraintes à traiter, pas de simples coûts à diluer dans une moyenne.

Pour une API, on observe les volumes, la longueur des documents, les outils et les pics d’activité. Pour le local, on mesure la capacité effectivement utilisée, la concurrence entre utilisateurs, les délais et la disponibilité nécessaire. Pour un Bridge, on ajoute la maintenance des règles et l’évaluation du filtrage. Pour l’hybride, on intègre le pilotage de plusieurs environnements. Il n’existe pas de seuil de rentabilité universel.

Une méthode de décision en cinq étapes

La recommandation Quanta est de partir d’un processus limité et mesurable. L’objectif du premier projet est de prouver qu’une tâche peut être mieux réalisée dans un cadre maîtrisé. Déployer simultanément un assistant généraliste, un serveur local, plusieurs API et une passerelle complexe ajoute des dépendances avant d’avoir démontré la valeur.

La première étape consiste à choisir un usage et son résultat attendu. La deuxième est de cartographier les données, les destinataires et les contraintes. La troisième compare une ou deux architectures réalistes. La quatrième met les options à l’épreuve sur des cas représentatifs et des situations dégradées. La cinquième formalise l’exploitation avant l’ouverture aux utilisateurs.

Le livrable utile est une décision documentée : ce qui est autorisé, dans quel environnement, pour quels utilisateurs, avec quels contrôles et quelle solution de repli. Cette décision doit pouvoir évoluer lorsque les modèles, les contrats ou les besoins changent. Garder les évaluations et les règles indépendantes d’un fournisseur aide à conserver cette liberté.

• Cadrer : tâche, bénéfice attendu, qualité minimale et validation humaine.
• Cartographier : sources, champs, flux, accès, conservation et contraintes sectorielles.
• Comparer : qualité, confidentialité, intégration, délai et coût total.
• Tester : cas usuels, exceptions, données interdites et indisponibilité d’un composant.
• Exploiter : responsables, alertes, budget, mises à jour et réexamen périodique.

La souveraineté commence par une décision que l’on peut expliquer

Tout héberger soi-même ne garantit ni la qualité des réponses ni une gouvernance suffisante. Utiliser un cloud n’interdit pas non plus une maîtrise sérieuse des usages. La question est de pouvoir expliquer, pour chaque traitement, où va la donnée, pourquoi elle est nécessaire, ce qui est transmis et qui garde le contrôle.

À Monaco, l’enjeu est de construire des infrastructures IA adaptées aux données et au travail réel des organisations. Un modèle puissant apporte une capacité. Une architecture gouvernée permet de l’utiliser durablement, de comprendre ses limites et de décider quand elle doit s’arrêter.

Quanta accompagne le cadrage des usages, la comparaison des architectures et leur intégration aux outils de l’entreprise. Le point de départ peut être simple : prendre un processus, suivre le parcours de ses données et décider des frontières à respecter avant de choisir le modèle.