Comment organiser la gestion de l’ensemble des données de leur création à leur suppression ?

Une donnée professionnelle peut être créée dans un CRM, copiée dans un tableur, transmise à un prestataire, archivée dans une GED puis oubliée dans une sauvegarde. Sans règles communes, chaque application conserve sa propre version de l’information, parfois bien après la disparition de son utilité.

Pour un responsable des systèmes d’information, maîtriser le cycle de vie des données consiste à définir leur finalité, leur responsable, leurs conditions d’accès, leur durée de conservation et leur sort à échéance. Cette organisation doit couvrir les données personnelles comme les informations métier, en distinguant les obligations juridiques des choix opérationnels.

Le dispositif repose sur quatre décisions : savoir où résident les informations, déterminer lesquelles doivent rester accessibles, organiser leur archivage lorsque celui-ci est justifié et garantir leur suppression lorsqu’elles ne doivent plus être conservées. Dans une PME, cette démarche peut progresser par système et par catégorie documentaire, sans imposer immédiatement un programme de gouvernance complexe.

Pourquoi conserver toutes les données historiques complique-t-il les opérations au quotidien ?

Conserver toutes les données historiques complique les opérations parce que les informations utiles deviennent plus difficiles à distinguer des données périmées. Les recherches produisent davantage de résultats à vérifier, les contrôles d’accès concernent des périmètres mal identifiés et les responsables métier perdent la maîtrise de leurs référentiels. Le problème dépasse largement le coût du stockage.

Le stockage supplémentaire peut représenter une dépense limitée dans certaines infrastructures. En revanche, le temps nécessaire pour retrouver un contrat valide, identifier la dernière version d’une procédure ou vérifier les droits associés à un ancien dossier constitue une charge opérationnelle récurrente.

Dans un CRM, des contacts historiques non qualifiés peuvent apparaître aux côtés de prospects actifs. Dans une GED, plusieurs versions de documents clôturés peuvent masquer celle qui fait autorité. Ces situations multiplient les vérifications manuelles et les risques d’utilisation d’une information dépassée.

Un second problème concerne la responsabilité. Lorsqu’un répertoire contient des fichiers accumulés pendant plusieurs années, il devient parfois impossible de déterminer quel service les utilise encore, qui peut autoriser leur suppression ou pourquoi ils ont été conservés.

Cette incertitude complique notamment le traitement d’une demande d’accès ou d’effacement portant sur des données personnelles.

Pour détecter une accumulation problématique, le DSI peut examiner quelques signaux concrets :

• Des répertoires dont personne ne peut expliquer précisément le contenu.
• Des documents sans propriétaire métier identifiable.
• Des données anciennes encore visibles dans les recherches courantes.
• Des opérations nécessitant de nombreuses vérifications manuelles.
• Des historiques sans date de fin de conservation.

La conservation excessive soulève également une question juridique. La CNIL rappelle, dans ses recommandations sur les durées de conservation des données personnelles, que leur durée doit être déterminée en fonction de la finalité du traitement.

Cette exigence ne signifie pas que toutes les données anciennes doivent être effacées : certaines obligations imposent leur conservation. Elle oblige en revanche à justifier leur maintien et à organiser leur cycle de vie.

Une fois les catégories obsolètes identifiées, la difficulté suivante consiste à les retirer de l’ensemble des applications qui en détiennent une copie.

Comment supprimer des informations obsolètes dans plusieurs applications liées ?

Pour supprimer des informations obsolètes dans plusieurs applications, il faut d’abord cartographier leurs échanges, identifier le système qui fait autorité, organiser la propagation de la suppression et conserver une trace de son exécution. Effacer un enregistrement dans une application ne garantit pas sa disparition des outils synchronisés, des exports ou des sauvegardes.

Dans un environnement interconnecté, une même information peut circuler entre un ERP, un CRM, une plateforme de support et un outil de reporting. Chaque intégration possède ses propres règles de synchronisation, de mise à jour et parfois de conservation.

Une suppression effectuée uniquement dans l’outil destinataire peut même être annulée lors de la synchronisation suivante : si l’enregistrement existe toujours dans le système source, le connecteur risque de le recréer.

La méthode opérationnelle comprend quatre étapes :

1. Cartographier les dépendances. Recenser les applications, connecteurs, bases secondaires et destinations d’export. Préciser le sens des échanges et leur fréquence.
2. Identifier la donnée maîtresse. Déterminer quelle application détient l’enregistrement de référence et quelle équipe décide de son maintien ou de sa suppression.
3. Définir l’ordre des opérations. Traiter la source et les copies selon les mécanismes techniques disponibles, en évitant toute recréation automatique.
4. Documenter et vérifier. Enregistrer les systèmes concernés, la date, le motif, les résultats et les éventuelles exceptions.

La suppression doit également couvrir les copies qui échappent aux interfaces métier habituelles. Les fichiers Excel exportés vers un espace partagé, les pièces jointes d’une messagerie ou les captures conservées dans un ticket d’assistance peuvent contenir les mêmes informations.

Les sauvegardes exigent un traitement particulier. Une suppression immédiate dans chaque copie de sauvegarde n’est pas toujours techniquement réalisable. Il faut alors définir une durée de rétention justifiée, limiter les accès et prévoir les mécanismes empêchant qu’une restauration ne réintroduise durablement des données effacées.

Lorsque des sous-traitants traitent des données personnelles, les obligations contractuelles doivent également être prises en compte. L’article 28 du RGPD encadre notamment leur suppression ou restitution à la fin de la prestation, sauf obligation légale de conservation.

Avant de déclencher cette procédure, il reste toutefois indispensable de vérifier que les données concernées ne doivent pas être conservées sous une forme archivée.

Archivage intermédiaire ou suppression définitive pour des dossiers clôturés ?

Un dossier clôturé doit être placé en archivage intermédiaire lorsqu’une obligation légale ou une justification résiduelle nécessite sa conservation sans utilisation quotidienne. Il doit être supprimé lorsque sa finalité est épuisée et qu’aucun autre motif légitime ne justifie son maintien. Le choix dépend de la nature des données, des délais applicables et des risques associés.

Trois critères permettent de prendre cette décision : l’existence d’une obligation de conservation, l’utilité opérationnelle ou probatoire du dossier et le risque lié à la conservation prolongée d’informations personnelles.

En France, les durées diffèrent selon les documents. Par exemple, l’article L123-22 du Code de commerce impose la conservation pendant dix ans des documents comptables et pièces justificatives concernés, comme le précise l’article L123-22 du Code de commerce.

Le tableau suivant aide à distinguer les décisions possibles pour un dossier clôturé.

L’archivage intermédiaire n’est pas un stockage permanent. Les données quittent l’environnement de travail courant pour un espace séparé, accessible uniquement aux personnes habilitées. Une échéance doit être définie, puis appliquée par un mécanisme de réexamen ou de suppression.

À l’inverse, déplacer un dossier vers un répertoire nommé « anciennes archives » sans responsable ni date limite revient à déplacer le problème plutôt qu’à le résoudre.

Il faut également distinguer suppression logique et suppression définitive. La première masque ou désactive un enregistrement tout en permettant sa récupération. La seconde vise à rendre les données irrécupérables dans le périmètre concerné, sous réserve des contraintes techniques et des obligations légales applicables.

Lorsqu’un droit à l’effacement s’applique, une simple désactivation visible peut donc être insuffisante si les données demeurent conservées sans justification.

Cette politique doit également couvrir les données dont le responsable opérationnel disparaît, notamment lorsqu’un salarié quitte l’entreprise.

Les données oubliées lors du départ d’un collaborateur

Le départ d’un collaborateur peut laisser des données professionnelles sans propriétaire, des comptes actifs et des automatisations dépendant d’une identité individuelle. Le traitement de ces informations doit associer transfert des ressources utiles, révocation des accès et conservation encadrée des données personnelles du salarié. Une simple désactivation de son compte principal ne suffit pas.

Les informations concernées se trouvent souvent dans des emplacements dispersés : messagerie nominative, espace cloud personnel professionnel, fichiers locaux non synchronisés, outils SaaS souscrits directement, applications mobiles ou scripts exécutés avec des identifiants individuels.

Les clés API et les automatisations méritent une attention particulière. Un flux de synchronisation peut continuer à fonctionner avec les identifiants d’un ancien collaborateur, ou au contraire s’interrompre brutalement lorsque son compte est désactivé.

La procédure de départ doit couvrir trois volets distincts.

• Transfert de propriété : identifier les dossiers, documents, services et automatisations nécessaires à l’activité, puis désigner un nouveau responsable.
• Révocation des accès : désactiver les comptes, sessions, jetons, clés et autorisations accordées aux applications connectées.
• Traitement des données personnelles : appliquer aux documents RH et aux informations du collaborateur les règles de conservation correspondant à leurs finalités.

La CNIL recommande de supprimer les permissions d’accès dès qu’un utilisateur n’est plus habilité, notamment à la fin de son contrat. Sa fiche Sécurité : Gérer les habilitations recommande également une revue régulière, au minimum annuelle, des droits attribués.

Un autre piège concerne les comptes nominatifs utilisés comme comptes fonctionnels. Si l’abonnement d’une application critique dépend exclusivement de l’adresse professionnelle d’un salarié, son départ peut perturber la facturation, l’administration ou la continuité du service.

Les comptes fonctionnels nécessaires à l’exploitation doivent donc être administrés indépendamment des identités individuelles, avec des accès nominatifs traçables.

Enfin, les données professionnelles stockées sur un équipement personnel ou dans un compte privé ne disparaissent pas du périmètre de responsabilité de l’entreprise. Leur récupération doit être organisée dans le respect des droits du collaborateur, de la confidentialité des contenus privés et des règles applicables aux équipements personnels.

Au-delà des départs, cette discipline doit devenir régulière pour empêcher la reconstitution progressive de données orphelines.

À quelle fréquence examiner les données devenues inutiles dans un système métier ?

Il n’existe pas de fréquence universelle pour examiner les données devenues inutiles. La périodicité doit dépendre des durées de conservation, du rythme de création des informations et de leur sensibilité. Une revue programmée doit être complétée par des contrôles déclenchés lors des événements métier, comme une clôture de projet ou un changement d’application.

Un système produisant quotidiennement des données à courte durée de conservation nécessite un mécanisme de purge plus fréquent qu’un référentiel documentaire dont les échéances sont longues.

La revue ne doit surtout pas devenir un substitut à l’exécution des échéances légales. Si une catégorie doit être supprimée à une date déterminée, le calendrier de contrôle doit permettre de respecter cette échéance, idéalement au moyen d’une règle automatisée.

Deux modes de contrôle se complètent :

• La revue systématique : examen périodique d’un périmètre défini, des catégories de données et des anomalies détectées.
• La revue événementielle : contrôle déclenché par un départ, une fin de contrat, une migration, une clôture de projet ou une évolution réglementaire.

Une PME peut intégrer ces contrôles à des rituels déjà existants, comme les bilans trimestriels des applications ou les revues de fin de projet. La fréquence retenue doit rester une décision interne documentée, non une obligation réglementaire supposée.

Trois indicateurs permettent de suivre les progrès : la proportion d’informations non consultées depuis une période définie, le volume de données sans responsable identifié et le nombre de catégories sans échéance de conservation paramétrée.

L’absence de consultation n’établit toutefois pas qu’une donnée peut être supprimée. Un document peu utilisé peut conserver une valeur probatoire ou relever d’une obligation légale.

Cette logique de réexamen s’applique également aux versions successives des documents partagés, souvent accumulées automatiquement sans décision explicite.

Comment définir la durée de conservation des versions de documents partagés ?

La durée de conservation des versions de documents partagés doit être définie selon la catégorie documentaire, l’utilité des anciennes versions et les obligations applicables. Il faut distinguer l’historique technique généré automatiquement par l’outil collaboratif de l’archivage volontaire des documents faisant autorité. Ces deux mécanismes ne répondent pas nécessairement aux mêmes besoins.

Un historique technique sert principalement à restaurer un fichier, comparer des modifications ou corriger une erreur. Un archivage documentaire vise plutôt à préserver un document identifié, parfois pour établir une preuve ou satisfaire une obligation de conservation.

Conserver indéfiniment chaque modification d’un brouillon n’offre pas la même valeur que préserver une version contractuelle signée.

La première étape consiste à classer les documents par famille. Le tableau ci-dessous présente des critères d’arbitrage, sans imposer de durées universelles.

Pour chaque famille, le responsable documentaire peut définir un nombre maximal de versions techniques et une durée de conservation adaptée. Ces paramètres doivent être validés avec les équipes métier et, lorsque nécessaire, les fonctions juridiques ou conformité.

La valeur probante des versions doit être appréciée avec précaution. Une ancienne version peut aider à comprendre qui a modifié un document, mais elle peut aussi contenir des informations personnelles supprimées de la version courante.

Dans les outils collaboratifs, le DSI doit examiner les paramètres d’historique disponibles : limites de versions, règles de rétention, politiques d’archivage, corbeilles et mécanismes de purge. Les possibilités varient selon les produits, leurs éditions et les politiques d’administration.

Il est utile de tester ces règles sur un espace pilote, puis de vérifier leur comportement après restauration ou déplacement d’un document. Une limite de versions ne garantit pas nécessairement l’effacement de toutes les copies associées.

Pour appliquer ces règles de manière cohérente, chaque catégorie sensible doit disposer d’un responsable clairement identifié et de droits de décision définis.

Comment établir une matrice de responsabilités pour les données sensibles ?

Une matrice de responsabilités pour les données sensibles associe chaque catégorie d’informations à un responsable métier, précise les personnes autorisées à agir et définit les validations nécessaires. Elle doit distinguer les rôles opérationnels des responsabilités juridiques du RGPD, puis se traduire en habilitations effectives dans les applications de l’entreprise.

Le propriétaire métier de la donnée est généralement la personne chargée de sa qualité, de ses usages et des arbitrages opérationnels. Le responsable du traitement, au sens du RGPD, est l’entité qui détermine les finalités et les moyens du traitement, seule ou conjointement avec d’autres. L’utilisateur, lui, intervient dans le cadre des droits qui lui sont attribués.

Ces rôles peuvent se recouper, mais ils ne sont pas interchangeables. Désigner un salarié comme propriétaire métier ne transfère pas automatiquement sur lui la responsabilité juridique de l’entreprise.

La matrice peut être construite en quatre étapes :

1. Recenser les catégories sensibles, notamment les données personnelles clients et salariés, les informations contractuelles et les données métier confidentielles.
2. Désigner un responsable métier principal et un suppléant pour chaque catégorie.
3. Définir les prérogatives : validation des accès, autorisation d’export, arbitrage d’archivage et décision de suppression.
4. Formaliser les responsabilités dans un document validé, diffusé aux personnes concernées et régulièrement actualisé.

La matrice doit ensuite être traduite en droits applicatifs. Une personne autorisée à consulter un dossier n’a pas nécessairement besoin de pouvoir l’exporter ou le supprimer définitivement. Pour les opérations sensibles, une validation distincte peut limiter les erreurs et les abus.

Le cadre juridique impose également une organisation démontrable. Le chapitre IV du RGPD relatif au responsable du traitement et au sous-traitant prévoit notamment des mesures techniques et organisationnelles appropriées ainsi que, dans la mesure du possible, la documentation des délais d’effacement dans le registre des traitements.

Pour une PME, le registre reste un outil important. La dispense conditionnelle prévue pour certaines organisations de moins de 250 salariés ne constitue pas une exemption générale, notamment lorsque les traitements ne sont pas occasionnels.

Cette matrice ne remplace ni le registre des traitements ni une éventuelle analyse d’impact. Elle permet de rendre opérationnelles les décisions de gouvernance et de produire des éléments de preuve sur l’organisation réellement appliquée.

Une fois cette répartition définie, la PME peut construire une gouvernance proportionnée à ses moyens, sans multiplier inutilement les instances et les documents.

Comment mettre en place une gouvernance des données d’entreprise adaptée à une PME ?

Pour une PME, une gouvernance des données efficace repose sur un référent identifié, des responsabilités métier explicites, quelques règles documentées et des contrôles intégrés aux outils existants. Le déploiement doit commencer par les informations les plus sensibles, puis s’étendre progressivement aux autres systèmes. L’objectif est de rendre les décisions de conservation et de suppression exécutables et vérifiables.

Il n’est pas indispensable de créer un comité permanent ou une structure spécialisée. Un référent à temps partiel peut coordonner le dispositif, à condition de disposer d’un mandat clair, d’un suppléant et de relais dans les services concernés.

Le socle initial peut tenir en quatre documents courts :

• Un inventaire des systèmes : applications, catégories de données, flux, prestataires et emplacements de stockage.
• Une matrice de responsabilités : propriétaires métier, validateurs, administrateurs et suppléants.
• Un référentiel de conservation : finalités, durées, points de départ des délais, règles d’archivage et modalités de suppression.
• Une procédure de départ : transfert des ressources, révocation des accès et traitement des données du collaborateur.

Ces documents peuvent être synthétiques, mais ils doivent renvoyer aux procédures et justificatifs nécessaires lorsque la complexité des traitements l’exige.

Le déploiement doit suivre un ordre de priorité. Les données personnelles des clients et salariés, les dossiers contractuels et les informations particulièrement sensibles constituent généralement des périmètres à examiner en premier. Les référentiels secondaires peuvent ensuite être intégrés progressivement.

Un scénario pédagogique illustre cette démarche.

Trois facteurs fragilisent particulièrement cette organisation : un référent unique sans remplaçant, des règles écrites qui ne correspondent pas aux capacités des outils et l’absence de contrôle après le lancement.

Les contre-mesures sont concrètes : désigner un suppléant, vérifier les possibilités techniques avant de valider les procédures et inscrire les revues dans les réunions de pilotage existantes.

La gouvernance doit enfin rester évolutive. L’arrivée d’une application, la signature d’un nouveau contrat de sous-traitance ou la modification d’un processus métier doivent déclencher une mise à jour de l’inventaire et des responsabilités concernées.

La première action consiste à sélectionner un système métier prioritaire, identifier son responsable et documenter le cycle de vie d’une catégorie de données, de sa création à sa suppression. Ce périmètre pilote fournira une méthode concrète pour étendre progressivement la gouvernance à l’ensemble de l’entreprise.