L'open source n'est pas une renonciation à la responsabilité
A repository is an opening, not an ending
There is a comforting little story about open source. A group publishes code. Other people can read it. The code becomes a common good, or at least a useful common nuisance. Responsibility dissolves into the crowd.
The first two sentences may be true. The last one is not. A public repository can widen inspection, reuse and contribution. It can give an organisation a clearer exit route than a closed service. It can allow a public body to examine a component without asking a supplier for permission. None of that answers the question that arrives on an ordinary Tuesday morning: which version is running here, under which licence, with which configuration, and who is going to act if the security advisory applies?
Open source changes the shape of responsibility. It does not make responsibility optional. The maintainer still has decisions to make about releases, security reports, supported versions and licensing. The organisation that packages a component still has decisions to make about provenance, updates and what it tells its users. The deployer still has decisions to make about inventory, exposure, configuration, access and recovery. A licence gives permissions and conditions. It does not provide an on-call rota.
This matters because open source has become ordinary infrastructure. It sits in operating systems, browsers, public services, research tooling, industrial systems and the libraries that make a product look more self-contained than it is. The mature question is therefore not whether an organisation is for or against open source. It is whether it can carry the responsibilities created by the software it chooses to depend on.
European policy has begun to describe that distinction more plainly. The Cyber Resilience Act regulates products with digital elements and includes a specific route for free and open-source software stewards. The route recognises that a person or organisation which provides sustained support for free and open-source software can occupy a real place in the security chain. It does not turn every volunteer who publishes code into a manufacturer. Equally, it does not allow a commercial actor to hide behind a public repository when that actor brings a product to market.
The practical consequence is pleasantly unromantic. Treat every dependency as something that must be named, understood and looked after. That is not an attack on open source. It is the discipline that lets open source remain useful when the novelty has gone.
What publication actually changes
Source availability changes several things at once. A reader can inspect the implementation rather than infer it from a marketing page. A team can reproduce a build if the build instructions, dependencies and environment permit it. A supplier can be replaced more readily when the licence and interfaces allow it. A researcher can test a claim, a security team can review a patch, and a public buyer can ask questions without treating a black box as a constitutional principle.
Those are significant public goods. They are also conditional. Code that is visible but impossible to build is less inspectable than it first appears. Code that is buildable but lacks a clear licence leaves reuse uncertain. Code that is licensed but assembled from unknown dependencies carries a provenance problem. Code that is maintained only in a branch no one can identify is not made reliable by the fact that a repository page exists.
L'Open Source Initiative décrit l'open source à travers une licence approuvée et un ensemble de droits, notamment l'accès au code source et la liberté de redistribuer et de modifier selon des conditions énoncées. Cette définition porte délibérément sur les permissions. Il ne s'agit pas d'un accord de niveau de service, d'une certification de sécurité, d'une garantie d'aptitude à une tâche publique particulière ni d'une assurance qu'un composant sera maintenu indéfiniment. L'absence de ces promesses n'est pas un défaut de la définition. C'est une raison d'être précis sur ce sur quoi une organisation s'appuie.
Il est utile de distinguer quatre questions souvent regroupées sous un seul mot commode. Le code source est-il disponible ? Est-il sous licence pour l'usage prévu ? L'organisation peut-elle établir d'où proviennent le code et ses dépendances ? Quelqu'un assume-t-il activement le travail opérationnel que ce déploiement exige ? Une réponse affirmative à la première question ne répond pas aux trois autres.
Cette distinction rend aussi les conversations moins théâtrales. Une équipe d'approvisionnement n'a pas besoin de feindre l'enthousiasme pour un dépôt. Elle doit savoir si le composant convient au système qu'elle achète ou exploite. Une équipe d'ingénierie n'a pas à s'excuser d'utiliser une licence permissive. Elle doit savoir comment elle respectera les mentions de licence, conservera les documents requis, mettra à jour les dépendances et répondra à un problème divulgué. Une équipe juridique n'a pas à devenir gestionnaire de versions. Elle a besoin d'une voie d'accès au processus de publication avant qu'un problème de licence ne devienne une correction publique.
La licence est une frontière, pas un bulletin météo
Les licences sont parfois traitées comme un détail administratif, comme si le travail juridique commençait après la fin du travail d'ingénierie. En pratique, les choix de licence façonnent les décisions d'ingénierie dès le départ. Ils déterminent si un composant peut être combiné avec un autre, si des mentions doivent accompagner une distribution, si le code source modifié doit être proposé dans certaines circonstances et si une équipe peut satisfaire aux conditions attachées aux droits qu'elle souhaite utiliser.
Cela ne signifie pas que chaque ingénieur doit devenir un spécialiste du droit d'auteur. Cela signifie que l'organisation a besoin d'une traduction fiable entre les logiciels qu'elle construit et les engagements qu'elle prend lorsqu'elle distribue, héberge ou modifie ces logiciels. La traduction doit avoir lieu pendant que les faits sont encore disponibles : quel paquet a été sélectionné, quelle version a été utilisée, s'il a été modifié, comment il a été lié ou inclus, avec quoi il est distribué et quelle est la voie de distribution prévue.
Il n'existe pas de réponse universelle en matière de licence. Une licence permissive peut faciliter la réutilisation tout en exigeant des mentions et la préservation du texte de droit d'auteur. Une licence réciproque peut ajouter des conditions supplémentaires à la distribution ou à la modification. Un arrangement de double licence peut exiger qu'une organisation choisisse une voie commerciale ou une voie open source particulière. Une organisation ne doit pas déduire des obligations d'un surnom de licence, d'un badge de gestionnaire de paquets ou du souvenir à moitié oublié d'un collègue datant de 2014. Elle doit lire le texte de la licence, consigner la décision et demander conseil lorsque l'usage prévu est incertain.
La conformité en matière de licences n'est pas non plus un exercice de pure forme réservé à la semaine de publication. Une nomenclature logicielle, un inventaire des dépendances et un registre des versions publiées peuvent rendre la question ultérieure répondable : qu'est-ce qui était inclus dans cet artefact ? Mais une liste n'est utile que si elle décrit un artefact, une version et une date précis. Une feuille de calcul nommée dependencies-final-final.xlsx n'est pas un système de traçabilité. C'est une couche archéologique.
Pour une institution publique, cela va au-delà de la simple gestion interne. L'institution peut avoir besoin de préserver la capacité d'expliquer pourquoi un composant a été choisi, quelles conditions l'encadrent, comment il peut être remplacé et ce qui se passe si la maintenance cesse. Pour une organisation commerciale, ces mêmes registres affectent les engagements contractuels, les mises à jour de produits et les communications avec les clients. Pour une petite équipe, l'échelle est différente mais la logique ne l'est pas. Si un projet ne peut pas identifier la licence du code qu'il distribue, il ne peut pas honnêtement affirmer que la frontière juridique est maîtrisée.
La démarche responsable est proportionnée, pas grandiose. Enregistrez les dépendances directes. Conservez les textes de licence et les avis requis avec la version publiée. Enregistrez les modifications substantielles. Fixez un point de contrôle pour les nouvelles conditions de licence ou les conditions inhabituelles. Désignez une personne responsable de la résolution des incertitudes. Ce sont des contrôles modestes. Leur valeur est d'empêcher que l'incertitude ne devienne une surprise après que le logiciel a circulé.
La maintenance est un travail, même lorsqu'il est bénévole
La maintenance des logiciels open source est souvent décrite comme si elle était une vertu personnelle. Parfois, elle l'est. Des personnes relisent les correctifs, répondent aux questions, préparent les versions et empêchent que les anciennes hypothèses ne deviennent la panne de demain, parce qu'elles se soucient d'un outil et des personnes qui l'utilisent. Cette générosité mérite le respect. Elle ne devrait pas être utilisée comme modèle économique sans une décision commerciale.
La maintenance est un travail opérationnel. Elle comprend la décision des versions prises en charge, l'examen des contributions, la publication d'informations de sécurité, la gestion d'un processus de publication, la réponse aux signalements, la documentation des changements cassants, le maintien de l'infrastructure de construction utilisable et, parfois, le fait de dire non. Cette dernière partie est sous-estimée. Un projet qui ne peut pas refuser une demande de fonctionnalité, une plateforme non prise en charge ou un raccourci dangereux n'est pas nécessairement plus ouvert. Il peut simplement être plus exposé.
La stratégie de la Commission européenne pour les logiciels open source considère l'open source comme un moyen d'améliorer la réutilisation, la transparence, la collaboration et l'indépendance technologique dans l'administration publique. Ces avantages dépendent de la capacité. La réutilisation exige qu'une organisation comprenne ce qu'elle réutilise. La transparence exige que quelqu'un lise ce qui est divulgué. L'indépendance exige plus que la possession d'un bouton de clonage : elle exige la capacité pratique d'exploiter, d'adapter ou d'obtenir un support pour le logiciel lorsque le contributeur d'origine est parti.
C'est pourquoi la question « est-ce maintenu ? » a besoin de plus de précision. Cela peut signifier que des versions récentes existent. Cela peut signifier qu'un contact de sécurité est publié. Cela peut signifier que le projet décrit les versions prises en charge, les instructions de construction et un processus de contribution. Cela peut signifier qu'une organisation a consacré du temps rémunéré à ce travail. Cela peut signifier qu'un déployeur a sa propre capacité à maintenir un fork ou à remplacer un composant. Ce sont des faits différents. Un graphique d'activité vert peut être une preuve utile, mais ce n'est pas un contrat de maintenance.
Un adoptant responsable devrait donc décider du type de maintenance dont il a besoin avant de décider ce qu'il espère qu'une communauté fournira. Un outil interne à faible risque peut être compatible avec un petit projet et un plan de mise à jour modeste. Un composant au centre d'un produit exposé à l'extérieur nécessite un modèle de support plus clair, une évaluation plus rapide des vulnérabilités et un plan de sortie. La distinction ne concerne pas le prestige du projet. Elle concerne la conséquence d'une erreur.
Il y a une petite habitude néerlandaise qui mérite d'être reprise ici : ne pas confondre gezellig avec « sous contrôle ». Une communauté accueillante peut être un endroit merveilleux où contribuer. Elle peut néanmoins n'avoir aucune obligation de maintenir votre système de production en fonctionnement. L'organisation qui met ce système en production est propriétaire de cette différence.
La divulgation de vulnérabilités a besoin d'un circuit avant d'avoir besoin d'un slogan
La plupart des gens s'accordent, dans l'abstrait, sur le fait que les vulnérabilités devraient être divulguées de manière responsable. La partie difficile est moins abstraite. Où un rapporteur envoie-t-il ses constatations ? Qui les reçoit ? Quelles informations sont nécessaires pour les reproduire ? Qui décide si elles affectent une version prise en charge ? Comment un correctif est-il développé sans créer une fenêtre d'exposition publique inutile ? Comment les utilisateurs sont-ils informés de la marche à suivre ? Quels paquets en aval ont besoin d'une mise à jour ? Que se passe-t-il si le rapporteur ne reçoit aucune réponse ?
Ces questions ne sont pas une preuve de méfiance envers l'open source. Elles constituent le travail qui consiste à traiter les utilisateurs comme des personnes ayant besoin d'une réponse. Les travaux de l'ENISA sur la divulgation de vulnérabilités et la divulgation coordonnée de vulnérabilités décrivent la valeur de processus définis entre les rapporteurs, les fournisseurs et les autres parties concernées. Un processus ne peut pas garantir que chaque rapport soit correct ou que chaque correctif soit rapide. Il peut réduire la probabilité qu'un problème grave commence sa vie dans une boîte de réception non surveillée.
Un projet peut publier une politique de sécurité, une adresse de signalement et des informations sur les versions prises en charge. Ce sont des signaux utiles, surtout lorsqu'ils décrivent ce qu'un rapporteur peut attendre. Un projet peut aussi être trop petit pour fournir le temps de réponse dont un déploiement important a besoin. Ce n'est pas un échec moral. C'est un fait de planification pour l'organisation qui choisit la dépendance.
Il en va de même en aval. Un fabricant ne peut pas raisonnablement affirmer qu'une vulnérabilité est le problème de quelqu'un d'autre simplement parce que le composant vulnérable a commencé dans un dépôt ouvert. Si le fabricant met sur le marché de l'Union un produit comportant des éléments numériques, le règlement sur la cyberrésilience fixe des exigences concernant le traitement des vulnérabilités et la fourniture de mises à jour de sécurité dans le cadre applicable au produit. Le détail juridique dépend du produit et du rôle. Le point opérationnel est plus simple : la partie qui met le produit à disposition a besoin d'un moyen de savoir si un changement en amont affecte ce qu'elle a fourni.
C'est ici qu'un inventaire devient actif plutôt que décoratif. Il doit relier un composant à une version, à une compilation, à une version de produit et à un propriétaire capable d'évaluer le rapport. Le propriétaire n'a pas à corriger seul chaque défaut en amont. Il doit décider s'il faut mettre à jour, atténuer, désactiver, notifier, compenser ou cesser d'utiliser le composant. « Nous utilisons l'open source » est une description d'une entrée. Ce n'est pas un plan de réponse.
Prenons un exemple explicitement hypothétique. Une équipe inclut une bibliothèque dans un service de traitement de documents. Des mois plus tard, un avis de sécurité identifie une plage vulnérable. Si l'équipe a enregistré le composant, la version et les services dans lesquels il est intégré, elle peut commencer une évaluation. Si elle peut reproduire les compilations et tester la mise à jour, elle peut décider si le remède est une mise à niveau, un changement de configuration ou une restriction temporaire. Si elle n'a ni enregistrement ni propriétaire, la première tâche est un travail d'enquête. La vulnérabilité peut être identique dans les deux cas. Le risque opérationnel, lui, ne l'est pas.
La provenance répond à la question « qu’est-ce qu’on exécute exactement ? »
La provenance logicielle peut évoquer un terme emprunté aux étiquettes de musée. La question sous-jacente est pourtant ordinaire : d’où vient cet artefact, et peut-on en retracer le parcours ? Pour un logiciel, ce parcours peut inclure les dépôts de code source, les archives publiées, les registres de dépendances, les outils de compilation, la configuration, les clés de signature, les environnements de compilation et les systèmes de publication. La réponse est rarement un fait unique et élégant. C’est un ensemble de registres qui doivent suffisamment concorder pour qu’une personne puisse prendre une décision.
La provenance n’exige pas d’une organisation qu’elle prétende à une connaissance parfaite. Elle lui demande d’indiquer ce qui est connu, ce qui a été vérifié et où subsistent des incertitudes. Une compilation reproductible peut fournir une preuve solide qu’un code source défini et un environnement défini ont produit un artefact correspondant. Une version signée peut aider à identifier la clé utilisée pour attester d’une version. Une liste de composants logiciels peut décrire les composants déclarés. Aucun de ces éléments ne prouve à lui seul que le code est inoffensif, que chaque dépendance transitive a été examinée ou qu’une version convient à un usage particulier. Ensemble, ils peuvent rendre une enquête ultérieure beaucoup moins spéculative.
Cette distinction est importante car la provenance est souvent présentée comme un tampon magique. Elle ne l’est pas. Une empreinte peut vous dire que deux séquences d’octets correspondent. Elle ne peut pas vous dire que le programme correspondant devrait être autorisé à traiter des données sensibles. Une signature peut relier une version à une clé. Elle ne peut pas vous dire que la personne qui contrôle la clé a suivi un bon processus de revue. Un inventaire peut nommer un composant. Il ne peut pas vous dire si le composant est configuré de manière sûre. Une preuve reste une preuve, pas un substitut au jugement.
Pourtant, l’absence de provenance appauvrit le jugement. Lorsqu’une équipe ne peut pas établir quelle révision du code source a produit un paquet déployé, elle ne peut pas relier en toute confiance un correctif en amont à son propre service. Lorsqu’elle ne peut pas identifier une dépendance transitive, elle ne peut pas évaluer un avis ou une alerte sans d’abord reconstituer la chaîne d’approvisionnement. Lorsque la compilation produit des résultats différents sans explication, elle ne peut pas dire si un binaire a changé à cause du code source, de l’environnement ou d’une interférence. Ce sont des limites pratiques, pas des tests de pureté.
La souveraineté numérique européenne est souvent réduite à la localisation d’un serveur. La localisation compte. Elle ne suffit pas. Un système peut fonctionner en Europe tout en dépendant d’un pipeline de compilation, d’un registre de dépendances ou d’un canal de mise à jour que l’exploitant ne peut ni inspecter, ni contrôler, ni remplacer. À l’inverse, l’open source peut offrir une véritable voie vers l’examen et la portabilité, tout en laissant à l’adoptant la responsabilité de la capacité nécessaire pour emprunter cette voie. La souveraineté est une capacité d’agir sous pression, pas un drapeau apposé sur une image de conteneur.
Un registre de provenance utile devrait permettre à un collègue techniquement compétent de retracer une version dans les deux sens. En arrière : quels code source, dépendances et processus de compilation ont mené ici ? En avant : quels services, produits et utilisateurs peuvent être affectés si ce composant est modifié ou retiré ? Le registre peut être proportionné. Un petit outil interne n’a pas besoin de la machinerie d’un programme aéronautique. Mais il doit contenir assez de vérité pour assumer les conséquences de son usage.
Le Cyber Resilience Act trace une ligne sans prétendre que le monde est simple
Le Cyber Resilience Act est souvent résumé comme un nouvel ensemble d’exigences de cybersécurité pour les produits connectés. C’est vrai, mais incomplet. Sa contribution la plus utile à cette discussion est la distinction qu’il établit entre les rôles. Un steward de logiciels libres et open source peut être une entité qui fournit un soutien durable au développement de produits comportant des éléments numériques qualifiés de logiciels libres et open source et qui est conçue pour garantir la viabilité de ces produits. Le règlement fixe des conditions autour de ce rôle. Il ne traite pas chaque contributeur comme porteur des mêmes obligations qu’un fabricant.
Cette distinction reconnaît la réalité du fonctionnement de l'open source. Un projet peut compter des contributeurs individuels, une association, une fondation, une entreprise offrant du support, une distribution qui empaquète le logiciel, un intégrateur et un fabricant qui l'inclut dans un produit. Leurs responsabilités sont liées mais non interchangeables. Un contributeur peut corriger un bug. Un steward peut coordonner le projet. Un distributeur peut l'empaqueter. Un fabricant peut mettre un produit sur le marché. Un déployeur peut décider de la manière dont ce produit traite des données et des personnes réelles. Le dépôt public est un lieu de rencontre entre ces rôles, non un mélangeur juridique.
Pour les organisations, la lecture la plus prudente consiste à ne pas transformer la réglementation en folklore avant son application. La loi prévoit des dates d'application échelonnées et des dispositions spécifiques à chaque rôle. L'interprétation juridique doit se fonder sur le texte applicable et sur un avis compétent, en particulier lorsqu'un produit, une activité commerciale ou une mise sur le marché est en cause. La préparation opérationnelle, en revanche, n'a pas à attendre un séminaire avec un café froid et une diapositive intitulée « vue d'ensemble ». Inventoriez les composants. Identifiez qui est responsable des mises à jour. Conservez les preuves de publication. Mettez en place un canal de signalement des failles de sécurité. Définissez ce que signifie « pris en charge ». Ces actions sont utiles, qu'une clause particulière s'applique aujourd'hui, l'année prochaine ou pas du tout.
La loi résiste également à un faux dilemme. Elle ne dit pas que l'open source est dangereux. Elle ne dit pas non plus que la publication dispense un produit commercial du travail de sécurité. Elle reconnaît que la sécurité des logiciels utilisés dans des produits a des conséquences publiques et que la chaîne d'acteurs a besoin de responsabilités plus claires. Les obligations exactes méritent une lecture juridique attentive. Le principe est simple : un logiciel qui atteint des personnes via un produit a besoin de quelqu'un capable d'agir de manière responsable lorsque le risque est connu.
Ce principe est déjà familier dans d'autres domaines. Une recette publiée ne dispense pas un restaurant des règles de sécurité alimentaire. Une norme de construction publiée ne décharge pas un entrepreneur de son devoir de l'appliquer avec compétence. La comparaison a ses limites : les licences logicielles, les canaux de mise à jour et les communautés de développement ont leurs propres structures. Mais l'idée de base se transpose. La connaissance rendue publique peut permettre une vérification indépendante. Elle ne supprime pas la responsabilité de celui qui sert le repas ou ouvre la porte.
Ce que les adoptants se doivent à eux-mêmes
La politique open source la plus utile est souvent une politique opérationnelle déguisée en liste de contrôle sensée. Elle doit répondre à qui peut introduire une dépendance, quelles informations doivent être enregistrées, comment les licences sont examinées, comment les mises à jour sont évaluées, comment les rapports de sécurité sont acheminés et qui peut approuver une exception. Elle doit aussi répondre à ce qui se passe lorsque le support prend fin. Une politique qui explique la sélection mais ne dit rien sur le retrait n'est qu'une demi-politique.
Commencez par l'unité qui compte réellement : l'artefact ou le service déployé, et non un catalogue abstrait de projets favoris. Pour chaque composant important, une organisation doit être en mesure de localiser la version, la source ou le registre, la licence, le rôle interne responsable, le système dans lequel il est utilisé et le chemin de mise à jour. Le niveau de détail doit suivre la conséquence d'une défaillance. L'objectif n'est pas de transformer chaque développeur en commis. Il est d'empêcher que des faits importants deviennent des connaissances privées dans un ordinateur portable ou la mémoire d'une seule personne.
Ensuite, décidez quelles preuves modifieront une décision. Un avis publié peut déclencher une évaluation. Une nouvelle version peut déclencher un test de compatibilité. Un changement de licence peut déclencher un examen juridique. Une version prise en charge abandonnée peut déclencher un plan de migration. Une construction qui ne se reproduit plus peut déclencher une enquête. Sans ces déclencheurs, les inventaires ont tendance à devenir des documents historiques : exacts le jour de leur exportation, poliment ignorés par la suite.
Placez la propriété au plus près de l'action. Une équipe de gouvernance centrale peut définir la politique et fournir une expertise. Elle ne peut pas exploiter chaque service. Une équipe produit peut connaître l'architecture de son propre déploiement. Elle n'est pas nécessairement équipée pour interpréter chaque licence. Le dispositif fonctionne lorsque la transmission est explicite : le propriétaire du produit évalue l'impact, la sécurité conseille sur l'exposition et la réponse, le service juridique ou de conformité évalue les conditions de licence lorsque nécessaire, les achats enregistrent les engagements externes, et un décideur désigné accepte ou rejette le risque matériel. Les noms varieront. L'absence de noms est le problème récurrent.
Préservez une voie de sortie. L'open source peut réduire l'enfermement propriétaire, mais seulement si une organisation peut reconstruire, forker, remplacer ou sous-traiter le support lorsque les circonstances changent. Un miroir de dépôt, des instructions de compilation, un itinéraire de dépendances en cache et un enregistrement de la configuration requise peuvent sembler un travail ingrat jusqu'à ce que le service d'origine soit indisponible ou que la relation prenne fin. Le travail ingrat a un excellent bilan en cas d'urgence.
Enfin, soyez honnête au sujet du risque résiduel. Aucun programme de dépendances ne peut garantir que chaque vulnérabilité sera découverte en premier, que chaque projet en amont restera actif ou que chaque question de licence sera simple. Le but de la gouvernance n'est pas de promettre l'impossible. C'est de rendre l'incertitude visible assez tôt pour qu'une personne responsable puisse décider quoi en faire.
Ce que les mainteneurs peuvent raisonnablement offrir
Les mainteneurs ne doivent pas au monde un travail illimité parce qu'ils ont publié un code utile. Cette attente est à la fois injuste et dangereuse. Un projet peut être généreux en matière de réutilisation tout en étant explicite sur sa capacité. Il peut indiquer quelles versions sont prises en charge, où signaler les problèmes de sécurité, comment les décisions de publication sont prises, quels types de contributions il peut examiner et ce qu'il ne promettra pas. Des limites claires valent mieux pour les adoptants qu'une ambiguïté chaleureuse.
Même un petit projet peut améliorer la transmission opérationnelle avec quelques documents durables : un fichier de licence, un processus de publication lisible, une politique de contact ou de divulgation en matière de sécurité, des informations de version, des conseils sur les dépendances lorsque cela est pertinent, et une déclaration claire indiquant si la maintenance est active, limitée ou conclue. Aucun de ces éléments ne crée de garantie. Chacun aide un utilisateur en aval à faire un choix plus éclairé.
Lorsqu'un projet bénéficie d'un soutien organisationnel, la conversation peut aller plus loin. L'organisation peut publier une politique de versions prises en charge, décrire sa gouvernance, consigner sa pratique de signature des publications, maintenir un itinéraire de réponse aux vulnérabilités et expliquer comment les utilisateurs peuvent obtenir du support. Ce ne sont pas des badges pour une page d'accueil. Ce sont des promesses opérationnelles, et elles ne devraient être écrites que là où l'organisation est prête à les tenir.
Le message de maintenance le plus honnête peut parfois être « nous ne pouvons pas nous en charger ». Cela peut signifier qu'une fonctionnalité est hors du périmètre, qu'une plateforme ne peut pas être testée, qu'un rapport de sécurité nécessite plus d'informations, qu'une branche n'est plus prise en charge ou qu'une date de publication ne peut pas être promise. Un refus clair donne aux adoptants quelque chose autour duquel planifier. Le silence leur donne une histoire à se raconter, ce qui est généralement une entrée plus coûteuse.
Il existe également une responsabilité pour les utilisateurs qui dépendent d'un projet. Signalez les défauts avec suffisamment de détails pour les reproduire. Suivez l'itinéraire de sécurité s'il en existe un. Contribuez aux tests, à la documentation, au financement ou à la révision lorsque c'est possible. N'exigez pas une relation de service d'un projet bénévole tout en refusant de reconnaître qu'une relation de service coûte de l'argent. La réciprocité n'abolit pas les différents rôles, mais elle peut rendre la chaîne moins fragile.
L'open source peut renforcer la responsabilisation
Après avoir énuméré toutes ces obligations, on peut être tenté de conclure que l'open source crée trop de travail. Ce n'est pas le cas. Le travail existe, que le code source soit visible ou non. Les dépendances fermées exigent elles aussi un inventaire, une connaissance des licences, une gestion des vulnérabilités, une traçabilité de la provenance et un plan de sortie. Elles rendent simplement certaines preuves plus difficiles à inspecter et certaines alternatives plus difficiles à exercer.
L'open source peut permettre une posture de responsabilité plus solide. Un acheteur peut inspecter l'architecture. Un exploitant peut conserver une copie du code source et des instructions de compilation. Un évaluateur indépendant peut vérifier une affirmation. Une autorité publique peut éviter que la feuille de route privée d'un fournisseur soit la seule voie vers une correction. Une communauté peut trouver et corriger un problème qu'une organisation a manqué. Ce sont des avantages significatifs, notamment dans les contextes européens où la valeur publique, la continuité et la contestabilité ne sont pas des ornements facultatifs.
Mais la possibilité n'est pas l'achèvement. L'inspectabilité n'aide que celui qui est capable et autorisé à inspecter. La portabilité n'aide que celui qui a préservé les artefacts et sait comment les déplacer. Un fork n'est une stratégie de sortie que lorsqu'il existe une équipe, un budget et une voie juridique capables de le porter. « Le code est sur GitHub » n'est pas un plan de continuité, pas plus que « les fichiers sont dans un placard » n'est une stratégie d'archivage.
Notre travail open source chez Dweve garde cette limite en vue. Knot est décrit dans nos documents publiés comme une piste d'audit signée et inviolable pour les exécutions d'agents IA, avec vérification hors ligne d'un enregistrement reçu à l'aide d'une clé publique. Cela rend une affirmation plus inspectable. Cela ne décide pas de ce qu'une organisation doit journaliser, de qui peut accéder à un enregistrement, de la durée de conservation ou de qui enquête sur un résultat inattendu. Ces décisions restent des choix de gouvernance autour de l'outil. L'outil peut préserver des preuves. Il ne peut pas devenir l'organisation responsable au nom de qui que ce soit.
C'est la promesse modeste qui vaut la peine d'être tenue. L'open source peut donner aux gens plus de preuves, plus d'options et plus de place pour contribuer. On ne devrait pas lui demander d'offrir une absolution fictive des responsabilités de maintenance, de sécurité, de licence ou de jugement opérationnel.
La responsabilité survit au bouton de publication
Publier du code source est un acte utile. Cela peut inviter à l'examen, abaisser les barrières à la réutilisation et rendre un choix technique plus facile à contester. Dans une culture technologique saine, il devrait être normal que les institutions publiques et les entreprises considèrent l'open source sérieusement, le soutiennent correctement et expliquent leurs choix sans superstition.
Le bouton de publication n'est cependant pas une trappe sous la responsabilité. Il ne supprime pas la nécessité de savoir ce que contient un produit. Il ne corrige pas un service déployé. Il ne préserve pas un avis de licence, ne trie pas une divulgation, ne maintient pas une compilation et ne décide pas si un système doit rester en service. Ces tâches appartiennent toujours à des personnes et des organisations avec des rôles, des budgets, des autorités et des conséquences.
La bonne nouvelle, c'est que la pratique responsable n'a rien de mystique. Nommez la dépendance. Lisez la licence. Conservez la provenance. Décidez qui possède la mise à jour. Donnez une voie aux rapports de sécurité. Préservez une sortie. Dites clairement ce qui est pris en charge et ce qui ne l'est pas. Lorsque ces habitudes sont présentes, l'open source devient plus qu'un geste vers la transparence. Il devient une infrastructure qui peut être inspectée, maintenue et digne de confiance pour des raisons qui survivent à une journée difficile.
La question derrière la question
Lorsqu’une équipe se demande si un composant est open source, elle pose souvent plusieurs questions plus discrètes à la fois. Pouvons-nous lui faire confiance ? Pouvons-nous nous en passer ? Pouvons-nous le modifier ? Quelqu’un d’autre peut-il l’auditer ? Pouvons-nous obtenir de l’aide en cas de panne ? La licence et le dépôt peuvent contribuer à la réponse, mais ni l’un ni l’autre ne peut y répondre seul. La confiance découle de preuves, de compétences, d’incitations et de la manière dont un déploiement particulier est gouverné. Se passer du composant dépend des interfaces, des formats de données, des connaissances de construction et des ressources. Le modifier dépend des capacités techniques et des conditions dans lesquelles la modification peut être effectuée. L’aide dépend d’une relation de support réelle ou de la capacité à fonctionner sans elle.
Ces distinctions sont une défense à la fois contre le cynisme et contre les vœux pieux. Le cynisme affirme que l’open source n’est qu’un travail non rémunéré. Les vœux pieux affirment qu’il est automatiquement plus sûr parce que de nombreux regards pourraient être en mesure de l’inspecter. Aucune de ces affirmations ne dit à un opérateur quoi faire ensuite. L’opérateur doit savoir quels regards ont réellement examiné la version concernée, qui peut tester un correctif, quelle autorité existe pour effectuer une modification et comment le résultat parvient au système affecté. La sécurité est une chaîne d’actions vérifiées, pas un proverbe sur les foules.
La même retenue s’applique aux achats. Demander à un fournisseur un composant open source ne rend pas un contrat moins important. Cela change les questions qu’un bon contrat peut poser : quels composants en amont sont inclus, comment les avis et les obligations relatives au code source seront-ils traités, quelles versions sont prises en charge, quelles preuves accompagnent une version, ce qu’il advient des correctifs pendant la durée du support et quels éléments le client peut conserver pour assurer la continuité. Un acheteur doit valoriser la capacité d’inspecter et de migrer. Il doit également chiffrer les compétences nécessaires pour utiliser cette capacité.
Il n’y a aucune vertu à créer un processus tentaculaire pour un petit utilitaire, et il n’y a aucune prudence à utiliser un simple diagramme d’activité comme modèle de gouvernance pour un service critique. La proportionnalité est l’art pratique ici. Plus l’exposition est large, plus les données sont sensibles, plus la récupération est difficile et plus le composant est central, plus les enregistrements et les dispositifs d’exploitation doivent être solides. Ce n’est pas de la bureaucratie pour elle-même. C’est une tentative de garder la décision réelle proche de la conséquence réelle.
L’open source gagne sa place dans l’infrastructure numérique européenne lorsqu’il aide les institutions à rester capables : capables de vérifier, capables de modifier, capables d’expliquer et capables de continuer. La capacité s’acquiert plus lentement que l’enthousiasme. Elle exige du temps, des personnes, de la documentation, des tests et la volonté occasionnelle de financer un travail qui ne deviendra jamais un discours d’ouverture de conférence. C’est aussi ce qui demeure lorsqu’un dépôt populaire, une relation avec un fournisseur ou un calendrier de publication change sans demander la permission.
Voilà la responsabilité dans sa forme utile, sans glamour et pleinement publique.
Sources
- Règlement (UE) 2024/2847, le Cyber Resilience Act, Parlement européen et Conseil, consulté le 5 août 2026.
- Logiciels open source, Commission européenne, consulté le 5 août 2026.
- Stratégie 2020-2023 pour les logiciels open source, Commission européenne, consulté le 5 août 2026.
- Politiques de divulgation coordonnée des vulnérabilités dans l'UE, ENISA, consulté le 5 août 2026.
- Bonnes pratiques pour la divulgation des vulnérabilités, ENISA, consulté le 5 août 2026.
- La définition de l'open source, Open Source Initiative, consulté le 5 août 2026.
- Licence MIT, Open Source Initiative, consulté le 5 août 2026.
- Knot, Dweve B.V., documentation du dépôt vérifiée le 5 août 2026.