Votée dans l’urgence et portée par une personnalité politique au moins controversée, la loi Avia qui s’appliquera dès le mois de juillet vise à réprimer la « cyberhaine ». Un grand nombre de voix se sont pourtant élevées pour émettre des mises en garde, comme dans cette alerte « la loi Avia est évidemment une atteinte gravissime à la liberté d’expression » et même dans des tribunes du Figaro ici et là.

Nous avons choisi de reprendre ici celle de Laurent Chemla (c’est qui ce gars-là ?) qui fustige la précipitation brouillonne et souhaite l’application à la vie politique d’un fort ancien principe en médecine. Elle est parue d’abord sur son blog Médiapart et il nous autorise à la reproduire.

---

Primum non nocere — par Laurent Chemla

Si la médecine a retenu (entre autres) d’Hippocrate son fameux « primum non nocere » (« Avant tout, ne pas nuire »), on peut regretter que le politique n’ait pas, lui aussi, appris ce principe de prudence abstentionniste, et que trop souvent il use du mantra inverse : « Il faut faire quelque chose ».

Non. Il ne faut jamais « faire quelque chose ».

Déjà parce que, dans la très grande majorité des cas, « faire quelque chose » c’est faire n’importe quoi.

Ensuite parce que, souvent, ne rien faire est moins nocif que d’inventer des solutions qui semblent faciles et rapides mais qui risquent surtout d’aggraver les choses.

Et enfin parce que, presque toujours, on se retrouve à justifier l’injustifiable une fois qu’on a mal agi. Au motif évidemment qu’il fallait bien « faire quelque chose ».

Loi « contre la haine » ?

Prenons l’exemple de la loi Avia « contre la haine en ligne ».

Celle-ci part d’un constat: la haine se diffuse – en ligne comme partout, et (c’est le grand principe de cette loi, que Mme Avia a clairement exposé ) « ce qui est interdit dans l’espace réel doit l’être également dans l’espace virtuel ».

Passons rapidement sur le fait que – dans la rue – la haine est partout sans que rien ou presque ne s’y oppose. Entre usagers de la route, entre piétons, entre voisins, entre manifestants et contre-manifestants, entre police et manifestants, la haine est devenue dans nos sociétés occidentales presque un mode de vie, au point qu’on s’étonne et se méfie du moindre geste bienveillant non sollicité. Et la rue… la rue est le théâtre quotidien du harcèlement des femmes et des exclus, des insultes, des remarques sexistes, homophobes, racistes et violentes, des agressions, des crachats et de la peur. La rue aussi c’est la pauvreté mise en spectacle, le mépris de l’étranger et de ceux que la société laisse sur, justement, le trottoir.

Oser affirmer, devant la représentation nationale, que la haine est interdite dans  » l’espace réel  » c’est – évidemment – se foutre d’un monde auquel on n’appartient plus parce qu’on s’en est protégé par des vitres teintées, des chauffeurs et des gardes du corps.

Qu’on me comprenne bien : ceci n’est pas une raison pour ignorer la haine en ligne. Mais quand l’argument de Mme Avia, pour justifier son texte, repose sur un tel mensonge préalable, on a le droit de s’en inquiéter même si ce n’est pas en soi un motif d’inaction. J’y reviendrai.

Passons, donc.

Et que ça saute !

Cette loi repose sur une idée simple. Simpliste, même : il suffirait de rendre les intermédiaires techniques responsables des contenus publiés par des tiers, de les contraindre à retirer tout ce qui leur est signalé comme étant « manifestement illicite » sous peine d’amendes démesurées, pour que nous soyons tous protégés des méchants, car c’est très urgent.

Et hop !

Alors déjà, pardon de le dire, mais ce débat-là est si vieux qu’il a le droit de vote depuis déjà 6 ans. C’est dire l’urgence de légiférer et de voter un tel texte alors que le pays n’est même pas encore sorti d’un confinement imposé par une crise d’une ampleur encore jamais vue. C’EST URGENT ON T’A DIT les morts, les masques, les tests et le vaccin, on verra plus tard.

Ce débat date du tout début de l’Internet grand-public, autour de 1996. Il a réuni des comités, des commissions, il a connu des lois, des rejets du Conseil Constitutionnel, d’autres lois, des jurisprudences, des textes, des réglements et une directive européenne. Des centaines, des milliers d’experts, de juristes, d’associations, de citoyens et de lobbies se sont penchés dessus (et s’y penchent encore puisque l’Europe a prévu d’y revenir durant la présente législature), pour essayer d’imaginer des équilibres qui respectent à la fois le droit à la liberté d’expression et la juste volonté d’empêcher les délits.

Des livres y sont entièrement consacrés.

Depuis 24 ans.

C’est dire L’URGENCE du truc, alors qu’on a remis aux calendes un sujet aussi fondamental que nos retraites parce que, voilà, c’est pas trop le moment hein.

C’était TELLEMENT urgent qu’on n’a même pas respecté la procédure européenne obligatoire pour ce type de législation, c’est trop grave : on se moque des députés sur Twitter, tu te rends compte, il faut légiférer VITE !

Bref.

Têtes d’oeuf

Clément Viktorovitch résume très bien les termes du problème dans cette courte vidéo : quand on délègue à des entreprises privées le droit de juger de ce qui est légal ou illégal, on s’expose à une censure de très grande ampleur – parce que c’est plus simple et moins cher de censurer que de se poser des questions, surtout quand on risque des amendes de très grande ampleur, et que le profit est le seul guide des entreprises privées. Tout simplement.

Rendre la justice est une fonction régalienne. Les fonctions régaliennes sont des tâches que l’État ne doit pas, ou ne peut pas, déléguer à des sociétés privées. La loi Avia fait le contraire. Voilà mon résumé à moi.

Je le dis, je le répète, je le blogue et je le conférence depuis plus de 20 ans, ici et partout : si le droit à la liberté d’expression est inscrit dans notre constitution depuis le 18e siècle, ce droit n’était que très théorique jusqu’à l’arrivée d’Internet. C’est par et grâce à Internet que la parole publique est devenue accessible à tous.

Il n’est donc pas très étonnant que ce droit-là soit un des moins bien protégés par nos textes de loi, il n’est donc pas très étonnant que la liberté d’expression du grand public remette en cause les usages et les habitudes des puissants… et il n’est donc pas très étonnant que ces mêmes puissants fassent tout ce qu’ils peuvent pour remettre à sa place ce grand public qui ose s’arroger le droit de les critiquer à la face du monde.

Il est donc d’autant plus important d’y faire très attention et de ne pas légiférer n’importe comment et dans l’URGENCE parce que l’ego de quelque députée a été un peu froissé par des remarques en ligne sur ses tendances mordantes, fussent-elles problématiques. Je vous engage à revoir, encore une fois, dans la courte vidéo ci-dessus mentionnée en quels termes Mme Avia a présenté son texte en première lecture ( « MES trolls, MES haters, MES têtes d’œuf anonymes ») pour bien comprendre ses raisons – très personnelles et donc très éloignées du bien public – d’agir.

Hélas, le respect des grands principes républicains n’est visiblement pas l’URGENCE.

Latin de garage

En médecine, donc, le « triangle hippocratique » (médecin, malade et maladie) se base sur la confiance. La confiance qu’on accorde à celui entre les mains duquel on remet sa vie pour qu’il n’agisse que pour notre bien, ou – au minimum – pour qu’il n’aggrave pas notre situation. Primum non nocere.

En politique, ce même principe devrait s’appliquer. Mais force est de constater qu’en politique aujourd’hui, le principe est plutôt « primum actum » (« d’abord agir », dans mon latin de garage) avant même d’avoir bien pesé le pour et le contre. Au risque de tuer le malade, et dans le cas qui me fait réagir ici au risque de réduire à néant un de nos droits fondamentaux.

Pour autant, « ne rien faire » contre la haine en ligne n’est pas le contraire de « faire n’importe quoi pourvu que ça fasse taire mes opposants au risque de détruire des équilibres difficilement atteints ». L’accès à la liberté d’expression pour tous est un phénomène récent, et il est normal de réfléchir à ses dérives. Et il est normal que ces dérives se produisent tant que la société n’a pas intégré profondément les règles qu’impose l’usage d’une liberté. Ce n’est pas, pour faire un parallèle rapide, parce que la liberté de se déplacer est un droit fondamental qu’on a pas besoin d’un code de la route. Mais ce n’est pas parce qu’on a besoin d’un code de la route qu’on doit donner le droit aux sociétés d’autoroute d’interdire le passage à qui bon leur semble.

Intégrer les règles sociales d’un outil aussi profondément disruptif qu’Internet ne se fait pas en un jour, ni même en une génération. Ça prend du temps, ça nécessite des efforts, y compris financiers. On peut, on doit s’opposer à la haine. En ligne comme partout. En donnant des moyens à l’éducation pour former de futurs citoyens. En donnant à la justice des moyens d’agir plus rapidement et plus efficacement.

Pour qu’à force d’exemples et de formations, chacun apprenne à mieux se comporter, à mieux peser la responsabilité qu’il doit s’imposer lorsqu’il use de la parole publique, à mieux connaître ses droits et ses devoirs. En ligne comme partout. C’est long, c’est cher, ça ne se fait pas dans l’urgence et ce n’est pas aussi facile que de faire voter une loi stupide par une majorité sans partage.

Mais dans une société démocratique et respectueuse de ses grands principes, c’est comme ça que ça devrait se faire.

Et pas autrement.

 

« Il est évidemment plus qu’urgent de réguler les GAFAM pour leur imposer l’interopérabilité. » écrit Laurent Chemla. Diable, il n’y va pas de main morte, le « précurseur dans le domaine d’Internet » selon sa page Wikipédia.

Nous reproduisons ici avec son accord l’article qu’il vient de publier sur son blog parce qu’il nous paraît tout à fait intéressant et qu’il est susceptible de provoquer le débat : d’aucuns trouveront sa proposition nécessaire pour franchir une étape dans la lutte contre des Léviathans numériques et le consentement à la captivité. D’autres estimeront peut-être que sa conception a de bien faibles chances de se concrétiser : est-il encore temps de réguler les Gafam ?

Nous souhaitons que s’ouvre ici (ou sur son blog bien sûr) la discussion. Comme toujours sur le Framablog, les commentaires sont ouverts mais modérés.

« Interopérabilité » : ce mot m’ennuie. Il est moche, et beaucoup trop long.

Pourtant il est la source même d’Internet. Quasiment sa définition, au moins sémantique puisqu’il s’agit de faire dialoguer entre eux des systèmes d’information d’origines variées mais partageant au sein d’un unique réseau de réseaux la même « lingua franca » : TCP/IP et sa cohorte de services (ftp, http, smtp et tant d’autres) définis par des standards communs. Des machines « interopérables », donc.

Faisons avec.

L’interopérabilité, donc, est ce qui a fait le succès d’Internet, et du Web. Vous pouvez vous connecter sur n’importe quel site Web, installé sur n’importe quel serveur, quelle que soit sa marque et son système d’exploitation, depuis votre propre ordinateur, quelle que soit sa marque, son système d’exploitation, et le navigateur installé dessus.

Avant ça existaient les silos. Compuserve, AOL, The Microsoft Network en étaient les derniers représentants, dinosaures communautaires enterrés par la comète Internet. Leur volonté d’enfermer le public dans des espaces fermés, contrôlés, proposant tant bien que mal tous les services à la fois, fut ridiculisée par la décentralisation du Net.

Ici vous ne pouviez échanger qu’avec les clients du même réseau, utilisant le même outil imposé par le vendeur (« pour votre sécurité »), là vous pouviez choisir votre logiciel de mail, et écrire à n’importe qui n’importe où. Interopérabilité.

Ici vous pouviez publier vos humeurs, dans un format limité et imposé par la plateforme (« pour votre sécurité »), là vous pouviez installer n’importe quel « serveur web » de votre choix et y publier librement des pages accessibles depuis n’importe quel navigateur. Interopérabilité.

Bref. Le choix était évident, Internet a gagné.

Il a gagné, et puis… Et puis, selon un schéma désormais compris de tous, le modèle économique « gratuité contre publicité » a envahi le Web, en créant – une acquisition après l’autre, un accaparement de nos données après l’autre – de nouveaux géants qui, peu à peu, se sont refermés sur eux-mêmes (« pour votre sécurité »).

Il fut un temps où vous pouviez écrire à un utilisateur de Facebook Messenger depuis n’importe quel client, hors Facebook, respectant le standard (en l’occurrence l’API) défini par Facebook. Et puis Facebook a arrêté cette fonctionnalité. Il fut un temps où vous pouviez développer votre propre client Twitter, qui affichait ses timelines avec d’autres règles que celles de l’application officielle, pourvu qu’il utilise le standard (encore une API) défini par Twitter. Et puis Twitter a limité cette fonctionnalité. De nos jours, il devient même difficile d’envoyer un simple email à un utilisateur de Gmail si l’on utilise pas soi-même Gmail, tant Google impose de nouvelles règles (« pour votre sécurité ») à ce qui était, avant, un standard universel.

On comprend bien les raisons de cette re-centralisation : tout utilisateur désormais captif devra passer davantage de temps devant les publicités, imposées pour pouvoir utiliser tel ou tel service fermé. Et il devra – pour continuer d’utiliser ce service – fournir toujours davantage de ses données personnelles permettant d’affiner son profil et de vendre plus cher les espaces publicitaires. Renforçant ainsi toujours plus les trésoreries et le pouvoir de ces géants centralisateurs, qui ainsi peuvent aisément acquérir ou asphyxier tout nouveau wanabee concurrent, et ainsi de suite.

C’est un cercle vertueux (pour les GAFAM) et vicieux (pour nos vies privées et nos démocraties), mais c’est surtout un cercle « normal » : dès lors que rien n’impose l’interopérabilité, alors – pour peu que vous soyez devenu assez gros pour vous en passer – vous n’avez plus aucun intérêt à donner accès à d’autres aux données qui vous ont fait roi. Et vous abandonnez alors le modèle qui a permis votre existence au profit d’un modèle qui permet votre croissance. Infinie.

Imaginez, par exemple, qu’à l’époque des cassettes vidéo (respectant le standard VHS) un fabricant de magnétoscopes ait dominé à ce point le marché qu’on ait pu dire qu’il n’en existait virtuellement pas d’autres : il aurait évidemment modifié ce standard à son profit, en interdisant par exemple l’utilisation de cassettes d’autres marques que la sienne (« pour votre sécurité »), de manière à garantir dans le temps sa domination. C’est un comportement « normal », dans un monde libéral et capitaliste. Et c’est pour limiter ce comportement « normal » que les sociétés inventent des régulations (standards imposés, règles de concurrence, lois et règlements).

Et il est évidemment plus qu’urgent de réguler les GAFAM pour leur imposer l’interopérabilité.

Nous devons pouvoir, de nouveau, écrire depuis n’importe quel logiciel de messagerie à un utilisateur de Facebook Messenger, pourvu qu’on respecte le standard défini par Facebook, comme nous devons écrire à n’importe quel utilisateur de Signal en respectant le standard de chiffrement de Signal. Il n’est pas question d’imposer à Signal (ou à Facebook) un autre standard que celui qu’il a choisi (ce qui empêcherait toute innovation), pourvu que le standard choisi soit public, et libre d’utilisation. Mais il est question de contraindre Facebook à (ré)ouvrir ses API pour permettre aux utilisateurs d’autres services d’interagir de nouveau avec ses propres utilisateurs.

Au passage, ce point soulève une problématique incidente : l’identité. Si je peux écrire à un utilisateur de Messenger, celui-ci doit pouvoir me répondre depuis Messenger. Or Messenger ne permet d’écrire qu’aux autres utilisateurs de Messenger, identifiés par Facebook selon ses propres critères qu’il n’est pas question de lui imposer (il a le droit de ne vouloir admettre que des utilisateurs affichant leur « identité réelle », par exemple : ce choix est le sien, comme il a le droit de limiter les fonctionnalités de Messenger pour lui interdire d’écrire à d’autres : ce choix est aussi le sien).

Il est donc cohérent d’affirmer que – pour pouvoir écrire à un utilisateur de Messenger depuis un autre outil – il faut avoir soi-même un compte Messenger. Il est donc logique de dire que pour pouvoir lire ma timeline Twitter avec l’outil de mon choix, je dois avoir un compte Twitter. Il est donc évident que pour accéder à mon historique d’achat Amazon, je dois avoir un compte Amazon, etc.

L’obligation d’avoir une identité reconnue par le service auquel on accède, c’est sans doute le prix à payer pour l’interopérabilité, dans ce cas (et – au passage – c’est parce que la Quadrature du Net a décidé d’ignorer cette évidence que j’ai choisi de quitter l’association).

Ce qui ne doit évidemment pas nous obliger à utiliser Messenger, Amazon ou Twitter pour accéder à ces comptes: l’interopérabilité doit d’accéder à nos contacts et à nos données depuis l’outil de notre choix, grâce à l’ouverture obligatoire des API, pourvu qu’on dispose d’une identité respectant les standards du service qui stocke ces données.

On pourrait résumer ce nouveau type de régulation avec cette phrase simple :

« si ce sont MES données, alors je dois pouvoir y accéder avec l’outil de MON choix ».

Je dois pouvoir lire ma timeline Twitter depuis l’outil de mon choix (et y publier, si évidemment j’y ai un compte, pour que les autres utilisateurs de Twitter puissent s’y abonner).

Je dois pouvoir consulter mon historique d’achats chez Amazon avec l’outil de mon choix.

Je dois pouvoir écrire à (et lire les réponses de) mes contacts Facebook avec l’outil de mon choix.

Il y aura, évidemment, des résistances.

On nous dira (« pour votre sécurité ») que c’est dangereux, parce que nos données personnelles ne seront plus aussi bien protégées, dispersées parmi tellement de services décentralisés et piratables. Mais je préfère qu’une partie de mes données soit moins bien protégée (ce qui reste à démontrer) plutôt que de savoir qu’une entreprise privée puisse vendre (ou perdre) la totalité de ce qui est MA vie.

On nous dira que c’est « excessivement agressif pour le modèle économique des grandes plateformes », alors qu’évidemment c’est justement le modèle économique des grandes plateformes qui est excessivement agressif pour nos vies privées et nos démocraties, d’une part, et que d’autre part l’interopérabilité ne modifie en rien ce modèle économique : dès lors qu’elles stockent toujours une partie de nos données elles restent (hélas) en capacité de les vendre et/ou de les utiliser pour « éduquer » leurs IA. Tout au plus constateront-elles un manque-à-gagner comptable, mais ne gagnent-elles pas déjà largement assez ?

À ce jour, l’interopérabilité s’impose comme la seule solution réaliste pour limiter le pouvoir de nuisance de ces géants, et pour rétablir un peu de concurrence et de décentralisation dans un réseau qui, sinon, n’a plus d’autre raison d’être autre chose qu’un simple moyen d’accéder à ces nouveaux silos (qu’ils devraient donc financer, eux, plutôt que les factures de nos FAI).

À ce jour, l’ARCEP, la Quadrature du Net (même mal), l’EFF, le Sénat, et même l’Europe (Margrethe Vestager s’est elle-même déclarée en faveur de cette idée) se sont déclarés pour une obligation d’intéropérabilité. C’est la suite logique (et fonctionnelle) du RGPD.

Qu’est-ce qu’on attend ?

Édit. de Laurent suite à la publication de l’article sur son blog

Suite à ce billet des discussions sur Twitter et Mastodon, indépendamment, m’ont amené à préciser ceci : prenons par exemple mamot.fr (l’instance Mastodon de la Quadrature) et gab.ai (l’instance Mastodon de la fachosphère). Mamot.fr, comme nombre d’autres instances, a refusé de se fédérer avec Gab. C’est son droit. En conséquence, les utilisateurs de Gab ne peuvent pas poster sur Mamot, et inversement.

Pour autant, les deux sont bel et bien interopérables, et pour cause : elles utilisent le même logiciel. Gab pourrait parfaitement développer un bout de code pour permettre à ses utilisateurs de publier sur Mamot, pour peu qu’ils s’y soient identifiés (via une OAuth, pour les techniciens) prouvant ainsi qu’ils en acceptent les CGU.

Ce qu’elles ne sont pas, c’est interconnectées : il n’est pas possible de publier sur l’une en s’identifiant sur l’autre, et inversement.

Je crois qu’au fond, les tenants de l’idée qu’on devrait pouvoir publier n’importe quoi n’importe où, sans identification supplémentaire, confondent largement ces deux notions d’interconnexion et d’interopérabilité. Et c’est fort dommage, parce que ça brouille le message de tous.

 

Pour aller plus loin dans la technique, vous pouvez aussi lire cette réponse de Laurent dans les commentaires de NextINpact.

Le projet Caliopen, lancé il y a trois ans, est un projet ambitieux. Alors qu’il est déjà complexe de créer un nouveau logiciel de messagerie, il s’agit de proposer un agrégateur de correspondance qui permette à chacun d’ajuster son niveau de confidentialité.

Ce logiciel libre mûrement réfléchi est tout à fait en phase avec ce que Framasoft s’efforce de promouvoir à chaque fois que des libristes donnent aux utilisateurs et utilisatrices plus d’autonomie et de maîtrise, plus de sécurité et de confidentialité.

Après une nécessaire période d’élaboration, le projet Caliopen invite tout le monde à tester la version alpha et à faire remonter les observations et suggestions. La première version grand public ce sera pour dans un an environ.

Vous êtes curieux de savoir ce que ça donne ? Nous l’étions aussi, et nous avons demandé à Laurent Chemla, qui bidouillait déjà dans l’Internet alors que vous n’étiez même pas né⋅e, de nous expliquer tout ça, puisqu’il est le père tutélaire du projet Caliopen, un projet que nous devons tous soutenir et auquel nous pouvons contribuer.

Bonjour, pourrais-tu te présenter brièvement ?

J’ai 53 ans, dont 35 passés dans les mondes de l’informatique et des réseaux. Presque une éternité dans ce milieu – en tous cas le temps d’y vivre plusieurs vies (« pirate », programmeur, hacktiviste, entrepreneur…). Mais ces temps-ci je suis surtout le porteur du projet Caliopen, même si je conserve une petite activité au sein du CA de la Quadrature du Net. Et je fais des macarons.

Le projet Caliopen arrive ce mois-ci au stade de la version alpha, mais comment ça a commencé ?

Jérémie Zimmermann est venu me sortir de ma retraite nîmoise en me poussant à relancer un très ancien projet de messagerie après les révélations de Snowden. Ça faisait déjà un petit moment que je me demandais si je pouvais encore être utile à la communauté autrement qu’en publiant quelques billets de temps en temps, alors j’ai lancé l’idée en public, pour voir, et il y a eu un tel retour que je n’ai pas pu faire autrement que d’y aller, malgré ma flemme congénitale.

Quand tu as lancé le projet publiquement (sur une liste de diffusion il me semble) quelle était la feuille de route, ou plutôt la « bible » des spécifications que tu souhaitais voir apparaître dans Caliopen ?

Très vite on a vu deux orientations se dessiner : la première, très technique, allait vers une vision maximaliste de la sécurité (réinventer SMTP pour protéger les métadonnées, garantir l’anonymat, passer par du P2P, ce genre de choses), tandis que la seconde visait à améliorer la confidentialité des échanges sans tout réinventer. Ça me semblait plus réaliste – parce que compatible avec les besoins du grand public – et c’est la direction que j’ai choisi de suivre au risque de fâcher certains contributeurs.

J’ai alors essayé de lister toutes les fonctionnalités (aujourd’hui on dirait les « User Stories ») qui sont apparues dans les échanges sur cette liste, puis de les synthétiser, et c’est avec ça que je suis allé voir Stephan Ramoin, chez Gandi, pour lui demander une aide qu’il a aussitôt accepté de donner. Le projet a ensuite évolué au rythme des échanges que j’ai pu avoir avec les techos de Gandi, puis de façon plus approfondie avec Thomas Laurent pendant la longue étape durant laquelle nous avons imaginé le design de Caliopen. C’est seulement là, après avoir défini le « pourquoi » et le « quoi » qu’on a pu vraiment commencer à réfléchir au « comment » et à chercher du monde pour le réaliser.

La question qui fâche : quand on lit articles et interviews sur Caliopen, on a l’impression que le concept est encore super flou. C’est quoi l’elevator pitch pour vendre le MVP de la start-up aux business angels des internets digitaux ? (en français : tu dis quoi pour convaincre de nouveaux partenaires financiers ?)

Ça fait bien 3 ans que le concept de base n’a pas bougé : un agrégateur de correspondances qui réunit tous nos échanges privés (emails, message Twitter ou Facebook, messageries instantanées…), sous forme de conversations, définies par ceux avec qui on discute plutôt que par le protocole utilisé pour le faire. Voilà pour ton pitch.

Ce qui est vrai c’est qu’en fonction du public auquel on s’adresse on ne présente pas forcément le même angle.  Le document qui a été soumis à BPI France pour obtenir le financement actuel fait 23 pages, très denses. Il aborde les aspects techniques, financiers, l’état du marché, la raison d’être de Caliopen, ses objectifs sociétaux, ses innovations, son design, les différents modèles économiques qui peuvent lui être appliqués… ce n’est pas quelque chose qu’on peut développer en un article ou une interview unique.

Si j’aborde Caliopen sous l’angle de la vie privée, alors j’explique par exemple le rôle des indices de confidentialité, la façon dont le simple fait d’afficher le niveau de confidentialité d’un message va influencer l’utilisateur dans ses pratiques: on n’écrit pas la même chose sur une carte postale que dans une lettre sous enveloppe. Rien que sur ce sujet, on vient de faire une conférence entière (à Paris Web et à BlendWebMix) sans aborder aucun des autres aspects du projet.

Si je l’aborde sous l’angle technique, alors je vais peut-être parler d’intégration « verticale ». Du fait qu’on ne peut pas se contenter d’un nouveau Webmail, ou d’un nouveau protocole, si on veut tenir compte de tous les aspects qui font qu’un échange est plus ou moins secret. Ce qui fait de Caliopen un ensemble de différentes briques plutôt qu’une unique porte ou fenêtre. Ou alors je vais parler de la question du chiffrement, de la diffusion des clés publiques, de TOFU et du RFC 7929…

Mais on peut aussi débattre du public visé, de design, d’économie du Web, de décentralisation… tous ces angles sont pertinents, et chacun peut permettre de présenter Caliopen avec plus ou moins de détails.

Caliopen est un projet complexe, fondé sur un objectif (la lutte contre la surveillance de masse) et basé sur un moyen (proposer un service utile à tous), qui souhaite changer les habitudes des gens en les amenant à prendre réellement conscience du niveau d’exposition de leur vie privée. Il faut plus de talent que je n’en ai pour le décrire en quelques mots.

Il reste un intérêt pour les mails ? On a l’impression que tout passe par les webmails ou encore dans des applis de communication sur mobile, non ?

Même si je ne crois pas à la disparition de l’email, c’est justement parce qu’on a fait le constat qu’aujourd’hui la correspondance numérique passe par de très nombreux services qu’on a imaginé Caliopen comme un agrégateur de tous ces échanges.

C’est un outil qui te permet de lire et d’écrire à tes contacts sans avoir à te préoccuper du service, ou de l’application, où la conversation a commencé. Tu peux commencer un dialogue avec quelqu’un par message privé sur Twitter, la poursuivre par email, puis par messagerie instantanée… ça reste une conversation: un échange privé entre deux humains, qui peuvent aborder différents sujets, partager différents contenus. Et quand tu vas vouloir chercher l’information que l’autre t’a donné l’année passée, tu vas faire comment ?

C’est à ça que Caliopen veut répondre. Pour parler moderne, c’est l’User Story centrale du projet.

C’est quoi exactement cette histoire de niveaux de confidentialité ? Quel est son but ?

Il faut revenir à l’objectif principal du projet : lutter contre la surveillance de masse que les révélations d’Edward Snowden ont démontrée.

Pour participer à cette lutte, Caliopen vise à convaincre un maximum d’utilisateurs de la valeur de leur vie privée. Et pour ça, il faut d’abord leur montrer, de manière évidente, que leurs conversations sont très majoritairement espionnables, sinon espionnées. Notre pari, c’est que quand on voit le risque d’interception, on réagit autrement que lorsqu’on est seulement informé de son existence. C’est humain : regarde l’exemple de la carte postale que je te donne plus haut.

D’où l’idée d’associer aux messages (mais aussi aux contacts, aux terminaux, et même à l’utilisateur lui-même) un niveau de confidentialité. Représenté par une icône, des couleurs, des chiffres, c’est une question de design, mais ce qui est important c’est qu’en voyant le niveau de risque, l’utilisateur ne va plus pouvoir faire semblant de l’ignorer et qu’il va accepter de changer – au moins un peu – ses pratiques et ses habitudes pour voir ce niveau augmenter.

Bien sûr, il faudra l’accompagner. Lui proposer des solutions (techniques, comportementales, contextuelles) pour améliorer son « score ». Sans le culpabiliser (ce n’est pas la bonne manière de faire) mais en le récompensant  – par une meilleure note, de nouvelles fonctionnalités, des options gratuites si le service est payant… bref par une ludification de l’expérience utilisateur. C’est notre piste en tous cas.

Et c’est en augmentant le niveau global de confidentialité des échanges qu’on veut rendre plus difficile (donc plus chère) la surveillance de tous, au point de pousser les états – et pourquoi pas les GAFAM – à changer de pratiques, eux aussi.

Financièrement, comment vit le projet Caliopen ? C’était une difficulté qui a retardé l’avancement ?

Sans doute un peu, mais je voudrais quand même dire que, même si je suis bien conscient de l’impression de lenteur que peut donner le projet, il faut se rendre compte qu’on parle d’un outil complexe, qui a démarré de zéro, avec aucun moyen, et qui s’attaque à un problème dont les racines datent de plusieurs dizaines d’années. Si c’était facile et rapide à résoudre, ça se saurait.

Dès l’instant où nous avons pris conscience qu’on n’allait pas pouvoir continuer sur le modèle du bénévolat, habituel au milieu du logiciel libre, nous avons réagi assez vite : Gandi a décidé d’embaucher à plein temps un développeur front end, sur ses fonds propres. Puis nous avons répondu à un appel à projet de BPI France qui tombait à pic et auquel Caliopen était bien adapté. Nous avons défendu notre dossier, devant un comité de sélection puis devant un panel d’experts, et nous avons obtenu de quoi financer deux ans de développement, avec une équipe dédiée et des partenaires qui nous assurent de disposer de compétences techniques rares. Et tout ça est documenté sur notre blog, depuis le début (tout est public depuis le début, d’ailleurs, même si tous les documents ne sont pas toujours faciles à retrouver, même pour nous).

Et finalement c’est qui les partenaires ?

Gandi reste le partenaire principal, auquel se sont joints Qwant et l’UPMC (avec des rôles moins larges mais tout aussi fondamentaux).

Quel est le modèle économique ? Les développeurs (ou développeuses, y’en a au fait dans l’équipe ?) sont rémunérés autrement qu’en macarons ? Combien faudra-t-il payer pour ouvrir un compte ?

Je ne suis pas sûr qu’on puisse parler de « modèle économique » pour un logiciel libre : après tout chacun pourra en faire ce qu’il voudra et lui imaginer tel ou tel modèle (économique ou non d’ailleurs).

Une fois qu’on a dit ça, on peut quand même dire qu’il ne serait pas cohérent de baser des services Caliopen sur l’exploitation des données personnelles des utilisateurs, et donc que le modèle « gratuité contre données » n’est pas adapté. Nous imaginons plutôt des services ouverts au public de type freemium, d’autres fournis par des entreprises pour leurs salariés, ou par des associations pour leurs membres. On peut aussi supposer que se créeront des services pour adapter Caliopen à des situations particulières, ou encore qu’il deviendra un outil fourni en Saas, ou vendu sous forme de package associé, par exemple, à la vente d’un nom de domaine.

Bref : les modèles économiques ce n’est pas ce qui manque le plus.

L’équipe actuelle est salariée, elle comporte des développeuses, et tu peux voir nos trombinettes sur https://www.caliopen.org

 

Trouver des développeurs ou développeuses n’est jamais une mince affaire dans le petit monde de l’open source, comment ça s’est passé pour Caliopen ?

Il faut bien comprendre que – pour le moment – Caliopen n’a pas d’existence juridique propre. Les gens qui bossent sur le projet sont des employés de Gandi (et bientôt de Qwant et de l’UPMC) qui ont soit choisi de consacrer une partie de leur temps de travail à Caliopen (ce que Gandi a rendu possible) soit été embauchés spécifiquement pour le projet. Et parfois nous avons des bénévoles qui nous rejoignent pour un bout de chemin 🙂

Le projet est encore franco-français. Tu t’en félicites (cocorico) ou ça t’angoisse ?

J’ai bien des sujets d’angoisse, mais pas celui-là. C’est un problème, c’est vrai, et nous essayons de le résoudre en allant, par exemple, faire des conférences à l’étranger (l’an dernier au FOSDEM, et cette année au 34C3 si notre soumission est acceptée). Et le site est totalement trilingue (français, anglais et italien) grâce au travail (bénévole) de Daniele Pitrolo.

D’un autre côté il faut quand même reconnaître que bosser au quotidien dans sa langue maternelle est un vrai confort dont il n’est pas facile de se passer. Même si on est tous conscients, je crois, qu’il faudra bien passer à l’anglais quand l’audience du projet deviendra un peu plus internationale, et nous comptons un peu sur les premières versions publiques pour que ça se produise.

Et au fait, c’est codé en quoi, Caliopen ? Du JavaScript surtout, d’après ce qu’on voit sur GitHub, mais nous supposons qu’il y a pas mal de technos assez pointues pour un tel projet ?

Sur GitHub, le code de Caliopen est dans un mono-repository, il n’y a donc pas de paquet (ou dépôt) spécifique au front ou au back. Le client est développé en JavaScript avec la librarie ReactJS. Le backend (l’API ReST, les workers …) sont développés en python et en Go. On n’a pas le détail mais ce doit être autour de 50% JS+css, 25% python, 25% Go. L’architecture est basée sur Cassandra et ElasticSearch.

Ce n’est pas que l’on utilise des technos pointues, mais plutôt qu’ on évite autant que possible la dette technique en intégrant le plus rapidement possible les évolutions des langages et des librairies que l’on utilise.

Donc il faut vraiment un haut niveau de compétences pour contribuer ?

Difficile à dire. Si on s’arrête sur l’aspect développement pur, les technos employées sont assez grand public, et si on a suivi un cursus standard on va facilement retrouver ses habitudes (cf. https://github.com/kamranahmedse/developer-roadmap).

Effectivement quelqu’un qui n’a pas l’habitude de développer sur ces outils (docker, Go, webpack, ES6+ …) risque d’être un peu perdu au début. Mais on est très souvent disponibles sur IRC pour répondre directement aux questions.

Néanmoins nous avons de « simples » contributions qui ne nécessitent pas de connaître les patrons de conception par cœur ou de devoir monter un cluster; par exemple proposer des corrections orthographiques, de nouvelles traductions, décrire des erreurs JavaScript dans des issues sur github, modifier un bout de css…

Ou même aider la communauté sur https://feedback.caliopen.org/ ou sur les réseaux sociaux, tout ça en fait partie.

Et bien sûr les alpha-testeurs sont bienvenus surtout s’ils font des retours d’expérience.

Qu’est-ce qui différencie le projet Caliopen d’un projet comme Protonmail ?

Protonmail est un Gmail-like orienté vers la sécurité. Caliopen est un agrégateur de correspondance privée (ce qui n’est rien-like) orienté vers l’amélioration des pratiques du grand public via l’expérience utilisateur. Protonmail est centralisé, Caliopen a prévu tout un (futur) écosystème exclusivement destiné à garantir la décentralisation des échanges. Et puis Caliopen est un logiciel libre, pas Protonmail.

Mais au-delà de ces différences techniques et philosophiques, ce sont surtout deux visions différentes, et peut-être complémentaires, de la lutte contre la surveillance de masse: Protonmail s’attaque à la protection de ceux qui sont prêts à changer leurs habitudes (et leur adresse email) parce qu’ils sont déjà convaincus qu’il faut faire certains efforts pour leur vie privée. Caliopen veut changer les habitudes de tous les autres, en leur proposant un service différent (mais utile) qui va les sensibiliser à la question. Parce qu’il faut bien se rendre compte que, malgré son succès formidable, aujourd’hui le nombre d’utilisateurs de Protonmail ne représente qu’à peine un millième du nombre d’utilisateurs de Gmail, et que quand les premiers échangent avec les seconds ils ne sont pas mieux protégés que M. Michu.

Maintenant, si tu veux bien imaginer que Caliopen est aussi un succès (on a le droit de rêver) et qu’il se crée un jour disons une dizaine de milliers de services basés sur noooootre proooojet, chacun ne gérant qu’un petit dixième du nombre d’utilisateurs de Protonmail… Eh ben sauf erreur on équilibre le nombre d’utilisateurs de Gmail et – si on a raison de croire que l’affichage des indices de confidentialité va produire un effet – on a significativement augmenté le niveau global de confidentialité.

Et peut-être même assez pour que la surveillance de masse devienne hors de prix.

Est-ce que dans la future version de Caliopen les messages seront chiffrés de bout en bout ?

À chaque fois qu’un utilisateur de Caliopen va vouloir écrire à un de ses contacts, c’est le protocole le plus sécurisé qui sera choisi par défaut pour transporter son message. Prenons un exemple et imaginons que tu m’ajoutes à tes contacts dans Caliopen : tu vas renseigner mon adresse email, mon compte Twitter, mon compte Mastodon, mon Keybase… plus tu ajouteras de moyens de contact plus Caliopen aura de choix pour m’envoyer ton message. Et il choisira le plus sécurisé par défaut (mais tu pourras décider de ne pas suivre son choix).

Plus tes messages auront pu être sécurisés, plus hauts seront leurs indices de confidentialité affichés. Et plus les indices de confidentialité de tes échanges seront hauts, plus haut sera ton propre indice global (ce qui devrait te motiver à mieux renseigner ma fiche contact afin d’y ajouter l’adresse de mon email hébergé sur un service Caliopen, parce qu’alors le protocole choisi sera le protocole intra-caliopen qui aura un très fort indice de confidentialité).

Mais l’utilisateur moyen n’aura sans doute même pas conscience de tout ça. Simplement le système fera en sorte de ne pas envoyer un message en clair s’il dispose d’un moyen plus sûr de le faire pour tel ou tel contact.

Est-ce qu’on pourra (avec un minimum de compétences, par exemple pour des CHATONS) installer Caliopen sur un serveur et proposer à des utilisateurs et utilisatrices une messagerie à la fois sécurisée et respectueuse ?

C’est fondamental, et c’est un des enjeux de Caliopen. Souvent quand je parle devant un public technique je pose la question : « combien de temps mettez-vous à installer un site Web en partant de zéro, et combien de temps pour une messagerie complète ? ». Et les réponses aujourd’hui sont bien sûr diamétralement opposées à ce qu’elle auraient été 15 ans plus tôt, parce qu’on a énormément travaillé sur la facilité d’installation d’un site, depuis des années, alors qu’on a totalement négligé la messagerie.

Si on veut que Caliopen soit massivement adopté, et c’est notre objectif, alors il faudra qu’il soit – relativement – facile à installer. Au moins assez facile pour qu’une entreprise, une administration, une association… fasse le choix de l’installer plutôt que de déléguer à Google la gestion du courrier de ses membres. Il faudra aussi qu’il soit facilement administrable, et facile à mettre à jour. Et tout ceci a été anticipé, et analysé, durant tout ce temps où tu crois qu’on n’a pas été assez vite !

On te laisse le dernier mot comme il est de coutume dans nos interviews pour le blog…

À lire tes questions j’ai conscience qu’on a encore beaucoup d’efforts à faire en termes de communication. Heureusement pour nous, Julien Dubedout nous a rejoints récemment, et je suis sûr qu’il va beaucoup améliorer tout ça. 🙂

• Devenir alpha-testeur
• Les fonctionnalités de Caliopen
• roadmap et bugreport
• GitHub de Caliopen