La vidéo de la conférence est disponible sur Youtube.
Sommaire
Transcription de la conférence sur l’évaluation des logiciels open source
Walid Nouh: bonjour à toutes et à tous, merci d’être là. Je m’appelle Walid Nouh, je suis le fondateur d’un podcast qui s’appelle Projets Libres!. Aujourd’hui, j’ai la grande chance de pouvoir animer une table ronde où on va parler d’évaluation de logiciels libres. Avec moi, on a quatre invités. Vous allez voir de profils différents qui ont chacun des intérêts différents à évaluer des logiciels libres. La première personne, c’est Lwenn Bussière qui est Technology Assessor chez NLnet. On va expliquer après ce qu’est NLnet. Thierry Aimé qui est responsable logiciel libre au ministère des finances. Benjamin Jean qui est le CEO du cabinet Inno3 et Raphaël Semeteys qui est senior architecte chez Worldline. Je vais vous laisser à chacun la parole pour vous présenter et expliquer un petit peu votre structure, qui vous êtes et quelle est votre structure. Louane, est-ce que tu veux bien commencer s’il te plaît ?
Présentation des intervenants
Lwenn Bussière: bien sûr. Merci de m’avoir invité Walid. Bonjour tout le monde. Je m’appelle Lwenn et je travaille à NLNet, qui est une fondation aux Pays-Bas qui donne des financements entre 5 000 et 50 000 euros à des projets de logiciels libres et open source. Essentiellement ces financements viennent par la Commission européenne, du programme NGi Zero, qui est un programme de cascading de financement venant de la Commission européenne et étant distribué par… une organisation, en l’occurrence NLNet. Et donc, nous évaluons au cours de notre travail des candidatures de centaines de projets de logiciels libres, hardware, open source aussi, et firmware, donc pas seulement du développement logiciel, cherchant des financements européens.
Walid Nouh: Benjamin ?
Benjamin Jean: bonjour tout le monde, vous m’entendez ? C’est un peu intimidant, mais très bien. J’ai l’impression de chuchoter. Donc, enchanté, Benjamin Jean, je suis le président et fondateur du cabinet Inno3, qui est une petite structure. On est moins de 10 personnes. En fait, on est principalement concentré sur tout ce qui est définition, mise en œuvre de stratégie de politique open source. Je fais très bref, mais des contextes dans lesquels se retrouvent souvent ces questions d’évaluation de l’open source. Quand est-ce qu’il est pertinent, d’une part, de diffuser ses propres projets en open source ? Et quand est-ce qu’il est pertinent d’utiliser les projets des autres et selon quels critères. Rapidement, on a aussi participé très récemment à la fondation d’une autre structure qui s’appelle Open Source Experts. C’est un groupement d’entreprises de l’open source qui vise à proposer les réponses groupées des acteurs de l’open source pour des gros marchés. C’est aussi dans cette logique que je me retrouve ici présent.
Walid Nouh: Raphaël, si tu prends un micro.
Raphaël Semeteys: merci. Merci pour le micro aussi, bonjour à tous. Moi je suis Raphaël Semeteys, je travaille avec et autour de l’open source depuis pas mal de temps. Précédemment chez Atos, pendant 10 ans, j’étais dans le centre de compétences open source où on accompagnait les clients dans leur adoption, leur réflexion autour de l’open source. Et puis depuis 10 ans à peu près aussi, je suis maintenant chez Worldline où on utilise beaucoup de composants open source pour construire notre propre solution, notamment dans le domaine du paiement.
Walid Nouh: Thierry.
Thierry Aimé: et donc moi c’est Thierry Aimé, je travaille au ministère des Finances, précisément à la direction générale des Finances publiques, au bureau de l’architecture et des normes. Dans le cadre de mes fonctions, responsable des choix open source, logiciels libres pour ma direction, nous utilisons énormément de logiciels libres et nous sommes régulièrement amenés à nous interroger sur la qualité des logiciels que l’on pourrait déployer pour remplir les besoins identifiés. Et sinon, plus largement, je m’occupe du marché de support et d’expertise logiciel libre. C’est un marché qui est au bénéfice de l’ensemble des administrations centrales. Tous les ministères en bénéficient. Et c’est un marché où on partage nos problèmes, nos questionnements sur l’identification des logiciels libres. On a en particulier pour ça des études d’opportunités, des études qu’on fait régulièrement, des études stratégiques ou techniques pour identifier ces logiciels libres.
Pourquoi évaluer les logiciels open source ?
Walid Nouh: très bien, alors si maintenant on commence à rentrer un peu plus dans le détail, la première chose qu’on peut se demander c’est quel est le besoin, pourquoi est-ce qu’on veut évaluer des logiciels libres ? Vous allez voir que chacun a des réponses très différentes en fonction de la structure dans laquelle il travaille. Donc on va commencer par parler de pourquoi vous avez besoin d’évaluer des logiciels libres. Loen, est-ce que tu peux expliquer un peu chez NLnet pourquoi vous avez besoin d’évaluer des logiciels libres ?
Lwenn Bussière: oui, bien sûr. Essentiellement, c’est notre mission puisque nous donnons des financements de recherche et développement. Donc, on travaille vraiment en amont, c’est-à-dire qu’on reçoit des candidatures de jeunes, moins jeunes, développeurs indépendants, compagnies, universités, qui vont nous proposer un projet, en général un projet tout neuf et très souvent de la recherche de pointe. Et pour… Oui, pour financer la recherche et le développement de nouveaux projets open source. Et ces financements de recherche et développement, on les adresse aussi à tous les niveaux de l’infrastructure de l’Internet européen. Pour nous, c’est important que les utilisateurs aient le contrôle de leur expérience, la possibilité de self-host (NDLR : auto-héberger), la possibilité d’avoir le contrôle de tes données, la possibilité de savoir ce qui se passe dans le code et d’avoir des solutions qui soient accessibles et sécurisées pour chacun d’entre nous. Ce sont des critères qui nous intéressent particulièrement. Donc, on travaille beaucoup en amont de nouveaux projets de recherche.
Walid Nouh: vous recevez beaucoup de candidatures ?
Lwenn Bussière: oui,
on a des appels à projets tous les deux mois et le dernier appel à projets qui s’est clôturé le 1er octobre, on avait 567 candidatures autour de toute l’Europe. Donc plusieurs centaines tous les deux mois. Et on a financé, depuis le début des programmes NGI et NLnet, on a financé plus d’un millier de projets. Je pense qu’on a passé la barre des 1,5 milliers à ce stade-là.
Lwenn Bussière
Walid Nouh: ok, donc là ce qui est intéressant c’est qu’on a de l’évaluation en amont avant que les projets soient matures, sur des projets qui sont vraiment un peu early stage (NDLR : phase précoce). Benjamin, dans votre cas à vous chez Inno3, quels sont les différents besoins qui font que vous avez, dans quel cas vous allez avoir besoin d’évaluer les logiciels libres ?
Benjamin Jean: c’est pour ça que j’ai pris mon PC. Finalement, on se pose souvent la question de l’évaluation, mais pas pour les mêmes raisons. Le terme est utilisé peut-être à mauvais escient. Il y a, je pense, de manière assez similaire, la question de l’évaluation d’un point de vue de la valorisation, de se dire, quel type de projet peut être diffusé utilement en open source ? D’une part, quels sont les critères qui vont être au sein d’un centre de recherche ou d’une organisation pris en compte pour décider de l’opportunité de diffuser en open source ? Les modalités qui sont associées ? Là, il y a une évaluation. Il y a une évaluation aussi a posteriori. Donc là, c’est plus pour piloter finalement la valorisation, mais c’est aussi lié à la valorisation. C’est-à-dire ce projet qu’on a diffusé dans un premier temps, qu’est-ce que ça nous a apporté au regard des objectifs qu’on s’était donnés ?
Donc ça rejoint peut-être un peu ce qui s’est dit, mais dans un contexte interne de l’organisation, donc un peu différent. Il y a la question plus liée à la manière. En fait, quand on travaille, quand on définit en interne une politique open source, finalement, on ne peut pas le faire comme si on était le seul au monde. C’est-à-dire que chaque organisation doit aussi s’interfacer avec les politiques des autres acteurs avec lesquels elle travaille, notamment les fournisseurs. C’est là où on va tomber sur les sujets de marché public. Et donc, il y a cette question de la façon dont on peut traduire dans les marchés qu’on publie les enjeux qu’on a quant à l’utilisation de l’open source en interne et comment on va évaluer les réponses sur cette base, notamment si on impose des solutions open source, par exemple, si on impose des solutions communautaires, si on impose, l’État l’a fait, différentes entreprises, uniquement des projets qui ne sont pas portés par des entreprises, mais plutôt par des organisations non créatives, par exemple.
Benjamin Jean
C’est quelques exemples comme ça, mais qu’on puisse se situer à cette échelle. Et qu’est-ce que je me suis noté d’autre ? Oui, dans tout ce qui est, alors ça rejoint finalement ce qui vient de se présenter avec NLnet, c’est dans tout ce qui est appel à commun. Alors c’est un terme qu’on utilise beaucoup en France, qui commence à être utilisé aussi en Europe, je trouve, de plus en plus, mais qui se rapproche beaucoup de ce que fait NLnet. C’est-à-dire que l’idée, c’est de penser d’une part à l’évaluation du projet, mais aussi de la communauté qui est derrière. Donc là, ça rejoint aussi les métriques. On va en parler tout à l’heure des méthodes. Mais comment dans ces appels à projet, un peu différents, qui vise à financer des projets qui d’une part sont ouverts mais qui d’autre part sont maintenus par des communautés qui pérennisent l’investissement des acteurs publics ou privés. Là, il y a une évaluation, et généralement la plus simple possible pour donner lieu ensuite à des financements, même si moins importants, plus réduits. Et je finirai juste avec ça. On est impliqué dans un projet, pour montrer la diversité des situations dans lesquelles on travaille sur l’évaluation, un projet qui s’appelle Hermine, un projet open source et open data, dans lequel ce qu’on cherche à introduire, ça permet d’avoir une vision aussi complète de l’ensemble des logiciels open source qu’on utilise au sein de son organisation. Pour différentes raisons, la première c’est la conformité open source, donc c’est de là que vient le projet initialement. Mais il y a d’autres sujets qu’on essaye de greffer à ça, notamment la question de la soutenabilité. C’est-à-dire de se dire, si j’utilise plein de logiciels open source au sein de mon organisation, comment est-ce que j’évalue la pertinence du choix de tel logiciel au regard aussi des critères qui sont liés à sa communauté, à la qualité juridique, et à plein d’autres choses. Et ça c’est notre façon d’évaluer qui est beaucoup plus automatisable. avec des standards et des méthodes qui se développent. Mais ça fait aussi partie de nos préoccupations.
Walid Nouh: on va en parler après, justement dans les méthodes aussi. Raphaël, de ton côté, chez Worldline, vous plutôt industriel, pourquoi évaluer ? Quels sont les enjeux pour vous ?
Raphaël Semeteys: effectivement, nous, on est plutôt en aval, on va dire. Clairement, l’enjeu pour un groupe comme Worldline, qui construit des services critiques, hautement régulés, très visibles, dès que ça tombe en panne, il n’y a plus de paiement, ce genre de choses-là, on a besoin d’avoir confiance dans les composants qu’on va sélectionner pour construire ces services-là, qu’ils soient open source ou pas d’ailleurs. Et donc, en fait, ça part vraiment d’une analyse de risque, c’est-à-dire quel risque je prends quant à ma capacité à opérer des services critiques, à sélectionner tel composant ou tel autre composant. Et c’est ça qui a amené à, et j’en parlerai après, sur la méthode que j’ai contribué à créer, sur comment évaluer ces risques-là. Donc c’est vraiment en tant qu’utilisateur final, s’assurer qu’on va sélectionner des composants qui sont pérennes, qui vont continuer à répondre aux besoins, qui vont être patchés au niveau de sécurité, ce genre de choses.
Walid Nouh: tu peux passer là. Le micro à côté à Thierry. Alors là, bon, le ministère, vous aussi.
Thierry Aimé: oui, nous sommes donc utilisateurs d’un très grand nombre de logiciels libres. Ça ne s’est pas fait d’un coup, c’est venu progressivement au tournant des années 2000. Les logiciels libres sont entrés dans la direction.
Et en fait, c’est le résultat d’une politique où systématiquement, c’est une politique stratégique de consulter systématiquement l’offre libre pour tout nouveau besoin avant de se tourner vers éventuellement l’offre propriétaire. Donc quand on se tourne vers l’offre libre, on définit un périmètre, on définit un besoin et puis souvent, très très souvent, il n’y a pas une solution qui ressort mais une multitude de solutions sur énormément de sujets. Il y a une profusion de logiciels libres, c’est assez étonnant, cette diversité, cette dynamique.
Thierry Aimé
Et donc la question qui arrive très vite, c’est comment le choisir ? Beaucoup de ces projets, c’est parfois des projets personnels, c’est parfois des projets d’études, c’est parfois des projets d’éditeurs qui ont en fait un projet qui ressemble beaucoup à celui des éditeurs propriétaires, c’est-à-dire qu’ils sont les seuls maîtres à bord de leurs solutions. Il faut évaluer toutes ces choses et estimer les risques et quelles sont les meilleures solutions à déployer chez nous, puisque l’enjeu quand on déploie un logiciel libre, ce n’est pas de le faire pour quelques mois mais c’est un enjeu de pérennité sur des dizaines d’années où il faut garantir que ce logiciel continuera d’être disponible, maintenu et que l’on pourra même pourquoi pas contribuer d’ailleurs à améliorer le logiciel. Ne serait-ce que, si on détecte des anomalies, disposer de recours pour, auprès de la communauté, faire valoir ses correctifs. Voilà, donc c’est vraiment important pour nous de sécuriser l’utilisation du logiciel libre en garantissant le choix initial.
Comment évaluer le logiciel open source ?
Walid Nouh: très bien. Passons un peu au gros morceau de la conférence, c’est les méthodes d’évaluation. On voit qu’il faut évaluer, mais alors comment on évalue ? Et là, il y a plein de méthodes, il y a plein de manières de faire différentes. Et encore une fois, en fonction de quelle organisation, les méthodes sont un peu différentes. Donc là, je vais reposer encore une fois la question cette fois-ci. Mais Lwenn, comment vous maintenant, un peu plus dans le détail, comment vous faites pour évaluer toute cette masse de dossiers qui arrivent et tous ces projets qui viennent vers vous ?
Lwenn Bussière: comme les projets qui arrivent sont en général des projets très jeunes, et aussi de par le fait que notre procédure de candidature est très simplifiée. D’ailleurs, si vous avez un projet que vous avez envie de présenter pour notre prochain call (NDLR : appel à projet), n’hésitez pas. Donc, on a une procédure très simplifiée qui est juste un webform qui prend peut-être une demi-heure, une heure à remplir et où on encourage les développeurs à oublier le marketing et juste nous expliquer ce qu’ils font, pourquoi. et s’arrêter là. Et donc nous on reçoit ces candidatures qui font chacune une ou deux pages relativement courtes et à chaque fois on a besoin de faire beaucoup, beaucoup de recherches pour chacun des projets que nous recevons puisque ce sont souvent des projets qui sont même pas encore créés ou bien très jeunes. On va jeter un œil au repo, on va jeter un œil aux différents projets qui existent dans le même espace, aux différentes librairies sur lesquelles quelqu’un construit, si c’est des projets de hardware, quelles sont les solutions qui existent, quelles sont les schématiques, quels sont les fournisseurs pour le firmware, quelles sont les plateformes qui sont targetées, etc. Donc c’est très pointu et c’est taillé sur mesure à chacune des candidatures que l’on reçoit. On a quelques critères qui sont très stricts, puisqu’il faut que les projets soient européens. Il faut qu’il y ait une dimension européenne. Ce sont des financements européens, donc il y a des règles. On regarde le budget, on regarde aussi les critères stricts. Il faut que le projet soit de la recherche et du développement. Et ensuite, on évalue les projets sur trois critères, seulement trois, donc comparés. à la méthode de Benjamin qui est très précise. Ça va être beaucoup plus un processus de prendre des notes et de poser des questions, puisqu’on regarde l’excellence technique. Est-ce que la solution est adaptée au problème ? Est-ce que la solution est maintenable ? Est-ce que c’est clair ? Notre critère principal, c’est l’impact, la pertinence. Est-ce qu’on pense que le problème fait sens ? Ou est-ce qu’on pense juste que ce n’est pas forcément un use case (NDLR : cas d’utilisation) qui nous intéresse ? Et enfin, on regarde le budget, l’organisation, le planning. Est-ce que ça a l’air d’être un projet qui est viable en termes de micro-grants (NDLR : micro financements) entre 5 000 et 50 000 ? Est-ce que c’est une stratégie qui est faisable sur un an avec les financements qu’on a ? Et quels sont les aspects sur lesquels on peut aider et raffiner ? Donc après cette première approche, on fait une présélection des projets qui nous intéressent et ensuite on va contacter les personnes qui ont candidaté aux projets qui nous intéressent et leur poser des questions pour raffiner la direction de leur projet. Donc ça va être le moment où on pose des questions techniques en détail, comparer sur d’autres projets qui existent, pourquoi créer une nouvelle solution, pourquoi utiliser cette librairie plutôt que celle-là. Après cette phase d’échange, qui est souvent très enrichissante pour nous et pour les personnes qui candidatent, on fait une deuxième sélection d’évaluation qui va ensuite être envoyée à un comité externe qui supervise notre travail. C’est le life cycle d’un projet. Lorsqu’on a sélectionné un projet, ensuite on va travailler avec eux, on a plusieurs partenaires, des associations, des entreprises qui vont soutenir le projet avec des audits de sécurité, d’accessibilité, apporter de l’aide pour trouver des business models qui soient soutenables, trouver de l’écriture technique et identifier les besoins des projets. Donc on n’est pas seulement juste sur la sélection et voici vos sous et allez-y coder, on essaie vraiment d’être présent. sur toutes les étapes de développement pour pouvoir soutenir et appuyer les projets open source qu’on sélectionne le plus possible.
Walid Nouh: si vous voulez en savoir plus sur les financements NLnet, je vous renvoie vers l’épisode du podcast Projet Libre qui parle de NLNet justement, avec Lwenn, sur lequel on revient pendant plus d’une heure sur le fonctionnement, comment ça fonctionne, quels types de projets sont financés, etc. C’est assez passionnant. Moi, je suis un fan total de NLNet. J’en parle dans quasiment tous mes épisodes. Donc voilà, je ne suis pas… Raphaël, est-ce que tu peux s’il te plaît succinctement parler un peu de la méthode que tu as créée il y a bien longtemps maintenant pour faire de l’évaluation ?
Raphaël Semeteys: oui bien sûr merci, il y a 20 ans en fait. La méthode s’appelle QSOS, ça veut dire « qualification, sélection, logiciel open source ». Puis ça existe aussi en anglais, qualification etc. C’est une méthode que j’ai créée il y a une vingtaine d’années quand j’étais chez Atos et qu’on accompagnait nos clients dans le choix de logiciels libres open source. Et c’est quelque chose qu’on faisait déjà en interne. Au départ, c’est tout con, QSOS, ça n’a pas inventé l’eau chaude, véritablement. C’était faire des comparatifs, un peu comme ce qu’on trouvait dans les trucs de la FNAC, en disant, « tel téléviseur, voilà ses caractéristiques techniques, voilà ce qu’il permet de faire », et donc nous, on commençait à faire ça en interne. Puis après, dans mon boulot de conseil auprès de mes clients, dans l’accompagnement justement de leur stratégie open source, etc., on s’est dit « mais en fait… Cette méthode-là, on pourrait l’open sourcer elle-même ». Et donc, en quoi ça consiste ? Je l’ai dit, c’est une analyse de risque au départ. On va regarder plutôt le projet que le software lui-même pour essayer d’identifier les risques qui pourraient être liés à l’adoption du projet. Donc, la maturité et la pérennité, ça va être des aspects légaux, ça va être des aspects, est-ce qu’il y a de la gouvernance ? Comment est organisée la communauté ? Est-ce que les contributeurs font tous partie de la même entreprise ? Combien ils sont ? Ce genre de choses-là, est-ce que c’est industrialisé ? Est-ce qu’il y a du patch management ? Il y a toute une batterie de critères qui est standard, qui est définie dans la méthode elle-même et qui est appliquée systématiquement, quel que soit le type de logiciel. Ensuite, il y a une autre batterie de critères qui va dépendre de la famille de logiciels considérés pour pouvoir comparer des solutions les unes avec les autres. Si je prends des solutions de BI, injection de dépendance, framework back, front, etc. On va définir des grilles de critères.
Donc c’est organisé sous forme d’arbres qu’on va pouvoir, sur la base de ces grilles-là, on va pouvoir évaluer des solutions. Mais ce qu’il faut comprendre c’est que quand on a décidé d’open sourcer la méthode, ce qu’on s’est dit c’est, ce qu’on voudrait c’est faire de la veille technologique collaborative, donc communautaire. Parce qu’à partir du moment où on livrait des études, par exemple au ministère des Finances ou à d’autres clients, à partir du moment où on a livré l’étude, elle devient caduque, puisque les logiciels, les projets continuent à évoluer. Et donc on s’est dit « c’est dommage, il y a une déperdition d’énergie qui est énorme, alors qu’on analyse des communautés qui justement se mettent ensemble pour créer de la valeur. Donc est-ce qu’on ne peut pas créer de la valeur également en partageant la veille et en distribuant l’effort de veille ? ». Et c’est ça qui explique un peu comment est organisé QSOS. Alors je ne vais peut-être pas rentrer dans les détails là maintenant tout de suite, peut-être qu’on y reviendra un peu après.
Mais il y a un point qui est très important, c’est qu’on veut dissocier les activités de créer une grille d’évaluation de celle d’utiliser une grille d’évaluation que j’ai faite ou pas, que quelqu’un d’autre a créée, pour évaluer un logiciel. Et éventuellement, une autre personne, une tierce personne, peut utiliser des évaluations qui n’ont pas été faites par elle pour les comparer dans son contexte donné. Et c’est ça qui explique un peu comment est organisée la méthode et le fait que, notamment, on ait un système de notation qui soit le plus simple possible en disant un critère, à la fin, il est noté sur 0, 1, 2 : 0, ça ne fait pas. 2, ça couvre complètement ce qui est décrit dans le critère. Et 1, on est dans quelque chose qui est partiel, qui est intermédiaire.
Raphaël Semeteys
Et pour essayer de faire les choses les plus objectives possibles, pour que ça puisse être utilisé par d’autres, qui eux, lorsqu’ils vont s’approprier plusieurs évaluations et vouloir faire un choix, par exemple, je reviens sur des frameworks de BI, etc., ils vont regarder la partie maturité-pérennité, effectivement, parce que c’est très important. Mais ils vont être aussi capables de pondérer et de dire, moi, dans mon contexte, donc modéliser son contexte, forme de poids. qui vont s’appliquer sur ces différents arbres et grilles de critères. C’est comme ça qu’on articule les choses et se dit qu’on va produire de la valeur qui va être utilisée par d’autres. À partir de là, on a un format et on peut générer des rapports, etc. Ce genre de choses-là. Ça va, je pense que j’ai été trop long.
Walid Nouh: non, ça va. Je pense que la suite logique, c’est de passer le micro à Thierry pour expliquer comment ils utilisent justement cette méthode.
Thierry Aimé: effectivement, on a identifié cette méthode presque au moment de sa création. On a été peut-être un des premiers à s’y intéresser, extérieurs en tout cas à Atos. Et donc à cette époque, on était déjà avec régulièrement des choix de logiciels libres à faire. Et j’avais regardé les possibilités à l’époque qui existaient. Je disais justement qu’il y avait une solution poussée par Intel pour évaluer des logiciels libres dans le début des années 2000, mais qui était d’une très grande complexité avec énormément de critères, de sous-critères et des notations très fines à mettre en œuvre. Ça ne me paraissait pas nécessairement très praticable. Et ce que j’avais trouvé d’intéressant à l’époque, et qui s’est confirmé d’ailleurs, c’est que la méthode QSOS n’était pas mal dans le sens où elle ne coupait pas trop les cheveux en quatre. Elle était assez simple à mettre en œuvre et on arrivait à sortir une vision assez objective, je trouve quand on compare 2, 3, 4 logiciels dans un domaine donné.
Il y a un autre aspect qui nous plaisait énormément, c’est que le marché déjà à l’époque, maintenant il est interministériel, donc c’est encore à une autre échelle, mais déjà au début, dans les années 2005, il était déjà interdirectionnel, c’est-à-dire que toutes les directions du ministère des Finances en bénéficiaient. Donc en général, les directions n’ont pas du tout les mêmes agendas. Donc au moment où on faisait une étude, nous, pour un besoin, les autres n’avaient pas ce besoin, mais un an après, ils retrouvaient finalement le même besoin. Ils pouvaient reprendre ces études, regarder l’effet de pondération qui est un outil extrêmement intéressant parce que ça permet de contextualiser l’étude QSOS. Et donc, les autres directions qui, selon leur cycle de vie et d’intérêt pour tel ou tel logiciel libre, pouvaient donc rejouer cette méthode, la ressortir, l’adapter à leur contexte et obtenir dans leur contexte, la meilleure solution. Et ça, c’est un intérêt encore plus grand aujourd’hui où le marché est partagé avec l’ensemble des ministères.
Thierry Aimé
C’est des études que l’on fait mensuellement, elles sont techniques ou stratégiques. On met au point de départ un demandeur qui va exprimer un besoin, qui va définir des critères, etc. Dans le cadre de ce marché, une étude est réalisée, une étude QSOS est réalisée sur la base du besoin, évidemment, initialement présenté, mais qui peut s’élargir un peu puisque quand on fait les cadrages pour nos études, on est ouvert à l’ensemble des ministères. Donc tous les ministères peuvent partager et compléter la grille fonctionnelle, sachant que si moi je ne suis intéressé que par certains aspects de cette grille fonctionnelle, je pondère à zéro les autres. Donc c’est très simple d’adapter en fait le résultat de l’étude QSOS à mon contexte. Et donc, cette étude, une fois réalisée, elle peut continuer à vivre, puisqu’on pourra toujours la ressortir et adapter éventuellement les critères au contexte nouveau, peut-être, où un choix s’impose, peut-être un peu différent du choix initial.
Walid Nouh: les études, c’est vous qui les faites en interne ?
Thierry Aimé: alors, c’est des études qui sont réalisées dans le cadre de marché. Donc, j’ai évoqué au départ le marché de support logiciel libre, dans le cadre de ce marché de support, il y a une prestation d’études de veille qui est réalisée tous les mois sur des sujets qui sont choisis par l’administration et qui sont donc cadrés ensemble et réalisés par le prestataire, celui titulaire du marché, et restitués à l’ensemble des ministères qui peuvent participer. C’est une restitution en visioconférence maintenant et où chacun peut participer, peut participer et quand il s’agit donc d’études techniques ou une étude ou en tout cas une grille QSOS a été utile. Parce qu’on fait parfois des études où on peut malheureusement pas mettre en œuvre de grilles QSOS c’est pas toujours la solution idéale donc en tout cas quand c’est présenté sous forme d’étude QSOS on a donc à l’occasion de la restitution les fameux diagrammes qui permettent de comparer de visualiser les avantages et les inconvénients Et en tout cas, nous, un élément qui est absolument essentiel, c’est la pérennité des solutions, leur stabilité, leur fiabilité, effectivement, selon tous les critères génériques qui prévalent à toutes les études et qui sont un élément extrêmement important dans nos choix.
Walid Nouh: très bien. Benjamin, pour toi, en fait. Qu’est-ce que vous utilisez comme méthode ? Est-ce que vous avez développé quelque chose en interne ? Comment est-ce que vous faites pour justement évaluer dans le cadre des missions que vous avez ou des veilles que vous faites ces logiciels ?
Benjamin Jean: alors, j’ai réfléchi à ça en même temps.
On est assez agnostique dans le sens où on va utiliser à peu près tout ce qui existe pour répondre aux besoins des missions dans lesquelles on est. On n’est plus sur du sur-mesure. Alors, pas de manière péjorative, ça pourrait parfois. L’exemple, j’évoquais tout à l’heure l’évaluation de la valorisation. Et en fait, l’important, c’est déjà de contextualiser la valeur pour l’organisation. Je suis un centre de recherche. Qu’est-ce que je recherche quand je veux diffuser en open source ou réutiliser l’open source ? Quels sont mes critères à moi ? Pareil si je suis la Commission européenne, pareil si je suis une collectivité.
Benjamin Jean
Et de ce premier travail sur la valeur, on en tire ensuite des éléments à mesurer et on va trouver ce qui est automatisable, ce qui ne l’est pas et qui peut passer par des enquêtes ou d’autres méthodes de ce type-là. Donc la majorité du temps, on va vraiment faire ce travail avec l’acteur pour qui on est missionné, pour adapter, en utilisant tous les outils qui existent, une grille d’évaluation qui soit la plus pertinente pour répondre à ces enjeux. Et forcément, on réutilise de projet en projet des briques, mais il n’y a jamais eu deux cas similaires. Je prends l’exemple de ce centre de recherche, le CNES. Vous pourrez voir, il y a tout le travail qu’on a fait, publié sur Internet. Vous le retrouverez. La Commission européenne, on était plus sur les logiciels open source critiques pour la Commission. Pareil, vous retrouvez à chaque fois, c’est des… Les résultats ne sont pas les mêmes. Pour autant, on s’appuie énormément sur toutes les méthodes qui existent. Là, on va dans le même sens. Ensuite, l’autre contexte que j’évoquais tout à l’heure, qui était plus les appels à commun, en tout cas des appels à projet qui se rapprochent plus de ces logiques de commun. Là, généralement, on intervient plus sur ce qui fait que le projet est un commun. On est moins sur l’expertise métier qui reste souvent par l’acteur commanditaire ou l’acteur qui finance. Et le prisme qu’on essaye de prendre généralement, c’est dans les communs, on parle souvent du triptyque avec d’une part les ressources, d’autre part les communautés, et ensuite les règles de gouvernance des ressources. Et donc c’est de faire cette analyse des trois axes pour comprendre d’une part quelles sont les ressources et leur fiabilité, de comprendre quelles sont les communautés et aussi voir la pérennité du projet derrière la communauté. Et pareil, de réfléchir à l’organisation des acteurs entre eux et avec d’autres. pour voir dans quelle mesure c’est quelque chose qui est pérenne dans la durée ou pas. Là c’est plus réduit mais ça se rapproche aussi de ce qui a été évoqué tout à l’heure par NLnet pour vraiment s’assurer que le projet ait un intérêt à financer ce projet particulièrement.
Walid Nouh: effectivement tout ça c’est intéressant parce qu’on voit que en fonction de ce qu’on regarde, à quel moment dans la chaîne du développement de la vie du produit on évalue pas de la même manière. Une des questions que je voulais reposer à Raphaël c’est cette méthode QSOS qui a été développée il y a 20 ans elle est certes toujours où est-ce qu’elle en est en fait ? Actuellement elle en est où ?
Raphaël Semeteys: il faut différencier la méthode du projet et notamment du projet initial de dire on voulait créer de la veille technologique communautaire et collaborative la méthode elle existe toujours elle est utilisée toujours aujourd’hui Dans le projet, pour faciliter le travail, le déroulé de la méthode et surtout le partage d’informations, on avait commencé à développer des outils. Et moi, il y a une dizaine d’années, je me disais toujours : « si j’appliquais QSOS au projet QSOS, je pense que sur la partie maturité, pérennité, je ne serais pas super top ». Parce que c’est quand même vachement lié à moi, à Atos. Alors après, il y a des gens qui sont partis, il y a d’autres gens qui quittent QSOS, etc. Mais la pérennité n’est pas garantie. Quand j’ai quitté Atos, ça s’est un peu confirmé. Il y a un peu d’orphelinat quand même qui s’est ouvert là. Mais pour autant, la méthode elle-même, elle reste toujours valable. C’est plus l’outillage maintenant qui est complètement déprécié, obsolète vu les technologies. Mais on est en train de travailler sur un reboot de QSOS justement. Donc ça tombe bien. Et là, cette fois-ci, on veut le faire vraiment de la manière la plus communautaire possible. Donc là, ce qu’on est en train de faire, c’est qu’on est en train de préparer les bases techniques pour pouvoir avoir quelque chose pour rebooster le projet, et ensuite essayer de venir faire fédérer une communauté là-dessus. Donc si vous êtes intéressé par ce sujet-là, suivez-nous, contactez-moi, ça va être disponible sur GitHub bientôt. Là on va parler de l’aspect code et développement des outils, mais l’objectif vraiment c’est de collaborer et de contribuer à des évaluations, c’est clair. Et très vite vont se poser des questions, on l’espère. Aujourd’hui, on n’a jamais eu à vraiment mettre en place des règles de gouvernance et tout, parce qu’on n’a pas été confronté, on ne voulait pas construire une usine à gaz avant d’être confronté au problème. Lorsqu’il va y avoir plusieurs personnes qui vont vouloir corriger les évaluations, ou alors modifier des grilles, comment on met à jour des évaluations sur des versions de grilles qui sont plus récentes, ce genre de choses-là, et tout ça, ça va être très très intéressant. Donc venez nous rejoindre, là très vite on va essayer de relancer ça. Voilà, donc je ne sais pas si ça répond à la question.
Les tendances qui vont avoir un impact sur l’évaluation
Walid Nouh: ça répond à la question. Si maintenant on parle un peu en guise de conclusion du futur, comment vous voyez un petit peu, quelles sont un peu, j’allais dire, les tendances qui font qu’on va avoir besoin d’évaluer ou qui vont changer la manière dont vous évaluez les choses ? Dans ce qui se passe à l’heure actuelle ou dans ce que vous pressentez qui va se passer, qu’est-ce qui va remettre en cause la manière d’évaluer les choses ? Lwenn, est-ce que tu veux nous en parler un petit peu ? C’est un sujet très vaste, on pourrait en parler pendant très longtemps.
Lwenn Bussière: oui, c’est un sujet assez difficile aussi. Donc, ouf… c’est un sujet difficile.
Walid Nouh: prends un ou deux, prends un point ou deux qui deviennent à l’esprit, ça ira très bien.
Lwenn Bussière: pour nous, à NLnet, on a eu beaucoup de challenges au niveau de l’échelle, puisque la quantité de projets qui candidatent est de l’ordre du millier par an et qu’on est une équipe de quatre pour évaluer. Donc on a vraiment eu quelques soucis en termes d’échelle pour pouvoir continuer à avoir la qualité et l’attention qu’on porte aux détails de chaque projet qu’on reçoit, qui n’est pas quelque chose qu’on souhaite sacrifier, mais on est encore en train d’essayer de trouver un compromis qui fonctionne par rapport à la nouvelle échelle à laquelle on travaille.
De manière plus vaste, on a beaucoup parlé avant cette table ronde des enjeux du CRA qui commencent à changer les dynamiques d’évaluation.
Lwenn Bussière
Je pense que Benjamin est très concerné, donc je vais probablement te passer la patate chaude.
Walid Nouh: le Cyber Resilience Act.
Lwenn Bussière: de notre côté, c’est quelque chose qui nous tient à cœur, mais qui nous tenait déjà à cœur dans le sens où, quand on évalue des projets, on pose des questions dès le début sur l’architecture, les bonnes pratiques,les dépendances, le choix des languages qui peut impacter beaucoup de qualités, en termes de sécurité, d’accessibilité, de pérennité donc on essaye dès le début de pouvoir discuter de ces choses mais je pense qu’on est tous impactés par le CRA et la manière dont ça va changer nos méthodes d’évaluation et impacter les aspects qu’on recherche dans les différents projets.
Walid Nouh: Nenjamin, de ton côté ?
Benjamin Jean: alors le teasing pour le CRA, c’est que demain matin, vous avez une présentation sur un guide qu’on a produit pour le CNLL sur le Cyber Resilience Act, qui concerne vraiment la réglementation européenne en matière de cybersécurité associée aux projets qui sont mis sur le marché européen. Donc je vous invite demain matin à venir à la conférence et le guide sera publié à ce moment-là aussi. On a essayé vraiment d’aller le plus loin possible, notamment dans les effets que ça peut avoir vis-à-vis des acteurs d’open source, avec ce prisme particulier de l’open source. Et ça, c’était la réponse un peu facile. Sinon, pour ta question initiale, moi, ce que je vois aussi, c’est…
Dans le cas des projets qu’on a été amenés à auditer, souvent ce dont on s’est rendu compte, c’est qu’il y avait une dépendance via des API à plein de services qui étaient fournis par d’autres fournisseurs. Et je pense que dans l’audit des projets, dans l’évaluation des projets, même des projets open source, c’est important de prendre en compte cette dépendance d’un projet vis-à-vis d’autres projets. Parce qu’en fait, on n’est pas que dans une vision statique du périmètre du code. Ça, c’est un point qui est intéressant à avoir en tête.
Benjamin Jean
Et un enjeu peut-être pour les années à venir, c’est la qualité. L’open source, ça peut être soit un gros bloc, soit un grain très très fin. On travaille beaucoup sur les grains très très fins. Et là, ça ne peut que être automatisé. Et pour automatiser l’évaluation de ces grains très très fins, de toutes les bibliothèques que vous utilisez dans votre organisation, il faut avoir des métadonnées qui sont béton, qui sont super bonnes. Et là, il y a un gros travail encore à faire sur la qualité des métadonnées et ensuite la façon dont on peut les traiter. On a des méthodes pour les traiter, mais on n’a pas toutes les métadonnées qu’on aimerait avoir.
Walid Nouh: Raphaël, ton côté ? Qu’est-ce que tu vois comme évolutions qui vont impacter ta méthode, ta manière d’évaluer ?
Raphaël Semeteys: juste pour réagir à ce que tu disais sur les métadonnées, c’est clair. Il y a 20 ans, quand j’ai créé QSOS, il n’y avait pas SPDX, par exemple. Typiquement, ça, c’est quelque chose qu’on va se baser là-dessus. Ça, c’est un point important. Après, sur ce qui va changer, sur la manière d’évaluer, c’est ce qui a changé dans l’IT. Pour moi, il y a deux grands trucs qui changent. Il y a le cloud et l’IA. Le cloud, pourquoi ? C’est avec toutes les réactions qu’il y a eu des projets communautaires qui se sont dit « Ah ouais, mais il faut qu’on change nos licences pour réagir par rapport à des utilisateurs type cloud qui vendent notre projet as a service et qui ne contribuent pas ». Donc on voit qu’il y a des gens qui sont sortis de la définition de l’open source à cause de ça. Je pense à Mongo, il y en a plein, Elastic, Terraform et demain il y en aura d’autres. Donc il y a des nouvelles licences qui émergent. On peut associer à ça aussi d’autres types de licences où il y a des notions de Code of Conduct ou d’éthique qui sont rentrées dans les projets. Il y a des licences éthiques qui apparaissent. Ça, c’est le premier point. Donc, c’est sur les termes licences. Qu’est-ce que ça veut dire Open Source ? Mais pourtant, il faut quand même évaluer les choses. Et l’IA, pourquoi ? Et là, je vais faire rapidement. L’IA, parce qu’elle peut servir dans la partie évaluation en se basant sur des choses qui sont formelles et clairement, objectivement évaluées, à faire quelque chose en langage naturel. Donc je vois, c’est utiliser l’IA pour aller plus loin dans l’évaluation.
Et après, il se pose la vraie question d’évaluer l’IA, évaluer ce que ça veut dire Open Source AI. Donc là, je renvoie vers la discussion de ce matin et l’autre table ronde qui était plus animée que la nôtre. Nous, on est cool. Là, il y avait des étincelles. Et je renvoie à la prez que je ferai demain, d’ailleurs, sur ce sujet-là, sur ce que ça veut dire Open Source, en tout cas pour un industriel comme moi, et ce que ça veut dire ouverture quand on parle d’IA. Donc ça, ça va changer des choses et on voit qu’on dépasse la notion de code. Tu parlais d’API, on va parler de datasets, on va parler d’algorithme. Enfin voilà, il y a ce genre de questions qui se posent. Mais je me tais.
Raphaël Semeteys
Walid Nouh: Thierry, pour finir.
Thierry Aimé: oui, bon, nous, on est vraiment utilisateur final. Donc je ne pense pas que les choses ont trop évolué, à part peut-être la question de l’IA qui, effectivement, n’est pas vraiment pris en compte aujourd’hui dans la méthode QSOS.
En l’état, la méthode nous rend parfaitement le service qu’on en attend et donc de ce point de vue, il faut qu’elle continue d’exister. Je suis content d’apprendre qu’un reboot se prépare. En tout cas, on contribuera très volontiers par nos études puisque nos études de veille réalisées depuis 4 ans sont systématiquement mises à disposition en open source sur la forge de l’Adulact. Alors l’URL c’est gitlab.adulact.net/marche-sll : Support logiciel libre, SLL. Et donc sur cette page, vous verrez publié l’ensemble des études réalisées depuis 4 ans.
Thierry Aimé
Et donc dans notre action de publication, on ne manquera pas de publier sur la nouvelle instance de partage des études de veille QSOS pour participer à l’effort collectif sans problème puisque de toute façon c’est déjà open source. Alors, toutes les études ne contiennent pas d’études QSOS, mais en tout cas, à chaque fois qu’elles en contiendront, on le fera. Voilà.
Walid Nouh: parfait, il est 17h45, on a réussi à tenir 45 minutes. Petit mot de conclusion, c’est un sujet très vaste. Là, on n’a pas beaucoup parlé, on n’a pas rentré très dans le détail. Je vous renvoie sur le podcast Projets Libres si vous voulez en savoir plus là-dessus. Et on va commencer une série spécifiquement qui va s’appeler Comment évaluer le logiciel libre ? dans lequel on va aller voir des acteurs qui ont ces besoins d’évaluation et on va leur demander qu’est-ce que vous évaluez, pourquoi, comment, quels sont vos critères, etc. Donc là, ça va commencer en janvier avec Raphaël. On va commencer à parler à des gens et à faire des épisodes là-dessus. Merci à toutes et à tous. La conférence était filmée et elle sera aussi disponible sur le podcast avec une transcription. On espère que tout sera ok pour les gens qui n’ont pas pu être là. Merci à toutes et à tous. Bonne soirée.
Raphaël Semeteys: merci.
Cette conférence a été enregistrée lors du salon Open Source Experience à Paris le 5 décembre 2024.
Licence
Cette conférence est publiée sous la licence CC BY-SA 4.0 ou ultérieure.