Données et cloud : le dossier pour une architecture maîtrisée

Où sont vos données ? Qui peut y accéder, y compris sans vous le demander ? Combien de temps vous faudrait-il pour les reprendre et les installer ailleurs ? Peu de directions savent répondre précisément à ces trois questions, alors que l’essentiel de leurs systèmes repose désormais, en tout ou partie, sur des services hébergés par d’autres. Le couple données et cloud n’est pas un sujet d’infrastructure réservé à la DSI : c’est une question de maîtrise, qui engage la direction générale, le juridique et les métiers.

Ce dossier reprend les choix d’architecture dans l’ordre où ils devraient être pris. Il ne recommande pas de fournisseur et ne plaide ni pour ni contre le cloud. Il donne une méthode pour décider en connaissance de cause, et pour pouvoir changer d’avis plus tard.

Pourquoi l’architecture précède le choix du fournisseur

Beaucoup de migrations vers le cloud commencent par un appel d’offres ou par l’adhésion à l’offre d’un éditeur déjà présent. L’architecture se dessine ensuite, au fil des projets, chaque équipe choisissant les services les plus pratiques pour son besoin du moment. Quelques années plus tard, l’organisation découvre qu’elle dépend de services propriétaires impossibles à remplacer, que ses données sensibles sont dispersées dans des comptes que personne ne recense, et que sa facture a doublé sans que personne ne l’ait décidé.

L’inverse est plus sûr : décider d’abord de quelques principes (quelles données vont où, qui détient les clés, comment on sort), puis choisir les fournisseurs qui permettent de les respecter. Ces principes tiennent en une page. Ils évitent des années de rattrapage.

Classer avant de placer

Toutes les données n’appellent pas la même protection. Une classification simple, en quatre niveaux, suffit à la plupart des organisations. L’important n’est pas la finesse de la grille, mais qu’elle soit appliquée et que chaque jeu de données ait un responsable identifié.

La classification révèle presque toujours deux surprises. D’abord, une part importante des données sensibles se trouve là où personne ne l’attendait : dans des exports bureautiques, des boîtes de messagerie, des espaces de partage ouverts à tous. Ensuite, beaucoup de données classées « critiques » par prudence ne le sont pas, ce qui complique inutilement leur usage. La grille sert autant à protéger qu’à libérer.

Les modèles de déploiement et le partage des responsabilités

On distingue classiquement l’infrastructure fournie à la demande (IaaS), la plateforme sur laquelle on déploie ses applications (PaaS) et le logiciel prêt à l’emploi (SaaS). Plus on monte dans cette pile, moins on a de choses à gérer, et moins on a de leviers. Le principe de responsabilité partagée, que tous les grands fournisseurs décrivent, en découle : le fournisseur répond de la sécurité de ce qu’il exploite, le client de ce qu’il configure et de ce qu’il y dépose.

Dans la pratique, la plupart des incidents de sécurité liés au cloud ne viennent pas d’une défaillance du fournisseur, mais d’une erreur de configuration côté client : un espace de stockage laissé public, des droits trop larges, une clé d’accès publiée par erreur dans un dépôt de code. La maîtrise commence donc par la configuration, qui relève de l’organisation et non de son fournisseur.

Quant aux modèles d’hébergement, ils se combinent plus qu’ils ne s’opposent. L’infrastructure privée, dans ses propres salles ou chez un hébergeur, garde tout le contrôle et toutes les charges. Le cloud public apporte l’élasticité et un catalogue de services très large. Les offres de confiance, ou qualifiées, ajoutent des garanties juridiques et techniques pour les données sensibles. L’architecture hybride, de loin la plus fréquente, place chaque classe de données là où ses exigences sont respectées au meilleur coût.

L’identité, nouveau périmètre de sécurité

Dans un centre de données privé, la sécurité reposait largement sur le réseau : ce qui était à l’intérieur était réputé sûr. Dans le cloud, chaque service est accessible par Internet, et c’est l’identité de celui qui se connecte (une personne, une application, un automate) qui détermine ce qu’il peut faire. La gestion des identités et des accès devient le premier rempart.

Quatre pratiques font l’essentiel du travail. L’authentification forte, obligatoire pour tous les comptes et sans exception pour les comptes d’administration. Le moindre privilège : chaque compte ne reçoit que les droits nécessaires à sa tâche, et les droits d’administration sont accordés pour une durée limitée, à la demande, plutôt que de façon permanente. La séparation des environnements : production, recette et développement dans des comptes ou des projets distincts, pour qu’une erreur ou une compromission dans l’un n’atteigne pas l’autre. La journalisation centralisée enfin, conservée hors de portée des administrateurs eux-mêmes, pour pouvoir reconstituer après coup qui a fait quoi.

Les identités techniques méritent une attention particulière. Les clés d’accès utilisées par les applications et les scripts sont nombreuses, rarement renouvelées et souvent dotées de droits excessifs. Un inventaire de ces secrets, leur stockage dans un coffre dédié et leur rotation régulière réduisent un risque que les audits révèlent presque systématiquement.

Hybride et multi-cloud : choisir sa complexité

L’architecture hybride, qui combine infrastructure privée et cloud, est devenue la norme de fait. Le multi-cloud, qui répartit les services entre plusieurs fournisseurs, est plus discuté. Il est souvent présenté comme une protection contre la dépendance. En pratique, il la déplace : chaque fournisseur a ses propres outils, ses propres modèles de droits et ses propres services, que les équipes doivent maîtriser en parallèle. Les compétences se dispersent et la surface d’erreur de configuration s’élargit.

Le multi-cloud se justifie quand il répond à un besoin précis : un service introuvable ailleurs, une exigence réglementaire de diversification, une stratégie de sortie crédible pour une application critique. Il se justifie mal comme principe général. Une organisation de taille moyenne gagne souvent à maîtriser un fournisseur principal, complété par une offre de confiance pour ses données les plus sensibles, plutôt qu’à se disperser.

Souveraineté : ce que dit le droit, ce que fait la technique

Le mot « souveraineté » recouvre trois questions distinctes, qu’il vaut mieux séparer.

Quel droit s’applique aux données ? Pour les données personnelles, le RGPD encadre les transferts hors de l’Union. Après l’annulation du Privacy Shield par la Cour de justice de l’Union européenne en juillet 2020 (arrêt dit Schrems II), la Commission a adopté en juillet 2023 une nouvelle décision d’adéquation pour les États-Unis, le cadre de protection des données UE–États-Unis. Ce cadre est contesté et pourrait à son tour être remis en cause : une architecture robuste ne devrait pas reposer sur sa seule existence.

Qui peut être contraint de livrer les données ? Certaines lois ont une portée extraterritoriale. Le CLOUD Act américain de 2018 permet aux autorités des États-Unis d’exiger d’un fournisseur soumis à leur juridiction les données qu’il contrôle, y compris lorsqu’elles sont stockées hors du territoire américain. Héberger en Europe ne suffit donc pas, à lui seul, à écarter ce risque.

Quelles garanties sont vérifiées ? Des référentiels permettent d’objectiver les engagements d’un fournisseur. En France, la qualification SecNumCloud de l’ANSSI combine des exigences techniques et des exigences d’immunité aux droits extra-européens. À l’échelle européenne, un schéma de certification des services cloud, préparé sous l’égide de l’ENISA, fait encore débat sur la place à donner aux critères de souveraineté. Les normes ISO/IEC 27001, 27017 et 27018 attestent d’un système de management et de mesures propres au cloud, sans traiter la question juridique.

Chiffrement et clés : là où se joue le contrôle

Le chiffrement est devenu la norme : en transit, entre l’utilisateur et le service, et au repos, sur les disques du fournisseur. La vraie question est celle des clés. Trois configurations se rencontrent.

Dans la première, le fournisseur génère et gère les clés : c’est simple, mais il peut techniquement déchiffrer les données. Dans la deuxième, l’organisation fournit ses propres clés au service de gestion du fournisseur (on parle de BYOK, « apportez votre clé ») : elle garde la maîtrise de leur cycle de vie et peut les révoquer. Dans la troisième, les clés restent hors du fournisseur, dans un module matériel de sécurité que l’organisation contrôle (on parle de HYOK ou de gestion externe des clés) : le fournisseur ne voit jamais les données en clair au repos, au prix d’une complexité et d’une dépendance accrues envers ce module.

Le bon niveau dépend de la classe des données. Pour une donnée interne, les clés du fournisseur suffisent généralement. Pour une donnée sensible ou réglementée, la maîtrise des clés par l’organisation devient le cœur du dispositif. Les techniques de calcul confidentiel, qui protègent les données pendant leur traitement grâce à des enclaves matérielles, complètent ce tableau mais restent réservées à des usages précis.

Réversibilité : préparer la sortie dès l’entrée

La réversibilité est la capacité à quitter un fournisseur, pour un autre ou pour sa propre infrastructure, sans perdre de données ni interrompre durablement le service. Elle se joue sur trois plans.

Le plan contractuel d’abord : formats et délais de restitution, assistance à la sortie, coûts. Le règlement européen sur les données (Data Act), entré en vigueur en janvier 2024 et applicable à partir de septembre 2025, impose aux fournisseurs de services de traitement de données des obligations pour faciliter le changement de fournisseur, et prévoit la suppression progressive des frais de changement d’ici 2027.

Le plan technique ensuite : plus une application s’appuie sur des services propres à un fournisseur (bases de données propriétaires, fonctions sans serveur, outils d’analyse intégrés), plus sa migration sera coûteuse. Il ne s’agit pas de s’interdire ces services, mais de savoir lesquels on utilise et ce que coûterait leur remplacement. Décrire l’infrastructure sous forme de code, conteneuriser les applications et privilégier des formats ouverts réduit fortement cette dépendance.

Le plan organisationnel enfin : un plan de sortie qui n’a jamais été testé est une hypothèse. Restaurer une fois par an un service représentatif dans un autre environnement est l’exercice le plus révélateur qui soit.

La réversibilité ne se négocie pas le jour où l’on veut partir ; elle se construit le jour où l’on arrive.

Continuité : ne pas confondre disponibilité et sauvegarde

Un service réparti sur plusieurs zones de disponibilité résiste à la panne d’un centre de données. Il ne résiste pas à une suppression accidentelle, à un rançongiciel qui chiffre les données de toutes les zones à la fois, ni à la compromission du compte d’administration. La disponibilité et la sauvegarde répondent à des risques différents.

La règle dite 3-2-1 reste une bonne base : trois copies des données, sur deux supports différents, dont une hors site. Dans le cloud, on y ajoute deux exigences : au moins une copie immuable, qui ne peut être ni modifiée ni supprimée pendant une durée fixée, et une copie hors du compte, voire hors du fournisseur principal, pour les données dont la perte serait irréparable. Pour chaque service, la perte de données acceptable et la durée d’interruption tolérable doivent être fixées par les métiers, pas déduites de ce que la technique propose par défaut.

Gouvernance : savoir qui a décidé quoi

Une architecture maîtrisée est une architecture documentée. Quatre registres suffisent à la piloter : le registre des données (quelles données, quelle classe, quel responsable, où), le registre des services cloud utilisés (avec leur fournisseur, leur contrat et leur niveau de dépendance), le registre des accès privilégiés, et le registre des décisions d’architecture, qui conserve la justification de chaque choix structurant.

Ce dernier est le plus souvent absent. C’est pourtant lui qui permet, des années plus tard, de comprendre pourquoi une donnée sensible se trouve dans tel service, qui l’a validé, et sur quelle base. C’est aussi lui qui répond aux auditeurs et aux régulateurs. Notre produit Gouvernance part de ce besoin : tracer les décisions et leurs fondements, pour pouvoir les expliquer et les réviser.

La gouvernance couvre aussi la dépense. Dans le cloud, chaque équipe peut engager des coûts en quelques clics. Sans étiquetage des ressources, sans budgets par service et sans revue régulière, la facture devient illisible. La discipline FinOps, qui réunit finance, technique et métiers autour de la dépense cloud, apporte une méthode pour y remédier.

Ce que changent les textes européens

Trois textes font entrer l’architecture cloud dans le champ de la conformité. Le règlement DORA, applicable au secteur financier à partir du 17 janvier 2025, impose de tenir un registre des contrats de services informatiques fournis par des tiers, d’évaluer la concentration du risque sur un même fournisseur et de disposer de stratégies de sortie. La directive NIS 2, que les États membres devaient transposer au plus tard le 17 octobre 2024, demande aux entités concernées de maîtriser la sécurité de leur chaîne d’approvisionnement, fournisseurs cloud compris. Le Data Act, enfin, organise la portabilité et le changement de fournisseur.

Hors d’Europe, la tendance est comparable. De nombreux pays se sont dotés de lois de protection des données inspirées du RGPD, et plusieurs imposent la localisation sur le territoire national de certaines catégories de données, publiques ou personnelles. Pour une organisation présente dans plusieurs pays, l’architecture doit donc pouvoir accueillir des exigences différentes selon les juridictions, sans multiplier les systèmes.

Pour une organisation qui aura appliqué la méthode de ce dossier, ces obligations ne créent presque rien de nouveau : elles demandent de prouver ce qu’une architecture maîtrisée fait déjà.

Une feuille de route en six étapes

1. InventorierRecenser les services cloud réellement utilisés, y compris ceux souscrits directement par les métiers, et les données qu’ils contiennent.
2. ClasserAppliquer une grille simple aux principaux jeux de données et nommer un responsable pour chacun.
3. Écrire les principesUne page validée par la direction : quelles classes vont où, qui détient les clés, quel niveau de réversibilité pour chaque type de service.
4. Corriger les écarts prioritairesDonnées sensibles mal placées, accès trop larges, absence de sauvegarde immuable : traiter d’abord ce qui expose le plus.
5. Préparer la sortieRédiger un plan de réversibilité pour les services critiques et le tester sur un périmètre représentatif.
6. Gouverner dans la duréeTenir les registres, revoir les coûts et les dépendances chaque trimestre, documenter chaque nouvelle décision d’architecture.

Ces étapes ne demandent pas de grand programme. Elles demandent que quelqu’un les conduise jusqu’au bout, au plus près des équipes qui exploitent les systèmes. C’est le principe de nos équipes déployées : des ingénieurs qui travaillent dans vos opérations jusqu’à ce que vos équipes tiennent seules la feuille de route.

Questions fréquentes

Le cloud public est-il compatible avec des données sensibles ?

Il peut l'être, selon la nature des données, le droit applicable et les mesures retenues : chiffrement avec des clés maîtrisées par l'organisation, offre qualifiée lorsque la réglementation l'exige, contrôle des accès et journalisation. Certaines données, par la loi ou par choix, resteront dans une infrastructure privée.

Héberger en Europe suffit-il à protéger des lois étrangères ?

Pas toujours. Un fournisseur soumis à une loi extraterritoriale peut être contraint de communiquer des données qu'il héberge, où qu'elles soient. La localisation compte, mais le statut juridique du fournisseur et le contrôle des clés de chiffrement comptent autant.

Qu'est-ce qu'un plan de réversibilité ?

Un document, tenu à jour, qui décrit comment récupérer les données et reconstruire les services ailleurs : formats d'export, outils, délais, coûts, responsabilités. Il n'a de valeur que s'il a été testé, au moins partiellement, sur un périmètre réel.

Faut-il éviter le multi-cloud ?

Pas par principe, mais il ne faut pas le choisir par réflexe. Utiliser plusieurs fournisseurs multiplie les compétences, les outils et les surfaces d'attaque. Il se justifie lorsqu'un besoin précis le demande : réversibilité, exigence réglementaire, service introuvable ailleurs.