La nouvelle a déjà été reprise par de nombreux articles du CNRS, de l’INS2I, de l’Université de Paris, de l’Université Paris-Saclay, etc. Si je reviens dessus aujourd’hui, c’est, d’une part car les vidéos de la conférence, et en particulier de la cérémonie, sont désormais disponibles, et d’autre part, pour présenter le contenu de la candidature que nous avions soumise pour l’obtention de ce prix.

La vidéo de la cérémonie se trouve ici et la partie consacrée à Coq commence à 11:51 et dure jusqu’à 16:30.

Si vous ne souhaitez pas la regarder, en voici des extraits :

• Daniel Le Berre, président du jury :

  C’est un de nos plus vieux candidats puisqu’il a débuté dans les années 80, mais ce qui est intéressant c’est qu’on a une nouvelle génération de chercheurs qui le font évoluer, et ce qui a touché le jury c’est que ce logiciel, c’est un logiciel phare de la science française, mais cette nouvelle équipe, elle a une nouvelle façon de travailler, plus ouverte, plus “génie logiciel” que par le passé, et ils avaient écrit dans leur candidature qu’ils candidataient pour que cette approche soit validée et le jury a été touché par ça.

• Mon intervention, en tant que représentant de l’équipe Coq :

  Moi je n’étais pas né quand le logiciel a été créé, mais je représente aujourd’hui l’équipe de développement de l’assistant de preuve Coq, qui est un logiciel qui a toujours été développé avec une vision ouverte, car ça correspond à la manière dont la science se construit, et qui est distribué depuis plus de 20 ans sous une licence libre, mais en revanche ce qu’on soulignait tout à l’heure, c’est qu’au-delà de la licence libre, nous avons fait le choix depuis plus de 7 ans de chercher à ouvrir réellement le développement du logiciel pour impliquer davantage une communauté, qui est aujourd’hui une communauté mondiale. Le fait que l’équipe ait fait ce choix et ait organisé, par exemple, des journées lors desquelles l’équipe introduisait la base de code à des nouveaux contributeurs, et travaillé sur la documentation, à la fois la documentation technique mais aussi la documentation des processus de contribution, a fait qu’on a pu finalement augmenter très largement le nombre de personnes qui pouvaient contribuer à l’amélioration et à l’évolution de ce système, ce qui fait qu’on a aujourd’hui un nombre de contributeurs qui a très largement augmenté, disons pour vous donner une idée, qui a été multiplié par 4 dans les 5 dernières années, et on a aussi beaucoup plus de personnes qui sont impliquées dans la maintenance au jour le jour.

Puisque Daniel Le Berre mentionnait que le jury avait été touché par notre dossier de candidature, en voici le contenu ci-dessous, à commencer par la motivation de la candidature, dans laquelle nous expliquons ce que ce prix représente pour nous :

Motivation de la candidature

Coq est un logiciel de recherche développé depuis plus de 35 ans. Déjà récipiendaire du prix ACM Software System Award en 2013, sa réputation n’est plus à faire. Cependant, beaucoup d’efforts ont été effectués ces dernières années pour améliorer et ouvrir ses pratiques de développement. Les changements effectués entre 2015 et 2019 (passage à GitHub pour les pull requests puis les issues, adoption d’intégration continue et test avec des dépendances inverses, introduction d’un guide de contribution, documentation systématique des fonctionnalités introduites ou modifiées, extension de l’équipe des mainteneurs participants à l’intégration des changements, passage à des cycles de version plus courts, amélioration de la maintenance des paquets au niveau de l’écosystème) sont décrits en détail dans la thèse de Théo Zimmermann. D’autres changements ont été encore conduits depuis, comme la restructuration du manuel de référence et l’amélioration de son contenu, ou encore l’introduction de la Plateforme Coq, permettant de faciliter l’installation de Coq et de paquets standard de son écosystème, et de nouvelles plateformes de discussion telles que Zulip. Alors que le prix ACM Software System Award avait récompensé les développeurs initiaux de Coq, l’obtention du prix Science Ouverte du Logiciel de Recherche récompenserait les efforts de la nouvelle génération de développeurs et mainteneurs de Coq qui ont contribué à véritablement ouvrir ce logiciel et à développer sa communauté et son écosystème.

Diffusion

Les nouvelles versions de Coq sont publiées sur le dépôt GitHub, sous forme de code source. Elles sont ensuite rendues disponibles dans de nombreux systèmes de paquets (opam, Nix, Homebrew, distributions Linux). Voir : https://repology.org/project/coq/versions.

Désormais, la Plateforme Coq est la méthode recommandée d’installation de Coq, car elle permet de plus facilement avoir accès à Coq ainsi qu’à un ensemble de paquets standard de l’écosystème. Elle comporte un mode “débutant” basé sur des installateurs binaires pour Windows, macOS et Linux (Snap) et un mode “avancé” basé sur un script interactif faisant appel à opam de manière sous-jacente.

Éléments scientifiques et techniques

Dimension scientifique

L’assistant de preuve Coq s’appuie sur des décennies de recherche active dans diverses équipes, en France et à travers le monde. La page https://coq.inria.fr/refman/history.html contient une description détaillée des racines de ces recherches. Aujourd’hui, Coq est à la fois un objet d’étude (nouveaux développements théoriques permettant des évolutions) et un support à la recherche en mathématiques formalisées et vérification de logiciel. Le survey “QED at Large” décrit les nombreuses avancées scientifiques ayant eu lieu pour permettre la vérification de logiciel à l’aide d’assistants de preuve tels que Coq.

Le nombre d’articles de recherche publiés s’appuyant sur Coq est trop grand pour en faire une liste exhaustive. Pour donner un ordre de grandeur, la recherche de “Coq proof” sur Google Scholar conduit à l’obtention de plus de 30 000 résultats (en vérifiant les 10 premières pages, on constate que tous les résultats sont pertinents). Des requêtes similaires sur d’autres bases de données (Scopus, ACM DL, Inspec) donnent chacune plusieurs milliers de résultats. Le Coq’Art, le tout premier livre sur Coq, a été cité plus de 2500 fois.

Par ailleurs, Coq a été une source d’inspiration pour plusieurs autres assistants de preuve, notamment Lego, Matita et Lean, tous basés sur le Calcul des Constructions Inductives, théorie sous-jacente au logiciel Coq.

Dimension technique

Le développement de Coq a posé de nombreux défis techniques, au-delà des fondements scientifiques et théoriques sur lesquels le logiciel repose, notamment car il ne se limite pas à son noyau, composant logique permettant de vérifier les preuves. La partie “assistant” du logiciel représente une partie essentielle de la complexité du système. Un enjeu technique majeur actuel est de permettre de continuer à faire évoluer le logiciel tout en assurant les besoins en termes de stabilité des utilisateurs majeurs. Pour permettre de mieux évaluer en pratique l’impact d’un changement en termes de compatibilité, des tests avec des projets externes dépendants de Coq sont effectués de manière systématique. Lorsqu’un changement casse la compatibilité mais est jugé nécessaire, les développeurs de Coq réparent les projets externes inclus dans les tests afin de pouvoir continuer à les utiliser dans les futurs tests de compatibilité. Dans le même temps, de nombreux efforts ont été effectués pour retirer de la dette technique, accumulée au cours du temps par l’ajout de fonctionnalités expérimentales, dues à la nature de logiciel de recherche de Coq. Ces efforts permettent d’envisager les évolutions futures du logiciel de manière plus sereine.

Dimension génie logiciel

L’architecture de Coq est découpée en de nombreux composants qui dépendent les uns des autres, à commencer par un noyau, bien délimité, qui a pour tâche de vérifier les preuves. Grâce à cette architecture, classique parmi les assistants de preuve modernes, tout bug en dehors du noyau n’est pas en mesure d’affecter la confiance que les utilisateurs peuvent accorder au système. Coq dispose par ailleurs d’un système de plugins permettant d’étendre le système (sans perte de confiance) et un certain nombre de composants cœur se présentent d’ailleurs sous cette forme.

Comme précisé dans les motivations de la candidature, le développement de Coq a beaucoup évolué au cours des six dernières années. Développé depuis 1999 dans un dépôt SVN, git et GitHub ont été adoptés, d’abord pour permettre de faciliter les contributions extérieures. À partir de 2016, les pull requests ont été également adoptées au sein de l’équipe cœur pour permettre la revue de code. Par la suite, les issues de GitHub ont également été adoptées, ce qui a donné lieu a une publication évaluant l’impact d’un tel changement. Le passage à l’utilisation systématique de pull requests a permis de systématiser la mise à jour de la documentation et le test. Ce dernier repose sur un système d’intégration continue incluant des tests de régression et des tests de compatibilité avec des projets dépendant de Coq (plusieurs millions de lignes de code sont ainsi testées pour chaque changement). Le processus de sortie de nouvelles versions a également évolué pour permettre de produire de nouvelles versions de manière plus rapide. Les branches stables sont maintenues par des “release managers”, qui “backportent” les correctifs, aidés par un système semi-automatique. Un bot interagit avec les développeurs pour les aider dans leurs tâches répétitives. Tous ces changements sont décrits en détails dans la thèse de Théo Zimmermann.

Documentation

Qualité de la documentation pour les utilisateurs

Un frein au développement de l’utilisation de Coq a longtemps été le manque de documentation, les utilisateurs devant apprendre à utiliser le logiciel au contact d’autres utilisateurs ou de développeurs. Ce problème a été levé à partir de la publication en 2004 du premier livre sur Coq, le Coq’Art (édité par Springer en anglais mais également disponible gratuitement en version française, et depuis 2009 en chinois). Par la suite, de nombreux autres livres ont été écrits sur Coq (la page de documentation de Coq en référence près d’une dizaine), notamment le très célèbre Software Foundations de Benjamin Pierce et al., aujourd’hui largement utilisé par les nouveaux utilisateurs, et qui a également été traduit en chinois. Il existe également un livre sur Coq écrit en japonais (par Manabu Hagiwara et Reynald Affeldt).

L’équipe de développement de Coq maintient quant à elle le manuel de référence et la documentation de la bibliothèque standard. Un accent particulier a été mis ces dernières années sur l’amélioration de la qualité (exhaustivité, exactitude, accessibilité) du manuel de référence. Tout d’abord, celui-ci a été converti de LaTeX vers Sphinx (étendu pour les besoins de Coq) grâce à un effort collaboratif de la communauté. Le manuel contient de nombreux exemples de code, qui sont exécutés et qui font échouer la compilation s’ils déclenchent des avertissements ou message d’erreurs inattendus. Le langage de Coq ayant une grammaire très étendue (la plupart des commandes et des tactiques sont accessibles sous forme de syntaxe), un outil a été développé pour mettre en relation la grammaire telle que définie dans le parser et telle que documentée dans le manuel de référence. Une restructuration majeure du manuel de référence a également été entreprise pour organiser le matériel qui y avait été ajouté de manière organique.

Qualité de la documentation pour les développeurs et contributeurs

La documentation interne du code de Coq s’est longtemps limitée à quelques commentaires décrivant les fonctions exportées dans les fichiers sources. Cette documentation a été complétée par des documents décrivant l’implémentation de certaines parties du logiciel, des introductions à l’architecture de Coq, présentées sous forme de diaporamas lors d’évènements (Coq Users and Developers Workshops) destinés depuis 2015 à faciliter les contributions d’utilisateurs au code de Coq. Un tutoriel pour les auteurs de plugin a également été créé à cette occasion et est maintenu dans le dépôt de Coq. Enfin, un guide de contribution très complet a été rédigé pour permettre d’intégrer et de former de nouveaux contributeurs en leur exposant une progression à travers différents types de contributions, à commencer par des contributions à l’écosystème, à la gestion des tickets, pour continuer avec des contributions de code et de la maintenance. Ce guide de contribution a également pour but de servir de documentation de référence des processus établis dans l’équipe de développement de Coq, et sert par conséquent également aux contributeurs déjà bien établis.

Communauté

Quels sont les utilisateurs actuels du logiciel ?

Coq est utilisé par une très large communauté, dont la taille est difficile à évaluer du fait que ni le logiciel, ni le site web n’incluent de traceurs pour en mesurer l’audience. Il est en revanche incontestable que Coq est aujourd’hui l’un des logiciels de référence dans son domaine (les assistants de preuve), domaine qui est lui-même en forte croissance. Bien que peu fiable comme mesure de popularité, le nombre d’étoiles attribué à Coq sur GitHub (qui s’élève à 3 500) en fait l’assistant de preuve le plus populaire sur GitHub, ainsi que le logiciel le plus populaire listé sur code.gouv.fr (d’une courte tête devant OCaml, le langage dans lequel Coq est écrit). Coq est utilisé avant tout par des chercheurs pour des projets de taille de plus en plus impressionnante (le compilateur certifié C CompCert, le projet DeepSpec financé à auteur de 30 millions de dollars par la NSF) mais aussi par des industriels de plus en plus nombreux. Les utilisateurs industriels incluent de nombreuses start-ups de blockchain, à commencer par la française Nomadic Labs, qui développe la blockchain Tezos, d’autres types de start-ups comme l’espagnole Formal Vindications, qui vérifie des logiciels légaux, des entreprises américaines de conseil telles que Galois et Bedrock Systems, mais aussi de plus grosses entreprises telles qu’Amazon, Apple, Google, IBM. La page https://github.com/ligurio/practical-fm liste près d’une vingtaine d’entreprises qui utiliseraient Coq. La publication en 2020 par l’ANSSI d’un guide sur l’utilisation de Coq dans le contexte de certifications Critères Communs atteste de l’importance de ce logiciel pour le secteur industriel.

Animation de la communauté des utilisateurs et des contributeurs

Coq dispose de nombreux canaux de communication pour les utilisateurs (https://coq.inria.fr/community) : une liste de diffusion historique encore très active, récemment complétée par un forum Discourse, un système de messagerie instantanée Zulip avec plus d’un millier d’inscrits (un canal IRC non-officiel existe également sur Libera.Chat), un compte Twitter. Deux workshops annuels sont organisés à l’occasion de conférences majeures en informatique (CoqPL, associé à POPL, et le workshop Coq, associé à ITP / IJCAR / FLOC). Des workshops spécifiques destinés à des sous-communautés de l’écosystème Coq, ainsi que des écoles, sont également régulièrement organisés (https://coq.inria.fr/community).

Les canaux précédemment mentionnés sont également utilisés pour les contributeurs, complétés par le dépôt GitHub et un workshop annuel (Coq Users and Developers Workshop) destiné à aider les utilisateurs à devenir des contributeurs. Les développeurs se réunissent en vidéo-conférence une fois par semaine, et cette réunion est ouverte à tous. Les noms des contributeurs et des mainteneurs sont mis en avant dans les notes de nouvelles versions. L’utilisation d’équipes de mainteneurs combinée avec le système de CODEOWNERS de GitHub a permis d’élargir le nombre de mainteneurs participant à l’intégration des modifications à une trentaine de contributeurs réguliers (contre moins d’une dizaine de développeurs de l’équipe cœur auparavant), ce qui permet de traiter plus efficacement le nombre important de pull requests (créées par plus de 200 contributeurs, d’après le décompte de GitHub). Un système de Coq Enhancement Proposals permet de discuter certaines propositions de changements majeurs avant leur implémentation.

Écosystème

Coq dispose d’un écosystème très riche de paquets qui en étendent les capacités : plugins qui se connectent à l’API OCaml de Coq pour proposer des extensions de fonctionnalités, bibliothèques Coq réutilisables qui développent des applications particulières. Historiquement, ces “contributions” étaient distribuées avec Coq, par l’équipe de développement. À partir de 2013, des utilisateurs et développeurs de Coq ont étudié la possibilité de distribuer ces contributions à travers un index et un gestionnaire de paquets. Il a été décidé de réutiliser opam, qui avait été développé pour le langage OCaml, et l’index des paquets Coq existe depuis fin 2014. Depuis quelques années, de plus en plus de ces paquets Coq sont également disponibles à travers le gestionnaire de paquets générique Nix. Enfin, depuis 2018, une organisation communautaire destinée à assurer la maintenance à long terme des paquets importants de l’écosystème a été formée. Cette organisation permet la maintenance de plus de 50 paquets par plus de 30 mainteneurs, mais aussi la création d’outils pour l’aide à la maintenance, et la diffusion de bonnes pratiques (dans tout l’écosystème Coq). Cette organisation est basée sur un modèle qui a émergé dans plusieurs autres écosystèmes logiciels et qui fait actuellement l’objet de recherches. La plupart des paquets Coq sont disponibles sous licence libre. L’organisation coq-community n’accueille que du logiciel libre.

À noter que vous pourrez également retrouver la notice sur la Publication en Libre Accès (Open Access), par Pablo Rauzy, sur le site de ce dernier.

Crowdsourcing

Voir aussi : Concours d’innovation, Crowdfunding ou financement participatif, Économie collaborative, Innovation ouverte, Plateforme collaborative, Production de pair à pair, Wikipédia

Définition de la notion

Le crowdsourcing (ou externalisation ouverte) est une pratique apparue avec le Web, dit 2.0, par laquelle un problème est confié à une communauté d’internautes dont le travail consolidé permet d’y apporter une solution.

Le terme crowdsourcing est d’apparition récente mais est aussi très utilisé, ce qui peut expliquer qu’il possède une définition assez changeante, selon les sources. Estellés-Arolas et González-Ladrón-de-Guevara (2012) proposent d’intégrer les différentes définitions qu’on peut trouver dans les publications académiques en identifiant les caractéristiques essentielles du crowdsourcing :

• c’est un « appel » plus ou moins ouvert,
• à une « foule »,
• qui se fait par le biais d’un processus participatif,
• utilisant Internet.
• Il sert à résoudre une tâche bien définie,
• proposée par un individu, une organisation ou une entreprise,
• qui tire parti du processus le plus souvent en recevant la solution à son problème.
• La foule aussi reçoit une récompense ou tire parti de son travail.

Le néologisme est attribué à Jeff Howe et Mark Robinson, rédacteurs à Wired magazine, qui l’ont construit sur la base de outsourcing. Ainsi, dans son acception première, il exprime une forme d’externalisation. Il aurait été inventé en 2005 et publié pour la première fois en juin 2006. L’observation des courbes d’intérêt pour la recherche de ce mot sur Google, à l’aide de Google Trends, montre bien une apparition à cette date et une augmentation croissante depuis. De manière intéressante, le terme crowdfunding qui n’est finalement qu’un avatar bien particulier de crowdsourcing, n’apparaît qu’en juillet 2010 mais prend une toute autre ampleur en supplantant, dès mars 2012, le crowdsourcing dans les recherches des internautes et en continuant à s’envoler depuis (à ce sujet, voir la rubrique sur le financement participatif).

Exemples de mise en application de la notion

De nombreuses applications ont été qualifiées de crowdsourcing. Si on accepte les différentes caractéristiques qu’on vient de lister, certains de ces exemples doivent néanmoins être disqualifiés.

L’encyclopédie collaborative Wikipédia, en particulier, ne tient pas dans les limites restrictives du crowdsourcing. En effet, personne en particulier n’est à l’origine de l’appel à la foule. Quant à la tâche, bien définie, de construire une encyclopédie, elle est sans fin.

À l’inverse, le service Amazon Mechanical Turk, réunit toutes ces caractéristiques et est d’ailleurs régulièrement cité comme l’exemple paroxystique de crowdsourcing. Ce service propose à n’importe qui de donner des tâches à des « travailleurs du web » en échange de « micro-paiements ». Avec ce service, la personne à l’origine de l’appel à la foule se charge de fusionner les données obtenues de la manière pertinente.

InnoCentive est une plate-forme d’innovation ouverte, étudiée entre autres par Isabelle Liotard et Véronique Revest (2015). Bien que répondant à la définition du crowdsourcing, elle présente la caractéristique particulière que seule la meilleure solution proposée par la foule est retenue.

Le site Duolingo était à l’origine un exemple de crowdsourcing où la foule reçoit une récompense autre que monétaire, en l’occurrence un service d’apprentissage de langues étrangères gratuit. Un des exercices proposés aux apprenants avancés, appelé « immersion », consistait à traduire des textes complets (de la langue apprise vers la langue maternelle). Le travail collaboratif des apprenants permettait d’obtenir des traductions de documents fournis par les clients de l’entreprise, que Duolingo estimait de qualité professionnelle.²

Par ailleurs, il existe de nombreuses plateformes de crowdscience (plus souvent désignée sous les termes « sciences participatives » ou « sciences citoyennes »), sur lesquelles les internautes jouent et contribuent en même temps à l’avancement de la recherche (l’exemple le plus connu est FoldIt http://fold.it mais on peut aussi citer Phylo DNA Puzzles http://phylo.cs.mcgill.ca/, Galaxy Zoo http://www.galaxyzoo.org…).

Enfin, reCaptcha est un service de crowdsourcing « forcé » (ou crowdsourcing implicite). Le service, possédé depuis 2009 par Google, permet de vérifier que les internautes ne sont pas des robots lors de l’inscription à divers sites (il s’agit de la requête faite à chaque utilisateur de retranscrire des lettres ou des chiffres qui apparaissent de façon tordue³), tout en fournissant à l’entreprise des données utiles à la reconnaissance de caractères ou d’images. Une pratique proche, de la part de certaines entreprises ayant un très grand nombre d’utilisateurs telles que Facebook, consiste à se servir des données récoltées sur le comportement des utilisateurs pour conduire des études et éventuellement en tirer des bénéfices. Cette pratique a été qualifiée de piggyback crowdsourcing par Doan et al. (2011) mais elle ne respecte pas la définition du crowdsourcing présentée ici.

Régime juridique du crowdsourcing

Chaque forme de crowdsourcing fonctionnant autour d’une plateforme (voir la rubrique sur les plateformes collaboratives), c’est l’entreprise ou l’organisation qui la possède qui fixe les règles, étant entendu que le choix de ces règles participe au succès ou à l’échec de la plateforme. Selon les types de tâches, les considérations juridiques peuvent d’ailleurs varier grandement.

D’une part, certains systèmes visent à récolter de la connaissance pure ou des données brutes, que la personne à l’origine de l’appel à la foule peut alors utiliser à sa guise, sans prendre la peine de les protéger, car elle sera seule à les posséder toutes (les contributeurs ne voient la plupart du temps que leurs propres contributions). Ce sera le cas de systèmes comme reCaptcha ou de ceux visant à recueillir les préférences de consommateurs.

D’autre part, la foule peut être co-créatrice de procédés brevetables ou de réalisations protégées par le droit d’auteur, comme dans les cas d’InnoCentive ou de Duolingo. La plate-forme se protège alors par des conditions générales d’utilisation précisant les conditions dans lesquelles les contributeurs lui cèdent leurs droits. Dans le cas d’InnoCentive, cela va même plus loin puisque ceux qui répondent à un appel signent aussi, bien souvent, des accords de confidentialité.

Enfin, certaines plateformes, se situant nettement dans le domaine des communs, rendent à la foule sa création, que ce soit par l’utilisation de licences libres (comme sur Wikipédia), ou par le partage des connaissances obtenues (comme dans le cas des sciences citoyennes).

Modèle économique du crowdsourcing

Le crowdsourcing peut être vu comme une forme d’économie collaborative. Comme souvent dans ce type d’économie, il met en jeu trois types d’acteurs : les demandeurs de service, les fournisseurs de service qui sont en grand nombre (la foule) et une plateforme d’intermédiation. La particularité du crowdsourcing comparé à d’autres formes d’économie collaborative est que les demandeurs sont bien moins nombreux que les fournisseurs de service. Les mêmes questions éthiques, juridiques et sociales se posent néanmoins sur les conditions de travail des contributeurs (considérés comme indépendants) et le niveau de leur rémunération. Elles sont extrêmement pertinentes pour les plateformes comme Amazon Mechanical Turk, où les travailleurs sont rémunérés mais très faiblement. Elles se posent moins lorsque les contributeurs participent gratuitement et volontairement (comme sur Duolingo) ou que l’appel à la foule prend la forme d’un concours dont le vainqueur seul est très bien récompensé (cas d’InnoCentive).

La faiblesse du coût du travail dans ce type d’économie explique que le crowdsourcing soit souvent présenté dans le monde des affaires comme une technique d’externalisation très rentable. Elle dépend cependant du succès très incertain de l’appel à la foule. L’intermédiaire fournit parfois alors une forte valeur ajoutée. Par conséquent, le coût d’utilisation de la plateforme peut représenter une part plus importante que le coût de la main d’œuvre. Ce sera évidemment le cas avec l’intermédiaire Duolingo, rémunéré par ses clients et ne reversant rien directement à ses utilisateurs, mais dont le service d’apprentissage des langues, très sophistiqué, permet d’attirer un nombre d’utilisateurs important et représente un coût d’investissement élevé pour l’entreprise.

Considérations techniques sur le crowdsourcing

Du point de vue technique, le crowdsourcing est une forme de calcul distribué où les éléments du réseau vers qui on distribue des tâches sont humains au lieu d’être des machines. Cependant, les mêmes considérations s’appliquent : comment décomposer la tâche ? Comment répartir les sous-tâches obtenues ? Et comment combiner les réponses in fine ? Certains types de tâches se décomposent puis se recomposent très bien (et ces deux étapes peuvent alors être gérées automatiquement par une machine). Ce sera notamment le cas de la production de données, par exemple l’annotation de corpus destinés à entraîner des algorithmes d’intelligence artificielle. Dans ce cas, les contributeurs travaillent de manière complètement indépendante les uns des autres. Globalement, on assiste à un type de collaboration homme-machine où, à l’inverse du modèle traditionnel, l’homme se charge de tâches que la machine lui a déléguées.

D’autres tâches, plus dures à décomposer et recomposer, nécessitent une communication entre les membres de la foule (qui finalement se charge aussi des étapes de décomposition et recomposition) : soit chacun propose sa propre solution mais en s’inspirant de ce que font les autres, soit tout le monde travaille sur une solution commune. Ce sera notamment le cas avec Duolingo et Wikipédia.

Distinction avec les notions voisines

La notion de crowdsourcing est à distinguer principalement de celle de production de pair-à-pair. Les deux sont rendues faciles grâce à internet et les deux proposent des formes de collaboration. Cependant, alors que la production pair-à-pair, souvent décentralisée, met l’accent sur le reversement du résultat obtenu dans les communs (les contributeurs sont récompensés de leur travail par le résultat obtenu de manière collaborative), le crowdsourcing est centralisé et asymétrique : les trois acteurs précédemment mentionnés jouent des rôles spécifiques et tirent des avantages distincts de leur interaction. Wikipédia et les logiciels libres sont donc des exemples de production pair-à-pair et non de crowdsourcing.

Bien que nous n’en parlions que très succinctement dans cette notice, le crowdsourcing n’est à distinguer du crowdfunding (ou plutôt financement participatif) qu’en ce que le deuxième est une espèce très particulière du premier. En effet, on retrouve dans le financement participatif les trois types d’acteurs et toutes les caractéristiques précédemment cités. Mais plutôt que de contribuer avec son intelligence, la foule contribue avec son argent. Cela implique des considérations bien différentes qui sont spécifiquement traitées dans la rubrique sur le sujet.

Pertinence comme modèle de communs

Le crowdsourcing est un processus participatif. En cela, il partage de nombreux traits avec d’autres processus à l’origine de nouveaux communs informationnels : une certaine ouverture, l’usage d’Internet et d’une communauté de contributeurs. Par conséquent, certains auteurs assimilent volontiers ces processus au terme, à la mode, de crowdsourcing, entretenant par là une certaine confusion et laissant croire que le crowdsourcing appartient systématiquement au domaine des communs.

En fait, cela dépend grandement de la politique choisie par la plate-forme de crowdsourcing. Dans le cas d’Amazon Mechanical Turk ou d’InnoCentive, la personne à l’origine de l’appel à la foule et payant le service récupère tous les droits sur les résultats. Souvent ces résultats ne seront même pas rendus publics. Cette privatisation du travail collectif se justifie juridiquement et moralement par le fait que les contributeurs sont rémunérés.

Au contraire, dans le cas de reCaptcha, les contributeurs ne sont ni volontaires, ni rémunérés. Si le but initial de reCaptcha (aider à la numérisation du patrimoine littéraire de l’humanité) allait effectivement dans le sens des communs, le service a ensuite servi à améliorer Google Street Maps et à entraîner divers algorithmes d’intelligence artificielle de Google. Ces deux derniers bénéfices ne seront pas reversés dans les communs mais profiteront aux contributeurs seulement s’ils utilisent les services de Google.

Similairement, Duolingo se situait, avec son service de traduction, à la frontière entre privatisation du travail gratuit des utilisateurs (justifié par le service d’apprentissage de langue fourni par la plateforme) et contribution aux communs. En effet, les documents qui étaient soumis aux apprenants pour traduction avaient deux origines : soit ils provenaient des clients de Duolingo, qui récupéraient alors le copyright sur le résultat de la traduction, soit il s’agissait de documents sous licence Creative Commons soumis par n’importe quel utilisateur (la traduction étant alors gratuite et reversée dans le commun).

Finalement, les projets de sciences citoyennes s’inscrivent de manière évidente dans le domaine des communs. Les données initiales et produites sont généralement intégralement publiques. De plus, le travail des contributeurs sert à enrichir le commun de la connaissance scientifique, bien que se pose alors de manière aiguë la question de l’accès aux résultats de la recherche (cf. la rubrique sur l’open access).

Repères bibliographiques

• Doan A., Ramakrishnan R. et Halevy A., « Crowdsourcing systems on the World-Wide Web », Communications of the ACM, 2011, n° 4, pp. 86-96. [PDF]
• Estellés-arolas E. et González-Ladrón-de-Guevara F., « Towards an integrated crowdsourcing definition », Journal of Information Science, 2012, n° 2, pp. 189-200. [PDF]
• Liotard I. et Revest V., « InnoCentive : un modèle hybride d’innovation basé sur l’innovation ouverte », Le Retour des communs, Les Liens qui Libèrent, 2015, pp. 151-169. [PDF]

Sauf qu’il serait tout à fait naïf de se contenter de rejeter en bloc le vote électronique, car celui-ci est déjà partout : élections professionnelles, associatives… et même certaines élections politiques. De plus, de nombreux politiciens défendent désormais une généralisation du vote électronique, notamment en vue d’améliorer le taux de participation. Ne nous voilons donc pas la face et analysons quels sont les risques et les bénéfices induits par ce mode de scrutin. Ou plutôt devrions-nous dire ces modes de scrutins. Le vote électronique peut être de deux natures, bien différentes : machines de vote ou vote par internet. Nous traiterons ici des deux mais en prenant soin de distinguer les enjeux.

Continuez à lire cet article sur Kinea, le magazine plurilingue sur lequel il a été publié…

On peut tout de même faire des hypothèses sur les raisons de cette crise et je me permettrai d’en faire une. Les régimes démocratiques et les contextes sont bien différents d’un pays à l’autre. Qu’est-ce qui a changé partout à la fois pour provoquer cette crise généralisée ? L’une des nouveautés est l’apparition et la démocratisation d’internet, du web plus précisément, et, à travers ce biais, d’une multiplicité des sources d’information. Nos représentant.e.s ne sont peut-être pas moins bon.ne.s qu’avant mais ils/elles le paraissent car nous avons plus de moyens de nous informer sur leurs travers et le mécontentement se répand plus facilement.

Nous pouvons donc aujourd’hui prendre la mesure des limites de nos systèmes de démocratie représentative et c’est une raison bien suffisante pour souhaiter les rendre meilleurs. Peut-être l’outil qui aura permis de percer à jour les limites du système sera-t-il également utile pour en proposer un nouveau ?

C’est ce que pensent aujourd’hui beaucoup de gens : ceux/celles qui défendent la mobilisation citoyenne en ligne (par exemple Avaaz), ceux/celles qui testent la démocratie participative ou bien sont les chantres de l’open government ou de la démocratie ouverte. Et grâce à ces gens les choses avancent en effet : les mobilisations en ligne organisées par Avaaz et d’autres associations ont parfois des retombées très fortes ; le budget participatif mis en place par la maire de Paris a joui d’un grand succès ; la plate-forme Parlement & Citoyens a déjà attiré l’attention d’un grand nombre de parlementaires ; et pour la première fois en France, un projet de loi a été soumis aux amendements populaires avant son examen en Conseil des Ministres (loi sur la République Numérique).

Dans ce contexte, ce foisonnement d’idées, j’aurais tort de garder les miennes pour moi. Voici un projet qui me tourne dans la tête depuis déjà plus d’un an.

“Nul n’est censé ignorer la loi.” Ce principe de base, essentiel pour que la justice puisse fonctionner, est mis à mal, d’une part par la complexité des lois, d’autre part par la boulimie législative. Sans verser dans la pensée ultra-libérale qui consisterait à donner un grand coup de pied dans la fourmilière en supprimant, brutalement, 90% des textes de loi, on peut légitimement se demander si un peu de ménage ne serait pas nécessaire. C’est le constat qui est à la base de ce projet et c’est ce qui le distingue d’autres, plus courants, dont le but est d’inclure le/la citoyen.ne dans la préparation de nouvelles lois (toujours de nouvelles lois !).

Réapproprions-nous la loi !

La première étape, essentielle, c’est que nous soyons tous en mesure de comprendre la loi, au moins les textes qui nous concernent. Nombre de services de conseil juridique fleurissent sur le web. Certains sont très bien faits. Certains sont proposés par des associations, certains même le sont par l’État (Service-Public.fr). Cependant plutôt que de nous aider à comprendre la loi, ils nous aident à comprendre ce qu’il faut faire, ne pas faire, comment le faire. D’autre part, il y a Légifrance¹. Ce site permet de lire la loi, de comprendre comment elle est faite, mais pas ce qu’elle veut dire (dans cet esprit, voir aussi des initiatives privées telles que celle de Steeve Morin).

Pour que les citoyen.ne.s lisent enfin la loi lorsqu’ils/elles se posent des questions juridiques, mettons les explications en relation avec les textes ! Créons un outil (une plate-forme) qui permette d’une part de poser des questions juridiques et d’obtenir des réponses, par des gens qui se réfèrent aux textes, d’autre part de parcourir la loi et de voir, au fil du texte, les questions/réponses qui y ont été associées. Et qui permette, si un passage de la loi n’est pas clair et que rien n’y est encore associé, de le commenter…

Dépoussiérons la loi !

La suite vient d’elle-même. Si on s’amuse à parcourir la loi grâce à un outil bien fait, on tombera nécessairement sur des anachronismes (comme cette loi qui interdisait aux femmes de porter le pantalon et qui n’avait jamais été abrogée), on tombera sur des contradictions, ou on tombera sur des textes absurdes ou scandaleux. En effet, l’entretien n’a jamais été le fort des législat.eur/rice.s. On préfère s’assurer d’avoir une loi à son nom plutôt que d’abroger les lois datées. C’est donc aux citoyen.ne.s de s’emparer de cette tâche. Un outil bien pensé peut le permettre.

À la manière d’un wiki, on commencerait par rendre la loi “éditable”. Mais il est bien évidemment plus sensible de changer la loi que d’éditer une page d’encyclopédie. Il faudrait donc faire apparaître les modifications proposées par les citoyen.ne.s pour ce qu’elles sont : des propositions (on retrouve d’ailleurs une connexion avec l’outil commented.it). Notre outil pourrait facilement aller plus loin et générer automatiquement une proposition de loi correspondant à la modification (les propositions de loi ne sont jamais que des patchs, c’est-à-dire des descriptifs à apporter au code – code civil ou code source – pour passer de la version actuelle à la version proposée).

Promouvons les changements !

La première étape est rendue possible par la plate-forme et repose sur des initiatives individuelles, ainsi que des discussions de type commentaires. La seconde étape, plus délicate, consiste à vérifier si les propositions énoncées sont plébiscitées et éventuellement à les améliorer suite aux retours d’autres citoyen.ne.s, d’expert.e.s de la question traitée, et d’expert.e.s juridiques. À partir de là, plusieurs voies sont possibles.

Les voies du consensus sont les plus faciles à emprunter et pourraient être la priorité de la plate-forme : si la proposition est massivement rejetée, elle est enterrée ; si elle est massivement plébiscitée par les citoyen.ne.s utilisant la plate-forme, elle prend son envol.

C’est alors le rôle de l’association² soutenant la plate-forme que de lancer des enquêtes d’opinion pour évaluer si la proposition, largement soutenue par la communauté, est aussi largement soutenue chez les personnes qui n’ont pas rejoint le mouvement. Si c’est le cas et qu’il s’avère que la proposition est soutenue à l’échelle de la société toute entière, la dernière étape est celle du lobbying vis-à-vis des parlementaires pour faire inscrire la proposition de loi (toute prête) à l’agenda législatif et pour la faire voter. Cette étape ne sera sans doute pas la plus difficile : les grandes ONG sont déjà spécialistes de ce genre de choses et les parlementaires sont sensibles aux enquêtes d’opinion.

Organisons le débat

Il serait pour autant mesquin de se borner à traiter les propositions consensuelles (même si celles-ci doivent recevoir la priorité). Lorsqu’une proposition ne fait pas consensus, elle mérite un débat.

On dit que la démocratie directe ne marcherait pas parce que les sujets discutés au Parlement sont trop compliqués et demandent trop de préparation. En vrai, ils sont trop compliqués pour nos représentant.e.s qui, mal préparé.e.s, ne prennent même pas la peine de participer aux débats et font confiance au/à la seul.e spécialiste du sujet de leur groupe politique.

Un bon système démocratique laisserait débattre pour chaque sujet les milliers de vrai.e.s spécialistes qu’on peut trouver dans le pays, ensuite de quoi le peuple serait l’arbitre. Il y a, à mon avis, beaucoup à inventer pour organiser des débats sérieux, pendant lesquels les spécialistes ne s’écharperaient pas comme on le fait trop souvent en politique et ne chercheraient pas non plus à embobiner le public. Il y a un modèle à inventer pour que les contributions à haute valeur ajoutée aient de l’impact et que les mensonges et faux-arguments se retournent contre leurs auteur.e.s.

Ne passons pas à côté de la moitié des textes

La Constitution et la loi sont une chose mais beaucoup se décide également au niveau des décrets d’application, des ordonnances, des arrêtés locaux, de la réglementation européenne, des accords de branche, des traités internationaux. Tous les textes nous impactant méritent le même coup de projecteur, même s’il est clair que certains seront plus faciles à modifier que d’autres³.

Aujourd’hui les « solutions collaboratives » sont à la mode ainsi que « l’innovation ouverte » (et plus généralement ce qui est « ouvert »). Peut-on tout créer de manière collaborative ? Quand il s’agit de création artistique on est en droit d’en douter. Cependant on voit fleurir des initiatives s’engageant résolument dans cette direction.

Avec Jules Zimmermann, nous nous sommes posés la question, voilà maintenant un an, de savoir s’il était possible de créer un roman de manière entièrement collaborative (en excluant la collaboration à petite échelle de deux ou trois auteur·trice·s ou encore la collaboration limitée, où chacun·e écrit un chapitre). Nous n’avons pas encore la réponse.

Nous ne sommes pas les premiers à nous poser cette question, ce qui laisse penser que si une solution existe, elle n’est pas simple.

Solutions pour une collaboration massive (non littéraire)

Lorsqu’on observe le monde de la création collaborative, via internet, on rencontre deux modèles à succès. Tout d’abord il y a le logiciel libre, premier avatar dans l’histoire moderne de « l’ouvert » et du « collaboratif ». Le logiciel libre ne fournit pas un modèle universel de collaboration, chaque projet a le sien propre et la plupart ont d’ailleurs un modèle simple, celui où quelqu’un a tout fait dans son coin. Mais un certain modèle de collaboration pour le logiciel libre a la cote. Ce modèle, c’est celui de GitHub.

Le modèle de GitHub se décrit rapidement comme ceci : une petite équipe gère un dépôt ouvert contenant le code d’un logiciel libre. Des contributeur·trice·s extérieur·e·s soumettent des rapports de bug ainsi que des patchs. Sur GitHub, ces patchs prennent la forme de pull requests avec l’avantage qu’on peut très facilement observer les modifications proposées et en discuter (c’est certainement la clé du succès de cette plateforme, le principe de l’équipe cœur et des patchs lui étant antérieur).

L’autre modèle à succès de la collaboration massive, c’est celui de Wikipédia. Le principe du wiki est le plus simple qui soit : quiconque peut, à loisir, modifier une page quelconque de l’encyclopédie. Cependant, la clé du succès de ce modèle de collaboration réside dans le fait que l’historique des modifications est sauvegardé et que toute modification est réversible en un clic si elle s’avère inappropriée. Des modérateur·trice·s exercent donc un contrôle a posteriori, à l’aide d’outils spécialisés leur permettant de voir les modifications en temps réel. À cela on ajoutera que les pages les plus fréquemment vandalisées sont davantage protégées en y restreignant les droits de modifications aux utilisateur·trice·s enregistré·e·s, tout simplement.

Devant ces deux grands succès, on peut penser que l’une ou l’autre des solutions se transposera bien au cas de la création littéraire. Aucune modification ne devrait même être nécessaire, les deux permettant de travailler sur du texte (qu’est-ce qu’un code source sinon du texte). Voyons ce que ça a donné.

Le modèle de GitHub a bien été appliqué à l’écriture collaborative. À l’heure où j’écris ces lignes, 12 projets en rapport avec l’écriture sont mis en avant par GitHub (mise à jour : GitHub n’a jamais maintenu cette liste et a maintenant supprimé la page en question, d’où un lien vers Internet Archive). Sur ces projets, la plupart sont des tutoriels ou des manuels. Il s’avère que nous avons donc là un bon modèle, non seulement pour collaborer sur du code, mais aussi sur des tutoriels (de programmation soit dit en passant). Un seul projet sur douze est un roman mais quand on observe la page des contributions, on découvre le motif reconnaissable des projets reposant sur un seul homme : le premier contributeur (c’est-à-dire l’auteur) a écrit 100 000 lignes. Le second contributeur le plus prolifique a proposé deux modifications seulement, modifiant 10 lignes en tout.

On peut se dire que le modèle est le bon mais que l’outil est trop compliqué à utiliser pour des écrivain·e·s non-programmeur·se·s (ce qui expliquerait pourquoi tous les tutoriels ainsi écrits parlent de programmation). C’est le pari de Penflip, une copie de GitHub destinée aux écrivain·e·s. Ça a l’air plutôt réussi mais ça n’a pas l’air d’avoir donné lieu à une grande créativité jusqu’à présent.

Wikipédia étant un exemple réussi d’écriture collaborative, pourquoi ne pas faire un « wikiroman » ? Nombreux·ses sont ceux·lles qui y ont pensé. Le plus médiatique exemple a été celui lancé avec des roulements de tambours par la maison d’édition Penguins. Le projet, appelé « One million penguins », a été confié à un groupe d’étudiant·e·s chargé·e·s de le superviser. Hélas, la communication autour de ce projet a provoqué sa perte : les étudiant·e·s-éditeur·trice·s ont été débordé·e·s par le nombre de participant·e·s. De plus, en choisissant d’activer une modération a priori, l’équipe a tué l’idée géniale du wiki et s’est retrouvée avec le modèle précédent (celui de GitHub) dans un outil inadapté.

Solutions pour une collaboration restreinte

De l’autre côté du spectre des outils dits « collaboratifs » il y a Google Docs. Google Docs est un outil génial lorsque l’on veut collaborer sur un document avec relativement peu de monde. Il comporte deux modes principaux d’édition.

• Le mode Édition fonctionne sur le même principe que le wiki. On peut simplement faire ses modifications dans le corps du texte. Comme ce n’est pas prévu pour une collaboration massive, les outils pour contrôler l’historique des modifications et revenir à une version précédente, bien qu’existant, ne sont pas aussi accessibles et évidents à utiliser.
• Le mode Suggestion est inspiré du mode Révision ou Suivi des modifications qui existait dans Word depuis longtemps. Toute modification dans le corps du texte est traquée et marquée comme telle. À cela s’ajoute la possibilité de lancer une discussion à partir d’un commentaire ou d’une suggestion de modification.

Cette discussion en marge de la page, qui n’est rien d’autre que la note griffonnée depuis toujours dans un livre rendue sociale, est un concept qui a aussi pris récemment son essor. On la retrouve notamment chez Medium.com (chez qui les commentaires sont remplacés par des « notes » qui flottent à côté de chaque paragraphe¹). Cette fonctionnalité est d’ailleurs mise en avant comme « le mécanisme central de collaboration sur Medium ».

Solution pour une collaboration massive (littéraire)

Il n’y a plus qu’un pas à faire pour proposer un outil, s’inspirant de tous ces modes de collaboration mais différent, qui soit adapté à une collaboration massive sur un texte littéraire (mais pas que).

On décrira très succinctement cet outil auquel on a donné le nom de commented.it (et dont une version simplifiée se trouve sur la page de présentation du projet unkilodeplumes — mise à jour : le système n’est pas maintenu et n’est plus en démonstration sur ce site). Il consiste à faire figurer en parallèle le texte et une colonne de commentaires. Ces commentaires peuvent être associés à des propositions de modification (pendant des pull requests de GitHub). Comme dans Google Docs, ces modifications sont clairement marquées (suppressions barrées et surlignées de rouge, ajouts soulignés et surlignés de vert). Mais contrairement à Google Docs où ces modifications apparaissent directement dans le texte, il faut là cliquer pour les afficher. Ce choix permet la collaboration massive, quand un Google Doc deviendrait surchargé avec toutes les propositions de modification, d’auteur·trice·s différent·e·s, sans rapport les unes avec les autres. Comme sur Medium, les discussions ont lieu par « blocs » de texte, et sont donc liées au contexte. Enfin, on peut voter en faveur d’une modification. Un·e adminstrateur·trice de la page peut ensuite « valider » les propositions les plus populaires en les intégrant au texte.

De là à l’écriture collaborative d’un roman…

C’était là notre défi initial et nous n’y sommes pas encore. Si nous pensons que notre concept peut être utile dans ce but, il faudra noter que commented.it (que vous pouvez aussi prononcer comment-edit) ne fournit pas de modèle pour toutes les étapes de la création. Comme tous les autres outils dont j’ai parlé ici, il est bien adapté à l’édition collaborative d’un texte. Qui se charge de l’écriture d’un texte initial ?

Dans le cas des logiciels libres, tutoriels ou pages d’encyclopédie, c’est une personne seule qui commence le travail. Puis, des paragraphes sont ajoutés, ici et là. Est-ce que ça marcherait pour un roman, dont l’écriture est traditionnellement beaucoup plus linéaire ? Il faut expérimenter pour savoir. Mais même cette étape initiale d’écriture, nous aurions voulu la remplacer par un processus collaboratif, à savoir une « foire aux scenarii » puis une « foire aux textes », selon des modes et avec des outils qu’il reste à inventer…

La plus grande vulnérabilité est l’absence de garantie que l’expéditeur/trice est bien celui/celle indiqué-e. Exactement comme quand vous recevez une lettre par la Poste d’ailleurs, à moins que vous ne reconnaissiez l’écriture. La seconde vulnérabilité c’est que les mails sont a priori visibles par les acteurs qui les transmettent comme les cartes postales peuvent êtres lues par les facteurs.

Heureusement, il existe des mesures pour sécuriser ses mails. Ces techniques sont presque aussi vieilles que les mails eux-mêmes mais elles deviennent de plus en plus simples à mettre en place.

Dans ce billet, je vous propose de commencer très doucement : vous allez apprendre à vérifier que les mails que je vous envoie ont bien été écrits par moi. Ainsi, si un jour vous recevez un mail de moi vous disant que je suis coincé en Grèce et qu’il faut que vous me fassiez un virement sur un compte à l’étranger pour m’aider, il vous sera alors très simple de contrôler si oui ou non, je suis bien à l’origine du message.

Instructions si vous utilisez un webmail

(Si vous n’utilisez pas un webmail, sautez cette section.)

• Installez l’extension Mailvelope depuis le site officiel.
• Une fois l’installation terminée, une icône de cadenas est apparue dans votre navigateur. Cliquez dessus puis sur Options.

• Cliquez sur Importer les clés.
• Téléchargez ce fichier qui contient ma clé publique puis sélectionnez-le depuis l’interface de Mailvelope et validez en cliquant sur Importer.
• Ouvrez votre webmail. Si c’est autre chose que Gmail, Live ou Yahoo, il vous faudra probablement commencer par dire à Mailvelope de le reconnaître (en deux clics : depuis l’onglet de votre webmail, cliquez sur le cadenas de Mailvelope puis sur Ajouter) et éventuellement relancer votre navigateur.
• Cherchez un vieil e-mail signé de moi. Les mails signés sont facilement identifiables car ils commencent par la ligne :

-----BEGIN PGP SIGNED MESSAGE-----

Normalement, la seconde partie du message (la signature) est désormais recouverte d’un cachet. En cliquant dessus, la signature est vérifiée !

Désormais, vous pourrez facilement vérifier la signature des nouveaux mails que je vous envoie :)

Les cas problématiques

Mailvelope a été conçu pour rendre facile l’utilisation d’une technologie complexe. Hélas, les webmails ne lui rendent pas toujours la tâche facile.

Le problème PGP/MIME

Il existe deux types de signatures : dans le corps du message ou en pièce jointe. Mailvelope ne supporte que le premier type car il ne peut pas ouvrir vos pièces jointes. Or le second type est assez répandu. Dans mon cas, je fais attention d’envoyer des signatures du premier type le plus souvent possible.

Mais pour pouvoir signer des pièces jointes², seule la seconde solution fonctionne. Dans ce cas, vous ne pourrez pas vérifier la signature avec Mailvelope.

Des webmails trop malins

Lorsque vous incluez le texte des messages précédents dans votre réponse (ce qui est le comportement de la plupart des utilisateurs/trices), certains webmails tels que Gmail décident de masquer cette partie du mail. Le problème c’est que ce texte faisait intégralement partie du message et le masquer peut mener Mailvelope à être incapable de vérifier la signature, voire à penser que cette dernière est incorrecte.

De même, les messages avec du formatage sophistiqué (gras, italique, gros texte, tableaux) sont difficilement compatibles avec les signatures.

Ayez donc conscience que ce genre d’erreur peut se produire, tout en restant méfiant vis à vis des messages dont vous n’avez pas pu vérifier la signature (surtout s’ils vous demandent de faire une action risquée comme un transfert d’argent).

Dans mon cas, je fais attention à envoyer du texte non formaté et ne pas inclure les messages précédents dans mes réponses pour ne pas créer ces problèmes mais tout le monde ne fait pas comme moi.

Instructions si vous utilisez Thunderbird

(Si vous n’utilisez pas Thunderbird, sautez cette section.)

• Commencez par installer GPG³. Pour Windows, c’est ici (la version la plus légère Gpg4win-Vanilla suffit) et pour Linux, vous n’avez probablement rien à faire car le logiciel a de grandes chances d’être déjà installé.
• Dans le menu de Thunderbird, cliquez sur Modules complémentaires (peut se cacher dans le menu Outils dans certaines versions de Thunderbird).

• Dans la barre de recherche tapez “enigmail” et installez le module correspondant.
• Redémarrez Thunderbird comme suggéré.
• Au redémarrage, l’assistant de configuration d’Enigmail se lance. Il vous demande de choisir entre trois modes de configuration (débutant, avancé, expert). Sélectionnez expert (ne vous inquiétez pas, je vous guide).
• Sur l’écran suivant, cliquez sur le bouton Gestion de clefs (vous pourrez ensuite fermer l’assistant de configuration en cliquant sur Terminer).
• Téléchargez ce fichier qui contient ma clé publique puis sélectionnez-le depuis la fenêtre “Gestion de clef Enigmail” qui s’est ouverte (menu Fichier/Importer des clefs depuis un fichier).
• Cherchez un vieux mail signé que je vous ai envoyé. Vous reconnaitrez facilement les mails signés : un bandeau “Enigmail” apparait en haut de ces derniers.

Si vous avez correctement effectué l’étape précédente, le bandeau devrait être bleu-vert et indiquer “Signature correcte de …” probablement précédé de “NON CERTIFIÉE”.

Je vous expliquerai ce que veut dire “NON CERTIFIÉE” un autre jour. L’important est que la signature soit correcte. Vous pouvez d’ailleurs la vérifier en un clin d’oeil car si elle n’était pas correcte, le bandeau serait rouge.

Vous n’aurez plus jamais besoin d’importer ma clé. En revanche, si un autre de vos contacts décide de chiffrer ses mails et vous envoie sa clef, vous pourrez l’importer très facilement en ouvrant à nouveau la fenêtre “Gestion de clefs Enigmail”. Vous pouvez accéder à cette fenêtre à tout moment en ouvrant le menu de Thunderbird (sous-menu Enigmail/Gestion de clefs).

Instructions si vous avez sauté les deux sections précédentes

Si vous n’utilisez ni Thunderbird, ni un webmail, vous avez deux solutions :

1. Débrouillez-vous.
2. Installez Thunderbird et recommencez.

Aller plus loin

Si vous avez lu ce post jusqu’au bout, vous êtes désormais capables de vérifier la signature des mails que je vous envoie. Vous pourrez aussi facilement vérifier la signature d’autres personnes (à supposer que ces personnes signent leurs mails) en leur demandant leur clé publique.

Si vous souhaitez à votre tour signer vos mails, dites-le moi et je serai ravi d’écrire une suite à ce billet pour vous expliquer comment procéder.

En coulisses

La signature d’un message ne vous garantit pas seulement l’origine du destinataire. C’est un cachet qui vous assure que le message que vous lisez n’a pas été modifié.

Pour garantir qu’un document n’a pas été modifié, on utilise des fonctions à sens unique qui sont des fonctions mathématiques compliquées associant à tout texte de départ une courte “empreinte” (quasiment) unique. Il est concrètement impossible de reconstruire un texte à partir de son empreinte, le calcul ne peut se faire que dans l’autre sens : c’est pour ça que ces fonctions sont “à sens unique”.

Ces fonctions sont bien utiles pour d’autres applications : par exemple établir une antériorité. Vous publiez uniquement l’empreinte d’un texte détaillant votre découverte. Le jour où vous avez besoin de prouver que vous aviez fait cette découverte à telle date, vous révélez le contenu du texte et tout le monde peut alors calculer à nouveau son empreinte et constater qu’il s’agit bien de la même. En revanche, si vous ne changez ne serait-ce qu’une virgule au texte de départ, l’empreinte n’aura plus aucun rapport.

Dans le cas qui nous intéresse en revanche, ça ne suffit pas. Comment transmettre l’empreinte du message de façon sûre et en garantir l’origine ?

La solution repose sur la cryptographie dite asymétrique : l’expéditeur/trice dispose de deux clés qui sont liées entre elles : l’une est dite privée et seul-e l’expéditeur/trice en dispose. L’autre est dite publique et est distribuée le plus largement possible.

La clé privée permet de traduire l’empreinte du message en signature (le texte incompréhensible que vous voyez en bas du message). Quant à la clé publique, elle permet de traduire la signature en empreinte. Vérifier une signature consiste alors à comparer l’empreinte du message (facilement calculable) avec le résultat obtenu en déchiffrant la signature. Les deux doivent se correspondre exactement pour que la signature soit vérifiée.

Pour en savoir plus : “Signature numérique” sur Wikipédia.

Diffuser l’information

Si comme moi, vous signiez déjà vos mails, il est probable que très peu de vos contacts vérifiaient vos signatures. Or, dans ce billet, j’ai cherché à montrer que vérifier les mails signés est très simple, suffisamment simple pour que tout le monde le fasse.

Le problème actuel c’est que les explications sur les techniques de signature et de chiffrement vont toujours beaucoup trop loin, ce qui démotive la plupart des gens. Les signatures perdent cependant tout leur intérêt si personne ne les vérifie. Faisons donc en sorte que tous nos contacts se mettent à vérifier nos signatures. Par ailleurs, certains pourraient finir par avoir envie de signer leurs mails à leur tour et nous répandrons ainsi cette pratique.

N’hésitez donc pas à adapter et reblogger ce billet (en particulier, en mettant un lien vers votre propre clé publique à la place de la mienne). Comme d’habitude, il est sous licence CC-BY et c’est aussi le cas des captures d’écran qui l’accompagnent.

Qu’est-ce qu’un isomorphisme ?

La (courte) page Wikipédia traitant du sujet nous rappelle la définition usuelle :

Un isomorphisme entre deux ensembles structurés est une application bijective qui préserve la structure et dont la réciproque préserve aussi la structure.

En pratique, cette notion nous était généralement présentée en cours de mathématiques sur des exemples. Un isomorphisme de groupe par exemple est un morphisme bijectif (où dans ce cas précis morphisme signifie une application envoyant l’élément neutre sur l’élément neutre et le “produit” de deux éléments sur le “produit” de leurs images).

La notion admet une définition générale grâce à la notion sous-jacente de structure mathématique, c’est-à-dire un ensemble muni d’un certain nombre de relations et d’axiomes décrivant les propriétés de ces relations (cette notion s’apparente à celle de théorie). On dispose alors d’une structure concrète (ou modèle) lorsque l’on connait l’ensemble sous-jacent, l’on est capable de définir les relations et de démontrer les axiomes.

On peut voir le rapport avec le besoin d’abstraction en programmation. La notion de signature en OCaml (ou d’interface en Java) correspond à celle de structure et son implémentation en termes de modules (respectivement en classes) correspond à la concrétisation.

À quoi sert ce genre d’abstraction ?

L’un de l’intérêt de l’abstraction est de simplifier et généraliser les raisonnements. On voit aussi qu’il peut exister plusieurs modèles pour une même structure. On pourra ainsi démontrer un théorème portant sur les groupes, en toute généralité, i.e. en ne se servant que des axiomes. Quel est alors l’intérêt de transférer des théorèmes d’une structure concrète à l’autre (ce qui est une technique différente) ?

Parfois, on peut préférer une structure concrète à une autre car ses propriétés spécifiques rendent les raisonnements plus faciles. Pour reprendre l’exemple des matrices, il est drôlement plus facile de faire un produit de matrices plutôt que de composer “à la main” les applications linéaires correspondant. Les démonstrations de certains théorèmes se font donc non pas sur la base des axiomes uniquement mais sur la base des connaissances supplémentaires dont on dispose.

Deux ensembles ayant la même structure ne sont pas nécessairement isomorphes. Il existe par exemple toutes sortes de groupes : certains finis, d’autres infinis ; pour certains l’opération commute (groupe Abéliens), pour d’autres non. Montrer alors un théorème pour un de ces ensembles ne permet pas nécessairement de le transférer à tous les autres. On pourra le faire si on peut identifier les deux structures à l’aide d’un isomorphisme.

Le (la) mathématicien-ne va donc s’employer à chercher un isomorphisme. Lorsqu’il (elle) l’a trouvé et l’a démontré, il (elle) prend alors un air solennel et déclare “nous pouvons identifier les deux structures donc les théorèmes que nous avions démontré pour l’une sont valables pour l’autre”.

Qu’est-ce que ça veut dire ?

C’est la justification de cette déclaration qui m’intéresse ici car mon but est de pouvoir la donner à un ordinateur. Les ordinateurs n’apprécient guère les déclarations solennelles.

Wikipédia ne m’aidera pas dans ma quête. En effet, voici ce qu’on y lit :

Savoir que deux objets sont isomorphes présente un grand intérêt car cela permet de transposer des résultats et propriétés démontrés de l'un à l'autre.

Selon certains points de vue, deux objets isomorphes peuvent être considérés comme identiques, ou du moins indiscernables. En effet, bien souvent, les propriétés intéressantes d'un objet seront partagées par tous les objets isomorphes de la catégorie. Ainsi on parle souvent d'unicité ou d'identité « à isomorphisme près ».

Ce dont j’ai besoin c’est d’une sorte de théorème méta-mathématique, autrement dit logique qui exprime cela. Je pense qu’une expression approximative en serait : Si une formule logique dont les atomes ne font intervenir que les éléments - de manière abstraite - et les relations de la structure est vraie alors elle est aussi vraie pour toute structure isomorphe.

Je ne vous fournirai pas de démonstration de ce théorème car je l’ai exprimé de manière intuitive. Mais je serais curieux d’en lire une formulation et une démonstration rigoureuse (il y a sûrement des gens qui l’ont faite). Dans la suite, je vous montrerai une démonstration d’un cas particulier.

Les questions subséquentes sont alors de s’interroger sur la minimalité des hypothèses de ce théorème. A-t-on vraiment besoin d’un isomorphisme ? A-t-on besoin de la notion de “structure” ?

Nous n’avons pas toujours besoin d’isomorphisme.

Prenons deux ensembles E (respectivement E’) munis d’une relation R (respectivement R’).

Soit F(E, R, x₁, …, x_n) une formule du premier ordre positive² dont les variables libres³ sont x₁, …, x_n ∈ E et les atomes sont de la forme R(y₁, …, y_k).

Supposons qu’on dispose d’une fonction f : E → E’

• surjective : ∀ y ∈ E’, ∃ x ∈ E, f(x) = y
• avec une propriété de transfert de R : ∀ x₁, …, x_k ∈ E, R(x₁, …, x_k) → R’(f(x₁), …, f(x_k))

Alors si F(E, R, x₁, …, x_n) est vraie, F(E’, R’, f(x₁), …, f(x_n)) aussi.

Le cas particulier où il n’y a pas de variable libre nous montre que tout théorème positif du premier ordre ne portant que sur R se transfère de E à E’.

Effectuons la démonstration par récurrence structurelle sur F :

Cas F = ∀ x ∈ E, F’(E, R, x₁, …, x_n, x)

Soit x ∈ E’, d’après la surjectivité de f, on peut trouver x’ ∈ E tel que x = f(x’). Alors on applique F à x’ pour obtenir F(E, R, x₁, …, x_n, x’).

Du coup, par hypothèse de récurrence, F(E’, R’, f(x₁), …, f(x_n), f(x’)) est vraie, i.e. F(E’, R’, f(x₁), …, f(x_n), x) est vraie.

Ainsi on conclut que ∀ x ∈ E’, F’(E’, R’, f(x₁), …, f(x_n), x).

Cas F = ∃ x ∈ E, F’(E, R, x₁, …, x_n, x)

Soit un témoin x rendant la formule F’(E, R, x₁, …, x_n, x) vraie. Alors par hypothèse de récurrence, F’(E, R, f(x₁), …, f(x_n), f(x)). D’où f(x) est un témoin rendant la formule ∃ x ∈ E’, F’(E’, R’, f(x₁), …, f(x_n), x) vraie.

Cas F = F’(E, R, x₁, …, x_n) ∨ F’‘(E, R, x₁, …, x_n)

L’une au moins de ces deux sous-formules F’ et F’’ est vraie. Supposons par exemple que ce soit F’. Alors par hypothèse de récurrence, F’(E’, R’, f(x₁), …, f(x_n)) est vraie ce qui suffit à conclure que F’(E’, R’, f(x₁), …, f(x_n)) ∨ F’‘(E’, R’, f(x₁), …, f(x_n)) est vraie aussi.

Le cas avec ∧ est similaire.

Cas de base F = R(y₁, …, y_k)

C’est là qu’on utilise la seconde propriété de f et c’est alors immédiat.

QED

On peut généraliser facilement à des formules comportant aussi des négations ¬ et des implications → à condition :

1. Qu’aucun quantificateur n’apparaisse sous ces deux connecteurs logiques ;
2. Qu’on renforçe un petit peu la seconde hypothèse sur f : ∀ x₁, …, x_k ∈ E, R(x₁, …, x_k) ↔ R’(f(x₁), …, f(x_k)).

Pour le voir il faudra renforcer l’hypothèse de récurrence sur toutes les sous-formules sans quantificateurs, dans l’esprit avec lequel on a renforcé l’hypothèse sur f.

En revanche, nous avons besoin d’un isomorphisme pour considérer les théorèmes quelconques du premier ordre mixant allègrement les quantificateurs et les négations.

Nous avons besoin d’un isomorphisme si nous rajoutons l’égalité

Plus précisément, dès lors que nous autorisons les formules atomiques à être des égalités x = y et pas seulement des relations R(y₁,…,y_k), alors on peut exprimer la taille de l’ensemble pour tout ensemble fini. Une bijection est alors nécessaire pour qu’une telle propriété se transmette (une surjection entre deux ensembles finis de même taille est une bijection).

Nous n’avons pas besoin des axiomes de la structure

Il est bien connu qu’un morphisme de monoïde transfère les propriétés de groupe et de groupe Abélien. La raison est la même que pour tous les autres théorèmes que nous pouvons vouloir transférer. Par conséquent, tous ces axiomes structurels sont superflus : si on peut transférer les relations, on peut transférer les axiomes.

Que se passe-t-il lorsque nous avons des éléments distingués et des opérations ?

Des opérations (i.e. des applications à plusieurs arguments, à valeurs de départ et d’arrivée dans la structure) peuvent être représentées par des relations bien particulières.

De même, des éléments distingués (comme l’élément neutre d’un groupe) peuvent n’être distingués que par une relation spéciale à un seul argument, toujours fausse, sauf pour l’élément concerné.

Cependant, il pourra être utile, en encodant cela, de traiter les opérations et les éléments distingués de manière spécifique, notamment pour des raisons d’efficacité et d’utilisabilité.

Conclusion

J’ai essayé de faire une présentation assez pédagogique, au moins pour le début. En revanche, elle est aussi assez naïve, comme je ne suis pas spécialiste du sujet, alors que les questions soulevées m’intéressent vraiment pour mon travail. Je serais donc ravi d’avoir des retours de mes amis mathématiciens ou catégoriciens (ce mot n’existe pas, j’en ai conscience).

Si vous voulez en savoir plus, lisez l’article que j’ai écrit sur le sujet depuis [en anglais].

Le sujet abordé par ce livre est très vaste mais s’il fallait le réduire à quelques mots-clés, je listerais, par ordre d’importance : science ouverte (open science), collaboration, Internet, partage des données (open data), accès libre aux résultats de la recherche (open access), science participative (citizen science), mise en réseau des connaissances (data web), extraction automatique de significations nouvelles (data mining). Je vais m’étendre sur certains points plus que d’autres en fonction de l’intérêt personnel que j’y attache.

Michael Nielsen est un physicien qui, impressionné par le succès du projet Polymath¹, a décidé de se consacrer à l’étude de cette révolution silencieuse qu’Internet a déclenchée et qui est en train de redéfinir la manière dont la connaissance scientifique est produite. Dans son livre, il présente un certain nombre d’exemples concrets de projets² ayant eu du succès (ou pas) et analyse les éléments indispensables au succès d’un projet collaboratif.

Cette révolution du partage scientifique est comparable à la précédente révolution du même type : l’invention des revues dans lesquelles tout-e scientifique se doit de publier les résultats de sa recherche. Cette première révolution, au XVIIème siècle, eut un effet radical sur la manière dont la recherche scientifique se pratiquait et influence plus encore la manière dont elle se pratique aujourd’hui. En effet, la conséquence positive de cette révolution est une première forme de collaboration, la création de nouvelles connaissances s’appuyant sur les connaissances précédemment acquises par d’autres scientifiques et le principe de citation permettant aux articles de se baser les uns sur les autres.

Les clés du succès d’un projet collaboratif

Le concept de micro-expertise

La connaissance scientifique est devenue si vaste qu’il est aujourd’hui impossible d’être un-e expert-e sur tout (alors que c’était quasiment possible à son époque pour un génie comme Léonard de Vinci). Même dans leur propre domaine, les plus grand-e-s expert-e-s de notre époque (que sont, par exemple, les médaillé-e-s Fields en mathématiques ou les champion-ne-s du monde d’échecs), ne peuvent pas avoir une connaissance totale.

Sans être aussi brillant, un autre individu peut avoir des connaissances spécifiques sur un point de détail, simplement parce qu’il y a déjà été confronté. Cette micro-expertise peut alors surpasser celle de tout autre personne.

Par conséquent, nous pouvons “augmenter notre intelligence collective” (je dirais plutôt tirer parti au mieux de notre intelligence collective) si un système est capable de connecter adéquatement un problème à la personne ayant la meilleure micro-expertise pour le résoudre.

Faire collaborer les bonnes personnes

De manière plus générale, des scientifiques peuvent être confrontés à des problèmes qui sortent carrément de leur domaine d’expertise (nouveaux concepts mathématiques pour résoudre un problème de physique par exemple). Internet a déjà rendu beaucoup plus facile la tâche de trouver la bonne personne (autrement que par simple chance) mais des outils nouveaux émergent qui rendent cette tâche encore plus aisée. L’auteur utilise le terme de designed serendipity pour désigner le fait que cette connexion nécessite de “forcer le hasard”.

L’émulation

L’intervention au moment adéquat de la personne adéquate permet à la communauté cherchant à résoudre un problème plus général (tel qu’une démonstration) de ne pas être bloquée. S’en suit, si le nombre de collaborateurs/trices dépasse une taille critique, une sorte de réaction en chaîne des idées. Une personne peut apporter régulièrement des idées qui font progresser la résolution alors que, toute seule, elle aurait passé la plupart de son temps à essayer de se débloquer de situations dont elle n’était pas spécialiste.

Les caractéristiques du logiciel libre : modularité, réusabilité, micro-contributions

Un modèle collaboratif ayant eu beaucoup de succès est celui des logiciels libres. Souvent les équipes développant de tels logiciels font un réel effort pour rendre le développement le plus modulaire possible. Afin que les différentes personnes y contribuant puissent travailler le plus indépendamment possible.

La réusabilité est une caractéristique que partagent le logiciel libre et la recherche scientifique. En effet, de la même manière qu’il est beaucoup plus facile de créer un logiciel en utilisant des bibliothèques codées par d’autres, le principe des citations dans les articles scientifiques permet de construire de nouvelles connaissances en s’appuyant sur les résultats des autres. La preuve d’un théorème peut ainsi faire appel à plusieurs autres théorèmes sans pour autant devoir réexpliquer la preuve à condition qu’elle soit disponible quelque part.

Enfin, l’auteur observe que la plupart des contributions à des logiciels libres sont seulement d’une ou quelques lignes. Un projet collaboratif aura probablement d’autant plus de succès qu’il permet ce genre de micro-contributions.

La question de la modularité et des micro-contributions sont des éléments possibles pour réduire les “barrières à l’entrée” d’un projet collaboratif. De telles barrières sont un obstacle significatif à la réussite d’un projet massivement collaboratif car il est peu probable que tou-te-s les contributeurs/trices arrivent au même moment et suivent le projet avec le même degré d’attention. C’est une des raisons pour lesquelles le succès de Polymath a été limité à quelques dizaines de personnes et certainement pas quelques milliers.

Permettre les discussions et créer un esprit de communauté

La plupart des projets ayant eu du succès possédaient des espaces permettant la discussion et le débat mais aussi de forger un esprit d’appartenance à une communauté. Parfois de tels espaces créent une différence significative. Par exemple, si la communauté vote sur chaque décision comme c’était le cas lors du match d’échecs Kasparov vs the World, le fait d’avoir un espace de débats préalables permet d’orienter les votes vers de meilleures décisions. Et sur Wikipédia, l’existence de pages de discussion et de communauté fidélise les contributeurs et permet de résoudre les problèmes que l’outil du wiki lui-même ne suffit pas à combler.

Focaliser l’attention

Lorsqu’un projet enregistre un grand nombre de contributions, il devient impossible pour une personne seule de les suivre et les analyser dans leur ensemble. Différents mécanismes peuvent être mis en place de manière à focaliser l’attention.

Une première catégorie de mécanismes permet de mesurer la qualité de chaque contribution de sorte à concentrer l’attention générale sur les meilleures idées, celles qui permettront d’avancer plus vite et plus loin. La solution la plus simple dans cette catégorie consiste à attribuer un score à chaque solution (comme dans le concours organisé par MathWorks). Cependant, cette solution est loin d’être systématiquement praticable car il n’est pas toujours faisable d’évaluer automatiquement la qualité d’une idée ou solution.

L’auteur généralise l’idée du score au concept de shared praxis. D’une certaine manière, l’existence d’un score fournit un langage commun (rudimentaire) à tou-te-s les contributeurs/trices. Ce langage commun peut être en revanche plus compliqué, comme dans le cas du jargon scientifique. Dans les deux cas, la possession d’un tel langage se révèle importante pour la communication effective au sein de la communauté donc pour l’évaluation des idées émises par d’autres. En d’autres termes, “avoir une idée” est alors l’étape délicate tandis que “comprendre qu’une idée est bonne” est aisé. L’absence d’un tel moyen de partager effectivement ses idées rend au contraire les projets collaboratifs plus difficiles : c’est une problématique importante dans le domaine littéraire en particulier³ et dans le domaine de la création artistique en général, mais aussi en politique et dans tout domaine où il est compliqué d’obtenir un consensus d’un grand nombre de gens.

Une seconde catégorie de mécanismes permet de focaliser l’attention de chaque personne sur les problèmes les plus proches de son domaine d’expertise. Une telle catégorie d’outil est plus intéressante car elle permet une division de l’attention (donc la communauté dans son ensemble est attentive plus largement), tout en permettant le succès du concept de designed serendipity. Le monde du logiciel libre nous fournit un exemple basique de tel outil. Un issue tracer regroupe les bugs rapportés en un même endroit ; un système de tags permet de savoir si un bug vient d’être rapporté ou s’il a déjà été confirmé, si le type de problème qu’il soulève a déjà été identifié, et enfin si une personne spécialiste a été chargée de sa résolution.

L’extension des communs

La deuxième partie du livre (chapitre 6 et suivants) ne traite plus de projets collaboratifs en particulier mais plus généralement de la révolution du partage scientifique en cours. Par rapport à la première révolution suite à laquelle le partage scientifique se faisait uniquement par le biais de publications dans des revues, deux nouveautés essentielles sont l’open access et l’open data.

Les nouvelles formes de partage

L’open access est le fait de rendre librement (et gratuitement donc) accessibles les résultats de la recherche. De manière plus concrète, les articles scientifiques sont alors rendus publics sur des sites web dont l’accès n’est pas limité. Il prend deux formes : la mise à disposition par les chercheurs/euses eux/elles-mêmes de documents de travail et de preprints (version de l’article avant le travail d’édition effectué par la revue) sur des portails ouverts ; l’apparition de revues ouvertes qui ne se financent pas en vendant des abonnements et en restreignant l’accès mais par d’autres moyens (par exemple en facturant l’acte de publication directement aux auteur-e-s).

Dans le premier cas, les articles partagés n’ont pas nécessairement été relus et contrôlés par des comités de lecture, donc leur fiabilité est moindre. En revanche, la plupart des revues opérant encore de manière fermée, c’est bien par le partage de preprints qu’il y a le plus d’espoir aujourd’hui d’accéder aux derniers travaux de nombreux scientifiques.

Les scientifiques eux/elles-mêmes peuvent avoir intérêt à faire cette démarche de mettre en ligne leurs articles dans une version non-finale pour plusieurs raisons : atteindre un public plus large, obtenir des citations supplémentaires et s’assurer d’être les premiers/ères à publier un résultat inédit.

Des tentatives d’y adjoindre des sortes de relectures ont eu lieu. Une idée persistante est notamment d’en finir avec la relecture anonyme et d’encourager les chercheurs/euses à écrire et signer des commentaires des preprints mis en ligne par leurs collègues. Cette idée n’a cependant pas abouti pour l’instant. Deux explications possibles sont d’une part le manque de temps et d’incitations, d’autre part la crainte de payer le prix de critiques si les collègues critiqué-e-s se retrouvent ensuite à devoir évaluer l’article ou la demande de financement du/de la chercheur/euse auteur-e des critiques.

Pour en savoir plus sur l’open access, je recommande la lecture de ce dossier par Pablo Rauzy.

Le principe de l’open data est de rendre librement accessible les données récoltées pour une étude scientifique, soit immédiatement, soit au moment de la publication. Ces données peuvent alors servir à d’autres chercheurs/euses dans de nouvelles analyses.

Enfin, certain-e-s chercheurs/euses vont plus loin en partageant l’état de leur recherche, quasiment en direct, sur leur blog (ce qu’on peut qualifier de recherche ouverte ou recherche en public). Certains blogs de chercheurs/euses connu-e-s reçoivent alors des milliers de visiteurs/euses, y compris des gens en dehors du milieu scientifique et qui s’intéressent aux dernières avancées ou à la vision du monde qui est présentée dans ces espaces.

La combinaison de ces nouvelles formes de partage laisse entrevoir l’apparition d’un internet des données. L’objectif serait alors que l’immense majorité de la connaissance scientifique soit facilement accessible de sorte qu’il serait possible d’en tirer de nouvelles significations de manière automatique ou semi-automatique (à l’aide de requêtes potentiellement complexes). Outre la généralisation du partage des connaissances, une telle application nécessite l’utilisation de formats de données standardisés, aidant alors l’ordinateur à parcourir automatiquement la gigantesque base de données mondiale.

L’implication des citoyen-ne-s rendue possible

Les sciences citoyennes ne sont pas un phénomène nouveau (par exemple, ce sont souvent des amateurs/trices qui découvraient de nouvelles comètes) mais Internet rend l’implication des citoyen-ne-s beaucoup plus facile. Les amateurs/trices peuvent intervenir de plusieurs façons : en collectant et traitant de grands volumes d’information, mieux que les ordinateurs (Galaxy Zoo) et parfois mieux que les expert-e-s du domaine eux/elles-mêmes (FoldIt) ; en repérant les anomalies et ce qui est digne d’attention et en faisant parfois eux/elles-mêmes un véritable travail de recherche⁴ ; en compilant la littérature (Open Dinosaure Project). Enfin, lorsque même les amateurs/trices ne sont plus assez nombreux/euses pour traiter l’énorme volume de données disponibles, on peut se servir de leur travail pour entraîner des ordinateurs à reproduire leur “expertise”.

Un projet tel que Galaxy Zoo n’aurait pas été possible sans open data. Un projet comme Open Dinosaure n’aurait pas été possible sans open access. Autant l’un que l’autre sont indispensables lorsque des personnes hors du milieu académique décident de s’attaquer à un problème scientifique. Outre l’histoire des “green peas”, d’autres découvertes importantes ont récemment été le fait d’amateurs/trices. L’auteur cite le cas d’un informaticien à la retraite ayant découvert un lien entre la migraine et le manque de magnésium uniquement en sondant des bases d’articles en libre accès et donc en tirant de nouvelles conclusions d’études déjà réalisées.

Les sciences citoyennes (ou participatives) sont attrayantes car elles sont un moyen efficace d’utiliser le “surplus de temps disponible” de notre société, c’est-à-dire le temps que les individus n’ont pas besoin de passer à travailler, couramment associé aux loisirs. Pour autant, il est très dur de savoir à quel point les sciences participatives vont impacter la manière dont la recherche scientifique est conduite. Il se pourrait en effet qu’elles restent un phénomène marginal tant chaque nouveau projet demande de l’ingéniosité, notamment lorsqu’il s’agit de rendre ludique la résolution de problèmes scientifiques. Lorsque les citoyen-ne-s deviennent de véritables scientifiques et font de la vraie recherche (par opposition à seulement y contribuer sur des tâches spécifiques et répétitives), ils/elles ont besoin de systèmes d’auto-formation, de communautés et de mentors pour coopérer et progresser.

Le partage libre des connaissances scientifiques pourrait avoir un autre avantage, à savoir instaurer une communication plus directe entre science et décision politique. Le risque d’une surinterprétation ou d’une mauvaise interprétation des publications scientifiques par les médias grand public existe cependant. L’auteur n’est pas pour autant inquiet car, d’après lui, les médias mettent en danger leur réputation à chaque fois qu’ils publient une information qu’ils doivent démentir par la suite et vont donc rapidement acquérir des pratiques visant à éviter que ce genre de situation ne se produise trop souvent.

Les freins au partage

Une des thèses importantes de ce livre est que le partage est globalement une bonne chance pour la science et que celui-ci doit être encouragé. Cependant, alors que chaque scientifique a intérêt à ce que la communauté partage plus, il n’est pas dans son intérêt personnel d’agir individuellement dans ce sens.

Les scientifiques ne sont actuellement valorisé-e-s que lorsqu’ils/elles écrivent des articles scientifiques. Ils/Elles passent aussi une grosse partie de leur temps à chercher des financements (principalement en rédigeant des candidatures pour des allocations ou grants). Par manque de temps et de valorisation, rares sont ceux/celles qui contribuent à Wikipédia, documentent des programmes qu’ils/elles auraient programmés en vue de les partager, ou maintiennent des blogs actifs.

Le second frein résulte de la crainte que le partage ne profite qu’aux autres et soit même contre-productifs pour les chercheurs/euses, par exemple si leurs concurrent-e-s tirent avant eux/elles des analyses des données qu’ils/elles ont rendues publiques.

Enfin, un dernier frein est dû à la volonté de commercialiser les résultats scientifiques, essentiellement sous la forme des brevets. Dans les domaines où des possibilités de brevets existent, la recherche ne peut nécessairement avoir lieu qu’en secret (un esprit radicalement contradictoire par rapport à celui de la recherche ouverte). L’auteur pense néanmoins que ce problème a un impact mineur en comparaison avec les deux premiers.

Dans l’état actuel des choses, beaucoup de scientifiques hésitent voire refusent complètement de changer de pratiques vers plus d’ouverture. Pour combler ce différentiel entre intérêt collectif et intérêt personnel, des incitations ou des règles doivent être mises en place de manière institutionnelle.

Puisque les scientifiques sont essentiellement récompensé-e-s par leur réputation (qui leur servira ensuite à décrocher de meilleurs postes et d’autres avantages), il faut tout d’abord changer de mesure de réputation. Aujourd’hui le travail de création d’un outil collaboratif ou de partage de données est trop souvent dénigré. En s’assurant que citer les auteurs des données ou des outils utilisés pour une étude devienne aussi systématique que de citer les articles sur lesquels le travail se base, et en mesurant le nombre de citations recueillies par un-e auteur-e pour tous ses travaux, et pas seulement pour ses articles publiés dans des revues, l’incitation à faire de la science ouverte sera alors évidente. D’ores et déjà, des outils permettent de mesurer le nombre de citations d’un article (y compris d’un preprint et en comptant les citations par des preprints).

D’autre part, les scientifiques peuvent mettre en place de nouvelles règles que les agences de financement de la recherche peuvent alors faire appliquer. Un exemple est celui de l’accord des Bermudes en 1996 qui a édicté que toute donnée récoltée sur le génome humain doit être immédiatement rendue publique.

La licence GPL a été inventée par des gens et pour des gens qui pensent que tous les logiciels devraient être des logiciels libres³. Ne l’utilisez pas si vous n’êtes pas d’accord avec cette philosophie !

Si vous êtes d’accord avec cette philosophie, ayez conscience que l’usage de cette licence rend très compliquée l’utilisation de bibliothèques propriétaires (ou incompatibles avec la GPL) dans les programmes que vous développez⁴.

Maintenir deux versions d’un logiciel

Ce que je trouve stupide par dessus tout, ce sont les entreprises qui créent deux versions d’un logiciel : une version de base libre et gratuite sous licence GPL et une version améliorée, payante et non-libre (propriétaire). Pour pouvoir vendre ensuite la version fermée de leur programme et ne pas en dévoiler le code, elles ont besoin de posséder le copyright de l’ensemble. En particulier, l’intégralité du code sous GPL doit leur appartenir, de sorte que la GPL ne s’applique pas à elles-mêmes.

Ces entreprises font donc signer des contrats (dits contributor license agreement) à tou-te-s les contributeurs/trices dont elles intègrent les modifications. Il faut avoir conscience, lorsque vous contribuez à un logiciel sous GPL, géré par une entreprise qui exige que vous lui cédiez vos droits que vous êtes en train de briser vous aussi la philosophie selon laquelle tout logiciel devrait être libre⁵.

Ce ne sera pas le cas par contre si vous cédez vos droits à une organisation en laquelle vous avez confiance, telle que la Free Software Foundation. Les associations qui choisissent de centraliser le copyright le font souvent afin de simplifier la gestion des procès⁶.

Notez de plus que renoncer à ses droits d’auteur n’est pas une chose anodine. Selon le type de contrat que vous signez avec l’organisation gestionnaire du logiciel auquel vous contribuez, soit vous accordez à cette dernière une licence définitive, gratuite et non-exclusive d’utilisation et d’exploitation de votre code (pour qu’elle puisse le revendre au sein d’un logiciel fermé), soit vous lui cédez votre copyright. Dans ce second cas, vous n’êtes plus propriétaire de votre code et c’est uniquement parce que l’entreprise qui en est désormais propriétaire l’a publié sous GPL que vous continuez à pouvoir l’utiliser. Si dans le futur, vous choisissez de réutiliser votre code dans un logiciel fermé ou sous une licence différente, vous enfreindrez les termes de la GPL et vous serez dans l’illégalité. C’est pourquoi je vous encourage à ne jamais accepter de céder purement et simplement votre copyright à moins que vous soyez certain que tous les logiciels que vous produirez dans le futur seront aussi sous la même licence. Méfiez-vous, à ce propos, des incompatibilités entre les versions des GPL⁷.

Heureusement, il semblerait que l’accord que demande la FSF à ses contributeurs/trices inclue une clause stipulant que ceux-ci peuvent continuer à utiliser leur travail comme bon leur semble⁸. Un autre exemple est celui de Canonical, l’entreprise qui édite Ubuntu, un système d’exploitation basé sur Linux. Elle demandait par le passé que les contributeurs/trices lui cèdent leur copyright mais l’accord qu’elle leur demande désormais est beaucoup plus respectueux de leurs droits et garantit que leur code ne sera pas utilisé dans des programmes fermés⁹.

Les alternatives à la licence GPL

Moralement, les entreprises qui veulent développer deux versions (une libre, une fermée) de leur logiciel ne devraient pas utiliser la GPL.

Juridiquement, aussi, elles feraient mieux de ne pas l’utiliser. Si elles choisissent cette licence, c’est qu’elles se disent que cela va les protéger des concurrents qui produiraient un logiciel fermé en partie basé sur leur code source. C’est une crainte que n’ont que les petites entreprises (les plus grosses entreprises - Adobe, Apache, Apple, Google, Mozilla, Sun

• utilisent souvent des licences plus permissives telles que la licence Apache ou la MPL 2.0 ; ou alors, comme RedHat ou Canonical, ne produisent que des logiciels libres¹⁰). Cependant, il faudrait que ces petites entreprises craintives réalisent les difficultés qu’elles se créent en s’engageant dans cette voie !

D’abord le contrat qu’elles font signer à leurs contributeurs/trices ne sera certainement pas aussi peaufiné que les licences libres les plus courantes (et pourrait s’avérer caduque lors d’un procès).

Deuxièmement, en utilisant la GPL, ces entreprises se compliquent la vie si elles souhaitent utiliser des bibliothèques propriétaires, pour des raisons philosophiques qui leur échappent.

Troisièmement, ces entreprises ne peuvent pas du tout utiliser des bibliothèques libres sous GPL car celles-ci seraient incompatibles avec la version fermée de leur programme.

Enfin mais surtout, ces entreprises doivent contrôler que les contributions extérieures sont effectivement complètement nouvelles et qu’elles n’embarquent pas du code sous licence libre GPL d’une autre source. En effet, dans ce cas-là, le/la contributeur/trice ne possède pas le copyright sur ces lignes de code de source extérieure. Par conséquent, même en signant un accord quelconque, il/elle ne peut pas légalement céder les droits dessus. Je suis sûr que la plupart des entreprises qui fonctionnent sur ce modèle n’effectuent jamais ces vérifications car elles n’en ont pas les moyens.

En pratique, la conséquence c’est que beaucoup de logiciels libres ou non libres enfreignent la loi de manière notable ou anecdotique¹¹. Il ne faut pas encourager cela car cela met en danger le monde du logiciel libre dans son ensemble.

Note : dans le cas d’un logiciel destiné à tourner sur des serveurs distants et être utilisé via un navigateur plutôt que d’être installé sur des machines individuelles¹², la GPL n’a que peu d’intérêt. Tout ce que j’ai dit s’applique également à la licence AGPL¹³, plus adaptée à ce type d’usage.

Je trouve formidable que des entreprises souhaitent contribuer au libre tout en faisant des profits. Je comprends que pour certaines, cela implique de ne partager qu’une partie de leur code seulement (ou alors qu’elles veulent se garder des portes ouvertes si demain elles décidaient de repasser à un modèle fermé). Mais je leur déconseille avec force d’utiliser alors le système répandu GPL + accord avec les contributeurs.

Je leur conseille plutôt d’utiliser des licences qui ont été pensées, notamment, pour elles. Pour faire simple, le choix se résume à une alternative entre la licence Apache et la licence MPL 2.0.

La licence Apache est utilisée massivement par Google¹⁴ pour tous ses projets libres (tels qu’Android, Chromium et Chromium OS). Elle permet d’intégrer ces projets avec des extensions propriétaires, ce qui donne les nombreuses versions “fabricant” d’Android, ainsi que Chrome et Chrome OS. Cette licence n’exige pas que les modifications du programme soient partagées mais une entreprise comme Google n’a rien à craindre car elle sait qu’elle disposera toujours de la meilleure version même si des “passagers clandestins” refusent de participer à l’effort collectif.

Pour les plus petites entreprises, je recommande plutôt la licence MPL 2.0¹⁵, celle du navigateur Firefox. En effet, c’est une licence dite weak copyleft. Elle permet l’intégration dans des logiciels propriétaires, mais toutes les modifications apportées aux fichiers d’origine doivent être partagées. Cela permet de se protéger contre les profiteurs les plus immoraux tout en laissant la place pour des extensions payantes. Bien entendu, il ne s’agit pas de nier que des concurrents aussi pourront proposer des extensions payantes.

Deux licences que je n’ai pas citées et qui sont proches de la licence Apache et de la MPL 2.0 sont la licence MIT et la licence LGPL. Celles-ci sont aussi très intéressantes pour certains projets mais probablement moins adaptées à des entreprises.

La licence MIT est similaire à la licence Apache mais cette dernière intègre en plus des mesures de protection contre les brevets logiciels (problème qui ne nous touche pas encore en Europe mais ça pourrait arriver bientôt

• l’Office Européen des Brevets a commencé à enregistrer des brevets logiciels - et si vous avez des ambitions, vous ne souhaitez probablement pas vous limiter à l’Europe pour toujours
• aux États-Unis et dans la majorité du reste du monde le problème des brevets est réel). De telles mesures sont présentes dans toutes les grandes licences modernes (licence Apache, MPL 2.0, LGPL v3, GPL v3, AGPL v3).

La licence LGPL est proche de la MPL 2.0 sur le plan pratique (quoiqu’un peu plus tordue¹⁶), mais très différente au point de vue philosophique. La licence LGPL a été conçue par et pour des gens qui pensent que tout logiciel devrait être libre mais qui avaient conscience que, pour gagner le combat, il serait préalablement intéressant de créer des bibliothèques que tout le monde utilise y compris les logiciels fermés¹⁷. Ce pari est réussi car un grand nombre de bibliothèques standard sont aujourd’hui des bibliothèques libres si bien qu’on peut affirmer sans crainte de se tromper que le logiciel libre est partout¹⁸.

Vous devriez aussi savoir que les conditions d’utilisation de l’Apple Store contredisent les principes essentiels des licences libres GPL et LGPL¹⁹. Bien entendu cela devrait être une raison suffisante pour boycotter Apple. Cependant, si votre activité économique implique de distribuer des applications mobiles, vous aurez du mal à convaincre tous vos utilisateurs d’abandonner leur iPhone. Vous feriez donc bien d’envisager (tant qu’Apple maintient sa politique liberticide) d’utiliser des licences plus laxistes (pour une fois je trouve ce terme justifié) pour tous vos programmes pouvant être intégrés à des applications mobiles.

Remarque finale : Il n’est pas du tout absurde pour une entreprise d’avoir un business model basé sur la GPL. Si vous souhaitez suivre cette voie, plutôt que de maintenir deux versions de votre logiciel, vous devriez tout publier sous GPL et suivre l’exemple de RedHat pour faire des profits. À savoir, faire payer à vos clients non pas le logiciel lui-même mais la garantie et l’assistance.

Une autre manière de faire du business avec la GPL est celle qui consiste à vendre des exceptions²⁰. Cette méthode consiste à maintenir une unique version du logiciel et à la distribuer à la fois sous licence GPL et sous licence propriétaire (pour des clients souhaitant éviter les contraintes de la GPL). En revanche, elle n’est pas idéale en ce qu’elle souffre de la plupart des problèmes que j’ai décrits dans cet article.

C’est un concept assez simple et il n’est pas nouveau dans mon esprit. Cependant, il se heurte à un problème majeur : comment convaincre les gens de partager leurs idées alors que ces dernières ne peuvent être protégées que par le secret ?

En effet, il n’y a pas de propriété intellectuelle sur les idées en général :

• Elles ne peuvent pas être protégées par le droit d’auteur. Seul l’écrit décrivant l’idée est protégé. Pas le contenu conceptuel. On peut accuser de plagiat celui qui décrirait de nouveau la même idée par la suite sans citer son auteur original. Mais on ne pourrait pas attaquer celui qui mettrait l’idée en oeuvre, par exemple en créant une entreprise.

• Lorsqu’une idée est réalisée par la création d’un logiciel, ce dernier est aussi protégé par le droit d’auteur. C’est pourquoi vous n’avez pas le droit de copier le logiciel et de l’utiliser sans l’accord de son auteur. En revanche, le droit d’auteur ne vous empêche pas de reproduire le logiciel à l’identique ou presque, si vous le re-codez de zéro. C’est une situation qui survient fréquemment et donne lieu à une concurrence effrénée entre plusieurs acteurs, sans que le premier à avoir eu l’idée ne tire de gros avantages, si ce n’est celui d’avoir commencé plus tôt.

• Certaines idées, à savoir les inventions et les procédés industriels, peuvent être brevetées, à condition d’avoir été décrits en suffisamment grands détails. L’idée initiale à partir de laquelle va naître l’invention n’est pas brevetable en tant que telle.

Peut-être que la solution réside dans un argument donné par Tim Gowers dans l’article de blog à l’origine du projet Polymath.

C’est ici qu’entre en jeu ce qui fait la beauté des blogs, des wikis, des forums, etc: ils sont entièrement publics, de même que l’est leur historique complet. Pour comprendre quel impact ça peut avoir, imaginez qu’un problème était résolu via les commentaires d’un article de blog. Supposons que le blog était très actif et que l’article en question recevait plusieurs commentaires intéressants. Et supposons que vous ayez une idée qui vous semble être potentiellement bonne. Au lieu de la réaction habituelle qui consiste à avoir peur de partager votre idée au cas où quelqu’un trouve la solution complète avant vous, vous auriez peur de ne pas la partager au cas où quelqu’un trouve cette idée précise avant vous.

Cette même idée est derrière la raison pour laquelle il a lancé ce projet à ce moment particulier :

J’avais imaginé faire ça depuis longtemps. La raison pour laquelle j’ai soudainement décidé de me lancer, c’est que j’ai suivi quelques liens depuis cet article sur le blog de Michael Nielsen et que j’ai découvert que, sans surprise, d’autres ont eu des idées similaires, et certaines personnes font déjà de la recherche en public. Mais l’idée semble encore plutôt neuve, en particulier appliquée à un unique problème de mathématiques, donc je voulais la tester tant qu’elle était encore fraîche.

La conclusion c’est que, dans le monde d’aujourd’hui, garder une idée secrète n’a plus grand sens, à moins que vous soyez très motivés par sa réalisation à court terme.

En effet, si vous ne la concrétisez pas vite, il est probable que vous ne serez plus le premier à l’avoir eue et que vous ne serez pas du tout crédité pour elle. Tandis que si vous la partagez, même si vous n’en retirerez pas nécessairement tous les bénéfices, vous pourrez au moins en assumer la (co-)paternité.

Car la publicité d’internet fera que les personnes qui auront, en fin de compte, réalisé votre idée ne pourront pas faire comme si vous n’existiez pas et seront tenues de donner des explications : soit votre idée les a inspirées, soit vous avez eu la même idée qu’elles (ou une idée similaire) de manière indépendante¹. Quel que soit ce qu’elles affirment, vous serez cité et ça aura certainement un impact sur votre réputation.

Pour finir, il serait grandement stupide que cette idée-ci (le concept d’un lieu où chacun puisse partager ses idées) traine longtemps dans un placard avant sa réalisation. Il faut donc trouver rapidement une voie de la rendre publique, éventuellement un article de blog, même si ça nécessite de créer un blog².

J’en profite pour rajouter que si vous êtes intéressé par cette idée, n’hésitez pas à laisser un commentaire : peut-être pourra-t-on la réaliser ensemble…