systemd ajoute un champ facultatif « birthDate » pour la vérification de l'âge aux enregistrements utilisateur
systemd ajoute un champ facultatif « birthDate » pour la vérification de l'âge aux enregistrements utilisateur JSON,
une situation qui a divisé l'écosystème et conduit à un fork de protestation
En fusionnant discrètement une requête de contribution qui ajoute un champ optionnel de date de naissance à ses enregistrements utilisateurs JSON, systemd s'est retrouvé en quelques jours au cœur d'une tempête communautaire. Entre lois californiennes sur la vérification d'âge, refus catégoriques de distributions alternatives et apparition d'un fork protestataire baptisé « Liberated systemd », l'écosystème Linux affronte une question qui dépasse largement la technique : jusqu'où un gestionnaire d'initialisation peut-il s'immiscer dans la gestion de l'identité numérique de ses utilisateurs ?
Le 18 mars 2026, le projet systemd a intégré dans sa branche principale la requête de contribution n° 40954. Techniquement, le changement est minimaliste : il ajoute un champ birthDate au format YYYY-MM-DD dans les enregistrements utilisateurs JSON gérés par le composant userdb. Ce champ rejoint des métadonnées qui existent déjà dans ce même fichier (realName, emailAddress, location) et ne peut être renseigné que par un administrateur, jamais par l'utilisateur lui-même.
Lennart Poettering, le créateur de systemd qui a récemment quitté Microsoft pour cofonder une entreprise orientée sécurité Linux, s'est empressé de contextualiser la démarche. Il a précisé que ce changement constitue « un champ optionnel dans l'objet JSON userdb », qu'il ne s'agit « pas d'un moteur de politique, pas d'une API pour les applications » et que systemd se contente de définir le champ pour le standardiser si quelqu'un souhaite y stocker la date, sans en faire une obligation. En d'autres termes, systemd jouerait uniquement le rôle de fournisseur de données en arrière-plan, les décisions de contrôle d'accès restant entièrement à la charge d'autres composants du système.
Cette mise au point n'a convaincu qu'une partie de l'assistance. Une requête de contribution demandant l'annulation pure et simple de la modification a été soumise dans la foulée et rejetée par Poettering lui-même. La discussion a été verrouillée après plus de 945 commentaires, un record qui illustre l'intensité des passions soulevées.
Le contexte législatif : Californie, Colorado, Brésil
Pour comprendre l'origine du changement, il faut se tourner vers plusieurs législations récentes. La loi californienne AB-1043 entrera en vigueur le 1er janvier 2027, tandis que la loi brésilienne Lei 15.211 est effective depuis le 17 mars 2026 ; le Colorado a de son côté adopté le texte SB26-051. Ces textes imposent à certains services en ligne et plateformes de distribution d'applications de disposer de mécanismes de vérification de l'âge de leurs utilisateurs.
La mention explicite de ces trois législations dans le message de la requête de contribution a été le premier détonateur. Les détracteurs y ont lu non pas une standardisation neutre, mais une capitulation préventive face à des gouvernements qui, selon eux, n'ont pas à dicter l'architecture interne d'un système d'exploitation libre.
Des voix plus nuancées soulignent que les distributions Linux commerciales, celles qui vendent des contrats de support aux entreprises, ne peuvent pas simplement ignorer ces obligations légales comme le feraient des projets bénévoles hébergés sur un serveur dans un pays tiers. Le dilemme est réel : un développeur indépendant témoignant sur un forum spécialisé a résumé la situation en expliquant que ses distributions personnalisées seraient contraintes de fermer en décembre 2026, faute de ressources pour bloquer géographiquement les États concernés ou pour se défendre lors d'un éventuel procès.
L'architecture technique : une pile à deux étages
Pour saisir ce que cette modification implique réellement, il faut comprendre comment elle s'inscrit dans un ensemble plus large. systemd agit uniquement en tant que fournisseur de données en arrière-plan : en stockant une date de naissance cohérente au niveau du système, il permet aux composants de plus haut niveau (portails ou services de comptes) de prendre des décisions liées à l'âge sans que chaque application ait à implémenter sa propre logique ou son propre stockage.
Le maillon supérieur de cette architecture est xdg-desktop-portal, l'interface standardisée qui permet aux applications confinées dans des environnements Flatpak d'interroger le système hôte de façon contrôlée. Les applications ne sont pas censées accéder directement aux données sensibles de l'utilisateur ; elles formulent des requêtes via une interface contrôlée, et le portail ne retourne qu'une réponse limitée (par exemple une tranche d'âge ou une décision d'autorisation/refus) plutôt que la date de naissance effective.
Une proposition antérieure, soumise directement aux spécifications XDG gérées par freedesktop.org, avait suggéré d'ajouter une interface D-Bus nommée org.freedesktop.AgeVerification permettant aux applications d'interroger directement le système d'exploitation pour une tranche d'âge. Cette proposition a été abandonnée après de fortes réactions de la communauté. Son auteur, Aaron Rainbolt, recommande désormais l'approche via xdg-desktop-portal comme voie à suivre.
La réaction de l'écosystème : du refus catégorique au fork protestataire
La fracture au sein de l'écosystème Linux s'est cristallisée avec rapidité et vigueur. D'un côté, des distributions qui ignorent le champ ou ne le considèrent pas comme un problème fondamental. De l'autre, plusieurs projets qui ont adopté des postures de refus explicites et parfois spectaculaires.
GrapheneOS, le fork d'Android axé sur la vie privée, a déclaré qu'il resterait utilisable par n'importe qui dans le monde sans exiger d'informations personnelles, d'identification ou de compte ; si cela empêche la vente de ses appareils dans certaines régions en raison de leur législation, « qu'il en soit ainsi ». À l'autre extrême du spectre, un projet (dont la description sur le site de suivi Ageless Linux le qualifie de « manifestement non conforme ») a choisi de livrer avec sa distribution une notice de refus lisible par machine, sans fournir aucune interface de collecte d'âge ni aucune API de tranche d'âge, et prévoyant même de distribuer des appareils physiques à des enfants lors de foires scolaires STEM.
L'épisode le plus symbolique est sans doute l'apparition de « Liberated systemd », un fork lancé par Jeffrey Seathrún Sardina, chercheur en apprentissage automatique. Le projet est explicite sur sa raison d'être : retirer ce qu'il considère comme du code facilitant la surveillance tout en conservant le reste intact, et rester synchronisé avec le projet principal au fil du temps. Comparé à systemd d'origine, le fork modifie douze fichiers répartis sur cinq contributions, supprimant non seulement le champ lui-même mais aussi la possibilité de définir une date de naissance via homectl, les entrées correspondantes dans les pages de manuel, le code d'affichage et les tests. Le projet reste pour l'instant une initiative individuelle, avec des dizaines de contributions de retard sur le code amont, ce qui en limite l'usage en production.
La question de fond : les choix techniques sont des choix politiques
Le débat dépasse rapidement la question du champ birthDate pour toucher à la trajectoire générale de systemd. Des commentateurs pointent que le gestionnaire d'initialisation s'est au fil des années étendu bien au-delà de son périmètre d'origine : journalisation binaire, gestion réseau via systemd-networkd, montage de systèmes de fichiers, authentification des utilisateurs, et désormais gestion des métadonnées d'identité. Chacune de ces extensions a été présentée comme optionnelle et modulaire au moment de son introduction.
Un commentateur de Slashdot a résumé la position critique avec une formule acérée : « Les choix techniques sont des choix politiques. On ne peut pas y échapper. » Cette tension est au cœur du débat : fournir l'infrastructure pour une politique, c'est déjà orienter la politique possible. Un autre angle d'attaque, soulevé dans les discussions de la même plateforme, touche à la protection des données personnelles aux États-Unis. Une étude citée dans les échanges rappelle qu'une combinaison de sexe, code postal et date de naissance complète permet d'identifier 87 % des citoyens américains. Stocker une date de naissance dans un enregistrement utilisateur JSON, accessible sans droits particuliers aux applications qui partagent cet espace, crée mécaniquement une surface d'exposition supplémentaire et ce même si systemd lui-même ne fait rien de cette donnée.
La loi fédérale américaine sur la vie privée de 1974 (Privacy Act) est également invoquée : si des États fédérés contraignent de facto chaque système d'exploitation à collecter et à transmettre des informations personnelles via des intermédiaires, cela pourrait entrer en contradiction avec les principes fédéraux de protection des données, voire ouvrir la voie à des contentieux.
Un précédent pour l'ensemble de la chaîne logicielle
Ce qui se joue autour de systemd est un cas d'école pour l'ensemble de la chaîne logicielle libre. Lorsqu'une loi de protection des mineurs oblige les plateformes de distribution d'applications à vérifier l'âge, la pression remonte naturellement vers les couches inférieures : système d'exploitation, gestionnaire d'identité, magasin d'applications, navigateur. Chaque maillon de la chaîne peut soit mettre en œuvre un mécanisme, soit refuser et laisser la contrainte se reporter sur le maillon suivant.
Le fait que GNOME renforce sa dépendance à userdb (la brique systemd qui accueille le nouveau champ) dans ses prochaines versions renforce le sentiment que l'infrastructure se met progressivement en place, indépendamment de toute obligation immédiate. Les distributions basées sur GNOME et systemd se retrouveront techniquement équipées pour répondre aux exigences légales bien avant que ces exigences ne leur soient formellement opposables.
Pour les distributions sans systemd (Devuan, Artix, Void Linux, et bien d'autres), la question ne se pose pas dans les mêmes termes : le champ birthDate n'existe tout simplement pas dans leur architecture. Ce clivage pourrait à terme redessiner les préférences des utilisateurs et des organisations les plus soucieux de souveraineté sur leurs données.
Source : GitHub
Et vous ?
La distinction entre « fournir l'infrastructure » et « appliquer une politique » vous semble-t-elle tenable sur le long terme, ou l'existence d'un mécanisme standardisé rend-elle son activation future quasi inévitable ?
Répondre avec citation
Partager