Par Olivia Dubois
·
4 juillet 2026
Je vais droit au but : sous le RGPD, je ne peux pas garder des données personnelles sans limite, et en SaaS, le risque vient surtout des données dispersées.
En pratique, une politique de rétention SaaS tient sur quelques règles simples :
Deux chiffres montrent le sujet : la CNIL a déjà sanctionné des durées trop longues, avec 100 000 € pour des comptes inactifs gardés trop longtemps et 1,75 M€ pour des données conservées pendant des décennies.
Voici ce qu’il faut retenir tout de suite :
Je peux résumer l’article comme ça : il faut d’abord cartographier, puis classer, ensuite fixer les durées, exécuter la suppression dans chaque outil, et enfin conserver un dossier de preuve propre et daté.
Cela donne une politique plus simple à appliquer côté juridique, IT et métiers.
Fixer des durées sans cartographie fiable mène presque toujours à des règles de rétention difficiles à défendre. Le RGPD demande un lien clair entre chaque durée, une finalité précise et une base légale documentée. En clair, on ne commence pas par la durée. On commence par la carte du terrain.
La première étape consiste donc à recenser tous les flux de données, puis à les rattacher à une catégorie nette.
Un inventaire utile ne s'arrête pas aux applications principales. C'est souvent là que les trous apparaissent. Il faut aussi couvrir les modules internes - par exemple les formulaires d'un CRM - , les connecteurs et API entre outils, les exports réguliers comme les rapports PDF ou les extractions analytiques, ainsi que les zones de stockage secondaires : sauvegardes, archives et environnements de test.
Pour chaque flux repéré, l'inventaire doit indiquer :
Ce dernier point compte beaucoup. Certains SaaS ne permettent pas de supprimer des enregistrements individuels. Mieux vaut le découvrir à ce stade qu'après avoir rédigé une politique impossible à appliquer.
Une fois l'inventaire en place, il faut regrouper les données dans des catégories cohérentes : données clients, données prospects, données salariés et candidats, logs d'authentification, tickets de support, données de paiement et archives.
Chaque catégorie suit ses propres obligations et ses propres durées. Il faut aussi ajouter le profil d'accès et le niveau de sensibilité. Dit autrement, deux jeux de données peuvent sembler proches sur le papier, mais demander un traitement très différent. Un log technique accessible seulement aux administrateurs système ne se gère pas comme des données de santé de salariés consultables par plusieurs équipes.
Cette combinaison - type, accès et sensibilité - aide à traiter d'abord les catégories les plus exposées et à ajuster les mesures de sécurité qui vont avec.
Une fois ces catégories stabilisées, on peut fixer des durées de conservation par type de donnée.
Le principal risque, ce sont les flux invisibles. Et dans un stack SaaS, ils se glissent partout. Shadow IT, connecteurs non déclarés, exports oubliés : il suffit d'un flux passé sous le radar pour fausser la cartographie.
Des plateformes de gouvernance SaaS comme Avanoo aident à repérer ces flux non documentés. Sans cette visibilité, les durées de conservation reposent sur une vue partielle du système. Et une durée fondée sur une vue partielle devient vite difficile à justifier.
Cette cartographie sert ensuite à fixer des durées défendables par catégorie.
À partir de la cartographie, il faut poser un tableau clair, catégorie par catégorie : durée, déclencheur, base légale et action de fin de vie. Sans ce tableau, la politique reste compliquée à appliquer sur le terrain et encore plus compliquée à justifier en cas de contrôle. En pratique, ce tableau sert de repère commun pour régler les règles de rétention dans chaque SaaS.
Une durée ne part pas “à peu près” d’un moment flou. Elle commence à partir d’un événement précis, daté et vérifiable : fin de contrat, dernier contact, clôture d’un ticket, départ d’un salarié.
C’est un point souvent sous-estimé. Un même SaaS peut contenir plusieurs catégories de données, avec des usages différents. Donc, un même outil peut aussi porter plusieurs règles de rétention. Par exemple, dans un CRM, les données clients ne suivent pas forcément la même durée que les données prospects.
Pour chaque ligne du tableau, rattachez la catégorie à une seule base légale : contrat, obligation légale, intérêt légitime, consentement ou défense en justice. L’idée est simple : une ligne, un fondement principal.
La défense en justice doit rester limitée au besoin réel. Ce n’est pas une case pratique à utiliser partout. Si vous l’appliquez trop largement, votre tableau perd en clarté et votre position devient plus dure à défendre.
Chaque ligne relie une donnée, un point de départ et une action finale.
Exemples de lignes à intégrer dans le tableau :
| Catégorie | Emplacement SaaS | Durée | Déclencheur | Base légale / Justification | Action de fin |
|---|---|---|---|---|---|
| Données clients | Salesforce, HubSpot | Fin du contrat + 5 ans | Fin de contrat | Exécution du contrat / Défense en justice | Archivage puis suppression |
| Données prospects | HubSpot, Pipedrive | 3 ans | Dernier contact actif | Intérêt légitime / Consentement | Suppression |
| Dossiers salariés | Lucca, Payfit | 5 ans | Départ du salarié | Obligation légale (droit du travail) | Archivage restreint |
| Factures / comptabilité | Pennylane, Stripe | 10 ans | Clôture de l'exercice comptable | Obligation légale (Code de commerce, art. L123-22) | Archivage à accès restreint |
| Journaux de sécurité | Datadog, Okta | 6 à 12 mois (jusqu'à 3 ans si justifié) | Création du journal | Intérêt légitime (sécurité) | Suppression |
| Tickets support | Zendesk, Intercom | 3 à 5 ans | Clôture du ticket | Exécution du contrat / Défense en justice | Anonymisation ou suppression |
| Comptes utilisateurs | Google Workspace, Okta | 1 mois | Clôture du compte | Exécution du contrat | Suppression |
Ces durées s’appuient sur les repères CNIL et le droit français : 3 ans pour la prospection commerciale à compter du dernier contact actif[4][7], 10 ans pour les documents comptables[2][1], 5 ans pour certains dossiers RH après le départ[3], et 6 à 12 mois pour les journaux de sécurité, avec une extension possible jusqu’à 3 ans selon le contexte[5].
La suite consiste à définir, pour chaque catégorie, l’action de fin de vie la plus adaptée : suppression, anonymisation ou archivage.
Quand la durée de rétention arrive à son terme, la donnée ne doit plus rester dans la base active. Le cycle de vie est simple sur le papier : base active, archive restreinte, puis suppression ou anonymisation. Mais dans un SaaS, ce schéma doit se traduire en règles séparées pour la production, l’archive et les sauvegardes.
Chaque ligne du tableau de rétention doit mener à une action de sortie nette.
La suppression sécurisée reste la règle par défaut. Si la donnée n’a plus d’usage légal ni métier, il faut la retirer de la production, puis la purger selon le cycle prévu dans les sauvegardes.
L’anonymisation sert à garder une utilité statistique sans conserver de données personnelles. Si elle est irréversible, la donnée sort du champ du RGPD. À l’inverse, la pseudonymisation baisse le risque, mais la donnée reste une donnée personnelle.
L’archivage intermédiaire, avec accès restreint, ne se justifie que dans des cas précis : obligation légale, défense en justice pendant les délais de prescription, ou contrôle réglementaire. Cette archive doit rester séparée de la base active, sur le plan physique ou logique, avec des droits d’accès limités et une journalisation des accès. Elle ne doit contenir que les données strictement utiles au besoin documenté.
Dans un environnement SaaS, ces règles doivent devenir des workflows automatisables et audités. Le tableau ci-dessous résume le choix à faire :
| Action | Quand l'appliquer | Effet sur le RGPD |
|---|---|---|
| Suppression sécurisée | Fin de rétention, aucune utilité résiduelle | Les données sont retirées de la production et purgées des sauvegardes selon le cycle prévu |
| Anonymisation | Conservation analytique ou statistique nécessaire | Les données sortent du champ du RGPD si l'anonymisation est irréversible |
| Pseudonymisation | Réduction du risque sur des données actives ou archivées | Les données restent personnelles, le RGPD continue de s'appliquer |
| Archivage intermédiaire | Obligation légale ou contentieux documenté | Le RGPD s'applique, avec accès strictement limité |
Un point passe souvent sous le radar : les sauvegardes. Si une donnée disparaît de la production mais reste dans des backups, la suppression n’est pas effective. La politique de rétention doit donc fixer, à part, la durée de conservation des sauvegardes pour chaque SaaS - par exemple 30 à 90 jours pour les sauvegardes quotidiennes et 6 à 12 mois pour les sauvegardes mensuelles [6][8] - puis vérifier que ces cycles restent alignés avec les règles de rétention principales.
Choisir l’action ne suffit pas. Il faut aussi pouvoir l’exécuter, outil par outil.
La suppression ne se limite pas à un clic. Elle doit couvrir la production, les exports, les espaces partagés, les environnements de test, les caches, les index et les sauvegardes.
Les workflows opérationnels doivent prévoir :
En cas de contentieux ou d’audit, un mécanisme de gel juridique doit suspendre la suppression de façon automatique et rediriger les données visées vers l’archive restreinte. La portée du gel et sa durée doivent être documentées sans zone floue.
La traçabilité est obligatoire. Chaque action de suppression, d’anonymisation ou d’archivage doit être journalisée avec la date, la catégorie de données, l’outil utilisé et l’action menée. Des plateformes comme Avanoo aident à repérer les exports oubliés, les environnements non maîtrisés et à vérifier l’application réelle des règles de suppression. Ces journaux servent ensuite de dossier de preuve en cas de contrôle.
Une fois les suppressions faites, le sujet n'est plus seulement l'exécution. Il faut pouvoir le prouver. Sans archivage centralisé, les journaux de suppression deviennent pénibles à sortir au moment d'un contrôle. Or, le principe de responsabilité du RGPD impose de démontrer la conformité, pas juste de l'affirmer [9][13].
Concrètement, il faut monter un dossier structuré, centralisé et facile à retrouver. Ce dossier doit pouvoir servir aussi bien à la CNIL qu'à un audit interne ou à un audit client.
Le dossier de conformité doit réunir sept preuves clés [9][11][13][16][18] :
| Élément | Ce qu'il doit contenir |
|---|---|
| Politique de rétention approuvée | Version datée, signataire identifié, historique des révisions |
| Tableau de rétention | Durées par catégorie, déclencheur, base légale, action de fin de vie |
| Lien vers le registre des traitements (RoPA) | Correspondance entre chaque règle de rétention et l'entrée RoPA concernée |
| Journaux de suppression et d'anonymisation | Date, catégorie, outil, périmètre (production, sauvegardes et, le cas échéant, sous-traitants), résultat |
| Journaux d'accès aux archives | Identité, horodatage, jeu de données consulté, finalité, action menée |
| Registre des exceptions et gels juridiques | Système concerné, motif, date de début, durée prévue, responsable |
| Preuves d'exécution | Rapports de jobs de suppression, exports API, comptages avant/après |
Chaque document doit être versionné, daté et rattaché à l'application SaaS concernée ainsi qu'à la catégorie de données. Ce point peut sembler administratif, mais c'est souvent là que tout se joue lors d'un contrôle.
Les journaux d'audit peuvent eux-mêmes contenir des données personnelles. Il faut donc leur appliquer une durée propre : 30 à 90 jours pour les logs opérationnels, et 12 à 24 mois pour les logs de sécurité et d'audit [15][17][19].
Pour donner plus de poids aux logs, les bonnes pratiques recommandent un stockage en écriture seule, séparé de la base applicative principale, avec des droits d'accès stricts [10][12][14]. En clair : si les preuves sont mélangées au reste, ou si elles peuvent être modifiées trop facilement, elles perdent une bonne partie de leur intérêt.
Des plateformes comme Avanoo peuvent aider à centraliser ces éléments de preuve par application SaaS et à préparer plus facilement les rapports de conformité.
La documentation minimale tient en cinq blocs. L'idée est simple : savoir ce qu'on couvre, pourquoi, pendant combien de temps, et où se trouve la preuve.
La politique doit aussi rester alignée avec les contrats fournisseurs - notamment les DPA et les SLA - ainsi qu'avec les exigences de sécurité applicables. Pourquoi ? Parce que certaines suppressions dépendent directement de ce que le prestataire SaaS permet de faire, ou non.
Un audit à blanc annuel reste souvent le moyen le plus sûr de vérifier que le dossier tient debout. Il permet de contrôler que chaque preuve est complète et que tout colle entre les volets juridique, IT et sécurité [9][11][13].
::: faq
Commencez par une cartographie complète de votre paysage applicatif. Le but est simple : repérer tous les outils SaaS et IA en usage, y compris ceux du Shadow IT.
Puis, classez chaque application selon son niveau de criticité et le type de données traitées. Ce travail sert à poser les bonnes bases légales, à aligner les durées de conservation avec le RGPD, NIS2 ou DORA, et à documenter la politique dans un référentiel centralisé pour pouvoir la justifier en cas de contrôle. :::
::: faq
Pour définir une durée de conservation conforme au RGPD, le plus simple est d’aligner votre politique de rétention sur les obligations légales liées à chaque type de donnée traité dans vos applications SaaS.
Concrètement, il ne suffit pas de fixer une date “par défaut” pour tout. Les données n’ont pas toutes le même statut, ni la même durée de conservation. Certaines doivent être gardées pendant une période précise. D’autres doivent être supprimées plus tôt.
Il faut aussi classer les données personnelles et les données sensibles, puis documenter noir sur blanc les règles de suppression et d’archivage. C’est ce qui permet de montrer, en cas de contrôle, que votre organisation sait quoi conserver, combien de temps et pour quelle raison.
Avanoo peut aider sur ce point en cartographiant en continu vos applications SaaS et en facilitant la production des preuves attendues lors d’un contrôle. :::
::: faq
Ils posent un gros risque côté conformité RGPD. Pourquoi ? Parce qu’ils peuvent contenir des données personnelles sensibles, tout en restant hors de votre surveillance au quotidien. Il faut donc les faire entrer dans votre cartographie des données.
Appliquez aussi vos règles de rétention aux sauvegardes, aux archives et aux logs. L’idée est simple : mettre en place une suppression automatisée dès que la durée légale est dépassée. Avanoo aide à repérer les exports non autorisés et à vérifier que ces règles sont bien appliquées. :::
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é.
