API publique, cloud privé ou on-premise : où traiter les données sensibles ?

Réponse en bref

Pour traiter des données sensibles avec une IA, choisissez une API publique lorsque la minimisation, le contrat fournisseur et les contrôles d'accès suffisent. Préférez un cloud privé lorsque vous devez garder le trafic dans un périmètre réseau maîtrisé et administrer les clés, les journaux et les identités. Réservez l'on-premise aux contraintes fortes de résidence, de connectivité ou d'exploitation locale. Dans les trois cas, la décision porte sur tout le chemin de la donnée, pas seulement sur le lieu où le modèle produit sa réponse.

Cette conclusion est une règle d'architecture, pas un classement universel. Les capacités changent selon le fournisseur, le modèle et la fonctionnalité activée. Les documentations d'OpenAI, AWS, Google Cloud et Microsoft décrivent chacune des conditions différentes de conservation, de résidence et d'accès aux données. Elles doivent être relues pour le service exact avant un contrat ou une mise en production (OpenAI, contrôles de données par endpoint, AWS Bedrock, protection des données, Google Vertex AI, zero data retention, Microsoft Foundry, confidentialité des données).

Schéma Nexxom : la classification et la politique de données déterminent l'architecture à examiner. Le schéma illustre une logique de décision, pas une obligation réglementaire.

Le vrai critère n'est pas la localisation seule

La résidence géographique est un critère important, mais elle ne répond pas à quatre questions opérationnelles : quelles données quittent le système source, qui peut les lire, combien de temps elles sont conservées et comment les supprimer ou les auditer ? Une charge de travail « privée » peut encore exposer des prompts dans des journaux, des traces d'outillage ou des sauvegardes. À l'inverse, une API publique peut convenir si le texte envoyé est minimisé, si les journaux sont contrôlés contractuellement et si les identifiants sont séparés des données métier.

Avant de comparer les options, décrivez le trajet suivant : source métier, proxy ou passerelle, fournisseur de modèle, journaux d'application, outils appelés par l'agent, stockage des sorties, sauvegardes et systèmes humains qui consultent les traces. Cette cartographie rend visibles les copies souvent oubliées. Elle complète un registre d'IA et une analyse de risques inspirés du NIST AI Risk Management Framework et de son profil pour l'IA générative NIST AI 600-1.

Le principe de zero trust décrit dans NIST SP 800-207 est utile ici : ne faire confiance à aucun réseau ou service par défaut, vérifier explicitement l'identité, le contexte et l'autorisation de chaque appel. La localisation choisie n'annule ni les contrôles d'identité, ni la segmentation, ni la journalisation.

API publique : rapidité et contrôle par contrat

Une API publique est un service managé accessible par HTTPS. Elle est pertinente pour un pilote, un traitement à faible volume ou un cas où l'entreprise préfère confier l'exploitation de l'infrastructure au fournisseur. Le risque principal se déplace vers la sélection des endpoints, le contrat, la configuration et le proxy applicatif.

OpenAI indique que les données envoyées à l'API ne servent pas à entraîner les modèles par défaut. La même documentation précise que les journaux de surveillance des abus peuvent être conservés jusqu'à 30 jours par défaut et que l'éligibilité à une conservation nulle varie selon l'endpoint. Une politique de rétention doit donc être vérifiée pour l'endpoint réellement appelé, et non déduite du simple mot « API » (documentation OpenAI).

Une API ne doit jamais recevoir plus de données que nécessaire. Le proxy doit supprimer les identifiants directs, limiter les champs, appliquer une politique de taille et refuser les pièces jointes non prévues. Il doit aussi distinguer les logs techniques, les prompts, les réponses et les données de sécurité. Les clés d'API appartiennent à un coffre de secrets, jamais au navigateur ou au code source. Les permissions et les journaux d'accès doivent suivre le principe du moindre privilège, comme le recommande la documentation AWS IAM pour Bedrock.

La faiblesse d'une API publique n'est pas automatiquement l'absence de sécurité. Elle est l'impossibilité de contrôler certaines couches opérées par le fournisseur. Il faut donc obtenir les garanties dans la documentation, le contrat, l'avenant de traitement des données et les paramètres de compte. La documentation AWS sur la responsabilité partagée rappelle que le fournisseur protège le service, tandis que le client reste responsable des données, des identités et de la configuration.

Cloud privé : périmètre réseau et services managés

Le cloud privé désigne ici un déploiement dans un compte ou un projet contrôlé par l'entreprise, avec réseau privé, IAM, clés gérées par le client et journaux centralisés. Le modèle peut être un service managé accessible dans ce périmètre ou un composant déployé sur des ressources dédiées. Ce terme ne signifie pas qu'aucun tiers n'intervient : l'hyperviseur, le fournisseur de cloud, le modèle et les services de support ont chacun un rôle à vérifier.

Google Cloud publie un tableau de contrôles par modèle et fonctionnalité. La résidence des données, les clés CMEK, VPC Service Controls et Access Transparency ne sont pas disponibles de façon identique pour chaque service. La conclusion est simple : il faut lire la ligne correspondant au modèle, à la région et à la fonctionnalité retenus, puis la conserver dans le dossier d'architecture (contrôles de sécurité Vertex AI). Google précise également que certaines données peuvent être conservées pour fournir la fonctionnalité, prévenir les abus ou assurer le support, avec des règles distinctes selon le scénario (zero data retention Vertex AI).

Le cloud privé apporte souvent un meilleur contrôle du chemin réseau, de la segmentation et des clés. Il augmente en revanche le travail de configuration : règles egress, certificats, rotation des secrets, routes de secours, observabilité, tests de restauration et contrôle des accès opérateurs. La sécurité réelle est celle qui est maintenue après six mois, pas celle dessinée dans un diagramme initial.

On-premise : contrôle local, responsabilité locale

L'on-premise est justifié lorsque les données ne peuvent pas sortir du site ou d'une zone administrative, lorsque la connectivité externe est intermittente, ou lorsque l'organisation doit maîtriser chaque composant de l'inférence. Il peut aussi répondre à une contrainte de latence physique. Il ne transforme pas une donnée sensible en donnée sûre : le stockage, les GPU, les sauvegardes, les comptes administrateurs, les dépendances logicielles et les journaux restent à protéger.

Un déploiement local impose un inventaire de versions, une chaîne de correctifs, une gestion des modèles, des tests de régression et un plan de remplacement matériel. Il faut définir qui répond à une alerte, qui peut extraire les traces et combien de temps les sorties sont conservées. Les recommandations du NIST AI RMF Playbook et les travaux NIST sur la sécurité et la résilience de l'IA donnent une structure pour ces responsabilités, sans imposer une topologie particulière.

Le coût caché est opérationnel. Une équipe doit assurer les mises à jour de sécurité du système, du runtime d'inférence, des pilotes, de la couche réseau et des outils de supervision. Si ces tâches ne sont pas financées, le contrôle théorique de l'on-premise devient un risque de disponibilité et de vulnérabilité.

Comparer les trois options

Le tableau suivant sépare des propriétés observables de recommandations de contexte. « Élevé » ne signifie pas « meilleur » : davantage de contrôle suppose souvent davantage de travail et de responsabilités.

Matrice Plotly statique produite par Nexxom. Les valeurs 1, 2 et 3 sont une heuristique éditoriale explicite : elles servent à lire les compromis du tableau, pas à représenter une mesure de fournisseur ou un benchmark.

Grille de décision reproductible

Pour éviter le débat abstrait « cloud contre local », notez chaque contrainte sur une échelle documentée. L'équipe peut ensuite conserver la justification dans le dossier de traitement.

Cette grille ne remplace pas une analyse juridique. Le NIST AI RMF est volontaire et n'établit pas à lui seul une conformité réglementaire. Le contrat, la qualification des données, les obligations sectorielles et les exigences du délégué à la protection des données restent déterminants.

Contrôles transversaux à exiger

Quelle que soit l'architecture, imposez une séquence minimale :

1. Classifier les entrées, sorties, pièces jointes, embeddings et journaux.
2. Minimiser avant l'appel : supprimer les identifiants inutiles, tronquer les champs et séparer les clés de jointure.
3. Authentifier chaque service avec des identités distinctes, une rotation des secrets et des permissions limitées.
4. Chiffrer en transit et au repos, puis décider qui possède les clés et qui peut les révoquer.
5. Journaliser les décisions et les erreurs sans recopier automatiquement le contenu sensible dans un log général.
6. Tester la suppression, la restauration, le changement de modèle et la réponse à incident.
7. Réviser la documentation du fournisseur à chaque changement d'endpoint, de modèle ou de région.

Les fonctionnalités d'un fournisseur ne sont pas interchangeables. Microsoft souligne que les contrôles et la rétention varient selon le type de déploiement et les fonctionnalités Azure utilisées (Azure OpenAI et confidentialité). AWS décrit également des contrôles comme TLS, IAM, CloudTrail et le chiffrement, mais leur activation et leur configuration relèvent du client (protection des données Bedrock).

Trois scénarios de choix

Assistant documentaire interne avec données pseudonymisées. Une API publique peut être raisonnable si le proxy retire les identifiants, si le fournisseur documente la rétention de l'endpoint et si les réponses ne sont pas réinjectées dans un système décisionnel sans validation. Une solution cloud privé devient préférable si l'entreprise doit centraliser les journaux ou interdire l'egress général.

Analyse de dossiers réglementés sans sortie de site. L'on-premise est le candidat naturel, mais il faut vérifier la capacité de l'équipe à patcher et superviser la plateforme. Si cette capacité n'existe pas, un cloud privé avec région, clés et segmentation prouvées peut réduire le risque opérationnel, à condition que la politique l'autorise.

Prototype avec données réelles non nécessaires. Ne déplacez pas des données sensibles pour tester une interface. Créez un jeu synthétique ou fortement pseudonymisé, mesurez les sorties et documentez les limites. Le choix d'architecture devient alors un choix de vitesse et de réversibilité, pas une exception permanente à la gouvernance.

Limites et points de vigilance

Une région cloud ne garantit pas que tous les traitements, supports, métadonnées ou sauvegardes restent dans cette région. Une clé gérée par le client ne garantit pas que l'application ne conserve pas une copie en clair. Un modèle local ne garantit pas l'absence de fuite par les prompts, les logs ou les outils appelés. Chaque affirmation doit être reliée à un composant, une configuration et une preuve.

N'exposez pas de données réelles dans un test de fournisseur pour vérifier une promesse de confidentialité. Utilisez un corpus synthétique, une procédure de validation contractuelle et un test de suppression contrôlé. Si la question concerne une obligation légale, faites valider l'interprétation par la fonction juridique ou le DPO.

Conclusion

La meilleure architecture est celle qui rend le chemin de la donnée observable et maintenable. Commencez par classifier et minimiser. Choisissez ensuite l'API publique pour les cas à faible exposition et à forte exigence de vitesse, le cloud privé pour un périmètre réseau et IAM plus contrôlé, et l'on-premise pour une contrainte réelle de sortie ou de connectivité. Dans tous les cas, archivez la preuve de rétention, de résidence, d'accès, de suppression et de responsabilité avant de déclarer le traitement conforme.

Pour aller plus loin, reliez cette décision à un registre d'IA, à vos contrôles de gouvernance et à votre stratégie de sécurité des applications LLM. Nexxom peut ensuite vous aider à transformer la grille en architecture testable et en procédures d'exploitation.

Sources primaires vérifiées le 19 août 2026

• OpenAI, contrôles de données par endpoint
• AWS, protection des données dans Amazon Bedrock
• AWS, guide de sécurité IAM pour Bedrock
• Google Cloud, contrôles de sécurité Vertex AI
• Google Cloud, zero data retention pour Vertex AI
• Microsoft, confidentialité des données Azure OpenAI et Foundry
• NIST, AI Risk Management Framework
• NIST, profil GenAI AI 600-1
• NIST, AI RMF Playbook
• NIST, Zero Trust Architecture SP 800-207
• NIST, sécurité et résilience de l'IA