Je vous présente Tenzu, un logiciel libre de gestion de projets qui propose des tableaux Kanban en ligne collaboratif. Tenzu veut offrir une expérience de collaboration moderne, tout en restant léger à faire tourner et à utiliser.

Tenzu est sous licence AGPLv3 et n'est pas open core. Nous fournissons des recettes de déploiement sous Docker-compose et Kubernetes. Nous avons également un SaaS dont les revenus reposent sur la contribution libre.

L'équipe derrière Tenzu est une petite coopérative française nommée Biru (bonjour !).

Tenzu, anciennement connu sous le nom de Taiga-Next, est le successeur de Taiga. L'objectif derrière Taiga a été d'encourager les bonnes pratiques dans la mise en place de l'agilité au sein d'une équipe tout en restant facile à prendre en main. Tenzu reprend cette philosophie avec un outil plus moderne, qui permet par exemple l'édition collaborative en temps réel.

Dans cette dépêche, nous allons revenir plus en détail sur ce que fait Tenzu à l'heure actuelle, la stack technique, la genèse du projet ainsi que nos plans pour la suite.

Sommaire

• Tenzu, c'est quoi ?
  • Description
  • Stack technique et licence
  • L'équipe
• Comment le projet est né
  • L’héritier de Taiga
  • Reprise de Taiga Next
  • Nouveau nom et transmission
  • Transformation de la boîte et démarrage
  • Modèle financier
• Hier, aujourd'hui et demain
  • Première version
  • Améliorations apportées en 2026
  • Roadmap

Tenzu, c'est quoi ?

Description

Tenzu est actuellement une alternative à Trello. Cet outil permet d'organiser son travail, de répartir les tâches et d'en faire le suivi.

Les fonctionnalités disponibles sont :

• Espaces de travail : le logiciel s'organise autour d'un découpage par espace de travail puis par projet
• Kanban : Créez vos tableaux kanban avec des statuts personnalisables
• Cartes : une interface d'édition de cartes (appelé "story" pour l'instant) riche avec édition collaborative temps réel, commentaires, pièces jointes, commentaires, et plus à venir rapidement !
• Un thème sombre et trois langues (français, anglais, espagnol) sont disponibles
• Tout ce qui relève des cycles de développement (type SCRUM) est encore en spécification, nous sommes preneurs de testeurs motivés !

Stack technique et licence

Tenzu est une application web SPA, écrite en Angular et Django. Elle utilise django-ninja pour construire l’API et, pour ajouter de la réactivité temps-réel, nous utilisons django-channels à base de Redis et de websockets. La base de données utilisée est en PostgreSQL et l’API REST est entièrement documentée sous le standard OpenAPI.

Concernant le déploiement, l’environnement de développement tourne sous Docker et des recettes docker-compose ainsi qu’un helm-chart pour les environnements Kubernetes sont fournis par l’équipe dans la doc technique. Le helm-chart proposé est également celui utilisé pour le déploiement du SaaS officiel.

L’intégralité du logiciel est sous licence AGPL v3 et garanti sans open core. Pour l’instant nous ne sommes pas ouverts aux contributions de code, faute de ressources qui nous permettraient de mettre en place et d’encadrer une politique de contribution claire. Le fork reste évidemment possible et l’ouverture aux contributions externes est un objectif que nous souhaitons atteindre dès lors que le projet aura un socle fonctionnel plus avancé.

L'équipe

Tenzu est développé par Biru, une coopérative française créée en 2024 est dont le développement de Tenzu est l'activité principale.

L'équipe est actuellement composée de trois personnes :

• Julie Rymer (c'est moi !), co-fondatrice et qui s'occupe principalement du développement backend ;
• Paul Guichon, co-fondateur qui s'occupe principalement du développement frontend et de l'administration système ;
• Marie Jubault-Bregler, associée et notre précieuse Product Designer.

L'équipe au complet qui expose pour la première fois en 2026

Comment le projet est né

L’héritier de Taiga

BIRU, l’entreprise derrière Tenzu, était au départ une ESN (Entreprise de Services du Numérique) qui faisait du développement à la demande d'applications web. En accord avec leurs convictions personnelles, Julie et Paul ont choisi de fonder Biru sous la forme d’une SCOP, une coopérative où chaque membre peut participer aux décisions stratégiques et où les bénéfices sont répartis équitablement. Très engagés dans le libre et l'opensource, l'objectif de Paul et Julie (les fondateurs) était, à terme, de pouvoir reverser une partie de leurs bénéfices à tous les outils libres qu'ils utilisent au quotidien au sein de l'entreprise et de transitionner dès que possible pour devenir eux-mêmes éditeurs opensource, en lieu et place de leur activité d'ESN.
Tenzu est d’abord né d’un projet interne visant à servir de bac à sable didactique à une nouvelle recrue sur les technologies de l'entreprise : Django et Angular. Le projet choisi était la réécriture du frontend de Taiga 6.

Taiga est un logiciel libre de gestion de projets pensé pour être léger, facile à prendre en main et encourageant les bonnes pratiques dans la mise en place de l'agilité au sein d'une équipe. Julie et Paul sont des utilisateurs de Taiga de longue date, notamment Paul, qui a commencé à le déployer dans son équipe dès sa sortie en 2014. Taiga, dans sa version 6 actuelle, est toujours maintenu par une entreprise qui en assure le support technique, mais n'évolue plus depuis des années. La stack technique, composée de Django 3 et d’AngularJS en CoffeeScript, est vieillissante, très difficilement reprenable, et cela se ressent de plus en plus sur le produit.

Quelques années plus tôt, l’équipe de Kaleidos, auteurs originels de Taiga, avait déjà commencé une réécriture, sous la forme du projet nommé Taiga Next. Plus moderne, repensée grâce à l'expérience de leur premier logiciel et avec un fort accent mis sur l'accessibilité, Taiga Next a suscité l'engouement de la communauté Taiga dont nous faisions partie.
Taiga Next était malheureusement resté au stade de pré-alpha depuis juillet 2023, et la communication se faisait absente depuis.

Le logo de Biru embraçant celui de Taiga Next

Reprise de Taiga Next

Au bout de quelques mois, le 19 avril 2024, notre propre projet de réécriture a bien avancé et nous décidons de contacter Kaleidos pour leur présenter notre travail et vérifier auprès d'eux qu'une future communication de notre part à son sujet ne les embêterait pas. Ils nous répondent rapidement pour nous apprendre qu'ils sont activement à la recherche de repreneurs pour Taiga Next.

Nous obtenons à ce moment là une confirmation de la raison de l’arrêt de l’activité sur Taiga Next : à peu près en même temps que celui-ci, Kaleidos se lance sur Penpot, un concurrent libre de Figma pensé pour permettre une collaboration sans heurt entre développeurs et designers. En plus d'offrir une alternative opensource, Penpot résout un véritable besoin non satisfait sur le marché et le projet décolle, avec des levées de fonds à la clé. Kaleidos doit se rendre à l'évidence : il leur est impossible de continuer à travailler sur les deux projets à la fois.

Le 5 juin 2024, après avoir longuement étudié la question, nous candidatons publiquement à la reprise du projet. Fin juillet cette candidature est validée et nous commençons à travailler à temps plein dessus. La transition d'ESN à éditeur opensource est arrivée bien plus vite que prévu, pour notre plus grand bonheur.

Nouveau nom et transmission

Plusieurs échanges permettent à l’équipe espagnole de confirmer que nous partageons ses idéaux. Nos deux entreprises tiennent à ce que Taiga Next reste opensource, inclusif et simple d'utilisation. Kaleidos (d'ailleurs également une ancienne ESN devenue éditrice opensource) nous cède la propriété intellectuelle sur le code de Taiga Next, nous accorde un financement pour démarrer le projet (100 000€) et nous accompagne dans la reprise. Cette générosité totalement désintéressée a fait hausser les sourcils de plus d'une personne à qui nous l'avons comté, à commencer par notre comptable et notre avocate !

Cette reprise s'accompagne d'un changement de nom et d'identité graphique afin de ne pas empiéter sur Taiga. Taiga Next devient alors Tenzu (après un bref détour par MotherShip/MotherSheep dont nous avons conservée l'idée pour le logo), en référence aux kanjis japonais 天図 qui signifient individuellement "carte" + "céleste". (Anecdote : BIRU vient lui du mot japonais ビール, bière). Ces mots reflètent notre ambition de construire un logiciel qui pourra guider naturellement ses utilisateurs.

Taiga Next devient Tenzu

Transformation de la boîte et démarrage

Ce changement entraîne aussi un renouvellement de l'équipe. En effet, l’entreprise quitte le modèle économique de l'ESN, c'est-à-dire la vente de prestations informatiques et technologiques, pour transitionner vers un fonctionnement type "startup" où l’équipe fabrique un produit et qui implique des profils de “builders”. La prise de risque et l’incertitude associées à ce changement ne conviennent pas à tous les caractères ni à toutes les situations de vie. Nous étions six dans l'équipe à ce moment-là ; nous sommes redescendus à trois dans les mois qui ont suivi pour arriver à l'équipe actuelle.

Modèle financier

Le modèle financier de Tenzu repose sur plusieurs offres :

1. Nous mettons à disposition un SaaS rémunéré par la contribution libre : chacun décide du montant qu’il ou elle souhaite nous reverser, y compris zéro. Ce modèle permet à chacun de participer à la hauteur de ses moyens et selon son utilisation de l'outil, sans engagement respectif.
2. Nous travaillons également avec des partenaires qui proposent du support, de l’hébergement, de l'infogérance ou encore de la formation pour celles et ceux qui voudraient être accompagnés dans leur utilisation de Tenzu.

Aujourd’hui encore, nos revenus viennent uniquement des contributions et des subventions reçues pour ce projet.
Tenzu n'est pas gratuit, d'ailleurs aucun projet opensource ne l'est, mais nous avons choisi un modèle de financement qui convient à nos valeurs et nos ambitions.

Hier, aujourd'hui et demain

Première version

Notre ambition est claire : nous allons reprendre les fonctionnalités principales de Taiga en les améliorant en termes d’interface et d’expérience utilisateur, tout en conservant sa légèreté et sa simplicité. Nous avons pour objectif d’atteindre le plus rapidement possible un nombre d’utilisateurs qui nous permette de vivre de notre travail.

Nous sommes repartis de la dernière version de Taiga Next. Nous avons conservé en grande partie le backend existant mais avons dû repartir de zéro pour le frontend.

Le 30 octobre 2024, la première bêta de Tenzu sort sous la forme d'une démo en ligne, avec la mise à disposition de son code source. Nous y avons intégré les fonctionnalités cœur du logiciel : le multi-Kanban, les stories et les espaces de travail.
Le 4 mars 2025, nous sortons la documentation avec des recettes et toutes les explications nécessaires pour faire tourner Tenzu chez soi.

Le 30 septembre 2025, exactement 11 mois après la sortie de la démo, la première version stable de Tenzu sort. L’intégration du SSO ainsi que l’ajout de commentaires arrivera très vite par la suite.
Notre SaaS sera hébergé par IndieHosters, une autre coopérative impliquée dans le libre, rencontrée via le réseau Libre Entreprise et qui a choisi de participer à l'aventure.

Améliorations apportées en 2026

De gros chantiers ont été finalisés en 2026, à commencer par l’écriture collaborative.
L’éditeur existant n’a pas changé en apparence, mais désormais, lorsque deux personnes ouvrent en même temps une même story, elles voient l’avatar de l’autre apparaître et un curseur individuel dans le champ de description leur permet de suivre en temps réel toutes les modifications apportées.

Puis est arrivée la possibilité d’importer vos projets depuis Taiga. Vous pouvez désormais récupérer vos projets et leurs rôles, ainsi que le contenu de vos Kanbans avec vos statuts, stories, commentaires et pièces jointes, ainsi que réinviter automatiquement vos utilisateurs !

Un fil d'actualité a également été ajouté pour permettre d’annoncer les nouvelles versions, les maintenances et poser d’éventuelles questions aux utilisateurs.
Le design system a été complètement revu, du point de vue de l’interface comme de la technique, pour apporter plus de simplicité et d’accessibilité. C’est un premier pas vers un système de configuration dynamique du thème qui permettra aux utilisateurs de personnaliser leur expérience.

Enfin, nous avons très récemment ajouté un système de tags afin d’enrichir et catégoriser vos stories.

Roadmap

Nous continuons de travailler sur plusieurs chantiers :

• Permettre l’ajout de davantage de méta-informations sur les stories ;
• La mise en place d’une barre de recherche et de filtres ;
• La traduction communautaire, pour ajouter de nouvelles langues ;
• L’exportation de vos données au format JSON.

Et rapidement nous allons mettre en place les cycles de développement de type SCRUM, le deuxième module majeur de Taiga et celui qui lui a permis de conquérir le cœur de ses utilisateurs face à la concurrence.

Tenzu a bientôt deux ans et nous continuons de le faire évoluer avec passion. Ancien utilisateurs de Taiga aguerris ou nouveaux venus, nous vous souhaitons la bienvenue à la découverte de notre aventure.

Nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions Eyrolles, ENI et D-Booker. Voici les gagnants du mois de septembre 2026 :

• Minaucro pour sa dépêche Présentation de SlyOS, un système basé sur Arch linux équipé d'OpenRC, ReGreet et niri ;
• LaurentClaessens pour sa dépêche Le Frido 2026 est disponible ;
• cévhé pour son journal Devine mon mot de passe ;
• Thomas Debesse pour sa dépêche Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ?.

Les livres gagnés sont détaillés en seconde partie de la dépêche. N’oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

Les livres 📚 sélectionnés

• Rust — Développez des programmes robustes et sécurisés ;
• Git — Maîtrisez la gestion de vos versions — 5^e édition ;
• Linux — Préparation à la certification LPIC-1 (examens LPI 101 et LPI 102) — 7^e édition.

Certaines personnes n’ont pas pu être jointes ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’aux éditions Eyrolles, ENI et D-Booker.

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois de septembre passé.

• « Lassitude » par impromptux ;
• « ChienGPT lance ChienGPT Opel Astra, son premier modèle d’IA capable de se pirater tout seul » par dovik ;
• « Devine mon mot de passe » par cévhé ;
• « La folle histoire des noms de domaine internationalisés » par Faya ;
• « 25 ans de journaux Linuxfr dans mon flux RSS » par ploum ;
• « L'efficacité des LLMs pour la recherche de vulnérabilités, point de vue d'un mainteneur » par Samuel ;
• « Bloquer les bots avec Nginx de façon simple avec Nginx botcheck » par Framasky ;
• « Dis, journal, comment on demande à un LLM de faire de la pub pour un projet ? » par SpaceFox ;
• « Les IAs, nouveaux pirates informatiques ? » par 🚲 Tanguy Ortolo ;
• « Fuites de données, vous m'en direz tant » par guiv42.

Nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions Eyrolles, ENI et D-Booker. Voici les gagnants de l’été 2026 :

• frankrousseau pour sa dépêche 15 ans de projets libres : bilan ;
• Zatalyz pour son journal Comment bannir (presque) tout internet ;
• David Tschumperlé pour sa dépêche G’MIC 4.0 : La quadrature du pixel, plus facile que jamais ! ;
• gnumdk pour son journal Contribuer au noyau Linux, tu peux le faire!.

Les livres gagnés sont détaillés en seconde partie de la dépêche. N’oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

Les livres 📚 sélectionnés

• Design UI-UX — Concevoir sites et apps pour et avec les utilisateurs — 2^e édition ;
• Rust — Développez des programmes robustes et sécurisés.

Certaines personnes n’ont pas pu être jointes ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’aux éditions Eyrolles, ENI et D-Booker.

C’est la rentrée et avec elle son flot de nouveauté chez votre marchand de journaux préféré. Voici donc notre rituel petit panorama, forcément subjectif et parti{e,a}l, de la presse papier (et en ligne) disponible en cette rentrée.

Voici donc les nouveautés des éditions Diamond sorties en septembre et disponibles jusqu’à fin octobre, peu ou prou.

• GNU/Linux Magazine France n^o 283 construit et déploie ses propres agents IA avec du Python ;
• SysOps Pratique n^o 157 en a marre de Kubernetes et déploie avec Kamal ;
• MISC magazine n^o 147 sécurise les agents IA, l’angle mort du SOC ;
• Hackable n^o 68 propose une authentification facile sur WiFi avec du ESP32 ;
• MISC hors-série n^o 37 plonge bien profond dans les coulisses des Spywares (disponible jusque fin septembre).

Enfin, il y a aussi toute la clique des Linux Inside, Linux Reference, Linux Optimum, etc. si vous aimez les articles traduits automatiquement sans relecture apparente…

Bonnes lectures !

Les sommaires des numéros de septembre 2026

GNU/Linux Magazine numéro 283

Au sommaire de ce numéro de septembre — octobre 2026 :

• Le langage Python pour automatiser dans AWS ;
• Construire et déployer un agent IA autonome sur AWS avec Strands Agents SDK et Bedrock AgentCore ;
• Posython : l’Electron mode Python ;
• Retrocomputing : aux origines du C ;
• Améliorez votre conception avec l’inversion des dépendances ;
• Les codes fantastiques : changelog.

SysOps Pratique numéro 157 (ex Linux Pratique)

Au sommaire de ce numéro de septembre — octobre 2026 :

• Les agents autonomes auto-hébergés ;
• Le futur de la sauvegarde sort du projet Plakar ;
• Kamal : déployez vos applications sans la complexité de Kubernetes ;
• Automatiser le réseau avec Ansible ;
• Sécurisez les secrets de votre infrastructure et de vos applications avec OpenBao ;
• NFS et Kerberos, partie 3 : Kerberos en environnement dynamique.

MISC Magazine numéro 147

Au sommaire de ce numéro de septembre — octobre 2026 :

• Memory poisoning : quand l’agent IA devient l’angle mort du SOC ;
• iOS Predator : sous le capot ;
• CVE-2026-41089 : compromission d’un contrôleur de domaine par une simple requête réseau ;
• CVE-2025-14942 : défauts dans la machine à états de wolfSSH ;
• Automatisation SOC avancée : développer des modules Python pour une plateforme XDR ;
• France Identité : anatomie des justificatifs à usage unique ;
• GRC opérationnelle : une approche d’ingénierie pour mieux gérer son programme cyber.

Hackable numéro 68

Au sommaire de ce numéro de septembre — octobre 2026 :

• NVS : le stockage permanent sur ESP32 ;
• ESP-IDF WiFi Provisioner : une solution de provisioning simple compatible ESP-IDF 6.0 ;
• Lire vos tags RFID SRT512/ST25TB avec un ESP32 ;
• Zephyr RTOS : le système de choix pour une plateforme SoC LiteX ;
• Simulation de processus nucléaires au moyen de Geant4 : fluorescence X et détection de particules cosmiques.

MISC hors‑série numéro 37

Au sommaire de ce numéro hors-série d’août — septembre 2026 :

• Le Processus de Pall Mall : un effort diplomatique de régulation de l’industrie de la cyber-intrusion ;
• Introduction au dossier : Spyware ;
• Spyware à louer : l’industrie de la cybersurveillance entre normalisation et impunité ;
• Anatomie d’une compromission d’iPhone ;
• SpyGuard : détection de compromission d’ordiphone par analyse de flux réseau ;
• Analyse inforensique des logiciels espions sur Android ;
• Construction d’une infrastructure d’analyse d’appareils Apple ;
• Sécurité opérationnelle pour les petits budgets.

Le règlement (UE) 2024/2847, aussi appelé Cyber Resilience Act ou CRA, impose des exigences de cybersécurité à tout « produit comportant des éléments numériques » mis sur le marché de l’Union (logiciels compris, mais pas les services web). Son article 14 est entré en application le 11 septembre 2026. Tout fabricant doit signaler sous 24 heures toute vulnérabilité activement exploitée dans son produit et tout incident grave de sécurité, y compris pour les produits déjà sur le marché, puis compléter ce signalement sous 72 heures et le clore par un rapport final. Le reste du règlement s’applique à partir du 11 décembre 2027.

L’écosystème du libre s’était alarmé dès la proposition de 2022, et LinuxFr.org s’en était fait l’écho : le CRA menace l’avenir du logiciel libre, puis le texte du CRA a été finalisé. Le point d’achoppement était la notion d’« activité commerciale », dont dépend l’application du règlement. Le texte adopté en 2024, puis l'orientation de la Commission publiée le 27 juillet 2026, document interprétatif non contraignant, l’ont précisée dans un sens qui épargne les contributeurs individuels et les projets non monétisés.

Restent des chantiers ouverts : aucune norme harmonisée publiée à ce jour au Journal officiel, pas encore de mécanisme d’attestation de sécurité pour le logiciel libre, une plateforme de signalement sans API, et la question de qui paie les mainteneurs.

Sommaire

• Deux définitions du règlement
• Ce que l’écosystème a obtenu depuis 2023
• Les obligations vis-à-vis des mainteneurs
• Ce qui n’est pas prêt
• Qui paie les mainteneurs ?
• Prochaine manche : le règlement sur l’IA

Ce qui s’applique aujourd’hui

L’article 14 comporte deux déclencheurs : une vulnérabilité activement exploitée présente dans le produit, et un incident grave « ayant des répercussions sur la sécurité du produit », par exemple l’exécution d’un code malveillant dans le produit ou chez ses utilisateurs, qu’une faille ait été identifiée ou non. Chacun suffit. Les deux suivent la même cadence, au rapport final près :

• 24 heures : alerte précoce à l’ENISA (l’agence européenne de cybersécurité) et au CSIRT de son État membre (l’équipe publique de réponse aux incidents, CERT-FR pour la France), via la plateforme de signalement unique ;
• 72 heures : notification complémentaire, avec les éléments techniques et les mesures engagées ;
• rapport final : quatorze jours après la mise à disposition d’un correctif pour une vulnérabilité exploitée, un mois après la notification à 72 heures pour un incident grave.

Le texte apporte deux nuances. L’obligation de signaler s’impose à tous les fabricants, mais l’amende n’est pas la même pour tous (article 64(10)). Une microentreprise ou une petite entreprise qui dépasse les 24 heures n’est pas sanctionnée pour ce retard. Un intendant de logiciels ouverts (défini plus bas) n’encourt, lui, aucune amende, quel que soit le manquement. Enfin, l’article 14 vise les vulnérabilités « contenues dans » le produit : une faille exploitée dans une dépendance n’est à signaler que si le produit embarque le code vulnérable et que ce code y est effectivement atteignable. Une bibliothèque vulnérable dont le code fautif n’est jamais exécuté par le produit n’a pas à être signalée.

Côté outillage, la plateforme de l’ENISA ouvre aujourd’hui sans API : les signalements se saisissent à la main, en texte, dans une vingtaine de champs, et aucune pièce jointe n’est acceptée.

Deux définitions du règlement

Le texte français des articles et des annexes n’emploie pas une seule fois l’expression « open source ». Voici l’article 3, point 48) :

« logiciel libre et ouvert » : un logiciel dont le code source est partagé de manière ouverte et qui est mis à disposition sous licence libre et ouverte prévoyant tous les droits pour qu’il soit librement accessible, utilisable, modifiable et redistribuable ;

La définition pose deux conditions : une licence libre, et le partage ouvert du code source. Du code sous licence libre remis au seul client qui l’a commandé, sans publication, remplit la première condition et pas la seconde : il n’est pas « logiciel libre et ouvert » au sens du règlement. La FAQ officielle de la Commission le confirme pour le développement sur mesure : livrer à un client un logiciel écrit pour lui est une mise sur le marché, le prestataire qui le livre sous son propre nom en est le fabricant, sans aucun des allègements réservés au libre. Il peut seulement aménager par contrat deux des exigences essentielles de sécurité (question 4.2.5). La FAQ de l’ORC WG, le groupe de travail de la Fondation Eclipse qui suit le règlement pour l’écosystème du libre, ajoute, sur la base de l’orientation, qu’installer, configurer ou intégrer un logiciel existant pour un client reste une prestation de service.

L’article 3, point 14), crée une catégorie juridique inédite :

« intendant de logiciels ouverts » : une personne morale, autre que le fabricant, qui a pour objectif ou finalité de fournir un soutien systématique et continu au développement de produits spécifiques comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits ;

Le mot « steward » s’est imposé dans l’usage, y compris en français. Le statut est réservé aux personnes morales, sans condition de forme ni de but : une association loi de 1901, une fondation ou une société commerciale peuvent y prétendre. Le considérant 19 (les considérants forment l’exposé des motifs qui ouvre le règlement) vise expressément les entités qui développent et publient du logiciel libre dans un cadre professionnel. La FAQ de l’ORC WG répond sans détour qu’une société peut être intendante.

Reste le cas de la société qui est aussi fabricant, le plus courant chez les éditeurs. Les versions linguistiques y divergent. L’anglaise dit « a legal person, other than a manufacturer » : une personne morale qui n’est pas un fabricant, ce qui interdit d’être fabricant d’un produit et intendant d’un autre. La française dit « une personne morale, autre que le fabricant » : autre que le fabricant des produits soutenus, ce qui autorise le cumul en général mais l’interdit pour un même produit, précisément le cas courant de l’éditeur qui vend une édition de son logiciel et publie l’autre. Les vingt-quatre versions linguistiques ont la même valeur juridique. Sur ce point, elles ne disent pas la même chose. L’orientation de juillet 2026 va plus loin que l’une et l’autre : la même entité peut être fabricant de l’édition qu’elle monétise et intendante de l’édition communautaire du même logiciel. Tant mieux pour les éditeurs. Mais un document sans valeur contraignante accorde ainsi ce qu’aucune version du règlement ne dit. Sur le point le plus disputé du texte, le législateur a laissé deux versions qui se contredisent. L’édifice tient par une orientation que la Commission peut réviser.

Ce que l’écosystème a obtenu depuis 2023

Les contributions et les dons. Le considérant 18 exclut du règlement ceux qui contribuent à un logiciel qui « ne relève pas de leur responsabilité ». Un logiciel relève de la responsabilité de celui qui le publie et contrôle son développement, ses versions et sa distribution ; un accès en écriture au dépôt ne suffit pas. Un salarié qui envoie un correctif à un projet tiers pour le compte de son employeur reste un contributeur hors champ. Qui est payé pour le logiciel est fabricant ; qui est payé pour travailler sur le logiciel est prestataire, ou contributeur. Afficher un lien de don ne vaut pas intention de faire du profit ; les dons ne deviennent suspects que si l’ensemble des revenus du projet dépasse de loin ses coûts, dans lesquels entrent les frais de subsistance raisonnables du mainteneur.

L’intendant. L’article 24 lui impose trois choses : une politique de cybersécurité documentée et vérifiable, la coopération avec les autorités de surveillance du marché, et le signalement de l’article 14 dans la mesure où il participe au développement, si bien qu’un intendant purement financier ou juridique ne signale rien. Il le dispense de tout le reste : ni exigences essentielles de sécurité de l’annexe I, ni marquage CE, ni documentation technique, ni SBOM (l’inventaire des composants d’un produit), ni obligation de corriger. L’article 64(10)(b) l’exempte de toute amende.

Les modèles économiques. Le cas du bénévole isolé était pour l’essentiel acquis dès la proposition initiale de septembre 2022. La difficulté la plus sérieuse portait sur les éditeurs qui vendent de la maintenance sur ce qu’ils publient librement. C’est pour eux, plus que pour les bénévoles, que les associations professionnelles comme le CNLL ont bataillé. La réponse figure dans l’orientation, avec la fragilité relevée plus haut : les rôles s’apprécient logiciel par logiciel et activité par activité, y compris en open core (cas où l’édition payante étend la base de code de l’édition libre et ouverte). La condition est que les deux éditions soient réellement séparées : dépôts, artefacts et canaux distincts.

Les obligations vis-à-vis des mainteneurs

L’article 13(6) impose aux fabricants une obligation envers les mainteneurs des composants qu’ils intègrent. Le voici, deux renvois en moins :

Lorsqu’ils identifient une vulnérabilité dans un composant, y compris un composant logiciel ouvert, qui est intégré au produit comportant des éléments numériques, les fabricants signalent la vulnérabilité à la personne ou à l’entité qui assure la maintenance du composant […]. Lorsque les fabricants ont mis au point une modification logicielle ou matérielle pour remédier à la vulnérabilité de ce composant, ils partagent le code ou la documentation correspondants […], dans un format lisible par machine s’il y a lieu.

Le signalement est dû dans tous les cas. Le partage, lui, suppose que le fabricant ait effectivement développé une modification : s’il n’a rien écrit, il n’a rien à remettre. Et ce qu’il remet correspond à ce qu’il a fait, les deux « ou » de la phrase se répondant : le code pour une modification logicielle, la documentation pour une modification matérielle. L’orientation y ajoute des bornes : l’obligation ne porte que sur la version intégrée du composant et sur ses propres failles, elle s’exerce dans le respect de la politique de divulgation du projet, et elle tombe si le composant n’a plus de mainteneur. L’obligation ne dépend d’aucun lien contractuel entre le fabricant et le projet. Rien dans le règlement ne donne pour autant au mainteneur d’action propre pour l’exiger : la faire respecter revient aux autorités de surveillance du marché.

Ce qui n’est pas prêt

• Les normes harmonisées. Appliquer l’une d’elles vaut présomption de conformité : le fabricant est réputé satisfaire aux exigences qu’elle couvre, sans avoir à le démontrer autrement. Sur les 41 commandées aux trois organismes européens de normalisation (CEN, CENELEC, ETSI), aucune n’a encore été publiée au Journal officiel. Or l’article 27 ne fait naître la présomption qu’à cette publication. Trois projets sont en approbation (prEN 40000-1-1, -1-2, -1-3) ; le lot du catalogue d’exigences génériques a été mis en attente faute de contributeurs.
• Les attestations de sécurité du logiciel libre (article 25). Le règlement habilite la Commission à créer, par acte délégué (un texte d’application que la Commission adopte seule), des programmes volontaires d’attestation de sécurité pour le logiciel libre, afin de faciliter la vérification que les fabricants doivent faire des composants qu’ils intègrent, la « diligence raisonnable » de l’article 13, paragraphe 5. Le texte ne dit pas qui les financerait. L’ORC WG propose d’en faire le canal par lequel les fabricants paieraient les projets dont ils dépendent ; pour les projets libres, c’est l’absence la plus coûteuse. Aucun acte délégué n’a été publié ni planifié. En attendant, les référentiels de l’OpenSSF, la fondation de la Linux Foundation consacrée à la sécurité du logiciel libre, servent de justificatifs : Scorecard, Best Practices Badge, OSPS Baseline et SLSA.
• L’orientation elle-même. Elle n’existe qu’en anglais, n’a pas de valeur contraignante, et n’est pas encore formellement adoptée, faute des autres versions linguistiques. Tout ce que la section précédente lui attribue a la solidité d’une interprétation, que la Commission peut réviser et qu’un juge n’est pas tenu de suivre.
• Très peu de projets auront un intendant. Le rapport OSSRA 2025 de l’éditeur d’outils d’audit Black Duck, sur 965 bases de code commerciales auditées en 2024, y a dénombré 282 521 paquets JavaScript distincts. L’OpenJS Foundation héberge environ 35 projets. Un projet publie souvent plusieurs paquets, mais l’écart reste de plusieurs ordres de grandeur : la plupart des dépendances d’un produit n’auront ni fabricant ni intendant, et leur sécurité restera à la charge de qui les intègre.
• Le matériel libre. L’article 24 vise les logiciels : RISC-V International, l’OSHWA (Open Source Hardware Association) ou l’OpenHW Group ne peuvent pas prétendre au statut d’intendant.
• Les sanctions nationales. L’article 64 laisse aux États membres le soin de fixer le régime de sanctions, d’où des lois d’application nationales. Le règlement exempte les intendants de toute amende. Le projet de loi finlandais en prévoyait pourtant : le Parlement finlandais ne les a retirées qu’au printemps 2026.

Qui paie les mainteneurs ?

L'étude d’impact qui accompagnait la proposition de 2022 estimait qu’un cycle de développement sécurisé ajoute en moyenne 30,5 % au coût de développement d’un produit, pour un fabricant qui part de zéro : 42 700 € sur un produit moyen à 140 000 €. S’y ajoutent 9 % de coûts administratifs, documentation et signalement compris. C’est le « 30 % » que citait le CNLL en 2023. Aucune actualisation n’a été publiée depuis.

Le fabricant répercute ce surcoût sur son client, ou l’absorbe et cesse d’investir ailleurs. Le mainteneur n’a pas de client à qui le répercuter. Le travail lui arrive quand même. L’article 13(5) oblige le fabricant qui intègre un composant à en vérifier la sécurité ; beaucoup s’en acquittent en envoyant leurs questions au projet, sous forme de questionnaires de sécurité, de demandes de SBOM ou de délais de correction à confirmer. Hors champ du règlement, le mainteneur ne doit rien de tout cela. Rien n’oblige pour autant les fabricants à cesser : l’ORC WG en est réduit à plaider pour une « diligence respectueuse », qui ne traite pas un projet libre comme un fournisseur.

Le mécanisme d’attestation de l’article 25, seul canal de financement esquissé par le règlement, n’existe pas. La stratégie européenne pour l’open source du 3 juin 2026 annonce un « instrument de maintenance de l’open source », que l’écosystème réclamait sur le modèle du Sovereign Tech Fund allemand, sans budget ni calendrier.

Trois ans de mobilisation ont produit un règlement vivable pour le libre. Qui paie les mainteneurs dont il fait dépendre tout l’édifice, le texte ne le dit pas, et personne d’autre non plus, à ce stade.

Prochaine manche : le règlement sur l’IA

Le règlement sur l’intelligence artificielle exempte lui aussi les systèmes publiés sous licence libre (article 2, paragraphe 12), sauf s’ils sont mis sur le marché comme systèmes à haut risque. Or un système est classé à haut risque d’après l’usage auquel son fournisseur le destine. Le projet d’orientations publié par la Commission le 19 mai 2026 retient qu’un système présenté comme largement applicable, dont le fournisseur n’exclut pas de façon constante les usages à haut risque, est réputé les couvrir. Une simple déclaration, ajoute-t-il, ne suffit pas. Un composant d’IA publié en libre est mal armé pour ce test : son auteur ne maîtrise ni les usages ni les utilisateurs, et une licence qui restreindrait les champs d’application cesserait d’être libre (liberté 0 de la FSF, critère 6 de l'Open Source Definition). L’exemption s’évanouirait donc là où elle compte. Reste à savoir quel poids une autorité accordera aux limitations inscrites dans un README ou une fiche de modèle.

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège de deux dizaines de ces journaux (été oblige) parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux des mois de juillet et août passés.

Juillet 2026

• « Ce que la fin de Windows 10 change vraiment chez les particuliers: retour de terrain d'un dépanneur » par EtienneAubry72 ;
• « Gatemate A2 : Le FPGA européen avec une chaîne de dev complètement open-source » par martoni ;
• « Blog de Codeberg sur la protection des communs contre les LLMs » par wilk ;
• « Dévoilement de 6 mois d'enquête sur le numérique - Commission d'enquête » par wilk ;
• « Tracim sort en 2026.07 - plus d'efficacité, plus de projet » par LeBouquetin ;
• « Auto-héberger ses IA : Matériel et optimisation de l'inférence » par Jérôme Flesch ;
• « Je teste NetBSD : retour vers le passé » par devnewton 🍺 ;
• « Les journaux générés par IA » par fork_bomb ;
• « la folie continue, maintenant elle touche la CPAM » par mahikeulbody ;
• « Doctolib en opt-out pour utiliser mes données personnelles » par wilk.

Août 2026

• « Contribuer au noyau Linux, tu peux le faire! » par gnumdk ;
• « Comment bannir (presque) tout internet » par Zatalyz ;
• « uBlock Origin renonce à bloquer les publicités de Facebook » par tkr ;
• « Qui est le public de LibreOffice Base ? » par Élafru ;
• « Jujutsu v0.44.0 » par wilk ;
• « NVIDIA, l'OSI et la licence OpenMDW » par Misc ;
• « Le Littré libre a été porté sur Qt 5 en 2022 — et personne ne l'a su » par wouf ;
• « Auto-héberger ses LLM (IA) : Interfaces utilisateur » par Jérôme Flesch ;
• « Ce journal ne parlera pas d'Eclipse IDE » par octane ;
• « Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks » par Jérôme Flesch.