L’IA de confiance repose évidemment sur un stack technologique.
- 1. Une architecture cible possible
- 2. Première décision : où héberger ?
- Niveau A — Cloud public maîtrisé
- Niveau B — Cloud de confiance
- Niveau C — Infrastructure privée / dédiée
- 3. Pas tous les modèles au même endroit
- 4. Le cœur de la sécurité : IAM + Zero Trust
- 5. Ajouter une vraie couche DLP
- 6. Le deuxième grand sujet : sécuriser les agents
- 7. API Gateway obligatoire
- 8. Il faut également un « AI Firewall »
- 9. Confidential Computing : à surveiller de très près
- 10. Chiffrement : aller plus loin que « AES-256 »
- 11. Le Vector Database mérite une attention particulière
- 12. Observabilité : le SIEM doit voir l’IA
- 13. Et surtout : le « Model Registry »
- 14. La gouvernance technique que je viserais
- 15. Et je ferais une distinction « 3 zones »
- Le point le plus important
- Héberger ses applications et accélérer avec l’IA : oui, mais dans un environnement de confiance !
C’est une architecture de sécurité et de contrôle qui vient se placer entre les utilisateurs, les modèles, les données et le SI de l’entreprise.
Pour une entreprise française/européenne, il faut viser une architecture cloud hybride / cloud de confiance, avec une séparation très nette entre les données, les modèles et les capacités d’action.
1. Une architecture cible possible
Le principe essentiel est :
Le modèle d’IA ne doit jamais être directement connecté au SI.
Il passe par une couche de contrôle qui décide ce qu’il peut voir et ce qu’il peut faire.
2. Première décision : où héberger ?
Il faut distiinguer trois niveaux.
Niveau A — Cloud public maîtrisé
Adapté à beaucoup de cas d’usage non sensibles.
On utilise par exemple des services cloud avec :
- chiffrement ;
- IAM entreprise ;
- isolation réseau ;
- journaux d’audit ;
- région européenne ;
- engagements contractuels sur les données ;
- absence d’utilisation des données client pour l’entraînement, selon le service choisi.
C’est souvent le meilleur compromis pour commencer.
Niveau B — Cloud de confiance
Pour les données réellement sensibles, privilégier une offre SecNumCloud lorsque les exigences de sécurité, de souveraineté ou de réglementation le justifient.
L’ANSSI précise que SecNumCloud concerne des offres IaaS, PaaS, SaaS et CaaS et vise notamment la protection contre les menaces cybercriminelles et certaines contraintes liées aux lois extraterritoriales.
Il faut cependant être très précis :
Héberger une application sur un cloud SecNumCloud ne rend pas automatiquement l’application elle-même SecNumCloud.
L’ANSSI insiste explicitement sur ce point.
Niveau C — Infrastructure privée / dédiée
Pour les données les plus critiques :
- infrastructure dédiée ;
- modèles open-weight déployés dans l’environnement de l’entreprise ;
- réseau privé ;
- clés de chiffrement contrôlées par l’entreprise ;
- éventuellement infrastructure GPU dédiée.
C’est le niveau de contrôle maximal, mais aussi celui qui demande le plus de compétences et d’investissement.
3. Pas tous les modèles au même endroit
C’est un point stratégique.
Construisez de préference un Model Gateway.
Par exemple :
Le gateway décide automatiquement :
Quel modèle a le droit de traiter cette donnée ?
Donnée | Modèle public | Modèle européen | Modèle privé |
Information publique | ✅ | ✅ | ✅ |
Documentation interne | ⚠️ | ✅ | ✅ |
Données clients | ⚠️ | ✅ | ✅ |
Données RH | ❌/⚠️ | ⚠️ | ✅ |
Secret industriel | ❌ | ⚠️ | ✅ |
Données stratégiques | ❌ | ⚠️ | ✅ |
Cela permet de ne pas tomber dans le faux choix :
« Soit on utilise ChatGPT, soit on construit notre propre LLM. »
Il faut plutôt construire une architecture multi-modèles.
4. Le cœur de la sécurité : IAM + Zero Trust
Je considérerais cela comme non négociable.
Chaque requête doit être contextualisée :
Qui ?
Depuis où ?
Pour quelle application ?
Sur quelles données ?
Avec quel niveau d’autorisation ?
Pour quelle action ?
L’IA doit hériter des droits de l’utilisateur.
Exemple :
Paul peut consulter les contrats de son département.
L’IA de Paul peut donc les consulter.
Mais :
Paul ne peut pas consulter les contrats M&A.
L’IA ne doit pas pouvoir les consulter non plus.
Il faut donc une combinaison :
- IAM ;
- SSO ;
- MFA ;
- RBAC ;
- idéalement ABAC ;
- gestion des identités machines ;
- secrets management ;
- segmentation réseau ;
- principe du moindre privilège.
5. Ajouter une vraie couche DLP
Pour moi, DLP + AI Gateway deviennent des composants centraux.
Avant qu’une information parte vers un modèle :
Utilisateur
↓
Détection données sensibles
↓
Classification
↓
Masquage / anonymisation éventuelle
↓
Policy Engine
↓
Modèle autorisé
Exemple :
« Analyse ce fichier contenant 3 000 fiches clients. »
Le système peut détecter :
- noms ;
- emails ;
- IBAN ;
- données financières ;
- informations médicales ;
- secrets commerciaux.
Et appliquer une politique :
❌ modèle public interdit
✅ modèle privé autorisé
OWASP identifie précisément la divulgation d’informations sensibles comme un risque majeur des applications LLM, notamment les données personnelles, financières et confidentielles. (OWASP Foundation)
6. Le deuxième grand sujet : sécuriser les agents
C’est là que le sujet devient beaucoup plus intéressant.
Un chatbot peut essentiellement parler.
Un agent peut :
lire un CRM → créer une commande → modifier un fichier → envoyer un email → appeler une API → déclencher un paiement.
La surface d’attaque explose.
Je mettrais donc une Agent Security Layer :
Et surtout :
Un agent ne doit jamais disposer des droits de l’utilisateur administrateur.
Chaque agent possède son identité propre et des permissions minimales.
7. API Gateway obligatoire
Je mettrais toutes les connexions entre les agents et le SI derrière une API Gateway.
Elle permet :
- authentification ;
- autorisation ;
- limitation du débit ;
- validation des paramètres ;
- journalisation ;
- contrôle des actions ;
- révocation rapide des accès.
Cela évite :
LLM → directement ERP
et impose :
LLM → Agent → Policy Engine → API Gateway → ERP
C’est beaucoup plus sûr.
8. Il faut également un « AI Firewall »
C’est un composant que je considère particulièrement intéressant pour l’avenir.
Il contrôle :
Entrées
- prompt injection ;
- contenu malveillant ;
- données sensibles ;
- fichiers dangereux ;
- demandes hors périmètre.
Sorties
- données personnelles ;
- secrets ;
- informations confidentielles ;
- contenu non conforme ;
- réponses dangereuses.
Actions
- appel API ;
- écriture ;
- suppression ;
- transaction ;
- email ;
- modification de données.
OWASP classe notamment Prompt Injection, Sensitive Information Disclosure, Supply Chain et Data/Model Poisoning parmi les principaux risques des applications GenAI. (OWASP GenAI)
9. Confidential Computing : à surveiller de très près
Pour les entreprises qui veulent aller loin dans la confidentialité, je regarderais également le confidential computing.
L’idée est de protéger les données pendant leur traitement, et pas uniquement :
- au repos ;
- en transit.
On utilise des environnements d’exécution protégés, typiquement basés sur des Trusted Execution Environments (TEE).
Cela devient particulièrement intéressant pour :
- données très sensibles ;
- traitements externalisés ;
- inférence de modèles ;
- collaboration entre entreprises ;
- secteurs réglementés.
Ce n’est pas nécessaire pour commencer, mais c’est une brique que je mettrais dans l’architecture cible.
10. Chiffrement : aller plus loin que « AES-256 »
Il faut prévoir :
Au repos
- chiffrement des bases ;
- chiffrement des documents ;
- chiffrement des backups ;
- chiffrement des vector stores.
En transit
- TLS ;
- mTLS entre services critiques.
Clés
Idéalement :
- KMS ;
- HSM pour les secrets critiques ;
- rotation des clés ;
- séparation des responsabilités.
Et surtout :
L’entreprise doit maîtriser ses clés pour les données les plus sensibles.
11. Le Vector Database mérite une attention particulière
C’est souvent oublié.
Dans une architecture RAG, les documents sont transformés en embeddings puis stockés dans une base vectorielle.
On peut donc avoir :
une fuite massive d’informations sans que les documents originaux ne soient directement exposés.
Je traiterais donc le Vector DB comme une base de données sensible, avec :
- authentification ;
- chiffrement ;
- contrôle d’accès ;
- segmentation par domaine ;
- filtrage au niveau des requêtes ;
- logs ;
- politique de rétention.
Et surtout, ne pas faire :
« Tout le SharePoint dans un Vector DB. »
Il faut respecter les ACL d’origine.
12. Observabilité : le SIEM doit voir l’IA
Je créerais un AI Security Operations Center ou, plus simplement au départ, une extension du SOC existant.
Il doit surveiller :
- prompts anormaux ;
- accès inhabituels ;
- extraction massive de données ;
- appels API anormaux ;
- comportement des agents ;
- changements de modèles ;
- changements de prompts système ;
- violations de policy ;
- coûts anormaux ;
Les logs devraient alimenter le SIEM de l’entreprise.
13. Et surtout : le « Model Registry »
Élément | Informations |
Modèle | Version |
Fournisseur | Localisation |
Données autorisées | Classification |
Données interdites | Classification |
Usage | Métier |
Niveau de risque | Faible / moyen / élevé |
Performance | Benchmarks |
Coût | €/requête |
Sécurité | Évaluation |
Statut | Autorisé / expérimental / interdit |
Ainsi, un collaborateur ne choisit pas arbitrairement n’importe quel modèle pour n’importe quelle donnée.
14. La gouvernance technique que je viserais
Au final, je construirais une plateforme avec ces composants :
AI TRUST PLATFORM
- Identity
- IAM
- SSO
- MFA
- RBAC/ABAC
- Data Security
- DLP
- classification
- chiffrement
- KMS/HSM
- AI Gateway
- routing modèles
- quotas
- policies
- filtrage
- Knowledge Layer
- RAG
- vector DB
- data catalog
- ACL
- Model Layer
- modèles cloud
- modèles européens
- modèles privés
- modèles open-weight
- Agent Layer
- orchestrateur
- tools
- API Gateway
- permissions
- Security
- WAF
- Zero Trust
- SIEM
- SOC
- EDR/XDR
- AI Governance
- Model Registry
- AI inventory
- risk classification
- evaluation
- audit
- Human Control
- validation ;
- approbation ;
- kill switch ;
15. Et je ferais une distinction « 3 zones »
C’est probablement la recommandation la plus concrète que je donnerais à une entreprise.
🟢 Zone 1 — IA publique
Données :
publiques / faiblement sensibles
Technologies :
Cloud public + modèles externes + AI Gateway.
🟠 Zone 2 — IA entreprise
Données :
internes / confidentielles
Technologies :
Cloud entreprise européen ou cloud de confiance + RAG privé + IAM + DLP + SIEM.
🔴 Zone 3 — IA souveraine / critique
Données :
stratégiques / secrets industriels / données réglementées
Technologies :
SecNumCloud ou infrastructure dédiée + modèles déployés dans un environnement maîtrisé + clés contrôlées par l’entreprise + segmentation forte + éventuellement confidential computing.
La France dispose aujourd’hui d’une offre SecNumCloud identifiée par l’ANSSI ; la liste officielle comprend notamment des offres d’Adista, Bleu, OVHcloud, Scaleway et d’autres prestataires. Il faut toutefois vérifier l’offre précisément qualifiée, et non simplement le fait qu’un fournisseur propose du cloud.
Le point le plus important
On déconseille fortement de lancer un projet du type :
« Construisons notre propre IA souveraine. »
Préférez plutôt :
« Construisons notre propre plateforme d’IA de confiance, capable d’utiliser différents modèles selon la sensibilité des données et le niveau de risque de l’action. »
C’est beaucoup plus robuste technologiquement.
Et cela permet de rester indépendant de l’évolution des modèles : le modèle devient une commodité interchangeable ; la plateforme de confiance, les données, les règles métier et les intégrations deviennent le patrimoine stratégique.
Enfin, le contexte réglementaire européen renforce cette nécessité : l’AI Act est désormais dans sa phase d’application progressive, avec notamment les dispositions devenues applicables en août 2026 et les règles relatives aux systèmes à haut risque prévues pour décembre 2027. (Voir la Stratégie numérique européenne)
Si je devais transformer cela en projet concret, l’étape suivante serait de définir un “stack technologique cible”, couche par couche — par exemple hébergement / GPU / modèles / Kubernetes / IAM / DLP / RAG / vector DB / API Gateway / SIEM / SOC / monitoring / gouvernance — avec, pour chaque couche, 3 options : souveraine française, européenne et cloud international, et une recommandation selon le niveau de sensibilité.
Héberger ses applications et accélérer avec l’IA : oui, mais dans un environnement de confiance !
L’IA ouvre de nouvelles perspectives pour les entreprises : gains de productivité, innovation, automatisation… Mais comment en tirer pleinement parti sans perdre la maîtrise de ses données, de ses applications et de son environnement numérique ?
Entre exigences de cybersécurité, protection des données, performance et souveraineté numérique, le choix de l’environnement d’hébergement devient un enjeu stratégique.
C’est tout l’objet de notre table ronde digitale :
« Comment héberger vos applications et accélérer avec l’IA en toute sérénité dans un environnement de confiance ? »
Au programme des échanges :
Hébergement de confiance : quels critères privilégier pour sécuriser ses applications et ses données ?
Cybersécurité et maîtrise des risques : comment concilier innovation, protection et conformité ?
Intelligence artificielle : comment accélérer ses projets IA tout en gardant le contrôle sur ses données et ses usages ?
Du projet à la réalité : quelles solutions concrètes pour adopter le cloud et l’IA avec confiance ?
Notre ambition : vous donner les clés pour faire les bons choix technologiques, accélérer votre transformation numérique et exploiter le potentiel de l’IA dans un environnement maîtrisé et sécurisé.
Rendez-vous en ligne pour échanger autour des solutions et des bonnes pratiques qui permettent de concilier innovation, confiance et performance.
Date : 12 Novembre 2026
Horaire : de 11h à 12h
