Le CNLL auditionné par la mission Bothorel sur l'ouverture des codes et des données de l'Etat

• 10 octobre 2020

Stefane Fermigier, co-président du CNLL, a été auditionné par la Mission Bothorel ayant pour objet la politique de la donnée et des codes sources.

Le texte qui suit est le contenu mis au propre de son intervention.

---

Présentation

Bonjour je suis Stéfane Fermigier, co-président du CNLL, l’union des entreprises du logiciel libre et du numérique ouvert, une organisation qui représente 300 entreprises en France qui se reconnaissent dans les valeurs du logiciel les libre.

J’utilise personnellement le logiciel libre depuis bientôt 30 ans, d’abord en tant qu’étudiant puis mathématicien à université et ensuite depuis l’an 2000 en tant qu’entrepreneur. J’ai fondé successivement plusieurs entreprises qui sont des acteurs de l’écosystème du logiciel libre, et notamment des éditeurs de logiciels libres. J’ai également fondé plusieurs associations. La plus ancienne, l’AFUL, qui avait notamment signé en 1998 un accord-cadre avec le MEN pour assurer la promotion du libre dans l’éducation ; le CNLL, que je représente aujourd’hui ; et l’APELL qui est une fédération européenne d’associations nationales représentatives, et qui travaille depuis un an avec la Commission Européenne à la définition d’une stratégie open source pour l’Europe (qui sera, selon les informations dont je dispose, dévoilée dans les prochaines semaines).

Le libre et l’open source

J’interviens donc en tant qu’expert du logiciel libre et à ce titre mes commentaires concerneront bien plus largement les questions relatives aux logiciels libres que celles concernant l’open data.

Par ailleurs, je voudrais commencer par une clarification terminologique afin d’éviter tout risque de confusion. On oppose parfois logiciels libres et open source mais pour moi c’est une distraction qui n’a pas lieu d’être. Si l’on suit les définitions officielles, les logiciels libres sont en pratique des logiciels de sources, et les logiciels open source sont des logiciels libres.

Historiquement l’expression logiciel libre ou “Free software” a été la première à être utilisée. Il est apparu, notamment lorsque des entreprises ont commencé à se créer au sein de l’écosystème du logiciel libre, aux USA, qu’elle posait problème à cause du terme “free” qui peut signifier à la fois libre et gratuit en anglais. En 1998 un groupe d’entrepreneurs et d’activistes du logiciel libre américains ont proposé d’utiliser plutôt l’expression “open source”. En effet il était important et je pense que c’est toujours le cas aujourd’hui, de faire comprendre, pour faire court, que le libre n’est pas forcément gratuit et qu’au contraire, le logiciel libre est bien un objet susceptible d’une activité commerciale.

Les deux termes peuvent donc être utilisés de manière interchangeables. En France l’expression “logiciel libre” peut être préférée si on tient à la pureté de la langue française. En Europe il semble que la commission européenne ait choisi d’utiliser l’expression “open source”, mais on peut également entendre, dans une volonté de ne pas froisser les communautés qui seraient attachées à telle ou telle expression, les acronymes FOSS voire même FLOSS.

Au final, le marché du logiciel libre représente en 2020 environ 100 milliards d’Euros de CA annuel au niveau mondial, et en France 5 milliards d’Euros de CA et 50 000 emplois. Le CNLL représente pour sa part environ 300 entreprises du logiciel libre et du numérique en France.

Modalité de production du logiciel libre

Pour autant les logiciels libres et open source présentent une très large variété dans leurs modes de production et de commercialisation, et il y a lieu d’apporter quelques précisions avant d’entrer dans le vif du sujet.

Historiquement, i.e. jusqu’à la fin des années 90, le logiciel libre était très majoritairement issu du monde de la recherche et de l’enseignement supérieur, et notamment d’universités américaines comme le MIT, Berkeley, université de l’Illinois, etc.

Depuis, la situation a largement changé. On trouve encore des logiciels de premier plan issus du monde académique. Néanmoins la majorité des logiciels libres produits et utilisés dans le monde est probablement aujourd’hui issue d’acteurs privé:

• Editeurs de logiciels libre, i.e. entreprises, startups ou PME, qui produisent du logiciel dans le but d’en tirer des revenus.
• Communautés formalisées, ce que l’on appelle souvent les “fondations”
• Communautés informelles, rendues possibles grâce aux outils de collaboration sur Internet
• Grandes entreprises qui utilisent du logiciel libre et y contribuent de manière stratégique (i.e. dans des stratégies d’influence) ou tactique.
• Individus (le logiciel est toujours, in fine, créé par des individus, mais je pense en l’occurrence à des individus qui agissent à titre personnel et non dans le cadre d’un contrat de travail avec un tiers).

Il y a donc, dans les écosystèmes qui produisent du logiciel libre, une très large diversité d’acteurs.

Dans cette typologie, l’Etat peut être assimilé à une “grande entreprise”.

Par ailleurs, pour un logiciel libre donné, les modes de développement peuvent également être très variés. On a des projets importants voire cruciaux qui ne sont portés que par une seule personne ou un tout petit groupe de personnes, tout comme on peut avoir des projets avec des centaines voire des milliers de contributeurs, avec souvent dans ce cas des structures de gouvernance plus ou moins complexes qui sont mises en place, soit à travers les grandes fondations du logiciel libre, soit par des associations ad hoc.

Dans sa façon de produire et de publier des logiciels libres, s’il souhaite enclencher de véritables dynamiques collaborative en-dehors de ses propres services, l’Etat devra nécessaire prendre en compte cette diversité.

L’utilisation du libre selon la Loi française

Ce que dit la Loi

Le libre est à ma connaissance cité deux fois nommément dans la Loi française.

La première occurrence est la loi ESR sur l’enseignement supérieur et la recherche de 2013 où l’on peut lire ( l’article 9 de la loi ESR de 2013 ) “le service public de l’enseignement supérieur met à disposition de ses usagers des services et des ressources pédagogiques numériques. Les logiciels libres sont utilisés en priorité.”.

La deuxième occurrence, qui est de portée beaucoup plus générale, est l’article 16 de la loi “République numérique” de 2016 : “[Les administrations concernées] encouragent l’utilisation des logiciels libres et des formats ouverts lors du développement, de l’achat ou de l’utilisation, de tout ou partie, de [leurs] systèmes d’information.”

La loi Lemaire, sans faire le lien explicitement, mais c’est implicite compte-tenu du contexte, mentionne les avantages du logiciel libre: “préserver la maîtrise, la pérennité et l’indépendance des systèmes d’information [des services de l’Etat].”

Les limites de la Loi sur ces sujets

Malheureusement, dans les deux cas, on constate que le législateur n’a pas donné un caractère contraignant à ce qui reste des déclarations de principes, même si, selon nous, elles vont plutôt dans le bon sens.

Pour ce qui est de la loi ESR, il n’y a pas, à notre connaissance, d’inventaire complet de l’ensemble des logiciels utilisés, libres ou non, ni de justification systématique de l’utilisation des logiciels non libres lorsque c’est le cas. Des témoignages anecdotiques nous permettent quand même confirmer que les logiciels non libres sont encore largement utilisés.

A ce sujet, un appel d’offres récent du Ministère de l’Education Nationale concernant l’acquisition de licences d’une centaine de logiciels Microsoft sans aucune justification ni réelle mise en concurrence et surtout sans justification de l’utilisation de ces logiciels plutôt que leurs équivalents libres, nous pose évidemment quelques questions.

Pour ce qui concerne la loi Lemaire, on constate, là encore selon des sources anecdotique, que l’article 16 n’a pas eu un impact sensible sur les marchés publics. On ne voit pas passer beaucoup plus d’appels d’offres qu’il y a par exemple 10 ans qui mentionnent explicitement une préférence pour le logiciel libre dans les critères d’attribution du marché. Nous regrettons aussi que la mission d’encouragement à l’utilisation des logiciels libre n’ait été confiée explicitement à aucune agence de l’État, et en particulier pas la DINUM dont cela aurait pu être l’une des missions principales.

Il est à notre sens possible, et souhaitable, de donner un caractère plus contraignant à ces “encouragements” prévus par la loi, par des directives plus précises données aux sein de chaque administration.

Un exemple à suivre, à notre avis, est la directive de 2006 publiée par la DGSIC du Ministère de la Défense “portant sur les logiciels du ministère de la défense” (référence NOR DEFM0652897X):

Outre les avantages liés à la disponibilité du code source, les logiciels libres permettent de vérifier le respect des standards et favorisent l’interopérabilité. Le ministère de la défense doit s’efforcer, avant toute acquisition ou tout développement interne ou sous-traité, d’identifier des solutions alternatives en logiciels libres disponibles, de fonctionnalité équivalente ou voisine.

Il faut donc rechercher la libre disponibilité des logiciels acquis par le ministère de la défense :

• à coût global, risques et efficacité opérationnelle comparables, le logiciel libre est privilégié ;
  l’utilisation de certains logiciels libres peut être imposée aux contractants ;
• le bien fondé de solutions comprenant tout ou partie de logiciels libres doit être systématiquement étudié ;
• en cas d’acquisition de logiciels « propriétaires », la solution d’une licence libératoire est systématiquement étudiée par le porteur du besoin.

La publication des codes source de l’Etat

La Loi pour une République Numérique, dans son article 1, pose le principe de la communication des documents administratifs et en particulier des codes sources des applications développées par les services de l’État. La loi met seulement en avant que ces codes sources doivent pouvoir être réutilisés par d’autres services de l’Etat, mais la liste des licences pour ses codes sources fixée par décret ne contient que des licences de logiciels libres (et open source).

Il s’avère donc que les logiciels produits par les services de l’Etat sont potentiellement tous, sauf peut-être pour des exceptions justifiées, susceptibles d’être réutilisés par l’ensemble de la société, que ce soit d’autres services de l’État, les individus, les entreprises, les associations, etc.

Publier du logiciel libre, pour quoi ?

Comme on vient de le voir, les raisons premières de l’ouverture des codes sources de l’Etat sont, selon la Loi Lemaire:

• La transparence: nous n’y reviendrons pas, c’est une des valeurs fondamentales du logiciel libre, mais ce n’est pas le seul facteur discriminant.
• La réutilisation par d’autres services de l’Etat (“mutualisation”), qui permet de “préserver la maîtrise, la pérennité et l’indépendance [de ses] systèmes d’information” comme déjà cité.

La possibilité de réutiliser ces codes sources par le secteur privé, et les modalités de cette réutilisation, ne sont pas envisagées explicitement. Je lis quand même entre les lignes de votre lettre de mission que c’est un sujet d’intérêt pour l’Etat, notamment quand il y est question de l’impact que cela pourrait avoir sur “l’innovation et le passage à une économie de la connaissance”.

Modalité de partage

On peut noter, et s’en réjouir, que certaines modalités de partage ont été précisées dans un document publié par la DINUM, intitulé “Politique de contribution aux logiciels libres de l’État”.

Ce document présente à mon sens un certain nombre de points positifs:

• Reconnaissance du travail des individus
• Autorisation à contribuer par défaut à des projets tiers, pour peu qu’ils soient bien sous licence libre et open source.
• Prise en compte de la viscosité que peut créer dans certains cas les “Corporate Contributor Agreements”. (En notant au final que le cas ne s’est jamais présenté).
• Explications claires concernant le choix des licences lorsque les développeurs sont amener à publier un nouveau projet.
  Evocation des best practices visant à faciliter la réutilisation des paquetages par des tiers.

J’ai néanmoins identifié deux points qui peuvent constituer des freins à une réutilisation large des logiciels publiés:

• Concernant le choix des licences, le document évoque bien les critères qui peuvent donner lieu au choix d’une licence à réciprocité vs. permissive. Il laisse néanmoins le choix final aux développeurs concernés, sans que des directives claires ne soient données sur ce sujet. Or ce choix va impacter la possibilité éventuelle pour un industriel de réutiliser ce code source. Beaucoup d’industriels sont hostiles à l’idée d’intégrer du code appartenant à des tiers et sous licence à copyleft dans leurs produits.
• La question de la cession du logiciel à une communauté ayant pignon sur rue, n’est pas posée. Ce n’est pas forcément très courant, et à vrai dire je ne suis pas sûr.

L’inventaire par Etalab

Etalab publie un inventaire des dépôts de code source de différents services de l’Etat. 4600 dépôts, développés par 360 agences, services ou d’établissements dépendant de l’Etat, sont actuellement recensés. Il s’agit bien évidemment d’une resource très utile et j’en profite pour saluer le travail de Bastien Guerry au sein de la DINUM pour réaliser cet inventaire.

Pour autant, il n’est pas complet car il m’a semblé que de nombreux projets qui relèvent de la recherche, par exemple, ne sont pas recensés. Ce n’est pas forcément un problème, car les logiciels qui relèvent de la recherche me semblent devoir être traités très différemment des logiciels à usage administratif ou pour le rendu d’un service par l’administration, qui semblent constituer la majorité de l’inventaire.

Cf. aussi le Health Data Hub dont le dépôt ne contient pas, de ce que j’ai pu en juger, le code de l’application.

Cas du logiciel libre commandé par l’administration

Le guide de contribution de la DINUM mentionne expressément le cas de contributeurs à des logiciels de l’Etat salariés par des prestataires de service. J’ai présumé que cela concernait principalement le cas de développeurs en régie au sein d’un service concerné.

Je n’ai cependant rien trouvé, et pas entendu parler personnellement, de recommandations concernant des projets au forfait. Il y a en effet une différence fondamentale de modèle économique qui fait que les choses risquent de moins bien se passer dans le cas d’un projet au forfait, du fait que la création d'un projet open source selon les normes sociales en vigueur représente un effort donc un coût non-négligeable, susceptible d'impacter la marge du prestataire dans le cas d'un projet au forfait.

Je pense donc qu’il y a un sujet à creuser et à mon avis un guide présentant les contraintes et les best practices à imposer à un prestataire dans le cadre d’un projet au forfait qui a vocation, a priori, à être publié en logiciel libre, devrait venir compléter le guide du contributeur déjà existant.

Contributions de l’Etat aux grands marchés de support open source

Une enquête réalisée par le CNLL en septembre 2019 auprès d’une trentaine d’entreprises de la filière du logiciel libre en France, dont environ la moitié de sociétés ayant déjà répondu ou participé en direct ou en sous-traitance à un grand marché de support Open Source a permis de mettre en avant les limites et dysfonctionnements actuels de ces marchés. Il nous semblerait intéressant et utile que l’Etat favorise les contributions de ses agents et services au montage et au déroulement de ces marchés de support.

L’analyse des réponses à cette enquête met en évidence une image actuelle très négative des grands contrats de support notamment du point de vue de leur efficience pour les administrations, de leur capacité à financer les acteurs du développement et de la maintenance de logiciels libres, et de la capacité des acteurs de la filière à participer à ces marchés. Les solutions d’éditeurs, où se concentre une grande partie de l’innovation, ne sont pas présentes ou très mal supportées. La taille de ces marchés (limitant les réponses à de grandes SSII ou ENL, Entreprises du Numérique Libre), leur périmètre (plusieurs dizaines, voire centaines de composants / solutions à supporter) et l’intérêt des titulaires (capter la valeur, la marge) sont antinomiques à l’expertise ou la qualité espérée des prestations. Les experts se détournent de ces marchés qu’ils jugent peu efficaces, peu intéressants et inaccessibles pour eux dans des conditions raisonnables. Leur expertise n’est pas valorisée et les groupements ou partenariats avec les titulaires sont jugés très défavorables et déséquilibrés.

Les principales préconisations rapportées lors de l’enquête sont de privilégier aussi souvent que possible une relation étroite entre les administrations et les éditeurs de logiciels libre. Les groupements d’experts sont vus comme une solution qui peut être pertinente, à condition que, contrairement à ce qui est perçu aujourd’hui, leur gouvernance soit saine et permette de respecter tous les maillons de la chaîne de valeur.

Cas de la valorisation des LL issus de la recherche

Il y a plusieurs facteurs à prendre en compte.

Le premier, c’est le mouvement, depuis quelques années, pour une science reproductible, ce qui implique, dans un monde où la science est de plus en plus faite avec des logiciels, la publication, tant qu’on y est en open source, des codes sources des logiciels utilisés pour faire de la science. A ce sujet, saluons l’initiative portée depuis maintenant 5 ans par Roberto Di Cosmo qui vise à archiver l’ensemble de la production logicielle qui peut l’être, en commençant pas le logiciel libre, avec comme finalité, entre autre, de permettre

Plus généralement, il y a un mouvement pour le “default to open” dans la production logicielle de la recherche publique. L’idée étant qu’en faisant de l’open source on maximise les chances d’impact societal, tout en réduisant l’overhead infernal des contrats de valorisation, qui au final n’ont que très très rarement un impact financier positif pour les établissements de recherche.

On pourrait d’ailleurs, pour verifier cette hypothèse couramment admise chez les chercheurs, il faudrait “ouvrir” les données concernant les revenus lies aux contrats d’exploitation de licences de logiciels de recherche.

Ensuite, il faut je pense explorer d’autres voies de valorisation des logiciels issus de la recherche. J’en vois au moins deux:

• L’essaimage traditionnel, mais avec des spin-offs dont le modèle économique est fondé sur le logiciel libre. Ex: OCaml Pro.
• Le fait de faire porter des logiciels, une fois qu’ils ont acquis la maturité pour être exploités industriellement, par des Fondations, comme par exemple la Fondation Inria a pu le faire pour plusieurs logiciels libres, dont Scikit-Learn, la bibliothèque de machine learning la plus utilisée dans le monde. On peut par ailleurs citer l’annonce récente de l’Inria de proposer, via un dispositif baptisé “Inria Academy”, des formations sur un certain nombre des logiciels produits dans ses labos me semble à saluer.

L’open data

En dehors des codes sources qui nous ont occupés jusqu’à présent intéressons-nous maintenant à l’open data de manière plus globale.

La loi Lemaire a prévu la publication par les services de l’État de neuf jeux de données dits “de référence” qui sont essentiellement des informations géographiques, des informations sur les entreprises et les associations, et des informations sur l’emploi.

Ce sont des données utiles pour notre écosystème et à titre personnel je peux témoigner que mon entreprise a pu exploiter une partie de ses données de référence et dans le cadre de plusieurs projets. Dans les secteurs connexes, on pourrait rajouter les informations sur les entreprises issues des greffes des tribunaux de commerce, d’autre type d’informations géographiques notamment sur les communes de France et plus généralement les entités administratives françaises, ou les informations sur l’emploi issues de Pôle-Emploi.

Concernant les autres jeux de données dont la publication pourrait s’avérer utile, à titre personnel j’en vois deux:

• Les données sur la valorisation de la recherche, comme évoqué précédemment
• Les données sur les projets de R&D financés par l’Etat (FUI, etc.)

Mais il me sera facile d’interroger nos membres pour voir s’ils ont d’autres idées.

L'interopérabilité

L’interopérabilité est un autre sujet à la marge des sujets de votre missions qu’il peut être utile d’aborder.

Citons à ce sujet le rapport de la Sénatrice Catherine Morin-Desailly en 2014 “Nouveau rôle et nouvelle stratégie pour l’Union européenne dans la gouvernance mondiale de l’Internet” dont l’une des propositions était: “encourager le développement des logiciels libres par leur intégration dans les marchés publics et par l’imposition de standards ouverts, à condition de développer les compétences pour l’utilisation de ces logiciels et standards.” Source: http://www.senat.fr/rap/r13-696-1/r13-696-11.pdf.

Ce serait une erreur que d’assimiler aveuglément logiciel libre et interopérabilité, mais les deux sont néanmoins fortement liés, comme on peut le voir dans la citation de Mme Morin-Desailly. En effet, l’interopérabilité est assurée par l’utilisation de standards ouverts, i.e. dont les spécifications techniques sont publiques et sans restriction d’accès ni de mise en œuvre. L’immense majorité des protocoles de communication, des formats de données et des langages de programmation présentent de nos jours au moins une implémentation sous forme de logiciel libre.

En France, le RGI ou Référentiel Général d’Interopérabilité est un document de référence concernant les standards ouverts à utiliser au sein de l’administration. Comme pour les encouragements à l’utilisation des logiciels libres, il reste encore trop souvent ignoré par les services concernés.

Enfin on peut noter que les géants du cloud, que l’on appelle parfois les hyperscalers ou tout simplement les GAFAM, s’ils s’appuient massivement sur des logiciels libres pour faire tourner leurs services, et sont très ouverts dans les spécifications de leur API, n’en présentent pas moins des stratégies de vendor lock-in redoutables qui obligent à la vigilance lorsque l’on déploie une application dans le cloud d’un opérateur avec l’espoir de pouvoir en changer facilement ultérieurement.

Nos propositions en résumé

• Rendre actionnable l’article 16 de la Loi Lemaire, par exemple par la création d’une mission dédiée au logiciel libre dans l’administration, sous tous ses aspects, et indépendante des structures existantes.
• Compléter le Guide du contributeur open source de l’Etat
• Ecrire un guide concernant les projets au forfait
• Appliquer plus strictement le RGI
• Tenir compte des phénomènes de vendor lock-in lors des déploiements de logiciels libres dans le cloud

Et plus généralement:

• Avoir à l’esprit, lors de la rédaction de politiques publiques en matière de logiciel libre, le développement du tissu économique, notamment local et européen, en parallèle des motivations internes à l’Administration.