Un service cloud peut traiter des données personnelles dans des conditions conformes au RGPD, mais le nom du fournisseur, une région européenne ou un certificat ne suffisent pas à le démontrer. Il faut examiner le service réellement souscrit, les opérations effectuées, les responsabilités de chaque acteur et les garanties effectivement mises en œuvre. Cette analyse concerne aussi bien une infrastructure AWS, Azure ou Google Cloud qu’un logiciel fourni par un éditeur spécialisé.
L’objectif de ce guide est de préparer cette analyse avant une migration, puis de la maintenir pendant la prestation. Il distingue le contrat de sous-traitance, la sécurité technique, les transferts internationaux et les exigences françaises propres à certaines données. Il ne constitue pas une attestation de conformité des offres citées : leurs documents contractuels, options et périmètres doivent être vérifiés pour le projet concerné.
Décrire le service avant de qualifier le fournisseur
Commencez par les usages : stockage de dossiers, base de données, messagerie, application métier, sauvegarde ou analyse. Identifiez les personnes concernées, les données nécessaires, les accès administrateurs et les interfaces avec d’autres systèmes. Une même organisation peut utiliser plusieurs services du même fournisseur, avec des configurations et des conditions différentes.
Les catégories IaaS, PaaS et SaaS aident à comprendre la répartition des tâches techniques, mais elles ne déterminent pas automatiquement le rôle juridique de chaque partie. Un fournisseur qui stocke des données pour le compte du client intervient généralement comme sous-traitant pour cette opération. Il peut toutefois réaliser d’autres traitements pour ses propres finalités, ou participer à une détermination conjointe de certaines opérations.
La CNIL a publié le 28 mai 2026 une analyse des qualifications dans le cloud. Elle distingue la fourniture du service, son amélioration et la sécurité. Cette méthode évite de qualifier globalement tout un fournisseur à partir d’une seule phrase de son contrat. La distinction entre responsable de traitement et sous-traitant doit être appliquée aux opérations effectivement réalisées.
Examiner séparément amélioration, télémétrie et sécurité
L’amélioration d’un service peut répondre à des situations différentes. Si le client demande une analyse précise pour optimiser sa propre application et en fixe les objectifs, le fournisseur peut agir pour son compte. Si le fournisseur analyse les usages de nombreux clients pour définir sa propre évolution commerciale, il faut examiner sa responsabilité propre pour ce traitement. Une finalité présentée comme utile aux deux parties ne suffit pas, à elle seule, à établir une responsabilité conjointe.
Les journaux et données de télémétrie ne relèvent donc pas tous automatiquement du fournisseur comme responsable de traitement. Demandez quelles informations sont produites, pourquoi, pendant combien de temps et qui peut les utiliser. Un journal destiné à contrôler les accès aux dossiers du client se distingue d’une analyse globale d’attaques visant l’infrastructure du fournisseur.
La CNIL sépare ainsi la sécurité « du » nuage, portant sur le service et son infrastructure, de la sécurité « dans » le nuage, portant sur les traitements du client. Cette distinction aide à répartir les tâches sans décharger l’une des parties de ses obligations. Un contrôle des accès bien configuré chez le client ne corrige pas nécessairement une vulnérabilité du serveur, et la sécurité de l’infrastructure ne répare pas une base rendue publique par erreur.
Vérifier l’encadrement de l’article 28
Lorsque le fournisseur agit comme sous-traitant, l’article 28 du RGPD exige un contrat ou un autre acte juridique contraignant prévu par le droit de l’Union ou d’un État membre, sous forme écrite, y compris électronique. Dans une relation commerciale ordinaire, cet encadrement figure généralement dans un accord de traitement des données, souvent appelé DPA, accompagné d’annexes.
L’accord doit décrire l’objet, la durée, la nature et la finalité du traitement, les catégories de personnes et de données, ainsi que les droits et obligations du responsable. Une annexe limitée à « toutes données du client, pour tous services » peut ne pas permettre de comprendre le périmètre convenu. Reliez les annexes à la liste des services, aux configurations et aux flux du projet.
Le traitement s’effectue sur instruction documentée, y compris pour les transferts, sauf obligation imposée au sous-traitant par le droit de l’Union ou d’un État membre auquel il est soumis. Dans ce cas, il doit informer le responsable de cette obligation avant le traitement, sauf interdiction pour des motifs importants d’intérêt public. Le contrat doit également encadrer confidentialité, sécurité, assistance, recours à d’autres sous-traitants et contrôles.
Ne validez pas une offre en cochant une ligne « DPA disponible ». Lisez les documents applicables à la date de signature et leur ordre de priorité. Examinez les clauses qui permettent de modifier les conditions, les exclusions, les prestations facturées séparément et les informations nécessaires pour exercer les droits convenus. La checklist d’audit de l’article 28 peut structurer cette lecture.
Suivre la chaîne de sous-traitance
Le recours à un autre sous-traitant suppose une autorisation écrite préalable, spécifique ou générale, du responsable. En cas d’autorisation générale, le sous-traitant informe des changements envisagés afin de permettre une objection. Le RGPD ne fixe pas un préavis universel de six mois : vérifiez le délai contractuel, son point de départ et la manière dont l’information atteint réellement votre organisation.
Le sous-traitant ultérieur doit être soumis aux mêmes obligations de protection des données dans les conditions de l’article 28, paragraphe 4. Le premier sous-traitant demeure pleinement responsable envers le responsable de traitement de l’exécution de ces obligations par l’autre sous-traitant. Une liste publique de prestataires ne remplace pas cette organisation contractuelle.
Attribuez la surveillance des changements à une personne ou une équipe. Une objection n’est utile que si son motif peut être évalué et si les conséquences sont comprises : maintien de la prestation, solution alternative ou sortie. Identifiez notamment les prestataires de support, de sauvegarde et d’exploitation qui peuvent accéder aux données, plutôt que de limiter l’analyse à l’hébergeur le plus visible.
Demander des preuves de sécurité adaptées au projet
L’article 32 impose au responsable et au sous-traitant des mesures adaptées au risque. La fiche CNIL sur la sécurité de la sous-traitance recommande d’examiner les garanties du prestataire et les moyens de vérifier leur effectivité. Un engagement commercial général doit être traduit en éléments contrôlables : habilitations, authentification, journalisation, sauvegardes, restauration et traitement des vulnérabilités.
Pour une application de gestion des salariés, vérifiez par exemple qui peut ouvrir un dossier, exporter plusieurs dossiers ou modifier les permissions. Distinguez les comptes ordinaires des comptes d’administration et des accès du support. Vérifiez aussi ce qui est activé par défaut et ce qui dépend d’une option, d’une licence ou d’une action du client.
La disponibilité fait partie de l’analyse. Une copie de sauvegarde ne démontre pas que l’organisation peut retrouver des données utilisables après une erreur ou une attaque. Demandez comment les restaurations sont vérifiées, quels délais sont contractualisés et quelles dépendances pourraient empêcher la reprise. Les besoins doivent découler de l’activité et des conséquences d’une indisponibilité, plutôt que d’un objectif identique imposé à tous les projets.
Distinguer chiffrement et maîtrise effective des clés
Le guide CNIL sur le chiffrement dans le cloud public distingue les données au repos, en transit et en cours de traitement. Un chiffrement efficace contre le vol d’un disque ne protège pas nécessairement contre un administrateur autorisé à déchiffrer les informations. Il faut préciser la menace visée et l’endroit où les données deviennent accessibles en clair.
Les expressions « clés gérées par le client », BYOK ou HYOK ne démontrent pas, isolément, que le fournisseur ne peut jamais accéder au contenu. Examinez qui génère les clés, les conserve, peut les utiliser, modifier les autorisations ou déclencher un déchiffrement. Un service qui reçoit la clé pour traiter les informations n’est pas équivalent à un stockage de données chiffrées avant leur envoi, sans accès du fournisseur aux clés.
Le chiffrement applicatif côté client peut empêcher l’accès au contenu dans une architecture où les clés et leur usage restent effectivement maîtrisés en dehors du fournisseur. Cette organisation peut limiter les recherches, les traitements et les fonctions collaboratives côté serveur. Elle ne protège pas automatiquement toutes les métadonnées. Vérifiez également les copies temporaires, les journaux et les procédures de récupération.
Documentez ces choix avec les équipes techniques. Le guide sur le chiffrement des données personnelles permet d’approfondir cette question. Une mesure ne doit être présentée comme empêchant un accès que si l’architecture, les droits et les procédures permettent réellement de soutenir cette conclusion.
Vérifier la localisation au-delà de la région sélectionnée
Une région choisie dans une console décrit une partie de la prestation. Elle ne garantit pas à elle seule la localisation de toutes les données, sauvegardes, métadonnées, opérations de support et services associés. Demandez les engagements applicables au service précis, leurs exceptions et la configuration nécessaire pour les respecter.
Distinguez l’Union européenne, l’Espace économique européen et les autres pays européens. La Suisse, par exemple, ne devient pas un État membre parce qu’une offre utilise le mot « Europe ». Pour l’analyse juridique, identifiez les pays concernés et les entités destinataires, puis examinez les mécanismes applicables au flux.
Un accès distant par un destinataire distinct situé dans un pays tiers peut constituer un transfert même si le serveur reste en France. À l’inverse, le seul déplacement d’un salarié accédant aux données de son propre employeur ne constitue pas automatiquement un transfert à une autre entité. Il conserve néanmoins des implications de sécurité à évaluer. Cette distinction évite de déduire les obligations uniquement de la position du serveur ou de l’utilisateur.
Choisir le mécanisme de transfert correspondant au destinataire
La liste actuelle des décisions d’adéquation de la Commission européenne comprend les organismes commerciaux américains participant au cadre UE–États-Unis de protection des données, ou DPF. Il faut vérifier l’entité effectivement destinataire et la couverture applicable. La marque d’un groupe ne démontre pas que chaque filiale ou chaque traitement bénéficie de cette voie.
Lorsqu’une décision d’adéquation couvre le transfert, des garanties de l’article 46 ne sont pas nécessaires comme fondement de ce transfert. Les autres obligations du RGPD restent applicables, notamment la sécurité. Lorsqu’on utilise des clauses contractuelles types, il faut examiner les conditions du mécanisme, les lois et pratiques pertinentes ainsi que les mesures supplémentaires nécessaires pour le flux concerné.
Les principes des transferts internationaux de données doivent ainsi être appliqués au destinataire réel et à la situation actuelle. Il n’est pas exact d’affirmer que tout fournisseur américain est couvert par le DPF, ni qu’un jeu de clauses signé suffit toujours. Si les garanties nécessaires ne peuvent pas être assurées pour le mécanisme retenu, le transfert ne doit pas commencer ou doit être suspendu selon les règles applicables.
Conservez la preuve des vérifications et organisez leur mise à jour. Un changement de sous-traitant, d’accès aux clés, de finalité ou de pays peut remettre en cause l’analyse. Un plan de sortie utile repose sur les capacités de restitution et de remplacement ; il ne nécessite pas de spéculer sur l’issue future d’un recours judiciaire.
Lire les certificats et rapports dans leur périmètre
Une certification ISO 27001 renseigne sur un système de management de la sécurité de l’information dans un périmètre défini. Une référence à ISO 27701 concerne le management de la protection de la vie privée : vérifiez l’édition, le périmètre et le document effectivement délivré. Aucun de ces intitulés n’établit que toutes les offres d’un groupe satisfont automatiquement à l’ensemble du RGPD.
Un rapport SOC 2 fournit une assurance sur les contrôles couverts, selon son type et sa période. Demandez le rapport pertinent, ses exclusions, les éventuelles réserves et les contrôles complémentaires attendus du client. Un document ancien ou limité à une autre composante ne démontre pas la sécurité du service utilisé.
L’article 28, paragraphe 3, point h), oblige le sous-traitant à mettre à disposition les informations nécessaires et à permettre les audits, y compris les inspections, en y contribuant. Des rapports indépendants peuvent participer à cette vérification, mais ne doivent pas vider ce droit de sa substance. Convenez de modalités adaptées, de la protection des autres clients et du traitement des constats, en particulier lorsqu’une preuve fournie ne répond pas à un risque identifié.
Comprendre les limites de SecNumCloud et de HDS
La FAQ officielle de l’ANSSI sur SecNumCloud précise que la qualification vise une offre particulière. Un fournisseur peut proposer des services qualifiés et d’autres qui ne le sont pas. Une application hébergée sur un socle qualifié n’hérite pas automatiquement de cette qualification ; une qualification par composition suppose sa propre démarche.
SecNumCloud apporte des garanties techniques, organisationnelles et juridiques, notamment face à certaines menaces liées à des lois extraterritoriales. Il ne dispense pas le client de maîtriser les risques de son application. Vérifiez l’offre exacte dans la décision et son périmètre, plutôt que d’assimiler une démarche en cours à une qualification obtenue. Le guide de la qualification SecNumCloud aide à situer ce contrôle.
Pour la santé, l’article L.1111-8 du code de la santé publique définit un champ précis : données personnelles de santé recueillies lors d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, hébergées pour les personnes à l’origine de leur production ou recueil, ou pour le patient. Sur support numérique, l’hébergeur concerné doit disposer du certificat requis. Ce n’est pas une règle visant indistinctement toute donnée évoquant la santé dans toute entreprise.
Vérifiez les activités couvertes par le certificat, les services souscrits et la version applicable du référentiel. La certification HDS et SecNumCloud répondent à des cadres distincts : la première ne rend pas automatiquement la seconde obligatoire, et aucune ne constitue une autorisation générale d’héberger des informations classifiées. Les exigences sectorielles ou contractuelles supplémentaires doivent être identifiées séparément.
Préparer les incidents, les droits et la fin du service
Le sous-traitant doit notifier au responsable toute violation de données personnelles sans délai indu après en avoir pris connaissance. Il faut organiser les contacts, informations disponibles et mises à jour, sans attendre que l’enquête technique soit achevée. Le responsable évalue séparément la notification à l’autorité : sans délai indu et, si possible, sous 72 heures après connaissance, sauf risque improbable pour les droits et libertés ; un retard doit être motivé. Toutes les violations sont documentées et l’information des personnes relève d’une analyse distincte du risque élevé.
Pour les droits, précisez comment le fournisseur aide le responsable, compte tenu de la nature du traitement, par des mesures appropriées dans la mesure du possible. L’assistance relative à la sécurité et aux articles 32 à 36 tient également compte des informations dont il dispose. Vérifiez les possibilités de recherche, d’export, de rectification et d’effacement sans supposer qu’une interface d’administration répond à toutes les demandes.
À la fin de la prestation, l’article 28 prévoit, au choix du responsable, restitution ou suppression des données et destruction des copies existantes, sauf conservation requise par le droit de l’Union ou d’un État membre. Définissez le format de restitution, les délais, les vérifications et le sort des sauvegardes. Les règles sectorielles, notamment celles de l’hébergement de santé, doivent aussi être respectées. Faites un essai d’export avant que l’urgence d’une résiliation ne rende la sortie difficile.
Conserver un dossier de décision exploitable
Reliez le service aux activités concernées dans le registre des traitements, puis conservez les documents utiles : qualification des rôles, contrat, pays et accès, mesures techniques, certificats, analyse des transferts et décisions sur les limites résiduelles. Le registre décrit des activités ; il ne suffit pas d’y ajouter une ligne portant le nom commercial du fournisseur.
Pour une entité financière concernée, examinez également les règles sur les prestataires TIC tiers et DORA. La qualification de sous-traitant au sens du RGPD ne résout pas les autres obligations sectorielles. Désignez enfin un responsable des révisions : le dossier doit évoluer avec le service, les accès et les engagements contractuels pour rester utilisable lors d’un incident, d’un contrôle ou d’une migration.