En février 2023, nous avions décrit « les données à caractère personnel traitées, qu’elles soient ou non associées à un compte, le cycle de vie de ses données et le changement de politique concernant ce cycle de vie. » La règle a été mise en place au 28 juin 2023 (la date de dernière activité du compte ayant été mise en place au 31 mai 2023) :
- les comptes inactifs pendant trois ans sont fermés et les données conservées inutiles au service supprimées ;
- les comptes fermés depuis plus d’un an voient les données associées inutiles au service supprimées (cf dépêche d'évaluation 1 an après en 2024)
Depuis trois ans, les comptes fermés (par la personne détenant le compte ou par l’équipe de modération sur les spams par exemple) voient donc leurs données minimisées. La nouveauté cette année était la fermeture des comptes inactifs depuis trois ans.
Quelques chiffres pour donner une idée de l’évolution des comptes
- un an, c’est 961 comptes ouverts (et 286 fermés depuis), entre le 01 octobre 2024 et le 30 septembre 2025 (basées sur les rétrospectives des quinzaines)
- un an, c’est aussi 1607 tentatives de création de comptes, sur la même période (basé sur les identifiants en base de données), dont beaucoup ne sont visiblement jamais confirmés et donc jamais réellement ouverts (spam, erreur d’adresse, erreur sur le pseudo voulu, etc.)
Application de la règle des 3 ans d’inactivité
Regardons les statistiques conservées par archive.org du 11 avril dernier, soit avant l’échéance des trois ans d’inactivité du 31 mai dernier :
- 53599 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
- 33150 comptes
- 1384 comptes fermés
Et comparons avec les statistiques au moment de l’écriture de la dépêche, en base de données on trouve :
- 38847 utilisatrices et utilisateurs ayant ou ayant eu des comptes (et encore présents en base de données)
- 18397 comptes
- 12380 comptes fermés
Il y a donc eu purge de plus de 14500 comptes et fermeture de plus de 10000 comptes au 31 mai 2026.
Pourquoi certains comptes sont purgés ? Car ils n’avaient aucun contenu public ou commentaire public ou contribution à des contenus publics. Il peut s’agir de personnes n’ayant jamais rien eu à dire sur le site, de spammeurs n’ayant jamais réussi à publier quoi que soit, etc. La volumétrie est aussi due au stock puisque le traitement s’est appliqué à tous les comptes concernés depuis 1999 (année du plus vieux compte en base de données).
Pourquoi certains comptes sont fermés ? Parce qu’ils restent associés un ou plusieurs contenus ou commentaires ou contributions publics. Les cas peuvent être multiples : la personne est décédée, la personne est passée à autre chose, la personne avait juste besoin de poser une question à un moment et n’est donc pas restée, la personne est depuis 3 ans en prison ou en orbite ou dans un sous-marin ou tout autre endroit hors-ligne, etc.
Conséquences techniques ?
Va-t-on réutiliser les identifiants libérés dans la base de données de comptes ? Il n’y a pas vraiment d’intérêt à le faire.
A-t-on gagné sur le volume des sauvegardes ? La table des versions de dépêches pèse ~9 GiB pour ~430000 tuples, celle des commentaires ~3 GiB pour 2M de commentaires. La table des comptes n’est que la 11e plus volumineuse en base, avec 18 MiB. Donc non on ne gagne rien de significatif. Probablement moins que si on supprimait dès maintenant les encore présents en base 700 contenus non publics et 21900 commentaires non publics.
Est-ce que tout le site va aller plus vite ? Non, ça ne va pas être perceptible sur les requêtes SQL.
Quel serait le cas le plus favorable en termes de réduction des données ? L’anonymisation du compte et de tout ce qui est associé : cela supprime un compte bien sûr, mais ça permettait en théorie de fusionner des éditions de dépêches par exemple : si Anonyme, seul compte contributeur, a 82 éditions d’une même dépêche, alors des années après, on peut sans doute se contenter de ne garder que la première et la dernière édition par exemple (pour préserver dates et attribution). Et même si Anonyme a seulement les éditions 53 à 57 d’une dépêche, on pourrait faire de même sur cette partie contiguë.
Aide sur le sujet
- Quelles sont les données à caractère personnel (DCP) traitées par le site ?
- Quelles sont les données sans caractère personnel relatives au compte traitées par le site ?
- Quelles sont les données inutiles au service qui sont supprimées des comptes fermés ?
P.S. : cette dépêche sera ma 500e dépêche publiée
# Dommage ;)
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
Normalement, c'est ce que je pense avoir compris, tous ces comptes, ça devrait être un argument de poids pour pouvoir peser sur tel ou tel (notamment lorsqu'il est avide de chiffres sans aucun fondements).
Merci pour le boulot :)
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Dommage ;)
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+11/-0). Dernière modification le 22 juin 2026 à 13:41.
Oui mais nous on vise le compte en bois flotté recyclé ouvragé main avec finition décorative par des petites mains éco-responsables et éthiques, plutôt que des grosses quantités industrielles de comptes dégoulinants et insaturés enrichis en bulles d'air et produits à distance par des esclaves numériques. Voilà, c'est pour ça en fait, me disait notre gestionnaire de communauté et néanmoins labellisé RSE.
« Les bons comptes font les bons admins. »
[^] # Re: Dommage ;)
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
Joli ;)
"Si tous les cons volaient, il ferait nuit" F. Dard
# petits commantiares
Posté par alpha_one_x86 (site web personnel) . Évalué à 2 (+0/-0).
Je trouve que c'est peu de comptes (je suis habitué à des volumétries bien plus importante). Si le but est de réduire les données du backup, pourquoi ne pas faire un système de hot/cold ou un backup différentiel qui ne sauvegarde que les différences (c'est ce qu'on applique au travail pour les clients)
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
[^] # Re: petits commantiares
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0).
Ce n'est pas le but. En premier, il y a le réglementaire/légal (cf https://linuxfr.org/news/regles-de-perennite-des-comptes-linuxfr-org-et-donnees-a-caractere-personnel#toc-obligations-et-base-l%C3%A9gale-des-traitements ). Ensuite viendrait le nettoyage du spam, l'économie de ressources, etc. Mais comme indiqué dans la dépêche, ce ne sont pas les comptes qui permettront de réduire la sauvegarde.
[^] # Re: petits commantiares
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+8/-0).
Ce ne sont donc pas les comptes qui… comptent?
[^] # Re: petits commantiares
Posté par vincent LECOQ (site web personnel) . Évalué à 3 (+1/-0).
Quand on aime on ne compte plus !
# Commentaire supprimé
Posté par DoloresSerrano . Évalué à 0 (+0/-0). Dernière modification le 22 juin 2026 à 17:25.
Ce commentaire a été supprimé par l’équipe de modération.
# pourquoi garder les versions de dépêches ?
Posté par orfenor . Évalué à 2 (+0/-0).
Simple curiosité sans critique :
Cf le titre. Est-ce une obligation légale ? Sinon je ne vois pas l'intérêt.
[^] # Re: pourquoi garder les versions de dépêches ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 22 juin 2026 à 20:09.
Actuellement c'est les versions de dépêches qui permettent
On a donc la question du droit d'auteur et de la paternité (qui a écrit quoi et quand), la question des éventuels litiges qui nécessiterait de savoir qui a écrit quoi et quand (diffamation, plagiat, etc.) et de façon plus annexe on pourrait avoir la question de la recherche et des archives (très limité car les anciennes versions de dépêches ne sont pas publiques).
On pourrait dire qu'une fois passée la période de contentieux, on considère que c'est une œuvre collective (indépendamment de savoir si Ada a écrit 83% du contenu, Bob 16% et Eve 1%, et quels % ont été écrit par qui), pour ne garder juste que "Ada, Bob, Eve" comme co-auteurs (actuellement en premier se trouve le compte sous lequel le contenu est publié, indépendamment de son rôle réel dans l'écriture).
On pourrait dire que si Ada a écrit les versions 13 à 17, on se fiche un peu des version 13 à 16 en fait, vu que la différence entre 12 et 17 nous dit ce qu'Ada a changé au final en cumulé, si on accepte que les dates des versions 13 à 16 sont sans importance (un contre-exemple serait un cas de plagiat à 1 jour près). Ce qui peut s'étendre au cas où Ada a écrit de la version 1 à la dernière, auquel cas on pourrait ne garder que la dernière (ou juste les deux extrêmes si nécessaires).
ça revient à dire que le cas le plus simple est "tout est écrit par Anonyme" ou "tout est écrit par Ada". Ensuite tout dépend si on considère que c'est une œuvre collective (le cas explicite est lorsque c'est publié sous le compte Collectif) ou un assemblage de modifications faites par des individus. Dans le premier cas, on pourrait ne conserver que l'info de qui a écrit quelque chose (la date et le quoi n'étant plus utiles). Dans le second cas, il faudrait théoriquement tout conserver. Après je me demande si les autres sites ayant des contenus collaboratifs générés par le lectorat s'embêtent réellement à tout garder indéfiniment. (j'ai pensé "sites" mais sur un livre papier ou numérique à plusieurs, je ne suis pas sûr que l'éditeur conserverait la liste de quelle ligne a été écrite par qui indéfiniment…)
(avant la version actuelle Ruby du code, une seule version d'une dépêche était stockée, mais elle n'était associée qu'à un seul compte. C'est la version Ruby de 2011 qui a amené l'édition collaborative et de nouvelles contraintes sur le stockage des versions)
[^] # Re: pourquoi garder les versions de dépêches ?
Posté par vpo . Évalué à 2 (+1/-0).
Sans aller jusqu'à gérer un système de patchs chaînés pour gérer les versions successives des dépêches, un stockage zippé de chaque version des dépêches si la version zippée est moins lourde que la version non zippée ne permettrait-il pas de gagner pas mal de place en base ?
[^] # Re: pourquoi garder les versions de dépêches ?
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 29 juin 2026 à 14:28.
Pour être complet (et parce que je ne sais pas vraiment où le mettre, entrée de suivi ?)
Outre les dépêches en rédaction, les contenus modifiables par un utilisateur identifié au site sont :
le tout étant modifiable par l'équipe de modération et d'admin.
# stats
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
et la version archivée des stats LinuxFr.org au 2026-06-22 est désormais disponible ;-)
(forcément, un compte a été créé entretemps…)
# Et concrètement ?
Posté par Perdu (site web personnel) . Évalué à 5 (+4/-0).
Hello,
Ça me pose plusieurs questions en pratique. Je suis LinuxFR au travers de son flux RSS mais ne poste et commente que très occasionnellement : je n'ai pas exemple rien commenté entre décembre 2022 et mai 2025. C'est presque 3 ans. J'ai donc des risques de perdre accidentellement mon compte.
Plusieurs questions donc :
- comment est défini un « compte inactif » ? La question est posée en commentaire dans la dépêche originale, pourtant la réponse n'est pas claire. Il semblerait que se connecter ne suffise pas à éviter de perdre son compte.
- Une option sera-t-elle mise en place pour déclarer qu'on veut éviter de se faire passer à la moulinette ?
[^] # Re: Et concrètement ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 23 juin 2026 à 16:45.
Il s'est avéré à l'époque que l'indicateur "updated_at" du compte n'était pas utilisable comme indicateur d'activité, et un "last_seen_on" a été ajouté ensuite (après la dépêche initiale donc) le 31 mai 2023 (cf https://linuxfr.org/suivi/pouvoir-determiner-si-un-compte-a-eu-de-l-activite-recemment et https://linuxfr.org/suivi/derniere-visite-affichage-et-stats et https://github.com/linuxfrorg/linuxfr.org/pull/376 ). Et il suffit de visiter le site en étant connecté pour qu'il soit mis à jour (y compris sans écrire).
Non, ça serait contraire à la législation au final (on ne doit pas garder indéfiniment des données personnelles). Et par ailleurs, il suffit de se connecter une fois tous les 3 ans pour ne pas être concerné.e.
[^] # Re: Et concrètement ?
Posté par Caeies . Évalué à 3 (+2/-0).
Est-ce qu'un mail d'avertissement est envoyé dans le cas d'une suppression sur absence de connexion (désolé si ça a déjà été dit).
Et oui j'ai le longues périodes d'absence de connexions, même si je surf en anonyme :).
Merci !
[^] # Re: Et concrètement ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Non il n'y a actuellement pas d'envoi d'avertissement.
[^] # Re: Et concrètement ?
Posté par Caeies . Évalué à 1 (+0/-0).
ok merci.
Pour éviter les spammeurs, peut être que le message d'avertissement pourrait ne concerner QUE les comptes ouverts avant …. disons 2010 (y avait déjà du spam à cette époque ?).
Bon je sais, faudrait que je contribue :).
(J'ai regardé, et ah oui je suis vieux … 2002 avec des gros trous de présences).
Bonne soirée bien fraîche !
[^] # Re: Et concrètement ?
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Tu es une grande personne, si tu surfes essentiellement sans te logger mais que tu ne veux pas perdre ton compte, mets un rappel récurrent dans ton agenda de te logger une fois par an et ton problème est résolu.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.