Open Source, entreprises & communauté

Discussion avec Benjamin Jean, Open Law. Initialement publié sur le Medium d’Epidemium, sous licence CC-BY-ND.

Quel est l’apport de l’open source dans les domaines de la recherche et de l’innovation, par rapport aux méthodes classiques ?

Tout d’abord, l’apport de l’open source dans le domaine de la recherche est presque naturel. L’open source y existe depuis très longtemps. C’est un modèle d’autant plus pertinent que l’objectif même de la recherche n’est pas de faire du profit ou de vendre des licences. La plupart du temps, cela permet de travailler avec des pairs, de mutualiser des objets de recherche, des connaissances. L’open source dans la recherche est quelque chose qui fonctionne et qui n’est pas remis en cause. Même dans la période actuelle où les centres de recherche doivent s’auto-financer, on continue à avoir de grandes pratiques en matière d’open source, et ce, dans tous les domaines (Inria, Inra, CNRS, …).

Souvent les logiciels produits en open source, dans le domaine de la recherche, sont des logiciels qui sont très métiers, très experts, pas nécessairement industrialisés et donc difficiles à utiliser dans un contexte hors recherche, qu’il soit professionnel ou industriel. C’est peut-être ce qui est en train de changer, de se formaliser. Les centres de recherche y sont de plus en plus attentifs et il y a quelques grands groupes qui font le pari d’aller chercher dans le monde de la recherche de bons logiciels et d’opérer cette transformation, ce passage. C’est quelque chose qui s’observe de plus en plus : des partenariats entre privé et public, notamment dans le domaine de l’intelligence artificielle, où souvent la recherche produit des projets en open source et le privé construit des modèles économiques autour de ça.

Le rapport et l’apport de l’open source dans l’innovation est néanmoins plus complexe à expliquer, moins automatique ou naturelle. En revanche, on observe aujourd’hui, et c’est lié au numérique, à l’ouverture internationale, à la capacité offerte à plein d’acteurs de travailler ensemble, que les projets numériques se rapprochent de plus en plus du modèle de l’open source. L’open source, et notamment toutes règles définies dans ce type de projet, constituent un terrain favorable à l’innovation collaborative, à la mutualisation, à des structures de marché, etc. L’open source donne la possibilité de faire avancer les choses dans un modèle beaucoup plus horizontal par rapport à ce que l’on connaît par ailleurs.

On observe souvent que les pratiques d’innovation en open source se font en réaction à des pratiques d’innovation monopolistiques : un grand acteur devient dominant sur un marché et, par réaction, les autres acteurs favorisent l’ouverture de ce marché en s’appuyant sur des logiques open source. Dans ce cas, l’open source va permettre de rendre compétitif un marché, en sortant de ce marché une ressource qui auparavant appartenait qu’à un seul. C’est ce qu’on observe dans différents domaines.

Je peux citer l’exemple, dans le domaine du droit au sein d’Open law, d’un projet dont l’objectif est de créer une base de données en open data (IA & Droit : Datasets d’apprentissage), spécialement dédiée à l’entraînement d’algorithmes. Un certain nombre d’acteurs juridiques, privés et publics, dont la Cour de Cassation, se sont réunis et ont réalisé un travail d’alignement des données et de suppression des biais éthiques avant de diffuser le tout en Open Data. Ce projet est porté par la volonté que ce ne soit plus une seule personne qui aie le monopole sur les données, que l’innovation soit ouverte et le marché plus facile d’accès.

En matière de blockchain, c’est aussi un phénomène que l’on constate avec des projets très fermés issus des premiers acteurs d’envergure qui se sont positionnés sur le secteur, face auxquels d’autres initiatives se sont montées avec des modèles open source pour pouvoir lutter.

Enfin, un autre exemple plus connu, celui d’Android, projet ouvert et collaboratif, qui a réussi à percer dans le marché de l’exploitation pour mobile en favorisant cette idée de travailler ensemble et de gratuité du logiciel, là où auparavant il y avait peu d’acteurs et où les fabricants devaient payer un coût de licence par téléphone vendu. On pourrait aller plus dans les détails de cet exemple d’Android pour voir ce qui a, ou non, marché et pourquoi, mais il illustre bien le fait de pénétrer dans un marché fermé et verrouillé en mettant en place une logique d’open source. Sans elle, cela n’aurait pu se faire.

Quel est l’intérêt pour une entreprise de participer à des projets open source ? Pour une grande entreprise ? Pour une petite entreprise ?

Le premier intérêt à pratiquer l’open source, c’est qu’on va se servir de briques, de composants déjà utilisés par des milliers voire des millions d’autres personnes. Par là, on bénéficie d’un premier travail de qualité. Par exemple, le logiciel que l’on va utiliser dans notre produit est un logiciel sur lequel plein d’autres yeux se sont posés, plein d’autres personnes ont pu y passer du temps ; même si ce sont des concurrents, on considère que leur travail est équivalent au nôtre. Cela enlève ainsi une grosse partie des ressources que l’on aurait sinon dû mobiliser pour un même objectif de qualité.

En termes d’usage classique, l’intérêt de l’open source dans des domaines comme l’embarqué, et pour répondre à la question de l’open source et développement, se rapporte à la question de l’interopérabilité. Dans le domaine de l’embarqué et de l’IoT (Internet of Things), tout doit être interopérable, et il n’y a que l’open source pour utiliser, implémenter et respecter des standards ouverts, et favoriser ainsi l’interopérabilité. L’open source facilite et encourage la convergence qui est nécessaire.

La question de savoir ce qui peut amener une entreprise à participer à des projets open source est un peu plus compliquée. Il y a d’abord le côté mutualisation, c’est-à-dire qu’il est possible de se dire que développer seul un projet n’a pas de sens : soit parce que c’est un projet trop dynamique, c’est-à-dire qui évolue trop rapidement, soit parce qu’il n’est pas assez stratégique et trop coûteux. Ainsi, il est plus stratégique de chercher à mutualiser et à développer ce projet avec d’autres acteurs. C’est une solution qui fonctionne plutôt bien. L’intérêt est qu’en développant le projet en open source, on s’assure qu’il n’y ait pas un acteur qui en profite au détriment des autres car les règles sont strictes et établies ; tout le monde sait que ce qui est produit doit profiter à chacun. Il est possible de mentionner l’exemple d’OpenStack, infrastructures de cloud computing en open source, projet beaucoup financé aux origines par la Nasa, et dont ensuite, pour pouvoir à la fois mutualiser les développements et aussi assurer la pérennité du projet, la gouvernance a été ouverte.

L’open source n’est néanmoins pas qu’une question de licence et cela demande généralement une vraie acculturation des acteurs. Participer à un projet open source, ce n’est pas non plus seulement contribuer mais c’est aussi participer à la gouvernance. Dans ce type de projet, il ne faut pas que ce soit un acteur qui établisse la feuille de route. Il faut faire en sorte que la gouvernance soit suffisamment partagée et horizontale afin que tout le monde garde confiance en le projet.

Bien sûr ces propos généraux peuvent être relativiser et ce ne sera, par exemple, pas les mêmes motivations qui pousseront une petite entreprise, à participer à un projet open source. La première raison est que l’open source, c’est généralement gratuit. La deuxième est une question de culture : les petites entreprises sont plus dans l’optique de tirer partie de ce qui existe déjà, alors que les grands groupes aiment l’idée qu’un produit ou une solution soit recherché, développé, produit et commercialisé en interne. C’est donc une culture qui est peut-être un peu plus souple. La troisième est que, dans un projet open source, c’est schématiquement celui qui fait, qui est entendu. Par conséquent, cela crée une certaine égalité méritocratique dans laquelle les plus petits se retrouvent. De fait, il y a un certain nombre de projets open source d’envergure qui ont dans leur board, dans leur comité de gestion des grands groupes mais aussi de toutes petites structures dont c’est le métier et qui sont reconnues pour ce qu’elles font. À ce titre, elles ont un pouvoir aussi important que de gros acteurs qui ont beaucoup d’argent mais qui ne sont pas en capacité de s’occuper du projet.

Les projets open source, diffèrent entre eux par de nombreux aspects mais se rejoignent sur quelques points structurants tels que la question de la gouvernance. Très souvent ils adoptent des principes de méritocratie : celui qui produit doit être reconnu par ses pairs et si une entité a des responsabilités, c’est qu’elle est estimée par ces derniers comme étant suffisamment capable. C’est quelque chose d’assez simple qui a abouti à de belles réussites. Par exemple, dans OpenStack, il y avait une petite entreprise qui a été rachetée par Red Hat, grosse société américaine cotée, notamment par ses compétences et par la reconnaissance qu’elle tirait d’être membre du board : c’est une position très stratégique. En faisant cette acquisition, Red Hat a rejoint le mouvement en s’associant toute la légitimité de ces acteurs à ses contributions. Un autre exemple, toujours sur OpenStack, et concernant une autre entreprise française nommée Objectif Libre, dans la région toulousaine : très grande contributrice du projet, elle a été reconnue pour ses contributions et son expertise, et travaille depuis pour des grands groupes en France sur ce sujet-là. Ainsi, le grand groupe français qui veut bénéficier pleinement d’un produit aussi complexe et stratégique qu’Open Stack va s’appuyer sur les compétences d’un “petit” acteur tel qu’Objectif Libre parce qu’il a le contact et sait que son expertise est reconnue à l’international.

Point peut-être moins traité, quel est l’intérêt pour une communauté de bénévoles s’inscrivant dans un projet open source de voir participer des entreprises à leurs travaux ?

Cette question pose aussi celle de la maturité des projets. Il y a beaucoup de projets qui sont incapables de recevoir des entreprises comme contributrices : ils ne sont pas structurés comme tels, et il y a un gros risque de déséquilibre. Un projet avec cinq petits contributeurs principaux, par exemple, s’il y a une grande entreprise qui arrive, cela change tout. L’arrivée d’une grosse entreprise dans un projet open source peut vite changer la donne. Ainsi, pour les petits projets, c’est un peu compliqué.

En revanche, sur de gros projets communautaires open source, c’est différent. Il y a, par exemple, le projet PostGreSQL, open source, libre, horizontal : il n’y a pas une association PostGreSQL qui regroupe tous les contributeurs internationaux ; ce sont pleins de collectifs qui sont derrière une technologie. C’est une technologie qui est en ce moment en vogue, qui remplace Oracle chez de gros industriels. Depuis peu, des entreprises rejoignent PostGreSQL France pour contribuer directement au projet. On y retrouve des entreprises telles que la SCNF, la Société Générale, le Crédit Mutuel, Air France, etc. Par cette adhésion et leurs actions communes, elles s’accordent pour financer les unes après les autres les besoins qu’elles ont en termes de développement de l’outil ; plutôt que de faire appel à un prestataire externe pour faire ces changements, ajustements et de les utiliser uniquement en interne sans les partager, elles demandent à quelqu’un de la communauté PostGreSQL de produire ce développement directement dans le projet afin que tout le monde puisse en profiter. C’est une logique assez vertueuse et qui est un très bon vecteur de développement et de diffusion du projet ainsi que de cette technologie.

Qu’est-ce qui protège la mise en place d’un cercle vertueux où chaque type d’acteurs bénéficie de la contribution de l’autre, sans que l’un soit lésé, sans que le rapport soit inégal ?

Il y a plusieurs éléments. Le premier l’ouverture du logiciel : la licence qui va garantir que tout ce qui est soumis sous cette licence-là, pourra être réutilisé, mais aussi tout ce qui est complémentaire aux aspects juridiques tel que l’accessibilité du code, sa documentation, les outils nécessaires à son installation, etc. Globalement savoir si une personne peut réellement s’approprier le logiciel qui est en open source ou s’il faut considérer que, malgré la licence, il n’y a qu’un seul acteur capable d’exploiter la technologie. C’est donc l’accès au code, tant d’un point de vue juridique que matériel.

Le deuxième, c’est s’assurer que la gouvernance soit complètement horizontale, que tout le monde puisse avoir confiance dans le développement de l’outil et qu’il n’y ait pas un acteur qui fasse travailler les autres gratuitement. C’est l’association, la structure en charge du projet qui sera normalement vecteur de transparence et donc de confiance.

Comment le secteur de la santé peut, tout particulièrement, bénéficier de ces collaborations ?

Le secteur de la santé est un bon exemple d’un secteur qui est dominé par de grands monopoles. Quelques acteurs détiennent une bonne partie du marché, et cette logique open source de collaboration peut offrir la possibilité de déterminer ce qui peut-être sorti du marché, c’est-à-dire ce qui peut être mis dans une logique collaborative et open source et, de ce fait, de permettre à d’autres acteurs, actuellement en dehors du marché, d’y contribuer. Plus le marché est fermé à la base, plus il y a du potentiel pour l’open et le collaboratif.

Peux-tu citer des grands exemples de collaboration fructueuses ?

Il y en a beaucoup. En ce moment, je m’intéresse à l’innovation qui est réalisée à l’échelle d’écosystème, plutôt que l’innovation faite à l’échelle d’une organisation. On regarde une innovation qu’un ensemble d’acteurs peut faire émerger. C’est le cas des projets menés au sein d’Open Law : la base de données susmentionnée, d’autres exemples en matière de logiciel, de partage de code. Par exemple, dans le domaine juridique, le Programme 5 a réuni toutes les Cours suprêmes pour les faire réfléchir ensemble à la question de l’ouverture et de la vulgarisation de la jurisprudence. C’est un contexte de collaboration qu’elles ne connaissaient pas et elles ont vu au fur et à mesure des réunions l’intérêt qu’il y a, ne serait-ce que de discuter et de partager, pour faire les choses ensemble.

L’open source, c’est un moyen pour les acteurs qui veulent travailler ensemble de le faire et de s’accorder sur un cadre. La plupart du temps, ils vont réussir beaucoup plus facilement à le faire lorsqu’ils s’accordent sur le cadre, qui peut être très strict mais au moins très clair de l’open source. On sait que ce que l’on fait, on le fait pour le partager et si ça marche c’est peut être des choses que l’on va partager plus tard.

Autre exemple, c’est La Fabrique des mobilités où l’on réunit les acteurs, français pour l’instant, du secteur de la mobilité et on les fait travailler ensemble sur des ressources partagées, sur la base d’open source, d’open data.

La mobilité est vraiment un secteur intéressant et d’autres exemples de projets asiatiques, chinois notamment, sont vraiment dans cette logique : ils disent sans ambigüité la nécessité de produire ensemble, le fait que l’on est meilleur ensemble. Le projet open source Apollo en est un exemple dans le secteur des voitures autonomes, lancé par Baidu, qui réunit 53 entreprises.

Enfin, dans le domaine du spatial, le projet Fédération soutenu par le CNES vient appliquer ces mêmes idées à l’innovation dans le spatial.

Comment explique-t-on la démocratisation des projets open source ?

Cette démocratisation est certainement liée au fait que tout le monde maintenant se met à parler numérique et que la plupart des acteurs qui font du numérique ne le font pas parce que c’est leur métier, mais parce que c’est un besoin pour leur métier et ainsi c’est nécessaire et stratégique.

C’est une nécessité, mais nécessairement une plus-value. Mutualiser une telle tâche devient donc parfaitement logique car elle leur permet de rester concentrés et compétitifs sur leur “vrai” métier tout en mutualisant sur tout ce qui lui est nécessaire mais non spécifique.