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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
