La question de la conservation des données IA arrive toujours trop tard. On déploie un assistant, on branche une base documentaire, on active les journaux pour pouvoir déboguer, et dix-huit mois plus tard personne ne sait combien de temps ces éléments sont gardés, ni qui a décidé de cette durée, ni comment on les supprimerait si on le voulait.
Le problème n'est pas théorique. Un historique de conversations contient, dans toute organisation, des données personnelles que personne n'a prévu d'y mettre : coordonnées de clients collées dans une requête, extraits de courriels, éléments de dossiers du personnel. Ces données sont soumises au principe de limitation de la conservation, qui impose de ne les garder que le temps nécessaire à la finalité poursuivie.
Cet article propose une méthode pour écrire une politique de conservation lisible et applicable : les six flux à couvrir, des durées défendables pour chacun, la façon de trancher le conflit entre exigence d'audit et minimisation, et la mécanique de purge automatique qui fait respecter le tout sans intervention humaine.
Les six flux à couvrir, et pourquoi on en oublie toujours trois
Une politique qui ne parle que des conversations laisse la majorité du volume hors de son champ. Six flux distincts doivent être traités, avec des durées et des responsables différents.
| Flux | Contenu | Souvent oublié |
| Requêtes des utilisateurs | Le texte saisi, les fichiers joints | Non |
| Réponses produites | Le texte généré, les sources citées | Non |
| Documents indexés | Les copies de fichiers versées dans une base de connaissance | Parfois |
| Représentations vectorielles | Les vecteurs et fragments de texte dérivés des documents | Oui |
| Journaux techniques | Horodatage, identifiant utilisateur, modèle appelé, jetons consommés, erreurs | Oui |
| Jeux d'évaluation | Échantillons conservés pour mesurer la qualité ou spécialiser un modèle | Oui |
Les trois derniers sont les plus problématiques. Les représentations vectorielles, parce qu'elles survivent à la suppression du document d'origine si la purge n'est pas propagée : un fragment de texte reste alors récupérable dans l'index alors que le fichier source a disparu. Les journaux, parce qu'ils sont créés par défaut avec des rétentions généreuses. Les jeux d'évaluation, parce qu'ils sont constitués par copie manuelle, souvent hors de tout dispositif.
Conservation des données IA : fixer des durées défendables
Une durée de conservation ne se choisit pas au doigt mouillé : elle se justifie par une finalité. La logique attendue repose sur trois temps successifs, qu'il faut nommer explicitement dans le document.
- La base active : la donnée est utilisée au quotidien, accessible aux personnes qui en ont besoin.
- L'archivage intermédiaire : la donnée n'est plus utilisée couramment mais doit être conservée pour un motif précis, contentieux possible ou obligation légale. Accès restreint à un cercle limité.
- La suppression ou l'anonymisation : la donnée disparaît, ou perd tout caractère identifiant de façon irréversible.
Voici des durées qui se défendent pour un usage bureautique interne, à ajuster selon le secteur et les obligations propres à l'organisation.
| Flux | Base active | Archivage | Justification |
| Requêtes et réponses | 30 à 90 jours | Aucun par défaut | Confort d'usage, reprise d'un travail en cours |
| Documents indexés | Durée de vie du document source | Selon la politique documentaire | La copie ne survit pas à l'original |
| Représentations vectorielles | Alignée sur le document source | Aucun | Donnée dérivée, sans finalité autonome |
| Journaux techniques nominatifs | 6 mois | 12 mois si incident de sécurité | Détection d'usage anormal, sécurité |
| Journaux agrégés sans identifiant | Illimitée | Sans objet | Statistiques, pas de données personnelles |
| Jeux d'évaluation | Durée du projet | Aucun | À constituer sur données anonymisées |
Deux règles simplifient beaucoup la rédaction. D'abord, une donnée dérivée ne peut pas vivre plus longtemps que la donnée dont elle est issue. Ensuite, tout ce qui peut être agrégé ou anonymisé sort du champ et devient conservable sans limite, ce qui résout la plupart des besoins statistiques. La méthode de préparation correspondante est décrite dans notre article sur l'anonymisation des données avant leur envoi à un outil d'IA.
Le conflit entre exigence d'audit et minimisation
C'est le désaccord récurrent, et il est légitime des deux côtés. Le responsable de la conformité veut pouvoir reconstituer une décision assistée par IA plusieurs mois après, pour répondre à une réclamation ou à un contrôle. Le délégué à la protection des données veut que les historiques ne traînent pas.
La sortie ne consiste pas à arbitrer entre les deux, mais à séparer deux objets qu'on confond.
- Le journal d'audit conserve, sur longue durée, ce qui permet de reconstituer le déroulement : date, utilisateur, action, version du modèle et de la consigne, empreinte du contenu traité, décision humaine finale. Il ne contient pas le texte lui-même.
- L'historique de contenu conserve les textes échangés, sur courte durée, pour le confort d'usage.
Avec cette séparation, on peut prouver qu'une décision a été prise à telle date, sur la base de telle version de tel système, avec quel contrôle humain, sans conserver pendant trois ans le contenu intégral des échanges. L'empreinte cryptographique du contenu permet même de vérifier, si le document existe encore par ailleurs, qu'il s'agit bien de celui qui a été traité. Cette architecture est développée dans notre article sur la traçabilité des décisions prises avec l'IA.
Une nuance à ne pas oublier : lorsque la conservation répond à une obligation légale précise, dans le secteur bancaire ou en matière de facturation par exemple, cette obligation prime et doit être citée nommément dans la politique. C'est ce qui distingue une durée justifiée d'une durée confortable.
Faire respecter les durées avec des purges automatiques
Une politique sans mécanisme d'exécution est une intention. La purge doit être une tâche technique, planifiée, journalisée, et vérifiée. Cinq points de mise en œuvre.
- Une date d'expiration portée par la donnée. Chaque enregistrement porte sa date de création et sa durée applicable. La purge devient une requête simple, indépendante du code applicatif.
- Une tâche quotidienne, pas mensuelle. Une purge quotidienne fait disparaître peu de volume à chaque passage, donc échoue rarement et se rattrape facilement. Une purge mensuelle massive finit par dépasser sa fenêtre d'exécution et par être désactivée.
- La propagation aux données dérivées. La suppression d'un document doit déclencher celle de ses fragments et de ses vecteurs dans l'index, ainsi que celle des copies en cache. C'est le point technique le plus souvent manqué : testez-le explicitement.
- Les sauvegardes ont leur propre horloge. Une donnée purgée en base reste présente dans les sauvegardes jusqu'à l'expiration de leur rétention. C'est admis, à condition que la rétention des sauvegardes soit bornée et documentée, et que la donnée ne soit pas réintroduite en cas de restauration.
- Une trace de la purge. Nombre d'enregistrements supprimés par flux, date, durée d'exécution. Sans cette trace, vous ne pouvez pas démontrer que la politique est appliquée, et une purge qui s'est arrêtée passera inaperçue pendant des mois.
Ajoutez une alerte sur l'absence de purge : si la tâche n'a pas signalé sa réussite depuis 48 heures, quelqu'un doit être prévenu. C'est le même réflexe que pour toute automatisation de fond.
Ce que doit contenir le document
Une politique de conservation utile tient en deux pages. Au-delà, elle n'est pas lue, et une politique non lue n'est pas appliquée. Sa structure :
- Périmètre : les outils d'IA concernés, nommément, y compris les fonctionnalités intégrées dans des logiciels métiers.
- Tableau des durées : un flux par ligne, avec base active, archivage, sort final et justification en une phrase.
- Responsables : qui décide d'une durée, qui exploite la purge, qui contrôle qu'elle tourne.
- Traitement des demandes d'effacement : comment on retrouve et supprime les données d'une personne dans les six flux, avec un délai cible.
- Fournisseurs tiers : ce que chaque prestataire conserve de son côté, sous quelle durée, et où c'est écrit dans le contrat. Cette ligne est souvent la plus révélatrice.
- Révision : date de dernière mise à jour et fréquence de relecture, une fois par an au minimum.
Le point sur les fournisseurs mérite un mot. Beaucoup d'offres professionnelles annoncent une conservation limitée à quelques dizaines de jours pour la surveillance des abus, et l'absence d'entraînement sur les données clients. Ces engagements varient d'un contrat et d'une formule à l'autre : ils se vérifient dans les conditions applicables à votre abonnement, pas dans une page marketing. Notre article sur le RGPD et l'IA en entreprise détaille les clauses à examiner.
Par où commencer
Une politique de conservation des données IA se construit en trois séances de travail. La première fait l'inventaire des six flux pour chaque outil en service, et se termine presque toujours par une surprise sur les journaux ou les index vectoriels. La deuxième fixe les durées et écrit la justification en une phrase par ligne. La troisième branche les purges et l'alerte associée.
Le premier réflexe à adopter, avant même d'écrire quoi que ce soit : ouvrir la console d'administration de votre principal outil d'IA et regarder la durée de conservation configurée par défaut. Dans la majorité des cas, elle est illimitée, parce que personne n'a jamais eu à la choisir. C'est le point de départ de toute la démarche.
Laisser un commentaire