Open source et traitement des données : un modèle fiable

Titre : Open source et traitement des données : un modèle fiable !

Intervenants : Bastien Guerry - Yves-Alexis Perez - Su Yang - Stéphane Trainel

Lieu : Séminaire Data

Date : 21 octobre 2021

Durée : 1 h 09 min

Vidéo

Licence de la transcription : Verbatim

Illustration : À prévoir

NB : transcription réalisée par nos soins, fidèle aux propos des intervenant·e·s mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.

Transcription

Stéphane : Bonjour à tous et à toutes. Merci de nous avoir rejoints pour cette deuxième conférence de l’année je dirais presque scolaire, de septembre 2021 à juin 2022.
Je suis Stéphane Trainel, je travaille au secrétariat général des ministères économique et financier dans un dispositif qui s’appelle Bercy Hub, que vous connaissez peut-être un petit peu, où on fait un travail qui, finalement, mêle les données et le numérique. On a la conviction que sur ce mélange des données et du numérique on peut obtenir des transformations que je souhaite les plus durables possible dans les structures.
Ça ne vous a peut-être pas totalement échappé, il y a quelque temps il y a eu une circulaire du Premier ministre qui a demandé aux ministères de produire une feuille de route de la donnée, des algorithmes et des codes sources, que, au sein de Bercy, nous avions déjà un petit peu préparée et pensée avant, donc nous l’avons mise à jour et elle a été rendue publique en septembre. Évidemment je ne vais pas vous rappeler toute la feuille de route, je vais juste évoquer trois points importants.
Le premier c'est la culture de la donnée. La photo c’est un petit peu disruptif, la culture, mais acculturer l’ensemble des agents publics du ministère à ce qu’est la donnée, à ce qu’est le numérique et quelles sont les transformations qui sont rendues possibles en mêlant ces deux volets.
Le deuxième axe de la feuille de route, c’est l’architecture, c’est-à-dire comment on peut mettre en place une organisation à la fois au sein du ministère pour faire en sorte que les données, les algorithmes, les codes sources soient structurés, soient organisés, soient animés, mais également l’architecture peut-être plus technique où on va mettre en place des espaces qui vont permettre de pouvoir utiliser et valoriser les données. Vous entendez probablement souvent parler de data lake ou de « Lac des données » et c’est effectivement là où on va essayer de les mettre en place.
Dernier axe. Évidemment une fois qu’on a acculturé les agents et qu’on a une connaissance à peu près des possibles, une fois qu’on a l’architecture à la fois organisationnelle et technique, on va pouvoir utiliser, valoriser ces données et en tirer plein d’usages, en particulier, par exemple, au secrétariat général on est assez friands de data visualization qui permet de comprendre ce que portent les données. On est également assez friands d’outils à base d’intelligence artificielle pour aider le travail des agents et leur faciliter la vie sur des tâches parfois répétitives, c’est donc dans ce volet de la feuille de route qu’on va déployer un certain nombre de solutions.

Aujourd’hui, évidemment, nous allons parler de code source. On va parler toujours évidemment de données et se poser la question de savoir si code source et traitement des données, on a un modèle viable.

Je vais vous présenter tout de suite nos intervenants de cette deuxième conférence-débat.
Je vous donne tout de suite, si vous voulez poser des questions à nos intervenants, comme on est en ligne, fortement en ligne, le numéro de téléphone pour envoyer un SMS, on partagera les messages en fin d’intervention.
Je vais vous présenter les différents intervenants de ce matin.
Nous avons le plaisir d’accueillir Bastien Guerry qui est le référent logiciels libres de la direction interministérielle du numérique. Bonjour Bastien.

Bastien Guerry : Bonjour.

Stéphane : Nous avons également le plaisir d’accueillir Yves-Alexis Perez qui est le porte-parole open source de l’Agence nationale pour la sécurité des systèmes d’information, l’ANSSI. Bonjour Yves-Alexis.

Yves-Alexis Perez : Bonjour.

Stéphane : Nous accueillons également Su Yang qui est le responsable du pôle données de la Délégation à la transformation numérique de la direction générale des finances publiques. Bonjour Su.

Su Yang : Bonjour.

Stéphane : On commence, si vous voulez bien, directement dans le sujet. On parle effectivement beaucoup d’open source, c‘est devenu presque un mot extrêmement à la mode et parfois, peut-être, un peu réservé à un certain public de geeks. Ce n’est peut-être pas toujours le cas. Ça peut être intéressant, pour débuter, de nous expliquer ce que c’est que l’open source, essayer de poser quelques définitions. Je vais demander à Bastien d’essayer de poser ce cadre, qu’est-ce que l’open source ?, et de nous apporter un éclairage extrêmement pédagogique puisque c’est un peu l’ambition de ces conférences de base, c‘est qu’on puisse bien présenter les choses à nos participants.

Bastien Guerry : Merci beaucoup Stéphane. Merci pour l’invitation.
L’open source, il faut se projeter il y a 50 ans, dans les années 1970, dans un univers où ce qui coûte le plus cher ce sont les machines, où le logiciel vient souvent directement avec la machine sans que les clients en aient bien conscience. Où il n’est pas encore systématiquement vendu séparément. Où réellement c’est une affaire de chercheurs et de techniciens qui créent des logiciels qui permettent de faire tourner les machines, mais le logiciel n’a pas émergé, le code source n’a pas encore émergé comme objet propre.
On est obligé de raconter un peu cette histoire un peu fondatrice qui est entrée dans la légende : au MIT, à Boston, se trouve un développeur, un hacker, au laboratoire d’intelligence artificielle, Richard Stallman, qui se trouve un jour confronté au fait que son imprimante ne marche pas, souhaite la réparer et se voit répondre qu’il n’a pas le droit de le faire, qu’il n’a pas le droit de modifier le code source de son imprimante. Face à cette situation qui est anecdotique mais qui, pour lui, parle déjà des droits que les acteurs privés commencent à imposer pour limiter l’accès au code source, il réagit en se disant « attention, c’est la fin de la communauté des hackers qui s’échangeaient du code source librement, des chercheurs qui partageaient cette connaissance », le code source étant vraiment vu au départ comme une source de connaissance avant même d’être un actif technique. Partant de là, il démarre un mouvement pour sauver cette communauté des hackers qui va essayer de relancer une réécriture du système utilisé dans les universités de l’époque, le système Unix qui commençait justement à être refermé, à avoir des droits par-dessus, et il appelle ce système GNU pour dire GNU is not Unix et il lance le mouvement du logiciel libre.
Je lance cette anecdote, mais après je vais passer à grands traits sur la suite. On peut dire qu’il y a les années 70 où c’est un peu ce que j’appelle l’âge inconscient, les gens partagent du code source naturellement entre administrations, entre laboratoires de recherche, sans avoir conscience de faire du code source en particulier.
Il y a le deuxième âge des années 80 où il y a cette prise de conscience initiée par Richard Stallman, relayée par la communauté des hackers, c’est vraiment l’âge d’une construction technique d’un système alternatif. Système qui ne devient connu du grand public qu’à partir des années 90 quand un hacker finlandais, Linus Torvalds, crée le noyau Linux permettant à plein d’étudiants d’accéder au système GNU qui a été construit pendant dix ans. C’est vraiment une construction lente.
Années 90, ça touche plus en plus de personnes, c’est combiné au Web et aussi à un dispositif juridique, les licences libres, qui émerge à ce moment-là, porté par la Fondation pour le logiciel libre, et qui prend le contre-pied de la démarche classique de copyright en disant « on va créer un dispositif permettant à chacun de partager et de s’assurer que ce qu’on partage est vraiment libre d’accès pour tous et permet aussi d’encourager les contributions réciproques ».
À partir des années 2000, une sorte de nouvel âge s’ouvre qui est vraiment l’âge de l’open source. Le terme open source a été lancé à la fin des années 90 par Eric Raymond et d’autres pour dire nous ne sommes pas juste une communauté de hackers qui essaient de survivre avec des logiciels. En fait, tous nos logiciels sont déjà « business-ready », entre guillemets, pour reprendre le terme de l’époque. Mettons de côté le militantisme politique associé au logiciel libre et allons à la conquête de l’entreprise. C’est vraiment la veille de la bulle internet, on a déjà plein de serveurs web qui utilisent une solution libre qui est Apache. C’est vraiment à la fois la conquête des acteurs privés.
On a un âge, c’est plus flou, pour tout ce qui est contemporain, mais je dirais les années 2010 à 2020.
Pardon, je reviens à 2001 parce que c'est aussi la création des licences Creative Commons. On propage les idées du Libre au-delà du logiciel et c’est aussi la naissance de Wikipédia, donc l’idée de collaboration massive par Internet prend forme dans les grands communs.
. 2010/2020 c'est justement l’âge des communs numériques. On se rend compte que oui, ça fonctionne de solliciter les gens pour qu’ils contribuent à un projet commun. Ça fonctionne pour le noyau Linux depuis le début des années 90, ça fonctionne pour Wikipédia, ce n’est pas juste pour du logiciel.
Aujourd’hui, les années 2020/2030, j’espère que ce sera l’âge des rapports plus nombreux de l’administration publique avec le logiciel libre.

Si je peux prendre encore trois/quatre minutes, je voudrais maintenant faire un panorama à grands traits sur les rapports entre l’administration et le logiciel libre, on va dire le politique et le logiciel libre et surtout l’administration.
On a l’âge des précurseurs. 1999, le sénateur Laffitte demande l’obligation d’utiliser du logiciel libre dans l’administration. Ça n’est pas suivi d’effets, mais à noter que ça a déjà 22 ans.
L’autre précurseur c’est Michel Rocard qui contacte les communautés de libristes et qui mène avec eux la bataille contre les brevets logiciels en Europe. On vit sous l’héritage Rocard à ce sujet-là et ça a été important pour que d’autres parlementaires, hommes et femmes politiques, puissent se sensibiliser au sujet.
On a ensuite l’âge de l’engagement et, pour moi, c’est vraiment la DGFiP qui a été ici précurseur avec le projet Copernic, par exemple, et avec la formulation des trois principes qu’on retrouve dans la loi Lemaire qui sont la maîtrise, l’indépendance et la pérennité. L’administration, avant même qu’on parle de souveraineté, d’autonomie stratégique, s’était focalisée sur ces trois valeurs. Il faut à tout prix, en tant que directeur des systèmes d’information, que j’assure la maîtrise de mon SI, l’indépendance de mon SI et la pérennité qui sont des enjeux à la fois humains et techniques et j’observe que le logiciel libre m’aide à faire tout ça. La DGFiP s’engage à faire tout ça et elle est la première à le faire aussi fortement dans l’administration, dans le logiciel libre. On en a encore aujourd’hui le legs historique avec la DGFiP qui gère le marché de support logiciels libres pour toutes les administrations.
On a ensuite un âge, je dirais de 2012 à 2016, qui est celui de la convergence. C’est la circulaire Ayrault qui dit, en résumé, « le logiciel libre c’est bon, mangez-en, et surtout c’est un peu chaotique, c’est difficile de comprendre, donc faites en sorte que les ministères convergent sur des solutions techniques, s’accordent entre eux et qu’on puisse recommander telle base de données ou tel logiciel ». C’est un âge qui aboutit à 2016 avec la loi Lemaire qui dit non seulement qu’on peut ouvrir les codes sources, que ce sont des documents administratifs communicables – c’est pour ça qu’on retrouve les codes sources dans tout le travail de feuille de route que Stéphane a mentionnée, que je tiens à saluer au passage parce qu’on a 500 actions sur l’ensemble de toutes les feuilles de route dont plusieurs concernent le logiciel libre directement. La loi Lemaire dit donc qu’on ouvre les codes sources et, en plus, on renforce l’utilisation du logiciel libre, l’article 16 cite les trois principes que j’ai cités tout à l’heure, maîtrise, indépendance, pérennité.
Aujourd’hui la DINUM construit un pôle logiciels libres qui reprend vraiment ces deux axes simples : renforcer l’utilisation des logiciels libres, accompagner à l’ouverture des codes sources, en ajoutant une troisième dimension qui est de renforcer l’État employeur dans son attractivité auprès des talents dans le numérique, qui s’intéressent au logiciel libre, parce qu’on a vraiment une convergence de valeurs entre logiciel libre et intérêt général.
Je terminerai en disant que ce qui nous guide côté DINUM et côté pôle logiciels libres dans tout ce travail c’est l’empathie. On a appris, des années de la mission Etalab, de nos erreurs, on sait que la première chose à faire c’est comprendre les contraintes d’une administration. On n’arrive pas avec une doctrine ni un bâton de gendarme pour essayer de faire ouvrir, ça ne marche pas. On essaye de comprendre ce qui permet, dans l’ouverture, de valoriser telle ou telle action, d’accélérer la transformation numérique et on accompagne.
Deuxième principe c’est l’entraide. C’est difficile, il y a des grands ministères qui ont tous des actions particulières, donc on veut valoriser ces actions pour favoriser l’entraide entre ministères quand elle peut se faire de façon formelle ou informelle. Donc nous n’arrivons pas avec une offre de service complètement packagée qui permet de tout prendre en charge, on est trop peu nombreux, mais on peut essayer de favoriser cette entraide.
Le troisième principe c’est la rigueur dans le sens où ça demande vraiment que ce soit non pas uniformisé, mais que l’administration se concerte pour rationaliser toutes ses démarches, qu’on le fasse aussi dans le respect de la politique du cloud qui pose des limites, qui pose des questions.
Empathie, entraide, rigueur. Ce sera tout pour moi.

14’ 50

Stéphane : Merci Bastien.
Est-ce que tu pourrais citer un exemple, ou plusieurs, qui permette de comprendre finalement la différence entre code propriétaire, fermé, et puis code source ouvert, accessible et qui peut être utilisé. Aujourd’hui, dans le quotidien, on a tous de téléphones sur les tables, on est tous utilisateurs d’ordinateurs, de tablettes, est-ce qu’on sait, par exemple, donner des petites segmentations pour des outils grands usages ?

Bastien Guerry : Oui. Pour les outils grands usages, sur le poste de travail de l’agent on a, par exemple, Firefox qui est un logiciel libre et qui est l’équivalent libre de Edge dont le code source n’est pas connu. Ça permet de s’assurer de la transparence, de ce que fait le navigateur web quand on se promène sur le web.
On a aussi LibreOffice qui est la suite bureautique, qui a pu laisser beaucoup de mauvais souvenirs de-ci de-là dans l’administration, qui est un exemple de volonté politique mais qui n’est pas suivi d’une vraie conduite du changement. Je pense qu’il faut qu’on rétropédale sur ce mauvais souvenir puisque les enjeux du logiciel libre se jouent bien ailleurs, à mon avis, que sur le seul poste des agents publics.
On a des logiciels comme GIMP, qui est un logiciel de manipulation d’images qui est un peu le clone de Photoshop. On a toute cette série de logiciels libres qui essayent d’être des clones de solutions propriétaires existants. Et puis on a des domaines comme les serveurs web, que je citais tout à l’heure, où là en fait les logiciels libres sont dominants et c’est le contraire, c’est difficile de trouver des équivalents propriétaires.

Stéphane : Et dans l’administration, est-ce que tu aurais un exemple, ou deux, sur un outil qui a pu être développé, rendu ouvert et qui peut être connu ou reconnu d’intérêt ?

Bastien Guerry : Je donne un exemple, c’est peut-être anecdotique, mais on a un framework en Python qui s’appelle Django, qui permet de développer des services web assez rapidement. C’est déjà du logiciel libre, mais l’administration a adapté ce logiciel libre au design system du gouvernement. Le design system forçant l’harmonisation visuelle des différents sites en .gouv.fr demande d’être décliné et le fait de disposer du code source des différents frameworks ou de travailler sur des frameworks libres permet de partager ça beaucoup plus facilement. En termes de construction de sites et d’outils, tout ce qui sera design system du gouvernement c’est souvent le suffixe DSFR et si on cherche ce suffixe sur la plateforme code.etalab.gouv.fr, on va trouver tous les outils qu’on a à disposition, que les prestataires peuvent évidemment utiliser pour construire des sites du gouvernement.

Stéphane : Merci beaucoup Bastien. C’est important de bien reposer quelques éléments et cette frise temporelle, je pense effectivement que ça raconte à nouveau l’histoire, c’est important, ça participe au décor.
Je retiens en particulier le mot « maîtrise » parce que, effectivement, il y a un enjeu important. On voit que l’administration est invitée à la fois à utiliser de l’open source mais également à en publier. On peut aussi se poser, forcément, la question de la sécurité. Est-ce qu’il n’y a pas une espèce de paradoxe, finalement, entre dire « je vais ouvrir du code qui va être accessible de tous » et puis peut-être la souveraineté, la sécurité de ce code dans son usage. On va poser la question à Yves-Alexis. Aujourd’hui, finalement, est-ce qu’il y a un paradoxe ou pas ? Est-ce que la sécurité des systèmes d’information est compatible avec l’open source, l’ouverture ?, avoir le regard de l’ANSSI sur ce sujet.

Yves-Alexis Perez : Merci Stéphane.
C’est effectivement une question tout à fait légitime. Sans trop déflorer la suite, je dirais tout de suite que non, il n’y a pas de paradoxe, on peut tout à fait concilier les deux. Ceci dit, il y a des précautions à prendre et on va aborder un petit peu le sujet.
Sur la partie open source et logiciel libre et pour reprendre typiquement ce que Bastien a évoqué tout à l’heure. Globalement open source et logiciel libre c’est quasiment la même chose pour tout le monde. Richard Stallman a défini les principes du logiciel libre et a donné quatre libertés fondamentales. La première, notée 0 du fait qu’on compte souvent à partir de 0 en informatique, c’est la possibilité d’utiliser le logiciel parce si on ne peut pas l’utiliser c’est compliqué. Ça ne suffit pas, on est aussi capable de l’étudier, savoir comment il fonctionne et le modifier. Éventuellement le redistribuer, que ce soit à des amis, à des collègues, qu’ils soient chercheurs ou autre ou finalement à d’autres administrations, voire des clients. Ça peut être des redistributions commerciales, et éventuellement le modifier et redistribuer les modifications. À la fois pour l’étudier, pour le modifier et redistribuer les modifications, on a besoin de l’accès au code source.
Dans le cadre de ce qu’on appelle l’open source, l’accès au code source en général ne suffit pas. Il y a d’autres critères, mais globalement on peut dire que c’est assez proche.
Pour les administrations et pour les utilisateurs finaux, la première liberté qui est celle d’utiliser le logiciel est souvent vue comme la plus importante et c’est souvent vu comme un avantage financier, à savoir que c'est un logiciel gratuit. On a souvent confondu ça avec le freeware. En pratique, ça peut être un avantage financier, ce n’est pas toujours le cas. L’utilisation d’un logiciel par rapport à un autre a d’autres coûts que simplement, par exemple, l’acquisition de licence et, en pratique, sur le long terme ce n’est pas forcément non plus intéressant et la plus intéressante de ces libertés.
Pour donner aussi un petit peu des exemples de choses que les gens peuvent éventuellement connaître, on a mentionné les distributions Linux, on peut mentionner de vielles distributions Linux comme Debian, Red Hat, Stackware, des choses plus modernes comme Arch, les suites bureautiques LibreOffice, des clients web, Firefox et Chromium, dont Edge est issu, qui est un logiciel libre, qui a été très modifié par la suite, des clients mail et, sur la partie infrastructure, effectivement la pile LAMP pour Linux, Apache, MySQL et PHP ; c’est un acronyme qui date pour le coup des années 80/90, mais il est encore très utilisé.
On peut aussi avoir typiquement des logiciels d’infrastructure comme OpenStack qui est une suite de virtualisation qui est extrêmement utilisée pour faire des clouds privés ou semi-privés. C’est un logiciel libre.
Il y a aussi des langages de développement, le langage lui-même est libre et les outils pour les utiliser le sont aussi.

Si on en vient à la partie sécurité, maîtrise et souveraineté de la partie utilisation, un des gros avantages de l’accès au code source c’est qu’on a une relecture du code source qui est possible et, en particulier, un audit de sécurité qui est possible. On est capable de savoir comment ça marche, en particulier du point de vue par exemple de l’ANSSI, mais c’est plus général, être capable d’identifier des vulnérabilités dans un code. On sait qu’il y aura toujours des bugs dans le code, c’est normal, mais on est capable de les identifier.
Au-delà d’identifier des vulnérabilités, ça permet d’avoir une certaine confiance dans le code source et d’être raisonnablement certain du fait qu’un code source, un logiciel fait ce pourquoi il est conçu et éventuellement ce pourquoi il est vendu. À savoir que si on a traitement qui repose sur un logiciel, qui implémente des algorithmes et que, par exemple, ce logiciel, peut-être un logiciel serveur, prend des décisions sur, au hasard, l’affectation d’élèves dans l’enseignement, c’est bien de savoir ce que ça fait, pourquoi et sur quels critères il agit. Même chose, par exemple, si un logiciel calcule les impôts que les contribuables doivent payer. Je donne ces deux exemples parce que ce sont deux exemples de logiciels qui ont été écrits par l’administration et qui ont été publiés.
En termes de maîtrise, quelque chose qui est aussi extrêmement intéressant, au-delà de l’accès au code source, c’est l’accès à tout ce qui est la communauté, tout ce qui va derrière, on va dire les métadonnées, en particulier l’accès aux dépôts, les dépôts du code source avec un historique des modifications, que les modifications soient documentées, tracées et qu’on soit capable de savoir qui a fait telle modification, pour quelle raison et, finalement, remonter un petit peu l’historique.
Ça permet aussi de l’assurer de l’intégrité du code source et des binaires qui sont générés. En général, les logiciels qu’on utilise sur un poste de travail sont sous forme binaire, compréhensible par le processeur de l’ordinateur, ce n’est pas sous cette forme-là qu’ils sont écrits et l’opération de conversion du code source en binaire, qui s’appelle la compilation, masque un peu, finalement. le fonctionnement du logiciel. Être certain que les logiciels qu’on exécute sur un porte proviennent bien du code source c’est quelque chose qui n’est pas possible avec du logiciel propriétaire. On fait confiance à l’éditeur pour qu’il maintienne effectivement cette propriété on va dire.
Au-delà, ça permet aussi de s’assurer qu’on est capable de reproduire les binaires qui nous sont fournis. Si on a accès au code source on peut se dire « je suis capable de reproduire à l’identique, bit pour bit, les binaires qui me sont fournis ». C’est quelque chose qui est extrêmement intéressant dans des attaques qu’on a pu constater dans le monde entier sur la chaîne d’approvisionnement, à savoir que quelqu’un, un attaquant, va s’attaquer non pas à vos systèmes d’information mais plutôt aux systèmes d’information du fournisseur, d’un éditeur de logiciels que vous allez récupérer sur son site, par exemple, et, en fait, vous allez récupérer quelque chose qui est déjà compromis et qui va éventuellement servir de rebond pour atteindre votre système d’information.
Le fait d’utiliser des logiciels libres c’est très bien, ça permet de faire plein de choses, ça n’est pas entièrement gratuit non plus et ce n’est pas magique. Effectivement on est capable, quand on a le code source, d’auditer, d’examiner, de modifier ; on est capable de reproduire les binaires, mais ça ne se fait pas tout seul. Il faut des gens, des ressources qui soient compétentes sur le sujet, ça demande des moyens humains et financiers. Ça peut être quelque chose qui est éventuellement délégué à l’extérieur, des gens en qui on aurait confiance. Ça peut aussi être quelque chose qui est partagé. On le voit typiquement au niveau de l’administration française, parfois plusieurs ministères se mettent ensemble, parce qu’ils utilisent les mêmes logiciels, pour partager la charge.
D’autre part, la partie gouvernance des projets est importante aussi. Un logiciel qui est open source ne veut pas forcément dire qu’il est communautaire, il y a encore une distinction à avoir. Typiquement, parmi les plus gros éditeurs de logiciels open source et développeurs de logiciels open source, on va retrouver d’énormes entreprises comme Google, IBM à laquelle appartient maintenant Red Hat, même Apple, qui éditent, produisent, publient des logiciels open source. Évidemment, ça ne veut pas dire que c’est là-dessus qu’elles font tout leur chiffre d’affaires, mais ce sont de très gros contributeurs. Pour autant, les décisions qui sont prises appartiennent à l’entreprise.
D’autre part, tous les projets n’ont pas les mêmes moyens. Certains projets assez fondamentaux sont même cruellement en manque de moyens. On a un exemple qui date un peu, qui date de 2014. La bibliothèque OpenSSL qui est au cœur de la protection des communications sur Internet, typiquement c’est ce qui sert à protéger les communications par exemple à destination de serveurs web en utilisant le protocole SSL ou maintenant TLS ; c’est très souvent implémenté dans cette bibliothèque. Il s’est trouvé qu’en 2014 un bug a permis de s’attaquer aux logiciels qui utilisaient cette bibliothèque, le bug s’appelle Heartbleed et ça a nécessité d’énormes travaux correctifs de la part de tous les utilisateurs d’OpenSSL. Cette erreur aurait pu, aurait dû être identifiée bien avant, mais l’équipe qui s’occupait d’OpenSSL manquait cruellement de moyens. Donc ça ne suffit pas d’avoir accès au code source, encore faut-il qu’il y ait effectivement des gens pour le regarder.
De là aussi est venue une initiative mondiale qui s’appelle la Core Infrastructure Initiative, qui vise à donner, à fédérer des moyens pour augmenter la résilience des différents logiciels libres utilisés au sein, par exemple, d’Internet, ce qui était le cas d’OpenSSL.
Ça montre aussi l’importance de ce qu’on appelle les communs à savoir que plus on est nombreux, plus on utilise les mêmes logiciels, plus on peut aussi partager la charge et, si on identifie des choses, on peut partager et corriger avant que ce soit trop tard.
De là, je mentionne aussi le fait qu’on n’oppose pas forcément open source et propriétaire. Il y a d’autres critères qui vont derrière, que ce soit pour la maîtrise, la gouvernance, etc.

29’ 40

C’était pour la partie utilisation .
Pour la partie contribution c’est un peu la suite naturelle de l’utilisation. À savoir qu’il n’existe pas de logiciel sans bug, qu’il soit libre ou propriétaire. L’avantage d’avoir accès au code source et de pouvoir le modifier, c’est qu’on a un accès qui est finalement plus facile, plus rapide à la communauté des développeurs et qu’il est parfois simplement plus rapide de fournir un patch si on a identifié le problème qu’il y a chez soi, qui se pose dans son utilisation du logiciel. Finalement fournir un patch, ne serait-ce déjà que l’identifier, le remonter, ça permet de faciliter la correction et ça permet d’aider la communauté des utilisateurs. Cette communauté des utilisateurs n’est pas une entité complètement abstraite à l’autre bout de la planète. Parfois c’est le bureau, l’administration d’à côté qui utilise le même logiciel et qui, finalement, a les mêmes problèmes.
Ça permet aussi d’adapter à des cas d’emploi spécifiques qui n’étaient pas forcément vus ou pas vus comme prioritaires. Un exemple assez local, finalement, c'est la traduction en français. Tous les logiciels libres ne sont pas forcément disponibles en anglais. Très souvent les développements sont faits en anglais et les interfaces utilisateurs sont en anglais. La traduction en français c’est quelque chose qui permet de mettre un pas dans la contribution et c’est extrêmement important pour la diffusion des logiciels au sein de l’administration française.
Parfois c’est l’ajout d’une fonctionnalité qui est utile uniquement dans un cas particulier.
Ça va être aussi la partie accessibilité, quelque chose qui est aussi assez important.

J’espère que c’est moins le cas maintenant, mais pendant assez longtemps, les gens prenaient la peine de modifier des logiciels pour les adapter localement mais gardaient en interne les correctifs, les modifications, en se disant que ça n’intéresserait personne. Malheureusement, du coup, ça amène une charge de maintenance sur le long terme des contributions. C’est nettement plus intéressant de contribuer ce patch, de le pousser aux développeurs amont, ce qui permet de limiter la charge, donc de partager aussi les modifications aux autres utilisateurs.

Du côté des administrations l’intérêt de tout ça c’est aussi de permettre une meilleure maîtrise du système. Ça permet aussi de rendre à la communauté. Typiquement le fait qu’on utilise des logiciels libres c’est très bien, c’est très pratique, y contribuer ça permet finalement d’avoir une contribution plus active et c’est souvent très bien vu.

En termes de maîtrise, on l’a mentionné tout à l’heure, le fait que le code source soit accessible permet d’examiner le code source. Pour autant, ce n’est pas toujours évident. Le fait de le modifier, de l’adapter ça donne une maîtrise qui n’a rien à voir avec le simple fait de lire. C’est un peu la même chose que quand on est à l’école, on apprend un cours. Si on ne fait juste que lire le cours, on n’en retient pas tant que ça. Si on le lit, on l’applique, voire on essaie de creuser un peu, on le connaît beaucoup mieux. C’est typiquement quelque chose qui a été pris en compte à l’ANSSI il y a de ça maintenant une bonne quinzaine d’années, avec un principe qui était que les noyaux de système d’exploitation, typiquement Linux pour ne pas le nommer, étaient au cœur de l’informatique moderne, de la même façon que la cryptographie, à l’ANSSI, est une des bases de la souveraineté. C’était important d’avoir une maîtrise, de savoir ce qui se passait dans les systèmes d’information donc dans les noyaux de système d’exploitation. De là est issu un projet qui s’appelait CLIP, de distribution Linux, qui était effectivement utilisé sur des postes d’agents, etc., mais qui permettait aussi de mettre les mains dans le noyau, de savoir comment ça marchait et d’avoir une bonne idée par exemple de son niveau de sécurité.
Les contributions ça demande évidemment des ressources qu’il faut prendre en compte et éventuellement sur le long parce que si on commence à contribuer, à maintenir, etc., c’est quelque chose qu’il faut prendre en compte. Ce n’est pas toujours énorme. Ce qui est aussi important à prendre en compte, c’est que parfois c’est un peu de la Shadow Maintenance, à savoir qu’il y a beaucoup d’acteurs publics qui, finalement, contribuent à des logiciels libres sur leur temps libre. En fait ce sont des logiciels qu’ils utilisent au quotidien et, comme ça leur plaît, ils contribuent sans forcément que ce soit reconnu. Du coup ces niveaux ne sont pas pris en compte alors que ce serait intéressant et valorisable.

Pour conclure, je vais aborder rapidement la partie publication, c’est l’étape d’après.
Énormément d’administrations françaises et autres développent du code en interne. Le partage de ces productions est extrêmement intéressant que ce soit en termes de visibilité mais aussi de maîtrise et de sécurité. Ça permet de partager ce qu’on fait, que ce soit réutilisé ailleurs. Ça permet des économies énormes et des convergences, quand tout le monde refait peu ou prou la même chose. Typiquement un exemple, ce sont les collectivités territoriales qui ont très souvent les mêmes prérogatives, par exemple la gestion sociale, l’action sociale dans les départements, la gestion des crèches, des cantines scolaires, etc., ça demande souvent des systèmes d’information derrière mais c’est peu ou prou la même chose. Il existe très certainement des logiciels métiers propriétaires qui le font, mais certaines collectivités territoriales se sont dit « on fera mieux parce qu’on connaît mieux notre terrain ». Ceci étant c’est assez répandu en France, donc il y a une part collective qui est intéressante à faire.
Un exemple aussi de logiciel qui est peut-être un peu moins utilisé de nos jours, c’est le logiciel Sympa [Système de Multi-Postage Automatique], un gestionnaire de listes de diffusion qui a été développé, de mémoire, par l’université de Strasbourg et qui a été extrêmement utilisé, c’était un des deux ou peut-être trois logiciels de listes de diffusion sur toute la planète. Il a eu un énorme succès. Finalement il a permis à énormément de gens de ne pas implémenter à nouveau eux-mêmes un logiciel de listes de diffusion.
Au passage c’est une obligation, Bastien l’a mentionné, la loi pour une République numérique dite loi Lemaire considère les codes sources comme des documents administratifs communicables. Le plus simple, quand même, pour communiquer des codes sources c’est effectivement de rentrer dans une logique de publication parce que ça a énormément d’avantages sur l’aspect communauté, visibilité et partage.

Par contre il y a un certain nombre d’enjeux, il ne faut pas se voiler la face. En particulier, je l’ai mentionné ici, la sécurité du code publié. Je pense qu’il y a des administrations qui se posent des questions sur le fait que potentiellement le code qu’elles ont développé depuis des années ne peut pas être exposé au grand public. C’est vrai. Ceci étant, les éventuelles vulnérabilités existent dans le code, qu’il soit publié ou pas. À la limite, le fait de l’exposer peut permettre d’identifier des vulnérabilités plutôt qu’elles soient exploitées sans que personne le sache. Au passage il est toujours possible de faire des audits préalables, ça demande un certain temps mais c’est quelque chose qui est tout à fait possible.
Pour moi l’important c’est vraiment de se mettre dans une logique de publication et de réfléchir à ce qu’on peut publier, comment, du coup d’analyser ces parties-là progressivement. On ne dit pas qu’il faut tout publier tout de suite, n’importe comment, en tout cas il y a vraiment l’aspect de rentrer dans une démarche.

Stéphane : Merci beaucoup. Du coup si je me projette, je suis chef de projet dans une direction du ministère et le projet démarre. Est-ce que je dois me poser tout de suite la question de l’open source ? Est-ce que, dès le départ, je dois me mettre dans cette mécanique-là pour la conduite du projet ? Première question. La deuxième : tu dévoiles déjà peut-être un peu la fin, il y a aura peut-être une redite, mais quels sont les deux/trois arguments un peu massue que je pourrais présenter à ma ou mon sous-directeur pour le convaincre de publier ?

Yves-Alexis Perez : C’est effectivement vraiment une bonne de se poser la question dès le début, donc pour les futurs projets et, j’ai envie de dire, de rentrer dès maintenant dans une démarche même si la publication ne sera pas instantanée, même si le développement ne se fera pas de façon communautaire initialement, on ne demande pas forcément ça.
Se poser la question de l’exposition au public dès le début, ça permet aussi de prendre des bons principes, typiquement des bons principes de codage, mais aussi des principes d’architecture, par exemple de séparation entre le code, les données et les données de configuration. Quelque chose qui est très à la mode ces temps-ci c’est ce qu’on appelle le DevOps dans lequel on mélange un petit peu la partie développement et opérations. Ce n’est pas une mauvaise chose en tant que telle, par contre c’est important qu’en termes de code source on puisse séparer les deux, pour qu’on soit capable de publier les algorithmes eux-mêmes, la façon dont le logiciel va fonctionner, sans pour autant montrer la tambouille interne de l’hébergement, où est-ce que ça tourne , avec quels secrets, etc. ; évidemment, les administrations peuvent tout à fait garder ça pour elles. Du coup, en se posant la question dès le début, on architecture le projet un peu comme il faut.
Je pense que pour convaincre un peu les chefs de bureau, chefs de projets, etc., il y a un vrai intérêt aussi quand on publie du code source, c’est que c‘est beaucoup plus facile, derrière, d’avoir des contributeurs externes, évidemment ; d’échanger, sans forcément être contributeur, avec d’autres intervenants, voire d’échanger avec les logiciels qu’on utilise. De nos jours on ne redéveloppe jamais un logiciel complet de zéro, on utilise toujours des briques externes. C’est beaucoup un jeu de Lego dans lequel on assemble des briques extérieures, on rajoute des contributions internes et parfois on peut avoir des difficultés à intégrer des briques externes ; elles ne fonctionnent pas tout à fait comme on le souhaiterait, on a du mal à faire interagir des flux, etc.
Être capable de donner un exemple aux développeurs pour dire « j’aimerais bien me servir de votre logiciel de cette façon, il y a un exemple ici, c’est exactement comme que je l’ai fait et le résultat que je voudrais avoir c‘est ça, est-ce qu’on peut travailler à une évolution, est-ce que je peux vous soumettre des modifications, est-ce que vous pouvez m’aider à intégrer ? » C’est beaucoup plus facile, finalement, de travailler sur du concret.

Stéphane : Merci beaucoup Yves-Alexis.
On a évoqué tout à l’heure, en préambule, l’utilisation de l’open source d’une manière très historique à la DGFiP. La DGFiP, effectivement, travaille, supporte le marché logiciels libres, on voit bien toute la dynamique qui a été opérée depuis. On pense que l’open source est quasiment dans les gènes de la DGFiP. Su, est-ce que tu veux bien nous planter aussi le décor de l’open source ? Tu es aussi dans le pôle données de la Délégation de la transformation numérique de la DPFiP. Est-ce que tu peux nous donner aussi quelques exemples concrets sur des projets en cours, évidemment, et puis sur des outils open source que vous pouvez utiliser dans le traitement des données à la DGFiP ?

42’ 16

Su Yang : Bien entendu. Merci.
Le cœur de métier du pôle de données reste toutes les techniques d’analyse puis d’infrastructures qui sont nécessaires pour le traitement d’une grande masse de données, de valoriser les données. Cela étant dit, effectivement comme tu l’as si bien Stéphane, c’est dans l’ADN de la DGFiP de recourir autant qu’il se peut aux logiciels libres.
Nous travaillons avec Thierry Aimé, qui est responsable du marché open source au sein de la DGFiP sur le sujet.
Tout à l’heure on mentionnait un petit peu les exemples historiques. Quelque chose que j’ai appris en arrivant à la DGFiP c’est qu’on travaille déjà sur des choses assez connues. On est l’un des principaux contributeurs par exemple de la distribution LibreOffice, qui est quelque chose que nous utilisons bien entendu pour nos différentes productions internes.
Le projet dont je vais vous parler un petit peu est un projet qui est en cours. Je vais parler un petit peu du contexte, du besoin qui a conduit à ce projet-là, expliquer un petit peu le principe et puis un peu la feuille de route sous-jacente.

Pour le contexte. La DGFiP a mis en production depuis cette année, 2021, une infrastructure Big Data dite « Lac de données ». C’est une infrastructure qui est basée sur une distribution libre appelée Hortonworks, on verra que libre n’est plus tout à fait vrai. On a défini l’architecture technique et logicielle et réalisé l’intégralité de sa mise en œuvre.
Le besoin est vraiment venu de trois problématiques spécifiques : premièrement le traitement d’une grande masse de données. On a des calculs comme le calcul du foyer fiscal qui nécessitaient, avec des infrastructures classiques, jusqu’à quelques jours de traitement avec un temps qui croit d’année en année. On est arrivé à un point où le besoin est vraiment organique, c’est un besoin très basique, très simple à comprendre, qui nécessite vraiment une infrastructure dédiée.
On avait également un besoin de désiloter les données qui sont situées dans des applicatifs très différents, avec des technologies différentes, des formats différents et l’infrastructure où c’est simple de déposer les fichiers, de les croiser, d’en faire des transformations, était également bienvenue.
Et puis un troisième besoin qui était vraiment lié à la valorisation qu’on a citée. Une infrastructure native, avec des outils qui sont adaptés pour faire de la data science, pour faire de la dataviz, pour favoriser l’exposition des données était également nécessaire. On pouvait y arriver, on en faisait avant, mais comme ce n’était pas adapté, il y avait beaucoup d’énergie qui était brûlée pour faire ce genre d’initiative.

La distribution libre qu’on utilisait, Hortonworks, plus exactement la version 3.1.4, a été rachetée en octobre 2018 par la société Cloudera. Ce n’est pas toujours le cas, lorsqu’une solution libre est rachetée par une société, qu’elle devienne « fermée », entre guillemets, en l’occurrence les derniers agissements que propose cette société montrent que la solution ne sera plu supportée en logiciel libre dès la fin de cette année. La nouvelle distribution de Cloudera qui permet de faire la même chose demandera une souscription payante, avec une certaine opacité autour de son évolution, mais aussi du pressing autour de la solution.
L’arbitrage a été fait, notamment après des discussions avec les différents acteurs du groupe TOSit, auquel participe le secrétariat général du ministère de l’Économie et des Finances et les grands groupes français, c’est un groupe de partage notamment des difficultés rencontrées sur les différents projets informatiques. Il a été arbitré de démarrer un projet de développement d’une alternative à cette distribution Hortonworks.
Aujourd’hui EDF et DGFiP sont les principaux développeurs de cette solution et d’autres entités, après qu’on ait livré un lot 1 au mois de septembre de cette année, ont sollicité TOSit pour prendre part à ce développement. C’est très important d’avoir un écosystème avec une masse critique de participants pour faire vivre une solution open source, pour assurer la pérennité de la solution dans le temps.

Qu’est-ce que c’est ce projet ? On l’a intitulé TOSit Data Platform. Ça a l’air un peu technique, mais je vais plutôt faire un parallèle. Imaginons que vous êtes un chef cuisinier dans un restaurant, si vous êtes tout seul, vous êtes peut-être capable de servir trois à quatre convives et encore !, c’est relativement compliqué, vous allez être occupé à temps plein à cuisiner des plats. Vous pouvez peut-être recruter un autre chef cuisinier qui a autant d’expérience que vous, mais ce n’est pas quelque chose qui passe facilement à l’échelle. Pour être en capacité de servir par exemple une cinquantaine de couverts, qu’est-ce que vous faites, qu’est-ce qu’on fait dans la réalité ? On prend des petites mains pour diviser les différentes tâches. On va prendre des gens pour aller couper des légumes, les différents légumes, les différentes viandes et on va paralléliser certaines tâches. Le principe d’une plateforme Big Data c’est vraiment de diviser pour régner, de partager les différentes tâches pour qu’elles puissent être faites en parallèle. L’idée sous-jacente c'est vraiment d’être en capacité de solliciter plein de machines très peu chères mais, mises ensemble, ont une très grande capacité de traitement.
Les différentes composantes qui sont à l’écran sont les différentes composantes de la fondation Apache qui vont rester dans le domaine du Libre, qui vont gérer certains aspects d’une plateforme Big Data, qu’on appelle également parfois des plateformes distribuées, qui vont gérer peut-être l’aspect stockage, la gestion de ressources, ce que chaque machine fait, la question d’accès, d’audit, sécurité, et comment on facilite le dépôt peut-être de fichiers de données sur une telle infrastructure. Ce n’est pas toujours très simple de faire du requêtage pour ceux qui ont travaillé un petit peu sur les bases de données, ce qui fait que l’on peut requêter facilement si on indexe un petit peu, c’est la différence, par exemple, entre avoir les Lego sur un bureau ou les avoir rangés dans des tiroirs, en l’occurrence sur une plateforme distribuée. On ne cherche pas nécessairement de les ranger dans le tiroir, mais on va quand même essayer de déposer un modèle pour que les gens qui ont l’habitude d’aller chercher les Lego dans les tiroirs puissent le faire.
Ce sont un petit peu les composants, mais une fois qu’on a des composants qui gèrent beaucoup d’aspects afin de faire de l’informatique distribuée, il faut être en capacité de les faire interagir les uns par rapport aux autres et de faciliter l’intégration en SI. C’est ce chef d’orchestre, ou cet orchestrateur, qui est l’intérêt réel de la distribution Hortonworks, c’est quelque chose que nous souhaitons répliquer.

Pour les gens qui connaissent vraiment très bien le sujet techniquement, quelques composantes dont on a besoin. Ce n’est pas exhaustif et ça ne correspond pas nécessairement aux besoins de tout le monde. Ça fait partie des besoins minimum définis par EDF et DGFiP, pour les besoins de ces deux structures-là, l’idée c’est qu’avec les nouveaux participants la feuille de route va bien entendu évoluer. C’est aussi logique, plus de participants ça veut dire plus de ressources et la feuille de route doit être modifiée en ce sens. L’intérêt de participer à un tel projet c’est aussi de personnaliser le projet pour qu’il corresponde aux besoins de sa propre structure.

Aujourd’hui, côté DGFiP, on a constitué une équipe de deux personnes en début d’année et on a en cible, dès le début de l’année prochaine, d’investir cinq internes mais aussi des investissements en prestataires. J’ai un peu de mal à savoir exactement combien aujourd’hui mais, sur ce projet-là, on a à peu près moitié interne moitié externe parce que c’est aussi très important de recourir à des prestataires venant de plusieurs sociétés. L’une des difficultés pour pérenniser une solution libre c’est d’avoir des sociétés qui souhaitent faire du support. On comprend très bien que l’une des interrogations des grands groupes qui viennent nous solliciter sur le sujet c’est qui peut assurer le support de ces logiciels libres.
La mise en production de notre propre lac de données à partir de TOSit Data Platform est prévue pour 2023.

On a quelques structures qui souhaitent s’investir. La dernière en date, ce qui m’a un peu surpris personnellement, c’est l’OCDE qui avait entendu parler du projet et qui souhaite absolument s’intégrer au projet.
Le projet est divisé aujourd’hui en quatre paliers, je vais directement aller sur les jalons. On considère qu’on peut commencer à faire la production lorsqu’on arrive au jalon 4.
Le jalon 1, qui est aujourd’hui déjà réalisé, permet de complier des tests unitaires des projets d’Apache sur les cinq composants qui sont cités, qui sont essentiellement gestionnaire de ressources, espace de stockage, projeter un modèle de base de données, faire des tests de mémoire et la gestion de la sécurité. On est vraiment parti sur des choses assez modernes, on a conteneurisé notre solution qui est déployable en moins de 20 minutes.
Je ne vais pas détailler, mais je peux rendre la présentation disponible.
Voici dans l’ordre comment notre feuille de route va être menée : le lot 2 est prévu pour la fin de l’année. Le lot 3 est prévu pour juin 2022 et le lot 4 est prévu pour fin 2022.
Merci. Je vais m’arrêter là s’il y a des questions, n’hésitez pas.

Stéphane : D’accord. Donc d’ici à la fin de l’année prochaine, il y a aura une solution coconstruite DGFiP/EDF et puis peut-être d’autres personnes aussi, peut-être OCDE qui permettra de pouvoir traiter de la data finalement ?

Su Yang : Exactement. On a déjà participé à pas mal de projets en logiciel libre. Ce qui est intéressant c’est qu’on est vraiment à l’origine de ce projet-là, ce qui a nécessité aussi un peu de souplesse dans la manière de conventionner avec les acteurs. Je pense que c’est assez intéressant d’avoir ce retour d’expérience sur le sujet.

Stéphane : OK. On regardera la publication du code source. En tout cas merci beaucoup pour la présentation.
J’ai une question. Je vous la lis et vous me dites comment vous voulez y répondre : comment réagissent les éditeurs commerciaux au développement du logiciel libre ? Leur engagement sur la sécurité, la neutralité sont-ils une réponse satisfaisante ? Je ne sais pas qui veut. En deux temps. Peut-être déjà sur la manière dont les acteurs qui vendent des solutions qui ne sont pas en open source réagissent. Je vais prendre un exemple qui est peut-être sur la partie data. On a des éditeurs comme SAS qui ont livré des solutions depuis de nombreuses années à l’administration pour faire du traitement statistique, y compris à des grands groupes, et maintenant on a Python, on a R, on a tout un écosystème, on a des packages, des bibliothèques qui permettent de faire énormément de choses, du traitement statistique, également de l’analyse d’images, de la cartographie, du traitement de Big Data. Finalement comment réagissent-ils selon vous ? Bastien.

57’ 03

Bastien Guerry : Je ne peux pas parler pour les éditeurs. Il faut se souvenir qu’on a beaucoup d’éditeurs de logiciels libres. En France c’est un écosystème de petites et moyennes entreprises qui est très actif. On croit souvent que l’ensemble des ENL, les Entreprises du Numérique libre, sont majoritairement des entreprises de service et d’intégration qui font du support, de l’adaptation des logiciels. En réalité il y a parmi elles beaucoup d’éditeurs. C’est une étude du CNLL qui l’a encore dit récemment, en fin d’année, ce qui fait que les éditeurs propriétaires ont sous les yeux des exemples de gens qui éditent des logiciels libres. Ce que je vois, je pense que les éditeurs propriétaires s’intéressent à l’open source pour voir ce qu’ils pourraient proposer en open source tout en conservant la main sur leur modèle économique. Après, répondre plus en détail, je ne pourrais pas.
On peut quand même citer Oracle avec Java. On a une distribution libre et on a des ministères qui dépendent soit de la version payante Oracle, soit de la distribution libre. Là Oracle doit s’adapter parce qu’il se trouve que la version libre fonctionne très bien et que les ministères entre eux peuvent s’aider pour faire la migration vers cette version libre. C’est un rapport de force, un rapport économique où l’administration essaye de jouer son indépendance.

Stéphane : Très bien. Merci beaucoup.

Su Yang : Je vais essayer d’apporter des éléments de réponse aussi.
Déjà je pense que la réalité est assez différente d’une société à une autre, beaucoup d’éditeurs avec des positionnements différents donc c’est difficile de généraliser. Cela étant dit, tu mentionnes SAS. Il y a des grands éditeurs qui sont historiquement sur des solutions propriétaires qui, peut-être après un début de mouvement de résistance, se sont mis également à promouvoir de l’open source. Je pense qu’il ne faut oublier que peut-être, pour des acteurs qui vont fournir l’administration dont le cœur de métier n’est pas l’informatique, utiliser des solutions libres n’est pas forcément simple. On peut très bien imaginer, et c’est le cas pour ces sociétés-là, qu’ils passent de la vente de licences vers le support logiciel libre ou le pakadging de différentes solutions libres pour en faire un tout. Ça convient bien à certaines sociétés. Pour un ou deux acteurs en particulier dont le cœur de métier c’est vraiment la vente de licences c'est un peu plus compliqué et ils sont plutôt dans une démarche de campagne de terrain pour justement parler de problèmes de sécurité, de demandes de support sur ces solutions libres.

Stéphane : OK. Merci. Tout à l’heure on parlait du marché logiciel libre. On n’a pas trop expliqué ce que c’est. En un mot peut-être, à quoi ça sert et à qui il sert ?

Bastien Guerry : C’est un marché interministériel piloté par la DGFiP, avec Thierry Aimé aux commandes, qui permet aux administrations qui utilisent des logiciels libres de remonter des bugs et de demander que ces bugs soient corrigés, d’une part, c’est la partie support. L’autre partie c’est éventuellement de faire des développements spécifiques et c’est la partie expertise, donc solliciter les développements en passant par ce marché. C’est une procédure facilitatrice, c’est sur un ensemble d’un peu moins d’une centaine de logiciels, mais il y en a beaucoup sur différentes versions. On peut avoir du support sur jusqu’à deux trois versions stables de LibreOffice et d’autres logiciels. C’est donc un marché qui est ouvert aux administrations en général qui peuvent se tourner vers la DGFiP. On va essayer, dans les mois à venir de communiquer plus largement sur ce marché. Il y a un produit dont je n’ai pas parlé, c’est le Socle interministériel de logiciels libres qui est publié par la DINUM mais qui est en réalité une contribution de tous les ministères, c’est l’ensemble des logiciels qui sont recommandés aux administrations. Une sous-partie de ce socle de logiciels libres, qui contient 200 logiciels, sont les logiciels supportés officiellement par l’administration grâce à ce marché.

Stéphane : Super. Merci.
Question peut-être plus prospective. On va essayer de se projeter un tout petit peu, on est en 2030 ou 2035, on va se dire que c’est un peu loin mais relativement raisonnable, comment voyez-vous la place du Libre ? Une dynamique beaucoup plus forte ? Est-ce qu’il n’y a pas, comme toute action balancier, peut-être un retour en arrière à un moment donné ? Comment voyez-vous les choses en 2030 ou 2035 ? Où sera le logiciel libre ? On a le droit de rêver !

Bastien Guerry : J’ai peut-être deux éléments de réponse.
La première chose, je pense que les entreprises, ça y est, elles se sont emparées du sujet. Je pense que les administrations et pas seulement en France, mais d’autres grands pays, l’Allemagne et l’Italie avec lesquels on discute, le font. Je pense qu’il y aura une préoccupation citoyenne qui fait que ça sortira du sujet de la seule confidentialité de quelques techniciens qui s’intéressent à ce qu’il y a dans leur machine pour vraiment poser des questions de société sur le vote électronique, sur… On aura une telle numérisation que ça deviendra un sujet concernant et qu’on sera de plus en plus nombreux. C’est la partie citoyenne.
Pour la partie administration, je n’ai pas nommé dans mes âges en introduction mais je pense qu’on entre dans l’âge de la souveraineté. Qu’est-ce que ça veut dire pour le Libre ? Ça veut dire que dès que le Libre sera un outil efficace pour le maintien de la souveraineté de l’État, c’est-à-dire la maîtrise, ce que Yves-Alexis a cité tout à l’heure, sur oui, on maîtrise ce qu’on utilise, c’est essentiel, ça ne voudra pas dire qu‘on ira forcément ouvrir tout. On trouvera un équilibre. On a aussi ce mouvement dans les entreprises qui s’équipent chacune d’un Open Source Program Office, Microsoft, Google, SAP et d’autres entreprises, pour définir une stratégie. Je pense que dans dix ans on aura une stratégie plus claire avec un axe fort sur la souveraineté et, en face, des citoyens qui seront un peu plus concernés.

Stéphane : Merci beaucoup.

Yves-Alexis Perez : Pour compléter, je pense aussi aux enjeux et à l’attention qu’il faut avoir, la vigilance même qu’il faut avoir. Je pense que le sujet s’est un peu déplacé au fur et à mesure des années. Je pense que personne, et en particulier pas les grands éditeurs de logiciels, plus personne ne remet en cause l’intérêt, la pertinence et la validité du modèle du logiciel libre, eux-mêmes sont fortement contributeurs, fortement éditeurs de logiciels libres. Pour autant, il y a un enjeu toujours autour de la maîtrise et du contrôle. À savoir qu’on a un certain nombre de grands éditeurs ou de grandes entreprises qui cherchent à contrôler, maîtriser leurs utilisateurs, en particulier leurs données, et ça passe pas mal par un contrôle des plateformes qui sont utilisées. On voit que de plus en plus l’informatique se déplace vers des usages mobiles, en particulier téléphone, tablette, adossés à des usages dans le cloud, donc des liens entre des téléphones mobiles et des infrastructures cloud. Certaines entreprises cherchent clairement à contrôler ce qui s’exécute sur les plateformes des utilisateurs, parfois pour des raisons de sécurité, ce qui est en partie vrai parce qu’on n’a pas forcément envie que n’importe quoi s’exécute sur les postes des utilisateurs. Pour autant, ce n’est pas forcément aux distributeurs de contrôler ce qui s’exécute, mais il faut que ce soit quelque chose qui soit finalement à la main de l’utilisateur, pas forcément que tout le monde ait la capacité technique de le faire mais au moins qu’il y en ait la possibilité et que les services informatiques, eux, en soient capables, ce qui n’est pas du tout anodin et je pense que c'est un des vrais enjeux pour les années à venir.

Bastien Guerry : S’il est permis de rêver, je pense que le souhait, en tout cas le mien, serait qu’on multiplie les projets comme ceux qui viennent d’être présentés autour de Hortonworks, c’est-à-dire qu’on arrive à décupler la capacité de mutualisation. Je donne un exemple qui sera l’effort que la DINUM fera dans la prochaine année. On a aujourd’hui 9000 dépôts de codes sources listés sur code.etalab.gouv.fr : c’est beaucoup et c’est presque trop parce que ça demande des points de repère. On ne fournit pas encore ces points de repère sur quels sont les codes sources qui seront vraiment utiles au chef de service, au DSI sur la construction de ses SI, quels sont les plus importants.
On a plus de 3000 bibliothèques open source qu’on utilise, pour lesquelles doit-on demander un audit de sécurité ? Lesquelles sont tellement critiques qu’il nous faut un audit de sécurité ? Là encore on monte en maturité en même temps que le monde de l’entreprise. Peut-être, enfin c’est sûr, certaines de ces librairies sont déjà produites par l’administration. Est-ce qu’on doit faire un effort particulier de mutualisation soit à l’intérieur de l’administration soit, comme ça a été présenté, avec des acteurs privés, auquel cas il y a des sujets de gouvernance de communs ; je trouve admirable que TOSIT explore ces voies qui posent toutes ces questions de gouvernance. Mette autour de la table des grands comptes et des moyens et qu’on pourra éventuellement, entre guillemets, « internaliser » ces compétences sur de la mutualisation forte et qu’on saura de très près citer la liste des dix projets fortement mutualisés dans l’État et qui assurent son indépendance.

Stéphane : Merci beaucoup. Merci pour tout cet éclairage. Je crois que c’est extrêmement important de comprendre cette dynamique qui est quand même ancrée historiquement et qui va probablement se décupler encore dans les prochaines années. J’espère que ça vous a plu, que le labyrinthe numérique se résout au fur et à mesure. Prochaine conférence débat le 26 janvier. On fera une petite pause en novembre parce que nous avons d’autres événements et on ne veut pas faire trop de saturation. 26 janvier, on parlera de ce qu’est le RGPD, le Réglement général sur la protection des données. Merci à toutes et à tous. Bon appétit et très bonne fin de semaine. Merci à vous trois. Au revoir.