Walid Nouh : Bonjour et bienvenue sur Projets libres !. Je m’appelle Walid Nouh, je suis tombé dans la marmite du logiciel libre il y a plus de 20 ans. Libriste confirmé ou néophyte, venez découvrir avec moi les portraits des femmes et des hommes qui font le logiciel libre : communautés, modèles économiques, contributions, on vous dit tout.
Aujourd’hui, pour ce deuxième épisode, nous allons parler d’un logiciel que j’affectionne tout particulièrement, c’est un gestionnaire de mots de passe libre et open source qui s’appelle Passbolt [1], un logiciel que j’utilise depuis 2018. D’ailleurs, j’ai découvert qu’il était beaucoup plus ancien que je pensais en lisant les pages sur le site ; c’est un logiciel que je recommande à tout le monde à chaque fois que je passe dans une société. J’ai pensé à inviter Rémy Bertot qui est le CTO [Chief Technical Office] et un des cofondateurs de Passbolt après avoir vu une conférence au FOSDEM cette année, le gros salon de développeurs de logiciels libres qui se tient tous les ans à Bruxelles. Il a gentiment accepté.
Aujourd’hui nous allons parler avec lui de Passbolt, de la communauté, du modèle économique et de ce que veut dire développer un logiciel libre dans le domaine de la sécurité.
Bonjour Rémy, bienvenue sur Projets libres !. J’espère que tu vas bien.
Rémy Bertot : Oui. Je vais très bien. Merci pour l’invitation, Walid, ça me fait très plaisir.
Walid Nouh : Pour commencer, la première chose que je vais te demander : est-ce que tu peux te présenter pour nous expliquer un petit peu ton parcours et à quand remonte ton intérêt pour le logiciel libre ?
Rémy Bertot : Comme tu l’as dit je m’appelle Rémy Bertot. Je suis français d’origine et maintenant j’habite au Luxembourg depuis quelques années.
Je suis ingénieur logiciel de formation. J’ai commencé mes études à Bordeaux et je les ai finies en Irlande. Mon parcours est un parcours assez classique de formation de développeur, ingénierie logicielle avec une spécialisation interaction humain/machine, donc utilisabilité, tests d’utilisabilité, ce genre de choses. Ce qui m’a toujours intéressé c’est la partie interface graphique, mais aussi comment rendre les logiciels plus accessibles en général. C’est pour cela que j’ai choisi ça.
Comme mes cofondateurs, je suis mordu de l’informatique depuis que j’ai eu la chance d’avoir un ordinateur. Mon exposition au logiciel libre vient de là, dès le départ, par curiosité, installer Linux sur le PC des parents, ce genre de choses.
Après, plus tard, on a commencé à travailler ensemble avec Kevin et Cédric. Passbolt n’est pas notre première aventure, on avait fait des choses avant, notamment une agence de développement web juste après nos études, avec Kevin. Nous avions 2 000 euros en poche et nous sommes partis monter une agence web en Inde basée sur les logiciels libres justement. On a pas mal développé avec les logiciels libres. On n’a pas développé des logiciels libres, on a pas mal développé sur des logiciels libres ou avec des librairies. Par exemple, on a bossé sur des logiciels qui faisaient du rendu vidéo, on a été exposés à FFmpeg [2]. On a fait des sites web un peu dynamiques ; à l’époque c’était juste le début de jQuery [3], on a fait des petits plugins jQuery, on a commencé à faire des petites contributions sur des formats PHP qui étaient juste émergents à l’époque, typiquement traduire la doc, ce genre de choses.
Ça s’est fait assez naturellement en fait. Avec Cédric et Kevin nous étions toujours inspirés par les valeurs du logiciel libre et ce que ça représente, le fait que le savoir doit être libre et disponible à tous.
Walid Nouh : Au départ vous étiez, on va dire, utilisateurs de logiciels libres, vous n’étiez pas encore passés de l’autre côté de la barrière, mais dès le départ vous aviez la fibre entrepreneuriale.
Rémy Bertot : Oui. Faire quelque chose de nos mains était vraiment quelque chose qui nous attirait et, au final, après avoir fait du service, nous nous sommes dit « OK, pourquoi ne pas faire du produit ». On n’a pas commencé par Passbolt, on avait fait d’autres logiciels avant, un logiciel de e-learning qui s’appelait Click On French ; c’était une plateforme pour apprendre le français qui est une grande demande en Inde. On avait travaillé sur d’autres logiciels libres qui n’ont pas été publiés, qui étaient sous licence libre mais qui n’ont jamais été distribués. Après, plus tard, on a travaillé également sur des logiciels pas libres, on a travaillé par exemple avec Adobe ou le Parlement européen sur des logiciels propriétaires.
De fil en aiguille on s’est dit « OK, on va faire d’autres logiciels pour nous, pour l’agence web, justement pour régler des problèmes qu’on avait dans l’agence web qui étaient la gestion des mots de passe ». À l’époque il n’y avait pas grand-chose sur le marché, il y avait KeePass [4] qui est toujours utilisé par des millions de personnes, à juste titre, c’est un projet qui est bien fait. La communauté de KeePass est assez fragmentée, il n’y a pas un seul acteur qui contrôle KeePass, ce sont vraiment plusieurs communautés, il y a plusieurs versions. En fait il n’y avait pas la version web, il n’y avait pas la version où on peut partager, avoir de l’audit pour savoir ce que font les gens avec les mots de passe.
Typiquement, dans une agence web, vous allez avoir besoin de stocker des clefs SSH [Secure Shell], des passwords FTP [File Transfer Protocol ], ce genre de chose se faisait encore à l’époque, des logins sur des sites WordPress, peu importe. On avait besoin d’une solution qui soit partagée, qui soit libre. On a commencé à développer, en fait Kevin a fait une première version de ce logiciel dans les années 2012.
Walid Nouh : Sur le site il y a écrit « 2011, premier proto », j’étais vachement étonné, je pensais que c’était plus récent en fait.
Rémy Bertot : Cette première version du logiciel était utilisée en interne, n’était pas release en open source, elle était juste disponible à nos clients.
À l’époque je suis parti pour travailler ailleurs. J’en avais un peu marre de faire du service de sites, je suis parti travailler à Amsterdam pour Greenpeace International. J’ai travaillé sur un projet qui est devenu maintenant OpenSocial, je ne sais pas si vous connaissez, c’est un réseau social qui était en Drupal, ce n’est pas la technologie la plus évidente pour construire un réseau social ; c’est un logiciel qui est parti de chez Greenpeace et qui est devenu OpenSocial. En parallèle, Kevin développait Passbolt. On travaillait tous les deux, chacun de son côté, sur des logiciels libres.
Kevin m’a dit « j’ai envie de sortir Passbolt en logiciel libre ». J’ai fait la plus grosse erreur qui a été de dire à Kevin « OK je veux bien, mais on le refait depuis le début » plutôt que de fixer le logiciel existant qui avait des gros problèmes en termes de sécurité. J’ai dit « OK, on refait depuis le départ ». C’est pour cela, qu’en fait, il y a vraiment eu une version de 2012 à 2016 qui n’a pas été publique. On a lancé la v1, qui était déjà une v2, en public en 2016. C’était à peu près en même temps que Bitwarden [5] qui est un autre logiciel open source de gestionnaire de mots de passe qui est développé aux États-Unis.
Walid Nouh : Les premières traces que j’ai trouvées sur GitHub c’est 2016. La question que je me suis posée : qu’est-ce qui vous a poussé dans le choix de le faire en PHP et qu’est-ce qui vous a poussé dans le choix de le faire avec une licence AGPL [6] ?
Rémy Bertot : Dans un premier temps, le PHP [7], c’était parce qu’on voulait que le logiciel soit self-hosted. Notre expérience dans les agences web, même dans les ONG, c’était que n’importe quel administrateur ou département IT a déjà vu passer du PHP, donc les stacks LAMP [8] typiques sont assez résilientes, les gens ont vraiment l’habitude d’installer ce type de logiciel et de le maintenir. Donc l’idée c’était vraiment de partir sur une stack simple et résiliente, qu’il n’y ait pas beaucoup de choses qui changent, dans l’optique de réduire le support derrière. On a donc choisi une technologie la plus simple possible. La métaphore que j’utilise souvent : si vous jetez Passbolt contre un mur, ça va coller, il est pratiquement indestructible. On a des instances qui tournent depuis des années, elles n’ont pas de problème. C’est moins facile d’obtenir ce genre de résultat si vous prenez des technologies qui sont un petit plus cuting age qui sont, entre guillemets, « un peu plus innovantes et moins rodées ». C’est pour cela que nous sommes partis sur PHP à la base.
Pour la licence AGPL, l’idée c’est qu’on ne voulait pas faire ce que j’appelle du begware. On ne voulait pas être là, fonctionner sur les donations, etc., on l’a déjà vu avec des projets à nous. Typiquement, par exemple, on a aussi contribué sur Mailvelope [9], un logiciel qui permet le chiffrage de données, avec Kevin et Cédric nous avons également beaucoup bossé sur ce logiciel. Il a un modèle un peu différent, il fonctionne sur la base des donations. Ce n’est pas un modèle économique qui m’intéressait parce que ce n’est pas prédictible. La plupart des donations viennent, en fait, de fondations, il ne faut pas se leurrer, la plupart des individus ne donnent pas à l’open source, ce sont soit des grosses entreprises, soit des grosses fondations ; les grosses entreprises c’est assez rare, il faut vraiment avoir une adoption de dingue pour pouvoir avoir un modèle comme ça et généralement vous êtes dépendant de ces grosses entreprises, de une ou, si vous êtes chanceux, deux grosses entreprises qui, du jour au lendemain, peuvent vous laisser tomber. Pour les fondations c’est pareil. On l’a vu avec Mailvelope qui était financé par l’Open Technology Fund. Le jour où Trump est arrivé au pouvoir c’est le genre de truc qu’il a coupé direct et, pendant quatre ans, Mailvelope n’a plus eu de donations de ce côté, il a fallu chercher de nouveaux donateurs. Pour moi ce n’était pas vraiment un modèle économique qui m’intéressait, je voulais quelque chose qui soit sustainable dès le départ, que les gens comprennent qu’il y a de la valeur, donc il faut financer le truc pour que ça tienne la route.
La licence AGPL permet de faire ça, c’est-à-dire que le logiciel est sous licence libre. On a un service qui est disponible, les gens peuvent modifier, etc. Si quelqu’un veut rentrer en compétition avec nous, il faut qu’il rentre en compétition avec les mêmes règles du jeu. Si, par exemple, j’avais mis le logiciel en licence MIT, quelqu’un serait capable de reprendre le code de Passbolt, faire une version cloud et ne rien devoir à personne. Alors qu’en AGPL, cette personne va être obligée de redistribuer le code source à ses clients. Donc là on est à peu près sur le même pied d’égalité.
Au niveau de la licence on a une petite subtilité : on n’autorise pas l’utilisation de la trade-mark Passbolt. En gros, vous avez accès au logiciel, vous pouvez le changer, mais vous n’avez pas le droit d’utiliser le nom Passbolt. Si vous voulez le changer et le redistribuer, il faudra changer et le distribuer sous un autre nom, vous ne pouvez pas vous servir de la visibilité de Passbolt pour construire votre écosystème.
Je trouve que c’est juste dans le sens où vous pouvez venir concurrencer Passbolt, faire un fork avec un autre nom et créer votre propre modèle économique en créant une meilleure version de Passbolt et ce ne sera pas exclusif, on pourra bénéficier de cette relation tous les deux. On l’a déjà vu dans le passé, typiquement des relations entre Red Hat [10] et la communauté CentOS [11] ou d’autres distributions Linux, entre Ubuntu et d’autres versions d’Ubuntu. C’est un modèle qui fonctionne assez bien, mais il faut que tout le monde ait les mêmes règles du jeu. Typiquement, nous ne voulions pas que AWS ou Google prennent l’API et fassent leur version. L’AGPL permet aussi de se protéger un peu de ce côté-là.
Walid Nouh : Là nous sommes en 2016. En gros, vous publiez la première version, les premières sources sur GitHub. Ce n’est pas parce que tu publies tes sources sur GitHub que tu as une communauté, que ton logiciel est connu. Avant, vous travaillez sur une agence web et vous publiez votre première version, là je suppose que c’est quand même un certain défi. Je ne sais pas quel était votre passé dans la sécurité pour développer un logiciel comme Passbolt qui, en plus de ça, a certaines particularités, fonctionnalités assez avancées au niveau sécurité. Comment avez-fait ? Vous vous êtes entourés de personnes très compétentes en sécu, vous l’étiez déjà vous-mêmes dans l’équipe ? Comment ça s’est passé en fait ?
Rémy Bertot : Pour donner un peu de background, quand j’avais 16 ans, je décompilais des sharewares pour savoir comment les clefs de licences fonctionnaient, Kevin ce sont des expérimentations avec le hacking de téléphones. Nous ne sommes pas sortis non plus de nulle part. Après, nous ne sommes pas nés experts sécurité. Nous nous sommes quand même pas mal basés sur un travail qui a déjà été fait par pas mal de personnes. Comme je le mentionnais auparavant, Mailvelope est un projet qui existait avant Passbolt, donc on a repris plein de concepts. Thomas Oberndörfer, un des fondateurs de ce projet, a réanimé OpenPGP.js qui est l’implémentation de OpenPGP [12] en JavaScript qui est maintenant maintenu par l’équipe de Proton Mail [13], mais qui, à l’époque, était maintenue par lui. Nous nous sommes forcément basés sur son travail et sur les audits de sécurité qu’il a eus pour ne pas refaire les mêmes erreurs que lui. On regardait également attentivement les autres audits des passwords managers, quelles étaient les failles que les autres passwords managers avaient et sur quoi ils s’étaient faits pawner.
Maintenant, nous avons la chance d’être entourés et d’être constamment, entre guillemets, « sous surveillance ». On a des audits pratiquement tous les quarters, tout le temps, et on trouve toujours des choses, ce n’est jamais fini. C’est plus un effort de chercher, de connaissances pures. Il y a une partie de recherche et de connaissances initiales, mais après il y a une partie de pratique et de rigueur en fait.
Walid Nouh : Je reviens, parce que c’est un sujet que je trouve assez intéressant : comment faites-vous pour vous faire connaître et faire votre première communauté ? Est-ce que c’est justement parce que vous aviez déjà l’habitude de travailler sur Mailvelope et d’autres projets que, finalement, ça a commencé comme ça ? Comment avez-vous réussi à vous faire connaître comparativement à d’autres projets qui auraient pu être déjà là avant ou qui sont arrivés en même temps ?
Rémy Bertot : La stratégie de lancement a été assez simple. C’est quoi ? On va aller parler de Passbolt sur les forums open source qu’on connaît. Nous sommes allés sur linuxFr [14], nous sommes allés sur Hacker News [15], on a parlé de Passbolt et là, de fil en aiguille, le truc a pris tout seul, par le bouche-à-oreille. On n’a pas fait d’effort particulier, du moins au départ. Nous étions assez surpris, en fait, que la mayonnaise prenne toute seule. Quelque part, il y avait vraiment un besoin : ce que nous faisions correspondait aux gens, à comment eux auraient voulu l’avoir fait.
Walid Nouh : Vous avez donc réussi à bâtir une communauté. Je regardais tout à l’heure les statistiquess sur GitHub, il y a quand même pas mal de monde qui contribue. Toutes ces personnes ne travaillent pas chez Passbolt, les gens sont venus d’eux-mêmes. Comment s’est passé, comment se passe ce rapport à cette communauté de gens qui gravitent autour du projet Passbolt ?
Rémy Bertot : Sur GitHub, les statistiques du projet sont un peu biaisées parce que, en fait, à la base il n’y avait pas de composer pour CakePHP [16], en fait on a forké le repo, donc on a pris tous les contributeurs entre la v1 et la v2 de CakePHP qui sont listés comme contributeurs de Passbolt, ce que j’aime bien. De toute façon, indirectement, ils ont contribué au projet, mais ça fausse un peu les statistiques.
En gros, on n’a pas des centaines ou des milliers de contributeurs, on a une petite dizaine de gens qui contribuent à différents niveaux.
On a beaucoup de contributeurs en termes de traduction, on a une communauté assez active de traducteurs.
Après, on a une communauté qui nous reprend sur des petites coquilles ou qui veut, par exemple, des paramètres en plus, des petits changements, des petits ajustements de settings.
On a des contributeurs qui proposent des fonctionnalités un petit peu plus grosses, mais, généralement, ils ne les proposent pas sur le cœur du produit qui est l’API ou la browser extension ou même les applications mobiles maintenant, ils les proposent typiquement sur des SDK [Software Development Kit ] ou sur des librairies, sur des projets qu’ils ont créés pour résoudre leurs problèmes avec Passbolt. Typiquement, on a Samuel Lorch qui a créé le Passbolt CLI [Command Line Interface], qui est écrit en GO. Lui avait vraiment ce besoin de faire de la rotation de mots de passe dans Passbolt dans son entreprise, il ne voulait pas le faire avec une interface graphique. Il est parti, il a développé ce SDK et ensuite, au-dessus, ce CLI.
On a donc des contributions dans ce sens-là. On a, par exemple, un ancien employé de Passbolt, Christophe Vassort, qui a travaillé pas mal sur tout ce qui est collections Ansible [17], par exemple créer des packages pour un Raspberry PI, ce genre de choses.
En fait, les contributions sont généralement autour du produit, pour intégrer le produit, se connecter au produit, elles ne sont pas sur le cœur du produit qui est un peu, entre guillemets, « difficile d’accès » parce qu’il y a pas mal de sections : vous avez l’API, vous avez la StyleGuide et après vous avez la browser extension, il faut donc vraiment combiner ces trois éléments ensemble pour faire marcher Passbolt. L’architecture de Passbolt est un peu particulière vu que l’ensemble de l’application est pratiquement servi par la browser extension. Quand vous arrivez sur un site web qui fait tourner une instance Passbolt, l’application, la browser extension, va injecter un iframe et toute l’application va être dans cet iframe. En fait, quand vous développez le serveur, vous développez sur l’API qui va être utilisée par cette application ou par les applications mobiles. Si vous vous voulez développer une nouvelle fonctionnalité, il faut vraiment comprendre les clients et le serveur ce qui n’est pas forcément évident pour les développeurs. C’est un peu compliqué de faire du chiffrement end to end, il n’y a pas beaucoup de contributeurs sur des fonctionnalités complètement transversales.
Après, nous cherchons des spécialistes. Typiquement on bosse avec CakeDC [18], qui est l’un des développeurs du framework qu’on utilise pour l’API qui travaille, par exemple, sur la partie LDAP [Lightweight Directory Access Protocol] ou ce genre de chose. On a, par exemple, des clients qui demandent si on pourrait ajouter l’authentification Kerberos [19] pour le plugin LDAP. Là on va travailler avec des gens qui connaissent LDAP, qui connaissent bien OpenPHP.
Ce sont des contributeurs qui viennent de la communauté open source, qui sont payés pour travailler, ce qui est, je pense, l’idéal.
Walid Nouh : En tant qu’utilisateur de Passbolt, qu’est-ce que j’ai à ma disposition pour faire par exemple des features requests, des demandes de fonctionnalités, ou pour interagir avec vous ? Comment ça marche ? Comment avez-vous structuré ce dialogue entre les personnes qui voudraient faire des retours et l’équipe de développement ?
Rémy Bertot : On a un forum qu’on appelle le Community forum [20], qui est sur community.passbolt.com, qui est basé sur Discourse qui est également un logiciel open source.
On a un site d’aide qui est également disponible sur GitHub. Notre site d’aide, avec toutes les ressources, est également disponible en Creative Commons et les gens peuvent changer tout ce qu’ils veulent. Ils peuvent soit contribuer au niveau de la documentation sur le site web, soit ils peuvent proposer des traductions avec la plateforme qu’on utilise, Crowdin, qui n’est pas open source, mais qui est gratuite pour les projets open source, pour parler des fonctionnalités ou de leurs problèmes sur le forum.
Notre process de développement commence par répondre à quatre questions : quel est le problème que vous essayez de résoudre ?, Pourquoi c’est important ?, Qui est affecté ?, et après, seulement, on va commencer à parler de solutions. Sinon, de mon expérience, parler d’abord de la solution avant de parler du problème, c’est vous avez un marteau et tout ressemble à un clou. Le but du jeu c’est vraiment de déconstruire le problème, qui est impacté et pourquoi c’est important. Une fois qu’on a ça, on essaie de construire la solution vraiment avec la communauté. Par exemple on va demander : que pensez-vous si on prend cette approche pour résoudre ce problème ? Typiquement, avec l’équipe en interne, on va développer des wireframes, des diagrammes de quelle utilisation, des diagrammes de séquences. On va revenir vers la communauté et on va demander à la communauté de commenter.
Par exemple, si vous êtes abonné à notre newsletter, on va vous envoyer un e-mail quand il y a des grosses specs qui partent et, si on hésite entre deux approches possibles, on va demander à la communauté : que pensez-vous, il faut faire plutôt l’une, plutôt l’autre ?, et généralement les gens nous disent « toutes les deux ». Généralement on tranche en fonction de qui a répondu quoi et qui est plutôt notre audience et qui ne l’est pas trop. Après, en fait, on fait une release en alpha : la première version est derrière en feature flag, c’est-à-dire que vous pouvez la libérer, mais il faut vraiment mettre les mains dans le cambouis pour mettre le flag à on. Là vous avez l’opportunité de donner du feed-back : est-ce que la fonctionnalité vous plaît ?, Est-ce que vous trouvez des bugs, etc.
Après, on passe en mode qu’on appelle bêta, c’est affiché à l’écran que c’est en bêta, et on fait une revue de code, normalement avec nos partenaires de Cure53 [21] qui font une revue de sécurité. Ils prennent tout. Ils prennent les specs, ils prennent le produit et puis les questions/réponses. Nous finançons cet audit à chaque fois qu’il y a une fonctionnalité majeure. Forcément tout cela coûte de l’argent, donc on a besoin d’avoir un modèle économique viable.
Walid Nouh : On va y revenir tout à l’heure, c’est un des sujets auquel j’ai été confronté aussi, les audits de sécu, et ce n’est pas évident. Ça me rappelle des choses quand moi-même je bossais sur un projet open source. On demandait aux gens, nous aussi, de tester les versions alpha et les versions bêta et en fait, en gros, on n’avait pas trop de tests. On arrivait à la prod et c’est là que les gens commençaient à tester. On se creusait toujours la tête pour savoir comment faire en sorte que les gens testent nos versions pour nous aider à débugger le truc. On avait bien sûr des gens qui nous aidaient, mais jamais assez.
Rémy Bertot : C’est que personne ne veut être le cochon d’Inde. On a l’avantage d’avoir déjà des clients. On a des clients ou des gens qui sont en passe de devenir clients, qui attendent une fonctionnalité pour le devenir. Ce sont les premiers informés et on les accompagne vraiment. On fait l’installation avec eux, on fait une démo du truc pour qu’ils testent vraiment cette fonctionnalité. On provoque donc un peu cette phase de test. On a aussi beaucoup de tests en interne, on a beaucoup de tests unitaires, on a des tests Selenium [22] de bout en bout. Donc, quand on demande aux gens de tester, généralement on sait que ça marche, mais on trouve toujours des trucs, forcément. On ne s’attend pas à ce qu’il y ait une certaine configuration, on a toujours quelques surprises.
Walid Nouh : Si, maintenant, on passe un peu à Passbolt en tant qu’entreprise et en tant que modèle économique, vous êtes basés au Luxembourg et vous êtes combien de personnes ?
Rémy Bertot : Nous sommes à peu près 30 personnes dont 14 au Luxembourg. On n’a pas tout le staff au Luxembourg. On a pas mal de gens, la moitié, en remote. On est une boîte en remote en fait, donc on a des gens en Espagne, on a une personne aux États-Unis, en Allemagne, en Inde forcément, parce qu’à la base, avec Cédric et Kevin, nous étions en Inde, on a donc des contacts là-bas. On a également des gens qui viennent de Belgique pour travailler. Nous sommes donc assez cosmopolites de base.
Walid Nouh : Vous avez sorti la première release de Passbolt, en 2016, et là vous n’aviez pas encore monté la société Passbolt.
Rémy Bertot : En fait, on a participé à un projet d’incubation, on a participé à un concours qui s’appelle le Fit4Start [23] au Luxembourg parce que, à la base, Kevin et Cédric sont de la région Grand Est, ils étaient donc familiers avec les programmes d’accélération du Luxembourg. On a eu la chance d’être sélectionnés pour pitcher et on a eu la chance de participer au programme.
Une des obligations inclue dans ce programme c’est de construire son entreprise au Luxembourg en échange de quoi vous avez accès des subventions, vous pouvez vous installer ici. On a accès à l’écosystème ici. On avait accès au Technoport qui est un bâtiment qui sert d’incubateur, on avait des bureaux, pour commencer, avec tout ce qu’il faut, la sécurité, Internet, tout cela gratuitement. C’était vraiment un énorme avantage pour nous et c’est ce qui nous a permis de passer le cap de « OK on a un logiciel open source, mais on n’a pas de business » à « OK, maintenant on va développer un business basé sur ce logiciel », justement pour pouvoir le maintenir.
Walid Nouh : Justement, parce que c’est là que ça devient intéressant : quand vous avez monté la boîte, quelle était votre vision du business que vous vouliez faire ? Est-ce que c’était très différent de ce qu’il est maintenant ou pas ?
Rémy Bertot : Non. Je ne dirais pas que c’était différent. En fait, on a essayé d’avoir le même modèle économique que Mailvelope, c’est-à-dire de fonctionner sur la base des donations et ça n’a pas du tout marché. C’est pour cela qu’on s’est dit « il faut vraiment qu’on ait un modèle économique qui tienne la route, avoir une entreprise et essayer de la faire grossir ». C’est passé par construire une version payante qui s’appelle Passbolt Pro qui est sortie en 2018. Pendant cette période, entre fin 2016 et 2018, il y a eu du développement pour ajouter des fonctionnalités et, en 2020, le lancement de Passbolt Cloud qui est également une autre partie de l’offre payante. Passbolt Pro inclut du support et également des fonctionnalités en plus. Après, ces fonctionnalités en plus sont quand même sous licence AGPL.
Walid Nouh : C’est là où je voulais en venir, à cette question : est-ce que cette version pro est elle-même en AGPL ?
Rémy Bertot : Oui. En fait, il faut prendre une souscription, le logiciel vous demande une clef de souscription, mais vous avez le droit de modifier le logiciel pour qu’il ne vous demande pas la clef de souscription. Dans ce cas-là, si vous faites ça, on ne vous propose pas de support.
Typiquement, quand vous êtes une entreprise, vous n’avez pas envie de faire ça ; si vous êtes un individu lambda vous pouvez le faire. Si vous êtes une grosse entreprise, ça devient un peu compliqué de maintenir votre propre version, considérant le coût pas significatif de Passbolt par rapport à l’effort d’avoir une ressource qui bosse pour compiler les applications, les packages, etc.
Ce qu’on propose c’est justement la compilation de tout cela, c’est-à-dire l’application finie et pas juste les sources. Ça fonctionne assez bien. On s’était dit « OK, les gens vont payer pour du support », mais personne ne veut payer pour du support. Les gens veulent que le logiciel fonctionne de base, même si nous, nous savons qu’ils vont avoir besoin de support. C’est un peu la partie un peu bizarre de l’équation : on sait que si on propose un module LDAP, il va y avoir beaucoup de support sur du LDAP.
C’est pour cela qu’on préfère aller sur la version payante parce qu’on sait que les gens vont avoir besoin de support et on veut que les gens aient une bonne expérience, on ne veut pas qu’ils viennent tous sur le forum dire « mon LDAP ne marche pas ». On veut que les gens aient une bonne expérience du logiciel. C’est pour cela que nous avons développé certaines fonctionnalités dans cette version payante, ce sont justement les fonctionnalités qui créent le plus de support.
Walid Nouh : C’était une des questions que je me posais parce que c’est quelque chose qui est très spécifique d’un projet à un autre : qu’est-ce que tu inclus dans la version on va dire Community, qu’est-ce que tu n’inclus pas ? Sur quoi te bases-tu ? Il y en a qui vont dire que tout ce dont a besoin au quotidien on le met dans la version Community et toutes les fonctionnalités avancées on les met dans la version pro. Ce que je comprends c’est qu’en fait, pour vous, on va mettre dans la version pro tout ce qui va générer du support.
Rémy Bertot : C’est schématisé, mais ce n’est pas uniquement ça. Il y a aussi une partie où on sait, en gros, que les plus grosses entreprises vont avoir besoin de ces fonctionnalités ; on sait que ce sont des gens qui ont des budgets pour déployer ce type de logiciel. Il y a donc aussi un ciblage par rapport à l’audience.
Typiquement, vous pouvez utiliser la Community Edition avec 10/30 personnes sans aucun problème. Si vous atteignez 500 personnes vous commencez à avoir certains problèmes que vous n’avez pas quand vous avez 30 personnes, et c’est justement là où nous mettons le curseur. Si tu as 500 utilisateurs qui utilisent Passbolt, il faut passer à la caisse. Sinon tu prends le coût de forker l’application, tu prends le coût de construire les packages toi-même, peu importe.
Walid Nouh : Un autre sujet qui n’est pas évident, sur lequel j’ai beaucoup plus réfléchi à l’époque où je bossais sur un logiciel libre, pour lequel on avait regardé comment les autres logiciels faisaient : à quel moment tu backportes des fonctionnalités. Je pense en particulier il n’y a pas très longtemps vous avez backporté la notion de Folders carrément dans la Community, il y a aussi eu les clients mobiles.
Rémy Bertot : Les clients mobiles étaient toujours disponibles pour tout le monde.
Walid Nouh : Dès le départ ? D’accord.
Rémy Bertot : Folders [24] a été descendu au mois de janvier ou février, et on avait aussi le 2FA qui était aussi sur la Community Edition. La raison pour laquelle les gens nous en ont un peu voulu de mettre tout le 2FA sur la version payante c’est qu’à la base Passbolt utilisait un système de clef publique/clef privée, donc il n’y a pas besoin de tout refaire. D’un point de vue sécurité, ce que nous proposons en termes de login c’est un login par Challenge avec une signature, une preuve que vous avez la clef privée, c’est donc beaucoup plus fort qu’un password et un MFA [Multifactor Authentication]. Typiquement, c’est le même principe que les passkeys ou des trucs qui vont remplacer les mots de passe. On s’était dit que le MFA c’est vraiment pour les gens qui sont dans une entreprise où ils ont besoin de cocher la case MFA, donc pas les techniciens du Libre qui savent ce qu’ils font. Ça a été mal perçu, ça a été perçu comme mesquin, c’est pour cela qu’on l’a redescendu. C’était plus facile de dire « le MFA est disponible pour tout le monde » que de dire « d’un point de sécurité ça ne change pas grand-chose parce que l’authentification Passbolt est déjà super forte ».
Au départ on est aussi obligé de répondre à la communauté par rapport à l’image qu’on a, pas nécessairement par rapport à notre rationnel, mais aussi de répondre aux humeurs des gens.
Walid Nouh : Je sais qu’à l’époque où avait beaucoup regardé des logiciels dans lesquels soit, par exemple, c’était une entreprise qui finançait une fonctionnalité, cette fonctionnalité passait en fait un certain temps dans la version pro et ensuite elle redescendait dans la version Community ; d’autres disaient « on rajoute une fonctionnalité, on estime le temps qu’il nous faut pour la rentabiliser, une fois que c’est rentabilisé on la redescend dans la version Community ». En fait, il peut y avoir plein de modèles différents qui s’expliquent par la structure du projet, par les gens qui le gèrent, par le modèle économique et tout. En fait, c’est un truc qui n’est jamais vraiment abordé et que je trouve assez intéressant justement de comprendre parce que ça touche vraiment à la fois au modèle économique : qu’est-ce qu’il nous faut pour gagner de l’argent et, à la fois, comment on donne un logiciel libre qui soit assez utilisable pour que les gens l’utilisent et que, potentiellement demain, ils aient besoin d’avoir la version pro ?
Rémy Bertot : Nous n’avons pas une équation finie. Comme tu le dis, ça vient de plusieurs facteurs. Il y a aussi, par exemple, la compétition qui est un facteur que tu n’as pas mentionné. Typiquement, si nous voulons faire en sorte que la version communauté soit plus attractive que celle de nos compétiteurs, il faut qu’on donne plus de trucs gratuits. C’est quelque chose qui a très bien marché avec Bitwarden qui a donné beaucoup de choses gratuites dès le départ et qui a décollé plus vite que nous justement, parce qu’il faisait beaucoup plus de gratuit. Son focus c’était vraiment, dans un premier temps, les utilisateurs type individuels, il avait bien compris que s’il y a de l’adoption au niveau d’une personne, potentiellement, après, il y a de l’adoption en entreprise. Il a vraiment un focus américain, c’est très orienté cloud. Quand ils consomment des logiciels, les Américains les veulent en mode SaaS [Software as a Service. Sa version open source, self-hosted, c’est vraiment un appel du pied pour que les gens aillent à l’intérieur de l’entreprise pour, après, que l’entreprise achète la version pro.
Notre modèle est un peu différent. On veut vraiment que les gens fassent du self-hosted. On ne peut pas avoir la même stratégie.
Walid Nouh : C’est intéressant parce que si je prends une bonne partie des logiciels qui ont été créés récemment, on va dire à l’ère du cloud, pas les logiciels un peu legacy, une partie de leur modèle c’est d’attirer les gens vers la version cloud qui sont des revenus récurrents, ce qui permet de payer l’équipe de développement et tout ça et, ensuite, de pouvoir financer la version Community.
Là en gros, si je comprends bien ce que tu dis, le but pour vous c’est d’arriver à faire passer plutôt les gens sur la version pro, self-hosted, plutôt que sur la version cloud, ou peut-être un mix des deux.
Rémy Bertot : Pour moi, le but c’est que les gens qui ont des petites équipes – une petite ONG ou un petit projet – puissent utiliser la version Community et qu’ils n’aient rien à payer. C’est vraiment le but du jeu. Après, que des entreprises un petit peu plus matures, institutionnelles ou des gouvernements passent justement par la version payante.
Ce n’est pas intéressant, pour moi, de faire du support pour une PME où il y a un mec qui gère de l’IT, ça ne scale pas, je vais avoir besoin de trop de ressources en termes de support. Par contre, quand j’ai une grande entreprise française qui déploie Passbolt sur tout son parc, avec une équipe IT compétente qui a choisi Passbolt parce que ça répondait à ses critères de sécurité et qui a complètement la maîtrise du hosting, là ça devient intéressant.
Il y a aussi une sélection du type de client qu’on veut. Ce n’est pas « on essaye tout et on prend ce qui ramène de l’argent ». On essaye quand même d’être efficace parce qu’il y a des choses qui ne sont pas rentables, surtout dans le self-hosted.
Walid Nouh : Ça m’amène à la question suivante, on va finir par revenir sur la question des audits de sécu.
Vous avez monté la boîte, vous avez fait la preuve qu’il y avait effectivement un modèle économique. À quel moment avez-vous levé des fonds ? À quoi ces fonds vous ont-ils servi ? Je dis cela parce que quand je bossais sur un projet libre on avait des gens qui avaient des grandes entreprises, type industrielles françaises ou autre qui venaient nous voir en disant « est-ce que vous avez fait des audits de sécurité ? » et on répondait « désolés, nous n’avons pas d’argent pour faire les audits de sécu ». Vous, en fait, directement dans le business modèle, l’audit de sécurité est un truc qui est budgétisé. À quel moment avez-vous fait une levée de fonds et à quoi a-t-elle servi ?
Rémy Bertot : En fait, à la fin du Fit 4 Start, il y a une autre grant qui est débloquée de 150 000 euros si je me souviens bien, si je ne dis pas de bêtise ; 150 000 euros ça couvre le salaire de trois personnes pendant un an, plus les frais de fonctionnement de la boîte. On est partis là-dessus et ça a servi à développer cette version commercialisable. On n’a pas levé directement.
Après, une fois qu’on a lancé cette version payante, c’est là qu’on a levé. On a levé avec des acteurs institutionnels. À l’heure actuelle, le plus gros actionnaire de Passbolt s’appelle Digital Tech Fund qui est un fonds public/privé souverain luxembourgeois. Vous avez La Poste, l’Université du Luxembourg, la Banque du Luxembourg qui ont cré un fonds d’investissement géré par un venture capital qui s’appelle Venture Capital, qui est un fonds luxembourgeois. C’est le plus gros actionnaire de Passbolt. On a donc levé avec eux et des business angels du Luxembourg, de France et de Belgique. En gros, on a fait un tour de table avec tout ce monde-là et, plus tard, d’autres fonds sont également entrés de Belgique et du Luxembourg. Ce sont des anciens réseaux de business angels qui ont grossi et qui ont fait des fonds un peu plus gros.
Là, maintenant, nous sommes en pourparlers pour faire une nouvelle levée de fonds, que les gens appellent généralement série A, qui servirait justement à construire, à avoir des épaules un petit peu plus larges parce que, en face, nous avons des compétiteurs type 1Password ou même Bitwarden qui lèvent en centaines de millions d’euros. On a donc besoin, si on veut garder une place sur l’échiquier, de lever au moins avec un zéro de plus derrière pour pouvoir justement construire plus de fonctionnalités et avoir un outil commercial un petit peu plus costaud, ce genre de chose.
L’objectif c’est vraiment de garder ce caractère européen et ne pas prendre n’importe quel investissement. On veut travailler avec des gens sérieux qui comprennent l’open source qui comprennent la cybersécurité, ce qui n’est pas forcément évident. II n’y a pas foule, mais on a de bons partenaires.
Walid Nouh : Si je reviens sur les audits, vous faites beaucoup d’audits sur toutes les nouvelles fonctionnalités ce qui n’est pas forcément le cas de tous les acteurs du secteur. Est-ce que tu peux nous en dire un peu plus sur votre philosophie qui garantit la transparence et la bonne qualité du logiciel finalement ?
Rémy Bertot : Comme tu l’as dit, le budget sécurité avait déjà une place dès le départ, même quand l’entreprise était toute petite. On a eu la chance, en fait, d’avoir une grande entreprise d’automobiles en France, je ne peux pas dire le nom – vous vous faites une idée – qui a financé un audit de sécurité parce qu’elle voulait nous adopter en interne, qui a donc financé un premier audit de sécurité sans que nous ayons à verser quoi que ce soit. Ça a été notre premier audit de sécurité et après nous nous sommes tournés vers le partenaire que nous connaissions déjà avec Mailvelope, Cure53. Ils sont basés en Allemagne, ils ont fait les audits de 1Password, du protocole Ethereum, ils auditent pratiquement tout le monde, ils sont assez réputés.
Nous ne faisons pas un audit pour dire qu’on a fait un audit. On a des gens qui font des audits de deux heures, six heures ! C’est superficiel. Généralement on demande à Cure53 de se focaliser pendant une semaine sur une partie du logiciel. Typiquement, par exemple, on va faire un audit qui est focalisé sur le mobile, ils auront une semaine avec plusieurs personnes sur les deux applications mobiles. Par exemple, quand on a sorti le système de Account Recovery, le système d’escrow de clefs, pareil, ils ont passé une semaine dessus. Pareil quand on a sorti notre premier White Paper, ils avaient vraiment une semaine sur le White Paper pour dire ce qu’étaient les risques résiduels qui n’étaient pas bien décrits dans le White Paper.
C’est une des grosses différences qu’on a aussi avec les autres. Il y a une mention, en Europe, pour les programmes de passwords qui est de décrire les risque résiduels sur le White Paper. Vous avez des White Papers où tout le monde dit « ma solution est super bien ». Un White Paper ce n’est pas ça. Un White Paper c’est justement décrire ce que vous ne faites pas bien. Vous avez le droit de faire une partie sur ce que vous faites bien, forcément, vous avez écrit le système, mais il y a aussi toute une partie où « ça ce sont les risques que nous ne gérons pas, donc toi, en tant qu’utilisateur tu dois faire attention ». Typiquement, si j’ai peur que ce risque se réalise ou, si ce risque se réalise, il y a mort d’homme, donc ce n’est pas acceptable. Il faut bien lire cette liste et bien la comprendre, donc faire en sorte que cette liste soit accessible et compréhensible pas par des chercheurs en cybersécurité, mais, idéalement, par des gens avec une expérience technique, c’est quelque chose qui est vraiment dans notre philosophie. Dès le départ nous avons voulu être transparents, on n’a pas voulu mentir. C’est aussi une façon de se préserver pour dire « le truc ne sera jamais parfait, en fait il n’y a pas de sécurité absolue. Si vous voulez telle fonctionnalité, vous allez devoir abandonner telle partie de la sécurité ». C’est cette balance-là qui est importante pour nous et, de la même façon, quand on fait des erreurs, que ces erreurs soient publiques et que les gens puissent prendre en compte « OK, il y a eu telle erreur, c’est ça l’impact pour moi, il faut que je réagisse de telle façon, il faut que j’en parle à telle personne ». Il faut que ce soit transparent. En fait, c’est dans la philosophie du Libre, pour moi c’est l’extension de cette philosophie du Libre.
Walid Nouh : Tout à fait. C’est quelque chose que j’ai toujours apprécié sur la communication à chaque fois que j’ai mis en place Passbolt, etc., ce qui n’est pas forcément le cas chez certains autres qui vont plutôt mettre un peu ça sous le tapis pour que ça ne se voie pas. C’est quelque chose que j’ai toujours apprécié. On parle souvent de logiciel libre, mais on ne parle pas forcément des standards ouverts. Pour le coup, les standards ouverts en sécu c’est quelque chose qui est hyper-important.
Une question que je me pose : est-ce que vous êtes acteurs, d’une manière ou d’une autre, dans de la normalisation ou ce genre de chose ? Est-ce que vous travaillez justement sur l’évolution de protocoles ? Est-ce que vous êtes un acteur là-dedans à votre taille ou est-ce que, regroupé avec d’autres acteurs de la filière gestion de mots de passe, vous travaillez sur ces sujets ?
Rémy Bertot : Complètement. Déjà, dans un premier temps, nous ne sommes pas acteurs au niveau de OpenPGP, même si on a des affinités assez fortes avec la communauté, on a rencontré beaucoup de gens, on a travaillé sur des projets en partenariat avec GnuPG [25] par exemple quand il y avait eu un projet d’intégration pour Mailvelope, d’intégrer Mailvelope avec GnuPG pour servir de GnuPG comme back-end. On a aussi rencontré à des événements les gens qui travaillent sur Sequoia-PGP, une implémentation OpenPGP en rust.
Le standard OpenPGP est assez compliqué et il est, entre guillemets, assez « vieux ». Il y a toute une partie pour laquelle il y a des discussions assez houleuses sur ce que doit être l’évolution du standard. On se prononce en tant qu’utilisateur, mais on n’a pas la force de frappe ni l’expérience pour donner des conseils à Werner [Koch] ou à d’autres personnes. Ce qui nous intéresse plus c’est comment utiliser OpenPGP, quels sont les blocs que nous n’utilisons pas parce qu’on considère qu’ils ne sont pas safe. On travaille avec Thomas de Mailvelope pour savoir quels sont les OpenPGP good parts parce qu’il y a des parties un peu craignos dans OpenPGP et il faut justement les exclure, créer une solution de sécurité.
On suit avec attention tout ce que sont les nouvelles RFC [Requests for comments], par exemple Practical Cryptography, qui n’est pas officiellement un standard de OpenPGP, mais que tout le monde a déjà implémenté, on suit ça avec attention.
Je ne sais pas si vous avez vu, on a rejoint l’Alliance FIDO [26] qui travaille sur les standards type Web Open et passkeys. Pour nous, le but c’est de faire entendre notre voix vis-à-vis de l’interopérabilité des passkeys. Les passkeys ont vocation à remplacer les mots de passe, en gros c’est un jeu de clefs publique/privée qui sera créé pour chaque site web quand le truc sera disponible à tout le monde, et des acteurs type Microsoft Google, Apple seront en charge de stocker ces clefs publiques et clefs privées qui servent à faire les signatures pour se logger sur les sites web.
Les gens connaissent un peu ce protocole s’ils utilisent des clefs type Yubikey ou des alternatives open source, Nitrokey il me semble, bref, des clefs de sécurité hardware compatibles FIDO. Maintenant Microsoft permet, par exemple, une intégration avec Microsoft Hello, donc avec la reconnaissance faciale, d’interagir avec le keyring de Windows, Apple fait la même chose. Il y a donc une convergence, à ce niveau-là, pour créer en gros trois gros silos avec Apple qui gère les passkeys des utilisateurs Apple, Microsoft la même chose. Il y a donc une place à jouer pour les password managers, pour permettre justement cette interopérabilité, pour leur permettre un, de stocker des passkeys, mais aussi de faire le pont entre des écosystèmes Microsoft et Apple ou, je ne sais pas, Android et Linux, ce genre de chose.
C’est cette partie-là du dialogue qui nous intéresse. On a aussi un dialogue avec les acteurs de password managers, on discute avec les acteurs Bitwarden, avec 1Password, avec Dashlane [27] aussi qui est très actif là-dessus. Des groupes de travail ont été créés, d’ailleurs à l’initiative de Dashlane ce qui est tout à son honneur. On va, par exemple, se rencontrer à Dublin pour justement parler de ces standards interopérables.
Un autre projet sur lequel ils travaillent à l’heure actuelle, c’est justement l’interopérabilité entre les password managers. À l’heure actuelle c’est un peu la foire à la saucisse, chacun fait son format et tous les password managers sont obligés d’implémenter six/sept formats d’import /export. Généralement ils font six imports et un export.
Walid Nouh : C’est du KeePass ?
Rémy Bertot : À la base, on pensait que KeePass était déjà un bon format parce que, potentiellement, c’est supporté par tout le monde et c’est un export qui est sécurisé. Ce n’est pas un fichier csv en clair, KeePass c’est quand même mieux qu’un csv. Il y a une toute une partie, je ne veux pas trop gâcher la surprise, qu’ils sont en train de rajouter sur ça, qui n’est pas couverte par KeePass, vous en entendrez parler dans quelques mois.
Walid Nouh : Pour finir sur cette partie un peu sécurité, cette partie entreprise, ce qui m’intéressait c’est de savoir un peu quels sont vos prochains défis. Une petite remarque : je fais pas mal de no-code et, dans les applications no-code qu’on va pouvoir trouver type N8N, Zapier [28], il n’y a pas Passbolt, donc on fait des codes HTTP et tout. Je voulais savoir quels sont vos gros défis, les gros trucs que vous voyez pour l’avenir, qui sont vraiment hyper-importants pour Passbolt.
Rémy Bertot : C’est marrant que tu parles de Zapier parce que j’ai parlé au CTO de Zapier la semaine dernière. Il me demandait comment ça se fait que Passbolt ne fait pas partie du catalogue. Eh bien oui, pourquoi ? Il faut qu’on se pose pour toutes ces intégrations, idéalement, un partenariat avec eux, ça m’intéresse de m’intégrer avec Zapier, en même il faut que ça ait du sens pour nous.
Pour les projets open source qui ne sont pas commerciaux, c’est normal que nous fassions l’effort, typiquement on ne va pas demander à la communauté KeePass de faire l’import/export dans Passbolt.
Pour d’autres projets propriétaires il peut y avoir une discussion. On est en discussion avec d’autres produits cloud qui veulent construire des intégrations avec Passbolt. C’est un challenge, mais je dirais que ce n’est pas notre principal focus. Notre focus, à l’heure actuelle, c’est vraiment de créer le meilleur produit pour les utilisateurs, donc l’expérience à l’intérieur de Passbolt, et favoriser l’adoption du produit à l’intérieur d’organisations toujours de plus en plus grosses. C’est vraiment notre focus.
Après, on a des challenges en termes de sécurité. Typiquement, toutes les métadonnées ne sont pas encryptées dans Passbolt, ce n’est pas comme KeePass où vous avez un coffre-fort, un fichier chiffré, forcément là vous avez une base de données relationnelles. Il y a donc encore des data qui pourraient être encryptées et qui ne le sont pas. C’est un sujet qui me tient à cœur, sur lequel j’ai vraiment envie de travailler dans les mois qui viennent. C’est un sujet qui est compliqué parce que ça touche, justement, à la performance mais aussi à l’auditabilité : qu’est-ce qui est visible par un administrateur, comment faire en sorte que les choses encryptées soient visibles. Nous sommes en discussion. Typiquement on a la SNT [Interdisciplinary Centre for Security, Reliability and Trust], au Luxembourg, qui est un département de crypto de l’Université du Luxembourg, qui est assez réputé, qui travaille sur le chiffrement homomorphique, ça permet de faire du chiffrement qui a des propriétés logiques. Si vous avez deux chiffres encryptés, vous pouvez faire une multiplication, une soustraction, c’est intéressant parce que le serveur ne sait pas. Par exemple, si vous voulez faire des rapports sur l’entropie des mots de passe, vous allez stocker un entier qui va dire « j’ai 160 bits d’entropie » et vous allez avoir une politique de l’entreprise qui dit « je ne veux pas de mots de passe qui soient en dessous de 90 bits d’entropie ». Avec le chiffrement homomorphique vous allez pouvoir faire ça. Vous allez demander au serveur « calcule-moi la distance entre ces deux chiffres » sans savoir quels sont ces deux chiffres. Ce sont des propriétés super intéressantes pour nous, parce que ça permet de générer des rapports sans lâcher d’informations. Ce sont des choses qu’on ne peut pas faire à l’heure actuelle avec OpenPGP. Là on discute. Ce sont des algorithmes qui sont nouveaux, qui ne sont pas encore normés, il n’y a pas de recommandations par exemple au niveau de l’ISO sur ce type d’algorithme. Ce sont des choses qu’on regarde de près.
Il y a donc du court terme, il y a du moyen terme, il y a du long terme. On essaie de construire sur tous ces challenges.
Walid Nouh : On a parlé un petit peu des différentes initiatives, des différents acteurs au Luxembourg. Je ne connais pas la scène luxembourgeoise en termes de logiciels libres. Est-ce que c’est très actif ? Est-ce que c’est un endroit assez propice pour faire du logiciel libre ? Je ne me rends pas du tout compte. Toi qui es dedans, est-ce que tu peux nous donner un peu une vision de comment c’est de faire du logiciel libre au Luxembourg ?
Rémy Bertot : Le Luxembourg est assez petit, l’avantage c’est que tout le monde se connaît, mais il n’y a pas beaucoup d’acteurs. Il y a quand même des projets open source qui ont percé. Je ne sais pas si vous connaissez le MISP [29] qui est un logiciel qui permet de faire du threat sharing, de l’intelligence pour partager les adversaires type malware, qui est utilisé par plein d’autres solutions. Typiquement Google se ploque dessus pour avoir des informations sur les malwares qui circulent, des banques se ploquent dessus pour pouvoir détecter des attaques ou même créer des règles de pare-feu. Ça a été développé par une organisation qui s’appelle SECURITYMADEIN.LU, qui s’appelle maintenant House of Cyberecurity. Ils ont fait plusieurs logiciels open source.
Ils ont fait aussi un logiciel de gestion de risques qui s’appelle Kace, qui est également en open source. Il y a donc une vraie volonté, en tout cas de la part des acteurs de la cyber au Luxembourg, de créer des solutions open source. On a un alignement très fort avec eux. Le CIRCL [Computer Incident Response Center Luxembourg], au Luxembourg, travaille sur l’analyse de malwares et à la réponse d‘incidents. Ils font un travail assez exceptionnel et ils ont les mêmes valeurs que nous, c’est-à-dire qu’il y a un très bon alignement.
Après je ne connais pas d’entreprise qui soit vraiment éditeur de logiciels libres au Luxembourg, mais il y a un écosystème de prestataires de services, typiquement Smile [30] fait du logiciel libre en service ici.
orcément, comme partout, il y a beaucoup d’utilisateurs de logiciels libres et de contributeurs de logiciels libres au Luxembourg. Mais, à ma connaissance, il n’y a pas beaucoup d’acteurs, d’éditeurs de logiciels comme nous. Le terrain économique est propice à cela et, comme je disais, en tout cas au niveau de la cybersécurité, les autorités et les acteurs étatiques sont vraiment friands de cela.
Walid Nouh : On arrive à la fin de l’entrevue. C’est l’heure de faire la tribune libre. La parole est à toi, tu peux faire passer un message aux auditrices et aux auditeurs, je te laisse la parole pour finir.
Rémy Bertot : J voulais juste te dire merci, Walid, de m’avoir invité. Dire merci aussi à la communauté de Passbolt, à tous ceux qui ont contribué à Passbolt, et également à tous les employés de la société Passbolt qui font, au jour le jour, un travail qui est stressant et également très valorisant. Aujourd’hui je suis sur la scène, j’ai les projecteurs sur moi, mais il y a quand même beaucoup d’acteurs, chez Passbolt, qui font un travail exceptionnel dont mes cofondateurs, Cédric et Kevin, et également toute l’équipe design, tous les développeurs de Passbolt. Je vous invite à les rejoindre sur community.passbolt.com, si vous avez des questions, on se fera un plaisir de discuter avec vous.
Walid Nouh : Super, c’était le mot de la fin.
Pour tous ceux qui ont aimé cet épisode, déjà merci de l’avoir écouté. N’hésitez pas à en parler autour de vous, à le faire tourner sur les réseaux sociaux et je vous dis à bientôt pour un prochain épisode, passionnant j’espère, comme la discussion qu’on vient d’avoir qui me ravit en tant qu’utilisateur convaincu de Passbolt. C’était vraiment un grand plaisir, Rémy, de pouvoir parler avec toi du projet un peu en profondeur.
Rémy Bertot : Merci beaucoup. À bientôt.
Walid Nouh : À bientôt.