Par Olivia Dubois
·
20 juin 2026
Si je devais résumer l’article en une idée : un audit RGPD SaaS tient sur 5 vérifications simples, mais beaucoup d’équipes en ratent une ou deux. Et c’est là que le risque commence, surtout quand les données restent dans les sauvegardes, les journaux, les exports ou des outils reliés entre eux.
Concrètement, je dois vérifier :
Quelques repères à garder en tête :
Ce que je retiens surtout : une durée de conservation écrite ne suffit pas. Il faut un réglage dans l’outil, une clause dans le DPA, un process pour les demandes d’effacement, et une preuve datée de ce qui a été supprimé.
Avant d’entrer dans le détail, voici la logique de lecture de cette checklist : inventorier, localiser, fixer les durées, vérifier les contrats, puis tester l’effacement de bout en bout.
Cette étape relie chaque application SaaS au registre des traitements et à ses lieux de stockage. Pour faire un audit RGPD sérieux, il faut partir d’un inventaire SaaS complet et structuré.
Pour chaque outil, documentez la finalité, les catégories de données, y compris les données sensibles au sens de l’article 9, les destinataires, le rôle du prestataire comme sous-traitant au titre de l’article 28, ses sous-traitants ultérieurs si besoin, la durée de conservation prévue et le responsable métier interne. Attribuez aussi un propriétaire par application.
Le périmètre doit couvrir, au minimum :
Un audit mené pour une chaîne de cliniques privées a montré à quel point ce travail change la donne : une liste de départ de 47 traitements est passée à 136 après la découverte de systèmes non répertoriés, dont la vidéosurveillance des parkings, les données biométriques de prestataires de restauration et la géolocalisation d’ambulances sous-traitées [1].
Une fois chaque SaaS rattaché au registre, passez à un point très concret : où les données se trouvent en pratique, et comment elles circulent hors EEE.
Pour chaque application, localisez avec précision où les données sont stockées : en France, dans l’Union européenne ou dans un pays tiers. Il faut vérifier la localisation réelle dans la configuration de l’outil, et pas seulement se fier à ce qui est écrit dans le contrat [1].
Pour chaque transfert hors EEE, documentez le mécanisme juridique retenu : clauses contractuelles types (CCT, version 2021), certification Data Privacy Framework pour les prestataires américains, ou décision d’adéquation. Pour les pays sans décision d’adéquation, une analyse d’impact des transferts (TIA) doit être réalisée et datée [1].
Pensez aussi aux flux de données moins visibles. La télémétrie, les mises à jour automatiques ou la création forcée de comptes peuvent envoyer des données vers le pays d’origine de l’éditeur sans que cela saute aux yeux [5]. C’est souvent là que les ennuis commencent.
Pour chaque transfert, archivez la preuve juridique correspondante.
| Type de preuve | Objet | Point clé |
|---|---|---|
| DPA (article 28) | Sécurité contractuelle | Définit les rôles et la chaîne de sous-traitance [1] |
| CCT (version 2021) | Base juridique du transfert | À utiliser pour les transferts vers des pays sans décision d’adéquation [1] |
| TIA | Analyse de risque | Évalue les lois locales pouvant contraindre à divulguer des données [1] |
| Certification DPF | Transferts UE–États-Unis | Vérification active sur le site du Département du Commerce américain [1] |
Après la localisation, vérifiez que les durées de conservation et les paramètres de suppression suivent bien la politique écrite.
Un inventaire manuel laisse souvent des angles morts. La découverte continue aide à réduire ce risque.
Avanoo centralise la découverte SaaS, y compris les outils non référencés liés au Shadow IT, afin d’alimenter le registre des traitements et la cartographie des données.
Dans l’audit, passez SaaS par SaaS. Le but est simple : vérifier que chaque durée de conservation est écrite, appliquée et traçable.
Associez chaque catégorie de données à une durée écrite, liée à une finalité et à une base juridique. Quand aucun texte ne prévoit de délai précis, consignez une durée proportionnée à l’objectif visé.
| Catégorie de données | Durée de conservation | Base / finalité |
|---|---|---|
| Factures et données comptables | 10 ans | Obligation légale (Code de commerce / Code fiscal) |
| Données RH | Durée du contrat + 5 ans | Prescription légale pour litiges prud'homaux |
| Candidats non retenus | 2 ans | Délai de contestation d'un refus de recrutement |
| Prospects commerciaux | 3 ans après le dernier contact actif | Intérêt légitime / recommandation CNIL |
| Données clients | 5 ans après la dernière commande | Prescription commerciale |
| Journaux techniques et journaux de sécurité | 6 mois | Surveillance sécurité et réponse aux incidents |
| Cookies analytiques | 13 mois | Consentement / recommandation CNIL |
| Images de vidéosurveillance | 30 jours | Finalité sécurité (sauf litige) |
| Données de santé | Jusqu'à 20 ans | Obligations légales médicales et assurantielles |
Une fois la durée définie, il faut la traduire en règles concrètes : usage, archivage et suppression. Sinon, elle reste théorique.
Il faut séparer trois moments dans la vie de la donnée :
Le point souvent oublié, c’est la date de départ. Et sans elle, la règle ne tient pas.
Pour un prospect, le compteur démarre au dernier contact actif. Pour un salarié, à la date de fin de contrat. Pour une facture, à la clôture de l’exercice comptable. À chaque phase, notez le déclencheur, le propriétaire et la preuve du passage à l’étape suivante. Sans déclencheur écrit, la durée n’est pas applicable.
La règle n’a de poids que si l’outil l’applique dans ses réglages.
Le registre pose la règle. Le SaaS, lui, doit la faire vivre. Il faut donc vérifier que les durées déclarées dans le registre correspondent bien aux purges configurées dans les outils.
Cela vise en particulier la rotation et la purge des journaux, la suppression des comptes inactifs et la rétention des tickets de support.
Avanoo permet de comparer les réglages SaaS avec les durées documentées dans le registre, afin de faire remonter les écarts entre ce qui est écrit et ce qui est réellement configuré.
Si un écart apparaît - par exemple, un CRM qui garde les prospects 5 ans au lieu de 3 - il doit être corrigé ou justifié par une dérogation documentée.
Le point suivant consiste à vérifier que les clauses contractuelles et les capacités de suppression suivent la même logique.
Une fois les durées fixées, passez au concret. Il faut vérifier que le contrat et l’outil permettent bien d’appliquer ces règles. Sans ça, la politique de rétention reste théorique. Elle ne devient opposable que si le DPA la reprend noir sur blanc et si le SaaS sait l’exécuter.
Le DPA doit imposer de façon explicite plusieurs points clés :
| Point à vérifier | Ce qu'il faut trouver dans le contrat |
|---|---|
| Suppression ou restitution en fin de contrat | Engagement écrit à supprimer ou restituer toutes les données personnelles à l'expiration du service |
| Traitement des sauvegardes | Délai de purge des sauvegardes après résiliation, et confirmation que les copies sont bien détruites |
| Obligations des sous-traitants ultérieurs | Clause imposant les mêmes exigences à toute la chaîne de sous-traitance |
| Localisation des données, du support et des accès | Identification des régions d'hébergement et des pays depuis lesquels le support accède aux données |
| Droit d'audit | Possibilité pour le responsable de traitement de vérifier les pratiques du prestataire |
Ce point est souvent sous-estimé : si un support hors UE accède aux données, même à distance, cela constitue un transfert international qui doit être encadré dans le contrat [4].
Le contrat ne suffit pas. Il faut aussi voir si l’outil fait le travail, en pratique.
Vérifiez une suppression sélective, au niveau du compte et du champ, afin d’effacer ce qui doit l’être sans supprimer les données à garder [6].
Vérifiez aussi que la suppression se propage bien aux sauvegardes et aux archives, et pas seulement à la base active [1]. En clair, supprimer dans l’interface ne veut pas dire que tout a disparu. Il faut tester chaque demande d’effacement jusqu’aux sauvegardes et consigner les exceptions légales dans le registre des demandes [1][6].
Avanoo centralise les écarts contractuels et de configuration pour aller plus vite dans la mise en conformité. La plateforme automatise la cartographie SaaS et le repérage des écarts réglementaires - RGPD, NIS2, DORA - afin de faire remonter les non-conformités entre la politique écrite et la réalité de la configuration [2].
Il reste ensuite à vérifier ce que le contrat ne couvre pas à lui seul : sauvegardes, journaux et exports.
Après le contrat et la configuration, il faut vérifier ce que gardent les copies dérivées.
Une fois la base active traitée, le risque se déplace souvent ailleurs : dans les copies, les journaux et les exports. C’est là que beaucoup d’organisations se font piéger. On pense avoir supprimé une donnée, alors qu’elle reste présente dans une sauvegarde, un système de réplication ou un fichier exporté.
Un clic de suppression n’efface pas les sauvegardes. Il faut donc tester, de façon technique, chaque processus d’effacement jusqu’aux systèmes de réplication et d’archivage, puis consigner les exceptions dans le registre des demandes [1][6].
Pour les journaux, la CNIL recommande une durée de conservation de 6 mois pour les journaux de connexion et les journaux de messagerie professionnelle [7]. Si votre SaaS ou votre SIEM garde ces données plus longtemps sans motif documenté, vous avez un écart à corriger.
| Type de données | Durée recommandée | Base |
|---|---|---|
| Journaux de connexion | 6 mois | Recommandation CNIL [7] |
| Journaux de messagerie professionnelle | 6 mois | Recommandation CNIL [7] |
Une fois ces limites posées, testez une demande d’effacement de bout en bout. Pas sur le papier. Dans les outils, avec les vraies dépendances techniques.
Répondre à une demande d’effacement dans les délais RGPD - 1 mois, avec extension possible à 2 mois pour les cas complexes [1][6] - demande un processus tracé, pas une chasse manuelle dans plusieurs applications. La première étape consiste à vérifier l’identité du demandeur pour éviter toute suppression frauduleuse [6].
Ensuite, formalisez un processus d’effacement en six étapes :
Il faut aussi auditer les champs de texte libre dans les CRM et les outils RH. C’est un angle mort assez courant : ces champs contiennent souvent des données personnelles non déclarées qui échappent aux processus de suppression standard [5].
Si la suppression immédiate des sauvegardes est techniquement impossible, documentez les données résiduelles ainsi que la date prévue de purge au prochain cycle de rotation [6]. Dit autrement, si tout ne peut pas disparaître tout de suite, il faut au moins savoir quoi reste, où, et jusqu’à quand.
Avant de supprimer, il faut localiser les données et tracer les actions.
Avanoo donne de la visibilité sur l’activité SaaS - fichiers, exports et usages non déclarés - afin d’identifier les emplacements de données personnelles avant de lancer un processus de suppression. Cette vue aide aussi à repérer les exports non autorisés et les transferts transfrontaliers qui peuvent enfreindre le RGPD ou NIS2.
"Avanoo nous a offert une visibilité complète sur notre utilisation des SaaS et de l'IA, renforcé notre sécurité et aidé à optimiser nos coûts efficacement." - Pierre M., DSI, Cabinet d'audit Big Four [2]
La traçabilité des actions d’effacement - qui a agi, quand et sur quel outil - compte autant que l’effacement lui-même. Sans journal de suivi, impossible de prouver la conformité en cas de contrôle.
À la fin de cette checklist, tout se joue sur quatre contrôles simples : un inventaire SaaS à jour, des durées de conservation définies par finalité, des clauses DPA vérifiées, et des réglages techniques bien alignés avec la politique écrite. À cela s'ajoute un point souvent sous-estimé : la maîtrise des sauvegardes et des journaux, avec des rotations fixées à l'avance. Et surtout, il faut une traçabilité complète des suppressions : preuve d'effacement, identifiant de la demande, horodatage et valideur, sans remettre les données supprimées dans les environnements actifs [1][2][3][6][8].
La preuve d'effacement compte autant que l'effacement lui-même.
Pour le rythme d'audit, la base est claire : une revue trimestrielle du registre des traitements, puis un audit annuel complet avec le DPO et, si besoin, un auditeur externe [1]. Cette revue sert à vérifier que les durées, les purges et les suppressions restent bien alignées. La conformité RGPD sur la rétention ne se traite pas une bonne fois pour toutes. Chaque nouveau SaaS remet la machine en route : cartographier, paramétrer, contrôler, tracer.
::: faq
Commencez par un inventaire exhaustif de vos applications SaaS. Cette cartographie sert à repérer le Shadow IT et à voir quelles données personnelles sont traitées par chaque outil, qu’il soit validé ou non par la DSI.
Avanoo peut vous aider sur ce point en automatisant la découverte des applications et la classification des données. Vous obtenez ainsi, plus vite, une vue d’ensemble des risques, des localisations de serveurs et des pratiques de rétention. :::
::: faq
C’est un défi technique bien connu. Si la suppression immédiate n’est pas simple à mettre en place, fixez une durée de conservation claire et raisonnable pour les sauvegardes. Puis dites à l’utilisateur, noir sur blanc, que ses données seront supprimées selon ce délai.
Il faut aussi cadrer le processus. Documentez les risques et la marche à suivre, et gardez une trace des suppressions à rejouer si une restauration a lieu. Ces sauvegardes doivent servir uniquement à remettre l’environnement en état. Et bien sûr, les données qui s’y trouvent doivent être chiffrées. :::
::: faq
Mettez en place une traçabilité documentée. Après chaque suppression, générez un reçu ou un certificat de suppression avec des données anonymisées uniquement :
Tenez aussi un journal de suppression séparé pour les sauvegardes et les archives. Ce journal doit être rejoué après chaque restauration. En clair, si une sauvegarde remet en place des données déjà supprimées, le journal sert à relancer ces suppressions sans délai.
Documentez enfin les éventuelles exceptions légales. Mais attention : ces preuves d’audit ne doivent contenir aucune donnée personnelle. :::
Shadow AI Expert & Chief AI Officer
Olivia Dubois est Shadow AI Expert et Chief AI Officer chez Avanoo. Diplômée d'HEC Paris et ancienne consultante chez BCG, elle accompagne les entreprises dans la détection et la gouvernance du Shadow AI et du Shadow IT.
Découvrez comment Avanoo peut cartographier votre paysage SaaS et IA, réduire les risques et optimiser les coûts. Une plateforme fiable avec un accompagnement humain dédié.
