La passion du pair-à-pair

Binaire : Tout d’abord, peux-tu nous retracer rapidement le parcours depuis la petite fille en Bretagne jusqu’à la membre Académie des sciences ?

AMK : Oui, je viens de Bretagne ; je suis la petite dernière d’une fratrie de quatre. On a tous suivi des études scientifiques. Au lycée, en seconde, j’avais pris option informatique pour aller dans un lycée particulier à Saint-Brieuc. À la fac, j’hésitais entre l’économie, les maths, l’informatique, et j’ai choisi l’informatique, un peu par hasard j’avoue. Je n’avais pas une idée très précise de ce que c’était mais il se trouve que j’avais un frère informaticien, qui avait fait un doctorat, et ça avait l’air d’un truc d’avenir !

J’ai découvert la recherche pendant mon stage de maîtrise, où j’ai étudié les architectures des ordinateurs. Puis, en DEA et en thèse, j’ai bifurqué vers les systèmes distribués, là encore, un peu par hasard. La façon de travailler en thèse m’a beaucoup plu, et m’a donné envie de continuer dans cette voie. J’ai donc poursuivi un postdoc à Amsterdam, avec un chercheur qui m’a beaucoup inspiré, Andy Tanenbaum. C’est là que j’ai commencé à travailler sur les systèmes distribués à large échelle – mon sujet principal de recherche depuis.

Après deux ans comme maitresse de conférences à Rennes, j’ai passé cinq ans comme chercheuse pour Microsoft Research à Cambridge en Angleterre. C’était très chouette. Ensuite, je suis devenue directrice de recherche Inria et j’ai monté une équipe sur les systèmes pair-à-pair, un sujet très en vogue à l’époque. Cela m’a conduite à créer une start-up, Mediego, qui faisait de la recommandation pour les journaux en ligne et exploitait les résultats de mon projet de recherche. En 2019, juste avant le Covid, j’ai vendu la start-up. Depuis je suis professeure à l’EPFL. J’y ai monté un labo, toujours sur les systèmes distribués à large échelle, avec des applications dans l’apprentissage machine et l’intelligence artificielle.

Binaire : Pourquoi est-ce que tu n’es pas restée dans l’industrie après ta start-up ?

AMK : La création de ma start-up a été une expérience très enrichissante techniquement et humainement. On était parti d’un algorithme que j’avais développé et dont j’étais très fière, mais finalement, ce qui a surtout fonctionné, c’est un logiciel de création de newsletters qu’on avait co-construit avec des journalistes. Les joies du pivot en startup. Et à un moment donné, j’avais un peu fait le tour dans le sens où, même si ce n’était pas une grosse boîte, une fois qu’on avait trouvé notre marché, je m’occupais essentiellement des sous et des ressources humaines… et plus tellement, plus assez, de science. Donc j’ai décidé de revenir dans le monde académique que je n’avais pas complètement quitté, puisque j’y avais encore des collaborations. J’ai aimé mon passage dans l’industrie, mais j’aime aussi la nouveauté, et c’est aussi pour ça que j’ai pas mal bougé dans ma carrière. Et après quelque temps, le monde académique me manquait, les étudiants, les collègues. Et puis, ce qui me plaît dans la recherche : quand on a envie, on change de sujet. On fait plein de choses différentes, on jouit d’une énorme liberté et on est entouré d’étudiants brillants. J’avais vraiment envie de retrouver cette liberté et ce cadre.

Et puis, au vu de tout ce qui se passe avec ces grosses boîtes en ce moment, je me félicite d’être revenue dans le monde académique ; je n’aurais pas du tout envie de travailler pour elles maintenant….

Binaire : Ton premier amour de chercheuse était le pair-à-pair. Est-ce que tu peux nous expliquer ce que c’est, et nous parler d’algorithmes sur lesquels tu as travaillé dans ce cadre ?

AMK : Commençons par les systèmes distribués. Un système distribué consiste en un ensemble de machines qui collaborent pour exécuter une application donnée ; l’exemple type, ce serait les data centers. On fait faire à chaque machine un morceau du travail à réaliser globalement. Mais à un moment donné, il faut quand même de la synchronisation pour mettre tout ça en ordre.

La majorité des systèmes distribués, jusqu’au début des années 2000, s’appuyait sur une machine, qu’on appelle un serveur, responsable de l’orchestration des tâches allouées aux autres machines, qu’on appelle des clients. On parle d’architecture client-serveur. Un premier inconvénient, qu’on appelle le passage à l’échelle, c’est que quand on augmente le nombre de machines clientes, évidemment le serveur commence à saturer. Donc il faut passer à plusieurs serveurs. Comme dans un restaurant, quand le nombre de clients augmente, un serveur unique n’arrive plus à tout gérer, on embauche un deuxième serveur, puis un autre, etc. Un second problème est l’existence d’un point de défaillance unique. Si un serveur tombe en panne, le système en entier s’écroule, alors même que des tas d’autres machines restent capables d’exécuter des tâches.

Au début des années 2000, nous nous sommes intéressés à des systèmes distribués qui n’étaient plus seulement connectés par des réseaux locaux, mais par Internet, et avec de plus en plus de machines. Il est alors devenu crucial de pouvoir supporter la défaillance d’une ou plusieurs machines sans que tout le système tombe en panne. C’est ce qui a conduit aux systèmes pair-à-pair.

Binaire : On y arrive ! Alors qu’est-ce que c’est ?

AMK : Ce sont des systèmes décentralisés dans lesquels chaque machine joue à la fois le rôle de client et le rôle de serveur. Une machine qui joue les deux rôles, on l’appelle un pair. En termes de passage à l’échelle, c’est intéressant parce que ça veut dire que quand on augmente le nombre de clients, on augmente aussi le nombre de serveurs. Et si jamais une machine tombe en panne, le système continue de fonctionner !

Bon, au début, les principales applications pour le grand public étaient… le téléchargement illégal de musique et de films avec des systèmes comme Gnutella ou BitTorrent ! On a aussi utilisé ces systèmes pour de nombreuses autres applications comme le stockage de fichiers ou même des réseaux sociaux. Plus récemment, on a vu arriver de nouveaux systèmes pair-à-pair très populaires, avec la blockchain qui est la brique de base des crypto-monnaies comme le Bitcoin.

Maintenant, entrons un peu dans la technique. Dans un système distribué avec un très grand nombre de machines (potentiellement des millions), chaque machine ne communique pas avec toutes les autres, mais juste avec un petit sous-ensemble d’entre elles. Typiquement, si n est le nombre total de machines, une machine va communiquer avec un nombre logarithmique, log(n), de machines. En informatique, on aime bien le logarithme car, quand n grandit énormément, log(n) grandit doucement.

Maintenant, tout l’art réside dans le choix de ce sous-ensemble d’environ log(n) machines avec qui communiquer. La principale contrainte, c’est qu’on doit absolument éviter qu’il y ait une partition dans le réseau, c’est-à-dire qu’il doit toujours exister un chemin entre n’importe quels nœuds du réseau, même s’il faut pour cela passer par d’autres nœuds. On va distinguer deux approches qui vont conduire à deux grandes catégories de systèmes pair-à-pair, chacune ayant ses vertus.

La première manière, dite « structurée », consiste à organiser tous les nœuds pour qu’ils forment un anneau ou une étoile par exemple, bref une structure géométrique particulière qui va garantir la connectivité du tout. Avec de telles structures, on est capable de faire du routage efficace, c’est-à-dire de transmettre un message de n’importe quel point à n’importe quel autre point en suivant un chemin relativement court. Par exemple, dans un anneau, en plaçant des raccourcis de façon astucieuse, on va pouvoir aller de n’importe quelle machine à n’importe quelle autre machine en à peu près un nombre logarithmique d’étapes. Et la base de tous ces systèmes, c’est qu’il y a suffisamment de réplication un peu partout pour que n’importe quelle machine puisse tomber en panne et que le système continue à fonctionner correctement.

La seconde manière, dite « non structurée », se base sur des graphes aléatoires. On peut faire des choses assez intéressantes et élégantes avec de tels graphes, notamment tout ce qui s’appelle les algorithmes épidémiques (j’avais parlé de ça dans un autre article binaire). Pour envoyer un message à tout un système, je l’envoie d’abord à mes voisins, et chacun de mes voisins fait la même chose, etc. En utilisant un nombre à peu près logarithmique de voisins, on sait qu’au bout d’un nombre à peu près logarithmique d’étapes, tout le monde aura reçu le message qui s’est propagé un peu comme une épidémie. Cela reste vrai même si une grande partie des machines tombent en panne ! Et le hasard garantit que l’ensemble reste connecté.

On peut faire évoluer en permanence cette structure de graphe aléatoire, la rendre dynamique, l’adapter aux applications considérées. C’est le sujet d’un projet ERC que j’ai obtenu en 2008. L’idée était la suivante. Comme je dispose de ce graphe aléatoire qui me permet de m’assurer que tout le monde est bien connecté, je peux construire au-dessus n’importe quel autre graphe qui correspond bien à mon application. Par exemple, je peux construire le graphe des gens qui partagent les mêmes goûts que moi. Ce graphe n’a même pas besoin de relier tous les nœuds, parce que de toute façon ils sont tous connectés par le graphe aléatoire sous-jacent. Et dans ce cas-là, je peux utiliser ce réseau pour faire un système de recommandation. En fait, au début, je voulais faire un web personnalisé et décentralisé. C’était ça, la « grande vision » qui a été à la base de la création de ma startup. Sauf que business model oblige, finalement, on n’a pas du tout fait ça 😉 Mais j’y crois encore !

Binaire : Et aujourd’hui, toujours dans le cadre du pair-à-pair, tes recherches portent sur l’apprentissage collaboratif.

AMK : Oui, l’apprentissage collaboratif, c’est mon sujet du moment ! Et oui, on reste proche du pair-à-pair, mon dada !

Dans la phase d’entraînement de l’apprentissage automatique classique, les données sont rapatriées dans des data centers où se réalise l’entrainement. Mais on ne veut pas toujours partager ses données ; on peut ne pas avoir confiance dans les autres machines pour maintenir la confidentialité des données.

Donc, imaginons des tas de machines (les nœuds du système) qui ont chacune beaucoup de données, qu’elles ne veulent pas partager, et qui, pour autant, aimeraient bénéficier de l’apprentissage automatique que collectivement ces données pourraient leur apporter. L’idée est d’arriver à entraîner des modèles d’apprentissage automatique sur ces données sans même les déplacer. Bien sûr, il faut échanger des informations pour y arriver, et, en cela, l’apprentissage est collaboratif.

Une idée pourrait être d’entrainer sur chaque machine un modèle d’apprentissage local, récupérer tous ces modèles sur un serveur central, les agréger, renvoyer le modèle résultat aux différentes machines pour poursuivre l’entrainement, cela s’appelle l’apprentissage fédéré. A la fin, on a bien un modèle qui a été finalement entraîné sur toutes les données, sans que les données n’aient bougé. Mais on a toujours des contraintes de vulnérabilité liées à la centralisation (passage à l’échelle, point de défaillance unique, respect de la vie privée).

Alors, la solution est d’y parvenir de manière complètement décentralisée, en pair-à-pair. On échange entre voisins des modèles locaux (c’est à dire entrainés sur des données locales), et on utilise des algorithmes épidémiques pour propager ces modèles. On arrive ainsi à réaliser l’entrainement sur l’ensemble des données. Ça prend du temps. Pour accélérer la convergence de l’entrainement, on fait évoluer le graphe dynamiquement.

Cependant, que ce soit dans le cas centralisé ou, dans une moindre mesure, décentralisé, l’échange des modèles pose quand même des problèmes de confidentialité. En effet, même si les données ne sont pas partagées, il se trouve qu’il est possible d’extraire beaucoup d’informations des paramètres d’un modèle et donc du client qui l’a envoyé. Il y a donc encore pas mal de recherches à faire pour garantir que ces systèmes soient vraiment respectueux de la vie privée, et pour se garantir d’attaques qui chercheraient à violer la confidentialité des données : c’est typiquement ce sur quoi je travaille avec mon équipe à l’EPFL.

Binaire : L’entraînement dans un cas distribué, est-ce que cela ne coûte pas plus cher que dans un cas centralisé ? Avec tous ces messages qui s’échangent ?

AMK : Bien sûr. Il reste beaucoup de travail à faire pour réduire ces coûts. En revanche, avec ces solutions, il est possible de faire des calculs sur des ordinateurs en local qui sont souvent sous-utilisés, plutôt que de construire toujours plus de data centers.

Binaire : Cela rappelle un peu les problèmes de coût énergétique du Bitcoin, pour revenir à une autre application du pair-à-pair. Peux-tu nous en parler ?

AMK : Un peu mais nous sommes loin des délires de consommation énergétique du Bitcoin.

En fait, au début, quand j’ai découvert l’algorithme original de la blockchain et du Bitcoin, je n’y ai pas du tout cru, parce que d’un point de vue algorithmique c’est un cauchemar ! En systèmes distribués, on passe notre vie à essayer de faire des algorithmes qui soient les plus efficaces possibles, qui consomment le moins de bande passante, qui soient les plus rapides possibles, etc… et là c’est tout le contraire ! Un truc de malade ! Bon, je regrette de ne pas y avoir cru et de ne pas avoir acheté quelques bitcoins à l’époque…

Mais c’est aussi ça que j’aime bien dans la recherche scientifique : on se trompe, on est surpris, on apprend. Et on découvre des algorithmes qui nous bluffent, comme ceux des IA génératives aujourd’hui.

Binaire : Tu as beaucoup milité, écrit, parlé autour de la place des femmes dans le numérique. On t’a déjà posé la question : pourquoi est-ce si difficile pour les femmes en informatique ? Peut-être pas pour toi, mais pour les femmes en général ? Pourrais-tu revenir sur cette question essentielle ?

AMK : On peut trouver un faisceau de causes. Au-delà de l’informatique, toutes les sciences “dures” sont confrontées à ce problème. Dès le CP, les écarts se creusent entre les filles et les garçons, pour de mauvaises raisons qui sont des stéréotypes bien ancrés dans la société, qui associent les femmes aux métiers de soins et puis les hommes à conduire des camions et à faire des maths… Pour l’informatique, la réforme du lycée a été catastrophique. La discipline n’avait déjà pas vraiment le vent en poupe, mais maintenant, quand il faut abandonner une option en terminale, on délaisse souvent l’informatique. Et ça se dégrade encore dans le supérieur. La proportion de femmes est très faible dans les écoles d’ingénieurs, et ça ne s’améliore pas beaucoup. Pour prendre l’exemple d’Inria, la proportion de candidates entre le début du recrutement et l’admission reste à peu près constante, mais comme elle est faible à l’entrée on ne peut pas faire de miracles…

Pourtant, une chose a changé : la parité dans le domaine est devenue un vrai sujet, un objectif pour beaucoup, même si ça n’a pas encore tellement amélioré les statistiques pour autant. Ça prend beaucoup de temps. Un sujet clivant est celui de la discrimination positive, celui des quotas. Beaucoup de femmes sont contre dans les milieux académiques parce qu’elles trouvent ça dévalorisant, ce que je peux comprendre. Je suis moi-même partagée, mais parfois je me dis que c’est peut-être une bonne solution pour accélérer les choses…

Binaire : Bon, de temps en temps, cela change sans quota. Même à l’Académie des sciences !

AMK : C’est vrai, magnifique ! Je suis ravie de faire partie de cette promo. Une promo sans quota plus de 50 % de femmes parmi les nouveaux membres Académie des sciences en général, et 50 % en informatique. On a quand même entendu pendant des années qu’on ne pouvait pas faire mieux que 15-20% ! Pourvu que ça dure !

Serge Abiteboul, Inria, et Chloé Mercier, Université de Bordeaux