Architecture de référence d'une IA souveraine : cinq couches, flux, menaces et évaluation

Presque tous les fournisseurs d'IA se disent « souverains » aujourd'hui. Certains hébergent vos données dans votre région, d'autres affichent un drapeau sur leur site, d'autres encore promettent un « cloud de confiance ». Mais une étiquette n'est pas une architecture. Une IA est réellement souveraine lorsque vous pouvez répondre, pièces à l'appui, à une question simple : qui contrôle quoi, et que se passe-t-il si demain la relation s'arrête ou si la loi change ?

Cet article est la synthèse d'une série qui a commencé par ce qu'est une IA, s'est poursuivie avec l'IA et vos documents et le fonctionnement en local, et s'est penchée sur la souveraineté des données. Il s'adresse aux architectes, aux CTO et aux responsables sécurité : il décrit une architecture de référence, composant par composant, avec les compromis et les modes de défaillance que j'ai rencontrés ou que je juge probables. J'ai conçu moi-même un environnement LLM sur site, avec un modèle ouvert de la famille Granite servi par SGLang sur Kubernetes. Je m'y réfère en termes génériques : aucun détail confidentiel, aucun résultat chiffré. Les chiffres de cet article sont des calculs visibles ou des ordres de grandeur signalés comme illustratifs.

Ce que « souverain » veut vraiment dire

La souveraineté n'est pas une case à cocher : c'est un ensemble de quatre maîtrises. Une IA peut être solide sur certaines et fragile sur d'autres, et c'est dans les écarts que se cachent les mauvaises surprises.

• Souveraineté des données. Vous savez où se trouvent vos documents, vos questions et les réponses de l'IA, et qui peut y accéder. Rien n'est utilisé pour entraîner le modèle d'un tiers.
• Souveraineté de l'infrastructure. Les serveurs sont dans un lieu que vous choisissez, sous une juridiction que vous connaissez, chez vous ou chez un hébergeur local.
• Souveraineté du modèle. Vous pouvez faire fonctionner le modèle vous-même, le remplacer par un autre et l'évaluer sur vos propres cas. Vous ne dépendez pas d'une seule boîte noire.
• Souveraineté opérationnelle. Vos équipes, ou un partenaire que vous choisissez, savent administrer le système. Si un prestataire disparaît, vous gardez la main : accès, documentation, droit de reprendre l'exploitation.

Le piège de l'hébergement local

Un serveur situé dans votre pays n'est pas forcément souverain. Si le fournisseur qui l'exploite relève d'une loi étrangère, comme le CLOUD Act évoqué dans l'article sur la souveraineté des données, ou si le modèle qui tourne dessus ne peut être ni inspecté ni remplacé, la dépendance reste entière. Le lieu n'est qu'une des quatre dimensions.

Une remarque de méthode : ces quatre maîtrises se traduisent en propriétés testables. « Je sais où sont mes données » devient un inventaire des volumes et des flux sortants. « Je peux remplacer le modèle » devient un test de bascule sur un jeu de référence. Tout ce qui suit cherche à rendre ces propriétés vérifiables plutôt que déclaratives.

Les cinq couches d'une IA maîtrisée

Une IA d'entreprise n'est pas « un modèle ». C'est un empilement de couches, chacune avec son rôle, ses interfaces et ses défaillances propres. Les voici, du sommet à la base, avec un bloc transversal qui les traverse toutes.

1. L'infrastructure

C'est la base physique et son plan de contrôle : des nœuds équipés de GPU, du stockage, un réseau, hébergés dans un centre de données dont vous maîtrisez l'accès physique et juridique. Les questions clés sont simples : où se trouve-t-il, qui y accède, que se passe-t-il en cas de coupure ? Le dimensionnement dépend du nombre d'utilisateurs simultanés et de la taille des modèles, comme je l'ai détaillé dans l'article sur l'IA en local.

Kubernetes comme socle. Kubernetes n'est pas obligatoire, mais il apporte trois choses utiles ici : un modèle déclaratif reproductible (le même manifeste sur site et chez un hébergeur), un ordonnancement qui comprend les ressources rares, et un écosystème de contrôle réseau et d'identité de charge de travail. Son coût est réel : une équipe qui sait l'exploiter. Pour un seul serveur GPU et un seul modèle, un service systemd et un conteneur suffisent, et je ne conseille pas d'installer un cluster pour la forme.

Nœuds GPU et opérateur. Sur un nœud GPU, il faut le pilote, le runtime de conteneur adapté, le plugin d'équipement qui expose les GPU comme ressource ordonnançable, l'étiquetage des caractéristiques du matériel et la supervision. Selon sa documentation, l'opérateur GPU de NVIDIA automatise ce logiciel sur Kubernetes (pilote, plugin d'équipement, container toolkit, étiquetage, métriques DCGM) et se déploie par Helm. L'intérêt est d'éviter la dérive entre nœuds, source classique de pannes. Les versions de pilote, de CUDA, de moteur d'inférence et de noyau forment une matrice de compatibilité : je la fige et je la teste à chaque mise à jour, jamais en production directement.

Ordonnancement. Un pod demande des GPU entiers par la ressource étendue nvidia.com/gpu ; le planificateur ne partage pas un GPU de cette façon. Pour partager un GPU, il existe des mécanismes spécifiques au matériel (découpage en instances isolées, partage temporel), avec des compromis d'isolation et de latence à vérifier pour votre modèle de GPU. Mon réflexe : un modèle de production par GPU ou groupe de GPU dédié, des taints sur les nœuds GPU pour que rien d'autre ne s'y installe, et des priorités explicites pour que l'inférence interactive ne soit pas évincée par un traitement par lots.

# Extrait illustratif : un déploiement d'inférence qui réclame 2 GPU
# et ne peut s'installer que sur les nœuds GPU réservés.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-grand-modele
  namespace: inference
spec:
  replicas: 1
  selector:
    matchLabels: { app: llm-grand-modele }
  template:
    metadata:
      labels: { app: llm-grand-modele }
    spec:
      nodeSelector:
        pool: gpu-inference
      tolerations:
        - key: dedie
          value: gpu
          effect: NoSchedule
      containers:
        - name: moteur
          image: registre.interne/moteur-inference@sha256:<digest>
          resources:
            limits:
              nvidia.com/gpu: 2

L'image est référencée par son condensat (digest) et non par une étiquette mutable : c'est le premier maillon de la chaîne d'approvisionnement, j'y reviens plus loin.

Stockage. Trois usages à ne pas confondre : les poids des modèles (gros fichiers en lecture seule, chargés au démarrage), les données d'état (base vectorielle, PostgreSQL, journaux) et les caches du moteur. Les poids se stockent dans un registre ou un dépôt d'objets interne, avec une copie locale sur disque NVMe des nœuds pour que le démarrage ne dépende pas du réseau. Les données d'état vont sur un stockage répliqué et chiffré. Un modèle de 70 milliards de paramètres en 16 bits pèse environ 140 Go (70e9 × 2 octets) : le temps de chargement n'est pas négligeable et conditionne le temps de reprise après incident.

Réseau et segmentation par zones. Le principe : une zone par niveau de sensibilité, et seuls les flux explicitement listés passent entre elles. Dans Kubernetes, les NetworkPolicy ne s'appliquent que si le plugin réseau les implémente, et par défaut un pod n'est pas isolé : tout le trafic est autorisé, selon la documentation. Il faut donc partir d'un refus par défaut, en entrée et en sortie, dans chaque espace de noms.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: refus-par-defaut
  namespace: inference
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: moteur-depuis-passerelle-seulement
  namespace: inference
spec:
  podSelector:
    matchLabels: { app: llm-grand-modele }
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: passerelle }
      ports:
        - port: 8000

Contrôle des sorties réseau. C'est le point le plus sous-estimé. Une IA locale qui peut joindre n'importe quelle adresse sur Internet n'est pas isolée : un pod compromis, un conteneur piégé ou une injection de prompt qui déclenche un appel d'outil trouveront un chemin de sortie. Je filtre les sorties par un proxy ou une passerelle de sortie avec liste blanche de noms de domaine, j'interdis la résolution DNS externe directe depuis les zones sensibles (le DNS est un canal d'exfiltration classique) et je journalise chaque tentative refusée. Les NetworkPolicy standard raisonnent en adresses IP et en ports ; pour une liste de noms de domaine, il faut un composant supplémentaire, selon le plugin réseau ou le maillage de services retenu. Pour une zone totalement déconnectée, il n'y a pas de sortie du tout, et les mises à jour entrent par un processus de transfert contrôlé (voir la chaîne d'approvisionnement plus loin).

2. Les modèles et la passerelle d'inférence

Le modèle est le cerveau : un modèle ouvert, évalué sur vos propres cas. Le moteur d'inférence charge les poids dans les GPU et sert de nombreux utilisateurs à la fois ; vLLM et SGLang en sont deux exemples répandus. Tous deux, selon leur documentation, exposent un serveur HTTP compatible avec l'API OpenAI (chat completions, completions, et d'autres routes selon la version), avec des extensions propres que l'API d'origine ne connaît pas. Cette compatibilité est la pièce maîtresse de la réversibilité, à une réserve près : elle couvre le gros du contrat, pas tous les paramètres. Les sorties structurées, l'appel d'outils et les modes de raisonnement varient d'un moteur à l'autre, et je les teste explicitement avant de dire qu'un moteur en remplace un autre.

Dimensionnement : la mémoire du cache KV. Le facteur limitant n'est pas seulement le poids du modèle mais le cache clé-valeur de chaque requête en cours. Sa taille par jeton se calcule ainsi :

octets par jeton = 2 (K et V) x couches x têtes KV x dimension de tête x octets par valeur

Exemple illustratif, pour une architecture fictive de 32 couches, 8 têtes KV, dimension de tête 128, valeurs en 16 bits : 2 × 32 × 8 × 128 × 2 = 131 072 octets, soit 128 Kio par jeton. Un contexte de 8 192 jetons occupe donc 1 Gio par séquence, et 32 séquences simultanées 32 Gio, à ajouter aux poids. C'est ce calcul, refait avec les paramètres réels de votre modèle, qui dit combien de requêtes concurrentes tient un GPU, bien avant la puissance de calcul. Les moteurs modernes gèrent ce cache par blocs et le partagent entre requêtes qui ont un préfixe commun, mais l'ordre de grandeur reste le bon point de départ.

La passerelle. Entre les applications et les moteurs, je place une passerelle qui expose une API compatible OpenAI et porte tout ce qui ne doit pas être réimplémenté dans chaque application :

• l'authentification (jeton OIDC de l'utilisateur ou de l'application) et les quotas par identité ;
• le routage entre modèles, par alias logique (assistant-general, resume-rapide, embeddings) plutôt que par nom de modèle réel ;
• l'application des politiques (zone autorisée pour cette donnée, outils permis) ;
• l'écriture du journal d'audit et des métriques ;
• le repli : si un modèle est saturé ou indisponible, bascule vers un autre, si la politique l'autorise.

Les alias sont la clé : l'application demande assistant-general, et la passerelle décide, par configuration, quel modèle et quelle version répondent. Remplacer un modèle ne touche plus le code applicatif.

# Configuration illustrative de passerelle (schéma générique, pas celui d'un produit précis)
modeles:
  assistant-general:
    cible: moteur-grand-modele.inference.svc:8000
    nom_moteur: grand-modele-v3
    zones_autorisees: [confidentiel, interne]
    repli: resume-rapide
  resume-rapide:
    cible: moteur-petit-modele.inference.svc:8000
    nom_moteur: petit-modele-v2
    zones_autorisees: [confidentiel, interne, public]
  embeddings:
    cible: moteur-embeddings.inference.svc:8000
    nom_moteur: embeddings-v1
quotas:
  par_utilisateur: { requetes_par_minute: 30, jetons_sortie_max: 2048 }

Registre de modèles et versionnage. Un modèle est un artefact comme un autre : poids, tokenizer, gabarit de conversation, paramètres de génération, licence. Je les range dans un registre interne avec une version immuable, le condensat des fichiers, la licence (qui peut interdire certains usages), la provenance (d'où viennent les poids) et le rapport d'évaluation associé. Un détail qui piège : certains serveurs lisent par défaut la configuration de génération fournie avec le modèle, ce qui peut modifier les paramètres d'échantillonnage sans que personne ne l'ait demandé, d'après la documentation de vLLM. Je fixe ces paramètres explicitement dans la configuration de déploiement.

Évaluation avant bascule. Aucun changement de modèle, de quantification, de gabarit ou de version du moteur n'entre en production sans repasser le jeu de référence (voir la section sur l'évaluation continue). La quantification, par exemple, réduit la mémoire et accélère souvent le débit, mais peut dégrader la qualité de façon inégale selon les langues : l'arabe et les textes juridiques sont de bons révélateurs, et je ne fais confiance qu'à ma propre mesure.

3. Les connaissances et les données

C'est la couche qui donne à l'IA votre contexte : la méthode RAG décrite dans l'article sur l'IA et vos documents. Elle comprend l'ingestion (lire, découper et vectoriser les documents), une base vectorielle (pgvector ou Qdrant, par exemple) et surtout les droits d'accès.

La règle d'or n'a pas changé : l'IA ne doit retrouver que ce que l'utilisateur a le droit de lire, et le filtre s'applique au moment de la recherche, pas après la génération. Un filtrage a posteriori est trop tard : le passage confidentiel est déjà dans le contexte du modèle, et rien ne garantit qu'il n'en influencera pas la réponse. Techniquement, chaque fragment indexé porte les métadonnées de ses droits (groupes, niveau de classification, zone) copiées depuis la source à l'ingestion, et la requête vectorielle est exécutée avec un filtre dérivé de l'identité de l'utilisateur :

# Principe : le filtre de droits fait partie de la requête vectorielle.
def rechercher(question, utilisateur, k=8):
    vecteur = embeddings(question)
    filtre = {
        "groupes_lecture": {"any_of": utilisateur.groupes},
        "classification": {"max": utilisateur.habilitation},
        "zone": {"in": zones_permises(utilisateur)},
    }
    return base_vectorielle.search(vecteur, filtre=filtre, limit=k)

Deux écueils à surveiller. D'abord, les droits changent : si un document devient restreint ou si un employé change de service, les métadonnées indexées doivent suivre, ce qui impose une synchronisation incrémentale et un délai maximal documenté. Ensuite, les filtres appliqués dans certains index approximatifs peuvent réduire le nombre de résultats renvoyés ou la qualité du rappel quand ils sont très sélectifs ; il faut le mesurer sur votre moteur, pas le supposer. Enfin, l'index vectoriel lui-même contient des fragments de documents et se traite comme une donnée du même niveau de sensibilité que la source (chiffrement, sauvegarde, zone).

4. L'orchestration et les agents

Entre la question et la réponse, il y a souvent plus qu'un appel au modèle : reformuler la question, chercher dans plusieurs sources, interroger un logiciel métier, vérifier un calcul, demander une validation humaine. L'orchestration enchaîne ces étapes. Lorsque l'IA choisit elle-même les actions (créer un ticket, envoyer un e-mail), on parle d'agent, et le périmètre de risque change de nature : le modèle ne produit plus seulement du texte, il déclenche des effets.

Mes règles de conception, sans exception :

1. Liste blanche d'outils par rôle. Un outil non déclaré pour ce rôle n'existe pas pour l'agent. Chaque outil a un schéma d'arguments strict, validé côté serveur, jamais côté modèle.
2. Droits de l'utilisateur, pas de l'agent. L'outil s'exécute avec l'identité de la personne qui a posé la question (ou un jeton délégué restreint), pas avec un compte de service omnipotent. Sinon l'agent contourne les ACL de la couche connaissances.
3. Validation humaine pour l'irréversible. Envoi externe, écriture dans un système de référence, suppression, paiement : l'agent prépare, l'humain confirme, et l'écran de confirmation affiche ce qui sera réellement exécuté (arguments inclus), pas la description du modèle.
4. Budgets. Nombre maximal d'étapes, de jetons et d'appels d'outils par tâche, avec arrêt franc. Un agent qui boucle consomme des GPU et peut multiplier des actions.
5. Journalisation des appels d'outils : outil, arguments, identité, décision de validation, résultat (tronqué et masqué). Sans ce journal, on ne reconstitue pas un incident.

C'est la traduction directe de la catégorie « excessive agency » de la liste OWASP des risques pour les applications LLM : trop de fonctionnalités, trop de permissions, trop d'autonomie. Je commence toujours en lecture seule et j'ajoute les actions une à une.

5. Les applications et interfaces

C'est ce que voient vos équipes : une fenêtre de discussion, un assistant intégré à la gestion documentaire, au CRM ou à l'ERP, une application mobile. Deux points d'architecture comptent. Les applications ne parlent qu'à la passerelle, jamais directement à un moteur : c'est ce qui rend la couche inférieure interchangeable. Et l'interface doit gérer l'arabe de droite à gauche, le français et l'anglais, parfois dans une même conversation, y compris dans l'affichage des citations et des extraits de documents.

Et partout : identité, politiques, secrets, audit

La barre verticale du schéma n'est pas décorative. Sans elle, vous avez une démonstration, pas un système. Je la décompose en six chantiers.

Identité. Authentification unique (SSO) par OpenID Connect adossé à l'annuaire de l'entreprise : l'utilisateur présente un jeton signé, la passerelle le valide, et en extrait des rôles (grandes familles : analyste, juriste) et des attributs (pays, service, habilitation). Les rôles suffisent pour les outils ; les attributs sont nécessaires pour les documents (« dossiers du pays X »). Les services entre eux s'authentifient par identité de charge de travail et TLS mutuel, pas par secret partagé.

Point d'application des politiques. Les décisions (cette personne, cette donnée, cette zone, cet outil) sont évaluées en un endroit, interrogeable et testable, plutôt que dispersées dans le code de chaque application. La passerelle est le point d'application ; la politique elle-même peut être un moteur dédié ou un simple module versionné. Ce qui compte : elle est écrite en clair, relue, testée et déployée comme du code.

# Règles de politique illustratives
regles:
  - nom: confidentiel-reste-local
    si: { classification_document: confidentiel }
    alors: { zones_modele: [on-premise] , sortie_reseau: interdite }
  - nom: outils-ecriture-validation
    si: { outil.type: ecriture }
    alors: { validation_humaine: obligatoire }
  - nom: pays-isoles
    si: { document.pays: "!= utilisateur.pays" }
    alors: { acces: refuse }

Secrets et clés. Aucun secret dans les images ni dans les dépôts : un gestionnaire de secrets (ou le magasin de secrets de l'orchestrateur chiffré au repos, avec une clé que vous contrôlez), des jetons de courte durée, une rotation planifiée, et surtout une clé de chiffrement dont la garde est claire. Si la clé est chez le fournisseur qui héberge, le chiffrement ne vous protège pas de lui.

Chiffrement. Au repos (disques, base, sauvegardes, index vectoriel) et en transit (TLS partout, y compris à l'intérieur du cluster pour les zones sensibles). Le chiffrement ne protège pas contre un utilisateur légitime qui pose une question qu'il n'aurait pas dû pouvoir poser : c'est le rôle des ACL et des politiques.

Journal d'audit immuable, avec masquage. Chaque interaction produit un enregistrement structuré : horodatage, identité, alias de modèle et version réelle, zone, identifiants des documents récupérés, outils appelés, décisions de politique, volumes de jetons, empreinte du prompt et de la réponse. Écriture en ajout seul, sur un stockage qui interdit modification et suppression pendant la durée de rétention (stockage à écriture unique, ou chaînage d'empreintes pour détecter toute altération). Le texte brut des prompts et réponses contient des données personnelles : je le masque ou le pseudonymise avant écriture dans les traces courantes, et je ne conserve le contenu intégral que si une exigence précise le justifie, chiffré, avec accès exceptionnel journalisé lui aussi.

{
  "ts": "2026-03-04T09:12:41Z",
  "utilisateur": "u-5821",
  "role": "conformite",
  "alias": "assistant-general",
  "modele": "grand-modele-v3",
  "zone": "on-premise",
  "documents": ["doc-1182#p4", "doc-0457#p2"],
  "outils": [],
  "politique": ["confidentiel-reste-local:ok"],
  "jetons": { "entree": 1840, "sortie": 312 },
  "prompt_sha256": "<empreinte>",
  "contenu_masque": "Quelles sont les conditions de [PRODUIT] pour [CLIENT_1] ?",
  "chaine": "<empreinte de l'enregistrement précédent>"
}

Observabilité. Les métriques qui comptent pour un service d'inférence : le délai avant le premier jeton (TTFT), le débit en jetons par seconde (par requête et agrégé), la profondeur des files d'attente, le taux d'erreurs et de délais dépassés, l'occupation mémoire du cache KV, l'utilisation des GPU, et le coût par requête. Ce dernier s'estime simplement : coût horaire complet du nœud (amortissement, énergie, exploitation) divisé par le nombre de requêtes servies à l'heure au niveau de latence cible. Le TTFT dégrade d'abord sous charge (la file s'allonge), le débit par requête ensuite (les séquences se partagent le GPU) : je suis les deux avec des percentiles, pas des moyennes. Mêmes principes pour les métriques RAG : taux de récupérations vides, nombre de citations par réponse.

Sauvegarde et reprise. Ce qu'on sauvegarde : configuration (dans un dépôt Git), registre de modèles, base documentaire, index vectoriel (ou, mieux, les données sources, l'index pouvant être reconstruit), journaux d'audit. Ce qui compte, c'est le test de restauration, avec un objectif de reprise écrit : recharger les poids, réinitialiser l'index, redémarrer les moteurs. Un incident qui coupe un nœud GPU se mesure d'abord au temps de rechargement des poids (voir plus haut), d'où l'intérêt d'avoir au moins deux répliques pour les services critiques.

Réversibilité. C'est la propriété qui fait vraiment la souveraineté. Elle se construit par des choix concrets : API standard entre couches (compatible OpenAI pour l'inférence, SQL et formats ouverts pour les données), poids de modèles ouverts dans des formats courants, aucun format propriétaire de stockage (l'export des documents, des embeddings et des journaux doit être un exercice documenté et testé), configuration déclarative versionnée, et alias logiques pour les modèles. Le test que je recommande : une fois par an, remplacer réellement le moteur ou le modèle sur un environnement de test, et mesurer le temps et les écarts de qualité. Une réversibilité jamais testée est une hypothèse.

Le parcours d'une question

Pour que ces couches deviennent concrètes, suivons une question posée par un collaborateur : « Quelles sont les conditions de remboursement anticipé dans nos contrats professionnels ? »

1. Identifier. L'utilisateur est reconnu grâce à l'annuaire de l'entreprise. Son rôle et ses attributs déterminent les collections de documents auxquelles il a accès.
2. Retrouver. La question est transformée en vecteur, et la recherche ne porte que sur les documents autorisés. Les passages les plus pertinents sont sélectionnés.
3. Générer. Le modèle, hébergé chez vous, reçoit la question et les passages, puis rédige une réponse en citant ses sources.
4. Contrôler et tracer. Des filtres vérifient la réponse (données personnelles, contenu interdit, citations présentes), et l'échange est enregistré dans un journal d'audit protégé.

Le schéma ci-dessus est volontairement le trajet vu par l'utilisateur. Voici le même trajet vu des composants, avec la séquence des échanges et l'endroit où chaque décision est prise.

Plusieurs choix sont visibles dans cette séquence. La politique est évaluée avant toute récupération : une question qui vise une zone interdite s'arrête là. La passerelle, et non le client, appelle la récupération, ce qui évite qu'un client modifié choisisse ses propres filtres. Le contrôle de sortie intervient sur la réponse complète ou sur des fenêtres du flux, avec un compromis assumé : filtrer le flux au fil de l'eau réduit la latence perçue mais rend les filtres plus difficiles à appliquer à une phrase entière. L'écriture dans l'audit est une étape à part entière : si elle échoue, je préfère que la réponse n'arrive pas dans les zones soumises à obligation de traçabilité.

À aucun moment une donnée sensible ne sort du périmètre de sa zone, et chaque étape laisse une trace. C'est cette traçabilité, autant que la localisation, qui convainc un auditeur ou un régulateur.

Modèle de menace

Une IA d'entreprise a une surface d'attaque particulière, car le modèle traite dans le même flux des instructions et des données non fiables. La liste OWASP des dix risques principaux pour les applications LLM (édition 2025) est un bon cadre de référence ; voici les menaces qui pèsent le plus sur cette architecture, avec ce que j'y oppose.

Deux remarques d'honnêteté. L'injection de prompt n'a pas, à ma connaissance, de parade complète au niveau du modèle : on la traite par l'architecture (limiter ce que l'agent peut faire et ce qu'il peut lire), pas par un filtre magique. Et le masquage par expressions régulières ou classifieurs laisse passer des cas : c'est une réduction de risque, pas une garantie, et la rétention courte compense ses limites.

Chaîne d'approvisionnement, en pratique. Pour un environnement déconnecté ou à forte contrainte, le chemin est : téléchargement dans une zone d'import isolée, vérification des condensats et de la provenance, analyse, copie dans le registre interne, puis déploiement par condensat. Rien ne tire d'image ni de poids depuis Internet à l'exécution. C'est contraignant, mais c'est ce qui rend le terme « sur site » crédible.

Où faire tourner quoi : le tri par sensibilité

Souverain ne veut pas dire « tout en interne ». Ce serait renoncer aux meilleurs modèles du marché pour des usages qui n'ont rien de sensible. L'approche la plus raisonnable consiste à classer les données, puis à orienter chaque catégorie vers l'endroit adapté.

Ce tri ne vaut que s'il est appliqué par le système, pas par la bonne volonté des utilisateurs : la classification de chaque document vient de la source (étiquette, répertoire, métadonnée), et la passerelle refuse d'envoyer un contenu confidentiel vers un alias qui pointe hors de la zone. Une donnée mal classée est le principal point faible de ce modèle. D'où une règle prudente : à l'ingestion, tout ce qui n'est pas classé est traité comme confidentiel.

Les flux entre zones sont eux-mêmes une décision d'architecture. Voici ceux que j'autorise et ce que je ferme.

Les trois grands modes de déploiement ont chacun leur logique, et aucun n'est supérieur dans l'absolu.

Sur le coût, une règle de calcul plutôt qu'un chiffre : l'infrastructure propre devient intéressante quand le taux d'utilisation des GPU est élevé et stable, car un GPU inactif coûte autant qu'un GPU saturé. Un usage ponctuel ou très variable favorise le paiement à l'usage. Je compare toujours sur le coût complet par requête, exploitation comprise.

Un point de vigilance vaut pour les trois : la réversibilité. Quel que soit le mode, vous devez pouvoir changer d'hébergeur ou de modèle sans tout reconstruire. C'est pourquoi les couches sont séparées et reliées par des interfaces standard, et pourquoi il vaut mieux éviter les services propriétaires qui enferment vos données dans un format que vous ne pouvez pas exporter.

L'évaluation continue

Je considère l'évaluation comme un composant de l'architecture, au même titre que la passerelle. Sans elle, ni la réversibilité (on ne sait pas si le remplaçant est bon), ni la sécurité (on ne détecte pas une régression de comportement) ne sont vérifiables.

Le jeu de référence. Quelques centaines de cas représentatifs, construits avec les équipes métier, dans chaque langue utilisée : question, passages attendus, réponse de référence ou critères de réussite. Il contient aussi des cas négatifs : questions sans réponse dans les documents (le bon comportement est de le dire), tentatives d'accès à des documents interdits (le bon comportement est de ne rien révéler) et injections connues. Le jeu est versionné, et il évolue : chaque incident réel y ajoute un cas.

Ce qu'on mesure. Pour la récupération : le rappel des bons passages parmi les k premiers. Pour la génération : l'exactitude jugée par des experts (échantillon régulier), la part de réponses avec citations correctes, le taux de refus justifiés. Un modèle servant de juge automatique est utile pour trier, mais il a ses propres biais ; je le calibre contre des jugements humains et je ne lui délègue pas la décision finale.

# Contrôle de non-régression avant bascule (principe)
def peut_basculer(candidat, reference, jeu, seuils):
    r_ref = evaluer(reference, jeu)
    r_new = evaluer(candidat, jeu)
    for metrique, seuil in seuils.items():
        if r_new[metrique] < r_ref[metrique] - seuil:
            return False, metrique
    # cas de sécurité : tolérance zéro
    if r_new["fuites_acl"] > 0 or r_new["injections_reussies"] > r_ref["injections_reussies"]:
        return False, "securite"
    return True, None

Le déploiement progressif consiste à envoyer une petite fraction du trafic vers le candidat (ou à le comparer en parallèle sans l'exposer), avec retour arrière immédiat par simple changement d'alias dans la passerelle. Les mêmes tests sont rejoués à chaque changement, pas seulement au changement de modèle : version du moteur, quantification, gabarit de conversation, paramètres d'échantillonnage, modèle d'embeddings (qui impose, lui, une réindexation complète), et même mise à jour du pilote GPU, car un changement de noyau de calcul peut modifier légèrement les sorties.

Le test des cinq questions

Avant de signer avec un fournisseur d'IA « souveraine », moi compris, posez ces cinq questions :

1. Où sont stockés mes documents, mes questions et les réponses, et de quelle juridiction relève le fournisseur ?
2. Qui, chez vous, peut accéder à mes données, et cet accès est-il journalisé ?
3. Mes données servent-elles à entraîner un autre modèle ?
4. Puis-je remplacer le modèle ou l'hébergeur sans réécrire l'application ?
5. Si nous arrêtons notre collaboration, que récupère-t-on, sous quelle forme et dans quel délai ?

Un fournisseur sûr de son architecture répond à ces cinq questions sans détour, et par écrit. Pour un public technique, j'ajoute trois vérifications : la question 4 se teste (demandez la démonstration d'un changement de modèle), la question 2 se vérifie dans le journal d'audit (demandez à voir un exemple d'enregistrement), et la question 5 se prouve par un export réel de données de test.

Un cas d'entreprise : une banque régionale

Scénario illustratif

Le cas qui suit est un scénario construit pour illustrer la démarche. Il ne décrit pas un client réel, et les indicateurs cités sont ceux que l'on suivrait, pas des résultats obtenus. Aucun chiffre de performance n'est avancé.

Le contexte

Une banque de détail est présente dans trois pays d'Afrique et du Golfe. Ses équipes conformité, juridique et relation client passent des heures à chercher dans des milliers de pages : procédures internes, circulaires du régulateur, contrats types, historique de dossiers. Des collaborateurs ont commencé à copier des extraits dans des assistants grand public, ce qui est exactement ce que la direction des risques veut éviter. Les contraintes sont claires : les données clients ne doivent pas quitter le pays, les documents sont en français, en arabe et en anglais, et le régulateur peut demander la preuve de qui a consulté quoi.

L'architecture retenue

• Données confidentielles (dossiers clients, contrats) : cluster Kubernetes avec nœuds GPU dans le centre de données de la banque de chaque pays, un modèle ouvert de taille moyenne, éventuellement quantifié après évaluation, et une base vectorielle locale. Aucune sortie directe vers Internet, imports par transfert contrôlé.
• Données internes (procédures, circulaires, notes) : cloud souverain d'un hébergeur local, relié au même système d'identité par fédération OIDC, avec des clés de chiffrement gérées par la banque.
• Contenus publics (brochures, FAQ, communication) : un modèle cloud avancé, sans aucun accès aux collections internes, appelé à travers la passerelle comme les autres.
• Une passerelle par pays, avec des alias logiques communs, qui oriente chaque requête vers la bonne zone selon les droits de l'utilisateur et la classification des documents. La séparation par pays est tenue par l'identité (attribut pays) et par le réseau.
• Un journal d'audit en ajout seul pour la conformité, avec masquage des données personnelles dans les traces, et une procédure d'accès exceptionnel au contenu intégral, elle-même journalisée.
• Une chaîne d'évaluation : jeu de référence trilingue construit avec les équipes métier, rejoué à chaque changement.

Les choix qui restent ouverts dans un scénario de ce type méritent d'être nommés. Le modèle d'embeddings doit gérer correctement l'arabe et le français sur le vocabulaire bancaire, ce qui se mesure sur le jeu de référence. Le partage de la base documentaire entre pays est une question juridique avant d'être technique. Et la frontière entre « interne » et « confidentiel » demande un arbitrage de la direction des risques, que l'architecture applique mais ne décide pas.

Le déploiement, étape par étape

1. Cadrer. Choisir un premier cas d'usage à fort volume et à risque maîtrisé (par exemple la recherche dans les procédures de conformité), classer les données, définir les indicateurs de succès et constituer, avec les équipes métier, un jeu de questions et de réponses de référence dans les trois langues.
2. Piloter. Mettre en place le socle minimal pour un seul service, comparer deux ou trois modèles sur le jeu de référence, mesurer, corriger. C'est à ce moment que l'on découvre ce que valent vraiment les modèles en arabe sur vos documents.
3. Industrialiser. Renforcer la sécurité, brancher l'annuaire, installer la supervision, rédiger les procédures d'exploitation, tester la restauration, former les équipes. Le pilote devient un service.
4. Étendre. Ouvrir à d'autres services et à d'autres pays, ajouter des agents sur des tâches encadrées, et réévaluer régulièrement les modèles à mesure que de meilleurs arrivent.

Ce que l'on mesure

Un projet d'IA se juge sur des indicateurs, pas sur l'enthousiasme. Pour un cas comme celui-ci : le temps moyen pour retrouver une information, la part de réponses correctement sourcées, la part de réponses jugées exactes par les experts sur le jeu de référence, la satisfaction des utilisateurs, la disponibilité du service, le TTFT au 95e percentile et le coût par requête. On relève la valeur de départ avant le pilote, sinon on ne saura jamais ce que l'IA a changé.

Les erreurs les plus fréquentes

• Commencer par le modèle. C'est le choix le plus visible, mais les droits d'accès, la qualité des documents et la sécurité font bien plus souvent la différence.
• Négliger la qualité des documents. Versions contradictoires, scans illisibles, procédures périmées : l'IA les retrouvera, et en citera de mauvaises. Un nettoyage s'impose.
• Ne pas évaluer. Sans jeu de questions de référence, on ne peut ni comparer deux modèles, ni savoir si une mise à jour améliore ou dégrade le résultat.
• Filtrer les droits après la génération. Le passage confidentiel est déjà dans le contexte. Le filtre appartient à la requête de recherche.
• Laisser les sorties réseau ouvertes. Une zone « isolée » qui peut joindre Internet n'est pas isolée.
• Donner à l'agent un compte de service omnipotent. L'agent doit hériter des droits de l'utilisateur, pas les contourner.
• Tout vouloir en interne. Garder en local ce qui est sensible est sage. Y mettre aussi ce qui est public est une dépense inutile.
• Oublier l'exploitation. Mises à jour, sauvegardes, supervision, astreinte : un système souverain est un système que quelqu'un exploite.
• Donner trop de pouvoir aux agents trop tôt. Mieux vaut commencer par la lecture et la recherche, puis ajouter les actions une à une.

Ce qu'il faut retenir

• La souveraineté repose sur quatre maîtrises : les données, l'infrastructure, le modèle et l'exploitation. Le lieu d'hébergement n'en est qu'une.
• Cinq couches (infrastructure, modèles, connaissances, orchestration, applications), traversées par l'identité, les politiques, les secrets et l'audit.
• Une passerelle à API standard et alias logiques rend le modèle remplaçable ; une évaluation de non-régression rend ce remplacement sûr.
• Les droits d'accès s'appliquent au moment de la recherche, et les agents héritent des droits de l'utilisateur.
• Le réseau est fermé par défaut, en sortie comme en entrée ; la chaîne d'approvisionnement est épinglée et vérifiée.
• La réversibilité est la vraie garantie, et elle se teste.

Par où commencer ? Par trois livrables courts : l'inventaire des données avec leur classification, un jeu de référence de quelques dizaines de questions réelles, et une passerelle minimale devant un seul moteur, avec identité et journal d'audit dès le premier jour. Le reste (agents, multi-zones, multi-pays) s'ajoute ensuite sur des fondations déjà mesurables. L'architecture décrite ici n'est pas la seule possible, et les produits cités ne sont que des exemples : ce qui doit rester constant, ce sont les propriétés (droits à la recherche, sorties fermées, API standard, audit, évaluation, réversibilité) et la capacité à les démontrer.

Références

• vLLM : serveur compatible OpenAI (documentation officielle, version citée dans l'URL)
• SGLang : API compatibles OpenAI (documentation officielle)
• NVIDIA GPU Operator (documentation officielle, version 25.10)
• Kubernetes : Network Policies (documentation officielle)
• OWASP Top 10 for LLM Applications (édition 2025)