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 ???

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 ???, 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 j e 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 visualisation 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 : Bastien.

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 suive 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épendante, 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.