Cloud public et IA générative : où partent réellement les documents soumis au modèle ?
Par Emmanuel Forgues - 12 juillet 2026
Les services d’IA générative hébergés sur les clouds publics (OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI…) traitent chaque jour des millions de fichiers texte, images ou code source. Pour les organisations qui y confient leurs données sensibles – contrats, brevets, dossiers patients – la question n’est plus seulement «<0xE2><0x80><0xAF>le modèle peut‑il répondre correctement<0xE2><0x80><0xAF>?<0xE2><0x80><0xAF>» mais «<0xE2><0x80><0xAF>où ces documents sont‑ils réellement stockés, pendant combien de temps et à quelles fins<0xE2><0x80><0xAF>?<0xE2><0x80><0xAF>». Ce texte décortique l’architecture typique des services IA dans le cloud, décrit le cycle complet de la donnée depuis son ingestion jusqu’à sa possible réutilisation, analyse les exigences réglementaires (RGPD, AI Act) et les risques de confidentialité, puis propose un canevas d’actions concrètes pour maîtriser la souveraineté des informations tout en tirant parti des gains de productivité offerts par l’IA générative.
Introduction : le dilemme du “cloud‑first” à l’ère des modèles génératifs
Depuis le lancement de GPT‑3 (2020) et son évolution vers les suites GPT‑4, Claude ou Gemini, les entreprises ont rapidement adopté les API d’IA générative pour automatiser la rédaction de rapports, synthétiser des dossiers juridiques ou créer du code. Le modèle économique dominant repose sur un cloud‑first<0xE2><0x80><0xAF>: le fournisseur héberge le modèle et expose une interface HTTP/REST où le client envoie son texte (prompt) et reçoit la réponse.
Cette approche séduit par sa simplicité d’intégration, son évolutivité quasi illimitée et l’accès à des modèles continuellement mis à jour. Mais elle soulève un point de friction majeur<0xE2><0x80><0xAF>: la donnée d’entrée quitte les frontières du périmètre de sécurité interne. Les organisations se retrouvent face à une série d’interrogations :
- Le texte soumis est‑il conservé, même temporairement, sur le serveur du fournisseur ?
- Quels logs ou métriques sont générés et qui y a accès ?
- La sortie (texte généré) peut‑elle être réutilisée pour affiner le modèle sans consentement explicite ?
Ces questions impactent la conformité au RGPD, aux exigences de l’AI Act européen, ainsi que les obligations contractuelles de confidentialité. La suite décrit avec précision où partent réellement les documents lorsqu’ils transitent par un service d’IA générative en cloud public, et comment les organisations peuvent contrôler ce flux.
1. Architecture typique d’un service IA génératif dans le cloud public
| Composant | Fonction principale | Localisation (exemple) |
|---|---|---|
| API Gateway | Authentification, quota, routage des requêtes | Front‑end du fournisseur (AWS API Gateway, Azure Front Door) |
| Load Balancer | Distribution de charge entre les nœuds d’inférence | Région cloud (ex. us‑east‑1) |
| Inference Nodes | Exécution du modèle (GPU/TPU) | Clusters dédiés, souvent isolés par VPC |
| Data Staging Layer | Buffer temporaire des prompts avant inference | Stockage éphémère (S3 / Blob Storage) avec TTL de quelques minutes |
| Logging & Monitoring | Capture d’événements, métriques de performance | Services CloudWatch, Azure Monitor, Stackdriver |
| Model Training Pipeline (optionnel) | Ré‑entraînement continu à partir de données agrégées | Data Lake centralisé du fournisseur |
| Security Controls | Chiffrement en transit (TLS 1.3), chiffrement au repos (AES‑256) | Géré par le provider selon ses standards |
Cette architecture repose sur des zones d’isolation : les nœuds d’inférence sont généralement séparés du stockage persistant et ne conservent les prompts que pendant la durée de l’opération d’inférence. Toutefois, les pratiques exactes varient d’un fournisseur à l’autre et sont souvent décrites dans les whitepapers de sécurité (voir références [1][2]).
2. Cycle de vie des données soumises : de l’ingestion au traitement
2.1 Ingestion du prompt
- Connexion sécurisée – Le client établit une connexion TLS 1.3 et transmet le token d’authentification (OAuth 2.0, API‑Key).
- Transmission du payload – Le texte est encapsulé dans un JSON ("prompt": "…"). Aucun pré‑chiffrement n’est imposé par défaut, mais les clients peuvent chiffrer la charge utile avec leur propre clé publique (ex. RSA‑OAEP) avant l’envoi.
2.2 Validation et mise en file d’attente
Le service valide le format, applique des filtres de contenu (détection de PII, prévention de génération malveillante) puis place le prompt dans une queue éphémère (ex. Amazon SQS). La durée maximale de rétention est généralement de l’ordre de la seconde à quelques minutes.
2.3 Stockage temporaire
Le payload passe souvent par un object store transitoire (S3 / Blob) avec une TTL configurable (souvent < 5 minutes). Ce stockage sert uniquement à décorréler le réseau du calcul GPU et est automatiquement purgé.
2.4 Traitement par le modèle
Le nœud d’inférence charge le prompt en mémoire vive, l’alimente au modèle, récupère la séquence de tokens générée puis libère immédiatement la zone mémoire. Aucun disque persistant n’est utilisé pour le prompt pendant cette phase.
3. Persistance et rétention : logs, caches et entraînement continu
| Élément | Pourquoi il est conservé ? | Durée typique | Accès possible |
|---|---|---|---|
| Logs d’accès (IP, timestamp, user‑agent) | Audit, facturation, détection d’abus | 30 jours – 1 an (selon politique du provider) | Équipe ops du fournisseur, client via API de logs |
| Métriques d’inférence (latence, token count) | Optimisation de la capacité | 90 jours | Provider uniquement |
| Cache de réponses | Amélioration du temps de réponse pour prompts identiques | Variable (TTL configurable) | Provider; parfois partagé entre clients anonymisés |
| Dataset d’entraînement dérivé des prompts | Fine‑tuning continu, amélioration du modèle | Indéfini (si opt‑in) | Provider uniquement |
Les fournisseurs affichent généralement que les prompts ne sont pas stockés à long terme, sauf si le client active explicitement une option de «<0xE2><0x80><0xAF>data logging for model improvement<0xE2><0x80><0xAF>». Par défaut, les prompts sont supprimés après la période d’inférence, mais les métadonnées (horodatage, hash du prompt) restent dans les logs pour des raisons opérationnelles et légales [3].
4. Gouvernance et conformité : quels cadres s’appliquent ?
| Cadre | Implication concrète |
|---|---|
| RGPD (Art. 5‑9) | Obligation de minimiser la collecte, informer les personnes concernées, garantir le droit à l’effacement. Le fournisseur doit offrir un moyen d’invoquer le right to be forgotten sur les données stockées. |
| AI Act (projet, Chapitre II) | Classification des modèles « à haut risque » lorsqu’ils traitent des données sensibles; exigences de documentation et de traçabilité des jeux de données utilisés pour l’entraînement. |
| NIST SP 800‑53 Rev 5 – Privacy Controls | Contrôles AC‑1 (Access Control), PL‑2 (Plan de confidentialité) applicables aux services cloud. |
| ENISA “Threat Landscape for Generative AI” (2023) | Recommandations sur la journalisation, le chiffrement et les tests d’injection de données. |
En pratique, les contrats SaaS (CSA<0xE2><0x80><0xAF>Star, ISO/IEC<0xE2><0x80><0xAF>27001) précisent :
- Le data residency – où physiquement les données temporaires sont stockées (ex. région EU).
- Les conditions de data retention – durée maximale de conservation et processus de purge.
- L’option d’opt‑out du réentraînement à partir des prompts client.
5. Risques de confidentialité et vecteurs d’attaque
| Risque | Description | Impact potentiel |
|---|---|---|
| Fuite via logs d’audit | Un prompt contenant une PII peut être inscrit dans les journaux de requêtes, accessibles aux équipes du provider ou à des tiers en cas de compromission. | Violation RGPD, sanctions jusqu’à 4 % du CA mondial. |
| Cache partagé | Si le cache n’est pas correctement segmenté, un client A pourrait recevoir une réponse générée à partir d’un prompt de client B (confidentialité croisée). | Perte de secret commercial. |
| Ré‑entraînement non consentie | Les fournisseurs peuvent intégrer les prompts dans leurs jeux d’entraînement pour améliorer le modèle sans accord explicite. | Exposition de données sensibles, risques de “model inversion”. |
| Attaque par injection de prompt | Un acteur malveillant insère des instructions cachées (« prompt injection ») qui forcent le modèle à divulguer des informations internes ou à exécuter des actions non autorisées. | Escalade de privilèges, exfiltration de données. |
Ces risques apparaissent régulièrement dans les rapports d’incidents de l’ANSSI (2023) et de la CISA (2024). La mitigation repose sur le chiffrement côté client, des politiques de rétention strictes et la surveillance des logs.
6. Bonnes pratiques pour les organisations : sécuriser le flux de documents
6.1 Chiffrement de bout en bout
- Pré‑chiffrer le prompt avec une clé publique du client (ex. RSA‑OAEP, 4096 bits). Le serveur ne pourra pas déchiffrer la charge utile, mais pourra tout de même exécuter le modèle si le provider propose un secure enclave capable de décoder temporairement la donnée en mémoire isolée.
6.2 Anonymisation / Pseudonymisation
- Supprimer ou remplacer les champs d’identification (nom, numéro de sécurité sociale) avant l’envoi. Utiliser des outils comme Presidio (Microsoft) ou Deid‑AI pour automatiser le processus.
6.3 Contrôle du stockage transitoire
- Configurer la TTL du bucket temporaire via les paramètres d’API (ex. storage_ttl=60s). Vérifier que le provider respecte cette configuration dans ses audits de conformité.
6.4 Gestion des logs
- Activer le log redaction côté client pour masquer les prompts dans les journaux CloudWatch ou Azure Monitor.
- Mettre en place une rétention limitée (ex. 30 jours) et un processus d’effacement automatisé.
6.5 Clauses contractuelles
- Insérer des SLAs de suppression (ex. « les données client sont définitivement détruites 24 h après traitement ») dans le contrat.
- Exiger une auditabilité indépendante (SOC 2 Type II, ISO 27018) et la possibilité d’obtenir les rapports d’audit.
6.6 Surveillance des réponses
- Déployer un prompt‑injection detector qui analyse les sorties du modèle à la recherche de fuites potentielles (ex. code source ou données sensibles).
7. Cas d’usage concret : génération automatisée de contrats juridiques pour une PME
Contexte – Une société de services informatiques souhaite automatiser la rédaction de contrats de prestation (SLA, NDA) à partir de modèles pré‑définis et des réponses du client.
| Étape | Processus technique | Mesure de protection |
|---|---|---|
| 1. Collecte d’informations | Formulaire web interne → JSON contenant les clauses spécifiques | Chiffrement TLS + chiffrement symétrique (AES‑256) avant envoi au cloud |
| 2. Envoi du prompt | {"prompt":"Rédige un contrat de prestation incluant …"} envoyé à Azure OpenAI | Pré‑chiffrement avec clé publique de l’entreprise; token d’accès limité à la fonction completion |
| 3. Traitement IA | Modèle GPT‑4 exécute l’inférence dans une enclave isolée | Aucun stockage persistant du prompt ; TTL du bucket = 30 s |
| 4. Réception du texte | Retour sous forme de texte brut, décodé côté client | Vérification de conformité (détection de PII) avant sauvegarde interne |
| 5. Archivage | Document signé stocké dans le DMS interne (on‑prem) | Aucun transfert ultérieur vers le provider |
Résultats – Le temps moyen de génération passe de 45<0xE2><0x80><0xAF>minutes à 12<0xE2><0x80><0xAF>secondes, avec un taux d’erreur lexical <<0xE2><0x80><0xAF>1<0xE2><0x80><0xAF>%. Les mesures appliquées assurent la conformité au RGPD (article<0xE2><0x80><0xAF>30) et la certification ISO<0xE2><0x80><0xAF>27001 pour le processus IA.
8. Perspectives et évolutions : vers une souveraineté accrue
| Tendance | Impact sur la localisation des données |
|---|---|
| Edge AI (inférence locale sur appareils ou serveurs de proximité) | Réduction drastique du besoin d’envoyer les prompts au cloud public ; conformité « data‑locality » facilitée. |
| Federated Learning (apprentissage distribué) | Les modèles s’enrichissent sans centraliser les données brutes, limitant le risque d’exposition. |
| Zero‑Trust Architecture pour l’IA | Authentification forte à chaque appel, micro‑segmentation du trafic IA, audit continu. |
| Réglementation renforcée (AI Act final) | Obligation de fournir un “Data Usage Statement” détaillé et de permettre le retrait des données utilisées pour le fine‑tuning. |
Ces évolutions indiquent que les organisations pourront, à moyen terme, choisir entre cloud public avec contrôles stricts ou déploiement hybride/edge selon leur sensibilité aux données.
9. Points de vigilance
⚠️ Confidentialité des logs – Même si le prompt est effacé, les métadonnées (hash, timestamp) peuvent permettre une re‑identification lorsqu’elles sont combinées à d’autres sources.
⚠️ Opt‑in implicite – Certains fournisseurs activent par défaut la réutilisation des prompts pour améliorer leurs modèles ; il faut vérifier la configuration du compte.
⚠️ Juridiction de stockage – La localisation géographique du bucket temporaire influe sur le droit applicable (RGPD vs US CLOUD ACT).
10. Ce qu’un décideur doit retenir
| Décideur | Action prioritaire |
|---|---|
| Direction | Exiger des clauses contractuelles de suppression et d’auditabilité avant toute adoption du service IA. |
| RSSI / DSI | Mettre en place un chiffrement de bout en bout et une politique de rétention stricte pour les prompts. |
| Architecte Cloud | Choisir une région EU‑compliant, activer le data residency et configurer la TTL du stockage transitoire. |
| Responsable juridique / DPO | Vérifier que le fournisseur propose un mécanisme d’exercice du droit à l’effacement des prompts. |
Conclusion opérationnelle
L’utilisation d’IA générative dans le cloud public accroît la productivité, mais implique un parcours de données complexe où chaque étape (ingestion, mise en file, traitement, journalisation) peut constituer un point de fuite. En identifiant précisément le lieu de stockage des documents, leur durée de conservation et les finalités de leur réutilisation, les organisations équilibrent innovation et souveraineté des données.
Le chiffrement côté client, l’anonymisation préalable, la configuration stricte de la TTL et l’audit contractuel réduisent le risque à un niveau acceptable, conformément aux exigences du RGPD et du futur AI Act. Le déplacement des modèles vers l’edge et la démocratisation du federated learning diminueront la dépendance au cloud public, mais la vigilance demeure indispensable tant que des données sensibles transitent par des services partagés.
Recommandations prioritaires
- Cartographier le flux de données pour chaque usage d’IA générative (prompt → réponse).
- Activer le chiffrement de bout en bout et la pseudonymisation avant l’envoi au cloud.
- Configurer la rétention minimale des buckets temporaires (≤ 5
Poursuivre le parcours : Conformité NIS2, DORA et RGPD → Solution → Produit → Demander une démonstration