Filmés et géolocalisés, nos déplacements n’échappent pas à la surveillance. Même quand nous flânons dans une boutique physique, notre parcours est enregistré.
Voici déjà le 12e article de la série écrite par Rick Falkvinge. Le fondateur du Parti Pirate suédois s’inquiète aujourd’hui la fin de l’anonymat dans nos achats en raison des moyens électroniques de paiement.
Le fil directeur de la série de ces 21 articles, comme on peut le voir clairement dans les épisodes précédents que nous vous avons déjà livrés, c’est la perte de certaines libertés dont nous disposions encore assez récemment, avant que le passage au tout-numérique ne nous en prive.
Nos parents achetaient des objets sans être pistés, leurs pas en boutique n’étaient pas enregistrés
Traduction Framalang : goofy, draenog, Moutmout, xi + 2 anonymes
Dans le dernier article, nous nous sommes concentrés sur la façon dont les personnes sont pistées aujourd’hui lorsqu’elles utilisent des cartes bancaires plutôt que du liquide. Mais peu de gens remarquent qu’aujourd’hui, nous sommes également suivis à la trace même si nous utilisons du liquide.
Peu de gens font attention au petit signe (en) sur la porte tambour de l’aéroport d’Amsterdam-Schiphol. Il indique que chacune des personnes dans l’aéroport est suivie par Bluetooth et Wi-Fi.
Ce qui caractérise l’aéroport d’Amsterdam-Schiphol n’est pas le fait que le moindre pas des gens dans une zone commerciale y soit pisté (à des fins commerciales, pas pour la sécurité.) Non, ce qui différencie l’aéroport d’Amsterdam-Schiphol, c’est que les personnes en sont informées. Les Pays-Bas ont tendance à prendre la vie privée au sérieux, comme l’Allemagne, et pour la même raison (en).
Les balises de localisation sont devenues quasiment un standard dans les plus grandes zones commerciales. Elles envoient un signal à votre téléphone par Wi-Fi et par Bluetooth, et par triangulation, en utilisant la force du signal, un réseau de balises est capable de déterminer les déplacements de chaque individu en temps réel avec une précision inférieure à la longueur d’un pas. Tout ceci est utilisé pour « optimiser la vente » – en d’autres termes, trouver des façons de piéger le cerveau des gens pour qu’ils dépensent des ressources qu’ils n’auraient sinon pas dépensées. Notre propre perte de vie privée est utilisée contre nous, comme à chaque fois.
Où est-ce que les gens s’arrêtent un moment, qu’est-ce qui attire leur attention, qu’est-ce qui n’attire pas leur attention, qu’est-ce qui constitue un obstacle pour réaliser plus de ventes ?
Ce sont des questions légitimes. Cependant, retirer aux gens leur vie privée afin de répondre à ces questions n’est pas une méthode légitime pour y répondre.
Ce type de suivi individuel de masse a même été déployé à l’échelle de villes entières, ce qui s’est passé dans le silence le plus total jusqu’à ce que le Bureau de Vigilance pour la Vie Privée d’un gouvernement lointain sonne l’alarme. La ville de Västerås a obtenu le feu vert pour poursuivre le pistage une fois quelques critères de pure forme atteints.
Oui, le déploiement à l’échelle d’une ville de ce type de pistage dans au moins une petite ville d’un coin reculé du monde (Västerås, en Suède) est documenté. Maintenant que le Bureau de Vigilance pour la Vie Privée gouvernemental a haussé les épaules et dit « mouais, qu’importe », ne croyez pas que ça restera confiné à la petite ville de Västerås. Rectification, mauvais temps verbal : ne croyez pas que ce c’est resté qu’à Västerås, où le feu vert a été obtenu il y a trois ans.
Nos parents analogiques avaient le pouvoir de marcher sans être pistés dans la ville et dans la rue de leur choix, sans que cela soit utilisé ou retenu contre eux. Il n’est pas déraisonnable que nos enfants numériques aient le même pouvoir.
Il y a une autre façon d’acheter des choses avec du liquide qui permet d’éviter ce type de pistage, c’est le paiement comptant à la livraison à votre domicile lors de l’achat en ligne ou par téléphone. Dans ce cas, votre achat est aussi consigné et enregistré, simplement dans un autre type de système.
Tout ceci n’est pas seulement utilisé contre le citoyen ordinaire à des fins commerciales, évidemment. C’est utilisé contre le citoyen ordinaire à toutes fins possibles. Mais nous y reviendrons dans un article à venir de la série.
La vie privée demeure de votre responsabilité.
Des routes et des ponts (12) – en quête de modèle économique
Dans notre projet de traduction de l’ouvrage de Nadia Eghbal Roads and Bridges (tous les épisodes déjà traduits), nous abordons aujourd’hui une section importante consacrée aux modes de financement de ce qu’elle appelle l’infrastructure numérique et qui est comme l’épine dorsale de du monde informatique.
Elle donne ici un aperçu avec quelques exemples significatifs des trois principales voies explorées avec des succès variables par les développeurs et les entreprises : l’incitation par des récompenses, la monétisation par des services et le recours à des licences open source hybrides, en partie payantes…
Des modèles économiques pour les infrastructures numériques
Certains aspects des infrastructures numériques peuvent fonctionner dans un contexte concurrentiel. Les bases de données et les services d’hébergement, par exemple, sont souvent des affaires profitables, bien financées, parce qu’elles peuvent faire payer l’accès. Tout comme l’accès à l’eau ou à l’électricité, l’accès à un serveur ou à une base de données peut être mesuré, facturé, et fermé si les honoraires ne sont pas réglés.
Heroku (mentionné au début de ce rapport) et Amazon Web Services sont deux exemples notables de plateformes qui vendent des services d’infrastructure numérique à des développeurs logiciels contre une redevance (à noter qu’aucun des deux n’est un projet open source). Des projets open source similaires, à ce niveau d’infrastructure, tels que OpenStack (une plate-forme concurrente d’Amazon Web Services) ou MySQL (une base de données), ont trouvé leurs assises dans des entreprises. OpenStack est financé par un consortium d’entreprises, et MySQL a été racheté par Oracle.
Une partie de ce qui rend ces services financièrement attractifs, c’est l’absence de « bruit ». Pour un seul logiciel, un développeur utilise parfois 20 bibliothèques différentes, avec chacune des fonctions différentes, mais il n’a besoin que d’une seule base de données. En conséquence, les projets à succès ont plus de chances d’obtenir l’attention et le soin dont ils ont besoin.
Il existe une autre façon utile de cerner les infrastructures que l’on peut facturer : s’il y a un risque immédiat de défaillance, alors il y a probablement un modèle économique. En d’autres termes, un serveur peut subir des interruptions de service inattendues, tout comme l’électricité peut sauter à l’improviste, mais un langage de programmation ne « casse » ni n’a des périodes d’indisponibilités de cette même façon, parce qu’il s’agit d’un système d’information.
Pour ce genre de projets open source, le modèle économique a tendance à se focaliser sur la recherche de services ou d’assistance facturables. Cela fonctionne pour les projets qui bénéficient d’un usage significatif par les entreprises, en particulier quand il s’agit d’un problème techniquement complexe, ou lorsqu’une entreprise a besoin qu’une fonction soit développée.
Récompenses
Logo de Bountysource
À petite échelle, des gens ou des entreprises promettent parfois des « récompenses » d’ordre pécuniaire pour l’atteinte de certains objectifs de développement.
Par exemple, IBM demande régulièrement de nouvelles fonctionnalités pour divers projets par le biais d’un site web appelé Bountysource, offrant jusqu’à 5 000 $ par tâche. Bountysource est une plateforme populaire pour trouver et proposer des récompenses ; elle compte plus de 26 000 membres. 120 récompenses aident à régler les problèmes précédemment mentionnés liés aux simples dons à un projet. Comme les récompenses sont clairement liées à un résultat, l’argent va être utilisé. En revanche, les récompenses peuvent avoir des effets pervers pour l’incitation à contribuer à un projet.
Les récompenses peuvent dicter quel travail sera ou ne sera pas effectué, et parfois ce travail n’est pas en phase avec les priorités d’un projet. Il peut aussi introduire du bruit dans le système : par exemple, une entreprise peut offrir une forte récompense pour une fonctionnalité que les propriétaires du projet ne considèrent pas comme importante.
Du côté des contributeurs, des personnes extérieures sans connaissances sur un projet peuvent y participer seulement pour obtenir la récompense, puis le quitter. Ou bien elles peuvent bâcler le travail requis, parce qu’elles essaient d’obtenir des récompenses. Enfin, les récompenses peuvent être une façon appropriée de financer de nouvelles fonctionnalités ou des problèmes importants, mais sont moins pratiques lorsqu’il s’agit de financer des opérations continues, comme le service client ou la maintenance.
Jeff Atwood, le créateur de Stack Overflow, a remarqué les problèmes suivants avec les programmes de récompenses, en particulier en ce qui concerne la sécurité :
L’un des effets pervers de cette tendance à attribuer des récompenses pour les rapports de bugs est que cela n’attire pas seulement de véritables programmeurs intéressés par la sécurité, mais aussi tous les gens intéressés par l’argent facile. Nous avons reçu trop de rapports de bugs de sécurité « sérieux » qui n’avaient qu’une importance très faible. Et nous devons les traiter, parce qu’ils sont « sérieux », n’est-ce pas ? Malheureusement, beaucoup d’entre eux ne représentent qu’un gaspillage de temps… Ce genre d’incitation me semble mauvais. Même si je sais que la sécurité est extrêmement importante, je vois ces interactions avec de plus en plus d’inquiétude parce qu’elles me créent beaucoup de travail et que le retour sur investissement est très faible.
À une plus vaste échelle, un des exemples bien connus et les plus souvent cités de modèle économique open source, c’est Red Hat, l’entreprise dont nous avons déjà parlé, qui propose une assistance, des sessions de formation et autres services à des entreprises qui utilisent Linux. Red Hat a été fondée en 1993, il s’agit d’une entreprise cotée en bourse avec un chiffre d’affaires déclaré de 2 milliards de dollars par an.
Bien que Red Hat ait connu un succès fantastique d’un point de vue financier, nombreux sont ceux qui soulignent qu’il s’agit d’une anomalie qui n’aura pas de lendemains. Red Hat a bénéficié de l’avantage du premier arrivé dans son domaine technologique. Matt Asay, un journaliste spécialisé en open source, a remarqué que Red Hat utilise un ensemble unique de licences et brevets pour protéger ses parts de marché. Asay, qui auparavant était un fervent défenseur des entreprises open source, est maintenant persuadé que certaines licences propriétaires sont nécessaires pour faire sérieusement des affaires. Matthew Aslet du 451 Group, un organisme de recherche, a découvert lui aussi que la plupart des entreprises open source qui réussissent utilisent en fait un type ou un autre de licence commerciale.
Docker, déjà mentionné plus haut, est un projet open source qui aide les applications à fonctionner efficacement. C’est l’exemple le plus récent d’entreprise qui s’inspire de ce modèle. Docker a levé 180 millions de dollars en capital-risque auprès d’investisseurs, avec une valorisation d’un milliard de dollars de la part d’investisseurs privés. Comme sa part de marché s’est accrue, Docker a commencé à proposer des services d’assistance au niveau des entreprises. Mais sans solides revenus, Docker pourrait n’être qu’un exemple de plus de capital-risque qui fait un investissement dans une entreprise d’infrastructure leader sur son marché, mais qui réalise des pertes.
À petite échelle, beaucoup de développeurs proposent des services de consultants pour pouvoir financer leur travail. Hoodie est un framework poids plume qui repose sur Node et qui a réussi dans les services de consultants.
Hoodie lui-même est un projet open source. Plusieurs mainteneurs gagnent leur vie grâce à la boutique de l’entreprise, Neighbourhoodie, qui propose des services de développement logiciel. Bien que Neighbourhoodie se spécialise dans le framework de Hoodie, ce dernier est encore un projet plutôt jeune, de sorte que certaines parties de son travail proviennent de pojets qui ne sont pas lié à Hoodie. Dans le cas de Hoodie, le modèle de services choisi est censé payer le salaire de plusieurs mainteneurs, plutôt que de viser une stratégie d’entreprise de l’échelle de Red Hat.
Le conseil est une option viable pour les développeurs indépendants, s’il y a suffisamment de gens qui utilisent le projet qui sont d’accord et ont assez d’argent pour payer de l’aide supplémentaire. Mais à petite échelle, cela peut aussi les empêcher d’améliorer le projet lui-même, puisque les deux personnes au plus qui le maintiennent passent désormais leur temps à développer leur affaire et à fournir des services qui peuvent ou non être en accord avec les besoins du projet en termes de maintenance.
Aspirer à une activité de consultant peut aussi entrer en contradiction avec l’objectif de rendre le produit facile à utiliser et à appréhender, ce qui est bien dans l’esprit de l’open source. Twisted, la bibliothèque Python déjà citée, a mentionné un témoignage plein d’humour de l’un de ses utilisateurs, une entreprise nommée Mailman : « Les gars, vous avez un gros problème, parce que c’était vraiment trop facile ! Comment vous comptez vous faire un paquet d’argent juste avec du conseil ? 🙂 »
En fin de compte, le « modèle économique » pour un projet open source n’est pas très différent du simple travail indépendant.
Licences payantes
Certains développeurs ont l’impression que mettre les projets sous licence serait une solution au moins partielle aux problèmes de financement de l’open source. Si les projets open source sont fortement utilisés, pourquoi ne pas les facturer ? Ces « licences payantes » ne sont techniquement pas des licences open source, selon la définition de l’open source Initiative. Il s’agit plutôt d’initiatives qui tentent d’apporter un équilibre entre le besoin très concret de travail rémunéré et le désir de rendre le code accessible au public. Ce type de code peut être appelé « à source visible » ou « à source disponible ». Fair Source, par exemple, se décrit lui-même comme « [offrant] certains des avantages de l’open source tout en préservant la possibilité de faire payer pour le logiciel. »
La licence Fair Source fut créée en novembre 2015 par une entreprise appelée Sourcegraph pour répondre au besoin de licence payante. Les termes de la licence ont été rédigés par Heather Meeker, un juriste qui a également travaillé dans l’équipe principale de la Mozilla Public License v2.0. Avec la licence Fair Source, on peut librement consulter, télécharger, exécuter et modifier le code, jusqu’à un certain nombre d’utilisateurs par organisation. Une fois cette limite dépassée, l’organisation doit payer un forfait de licence, dont le montant est déterminé par l’éditeur. En d’autres termes, le code Fair Source est gratuit pour un usage personnel et pour les PME, mais fournit une base légale pour facturer les cas de plus gros usages commerciaux.
L’annonce par Sourcegraph de la création de la licence Fair Source, qu’ils utilisent maintenant eux-mêmes, a provoqué un débat animé sur la monétisation de l’open source. (Il est à noter qu’un mouvement similaire autour du « shareware », logiciel propriétaire gratuit, avait émergé avec un certain succès populaire dans les années 1980).
Mike Perham, l’un des mainteneurs de Sidekiq, un outil populaire pour le développement en Ruby, a aussi récemment suggéré aux contributeurs et contributrices open source d’utiliser une « licence duale » pour monétiser leur travail, faisant payer les entreprises l’accès à une licence MIT permissive plutôt qu’une licence AGPL plus restrictive qui impose l’attribution. Sa théorie est qu’en faisant d’AGPL la licence par défaut, « les entreprises vont payer pour l’éviter. »
Pour justifier cette idée, Perham a rappelé à son public :
« Souvenez-vous : logiciel open source ne signifie pas logiciel gratuit. Ce n’est pas parce que l’on peut consulter la source sur GitHub que tout le monde peut l’utiliser et en faire n’importe quoi. Il n’y a aucune raison pour laquelle vous ne pourriez pas donner l’accès à votre code mais aussi faire payer pour son utilisation. Tant que vous possédez le code, vous avez le droit d’y attribuer la licence que vous voulez. …[La] réalité, c’est que la plupart des petits projets open source dépendent d’une seule personne qui fait 95 % du travail. Si c’est votre cas, soyez reconnaissants envers les gens qui vous aident gratuitement mais ne vous sentez pas coupable de garder 100 % du revenu. »
Faire payer les entreprises offre une autre possibilité aux développeurs et développeuses qui souhaitent poursuivre leur travail, en particulier s’il n’y a qu’une ou deux personnes pour maintenir un projet actif. Cependant, tous les projets ne peuvent pas faire payer pour le travail fourni, en particulier les projets plus vieux, ou les projets d’infrastructure qui ressemblent plus à des biens publics qu’à des produits de consommation, comme les langages de programmation.
Même si les licences payantes peuvent fonctionner pour certains scénarios, ce modèle est aussi pour beaucoup en opposition avec l’énorme valeur sociale offerte par l’open source, qui suggère que lorsque le logiciel est libre, l’innovation suit.
L’objectif ne devrait pas être le retour à une société qui repose sur les logiciels fermés, où le progrès et la créativité sont limités, mais de soutenir de façon durable un écosystème public dans lequel le logiciel peut être créé et distribué librement.
Les anciens Léviathans I — Le contrat social fait 128 bits… ou plus
Qu’est-ce qui fait courir Framasoft ? De la campagne Dégooglisons à l’initiative C.H.A.T.O.N.S quelles idées ont en tête les acteurs et soutiens de l’association ? Vous reprendrez bien une tranche de Léviathan ?
Pour vous inviter à aller au-delà des apparences (la sympathique petite tribu d’amateurs gaulois qui veut modestement mettre son grain de sable dans la loi des entreprises hégémoniques) nous vous proposons non seulement un moment de réflexion, mais pour une fois une série de considérations nourries, argumentées et documentées sur l’état de bascule que nous vivons et dans lequel nous prétendons inscrire notre action avec vous.
Jamais le logiciel libre et les valeurs qu’il porte n’ont été autant à la croisée des chemins, car il ne s’agit pas de proposer seulement des alternatives techniques, c’est un défi économique et politique qu’il doit relever.
Entre les États qui nous surveillent et les GAFAM qui nous monétisent, jamais le refuge du secret, celui de l’intime, n’a été aussi attaqué ni menacé. Pour représenter le monstre à plusieurs têtes, Christophe Masutti qui est l’auteur de cette série de réflexions, a choisi la figure emblématique du Léviathan, forgée déjà par Hobbes en particulier pour désigner l’État toujours plus avide de domination.
C’est donc une série de Léviathans nouveaux et anciens que nous vous invitons à découvrir par étapes, tout au long de cette semaine, qui vous conduiront peut-être à comprendre et adopter notre démarche. Car une fois établies les sources du mal et posé le diagnostic, que faire ? Les perspectives que nous proposons seront peut-être les vôtres.
Note de l’auteur :
Chiffrer nos données est un acte censé protéger nos vies privées. Dans le contexte de la surveillance massive de nos communications, il devient une nécessité.
Mais peut-on mettre en balance la notion de vie privée et la paix entre tous que le contrat social est censé nous garantir ? Le prétendu choix entre liberté et sécurité tendrait à montrer que le pouvoir de l’État ne souffre aucune option. Et pourtant, les anciennes conceptions ont la vie dure.
Quand Manuel Valls s’exprime
Dans un article de RUE 89, le journaliste Andréa Fradin revenait sur une allocution du premier ministre M. Valls, tenue le 16 octobre 2015 à l’occasion de la présentation de la Stratégie nationale pour la sécurité numérique. Durant son discours, M. Valls tenait ces propos :
Mais – s’il était nécessaire de donner à nos services de renseignement les outils indispensables pour assumer leurs missions dans la société numérique – mon gouvernement reste favorable à ce que les acteurs privés continuent de bénéficier pleinement, pour se protéger, de toutes les ressources qu’offre la cryptologie légale.
Et le journaliste de s’interroger sur la signification de ce que pourrait bien être la « cryptologie légale », dans la mesure où le fait de pouvoir chiffrer des communications ne se pose pas en ces termes. Sur son site, l’ANSSI est très claire :
L’utilisation d’un moyen de cryptologie est libre. Il n’y a aucune démarche à accomplir.
En revanche, la fourniture, l’importation, le transfert intracommunautaire et l’exportation d’un moyen de cryptologie sont soumis, sauf exception, à déclaration ou à demande d’autorisation.
Si M. Valls s’adressait essentiellement aux professionnels des communications, une telle déclaration mérite que l’on s’y arrête un peu. Elle résonne particulièrement fort dans le contexte juridique, social et émotionnel très particulier qui a vu se multiplier l’adoption de lois et de procédures qui mettent fortement en danger les libertés de communication et d’expression, sous couvert de lutte contre le terrorisme, ainsi que l’illustrait le Projet de loi renseignement au printemps 2015.
Extrait de la conférence « Dégooglisons Internet »
On note que M. Valls précise que les moyens de « cryptologie légale » sont laissés au libre choix des acteurs privés « pour se protéger ». En effet, comme le rappelle l’ANSSI, le fait de fournir un moyen de chiffrer des communications doit faire l’objet d’une déclaration ou d’une autorisation. C’est uniquement dans le choix des systèmes préalablement autorisés, que M. Valls concède aux acteurs privés qui en ressentent le besoin d’aller piocher le meilleur moyen d’assurer la confidentialité et l’authenticité de leurs échanges ou des échanges de leurs utilisateurs.
C’est sans doute cela qu’il fallait comprendre dans cette phrase. À ceci près que rappeler ce genre d’éléments aussi basiques à des acteurs déjà bien établis dans le secteur des communications numériques, ressemble bien plutôt à une mise en garde : il y a du chiffrement autorisé et il y a du chiffrement qui ne l’est pas. En d’autres termes, du point de vue des fournisseurs comme du point de vue des utilisateurs, tout n’est pas permis, y compris au nom de la protection de la vie privée.
La question du choix entre respect de la vie privée (ou d’autres libertés comme les libertés d’expression et de communication) et l’intérêt suprême de l’État dans la protection de ses citoyens, est une question qui est à l’heure actuelle bien loin d’être tranchée (si elle peut l’être un jour). Habituellement caricaturée sur le mode binaire du choix entre sécurité et liberté, beaucoup ont essayé ces derniers temps de calmer les ardeurs des partisans des deux camps, en oubliant comme nous le verrons dans les prochaines sections, que le choix datait d’au moins des premiers théoriciens du Contrat Social, il y a trois siècles. L’histoire de PGP (Pretty Good Privacy) et du standard OpenPGP est jalonnée de cette dualité (sécurité et liberté) dans notre conception du contrat social.
Autorité et PGP
La première diffusion de PGP était déjà illégale au regard du droit à l’exportation des produits de chiffrement, ce qui a valu à son créateur, Philip Zimmermann quelques ennuis juridiques au début des années 1990. La France a finalement suivi la politique nord-américaine concernant PGP en autorisant l’usage mais en restreignant son étendue. C’est l’esprit du décret 99-200 du 17 mars 1999, qui autorise, sans formalité préalable, l’utilisation d’une clé de chiffrement à condition qu’elle soit inférieure ou égale à 128 bits pour chiffrer des données. Au-delà, il fallait une autorisation jusqu’au vote de la Loi sur l’économie numérique en 2004, qui fait sauter le verrou des 128 bits (art. 30-1) pour l’usage du chiffrement (les moyens, les logiciels, eux, sont soumis à déclaration1).
Si l’on peut aisément mettre le doigt sur les lacunes du système PGP2, il reste qu’une clé de chiffrement à 128 bits, si l’implémentation est correcte, permet déjà de chiffrer très efficacement des données, quelles qu’elles soient. Lorsque les activités de surveillance de masse de la NSA furent en partie révélées par E. Snowden, on apprit que l’une des pratiques consiste à capter et stocker les contenus des communications de manière exhaustive, qu’elles soient chiffrées ou non. En cas de chiffrement, la NSA compte sur les progrès techniques futurs pour pouvoir les déchiffrer un jour où l’autre, selon les besoins. Ce gigantesque travail d’archivage réserve en principe pour l’avenir des questions de droit plutôt inextricables (par exemple l’évaluation du degré de préméditation d’un crime, ou le fait d’être suspect parce qu’on peut établir que 10 ans plus tôt Untel était en relation avec Untel). Mais le principal sujet, face à ce gigantesque travail d’espionnage de tout l’Internet, et d’archivage de données privées lisibles et illisibles, c’est de savoir dans quelle mesure il est possible de réclamer un peu plus que le seul respect de la vie privée. Pour qu’une agence d’État s’octroie le droit de récupérer dans mon intimité des données qu’elle n’est peut-être même pas capable de lire, en particulier grâce à des dispositifs comme PGP, il faut se questionner non seulement sur sa légitimité mais aussi sur la conception du pouvoir que cela suppose.
Si PGP a finalement été autorisé, il faut bien comprendre quelles en sont les limitations légales. Pour rappel, PGP fonctionne sur la base du binôme clé publique / clé privée. Je chiffre mon message avec ma clé de session, générée aléatoirement à 128 bits (ou plus), et cette clé de session est elle-même chiffrée avec la clé publique du destinataire (qui peut largement excéder les 128 bits). J’envoie alors un paquet contenant a) le message chiffré avec ma clé de session, et b) ma clé de session chiffrée par la clé publique de mon destinataire. Puis, comme ce dernier possède la clé privée qui va de pair avec sa clé publique, lui seul va pouvoir déchiffrer le message. On comprend donc que la clé privée et la clé publique ont des rôles bien différents. Alors que la clé privée sert à chiffrer les données, la clé publique sert contrôler l’accès au contenu chiffré. Dans l’esprit du décret de 1999, c’est la clé de session qui était concernée par la limitation à 128 bits.
PGP a donc été autorisé pour au moins trois raisons, que je propose ici à titre de conjectures :
parce que PGP devenait de plus en plus populaire et qu’il aurait été difficile d’en interdire officiellement l’usage, ce qui aurait supposé une surveillance de masse des échanges privés (!),
parce que PGP est une source d’innovation en termes de services et donc porteur d’intérêts économiques,
parce que PGP, limité en chiffrement des contenus à 128 bits, permettait d’avoir un étalon de mesure pour justifier la nécessité de délivrer des autorisations pour des systèmes de chiffrement supérieurs à 128 bits, c’est-à-dire des chiffrements hautement sécurisés, même si la version autorisée de PGP est déjà très efficace. Après 2004, la question ne se pose plus en termes de limitation de puissance mais en termes de surveillance des moyens (ce qui compte, c’est l’intention de chiffrer et à quel niveau).
En somme c’est une manière pour l’État de retourner à son avantage une situation dans laquelle il se trouvait pris en défaut. Je parle en premier lieu des États-Unis, car j’imagine plutôt l’État français (et les États européens en général) en tant que suiveur, dans la mesure où si PGP est autorisé d’un côté de l’Atlantique, il aurait été de toute façon contre-productif de l’interdire de l’autre. En effet, Philip Zimmermann rappelle bien les enjeux dans son texte « Pourquoi j’ai écrit PGP ». La principale raison qui justifie selon lui l’existence de PGP, est qu’une série de dispositions légales entre 1991 et 1994 imposaient aux compagnies de télécommunication américaines de mettre en place des dispositions permettant aux autorités d’intercepter en clair des communications. En d’autres termes, il s’agissait d’optimiser les dispositifs de communication pour faciliter leur accès par les services d’investigation et de surveillance aujourd’hui tristement célèbres. Ces dispositions légales ont été la cause de scandales et furent en partie retirés, mais ces intentions cachaient en vérité un programme bien plus vaste et ambitieux. Les révélations d’E. Snowden nous en ont donné un aperçu concret il y a seulement deux ans.
Inconstitutionnalité de la surveillance de masse
Là où l’argumentaire de Philip Zimmermann devient intéressant, c’est dans la justification de l’intention de créer PGP, au delà de la seule réaction à un contexte politique dangereux. Pour le citer :
[…] Il n’y a rien de mal dans la défense de votre intimité. L’intimité est aussi importante que la Constitution. Le droit à la vie privée est disséminé implicitement tout au long de la Déclaration des Droits. Mais quand la Constitution des États-Unis a été bâtie, les Pères Fondateurs ne virent aucun besoin d’expliciter le droit à une conversation privée. Cela aurait été ridicule. Il y a deux siècles, toutes les conversations étaient privées. Si quelqu’un d’autre était en train d’écouter, vous pouviez aller tout simplement derrière l’écurie et avoir une conversation là. Personne ne pouvait vous écouter sans que vous le sachiez. Le droit à une conversation privée était un droit naturel, non pas seulement au sens philosophique, mais au sens des lois de la physique, étant donné la technologie de l’époque. Mais avec l’arrivée de l’âge de l’information, débutant avec l’invention du téléphone, tout cela a changé. Maintenant, la plupart de nos conversations sont acheminées électroniquement. Cela permet à nos conversations les plus intimes d’être exposées sans que nous le sachions.
L’évocation de la Constitution des États-Unis est tout à fait explicite dans l’argumentaire de Philip Zimmermann, car la référence à laquelle nous pensons immédiatement est le Quatrième amendement (de la Déclaration des Droits) :
Le droit des citoyens d’être garantis dans leurs personne, domicile, papiers et effets, contre les perquisitions et saisies non motivées ne sera pas violé, et aucun mandat ne sera délivré, si ce n’est sur présomption sérieuse, corroborée par serment ou affirmation, ni sans qu’il décrive particulièrement le lieu à fouiller et les personnes ou les choses à saisir.
En d’autres termes, la surveillance de masse est anticonstitutionnelle. Et cela va beaucoup plus loin qu’une simple affaire de loi. Le Quatrième amendement repose essentiellement sur l’adage très britannique my home is my castle, c’est à dire le point de vue de la castle doctrine, une rémanence du droit d’asile romain (puis chrétien). C’est-à-dire qu’il existe un lieu en lequel toute personne peut trouver refuge face à l’adversité, quelle que soit sa condition et ce qu’il a fait, criminel ou non. Ce lieu pouvant être un temple (c’était le cas chez les Grecs), un lieu sacré chez les romains, une église chez les chrétiens, et pour les peuples qui conféraient une importance viscérale à la notion de propriété privée, comme dans l’Angleterre du XVIe siècle, c’est la demeure. La naissance de l’État moderne (et déjà un peu au Moyen Âge) encadra fondamentalement ce droit en y ajoutant des conditions d’exercice, ainsi, par exemple, dans le Quatrième Amendement, l’existence ou non de « présomptions sérieuses ».
Le besoin de limiter drastiquement ce qui ressort de la vie privée, est éminemment lié à la conception de l’État moderne et du contrat social. En effet, ce qui se joue à ce moment de l’histoire, qui sera aussi celui des Lumières, c’est une conception rationnelle de la vie commune contre l’irrationnel des temps anciens. C’est Thomas Hobbes qui, parmi les plus acharnés du pouvoir absolu de l’État, traumatisé qu’il était par la guerre civile, pensait que rien ne devait entraver la survie et l’omnipotence de l’État au risque de retomber dans les âges noirs de l’obscurantisme et du déchaînement des passions. Pour lui, le pacte social ne tient que dans la mesure où, pour le faire respecter, l’État peut exercer une violence incommensurable sur les individus qui composent le tissu social (et ont conféré à l’État l’exercice de cette violence). Le pouvoir de l’État s’exerce par la centralisation et la soumission à l’autorité, ainsi que le résume très bien Pierre Dockès dans son article « Hobbes et le pouvoir »3.
Mais qu’est-ce qui était irrationnel dans ces temps anciens, par exemple dans la République romaine ? Beaucoup de choses à vrai dire, à commencer par le polythéisme. Et justement, l’asylum latin fait partie de ces conceptions absolues contre lesquelles les théoriciens du contrat social se débattront pour trouver des solutions. L’État peut-il ou non supporter l’existence d’un lieu où son pouvoir ne pourrait s’exercer, en aucun cas, même s’il existe des moyens techniques pour le faire ? C’est le tabou, dans la littérature ethnologique, dont la transgression oblige le transgresseur à se soumettre à une forme d’intervention au-delà de la justice des hommes, et par là oblige les autres hommes à l’impuissance face à cette transgression innommable et surnaturelle.
À cet absolu générique s’opposent donc les limitations de l’État de droit. Dans le Code Civil français, l’article 9 stipule : « Chacun a droit au respect de sa vie privée. Tout est dans la notion de respect, que l’on oublie bien vite dans les discussions, ici et là, autour des conditions de la vie privée dans un monde numérique. La définition du respect est une variable d’ajustement, alors qu’un absolu ne se discute pas. Et c’est cette soif d’absolu que l’on entend bien souvent réclamée, car il est tellement insupportable de savoir qu’un ou plusieurs États organisent une surveillance de masse que la seule réaction proportionnellement inverse que peuvent opposer les individus au non-respect de la vie privée relève de l’irrationnel : l’absolu de la vie privée, l’idée qu’une vie privée est non seulement inviolable mais qu’elle constitue aussi l’asylum de nos données numériques.
Qu’il s’agisse de la vie privée, de la propriété privée ou de la liberté d’expression, à lire la Déclaration des droits de l’homme et du citoyen de 1789, elles sont toujours soumises à deux impératifs. Le premier est un dérivé de l’impératif catégorique kantien : « ne fais pas à autrui ce que tu n’aimerais pas qu’on te fasse » (article 4 de la Déclaration), qui impose le pouvoir d’arbitrage de l’État (« Ces bornes ne peuvent être déterminées que par la Loi ») dans les affaires privées comme dans les affaires publiques. L’autre impératif est le principe de souveraineté (article 3 de la Déclaration) selon lequel « Le principe de toute Souveraineté réside essentiellement dans la Nation. Nul corps, nul individu ne peut exercer d’autorité qui n’en émane expressément ». En d’autres termes, il faut choisir : soit les règles de l’État pour la paix entre les individus, soit le retour à l’âge du surnaturel et de l’immoralité.
À l’occasion du vote concernant la Loi Renseignement, c’est en ces termes que furent posés nombre de débats autour de la vie privée sous l’apparent antagonisme entre sécurité et liberté. D’un côté, on opposait la loi comme le moyen sans lequel il ne pouvait y avoir d’autre salut qu’en limitant toujours plus les libertés des individus. De l’autre côté, on voyait la loi comme un moyen d’exercer un pouvoir à d’autres fins (ou profits) que la paix sociale : maintenir le pouvoir de quelques uns ou encore succomber aux demandes insistantes de quelques lobbies.
Mais très peu se sont penché sur la réaction du public qui voyait dans les révélations de Snowden comme dans les lois « scélérates » la transgression du tabou de la vie privée, de l’asylum. Comment ? Une telle conception archaïque n’est-elle pas depuis longtemps dépassée ? Il y aurait encore des gens soumis au diktat de la Révélation divine ? et après tout, qu’est-ce qui fait que j’accorde un caractère absolu à un concept si ce n’est parce qu’il me provient d’un monde d’idées (formelles ou non) sans être le produit de la déduction rationnelle et de l’utilité ? Cette soif d’absolu, si elle ne provient pas des dieux, elle provient du monde des idées. Or, si on en est encore à l’opposition Platon vs. Aristote, comment faire la démonstration de ce qui n’est pas démontrable, savoir : on peut justifier, au nom de la sécurité, que l’État puisse intervenir dans nos vie privées, mais au nom de quoi justifier le caractère absolu de la vie privée ? Saint Augustin, au secours !
À ceci près, mon vieil Augustin, que deux éléments manquent encore à l’analyse et montrent qu’en réalité le caractère absolu du droit à la vie privée, d’où l’État serait exclu quelle que soit sa légitimité, a muté au fil des âges et des pratiques démocratiques.
Dialogue entre droit de savoir et droit au secret
C’est l’autorité judiciaire qui exerce le droit de savoir au nom de la manifestation de la vérité. Et à l’instar de la vie privée, la notion de vérité possède un caractère tout aussi absolu. La vie privée manifeste, au fond, notre soif d’exercer notre droit au secret. Ses limites ? elles sont instituées par la justice (et particulièrement la jurisprudence) et non par le pouvoir de l’État. Ainsi le Rapport annuel 2010 de la Cour de Cassation exprime parfaitement le cadre dans lequel peut s’exercer le droit de savoir en rapport avec le respect de la vie privée :
Dans certains cas, il peut être légitime de prendre connaissance d’une information ayant trait à la vie privée d’une personne indépendamment de son consentement. C’est dire qu’il y a lieu de procéder à la balance des intérêts contraires. Un équilibre doit être trouvé, dans l’édification duquel la jurisprudence de la Cour de cassation joue un rôle souvent important, entre le droit au respect de la vie privée et des aspirations, nombreuses, à la connaissance d’informations se rapportant à la vie privée d’autrui. Lorsqu’elle est reconnue, la primauté du droit de savoir sur le droit au respect de la vie privée se traduit par le droit de prendre connaissance de la vie privée d’autrui soit dans un intérêt privé, soit dans l’intérêt général.
En d’autres termes, il n’y a aucun archaïsme dans la défense de la vie privée face à la décision publique : c’est simplement que le débat n’oppose pas vie privée et sécurité, et en situant le débat dans cette fausse dialectique, on oublie que le premier principe de cohésion sociale, c’est la justice. On retrouve ici aussi tous les contre-arguments avancés devant la tendance néfaste des gouvernements à vouloir automatiser les sanctions sans passer par l’administration de la justice. Ainsi, par exemple, le fait de se passer d’un juge d’instruction pour surveiller et sanctionner le téléchargement « illégal » d’œuvres cinématographiques, ou de vouloir justifier la surveillance de toutes les communications au nom de la sécurité nationale au risque de suspecter tout le monde. C’est le manque (subi ou consenti) de justice qui conditionne toutes les dictatures.
Le paradoxe est le suivant: en situant le débat sur le registre sécurité vs. liberté, au nom de l’exercice légitime du pouvoir de l’État dans la protection des citoyens, on place le secret privé au même niveau que le secret militaire et stratégique, et nous serions alors tous des ennemis potentiels, exactement comme s’il n’y avait pas d’État ou comme si son rôle ne se réduisait qu’à être un instrument de répression à disposition de quelques-uns contre d’autres, ou du souverain contre la Nation. Dans ce débat, il ne faudrait pas tant craindre le « retour à la nature » mais le retour à la servitude.
Le second point caractéristique du droit de savoir, est qu’on ne peut que lui opposer des arguments rationnels. S’il s’exerce au nom d’un autre absolu, la vérité, tout l’exercice consiste à démontrer non pas le pourquoi mais le comment il peut aider à atteindre la vérité (toute relative qu’elle soit). On l’autorise alors, ou pas, à l’aune d’un consentement éclairé et socialement acceptable. On entre alors dans le règne de la déduction logique et de la jurisprudence. Pour illustrer cela, il suffit de se pencher sur les cas où les secrets professionnels ont été cassés au nom de la manifestation de la vérité, à commencer par le secret médical. La Cour de cassation explique à ce sujet, dans son Rapport 2010 :
[…] La chambre criminelle a rendu le 16 février 2010 (Bull. crim. 2010, no 27, pourvoi no 09-86.363) une décision qui, entre les droits fondamentaux que sont la protection des données personnelles médicales d’une part, et l’exercice des droits de la défense d’autre part, a implicitement confirmé l’inopposabilité du secret au juge d’instruction, mais aussi la primauté du droit de la défense qui peut justifier, pour respecter le principe du contradictoire, que ce secret ne soit pas opposable aux différentes parties.
Au risque de rappeler quelques principes évidents, puisque nous sommes censés vivre dans une société rationnelle, toute tentative de casser un secret et s’immiscer dans la vie privée, ne peut se faire a priori que par décision de justice à qui l’on reconnaît une légitimité « prudentielle ». Confier ce rôle de manière unilatérale à l’organe d’exercice du pouvoir de l’État, revient à nier ce partage entre l’absolu et le rationnel, c’est à dire révoquer le contrat social.
La sûreté des échanges est un droit naturel et universel
Comme le remarquait Philip Zimmermann, avant l’invention des télécommunications, le droit à avoir une conversation privée était aussi à comprendre comme une loi physique : il suffisait de s’isoler de manière assez efficace pour pouvoir tenir des échanges d’information de manière complètement privée. Ce n’est pas tout à fait exact. Les communications ont depuis toujours été soumises au risque de la divulgation, à partir du moment où un opérateur et/ou un dispositif entrent en jeu. Un rouleau de parchemin ou une lettre cachetée peuvent toujours être habilement ouverts et leur contenu divulgué. Et d’ailleurs la principale fonction du cachet n’était pas tant de fermer le pli que de l’authentifier.
C’est pour des raisons de stratégie militaire, que les premiers chiffrements firent leur apparition. Créés par l’homme pour l’homme, leur degré d’inviolabilité reposait sur l’habileté intellectuelle de l’un ou l’autre camp. C’est ainsi que le chiffrement ultime, une propriété de la nature (du moins, de la logique algorithmique) a été découvert : le chiffre de Vernam ou système de chiffrement à masque jetable. L’idée est de créer un chiffrement dont la clé (ou masque) est aussi longue que le message à chiffrer, composée de manière aléatoire et utilisable une seule fois. Théoriquement impossible à casser, et bien que présentant des lacunes dans la mise en œuvre pratique, cette méthode de chiffrement était accessible à la puissance de calcul du cerveau humain. C’est avec l’apparition des machines que les dés ont commencés à être pipés, sur trois plans :
en dépassant les seules capacités humaines de calcul,
en rendant extrêmement rapides les procédures de chiffrement et de déchiffrement,
en rendant accessibles des outils puissants de chiffrement à un maximum d’individus dans une société « numérique ».
Dans la mesure où l’essentiel de nos communications, chargées de données complexes et à grande distance, utilisent des machines pour être produites (ou au moins formalisées) et des services de télécommunications pour être véhiculées, le « droit naturel » à un échange privé auquel faisait allusion Philip Zimmermann, passe nécessairement par un système de chiffrement pratique, rapide et hautement efficace. PGP est une solution (il y en a d’autres).
PGP est-il efficace ? Si le contrôle de l’accès à nos données peut toujours nous échapper (comme le montrent les procédures de surveillance), le chiffrement lui-même, ne serait-ce qu’à 128 bits « seulement », reste à ce jour assez crédible. Cette citation de Wikipédia en donne la mesure :
À titre indicatif, l’algorithme AES, dernier standard d’algorithme symétrique choisi par l’institut de standardisation américain NIST en décembre 2001, utilise des clés dont la taille est au moins de 128 bits soit 16 octets, autrement dit il y en a 2128. Pour donner un ordre de grandeur sur ce nombre, cela fait environ 3,4×1038 clés possibles ; l’âge de l’univers étant de 1010 années, si on suppose qu’il est possible de tester 1 000 milliards de clés par seconde (soit 3,2×1019 clés par an), il faudra encore plus d’un milliard de fois l’âge de l’univers. Dans un tel cas, on pourrait raisonnablement penser que notre algorithme est sûr. Toutefois, l’utilisation en parallèle de très nombreux ordinateurs, synchronisés par internet, fragilise la sécurité calculatoire.
Les limites du chiffrement sont donc celles de la physique et des grands nombres, et à ce jour, ce sont des limites déjà largement acceptables. Tout l’enjeu, désormais, parce que les États ont montré leur propension à retourner l’argument démocratique contre le droit à la vie privée, est de disséminer suffisamment les pratiques de chiffrement dans le corps social. Ceci de manière à imposer en pratique la communication privée-chiffrée comme un acte naturel, un libre choix qui borne, en matière de surveillance numérique, les limites du pouvoir de l’État à ce que les individus choisissent de rendre privé et ce qu’ils choisissent de ne pas protéger par le chiffrement.
Conclusion
Aujourd’hui, la définition du contrat social semble passer par un concept supplémentaire, le chiffrement de nos données. L’usage libre des pratiques de chiffrement est borné officiellement à un contrôle des moyens, ce qui semble suffisant, au moins pour nécessiter des procédures judiciaires bien identifiées dans la plupart des cas où le droit de savoir s’impose. Idéalement, cette limite ne devrait pas exister et il devrait être possible de pouvoir se servir de systèmes de chiffrement réputés inviolables, quel que soit l’avis des gouvernements.
L’inviolabilité est une utopie ? pas tant que cela. En 2001, le chercheur Michael Rabin avait montré lors d’un colloque qu’un système réputé inviolable était concevable. En 2005, il a publié un article éclairant sur la technique de l’hyper-chiffrement (hyper encryption) intitulé « Provably unbreakable hyper-encryption in the limited access model », et une thèse (sous la direction de M. Rabin) a été soutenue en 2009 par Jason K. Juang, librement accessible à cette adresse. Si les moyens pour implémenter de tels modèles sont limités à ce jour par les capacités techniques, la sécurité de nos données semble dépendre de notre volonté de diminuer davantage ce qui nous sépare d’un système 100% efficace d’un point de vue théorique.
Le message de M. Valls, à propos de la « cryptologie légale » ne devrait pas susciter de commentaires particuliers puisque, effectivement, en l’état des possibilités techniques et grâce à l’ouverture de PGP, il est possible d’avoir des échanges réputés privés à défaut d’être complètement inviolables. Néanmoins, il faut rester vigilant quant à la tendance à vouloir définir légalement les conditions d’usage du chiffrement des données personnelles. Autant la surveillance de masse est (devrait être) inconstitutionnelle, autant le droit à chiffrer nos données doit être inconditionnel.
Doit-on craindre les pratiques d’un gouvernement plus ou moins bien intentionné ? Le Léviathan semble toutefois vaciller : non pas parce que nous faisons valoir en droit notre intimité, mais parce que d’autres Léviathans se sont réveillés, en dehors du droit et dans une nouvelle économie, sur un marché dont ils maîtrisent les règles. Ces nouveaux Léviathans, il nous faut les étudier avec d’autres concepts que ceux qui définissent l’État moderne.
On peut se reporter au site de B. Depail (Univ. Marne-La-Vallée) de qui expose les aspects juridiques de la signature numérique, en particulier la section « Aspects juridiques relatifs à la cryptographie ».↩
Pierre Dockès, « Hobbes et le pouvoir », Cahiers d’économie politique, 50.1, 2006, pp. 7-25.↩
Hackadon du 11/12/13 Donnez au Libre ! Entretien avec Bastien Guerry
Bastien Guerry co-organise l’événement « 111213 » qui aura lieu le 11 décembre 2013 à simplon.co à Montreuil, une soirée où les internautes sont invités à soutenir des logiciels libres avec des dons. Nous lui avons posé quelques questions pour comprendre le pourquoi et le comment.
Peux-tu te présenter en deux mots ?
Je m’appelle Bastien Guerry. J’ai découvert le libre en 2000 via Thierry Stoehr, alors vice-président de l’AFUL, et en lisant le recueil d’articles de Florent Latrive et Olivier Blondeau intitulé « Libres enfants du savoir numérique », paru aux éditions de l’Éclat en 2001. Depuis, je suis devenu contributeur de GNU Emacs.
La programmation, simple passe-temps, est peu à peu devenu une passion. Quand j’ai reçu des dons pour mon implication comme mainteneur d’un logiciel, ça a fait « tilt » : je me suis dit qu’il fallait que j’aide d’autres développeurs à recevoir plus de dons. C’est à ça que je consacre aujourd’hui mon énergie avec le projet http://kickhub.com
Tu lances avec d’autres un « hackadon » le 11 décembre. C’est quoi ?
C’est une soirée pour faire des dons à des projets libres, pour recenser les différentes façons de le faire et pour réfléchir ensemble au sens de ce geste.
Depuis quelques années, un bandeau s’affiche tous les ans sur les pages de Wikipédia pendant les campagnes de dons de la Wikimedia Foundation et de Wikimédia France. Cela a permis aux gens de se rendre compte que le sort de l’encyclopédie était entre leurs mains, et que même ceux qui ne contribuent pas directement peuvent jouer un rôle, celui de soutenir l’infrastructure technique et le mouvement Wikimédia.
Pour les logiciels libres, c’est différent. D’abord parce que bon nombre d’entre eux sont en partie financés par des entreprises ; ensuite parce qu’il n’y a pas de canal de communication unique pour solliciter des dons, les demandes avancent en ordre dispersé.
Mais imaginons une campagne qui rassemble des logiciels populaires comme Firefox, LibreOffice et VLC. Qui ne serait pas sensible à un message du genre : « Pour continuer de développer ces logiciels et pour rester indépendants, nous avons besoin de votre soutien ! » Je crois qu’une telle démarche aurait du succès et permettrait à chacun de comprendre qu’il peut être utile, non pas comme développeur, mais comme soutien ; qu’il y a encore plein de logiciels dont la survie dépend de la bonne volonté des contributeurs, et qu’en général, les entreprises ne devraient pas être seules à en assurer le financement.
Le Hackadon du 11 décembre est une première tentative de sensibilisation.
Pourquoi maintenant ?
Le déclic a été pour moi d’assister à la montée en volume du financement participatif ces deux dernières années. Ce que les gens ont l’air d’apprécier dans ces modes de financement (un contact direct avec le porteur de projet, des nouvelles régulières sur ses avancées, etc.) c’est ce qu’on fait dans les projets libres depuis toujours !
On voit de plus en plus de projets libres sur les plates-formes comme kickstarter.com, la dernière campagne pour le Ubuntu Edge a beaucoup fait parler d’elle — et pour cause : il y a une affinité naturelle entre ce mode de financement et le mode de développement du libre.
Mais le préalable est que chacun comprenne qu’en soutenant un projet libre, même modestement, il donne du temps et de l’indépendance à son développeur. Et je crois qu’aujourd’hui les mentalités sont mûres pour cette prise de conscience.
Cette soirée s’adresse à qui ?
À tous ! Nous aurons à manger et à boire pour tous les invités qui se déplaceront jusqu’à Montreuil (l’événement a lieu à Simplon.co, qui co-organise l’événement), et le message s’adresse à Monsieur et Madame Toutlemonde. Pour qu’ils comprennent la différence entre un logiciel gratuit et un logiciel libre. Et qu’ils se disent : « Mais bon sang mais c’est bien sûr, un freeware c’est juste de la publicité, alors qu’un logiciel libre c’est ma liberté ! »
Nous invitons aussi tous les développeurs qui souhaitent solliciter des dons — la soirée sera ponctuée de présentations de donateurs qui expliquent pourquoi ils donnent et de développeurs qui partagent leur passion.
Vous avez un objectif précis ?
Assez : atteindre un beau score final et passer une soirée riche de témoignages et d’échanges !
Est-ce qu’il y aura une suite ?
J’ai un peu cherché mais je n’ai pas vu d’événement du même type.
J’espère que ce hackadon donnera envie à d’autres d’en organiser. La formule est simple : se réunir pour donner à des logiciels libres. Un geste qu’on fait parfois dans son coin, mais qui prend encore plus de sens quand on explique à d’autres pourquoi on le fait.
Donc les suites possibles, ce sont d’autres hackadons ailleurs : croisons les doigts !
As-tu un rêve pour l’avenir du libre ?
Je ne veux plus voir de libriste faire du propriétaire le jour et du libre la nuit. Je ne veux plus voir de libriste dire qu’il abandonne la maintenance d’un projet parce qu’il vient d’avoir un enfant.
La main invisible du marché logiciel a tout intérêt à laisser les utilisateurs confondre le libre et le gratuit ; mais cette main, on risque à tout moment de se la prendre dans la figure tant qu’on ne donne pas plus d’indépendance aux développeurs.
C’est sûr, il y aura toujours plus de bénévoles que de donateurs, car donner de l’argent est rarement une passion. Mais Wikipédia montre l’exemple : on peut rétablir, peu à peu, la balance !
0,12 % des utilisateurs de GitHub proviennent d’Afrique !
Y aurait-il moins de 5000 développeurs libres sur tout le continent africain (4527 pour être plus précis) ?
C’est ce qu’on peut lire sur cette intéressante carte interactive intitulée GitHub Africa Users. Leur auteurs (non africains) ont en effet collecté, en mars dernier, les données des utilisateurs de la plateforme qui avaient renseigné leur localisation (et uniquement ceux-ci) en nous présentant cela à l’aide de MapBox.
A partir de là un certain nombre de questions se posent pour nuancer ce chiffre :
Est-ce les utilisateurs africains de GitHub se localisent moins que les autres ?
Est-ce qu’un utilisateur de GitHub est nécessairement un développeur qui fait du libre ?
Est-ce que les développeurs libres africains utilisent GitHub ?
Est-ce que les développeurs libres africains voudraient utiliser GitHub mais en sont empêchés à cause de la faiblesse de leur connexion à Internet ?
Combien y a-t-il de développeurs non libres en Afrique ?
Il n’empêche que cela reste tout de même inquiétant.
Qu’en pensez-vous ?
Cent fois sur le métier remettez vos correctifs… (Libres conseils 12/42)
Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.
Kai Blin est un bio-informaticien qui mène des recherches sur les antibiotiques dans le cadre de ses activités quotidiennes, tant sur ordinateur qu’au labo. Il est très heureux de pouvoir diffuser le logiciel développé dans le cadre de ses activités professionnelles sous licence open source. Vivant dans la charmante ville de Tübingen, dans le sud de l’Allemagne, Kai passe une partie de ses soirées sur l’ordinateur, à programmer pour le projet Samba. Il consacre la majorité de son temps libre restant au théâtre, où il participe aussi bien à la performance scénique qu’à la construction d’accessoires et à la régie technique dans les coulisses.
Écrire des correctifs et les proposer est souvent la première interaction concrète que vous pouvez avoir avec un projet open source. C’est la première impression que vous donnez aux développeurs présents. Proposer de « bons » premiers correctifs, ou tout du moins jugés comme tels par le projet auquel vous contribuez, vous rendra la vie plus facile. Les règles précises d’écriture du correctif, de la façon de le soumettre au projet et tous les autres détails nécessaires vont sans doute varier selon les divers projets auxquels vous voulez contribuer. Mais j’ai trouvé quelques règles générales que l’on retrouve presque à chaque fois. Et c’est ce dont traite cet article.
Comment tout foirer
Le fil rouge de ce livre est « ce que j’aurais aimé savoir avant de commencer », aussi permettez-moi de commencer par l’histoire de mes premiers correctifs. J’ai été impliqué sérieusement dans l’écriture de code pour la première fois pendant le Google Summer of Code™ de 2005. Le projet Wine avait accepté que j’implémente un chiffrement NTLM basé sur des outils connexes à Samba. Wine est un projet à committer unique, ce qui signifie que seul le développeur principal, Alexandre Julliard, possède les autorisations de commit sur le dépôt principal. En 2005, Wine utilisait encore CVS comme système de gestion de versions. Quand le projet a démarré et que j’ai reçu le courriel me disant que j’étais accepté, j’ai contacté mon mentor sur IRC et me suis mis au travail.
J’alignais joyeusement les lignes de code et bientôt j’ai pu implémenter les premières fonctionnalités. J’ai produit un correctif et l’ai soumis à mon mentor pour qu’il fasse une relecture. Au temps du CVS, il fallait renseigner toutes les options de diff(1) manuellement, mais je m’étais particulièrement documenté sur la partie cvs diff -N -u > ntlm.patch. De cette façon, j’avais le fichier que je pouvais envoyer à mon mentor. En fait, c’est quelque chose que j’ai bien fait. Et c’est la première chose que vous devriez prendre en compte quand vous préparez un correctif. Le résultat classique de la commande diff est sans doute plus facile à lire pour un ordinateur, mais je n’ai jamais rencontré un humain préférant le résultat classique au résultat d’un diff unifié. Grâce à l’option -u , diff utilise les notations + + + et - - -
Par exemple, le diff qui suit est le résultat de la réécriture de « Hello, World! » en Python, version suédoise.
La ligne qui commence par « - » est la ligne supprimée, celle qui commence par « + » est celle qui va être ajoutée. Les autres lignes permettent à l’outil de correction de faire son travail.
J’ai envoyé le diff unifié que je venais de créer à mon mentor qui m’en a fait une review(2) en me signalant beaucoup d’éléments à modifier. J’ai effectué les corrections et lui ai renvoyé un nouveau diff peu de temps après. Le cycle d’analyse du code a continué durant toute la durée du GSoC et mon correctif ne cessait de grossir. Quand la date de livraison est arrivée, je me suis retrouvé avec un correctif monstrueux dans lequel étaient inclus tous mes changements. Naturellement, j’ai eu beaucoup de mal à obtenir une review de mon correctif, sans parler de le faire accepter. Pour finir, Alexandre refusa de regarder plus avant le correctif tant que je ne l’aurais pas scindé. Les règles en usage chez Wine exigent que les correctifs soient de petites étapes logiques ajoutant une fonctionnalité. Chaque correctif doit faire quelque chose d’utile et pouvoir être compilé.
De fait, scinder un énorme correctif existant en différentes parties cohérentes individuellement et qui peuvent être compilées représente beaucoup de travail. C’était même d’autant plus de travail que je ne connaissais qu’une seule manière de le faire : écrire un petit correctif, créer le diff, le proposer à la validation, mettre à jour ma contribution locale et écrire alors le correctif suivant. Peu de temps après que j’ai commencé à envoyer mes premiers petits correctifs, Wine est entré dans une phase de gel des fonctionnalités d’un mois menant à la version 0.9.0 bêta. Je suis resté sur le correctif suivant pendant un mois avant de pouvoir continuer et j’ai finalement envoyé mon dernier correctif en novembre. Complètement frustré par cette expérience, j’ai décidé que je ne voulais plus jamais avoir à faire avec la communauté Wine.
Ma frustration perdura jusqu’à ce que des personnes qui utilisaient réellement mon code commencent à me poser des questions sur celui-ci en février 2006. Mon code était vraiment utile ! Ils voulaient également davantage de fonctionnalités. Quand Google annonça qu’il reconduirait le GSoC en 2006, mes projets pour l’été étaient clairs. Maintenant que Wine avait basculé de diff à git en décembre 2005, je savais que je ne serais pas ennuyé par des gels de fonctionnalités, puisque je pouvais finalement créer tous mes petits correctifs localement. La vie était belle.
Ce n’est que lorsque je suis tombé sur une interface de git (appelée porcelaine dans le langage git) qui émulait le comportement de Quilt que j’ai appris qu’il y avait des outils qui auraient pu rendre ma vie plus facile, même en 2005.
Comment NE PAS tout foirer
Maintenant que je vous ai raconté comment j’ai réussi à me planter avec l’envoi de correctifs, permettez-moi de poursuivre avec quelques conseils pour éviter les pièges.
Règles pour la soumission de correctifs
Mon premier conseil est de lire attentivement toutes les directives de soumission de correctifs que peut avoir le projet auquel vous voulez contribuer. Celles-ci, ainsi que les normes de style de codage, doivent être consultées avant même de commencer à coder.
Des diffs unifiés
Même si ce n’est pas explicitement indiqué dans les directives de soumission des correctifs, vous devez vraiment, vraiment envoyer le résultat d’un diff unifié. Je n’ai encore rencontré aucun projet qui préfère la sortie non unifiée du diff. Les diffs unifiés rendent la révision du correctif beaucoup plus facile. Ce n’est pas par hasard que les programmes de gestion de version modernes utilisent automatiquement ce format dans leurs commandes diff par défaut.
Utilisez un contrôle de version distribué
En ce qui concerne la gestion de versions moderne, vous devriez vraiment utiliser un système de gestion de versions distribué (DVCS) pour travailler localement sur le code. Git et Mercurial sont les choix les plus populaires de nos jours, quoique Bazaar puisse aussi très bien faire l’affaire. Même si le projet auquel vous voulez contribuer utilise toujours un système de gestion de version centralisé, être en mesure d’envoyer vos changements de manière itérative est une très bonne chose. Tous les outils de gestion de versions distribués mentionnés ci-dessus devraient être capables d’importer des changements depuis un SVN ou un CVS. Vous pourrez y aller et apprendre doucement Quilt mais, sérieusement, le futur passe par les systèmes de gestion de versions distribués.
De petits correctifs, pour faire une chose à la fois
Quand je dois examiner des correctifs, les plus ennuyeux à traiter sont ceux qui sont trop gros ou qui tentent de faire de nombreuses choses en même temps. Les correctifs qui ne font qu’une chose à la fois sont plus faciles à traiter. Au final, ils vous faciliteront la vie quand vous devrez déboguer les erreurs qu’auront manquées à la fois l’auteur et le vérificateur.
Suivez votre correctif
Après avoir proposé votre correctif, gardez un œil sur les canaux de communication du projet et sur votre correctif. Si vous n’avez eu aucun retour au bout d’une semaine, vous devriez poliment en demander un. En fonction de la façon dont le projet gère les propositions de correctif, celui-ci pourrait être noyé dans le bruit. N’espérez pas voir votre correctif retenu du premier coup. Il faut, en général, quelques essais pour s’habituer au style d’un nouveau projet. En tant que contributeur néophyte, personne ne vous en voudra pour ça, à condition d’avoir presque tout bon. Assurez-vous seulement de corriger ce que les développeurs vous ont indiqué et envoyez une seconde version du correctif.
Conclusion
Écrire de bons correctifs n’est pas difficile. Il y a deux ou trois choses à prendre en considération. Mais après en avoir écrit quelques-uns vous devriez être au point sur celles-ci. Un système moderne de contrôle de version (distribué) et le workflow (Ndt : flux de production) qui en résulte gèreront de fait la plupart des choses que j’ai mentionnées. Si vous n’avez qu’une chose à retenir, c’est ceci :
Utilisez un système de contrôle de version distribué pour gérer vos correctifs.
Écrivez vos correctifs en petites étapes indépendantes.
Suivez les normes de codage en vigueur.
Répondez rapidement aux commentaires sur vos correctifs.
Les quelques lignes directrices ci-dessus devraient vous aider à bien faire la plupart des choses, sinon toutes, quand vous soumettrez vos premiers correctifs. Bon codage.
(1) Un diff (abréviation de différence) est un fichier qui affiche le résultat d’une comparaison entre deux éléments (en général, des lignes de code). Pour en savoir plus : http://fr.wikipedia.org/wiki/Diff
Un administrateur systèmes fainéant est un bon administrateur systèmes — Anonyme
Le travail d’un administrateur systèmes n’est généralement pas visible des autres services informatiques ou par les utilisateurs finaux. La plupart du temps, ils regardent les administrateurs systèmes en se demandant pourquoi ils n’ont pas l’air de faire grand chose.
Quand vous voyez un administrateur systèmes qui est tout le temps en train de courir dans tous les sens, à essayer d’éteindre le feu, en prise constante avec des problèmes de production, vous pourriez penser qu’il travaille dur et fait vraiment bien son boulot. Mais en réalité il ne fait pas bien son job.
Quand vous voyez un administrateur système (UNIX/Linux, base de données, réseau), qui apparemment n’a pas l’air de se fouler beaucoup au bureau, semble toujours relax et n’a pas l’air d’avoir une activité visible, vous pouvez être certain qu’il fait bien son job.
Voici 12 raisons qui font d’un administrateur systèmes paresseux le meilleur des administrateurs systèmes :
1. Qui est le chef ? La principale raison pour laquelle un administrateur systèmes paresseux est le meilleur administrateur système possible tient à son attitude. Ils ne voient pas tout à fait les machines comme les autres services informatiques. Il y a une différence entre les développeurs et les administrateurs systèmes. Les développeurs pensent qu’ils sont là pour servir les machines en écrivant du code. Il n’y a rien de mal dans cette démarche puisque les développeurs prennent beaucoup de plaisir à écrire du code. Mais les administrateurs systèmes pensent tout autrement. Ils pensent au contraire que les machines sont à leur service. Tout ce qu’ils ont à faire, c’est nourrir la machine, la rendre heureuse et laisser la machine faire tout le dur labeur pendant qu’ils se relaxent et paressent. La première étape pour devenir un administrateur systèmes paresseux demande parfois un léger changement d’attitude : il s’agit de faire savoir à la machine que vous êtes le patron.
2. Écrire des scripts pour des tâches récurrentes. Être fainéant, c’est être malin. Un administrateur systèmes intelligent est passé maître dans tous les langages de script (bash, awk, sed, etc.). Chaque fois qu’il sera obligé de faire une tâche, et s’il y a une vague possibilité qu’on puisse avoir besoin de ce même travail plus tard, il écrira un script pour faire le boulot. Ainsi, lorsqu’on lui demandera plus tard de refaire le même travail, il n’aura pas à réfléchir ; il aura simplement à exécuter le script puis à retourner paresser.
3. Tout sauvegarder. Être fainéant signifie tout sauvegarder. Un administrateur systèmes paresseux sait qu’il doit donner un peu de temps dans la création de processus de sauvegarde, et donc écrire des scripts de sauvegarde pour toutes les applications et tous les systèmes critiques. Quand l’espace disque n’est pas un problème, il planifie la sauvegarde pour toutes les applications même si elles ne sont pas critiques. Ainsi, dès que quelque chose se passe mal, il ne se met pas à transpirer de stress, il a simplement besoin de restaurer une sauvegarde pour pouvoir retourner aux trucs paisibles qu’il faisait juste avant.
4. Prévoir un plan de reprise d’activité. Les administrateurs systèmes n’aiment pas avoir à gesticuler dans tous les sens en cas d’urgence. Quand tout se passe bien, ils prennent un peu de temps pour créer un plan de reprise d’activité et de récupération de données.Comme ça, quand les choses tournent mal, ils peuvent le suivre, faire revenir rapidement les choses à la normale, puis retourner encore à leur rythme d’administrateur paresseux.
5. Configurer un sytème à haute redondance. Les administrateurs sysèmes fainéants n’aiment pas être réveillés au beau milieu de la nuit à cause d’une bête panne materielle. Ils font donc en sorte que les periphériques soient hautement redondants. Cela inclut à la fois le matériel et les logiciels : ils ont deux cartes réseaux configurées, une double alimentation, deux disques durs, bref tout en double. Comme ça, si l’un des équipements vient à flancher, le système fonctionnera toujours et notre fainéant d’administrateur pourra se concentrer à la réparation de l’équipement défaillant lorsqu’il se lèvera le matin, à la même heure que tous les autres matins.
6. Laisser de la place pour une croissance inattendue. Un administrateur systèmes paresseux ne permet jamais à son système de tourner à plein régime. Il garde toujours de la place libre en cas d’imprévus. Il s’assure que le système ait assez de CPU, ainsi que de l’espace disque et de la RAM disponibles. Lorsque le service commercial décide de larguer des tonnes de données pendant la nuit, il n’a pas besoin de réfléchir à la façon de gérer cette croissance inattendue.
7. Être proactif. Être paresseux ne veut pas dire que vous devez juste vous assoir et vous tourner les pouces. Être paresseux signifie être proactif. Les administrateurs systèmes paresseux détestent être réactifs. Ils anticipent toujours les difficultés et l’expansion. Lorsqu’ils ont du temps libre à disposition (et ils en ont donc beaucoup), ils gardent un œil attentif sur les projets afin de gérer la future croissance et éviter que des problèmes non prévus adviennent.
8. Adorer les raccourcis clavier. L’administrateur systèmes fainéants connaît tous les raccourcis clavier de toutes ses applications favorites. S’il passe quotidiennement un temps significatif sur une application, la première chose qu’il fait est de maîtriser les raccourcis clavier de cette application. Il tient à passer le moins de temps possible sur l’application pour parvenir à ses fins, et ainsi redevenir paresseux.
9. Passer maître de la ligne de commande. Tous les administrateurs systèmes paresseux sont des pros des lignes de commande. Cela s’applique aux administrateurs systèmes Linux, aux administrateurs de bases de données, aux administrateurs réseaux, etc. Si vous voyez un administrareur systèmes lancer une interface graphique alors que la même tâche peut être effectuée en ligne de commande, alors vous savez qu’il n’est pas un administrateur systèmes paresseux. Il y a deux raisons pour lesquelles les administrateurs systèmes paresseux adorent les lignes de commande. D’une, il peut faire les choses rapidement en ligne de commande. Et d’autre, ça lui donne l’impression que c’est lui le patron et non pas le système. Quand vous utilisez les lignes de commande, vous avez le contrôle, vous savez exactement ce que vous voulez faire. Quand vous utilisez une interface graphique, vous êtes à sa merci sans être sûr à 100% de ce qu’il va produire après votre clic.
10. Apprendre de ses erreurs. Les administrateurs systèmes fainéants n’aiment jamais faire les mêmes erreurs deux fois. Ils détestent travailler sur des problèmes imprévus, mais quand ils apparaissent, ils travaillent à le corriger, réfléchissent à comment cela est arrivé, et mettent immédiatement le nécessaire en place pour que cela n’arrive pas de nouveau. Travailler sur le même problème deux fois est considéré comme un véritable péché pour un administrateur système fainéant. Il aime travailler sur le problème une seule fois, faire ce qu’il faut pour prévenir l’apparition de la même erreur dans le futur, et retourner tranquillement paresser.
11. Se former en continu aux nouvelles technologies. Il n’y a rien de mal à apprendre de nouvelles technologies pour avoir un meilleur travail ou juste pour se tenir à jour des progrès dans le domaine. Mais un administrateur systèmes paresseux n’apprend pas de nouvelles technologies pour cette raison. Il s’y forme parce qu’il aime garder le contrôle sur les systèmes en permanence. Il sait que c’est lui le chef et non pas la machine. Ainsi, quand arrive une nouvelle technologie, il prend le temps de l’étudier. À présent, il a de nouveaux outils pour occuper le système tandis qu’il continue à paresser. C’est la paresse qui est la principale motivation de sa formation.
12. Tout documenter. C’est ce qui distingue les bons administrateurs systèmes des meilleurs administrateurs systèmes. Voyez-vous, l’administrateur systèmes paresseux déteste être dérangé lorsqu’il est sur la plage à profiter de ses vacances. Donc, que fait-il ? Il documente tout, de manière à ce que lorsqu’il n’est pas là, d’autres puissent faire le boulot de base à sa place, et fassent tourner les choses sans le déranger pendant ses vacances. Il y a une autre raison pour laquelle l’administrateur systèmes paresseux documente tout : parce qu’il oublie des choses. Comme il est fainéant, il a tendance à oublier ce qu’il a fait le mois précédent. Puisqu’il n’aime pas du tout réfléchir deux fois sur le même sujet, il documente tout, et quand il aura besoin de faire la même chose dans le futur, il reviendra à sa documentation pour comprendre ce qu’il avait fait la fois précédente.
Voilà. Être un administrateur systèmes fainéant, ce n’est pas si simple en fait, c’est même beaucoup de travail. Si vous n’en êtes pas, vous saurez désormais les reconnaître. Si vous en êtes et que vous courez toujours partout, vous savez maintenant ce qu’il vous reste à faire.
Et n’hésitez pas à venir nous passer le bonjour sur notre stand Framasoft (mais pas trop tôt le matin quand même, surtout au lendemain du Repas du libre !).
