Emmanuel LÉCHARNY

Expert Infrastructure

Cet article a pour objectif de lister les différents points à ne pas négliger quand on commence un projet intégrant des composants Open Source.

Toutes les parties de cet article sont accessibles ci-dessous :

Une fois ce panorama (partiel) présenté, certaines questions restent en suspens. Ce dernier chapitre va essayer de les lister, sans prétendre à l’exhaustivité.

Quid de la longévité ?

Ayant recherché un composant récemment pour un besoin client, voici le dernier message posté sur la page du projet[13] :

“This repository is now archived. Thank you all for your excellent contributions. May it continue to live in all your wonderful forks.” OPENLDAP Exporter

C’est juste un exemple, et fort heureusement il a été forké 65 fois, mais cela ouvre d’autres questions :

  • Quel fork utiliser ?
  • Quelle garanties a-t-on que le fork que l’on choisira survivra ?
  • Le problème ne va-t-il pas se reproduire ?

Encore une fois, dans le monde Open Source, l’utilisateur est le responsable de ses choix. Ceux-ci doivent être pesés.

La gestion des CVEs

Les CVE sont des failles de sécurité identifiées. Elles couvrent l’ensemble des logiciels depuis 1999. Ce système d’alerte est géré par The MITRE Corporation. Aujourd’hui, il s’agit de la référence conservant toutes les failles connues et elle est alimentée en continue. Le 15 avril 2025, le contrat qui liait cette organisation et le gouvernement américain a été rompu par ce dernier à la veille de la date d’expiration contractuelle[14]. Vu l’urgence, une extension de 11 mois a été mise en place, mais rien n’est prévu sur ce qui se passera en avril 2026… On peut légitimement se poser la question de savoir pourquoi l’industrie ne finance pas ce service essentiel.

En Europe, un service équivalent (EUVD, European Union Vulnerability Database[15]) a été mis en place et délégué à l’ENISA[16].

Que faire en cas de bug ?

Donc vous avez trouvé un bug dans un des composants que vous utilisez. Quelle est la démarche à suivre ? Il n’y a pas de procédure toute faite.

La première démarche est de vérifier que ce bug n’a pas été corrigé dans une version plus récente. Si ce n’est pas le cas, peut-être qu’un ticket d’anomalie a déjà été rempli ? Sinon, le plus simple est de créer un nouveau ticket. Mais encore faut-il que le projet propose un mécanisme qui le permette. Si le projet est sous GitHub, par exemple, vous pouvez certainement remplir un rapport d’anomalie (mais attention, tous les projets sous GitHub ne le permettent pas). Si le projet dispose d’un système de gestion des anomalies (JIRA, Redmine, Mantis, Bugzilla, etc), c’est sans doute votre point d’entrée. Une autre solution pourrait être de poster un message sur la liste de diffusion du projet, à condition qu’il y en ait une… Comme on le voit, il n’y a pas de mécanisme standardisé pour signaler une anomalie, chaque projet les gère à son gré et il faut en tenir compte.

En espérant qu’une correction sera proposée ! Et si ce n’est pas le cas, mais qu’on est à même d’apporter cette correction, la question suivante est de savoir comment la gérer : faut-il forker le projet en attendant une éventuelle release ?

Dans tous les cas, les utilisateurs sont fortement encouragés à remonter les anomalies et idéalement à proposer des patchs sous toutes formes possibles.

Et l’IA ?

Un nouveau venu est en train de bouleverser la façon dont on développait : l’IA. Depuis un ou deux ans, les progrès des solutions basées sur des LLM permettent de générer du code qui n’est pas totalement inutilisable. On prétend même que ces IA vont remplacer les développeurs, qui ne seront plus que des prompteurs avec une productivité 10 fois supérieure…

On peut rêver. En attendant, cela pose quand même un certain nombre de questions :

  • Quel est la qualité du code proposé par ces IAs ?
  • Quid de la licence ?
  • Qu’en est-il des tests associés ?
  • Les rapports d’anomalies générés par des IAs sont-ils pertinent ?
  • Quel sera le coût de ces solutions à long terme ?

Aujourd’hui, de nombreux mainteneurs de projets Open Source se plaignent d’être inondés de propositions de correction de piètre qualité générées par des IA. Le temps passé à relire les propositions, à les tester et à les corriger n’est pas forcément en rapport avec le gain obtenu. Sans compter les faux positifs à éliminer.

De plus, on peut se poser la question du coût d’usage de ces outils. S’ils sont aujourd’hui quasi gratuits, ils risquent de devenir payants quand les sociétés qui ont investit des dizaines de milliards de dollars dans ces solutions demanderont un retour sur investissement.

Certains sites se protègent (difficilement) contre ces robots en tentant de leur interdire l’accès aux sources. En effet, ces requêtes incessantes consomment de la bande passante et du temps CPU, ce qui se traduit en frais d’hébergement en forte augmentation. Le second problème est qu’on risque d’aboutir à une “moyennisation” des solutions proposées, puisque l’alimentation de ces outils se fait par la récupération des sources sur internet. A partir du moment où les IA se mettent à produire du code qui sera intégré dans les bases, elles vont se nourrir de ce qu’elles ont elles-même produit. Il ne faut pas oublier qu’il s’agit d’outil de génération probabilistique.

Sans vouloir dépeindre un tableau apocalyptique, il est important de questionner la portée de ces outils et d’en faire un usage raisonné.

Qui finance ?

La grande question… Puisqu’il s’agit d’Open Source, le modèle économique est compliqué à identifier. Aujourd’hui on peut considérer que les contributions sont financées de différentes façons :

  • Par de grosses sociétés comme Google, IBM, Microsoft, qui ont une politique Open Source assez poussée.
  • Par des fondations qui assurent non pas le financement des développements, mais au moins l’infrastructure nécessaire à sa mise à disposition. C’est le cas des fondations Apache ou Eclipse, etc.
  • Par des organisations gouvernementales qui couvrent tout ou partie des développements (NGI, NLNET…).
  • De nombreuses PMI/PME qui soit utilisent des composants et les maintiennent, soit développent ces composants en les mettant à disposition, soit ont une politique de contribution.
  • Par des initiatives publiques ou privées (Bug Bounties, GitHub sponsoring…).
  • Mais également par beaucoup de personnes travaillant sur leur temps personnel.

Parlons de souveraineté

L’Open Source n’a pas de frontière mais… savez-vous que les USA peuvent interdire l’accès à GitHub à certains pays, comme l’Iran ? Cela a été le cas jusqu’en 2021.

Il peut être utile de se poser la question de la disponibilité de certains composants en terme de souveraineté. Pendant de nombreuses années, toute partie de code qui relevait de la cryptographie relevait de mesures d’autorisation d’exportation de la part du gouvernement américain. Rien n’interdit de penser que des règles plus strictes pourraient être imposées.

L’Open Source offre plus de souplesse que le code privatif, mais il convient de rester prudent. Les demandes récurrentes de la mise en place de backdoors par les administrations sont autant d’éléments inquiétants, par exemple.

Sans aller jusqu’à la paranoïa, il semblerait utile que les administrations s’approprient l’Open Source, non seulement en tant qu’utilisatrices, mais également en tant qu’actrices au sein de projets d’importance vitale. Voilà un autre débat, qui ne sera pas ouvert ici et ce long post de blog se clôturera sur ce point en suspens !

Bibliographie

[13] OpenLDAP exporter
[14] CVE program averts swift end after CISA executes 11-month contract extension
[15] European Union Vulnerability Database
[16] ENISA

Vous pourriez aimer aussi