Quand dire non à l'IA cloud : Un guide pour les RSSI

Un RSSI doit refuser un déploiement d'IA cloud lorsque les données traitées sont soumises à des exigences de souveraineté, lorsque l'exposition au CLOUD Act crée un risque réglementaire inacceptable, ou lorsque les obligations DORA ou NIS2 imposent une traçabilité et une résilience que l'architecture cloud ne peut pas garantir. La réponse n'est pas systématiquement "non" — elle dépend du niveau de sensibilité des données, du secteur et du modèle de déploiement choisi.

La pression pour adopter l'IA cloud est réelle. Les éditeurs l'emballent comme une modernisation inévitable, les équipes métier réclament des outils dont leurs homologues dans d'autres entreprises disposent déjà, et les directions générales demandent des calendriers de déploiement qui ne laissent pas de place à une revue de sécurité approfondie. Dans ce contexte, le RSSI qui pose des questions devient facilement le frein à l'innovation.

Ce guide est un outil de décision, pas un plaidoyer pour le refus systématique. L'IA cloud a des cas d'usage légitimes. Mais elle a aussi des limites structurelles qui créent des risques réels pour les organisations régulées — et ces risques méritent une analyse rigoureuse avant tout déploiement. La question n'est pas "IA cloud ou pas" mais "quelles données, dans quel cadre réglementaire, avec quel modèle d'architecture".

Le problème : une pression d'adoption sans analyse de risque

Les déploiements d'IA cloud en entreprise échouent rarement au moment du déploiement. Ils échouent six ou dix-huit mois plus tard, lorsqu'un incident de sécurité fournisseur, un audit réglementaire ou une mise en demeure RGPD révèle que des données sensibles ont transité par une infrastructure sur laquelle l'organisation n'avait aucun contrôle réel.

La mécanique du problème est prévisible. Un éditeur d'IA cloud propose une démonstration convaincante. L'équipe métier est séduite. Le projet est lancé en mode pilote, avec un périmètre "non critique" qui, en pratique, contient des données client, des informations contractuelles ou des données RH. Le pilote réussit. Le périmètre s'élargit. Le volume de données sensibles traitées en cloud croît — sans que la revue de sécurité initiale ait été étendue au nouveau périmètre.

Pour les RSSI, le problème structurel est que l'IA cloud crée trois expositions que les logiciels d'entreprise classiques ne créaient pas :

• Exposition au moment de l'inférence. Chaque requête envoyée à un modèle cloud transmet du contenu — la question elle-même, les documents récupérés, le contexte métier — vers une infrastructure que vous ne contrôlez pas. Ce n'est pas une hypothèse théorique : c'est le fonctionnement normal de l'API.
• Ambiguïté sur l'utilisation des données. Même avec des clauses contractuelles d'exclusion de l'entraînement, vous dépendez des contrôles internes du fournisseur pour les faire respecter. La vérification est impossible depuis votre côté.
• Piste d'audit incomplète. Les journaux d'inférence fournis par les éditeurs cloud ne reproduisent pas ce qui est nécessaire pour satisfaire DORA ou NIS2 : traçabilité complète, reproductibilité, isolation des incidents.

Le cadre réglementaire : DORA, NIS2 et souveraineté des données

Deux textes européens redéfinissent les obligations des organisations régulées en matière d'IA : le Digital Operational Resilience Act (DORA), applicable depuis janvier 2025 aux entités financières, et la directive NIS2, transposée en droit national pour les opérateurs d'importance essentielle et les entités importantes.

DORA impose aux entités financières (banques, assureurs, gestionnaires d'actifs, infrastructures de marché) une gestion des risques liés aux tiers technologiques qui va bien au-delà des clauses contractuelles habituelles. Les fournisseurs tiers critiques d'IA cloud doivent faire l'objet d'une évaluation de résilience, de tests de scénarios de défaillance et de contrats incluant des droits d'audit. Un déploiement d'IA cloud qui n'a pas fait l'objet de cette évaluation crée une non-conformité DORA — pas seulement un risque de sécurité.

NIS2 étend les obligations de cybersécurité à un périmètre élargi d'organisations dans des secteurs comme l'énergie, les transports, la santé, les infrastructures numériques et l'administration publique. Les exigences de gestion des risques de la chaîne d'approvisionnement NIS2 s'appliquent directement aux fournisseurs d'IA cloud : l'organisation est responsable des risques introduits par ses prestataires tiers, y compris les prestataires IA.

Le CLOUD Act américain ajoute une dimension supplémentaire : toute organisation dont le siège social est aux États-Unis peut être contrainte par les autorités américaines à divulguer des données hébergées sur n'importe quelle infrastructure qu'elle opère, y compris des datacenters européens. Cela signifie que "hébergé en France" ou "hébergé en Europe" n'est pas une garantie de souveraineté si le fournisseur est une entité américaine. Pour les organisations traitant des données soumises à des restrictions juridictionnelles — données de défense, données couvertes par le secret professionnel, informations commerciales sensibles — l'exposition au CLOUD Act n'est pas un risque théorique.

Les trois options : plein cloud, hybride, on-premise

Critère	IA cloud (SaaS/API)	Architecture hybride	On-premise / air-gap
Souveraineté des données	❌ Données chez le fournisseur pendant l'inférence	⚠️ Partielle — données sensibles isolées, reste en cloud	✅ Totale — aucune donnée ne quitte votre infrastructure
Exposition CLOUD Act	❌ Élevée si fournisseur américain	⚠️ Réduite selon architecture	✅ Nulle si infrastructure EU sans dépendance US
Conformité DORA (entités financières)	⚠️ Possible avec évaluation fournisseur complète	⚠️ Conditionnel — scope d'évaluation réduit	✅ Naturel — pas de tiers critique à évaluer
Conformité NIS2	⚠️ Risque chaîne d'approvisionnement à gérer	⚠️ Partiel	✅ Simplifié — périmètre interne uniquement
Piste d'audit complète	❌ Dépend des logs fournisseur	⚠️ Partielle	✅ Totale — tous les journaux dans votre infrastructure
Délai de déploiement	✅ Rapide (semaines)	⚠️ Moyen (mois)	⚠️ Plus long (matériel, intégration)
Coût initial	✅ Faible (abonnement)	⚠️ Moyen	❌ Élevé (investissement capital)
Coût total sur 3 ans	⚠️ Variable, peut dépasser on-premise à scale	⚠️ Intermédiaire	✅ Prévisible — coûts fixes après investissement
Risque violation fournisseur	❌ Significatif	⚠️ Réduit	✅ Nul — le fournisseur ne détient rien
Adapté aux données très sensibles	❌ Non recommandé	⚠️ Selon architecture	✅ Oui

La matrice de décision : par niveau de sensibilité des données

La décision d'architecture ne se prend pas au niveau de l'organisation entière, mais au niveau de chaque type de données traitées par le système IA. Voici le cadre de décision recommandé :

Données de niveau 1 — Très sensible (on-premise obligatoire)

Ce niveau inclut les données couvertes par un secret légal ou professionnel (secret défense, secret médical, secret des affaires au sens strict), les données personnelles dont la divulgation crée un risque élevé pour les personnes concernées, les informations classifiées ou à diffusion restreinte, et les données stratégiques dont l'exposition compromettrait un avantage concurrentiel critique.

Décision : on-premise uniquement. Aucun modèle cloud ne peut garantir la souveraineté nécessaire pour ce niveau. L'air-gap est la seule architecture qui offre une garantie architecturale, non contractuelle.

Données de niveau 2 — Sensible (hybride ou on-premise)

Ce niveau inclut les données contractuelles client, les données financières non publiques, les données RH, les communications internes sur des sujets stratégiques, et les données soumises à des obligations sectorielles (données bancaires, données d'assurance, données de santé non anonymisées).

Décision : hybride avec isolation stricte ou on-premise selon le volume et la criticité. Si l'architecture hybride est retenue, les données de ce niveau ne doivent jamais atteindre l'inférence cloud — seules les métadonnées ou les résumés non sensibles peuvent transiter.

Données de niveau 3 — Interne non critique (cloud possible avec conditions)

Ce niveau inclut la documentation opérationnelle générale, les FAQ internes, les politiques non confidentielles et les données de formation qui ne contiennent pas d'informations personnelles ou stratégiques.

Décision : cloud possible à condition que le fournisseur soit évalué selon les exigences DORA/NIS2 applicables, que les clauses contractuelles d'exclusion de l'entraînement soient explicites, et que le DPA soit signé et conforme au RGPD.

Données de niveau 4 — Publiques (cloud sans restriction particulière)

Informations déjà publiques, documentation produit externe, contenu marketing, données open source.

Décision : cloud sans contrainte de souveraineté (les autres contrôles de sécurité standard s'appliquent).

La checklist RSSI : 12 questions avant d'approuver un déploiement d'IA cloud

Avant de donner votre approbation à un déploiement d'IA cloud, obtenez des réponses écrites et précises à ces douze questions. Une réponse vague est informative : elle signale que le fournisseur n'a pas de réponse claire — ou qu'il préfère que vous ne la connaissiez pas.

1. Où l'inférence se produit-elle exactement ? Quel datacenter, quelle région, quel prestataire d'infrastructure ? La réponse "en Europe" n'est pas suffisante — demandez l'identité juridique de l'entité qui opère l'infrastructure d'inférence.
2. L'entité opératrice est-elle soumise au CLOUD Act ? Si le fournisseur ou sa société mère est une entité américaine, l'exposition au CLOUD Act s'applique quelle que soit la localisation des datacenters. Demandez une attestation juridique explicite.
3. Nos données sont-elles utilisées pour entraîner ou affiner des modèles ? Demandez la clause contractuelle précise, pas une assurance verbale. Vérifiez si l'exclusion couvre également le fine-tuning, pas seulement le pré-entraînement.
4. Nos embeddings sont-ils isolés des autres clients ? Les bases vectorielles partagées entre clients créent un risque de contamination sémantique. L'isolation par client doit être architecturale, pas seulement logique.
5. Quels journaux d'inférence sont conservés, par qui et pendant combien de temps ? Les journaux qui contiennent le contenu des requêtes sont des données à part entière. Leur durée de conservation, leur lieu de stockage et les conditions d'accès doivent être documentés.
6. Disposez-vous des droits d'audit contractuels sur le fournisseur ? DORA impose des droits d'audit sur les fournisseurs tiers critiques. Ces droits doivent être dans le contrat, pas simplement promis. Vérifiez que votre évaluation DORA du fournisseur peut être conduite.
7. Quel est le plan de continuité si le fournisseur est indisponible ? DORA exige des tests de résilience et des scénarios de défaillance fournisseur. Avez-vous un plan de repli documenté si l'API cloud devient indisponible ?
8. Que se passe-t-il à nos données si nous résilions le contrat ? Délai de suppression, mécanisme de suppression, extension aux embeddings et aux journaux. Demandez la confirmation que la suppression couvre tous les dérivés des données originales.
9. Le fournisseur a-t-il signé un DPA conforme au RGPD ? Le DPA doit couvrir explicitement l'inférence IA. Un DPA générique pour un logiciel SaaS ne couvre pas nécessairement le traitement de données pendant l'inférence de modèle.
10. Qui a accès à nos données en interne chez le fournisseur ? Équipes support, ingénieurs ML, équipes de sécurité ? Les accès doivent être journalisés et soumis à un contrôle interne. Demandez leur politique de contrôle d'accès interne.
11. Y a-t-il des sous-traitants impliqués dans l'inférence ? Certains éditeurs d'IA cloud délèguent l'inférence à des prestataires GPU cloud tiers, ajoutant un niveau d'exposition supplémentaire. Demandez la liste complète des sous-traitants.
12. Comment gérez-vous la notification en cas d'incident affectant nos données ? Délais, périmètre de la notification, obligations d'investigation. Les délais RGPD (72h) et NIS2 s'appliquent — le fournisseur doit pouvoir les respecter.

Quand dire oui — et dans quelles conditions

Ce guide ne recommande pas le refus systématique de l'IA cloud. Il recommande une décision informée. Voici les conditions dans lesquelles un déploiement d'IA cloud peut être approuvé dans un contexte régulé :

• Les données traitées sont de niveau 3 ou 4 (internes non critiques ou publiques)
• Le fournisseur a été évalué selon un cadre de risque tiers formalisé, conforme à DORA si applicable
• Le DPA est signé, explicite sur l'inférence IA, et couvre les sous-traitants
• Les clauses d'exclusion de l'entraînement sont contractuelles et vérifiables
• Un plan de continuité en cas de défaillance fournisseur est documenté et testé
• Les journaux d'audit nécessaires à la conformité réglementaire sont disponibles et accessibles

Lorsque ces conditions ne peuvent pas être remplies — ou que le périmètre de données inclut des informations de niveau 1 ou 2 — l'architecture hybride ou on-premise est la réponse correcte. Ce n'est pas un frein à l'innovation. C'est la définition de l'innovation responsable pour les organisations régulées.

FAQ : Questions fréquentes des RSSI

L'hébergement en France ou en Europe suffit-il à garantir la souveraineté ?

Non, pas systématiquement. La localisation du datacenter est un facteur nécessaire mais insuffisant. Si le fournisseur est une entité soumise au CLOUD Act américain, l'exposition juridictionnelle existe indépendamment de la localisation physique des données. La souveraineté réelle exige une infrastructure opérée par une entité juridiquement indépendante des juridictions extra-européennes pouvant contraindre la divulgation de données.

DORA s'applique-t-il à tous les déploiements d'IA cloud dans le secteur financier ?

DORA s'applique aux entités financières (banques, assureurs, sociétés de gestion, infrastructures de marché) et concerne les prestataires de services TIC tiers jugés critiques. La qualification de "critique" dépend de l'importance du service pour la continuité opérationnelle. Un système IA utilisé pour des fonctions centrales — traitement des demandes client, aide à la décision de crédit, gestion des connaissances réglementaires — est susceptible d'être qualifié de critique et d'entraîner les obligations d'évaluation et d'audit DORA.

Peut-on déployer une architecture hybride conforme à NIS2 ?

Oui, à condition que l'architecture hybride soit conçue avec une isolation stricte par niveau de sensibilité des données, que les risques de la chaîne d'approvisionnement liés aux composants cloud soient évalués et documentés, et que les mesures de sécurité techniques et organisationnelles exigées par NIS2 soient appliquées à l'ensemble de l'architecture. L'hybride n'est pas une position par défaut — c'est une position qui nécessite une ingénierie de sécurité rigoureuse.

L'on-premise implique-t-il forcément des coûts prohibitifs ?

Les déploiements on-premise ont un coût d'investissement initial plus élevé. Sur 3 à 5 ans, le coût total de possession peut être comparable ou inférieur au cloud, en excluant les coûts cachés du cloud dans les environnements régulés : revues juridiques DPA récurrentes, évaluations de risque tiers, coûts de mise en conformité post-incident. La comparaison honnête doit inclure tous ces éléments — pas seulement le prix du ticket d'abonnement.

Comment convaincre la direction générale de ralentir un projet IA cloud déjà lancé ?

Ne formulez pas le message comme un frein — formulez-le comme une protection de l'investissement. Un déploiement qui crée une non-conformité DORA ou un incident de données expose l'organisation à des sanctions réglementaires et à des coûts de remédiation significativement supérieurs au coût d'une revue de sécurité préalable. La question n'est pas "faut-il faire ce projet" mais "comment faire ce projet de manière à ce qu'il soit défendable dans 18 mois".

Conclusion : Le rôle du RSSI dans l'ère de l'IA

Le RSSI n'est pas l'obstacle à l'IA en entreprise. Il est la garantie que l'IA déployée aujourd'hui ne devient pas le risque réglementaire de demain. Dans un contexte où DORA, NIS2 et le RGPD imposent des obligations concrètes sur les architectures IA, refuser un déploiement mal conçu n'est pas de la prudence excessive — c'est de la gouvernance.

La décision de dire non à l'IA cloud n'est pas une position idéologique. C'est le résultat d'une analyse de risque appliquée à un périmètre de données spécifique, dans un cadre réglementaire donné, avec une architecture proposée. Utilisez la matrice de décision de cet article pour structurer cette analyse — et pour la documenter de manière à ce qu'elle soit défendable face à un auditeur ou un régulateur.