RGPD : restituer ou effacer les données à la fin du contrat
La sortie d’un service informatique ne se limite pas à fermer des comptes. Le sous-traitant doit organiser la restitution ou l’effacement des données personnelles, y compris dans ses copies techniques.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
La fin d’un contrat crée souvent une zone grise. Les accès du client sont coupés, les ressources principales sont libérées et le dossier est déclaré clos. Pourtant, des données personnelles peuvent rester dans des sauvegardes, des journaux, des systèmes de support, des environnements de test ou des exports techniques. Pour un fournisseur agissant comme sous-traitant, ces traces ne sont pas un simple sujet de rangement. L’article 28, paragraphe 3, point g), du règlement (UE) 2016/679 impose qu’à l’issue des services, les données soient supprimées ou renvoyées au responsable du traitement, selon son choix. Les copies existantes doivent aussi être supprimées, sauf si le droit de l’Union ou d’un État membre exige leur conservation.
Une obligation de sortie
Le règlement fixe un résultat, mais ne décrit ni la commande d’effacement, ni le format de restitution, ni le traitement détaillé des sauvegardes. Ces modalités doivent donc être traduites dans le contrat et dans les procédures d’exploitation. Le responsable du traitement doit pouvoir exprimer son choix. Le fournisseur doit savoir quelles données sont concernées, où elles résident et comment exécuter l’instruction sans toucher aux données d’autres clients. Une clause générique annonçant que les données seront « supprimées conformément aux règles applicables » ne suffit pas à rendre l’opération exécutable. Il faut notamment distinguer la restitution des données utiles au client, l’arrêt des traitements, la suppression des copies de travail et l’expiration des copies conservées dans les mécanismes de protection.
Les copies oubliées
- Les sauvegardes et répliques exigent une règle explicite. Une suppression immédiate et sélective peut être incompatible avec certains supports immuables ou ensembles mutualisés. Le fournisseur doit alors pouvoir expliquer le cycle prévu, empêcher toute remise en production ordinaire des données concernées et limiter strictement les conditions d’une éventuelle restauration.
- Les journaux techniques peuvent contenir des identifiants, des adresses réseau, des noms de fichiers, des requêtes ou des fragments de contenu. Leur qualification dépend de ce qu’ils permettent de relier à une personne. Les traiter par défaut comme des données purement techniques conduit souvent à prolonger leur conservation sans décision formelle.
- Les outils de support concentrent des pièces jointes, des captures d’écran et des copies de bases transmises pour diagnostic. Ces données échappent facilement au processus de sortie lorsqu’elles sont rattachées à un ticket plutôt qu’à l’environnement du client. Leur inventaire doit suivre la relation contractuelle, pas seulement l’infrastructure de production.
- Les environnements de développement, de recette et de démonstration peuvent conserver des jeux issus de la production. La pseudonymisation ne fait pas nécessairement sortir ces données du champ du RGPD. Le processus de fin de contrat doit donc couvrir les clones, exports et instantanés, et pas uniquement le service visible par l’utilisateur.
- Les données de facturation, de sécurité ou de preuve peuvent relever d’une autre finalité ou d’une obligation de conservation distincte. Elles ne doivent pas être mélangées avec les données traitées pour le compte du client. La conservation fondée sur une exigence légale doit être identifiée et limitée ; une habitude interne ou une éventualité imprécise ne constitue pas, à elle seule, l’exception prévue par l’article 28.
Prouver sans surpromettre
L’article 28, paragraphe 3, point h), prévoit également que le sous-traitant mette à disposition les informations nécessaires pour démontrer le respect de ses obligations et contribuer aux audits prévus par le texte. Une attestation d’effacement n’a donc de valeur que si elle correspond à un processus vérifiable. Elle devrait identifier le périmètre traité, l’instruction reçue, les catégories de systèmes concernées, les opérations réalisées, les exceptions de conservation et le sort des sauvegardes. Il faut éviter les formulations absolues lorsqu’aucun mécanisme ne permet de les établir. Affirmer qu’il ne subsiste « aucune donnée » alors que des copies chiffrées attendent leur expiration dans une sauvegarde est difficilement défendable. Une preuve sobre, précise et cohérente avec l’architecture vaut mieux qu’un certificat trop large. L’effacement doit aussi être testé : suppression d’un compte, recherche des artefacts associés, contrôle des restaurations et vérification des systèmes de support.
La restitution ne dispense pas automatiquement le fournisseur de supprimer ses propres copies. Inversement, une demande d’effacement ne doit pas conduire à détruire des éléments qu’un texte applicable impose de conserver. La bonne réponse dépend des rôles réels, des finalités et des obligations sectorielles. Ces points doivent être examinés avant la résiliation, avec les fonctions juridiques, de protection des données, de sécurité et d’exploitation. Le présent article expose des principes généraux et ne constitue pas un conseil juridique personnalisé.
The end of a contract often creates a grey area. Client access is disabled, primary resources are released, and the file is marked as closed. Yet personal data may remain in backups, logs, support systems, test environments or technical exports. For a provider acting as a processor, these remnants are not merely a housekeeping issue. Article 28(3)(g) of Regulation (EU) 2016/679 requires personal data to be deleted or returned to the controller, at the controller’s choice, once the services have ended. Existing copies must also be deleted unless Union or Member State law requires their retention.
An exit obligation
The regulation defines an outcome, but it does not specify the deletion command, the return format or the detailed handling of backups. These arrangements therefore need to be translated into contracts and operating procedures. The controller must be able to state its choice. The provider must know which data is concerned, where it resides and how to carry out the instruction without affecting other clients’ data. A generic clause stating that data will be “deleted in accordance with applicable rules” does not make the operation executable. The process must distinguish between returning data that the client needs, stopping processing activities, deleting working copies and allowing copies held in protection mechanisms to expire.
The forgotten copies
- Backups and replicas require an explicit rule. Immediate, selective deletion may be incompatible with some immutable media or shared datasets. The provider must then be able to explain the planned lifecycle, prevent the affected data from being returned to ordinary production use and tightly restrict the conditions under which any restoration could occur.
- Technical logs may contain identifiers, network addresses, file names, queries or fragments of content. Their status depends on whether they can be linked to an individual. Treating them as purely technical data by default often results in extended retention without a formal decision.
- Support tools accumulate attachments, screenshots and database copies supplied for diagnostic purposes. This data can easily escape the exit process when it is associated with a ticket rather than the client’s environment. Its inventory must follow the contractual relationship, not only the production infrastructure.
- Development, testing and demonstration environments may retain datasets derived from production. Pseudonymisation does not necessarily take that data outside the scope of the GDPR. The end-of-contract process must therefore cover clones, exports and snapshots, not only the service visible to users.
- Billing, security or evidentiary data may serve a separate purpose or be subject to a distinct retention obligation. It must not be mixed with data processed on the client’s behalf. Retention based on a legal requirement must be identified and limited; an internal habit or an unspecified future possibility does not, by itself, qualify for the exception in Article 28.
Evidence without overstatement
Article 28(3)(h) also requires the processor to make available the information needed to demonstrate compliance with its obligations and to contribute to the audits provided for by the regulation. A deletion statement therefore has value only when it reflects a verifiable process. It should identify the scope addressed, the instruction received, the categories of systems involved, the operations performed, any retention exceptions and the treatment of backups. Absolute wording should be avoided when no mechanism can substantiate it. Claiming that “no data remains” while encrypted copies are awaiting expiry in a backup is difficult to defend. Evidence that is restrained, precise and consistent with the architecture is preferable to an excessively broad certificate. Deletion should also be tested by removing an account, searching for related artefacts, checking restoration procedures and inspecting support systems.
Returning data does not automatically release the provider from deleting its own copies. Conversely, a deletion request must not result in the destruction of records that applicable law requires to be retained. The appropriate response depends on the actual roles, purposes and sector-specific obligations. These points should be reviewed before termination by legal, data protection, security and operations functions. This article sets out general principles and does not constitute personalised legal advice.