Version classiqueVersion mobile

Nains sans géants

 | 
Francesca Musiani

Chapitre 4. L’« art du compromis » entre distribué et centralisé

Texte intégral

  • 55 Le nom fictif choisi pour l’entreprise signifie « pluie fine » en anglais et souhaite renvoyer aux (...)
  • 56 Service permettant à ses utilisateurs de stocker, sauvegarder, consulter et partager des fichiers (...)

1Troquer de l’espace disque en local contre de l’espace de stockage en ligne : en bref, telle est la proposition de Drizzle55, une start-up suisse proposant un service de stockage en ligne56 communautaire. Le dispositif est basé sur une technologie mise au point par les co-fondateurs de l’entreprise, Dietrich Poell et Kurt Gueden, lors de leur doctorat en informatique à l’Institut fédéral de technologie (ETH) de Zurich. La version closed alpha du dispositif est sortie à la fin de 2007, et la version beta publique a été proposée en 2009, année où Drizzle s’est associé à StockFast, fabricant français de périphériques de stockage. En septembre 2011, l’équipe compte 17 personnes, et continue de s’accroître ; dix des membres de l’équipe sont diplômés d’un master ou d’un doctorat en science informatique de l’ETH Zurich ou de l’Ecole Polytechnique Fédérale de Lausanne.

2Aux débuts de 2007, la création de la petite start-up survient dans un secteur où « l’industrie du stockage en ligne des données ne s’est jamais sentie aussi bien », notera par la suite un commentateur. Les disques durs montés sur la plupart des ordinateurs d’aujourd’hui dépassent souvent les cent gigaoctets de mémoire, tandis que ceux des serveurs destinés au stockage professionnel de données en comptent désormais plusieurs téraoctets. Amazon S3, Azure Storage, Sun Cloud Storage sont quelques exemples de ce que les grands noms de l’industrie informatique proposent aux entreprises, en mettant en avant un modèle de service où le fournisseur est en charge de l’infrastructure physique et du produit logiciel, abritant ainsi à la fois les applications et les données dans un lieu inconnu de l’utilisateur (le fameux « nuage », cloud en anglais) et interagit avec ce dernier grâce à une interface client. En parallèle, se développent de nombreuses offres de stockage en ligne pour le grand public, d’un volume généralement limité à quelques gigaoctets – c’est le cas de SkyDrive de Microsoft, une offre de stockage en ligne de 25 gigaoctets, lancé en août 2007.

3C’est au sein de ce scénario foisonnant d’applications de stockage, qui reposent généralement sur des serveurs « classiques » ou des plates-formes en nuage, que Drizzle doit se positionner et chercher une vocation lors de son démarrage en 2007. L’équipe de développeurs choisit de travailler sur l’architecture du service en tant qu’aspect différenciant et original par rapport à ses compétiteurs : l’idée centrale sous-tendant le dispositif est que les fichiers téléchargés par les utilisateurs dans le système seront stockés à la fois dans des centres de données classiques et sur un nuage de stockage composé d’une partie des disques durs de chaque utilisateur, reliés entre eux en architecture P2P.

4Comment et pourquoi se construit un compromis, un hybride, entre une approche largement dépendante d’une plateforme de serveurs, et une approche d’architecture distribuée et décentralisée, où le fonctionnement du dispositif repose sur la mise à disposition de ressources hardware de la part des usagers ? La courte mais dense histoire de Drizzle est celle d’une application dont les créateurs ont travaillé, selon les moments, avec différents modèles d’architecture technique – mais aussi avec la représentation de ces architectures auprès de leur public de clients potentiels, et avec la volonté de ces clients/usagers de s’engager dans un « jeu » de partage de ressources aux implications matérielles, juridiques et sociales multiples. Dans le façonnage de leur service de stockage distribué, les développeurs de Drizzle mènent une double expérimentation : avec la frontière entre centralisation et décentralisation, ainsi qu’avec des dynamiques de partage et d’utilisation mêlant P2P et réseautage social. Cette double expérimentation ouvre la voie à une situation qui est à la fois incertitude et opportunité technique : la mobilisation des marges du réseau, où se déploient des ressources matérielles et « humaines » très riches, mais disponibles de façon temporaire et inconstante. Ressources qui peuvent aider l’entreprise à trouver sa niche au sein d’un secteur foisonnant de nouvelles solutions, et où la concurrence est aigue.

UN STOCKAGE EN RÉSEAU P2P

5En 2009, Dietrich Poell a vingt-neuf ans et est titulaire, depuis deux ans, d’un doctorat en sciences informatiques de l’université de technologie de Zurich, au cours duquel il a fait des stages à l’université technique de Delft, aux Pays-Bas (2003) et à Siemens Corporate Research dans le New Jersey (2004). Une fois obtenu son doctorat, en 2007, il fonde une firme de développement de logiciels dont le premier produit est l’Address-Book, un logiciel pour la gestion des contacts professionnels des petites et moyennes entreprises. Au cours de l’année qui suit, il vend près de 35000 licences pour Address-Book en Suisse, Allemagne et Autriche, ce qui vaut au logiciel une certaine notoriété dans la partie germanophone de l’Europe. Avec les revenus de ce premier-né, qu’il définit « d’un impact révolutionnaire douteux, mais doté d’une valeur stable et claire », Dietrich compte financer les premiers pas d’un projet plus ambitieux, se basant sur un « vieux rêve » de l’informatique pour lequel les pères fondateurs, comme le professeur américain Andrew Tanenbaum, envisageaient pourtant de nombreux défis :

« Il s’agit d’un vieux rêve de l’informatique, en fait Tanenbaum écrivait dans son livre sur les systèmes d’exploitation distribués, au milieu des années 1990, que la conception d’un système de fichiers distribué, totalement transparent, destiné à une utilisation simultanée par des millions d’utilisateurs mobiles et souvent déconnectés était laissé comme expérience de pensée pour le lecteur. Maintenant, j’espère vraiment qu’il voulait dire cela ironiquement, parce que nous avons travaillé sur cette expérience de pensée pendant ces cinq dernières années ».

6L’idée du projet Drizzle, qui à ce moment n’a pas encore de nom, prend forme dès le retour de Dietrich des États-Unis en 2004, son inscription en doctorat de sciences informatiques à Zurich, et sa rencontre avec Kurt Gueden. Les deux étudiants se découvrent un intérêt commun pour les projets de recherche à large échelle sur les systèmes de stockage distribué, conduits à ce moment-là dans plusieurs universités techniques et départements de recherche d’entreprise aux États-Unis : OceanStore à l’université de Californie à Berkeley, Cooperative File System au Massachusetts Institute of Technology (MIT), Past à Microsoft Research. Ils trouvent cependant qu’il y a une limite commune à ces projets – aucun d’entre eux n’est orienté vers la fabrication d’un produit destiné à un marché de masse. Dietrich se remémore :

« Notre objectif était de construire quelque chose qui était à la fois un défi du point de vue de la recherche, mais qui avait aussi un grand potentiel. Les systèmes de stockage distribués étaient un sujet de recherche chaud à cette époque, et la construction d’un système qui peut exploiter les ressources inutilisées semblait très prometteuse, alors que le besoin de stockage en ligne était en hausse et la taille des fichiers augmentait. Mais les projets de recherche avaient un objectif purement théorique – nous voulions le réaliser, et le faire fonctionner en pratique pour des millions d’utilisateurs. »

7« Nous avons voulu combler le fossé entre la recherche fondamentale et ce qu’il fallait pour construire un produit, » renchérit Kurt. Pendant qu’ils achèvent leur doctorat, Dietrich et Kurt cherchent à préciser leur idée « orientée produit » d’un système de stockage distribué. En mai 2006, ils participent aux formations de Venturelab, un programme national suisse financé par la Commission pour la technologie et l’innovation. Leur proposition de projet, bien qu’appelé autrement, comporte déjà certaines caractéristiques du futur Drizzle : un système de stockage global et distribué en ligne, qui met à profit les ressources des ordinateurs participants, et qui répond au besoin croissant d’espace de stockage de l’utilisateur lambda. Le mémo présenté par Dietrich à Venturelab mentionne aussi l’accès en mobilité et l’« ouverture du système, donnant lieu à une multiplicité de possibilités ».

8L’idée est sélectionnée et, quelques mois après, ses créateurs comptent parmi les « Innovateurs Suisses » de Venturelab pour 2007.

9Quand Dietrich Poell et Kurt Gueden terminent leur doctorat à l’Institut de technologie de Zurich, en 2007, ils ont donc déjà travaillé depuis quelques années au stockage en ligne. Il leur semble clair à ce moment que l’originalité de « encore un autre » dispositif de stockage ne pourra pas être liée à la nature du service fourni. Celui-ci proposera grosso modo les mêmes fonctionnalités de plusieurs autres services de stockage : la possibilité de sauvegarder, stocker et accéder à des contenus en ligne, en attribuant différents degrés de confidentialité aux différents contenus. Ces fonctionnalités, qui s’enrichiront par la suite d’autres plus « sociales » de collaboration et partage, sont décrites dès novembre 2007, dans une des premières entrées de blog sur le site du service. Mais « il n’y a pas grand chose d’ original qu’un usager peut effectivement faire avec un service de stockage, » résume de façon lapidaire Dietrich. L’originalité du service ne sera donc pas celle du service en lui-même ; les deux développeurs considèrent que la manière dont ils pourront émerger et se différencier de leurs compétiteurs sera le travail sur les « tuyaux », la plateforme sur laquelle celui-ci est fourni – avec des implications pour la sécurité du système, la privacy des données stockées, la vitesse des téléchargements en amont et en aval, la rapidité des échanges effectués.

10Et si les ressources de cette plateforme étaient les terminaux, unités de mémoire, bande passante mises à disposition par les usagers ? Cette décentralisation permettrait d’un côté, du point de vue de l’entreprise, de diminuer les coûts d’entrée sur le marché en rendant cette entrée plus facile ; et, par ailleurs, cela permettrait de proposer aux clients un produit « alternatif » à plus d’un titre :

« Un stockage en ligne avec la puissance du P2P, s’il est bien fait, signifie des téléchargements rapides, pas de limites de taille de fichier, pas de limites au trafic […] Un système décentralisé pourrait exploiter les ressources inutilisées des ordinateurs participants, pour construire un stockage en ligne sécurisé, fiable et à grande échelle. Cela permettra aux utilisateurs d’échanger une partie de leur stockage local pour le stockage en ligne, et nous permettra d’offrir un meilleur service gratuitement. »

11L’idée d’un système où les fichiers sont stockés dans un réseau composé d’une partie des disques durs des utilisateurs, reliés entre eux directement en réseau P2P, commence alors à prendre forme et à faire le pont entre la recherche informatique et mathématique pure et un projet de service utilisable. Avec elle, les « problèmes » typiques du développeur de systèmes P2P commencent à faire surface et à nécessiter de solutions ad hoc. Dans la première version du système envisagée par Dietrich, lorsqu’un utilisateur télécharge un fichier, celui-ci doit d’abord être chiffré et mémorisé en bloc sur l’ordinateur de son utilisateur, puis divisé en fragments encryptés, qui quittent alors l’ordinateur de l’usager pour être stockés de manière redondante dans l’ensemble des ordinateurs des utilisateurs, reliés les uns aux autres directement, de manière à former une plateforme.

12Comme ce sera le cas plusieurs fois par la suite, remarque ironiquement Kurt Gueden, c’est lorsque Dietrich lui fait part de cette idée que son rôle dans la compagnie devient clair : « J’ai commencé à poser des questions difficiles et moinsque-rêveuses, et souvent il ne m’a vraiment pas beaucoup aimé pour ça. » Tous deux développeurs talentueux, l’un plus visionnaire et l’autre plus circonspect, Dietrich et Kurt forment un embryon d’équipe efficace… et ne tardent pas à se rendre compte de la difficulté de leur tâche. Comme souligne Dietrich :

« Plusieurs fois, nous avons constaté que nous avions besoin de prendre un peu de recul et réfléchir : la décentralisation en vaut-elle vraiment la peine ? Dans la plupart des cas, il s’agissait de débattre des avantages et des inconvénients de la décentralisation d’un aspect spécifique de la structure du service, et la réponse qu’on finissait par nous donner n’a jamais été deux fois la même. »

Redondance : façonner un stockage P2P permanent

13Les deux développeurs – qui ont entre temps été rejoints dans leur démarche par trois autres doctorants ou ex-étudiants de l’ETH Zurich – doivent répondre à une première question « difficile et peu séduisante ». Si les données sont stockées dans les ordinateurs formant le réseau P2P, les terminaux individuels de chaque pair peuvent donc passer hors ligne et réapparaître en ligne à tout moment. Comment peut-on assurer, dans cette situation de déconnexions et reconnexions fréquentes, que l’ensemble des données reste toujours disponible dans le réseau pour un utilisateur qui souhaiterait récupérer ses données ? En d’autres termes, comment construire un stockage P2P stable et permanent ?

  • 57 Ce que l’équipe Drizzle souhaite, au contraire, être l’un des points de force du service rendu pos (...)

14Une première approche est tout d’abord discutée au sein du groupe de développeurs : le réseau peut être développé de façon à ce que les données y soient constamment présentes, ce qui implique de déplacer les données stockées d’un ordinateur, quand celui-ci passe hors ligne, vers un autre ordinateur. Cette solution ne paraît pas, après discussion, la plus appropriée dans un contexte distribué, pour deux raisons que Dietrich explique. Tout d’abord, le déplacement de fichiers volumineux ou d’un nombre important de fichiers prendrait beaucoup de temps ; cela poserait un problème pour l’utilisateur sur le point de se déconnecter, qui devrait attendre que cette opération soit effectuée. Ensuite, et surtout, les déconnexions et reconnexions dans un environnement P2P sont généralement fréquentes ; de facto, les ressources en bande passante à la disposition du système, aussi importantes soient-elles, seraient utilisées pour des opérations sans fin de copie de données, au lieu d’être dédiées à la rapidité des téléchargements57.

15La deuxième approche consiste à laisser les données (ou, comme on verra d’ici peu, les fragments de données) là où ils sont, et à en assurer la redondance au sein du réseau. Celle-ci ne doit pas pour autant impliquer une réplication totale des fichiers, ni des fragments de fichiers, sur chaque ordinateur, ce qui nécessiterait un trop grand déploiement de ressources. Pour obtenir une redondance qui ne soit pas une réplication, l’équipe Drizzle commence donc à travailler avec les codes d’effacement, définis par Kurt comme « codes qui transforment un message de symboles k en un message plus long de symboles n, tels que le message d’origine peut être récupéré à partir d’un sous-ensemble des symboles n. »

  • 58 Le système de codage utilisé par Drizzle se reporte aux codes de Reed-Solomon, un code correcteur (...)

16Ce qui, traduit dans la gestion des ressources à disposition dans un système – m’explique Dietrich – signifie que ce système de codage permet de télécharger des duplicata de morceaux de fichiers beaucoup moins de fois qu’il ne serait nécessaire s’il fallait télécharger le fichier dans sa totalité58. Dans cette approche, Dietrich et Kurt voient aussi une façon de contrer un des problèmes des systèmes P2P « traditionnels » de partage de fichiers, qui marchent d’autant mieux que les fichiers sont plus populaires (et donc plus répandus dans le réseau).

  • 59 La Google Tech Talk Series est une série de conférences techniques, hébergées par Google dans son (...)

17Au vu du grand nombre d’utilisateurs envisagés, et de données qui circuleront dans le dispositif selon les prévisions de l’équipe, c’est donc cette deuxième approche qui est finalement adoptée, comme explique Dietrich lors d’une première démonstration de la version closed alpha du dispositif, en octobre 2007, à l’occasion d’une Google Tech Talk59. Ce choix entraîne par ailleurs des questions d’« entretien » du système. Assurer la redondance du système oblige à gérer la disponibilité des données non seulement d’un point de vue spatial (tous les fragments présents dans au moins un ordinateur), mais aussi dans le temps : à cause des déconnexions prolongées et inattendues, et des déconnexions permanentes, la disponibilité des certaines ressources matérielles de stockage peut cesser définitivement à un moment. Comme les développeurs s’en rendront compte, à la suite des réactions des utilisateurs du closed alpha après ses premiers mois de vie, il s’agit là d’un aspect tout aussi important pour la stabilité du système et sa durabilité à moyen terme :

« Nous avons alors compris combien les opérations de maintenance étaient importantes. Quand je stocke cinq cents fragments aujourd’hui, cela ne signifie pas qu’ils seront les mêmes cinq cents fragments qui seront disponibles dans un mois à partir de maintenant, par exemple. Donc, nous avons introduit la possibilité pour l’ordinateur d’[un utilisateur] de vérifier et maintenir ses fichiers, l’ordinateur vérifie périodiquement si la disponibilité du fichier est encore assez bonne, et s’il semble que certains ordinateurs ont quitté le système pour toujours, si nécessaire, il reconstruit de nouveaux fragments et les télécharge sur le réseau. »

« Fragments encryptés » entre local et global, une promesse de sécurité ?

18Le choix de baser le stockage P2P sur le mécanisme des codes d’effacement déterminera aussi, de façon que Dietrich n’hésite pas à définir « naturelle », un autre aspect de la technologie Drizzle qui fera débat : l’encryptage en local, sur la propre machine de l’utilisateur et au moyen du client P2P Drizzle, des contenus à stocker – avant que ceux-ci ne soient divisés en fragments, dupliqués et repartis au sein du système. Les « fragments encryptés » résultant de ce processus deviendront tour à tour – dans les mots des développeurs Drizzle, des experts techniques qui donneront leur avis sur les premiers pas du dispositif, et de sa base d’utilisateurs pionniers – le symbole même de la solution de stockage permanent en P2P proposée par la firme, solution sur laquelle repose une bonne partie de la crédibilité et de la spécificité du produit ; le mécanisme technique qui assure la sécurité des données par rapport non seulement aux utilisateurs non autorisés, mais à la firme elle-même ; ou encore, l’arène où va se jouer la controverse entre utilisateurs « méfiants » et « confiants » sur la capacité du dispositif de maintenir la promesse de sécurité et confidentialité accrue faite par ses développeurs.

19Les fonctions d’encryptage et de fragmentation des fichiers à stocker sont programmées par l’équipe Drizzle pour entrer en fonction dans tout ordinateur qui, ayant installé le logiciel, a sélectionné l’option de stockage partagé. Le fait de sélectionner cette option n’est pas nécessairement un choix obligé : au cours de ses premiers mois d’existence, Drizzle était programmé pour donner la possibilité aux utilisateurs ayant besoin de moins d’un gigaoctet de mémoire stockage de ne pas l’obtenir du réseau d’ordinateurs connectés, mais des serveurs de la firme (« Vous commencez avec un gigaoctet, fourni par nous ») : en conséquence, dans ce cas, les fragments encryptés n’étaient pas stockés sur l’ordinateur de cet utilisateur. Cette option, faisant partie des mesures prises par l’équipe pendant la phase d’amorçage, ne rencontre cependant qu’un intérêt mitigé de la part des usagers de la première heure ; comme souligne Dietrich, « les gens qui essayaient Drizzle étaient intéressés par le mécanisme de stockage P2P, donc par le troc d’espace de stockage et l’encryptage. »

20Un profil type de client/utilisateur pionnier de Drizzle commence à se dessiner à travers les mots de Dietrich : il s’agit de quelqu’un avec un intérêt pour le mécanisme de stockage en P2P, son fonctionnement technique et sa dimension communautaire à la fois – quelqu’un qui « suit » le dispositif, parce qu’il possède les capacités techniques et l’expertise pour le faire.

21Le logiciel est programmé pour fonctionner de la manière suivante : quand un usager dépose un fichier dans Drizzle, ce fichier est d’abord encrypté sur son ordinateur. Ensuite, le fichier crypté est divisé en fragments (« non exécutables, » note Dietrich – fragments qui, pris un par un, sont dépourvus de signification et d’autonomie), qui sont indexés dans le dossier « données » du logiciel et encodés de manière redondante, encore une fois sur la machine de l’usager. À ce moment, les fragments encryptés sont téléchargés à différents endroits du réseau P2P, où ils sont stockés. Si un utilisateur souhaite partager un fichier avec un deuxième utilisateur, le client P2P de ce dernier va chercher les fragments correspondants – un sous-ensemble de tous les fragments disponibles – dans le réseau P2P. Ensuite, il décode, décrypte, et ouvre le fichier.

22On voit dans ce processus une articulation intéressante des dimensions locale et globale, qui formate le rôle de l’utilisateur envisagé par le dispositif. Jusqu’à ce que l’encryptage et la fragmentation des données ne soient accomplis, le cœur du service est le terminal de l’utilisateur : là ont lieu, au moyen du client P2P, les opérations d’encryptage et de division en fragments. Comme le souligne Kurt, « Toutes les opérations d’encryptage et décryptage sont effectuées localement – l’avantage d’avoir un logiciel client. »

23Une fois que les données sont sous forme de fragments encryptés, ceux-ci sont stockés et partagés, « éparpillés » sur le réseau. Lorsque s’effectue le passage de la dimension locale de la machine utilisateur à l’ensemble du réseau, l’emplacement physique des contenus stockés (ou plutôt les multiples emplacements de ces contenus) est constitué par des sous-ensembles d’ordinateurs, qui forment un réseau constamment provisoire et évolutif. Plutôt que l’ensemble des ordinateurs, la dimension « globale » du système est donc l’algorithme qui permet à chaque moment de définir quels ordinateurs, à chaque moment et pour quelle durée, recueillent les données d’un utilisateur en particulier.

24En même temps, à moins que des opérations de partage et interrogation ne soient déclenchées explicitement, chaque utilisateur ignore quels fragments, à un moment, sont stockés sur sa propre machine parmi les autres. Un fichier partagé de cette façon sur le réseau est donc, en fait, invisible par les utilisateurs, même si leurs machines en stockent des parties ; les utilisateurs n’ont une connaissance directe que de leur mise à disposition des ressources computationnelles et matérielles nécessaires à l’encryptage et la fragmentation des fichiers, ainsi qu’à leur stockage. La capacité CPU de leurs machines se mobilise, mais ils ne sauront pas à quelle tâche elle est précisément destinée à un moment donné. C’est ainsi que, dès la première version du dispositif, l’équipe Drizzle estime nécessaire d’insérer dans les conditions d’utilisation du produit une clause très particulière, qui clarifie quelles ressources pourront être utilisées par le système et pour quel ensemble de tâches – tout en ne précisant pas quelle ressource servira quelle tâche, et comment, à un moment précis :

Conditions générales de vente. Date de la dernière révision : 11 mai 2009.
[…] 5. Services de l’utilisateur : L’utilisateur reconnaît que Drizzle peut utiliser le processeur, la bande passante et le disque dur (ou autre support de stockage) de son ordinateur dans le but de stocker, chiffrer, mettre en cache et fournir des données qui ont été stockées dans Drizzle, par l’utilisateur ou tout autre utilisateur. L’utilisateur peut spécifier la mesure dans laquelle les ressources locales sont utilisées dans les paramètres du logiciel client Drizzle. La quantité des ressources que l’utilisateur est autorisé à utiliser dans Drizzle dépend de la quantité de ressources locales que l’utilisateur contribue à Drizzle. Les ressources sont allouées et contrôlées conformément à la politique de confidentialité.

La sécurité « par obscurité » en débat

25Depuis ses débuts en 2007, Drizzle fait du niveau de sécurité élevé, promis par l’encryptage et la fragmentation des fichiers en local, une des pierres angulaires du service, au point que les informations fournies sur le site de la firme au sujet de la technologie développée par Drizzle coïncident bientôt avec une page intitulée « Sécurité ». Celle-ci met l’accent, selon les cas, sur des aspects de confidentialité (des données et des activités), de qualité de service (l’intégrité des données stockées), la permanence et la continuité du service (la distribution et la redondance des contenus stockés) : autant de termes qui renvoient à des acceptions de sécurité différentes. Lors de la Google Tech Talk d’octobre 2007, Dietrich met encore une fois la question de la sécurité au centre de son discours. Au milieu de considérations techniques poussées sur la structure cryptographique du dispositif, l’importance de la dimension locale des processus de sécurisation revient avec insistance et apparaît encore une fois comme un des points de force affichés de son système de stockage :

« Le système que nous utilisons est AES 128 bits pour l’encryptage, et 2048 RSA pour l’authentification ; toutes les données sont cryptées, ce qui signifie que les fichiers et les métadonnées sont chiffrées et toutes les opérations cryptographiques sont effectuées localement, ce qui signifie sur votre machine, sur votre ordinateur. Pour le contrôle d’accès, nous avons mis au point une structure cryptographique simple mais efficace, qui repose sur la définition de stockage non sécurisé : ce qui signifie que rien n’est révélé quant à l’endroit où la structure de contrôle d’accès est stockée, toutes les opérations sont exécutées sur le client, et le stockage n’est pas impliqué dans les opérations cryptographiques. »

26Plusieurs commentateurs et blogueurs notent également cette mise en relief de l’aspect sécurité de la part de Drizzle. Certains d’entre eux semblent par ailleurs signaler entre les lignes que la sécurité de Drizzle suppose, au moins à son stade de closed alpha (2007), un bon degré de confiance des utilisateurs dans la fiabilité de ces discours relatifs à l’encryptage :

« Les gens de Drizzle sont très désireux de parler de sécurité, en soulignant qu’ils utilisent l’encryptage en local avant que les fichiers soient envoyés vers le cloud et/ou sauvegardés via un réseau P2P qui permet aux autres utilisateurs d’offrir également un espace disque sur leur propres ordinateurs. L’utilisation de l’encryptage côté client, explique l’entreprise, signifie que Drizzle elle-même ne peut pas accéder aux fichiers d’un utilisateur, car le mot de passe ne quitte jamais son ordinateur. »

27La controverse sur la sécurité « en local » de Drizzle est tout particulièrement marquée par une attaque assez véhémente de la part du cryptographe Tom Miller, un développeur et chercheur en informatique dont le blog est une des références sûres pour les experts du domaine. En octobre 2007, l’expert publie sur son blog une critique acérée du dispositif, se basant sur une affirmation de Dietrich lors d’une interview : « Dans notre système, tout est chiffré et ce même chiffrement est utilisé par la CIA pour les fichiers top secret ».

28Celle-ci sera ensuite promptement rectifiée par l’auteur de l’interview en « Dans notre système, tout est crypté et il s’agit de techniques d’encryptage à la pointe du secteur, » mais pas avant que Miller ne soit parvenu à des conclusions aux implications assez destructrices pour la confiance de l’utilisateur lambda dans les aspects relatifs à l’encryptage et la sécurité du closed alpha de Drizzle :

« Tout compte fait, je pense que Dietrich Poell tombe dans la catégorie des “volontairement ignorants” – il ne comprend pas la cryptographie, et il n’a apparemment pas fait la moindre tentative pour consulter les gens qui la comprennent. Mais, soit qu’il ait délibérément menti au sujet de la sécurité de Drizzle, ou qu’il croit réellement ce qu’il prétend – que le cryptage utilisé par Drizzle est utilisé par la CIA pour les fichiers top secret – ne compte pas vraiment à la fin : Si vous vous souciez de vos données, ne lui en confiez pas la gestion. »

29Cette attaque sans détours vaut à Miller quelques interrogations de la part de ses lecteurs sur son objectivité : « une page entière appelant Drizzle une fraude est excessif. J’ai été membre de Drizzle pendant un bon moment. Est-ce que vous l’avez déjà au moins utilisée ? »

  • 60 Il avait été présenté au Symposium on Reliable Distributed Systems [SRDS] en 2006.

30Et, comme on pouvait s’y attendre, Dietrich contacte Miller en lui demandant de prendre en compte la rectification du passage de l’interview, et en fournissant des détails techniques additionnels sur la cryptographie qui ne sont pas présents sur le site de la firme. En particulier, le papier décrivant le système de cryptographie à l’œuvre dans Drizzle fait pour la première fois son apparition dans un contexte non académique60, et un lien direct au papier figure depuis lors sur la page Sécurité du site de Drizzle. Ce moment d’épreuve, que Dietrich décrira plus tard comme fondamental dans la stabilisation d’une légitimité pour le processus de sécurisation à l’œuvre dans Drizzle, est résolu en deux temps. D’abord, par un post de Miller : le cryptographe continue à souligner la grande complexité du système et les problèmes qu’une telle complexité peut soulever, tout particulièrement pour une technologie naissante, « en cryptographie, comme pour tous les autres domaines de l’informatique, plus de lignes de code signifient inévitablement plus de bugs et plus de failles de sécurité potentielles », mais note aussi qu’il a reçu plusieurs retours montrant que la confiance des utilisateurs semble se stabiliser, à la suite de la communication plus ouverte et complète sur les détails techniques du fonctionnement du système que Drizzle a mis en œuvre :

« Comme Dietrich l’a fait remarquer, ils sont encore en alpha, et ont beaucoup de temps pour stabiliser les détails de sécurité avant que Drizzle entre dans le stade d’utilisation plus généralisée. Dietrich semble certainement intéressé à régler les problèmes (ce qui est plus que je peux en dire de certaines autres personnes) et fournit de l’information sur la façon dont il le fait, donc nous allons devoir attendre et voir – nous espérons que le site Drizzle continuera d’être mis à jour pour décrire la façon dont l’ensemble de ces questions sont abordées, et que la sécurité de Drizzle puisse être évaluée sans qu’il soit nécessaire d’entrer dans un échange de courriels. »

31Une deuxième entrée de blog de Tom Miller, une année plus tard, entre dans les détails techniques pour expliquer comment le système de sécurisation de Drizzle est en train de prendre forme : bien qu’exprimant toujours des réserves, le ton de l’expert en cryptographie est dans son ensemble rassurant pour les utilisateurs.

32Une de ses remarques porte pourtant une des premières traces d’une autre controverse, qui, surtout depuis l’ouverture de la version beta publique du logiciel, se révèle importante pour la crédibilité du système « fragments encryptés ». Il s’agit du débat sur la fermeture du code source du client P2P de Drizzle : pour tout développeur ou utilisateur averti qui souhaiterait y voir plus clair dans la définition de sécurité proposée par Drizzle, il n’est pas possible d’explorer le code, qui reste propriétaire et fermé.

« Le code source du client Drizzle n’est pas disponible. Bien que je n’aie aucune raison de penser que Dietrich ou toute personne travaillant à Drizzle a inséré un code malicieux dans le client Drizzle, à l’heure actuelle il n’existe aucun moyen de le savoir. En quelque sorte, “hey, téléchargez et exécutez ce programme ! Il va sauvegarder toutes vos données sur Internet, et il est parfaitement sûr car il crypte tout d’abord. Vraiment, il le fait ! Croyez-moi !”, n’est pas un argument de vente qui m’inspire beaucoup de confiance »,

  • 61 Entre autres Apache Commons, Jakarta et Trove.

33conclut ironiquement Miller. De son côté, l’équipe de développeurs Drizzle s’était confrontée, depuis ses débuts, à la question de l’ouverture ou de la fermeture du code source. En 2005 et 2006, quand Dietrich et Kurt sont encore des doctorants à l’ETH Zurich et écrivent les premiers bouts de code, ils sont immergés dans une culture académique de recherche ouverte et de développement de code en open source. Ils font usage, pour la première version du client, de parties de code dérivées de plusieurs projets open source61, et des composantes du futur Drizzle sont développées et brevetées en tant qu’open source – Webstart, logiciel pour le démarrage rapide de l’application, et Persistent Map, un prototype de la table de hachage distribuée qui sous-tendra Drizzle, sont rendus disponibles sous licence LGPL (Lesser General Public License) sur le site SourceForge.

34Pourtant, quand Drizzle sort du statut de projet universitaire pour devenir un « embryon » de service, en 2007, la décision est prise de fermer le code source de l’application, en closed alpha d’abord et en beta privé et public depuis, bien que le site de la firme continue à reconnaître et à lister les contributions open source encore présentes dans le code source du dispositif : « Nous aimons la technologie open source et Drizzle est basé sur un certain nombre de projets open source », explique le site de la firme. Au moins jusqu’à ce que la firme précise son modèle d’affaires et recrute du personnel additionnel, il s’agit là d’une question de disponibilité de ressources, ainsi que de quantité et qualité de la « maintenance » et du dépannage éventuel que Dietrich et ses collaborateurs peuvent consacrer à Drizzle :

« Même si avoir un client open source a clairement des avantages, il faut beaucoup de ressources pour soutenir et maintenir la communauté qui l’entoure. Nous n’avons pas les ressources nécessaires et donc une version complètement ouverte du client Drizzle est hors de question pour le moment. »

  • 62 C’est-à-dire que la firme Dropbox possède un certain nombre de serveurs auxquels la totalité des f (...)

35C’est pourtant l’importance attribuée par l’équipe Drizzle elle-même à la sécurité « augmentée » assurée par la fragmentation et l’encryptage des fichiers qui amène certains utilisateurs pionniers, de façon toujours plus pressante, à demander l’ouverture du code source. Une des premières arènes où cette demande est formulée est, en mars 2010, le forum utilisateurs de Dropbox, un des principaux concurrents de Drizzle qui implémente un modèle de stockage en cloud « classique62 » ; Reginald O., un utilisateur qui paraît spécialement versé en techniques de cryptographie, arrive à définir ainsi l’approche de fermeture du code source de Drizzle :

« Il est tout à fait possible pour les employés de Drizzle de savoir quels sont vos fichiers, puisque les méta-données qui les concernent sont stockés sur les serveurs avec leurs tables de hachage. Il est très difficile de valider ce que Drizzle est effectivement en train de faire, parce que leur code et leurs méthodes ne sont pas open source. Ainsi, vous devez avoir confiance que ce qu’ils disent est correct (plutôt que d’obtenir un examen indépendant). […] Pour moi, cela crie “sécurité par l’obscurité”. Leur code, chiffrement, etc., sont tous propriétaires, sans examen. Pour moi, c’est ce qui me pousse à la méfiance. »

36Au contraire de ce qui est arrivé dans le cas de l’entrée de blog controversée de Tom Miller, aucun des développeurs de Drizzle n’intervient directement pour répondre à Reginald. Cependant, la même question est posée à nouveau, peu de temps après, sur le forum de Drizzle, et les motifs de la fermeture du code source font, une fois de plus, objet de débat.

37L’utilisateur jernst lance la discussion en mettant à nouveau en avant des questions de confiance. Il note qu’il s’agit là d’une question centrale, puisque la sécurité renforcée est un des aspects différenciants de Drizzle, suite à un choix précis de ses développeurs. Mais il est plus difficile d’avoir confiance s’il n’y a pas de moyen de rentrer dans le code ou le vérifier : « Avoir un client open source comporterait de nombreux avantages : examen par les pairs de la sécurité et du code, pouvoir plus vite le transporter vers de nouvelles plates-formes, développement plus rapide et corrections de bugs. »

38À défaut d’un code véritablement « ouvert » à la modification, par une licence libre, un autre utilisateur revendique, plus bas dans la même discussion, un code publiquement accessible et consultable :

« Même si vous ne mettez pas le code source sous licence GPL, ce serait au moins très bien si vous le publiez pour permettre aux gens de vérifier votre promesse de sécurité. Toute personne choisissant spécifiquement Drizzle, plutôt que d’autres solutions, se soucie de l’encryptage. N’est-ce pas (ce groupe) qui paie vraiment vos factures ? N’est-ce pas (ce) groupe qui a la volonté d’amener ses amis et ses familles à utiliser Drizzle au lieu de Dropbox et les autres ? »

39La conclusion de l’utilisateur Christian remarque, encore une fois, que c’est la capacité de Drizzle à se différencier d’un point de vue technique et économique qui est en jeu :

« Ce n’est pas seulement une question de confiance dans le fait que vous n’êtes pas mauvais, mais aussi de confiance que vous n’êtes pas en train de faire des erreurs dans le processus d’encryptage. Sans avoir une plus grande sécurité il n’y a pas beaucoup de raisons d’utiliser Drizzle plutôt que quelque chose comme Dropbox. »

40Sous la pression, Philipp, à ce moment l’un des membres plus récents du staff Drizzle, donne une intéressante réponse aux partisans de l’open source :

« En fait, nous n’avons aucune raison de vous mentir ici : ce n’est tout simplement pas notre modèle d’entreprise, il faut entretenir une communauté open source ainsi qu’en obtenir des choses. […] L’open source est une façon de créer la confiance. Mais vous faites confiance à votre banque, par exemple, même si vous ne pouvez pas aller voir leurs coffres. La différence entre Drizzle et Dropbox est que nous avons fait en sorte que nous n’avons même pas les moyens techniques pour trahir votre confiance. Pour rester dans la métaphore bancaire : Dropbox est comme un compte bancaire. Si la banque fait faillite, vous perdez votre argent. Drizzle est comme un compte de dépôt, où vous gardez le contrôle de vos données, même si nous devions être compromis à un moment. »

41Plusieurs éléments sont présents dans la réponse du développeur Drizzle. Tout d’abord, Philipp propose une redéfinition de la confiance que les utilisateurs cherchent à établir au moyen de l’ouverture du code, en suggérant une alternative qui évoque la « privacy par l’architecture » négociée par Sladder. Comme l’avait fait Georg Schneider, le représentant de Drizzle met l’accent sur les contraintes posées par le modèle technique de choix des développeurs. Un modèle technique se dessine où l’encryptage en local d’abord, et la fragmentation après – avant toute opération de partage ou téléchargement qui implique une circulation des données dans le réseau – fournissent, selon Drizzle, la preuve que la firme « n’aurait même pas les moyens techniques » de trahir la confiance des utilisateurs. Dans le pire des cas – celui où le réseau serait compromis – un éventuel attaquant en retirerait seulement des fragments non exécutables, et sans signification indépendante.

42Cet argument n’est pas une réponse directe à la question de l’ouverture du code, mais plutôt une négociation de ce qui est important pour l’entreprise et qui pourrait aussi l’être pour ses clients. Il vient renforcer une considération qui a trait au modèle économique de la firme, comme Dietrich l’avait souligné antérieurement. Une communauté de développeurs open source « auxiliaires » est, pour une firme avec des disponibilités de ressources financières et humaines très limitées, autant un investissement qu’une ressource : les retours, les critiques et les apports nécessitent de temps et d’attention afin d’être gérés, triés et incorporés au projet principal. La fermeture du code source est donc finalement présentée comme une décision pratique, que des développeurs « purs », baignant dans une culture de logiciel libre, n’auraient pas pris. Mais les entrepreneurs qu’ils sont devenus doivent prendre cette décision – peut-être temporairement, peut-être plus par nécessité que par choix – pour la durabilité de l’entreprise en considération de ses possibilités.

STOCKAGE « SOCIAL » ET PROTECTION DE LA VIE PRIVÉE

43« En 2007, tout était en train de devenir social », se remémore deux ans plus tard Dietrich Poell. Cette référence à l’explosion des médias sociaux, qui, Facebook et Twitter en tête, entraient à ce moment de façon de plus en plus omniprésente dans le quotidien de millions d’internautes, situe les « premiers pas » de Drizzle dans un contexte et une communauté de recherche et de développement qui, tout particulièrement depuis 2005, travaille à la mise au point de systèmes hybrides, au croisement entre réseaux P2P et réseaux sociaux.

44En 2007, Facebook existe depuis désormais trois ans. Des millions d’internautes y participent, et contribuent au succès massif de ces services basés sur le Web qui permettent aux individus de construire un profil public ou semi-public au sein d’un système fini, de définir une liste d’autres utilisateurs avec lesquels entretenir une relation, et de voir/parcourir la liste de leurs connexions et celles faites par d’autres au sein du système [Boyd & Ellison, 2007]. En parallèle à leur croissance spectaculaire, ces réseaux sociaux suscitent des vives discussions et controverses, à la fois parmi les experts et le grand public, au vu des usages que leurs administrateurs font des données privées des utilisateurs, parfois en permettant à des applications extérieures d’y accéder, et parfois à des fins commerciales directes [Boyd, 2008]. Des voix se lèvent, à la fois parmi les chercheurs en informatique et en droit des nouvelles technologies [Acquisti & Gross, 2006 ; Elkin-Koren, 2006], pour souligner que peu d’utilisateurs ont conscience du fait qu’en utilisant ces applications, ils laissent ouvert l’accès, par des publics non ou mal définis, à certaines informations privées conservées sur les serveurs des entreprises qui proposent les services – comportement qui est défini comme risqué par plusieurs commentateurs.

45Dans ce contexte, plusieurs développeurs, parmi lesquels figure l’équipe Drizzle, travaillent au croisement de deux grandes « tendances d’utilisation ». D’un côté, ils identifient dans une architecture de réseau de type P2P une façon possible d’aborder sous un angle novateur les questions de privacy des données personnelles – par leur relocalisation et « réappropriation » dans les terminaux des utilisateurs, qui pourraient héberger leur propre profil et les informations qu’il contient [Moglen, 2010 ; Aigrain, 2010, 2011]. De l’autre, ils voient dans la modélisation au niveau architectural des phénomènes qui assurent alors le succès retentissant des réseaux sociaux – tels que les liens d’amitié, la formation de communautés et groupes, l’attribution de différents degrés de confiance – une façon de remédier à certaines fragilités des réseaux P2P classiques : afin de rendre filtrages, blocages et identifications plus difficiles, ceux-ci maintiennent autant que possible l’anonymat des utilisateurs même quand la connaissance réciproque de l’identité entre nœuds communicants aurait rendu le réseau plus robuste [Figueiredo et al., 2008].

46Dietrich et son équipe travaillent donc sur quelque chose « à la mode », comme remarque ironiquement Kurt. L’idée de faire de Drizzle un dispositif de « stockage social en P2P » remontait cependant aux premières phases du projet, qui précède, bien que de peu, la véritable explosion des réseaux sociaux en Europe. Le mémo que Dietrich avait soumis au VentureLab en 2006 contenait déjà l’idée de continuité entre la fonction de stockage et celle de partage, et soulignait l’aptitude de la technologie P2P à soutenir cette continuité :

« Un utilisateur peut stocker en toute sécurité ses fichiers privés en ligne, de sorte qu’il puisse facilement y accéder de n’importe où à tout moment. Plus important encore, il peut aussi utiliser [le même logiciel] pour partager ses fichiers, photos, vidéos numériques, de la musique ou des documents avec ses amis […] L’ouverture et la distribution du système permettent une multitude de possibilités. Des services tels que Yahoo ! Photo, Flickr, YouTube et YouSendIt démontrent de manière impressionnante la nécessité de stockage en ligne gratuit. Grâce aux ventes massives d’appareils photo et vidéo numériques et la propagation continue de logiciels de production d’images, de vidéos et de musique, ce besoin sera constamment en train de croître. Plus de 100 millions d’internautes partagent déjà leurs photos numériques et clips vidéo en ligne aujourd’hui. »

47Les développeurs de Drizzle travaillent donc sur une architecture qui puisse mêler une structure distribuée, avec le déroulement de certaines opérations de sécurisation et conservation de données en local, à des dynamiques propres au réseautage social, dans lequel des liens directs – directs dans les « couches inférieures » aussi bien qu’au niveau de l’interface – peuvent être établis entre les utilisateurs pour les opérations de partage. Les infrastructures de réseautage social étant parfaitement aptes à découvrir et établir des liens sociaux, mais très peu aptes à permettre des connexions entre un usager et ses pairs au moyen de liens de réseau (liens « matériels », au niveau de l’architecture), le défi devient pour les développeurs d’envisager une architecture novatrice, capable d’intégrer le réseautage aux deux niveaux de l’interface et de l’application (voir aussi [Figueiredo et al., 2008]).

48Encore une fois, c’est une conception de la confidentialité qu’on a déjà appelé « privacy par la technique » qui se dessine dans la démarche de l’équipe Drizzle et que l’entreprise souhaite proposer à ses clients. Cette conception de la privacy prend forme avec les contraintes et les opportunités liées au traitement et à l’emplacement des données, selon les moments et les opérations se déroulant au sein du système ; en particulier, avec le rapport entre la confidentialité des données (personnelles, mais aussi les contenus stockés dans le cloud P2P) et le système d’allocation de ressources sur lequel se base le dispositif. Elle s’explicite tout particulièrement dans les discussions et les évolutions du rôle, dans l’économie du système, de deux « objets » : le mot de passe qui identifie l’utilisateur vis-à-vis du réseau, et la clé d’amitié qui sert à deux utilisateurs pour échanger des contenus entre eux.

Mot de passe et responsabilité de l’usager

49Dans les intentions de Dietrich, le rôle du mot de passe sélectionné par l’utilisateur pour le système Drizzle devait être quelque chose qui « frapperait l’utilisateur dès qu’il aurait eu accès au système pour la première fois ». En effet, le formulaire virtuel qui s’ouvre lors de la première souscription au service peut surprendre l’utilisateur : il informe que « Nous ne connaissons pas votre mot de passe car il ne quitte jamais votre ordinateur. S’il vous plaît, n’oubliez pas votre mot de passe et utilisez, le cas échéant, l’indice de mot de passe. »

50Le statut du mot de passe est donc négocié, au-delà de sa signification habituelle d’identifiant unique vis-à-vis du système, pour définir, préciser et « légitimer » le processus d’encryptage et décryptage en local des données du système Drizzle. Sous cet aspect se concentrent la promesse de sécurité et de privacy de Drizzle et la confiance de l’utilisateur, puisqu’il devient le symbole et la représentation graphique de la dimension « locale » du processus d’encryptage, du fait qu’il ne quitte pas l’ordinateur de l’usager qui l’a crée. Les opérations, pour la plupart gérées de façon automatique, liées à la protection des données personnelles sont donc hébergées sur la propre machine de l’utilisateur. Celui-ci voit sa place au sein de l’architecture de l’application modifiée : nœud dans un réseau de nœuds équivalents, il devient lui-même un serveur, plutôt qu’un point de départ et d’arrivée pour des opérations qui sont par ailleurs conduites sur une autre machine.

51En attribuant ce statut au mot de passe, les développeurs de Drizzle proposent aussi un rééquilibrage entre les droits que l’utilisateur exerce sur ses données et les droits acquis par le fournisseur du service sur ces mêmes données, au moyen d’un compromis. Puisque le mot de passe demeure chez l’utilisateur et n’est pas envoyé aux serveurs de la firme, celle-ci ne peut pas récupérer le mot de passe si besoin : l’utilisateur ne voit donc pas seulement sa privacy renforcée, mais en même temps et pour les mêmes raisons, la responsabilité de ses actions dans le système se voit augmentée – tandis que le fournisseur renonce à une partie de son contrôle sur les contenus qui circulent grâce au service qu’il gère. Les conditions d’utilisation de Drizzle, plus spécifiquement, sa politique de confidentialité, rendent ce compromis officiel :

« Drizzle encrypte et décrypte tous les fichiers localement. Votre mot de passe ne quitte jamais votre ordinateur, par conséquent, nous ne connaissons pas votre mot de passe. Cela permet de protéger votre vie privée, mais signifie également que, à part vous envoyer l’indice de mot de passe (spécifié lors de la création de votre compte, ou lors de la vérification de vos paramètres de compte) nous ne pouvons pas vous aider à le récupérer. Si vous avez oublié votre mot de passe, vous pouvez demander votre indice de mot de passe. Si celui-ci ne vous aide pas, nous ne pouvons rien y faire. Puisque votre mot de passe ne quitte jamais votre ordinateur […] nous ne pouvons pas récupérer votre mot de passe. »

52La signification de cette « renonciation », explique Dietrich, est double : d’un côté, l’équipe Drizzle souhaitait rendre évident, presque « traduire » dans un objet spécifique, auquel l’utilisateur puisse aisément faire référence, le processus « obscur » et peu familier de l’encryptage en local, qui, comme on l’a vu, suscite des controverses et des perplexités. De l’autre côté – ce qui avait été souligné par Philipp au cours du débat sur la fermeture du code source – il est aussi question du modèle économique de Drizzle : plus l’entreprise connaît d’éléments par rapport à ses utilisateurs, plus elle est obligée de soumettre ceux-ci à une surveillance et un contrôle périodiques, ce qui nécessite, encore une fois, un investissement de ressources et de temps : « Si nous pouvons savoir ce qui est dans votre compte, en commençant par votre mot de passe, nous avons des obligations accrues de surveiller le contenu et s’assurer que personne ne peut intercepter le trafic. »

Liens directs et « clé d’amitié »

53Le deuxième point critique auquel l’équipe se trouve confrontée au cours de sa démarche de développement est le moment où les contenus que l’utilisateur introduit dans le système, une fois encryptés et fragmentés, quittent la dimension locale du client P2P installé sur l’ordinateur de chaque utilisateur, pour être dispersés et stockés dans le réseau P2P – l’ensemble des ordinateurs des usagers – et les centres de données Drizzle. Comme le souligne Kurt, le défi qui se posait à l’équipe de développeurs à ce stade était double : non seulement assurer qu’à tout moment l’extraction d’un fichier est possible, mais aussi qu’aucun usager du système n’a accès à des contenus dont il n’est pas le destinataire prévu : en somme, il s’agit pour les développeurs d’obtenir un équilibre entre l’agilité du dispositif et la confidentialité des données qui circulent.

54À la démarche qui se base sur les trois aspects d’encryptage, fragmentation et redondance, les développeurs doivent superposer une « couche » qui puisse sécuriser les échanges et les partages entre utilisateurs. La manière de façonner cette couche est pendant longtemps sujet de débat. C’est seulement dans un deuxième temps que – peut-être, note Dietrich, l’idée a pris forme avec le bruit médiatique autour des « serveurs tout-puissants » de Facebook – l’équipe décide de travailler sur un système pouvant permettre des échanges directs aux deux niveaux de l’interface et de l’application.

55Le choix, qui a déjà été opéré, de baser le système sur une architecture P2P leur facilite la tâche, puisque la mise en relation directe de deux machines échangeant des paquets de données aurait une contrepartie intuitive dans le geste d’échange ou de partage effectué par les utilisateurs au moyen de l’outil social :

« Le système distribué, qui rend la programmation plus complexe en d’autres domaines, pour une fois, nous permettait de construire un système dans lequel l’expérience de l’utilisateur refléterait ce qui se passait en dessous. Chaque fois qu’un utilisateur a publié un fichier, la clé d’encryptage de ce fichier allait être rendue publique, mais même, lorsque l’utilisateur souhaitait partager quelque chose avec d’autres utilisateurs spécifiques, les clés de ces dossiers seraient révélées en toute sécurité, seulement aux amis et aux groupes destinataires du fichier avec. Entre nous [les développeurs], à un certain moment nous avons appelé cela la clé d’amitié, et c’est quelque chose qui est resté par la suite. »

  • 63 L’expression « No strings attached », qui signifie « sans conditions (déplaisantes) », veut dire l (...)

56Pour les opérations de partage, la « clé d’amitié » entre donc en jeu, une autorisation d’échange qui doit être connue seulement de celui qui l’attribue et de celui qui la reçoit, et qui permet de reconstituer le fichier. L’introduction d’un mécanisme d’« ajout d’amis », propre des réseaux sociaux, et le rapport direct entre le lien d’amitié établi et l’accès aux données de l’ami – mise en relation dont sont éliminés les intermédiaires – doivent renforcer ultérieurement la dimension de confidentialité dans les activités de stockage et partage. Au cours de la Google Tech Talk, Dietrich dépeint la « clé » comme étant le principe de base des échanges dans Drizzle, et ne résiste pas à la tentation d’insérer, en conclusion de son discours à prévalence technique, une référence à l’actualité qui ne manque pas d’humour63 :

« Quand ils deviennent amis pour la première fois, Alice et Bob échangent la clé d’amitié ; maintenant Alice encrypte le fichier avec la clé de l’amitié – il s’agit d’une simplification de ce qui se passe réellement, mais cela sert comme exemple – et elle l’échange avec Bob, qui procède à télécharger le fichier. No strings attached, et pas de serveur attachés, non plus. »

57Si l’interface de la version alpha de Drizzle est développée pour ressembler beaucoup à tout système de fichiers, avec ses dossiers aux couleurs différentes selon le niveau plus ou moins élevé de confidentialité dont ils sont investis, les fonctionnalités « sociales » du dispositif se voient accentuées, lors de l’introduction de la version beta, par son interface utilisateur. Celle-ci est désormais construite, remarque Dietrich, de manière à suggérer une continuité avec les réseaux sociaux qui deviennent de plus en plus populaires : le vocabulaire de « profil », « partage », « amis » et « groupes » est repris, en prévoyant que chaque usager puisse attribuer différents degrés de confiance à ses amis (ou à l’ensemble du réseau pour les contenus publics), pour chacun des fichiers qu’il stocke dans Drizzle.

58Les notions de réseau social et de clé d’amitié sont donc comprises ici non seulement comme une « couche marketing », ou comme une manière de structurer l’organisation pratique du stockage, mais elles contribuent aussi à changer le dispositif dès le niveau de l’architecture. Elles proposent une définition d’organisation sociale des utilisateurs, qui a trait à la confiance réciproque et à l’ouverture/mise à disposition d’une partie de ses ressources informatiques – ainsi qu’à une reconfiguration de la chaîne des intermédiaires dans l’acte d’échange et de partage.

Confidentialité des données et allocation de ressources

59Le troisième aspect qui marquera la définition de la privacy à l’œuvre dans Drizzle survient lors de la mise au point de la politique de confidentialité du système. En effet, l’équipe y introduit, suite au démarrage de la version beta, une section précisant les conditions d’allocation, à telle ou telle autre opération de stockage et partage, des ressources des ordinateurs participants au système.

  • 64 On se rappellera les conditions d’utilisation de Drizzle : « L’utilisateur reconnaît que Drizzle p (...)

60Dès le lancement de la première version du dispositif, le statut très particulier des ressources utilisées par le système avait rendu nécessaire de préciser dans les conditions d’utilisation un certain nombre d’aspects : le rôle des ordinateurs des usagers, les types de ressources qui pouvaient être utilisées par Drizzle, leurs fins, et comment l’utilisateur pouvait établir, et communiquer au système, la quantité maximale de ses ressources locales mises à disposition du réseau-système de stockage64. Mais cette première version des conditions d’utilisation n’explicite pas l’articulation entre la mise à disposition de ressources de la part des utilisateurs et la façon dont les ressources sont affectées ou attribuées à des opérations différentes par le système.

61Pourtant, comme en viennent à le conclure Dietrich, Kurt et leur équipe, la façon dont s’articulent ces deux aspects a des implications importantes pour la confidentialité des données circulant dans le système [à la fois les informations personnelles des utilisateurs et les contenus stockés]. L’« accaparement » et l’allocation des ressources de la part du système Drizzle ou de la firme Caleido impliquent pour les utilisateurs une surveillance possible ou un monitorage de ces ressources, de façon qui peut être plus ou moins automatique, invasive, poussée. Le problème est notamment posé par un utilisateur sur le forum de Drizzle en avril 2009, et à la suite de cette discussion, deux modifications sont apportées aux conditions d’utilisation un mois plus tard : si les termes d’utilisation généraux indiquent désormais que « Les ressources sont allouées et contrôlées conformément à la politique de confidentialité », celle-ci précise le degré d’automation et d’omniprésence du système d’allocation et monitorage des ressources :

« Afin d’assurer une répartition équitable des ressources au sein de Drizzle, plusieurs types de données concernant les ordinateurs participant au réseau Drizzle sont recueillies. Ces données comprennent les adresses IP, la disponibilite et le montant des ressources qu’ils contribuent (par exemple bande passante et mémoire). […] Drizzle garde la trace de combien d’espace de stockage vous avez utilisé et gagné dans le système. […] Drizzle collecte des informations statistiques à des fins de surveillance, débogage et amélioration de Drizzle. Cela inclut des rapports générés automatiquement, au sujet des problèmes, performances, analyses de réseau, ainsi que les logs des connexions et les requêtes effectuées sur les serveurs de Drizzle, et des données analytiques sur l’utilisation du site Drizzle. Cependant, aucune de ces données ne contient des informations à partir de vos fichiers privés ou partagés. »

62Le fonctionnement du système d’allocation comporte donc effectivement le rassemblement de certaines informations concernant les ressources matérielles, de mémoire, de calcul, mises à disposition par les ordinateurs participants. Cependant, ces informations sont traitées automatiquement et de façon agrégée, à des fins statistiques. La récolte d’informations, affirme la version révisée du document, a pour but le calcul automatique de la quantité d’espace de stockage que chaque utilisateur met à disposition (et, comme on le verra dans la prochaine section, de la mesure dans laquelle il peut réclamer du « cloud P2P », c’est-à-dire un espace de stockage équivalent dans le réseau d’ordinateurs participants).

63Les développeurs font aussi appel à l’esprit collaboratif des utilisateurs, en sollicitant des retours sur le forum et sur d’autres plateformes, et en soulignant l’utilité que ces informations auront pour l’amélioration et le développement ultérieur du dispositif. Mais surtout, en reformulant l’enjeu essentiel de ce système d’allocation – la stabilité et durabilité de Drizzle – le document contribue à séparer cet enjeu de la question de la confidentialité des données personnelles et des contenus stockés. Les informations rassemblées sur l’équipement de stockage (c’est-à-dire, les ressources locales des utilisateurs, que chacun d’entre eux met à disposition) n’impliquent pas une intrusion dans les contenus stockés eux-mêmes. Ceux-ci restent, en principe, sauvegardés par le système mis en place au moyen de l’encryptage et de la fragmentation des contenus ; de la sauvegarde du mot de passe en local ; des partages directs, basés sur l’échange des clés d’amitié.

ESPACE DISQUE CONTRE ESPACE EN LIGNE

64Deux années après la sortie du closed alpha – à l’automne 2009 – l’équipe semble demeurer assez perplexe quant aux modèles économiques pouvant s’adapter au système de stockage distribué qu’ils ont développé et qu’ils sont en train de perfectionner. Dietrich envisage soit la possibilité de faire acheter aux utilisateurs/clients de l’espace de stockage dans les centres de données Drizzle pendant la phase d’amorçage, soit d’installer un système d’annonces publicitaires, bien que pour le moment – déclare-t-il – l’équipe donne la priorité au développement de la technologie, pendant que la firme vit sur les revenus de l’Address-Book et d’autres produits et services « classiques » : « Je crains que nous n’avons pas encore d’idées brillantes sur la façon de rendre cette entreprise rentable, mais cela n’a pas du tout été notre objectif, loin s’en faut. »

65De son côté, Kurt souligne que la technologie de cloud P2P sous-tendant Drizzle est assez complexe à implémenter, et mérite que les efforts de l’équipe s’y concentrent de façon prioritaire. L’objectif est de mettre sur le marché un produit déjà doté d’une certaine stabilité et fiabilité, et en des temps relativement rapides :

« Notre attention était sur la technologie et les utilisateurs, ou plutôt, sur les utilisateurs et la technologie. Drizzle est une technologie complexe avec de nombreuses applications potentielles, et l’un des plus grands défis était de se concentrer sur son développement. Ceci est particulièrement important pour quelque chose qui prend des années pour mûrir, tandis que la terre tourne et change les choses. Pour nous, il était très important de publier vite une version alpha fermée et inviter des utilisateurs clés qui pourraient inviter leurs amis, afin que nous puissions écouter les commentaires et construire l’application en collaboration avec nos utilisateurs. »

66Plus d’une année après – début 2011 – à côté de mécanismes de revenus supplémentaires comme la vente d’espaces additionnels, le véritable cœur du modèle technique de distribution à l’œuvre dans Drizzle est devenu aussi bien son modèle socio-économique : un utilisateur peut échanger l’espace inutilisé du disque dur de son propre ordinateur contre de l’espace de stockage sur le « nuage d’utilisateurs » de Drizzle, pourvu qu’il reste en ligne un certain temps par jour.

67Le principe à la base de ce mécanisme de troc entre espace disque et espace en ligne, envisagé par Dietrich et son équipe, n’est pas de donner une plus grande capacité de stockage mais plutôt d’améliorer la qualité de l’espace de stockage dont l’utilisateur est normalement doté sur son disque dur ; il y gagne la possibilité de transformer son disque dur local en disque dur en ligne, potentiellement accessible en mobilité, et cela même si son propre ordinateur est éteint. Bien que ce modèle ne fournisse pas des revenus directs, de son côté, l’entreprise s’assure ainsi une certaine durabilité dans le temps des ressources matérielles et computationnelles à sa disposition, la stabilisation d’un ensemble d’usagers « pro », et la possibilité de s’appuyer sur ce noyau de ressources dont la présence est plus « sûre » pour proposer des solutions de stockage ad hoc à des acteurs institutionnels et du secteur privé.

Au commencement était l’application bureau… qui rencontra le Web

  • 65 Le web start de Java (une plateforme permettant d’exécuter des programmes écrits en langage de pro (...)

68Avant le démarrage du closed alpha, une discussion s’engage au sein de l’équipe sur la « porte d’entrée » de l’utilisateur dans le système Drizzle. Deux alternatives sont considérées : une application bureau (ce qui nécessiterait une installation, de la part de l’utilisateur, d’un logiciel client sur sa machine) et la possibilité de démarrer Drizzle directement depuis le web, au moyen d’une application Java65, sans que le téléchargement ou l’installation soient nécessaires, afin de faciliter l’accès aux fichiers « en mobilité », sur plusieurs machines, mais conservant la dimension « locale » des opérations d’encryptage et décryptage.

69Par ailleurs, Drizzle ne sera pas un service Web basé sur un navigateur, car cela comporterait une rupture totale avec la partie « en local » du modèle, avec la conception particulière de sécurité et confidentialité que celle-ci comporte – et donc avec ce qui différencie le système de stockage par rapport à ses concurrents :

« Vous vous demandez peut-être, pourquoi Drizzle n’a pas d’application web basée sur un navigateur comme tous les autres services de ce type ? La réponse est simple […] pour qu’une application web puisse fonctionner, un serveur web devrait envoyer vos données dans un format non crypté vers votre navigateur – certes possible via une connexion HTTPS sécurisée, mais les données seront tout de même complètes – car aujourd’hui, les navigateurs ne sont pas capables de faire le chiffrement et le déchiffrement des données en local. Cela signifie que ce serveur web aurait besoin de connaître la clé pour décrypter vos fichiers. En opposition avec d’autres services, Drizzle crypte et décrypte tous les fichiers directement sur votre ordinateur. […] Par conséquent, notre serveur web ne connaît pas la clé de vos fichiers, et ne peut donc pas les décrypter. En bref : toutes les applications par navigateur Web ont accès à vos données. Puisque le mécanisme de sécurité de Drizzle ne permet pas l’accès à vos fichiers, vos données ne sont pas accessibles par une application web. »

  • 66 On se rappellera la controverse autour du téléchargement du client P2P dans le cas de Sladder.

70Bien qu’il soit clair à ses yeux que le client, porte d’entrée dans le réseau P2P, est fondamental d’un point de vue à la fois technique et « symbolique », Dietrich se montre initialement assez perplexe quant à la possibilité que Drizzle soit exclusivement une application bureau, car l’intégration à d’autres services serait moins immédiate ; par conséquent, l’utilisateur devrait investir plus de temps et de ressources dans son « premier essai » de Drizzle, et risque peut-être de se désister à l’idée de devoir installer le client en local66.

  • 67 L’intégration Facebook ne sera pas implémentée par la suite.

« Avec l’idée P2P à sa base, Drizzle est clairement né comme une application bureau […] Il y a beaucoup d’avantages à une telle application. Cependant, on a bientôt commencé à travailler à une intégration dans le navigateur Web, afin que les gens soient en mesure d’accéder aux données aussi à travers le web. En outre, nous pensons qu’il est important dans la phase de lancement que les gens puissent se relier et se rapporter facilement à Drizzle et en faire une partie de leurs habitudes quotidiennes, donc il peut y avoir une intégration Facebook67. »

71La discussion qui s’engage parmi les utilisateurs lors de la sortie du closed alpha, qui ne comporte pour le moment que l’application bureau, ne contribue pas à établir une préférence claire parmi les utilisateurs, dont les développeurs pourraient tenir compte dans les étapes suivantes. Selon les priorités des différents utilisateurs, soit le téléchargement du client, ou même de l’application Java pour le démarrage direct depuis le Web, est vu comme un poids excessif par rapport à l’agilité que pourrait offrir une interface web ; soit il est considéré comme une composante « incontournable » de la promesse de sécurité offerte par l’encryptage des données en local, l’aspect essentiel pour la différenciation du produit par rapport à ses nombreux compétiteurs :

« Je n’aime pas la façon dont vous devez télécharger une application de bureau ou une application Java pour voir les fichiers que vous avez sur Drizzle. J’aimerais beaucoup plus s’il y avait une interface web… le logiciel est presque 7.5 Mo ! c’est fou ! »
« Vous vous soucier de la securite de vos fichiers et vous voulez une interface WEB ? NON ! Je veux quelque chose en LOCAL qui je sais va encrypter mes fichiers avant qu’ils ne quittent mon ordinateur. Drizzle fait justement cela. »

72C’est finalement l’importance de l’encryptage en local, réaffirmée par plusieurs utilisateurs, qui amène Dietrich et l’équipe Drizzle à pencher vers une solution à deux faces, qui fait co-exister le client et le démarrage depuis le Web au moyen de Java – et à rejeter cependant une solution « purement Web ». D’un point de vue technique, l’application bureau réaffirme les aspects « locaux » de la démarche de stockage et partage ; du point de vue du positionnement économique, elle veut réaffirmer aux yeux des usagers l’avantage concurrentiel du dispositif et l’« originalité » du dispositif.

  • 68 Ce qui, comme on verra dans la dernière section, sera source de nombreuses controverses quant au s (...)

73Le choix d’avoir une double « porte d’entrée » au système, mêlant client et démarrage Web, détermine par ailleurs, pour la première fois, un déplacement qui influencera de manière significative, par la suite, l’évolution du dispositif. De « stockage social en P2P », le service sera désormais appelé « cloud P2P » : les aspects de réseautage social co-existent maintenant avec une idée de plateforme, un système plus souple, accessible en mobilité – ainsi que plus évanescent et moins clair à appréhender pour l’utilisateur68. Le principe du « faire le pont entre le bureau et le Web » devient la pierre angulaire du modèle économique de Drizzle : le troc d’espace sur le disque dur de l’utilisateur contre de l’espace de stockage en ligne.

Troc et « Qualité de service »

  • 69 Dans cette même perspective de recrutement et d’intéressement, l’offre de base au stade de closed (...)

74Comme on l’a déjà évoqué, l’option de stockage partagé n’est pas proposée, au début, en tant que choix obligé pour l’utilisateur : au cours de ses premiers mois d’existence, Drizzle est en effet programmé pour donner la possibilité aux utilisateurs ayant besoin de moins d’un gigaoctet de mémoire pour leur stockage de ne pas l’obtenir du réseau d’ordinateurs connectés, mais des serveurs de la firme, comme offre de base gratuite. Cette option fait partie des mesures de « recrutement » et de stabilisation d’une base d’utilisateurs, que l’équipe estime opportun de mettre en œuvre pendant la phase d’amorçage69, mais ne rencontre qu’un intérêt très mitigé de la part des usagers de la première heure. Ce qui, comme le souligne Dietrich, était peut-être à prévoir – les utilisateurs pionniers de Drizzle « s’intéressent spécifiquement au système de stockage partagé, ce qui comporte le mécanisme de troc », et forment un groupe plus concerné que l’utilisateur lambda par les aspects techniques de l’infrastructure P2P qui le rendent possible.

75Au-delà de l’offre de base, une alternative est proposée à l’utilisateur pour étendre cette capacité. Il peut soit acheter des gigaoctets de mémoire supplémentaires, qui lui seront attribués sur les serveurs Drizzle, soit mettre à la disposition de Drizzle une partie de son disque dur : il pourra ainsi troquer de l’espace inutilisé du disque de son ordinateur contre un stockage équivalent sur la plateforme d’utilisateurs Drizzle.

76La façon de quantifier les ressources dont chaque utilisateur peut disposer dans le système est établie de la manière suivante : elle dépend de la quantité d’espace que chaque utilisateur fournit en local, multiplié par le pourcentage de temps qu’il passe en ligne : « Le montant des ressources que l’utilisateur est autorisé à utiliser dans Drizzle dépend de la quantité de ressources locales que l’utilisateur contribue à Drizzle, » récitent les conditions d’utilisation.

77Si un utilisateur met à disposition 100 Go d’espace de son ordinateur, il pourra obtenir jusqu’à 100 Go d’espace en ligne en échange, qui variera selon le temps qu’il passe en ligne : s’il reste connecté 70 % du temps, par exemple, il obtiendra 70 Go d’espace en ligne. Comme souligne Dietrich, l’idée à la base de ce mécanisme n’est pas de fournir davantage d’espace de stockage à chaque utilisateur, mais d’en améliorer la « qualité » ; l’espace de stockage en local est converti en espace de stockage en ligne, d’accessibilité plus facile surtout dans des situations en mobilité :

« L’idée derrière le troc de stockage est venue parce que nous avons cherché à améliorer la qualité de stockage des utilisateurs : il n’était pas viable de proposer un accord qui augmentait l’espace disponible, mais il est devenu possible de construire sur l’espace local pour offrir une solution globale et mobile, accessible lorsque l’ordinateur de l’utilisateur lui-même était hors ligne. La valeur du mécanisme de troc dans son ensemble est devenue la meilleure qualité du stockage qu’il était en mesure de fournir, plutôt que la quantité. »

78Une condition est également posée aux utilisateurs, pour qu’ils puissent faire partie du programme de troc : ils doivent être en ligne au moins quatre heures par jour. Encore une fois, il s’agit d’un choix à la fois de stabilisation technique et d’optimisation économique, qui vise à augmenter la stabilité et la persistance d’un « noyau dur » d’utilisateurs prêts à contribuer un minimum de ressources, de manière constante dans le temps, au système distribué : « La raison de ceci est que cela n’a tout simplement pas de sens que de stocker des fragments dans un ordinateur qui est en ligne juste, disons, une demi-heure par jour », dit Kurt.

79La mise en place de ce mécanisme implique également, par la suite, l’implémentation d’une fonctionnalité qui tient compte des fluctuations, au fil du temps, dans la durée moyenne des connexions des utilisateurs. Dès que la condition de rester un minimum de quatre heures par jour en ligne est satisfaite, plusieurs d’entre eux se posent en effet la question de ce qui se passe s’ils diminuent leur temps de connexion – et donc, de ce qui arrivera à leurs données si le stockage qu’ils ont acquis décroit ensuite.

80Un système de « rééquilibrage » est donc mis en place, selon lequel la quantité de stockage en ligne diminue si le temps de connexion moyen d’un utilisateur décroit, ou si l’utilisateur baisse la limite de la quantité d’espace que son client Drizzle a la permission de troquer. Kurt explique que si ce faisant, l’utilisateur arrive à avoir moins de stockage en ligne que la quantité de données qu’il a stockées sur Drizzle, il pourra toujours accéder à ses données mais ne pourra pas stocker des fichiers additionnels jusqu’à ce que son temps de connexion augmente à nouveau ou que, informé du changement de situation par Drizzle, il n’en supprime une partie lui-même.

81L’adhésion au mécanisme de stockage partagé et le fait de rester un certain temps en ligne représentent les deux critères qui permettent de qualifier un utilisateur comme « Pro » au sein du système. La définition d’utilisateur « Pro » reste dynamique au cours des différentes versions du dispositif, mais doit permettre, par exemple, de désélectionner les mécanismes de revenus « parallèles » de Drizzle, tels que les annonces publicitaires.

82Un deuxième critère n’est pas, au début, explicitement noté dans les conditions d’utilisation, mais il devient au fil du temps tout aussi important pour le bon fonctionnement technique et la durabilité du système : le type de connexion Internet des utilisateurs. En effet, plusieurs d’entre eux se voient refuser par leur client Drizzle l’adhésion au programme de troc parce que leur « connexion Internet ne permet pas de troquer du stockage ». Le type de connexion Internet se qualifie donc comme un enjeu de première importance pour que l’utilisateur puisse pleinement bénéficier du mécanisme de troc, car il peut même arriver à constituer une véritable barrière à l’entrée du système, au cas où le client Drizzle se heurte à un pare-feu particulièrement restrictif, qui n’accepte pas les connexions entrantes sur le port utilisé (et affiché) par le logiciel.

83Les nombreux problèmes rencontrés par les utilisateurs à ce sujet amènent finalement l’équipe Drizzle à définir plus précisément la « qualité de service » que l’utilisateur obtient avec le mécanisme de troc. Des données relatives à la connexion Internet, qui peut constituer une barrière a l’entrée de ce mécanisme, font désormais part de cette définition : l’accessibilité de l’ordinateur d’un utilisateur par les autres ordinateurs qui composent le système ; la qualité de la connexion de cet ordinateur à l’Internet ; et la capacité de celle-ci à permettre la circulation de certains types de trafic :

  • * le User Datagram Protocol [UDP] est l’un des protocoles de télécommunication les plus répandus de (...)

Vous pouvez recevoir des données uniquement quand votre ordinateur est accessible, c’est-à-dire uniquement si d’autres ordinateurs peuvent se connecter à vous. […]
4. Connexion non appropriée pour le troc : Drizzle ne peut envoyer et recevoir de paquets UDP*. Il y a de fortes chances que vous soyez derrière un pare-feu restrictif qui bloque le trafic UDP.
Vous pouvez atteindre l’accessibilité complète quand la redirection de port est activée sur votre routeur. Vous devez configurer votre routeur de façon à rediriger les paquets UDP qui arrivent au port Drizzle vers l’ordinateur sur lequel Drizzle est installé.

Derrière le nœud, l’usager : motivation et respect des ressources

84La stabilisation du mécanisme de troc en tant que modèle économique durable pour le stockage distribué passe également par la mise en place d’un système d’incitation des usagers au partage des ressources. Les préoccupations des développeurs de Drizzle rejoignent ici un des enjeux classiques des réseaux distribués : créer un système qui, au moyen de mécanismes de réputation, de motivation et d’attribution répartie de responsabilité, assure une gestion de ressources équitable entre les pairs, à la fois celles que chaque utilisateur peut réclamer du système et celles qu’il apporte à son fonctionnement [Oram, 2001 ; Taylor & Harrison, 2009]. Kurt résume : « Il faut prévenir le free-riding, c’est-à-dire que [comme développeurs] vous ne voulez pas avoir des nœuds qui consomment beaucoup et contribuent peu. »

85Dans le cas de Drizzle, les développeurs doivent prendre en considération pour la mise au point du mécanisme trois types de ressources qui sont directement ou indirectement « partagées » – il s’agit de l’espace disque local, du temps passé en ligne, et de la bande passante.

  • 70 Une motivation supplémentaire, qui sera introduite dans la version beta, est la possibilité de gag (...)

86L’équipe de développeurs décide de travailler sur les deux premiers types de ressources comme s’ils ne constituaient qu’un seul et même aspect, puisque dans l’économie du dispositif, un ordinateur qui reste en ligne pendant de longues sessions – voire en permanence – est particulièrement précieux puisqu’il contribue le plus à la décroissance du facteur de redondance nécessaire au fonctionnement du système. Le principe d’adhésion au mécanisme de troc, selon lequel l’utilisateur gagne autant de stockage qu’il en met à disposition sur son disque multiplié par le temps qu’il passe en ligne, est donc aussi le résultat de la volonté des développeurs de motiver les utilisateurs à rester en ligne de façon la plus constante possible, et pour des longues sessions70. Bien que ce principe ne reflète pas exactement la réalité technique plus complexe que sous-tend le mécanisme, les développeurs de Drizzle souhaitent que

« sa formulation concise et immédiate “accroche” les utilisateurs à l’esprit du système – et de notre côté, on se confronte à cette même réalité technique complexe pour essayer de quantifier et mesurer l’apport de chaque nœud, et le mobiliser pour le bien du système dans son ensemble. On continue a expérimenter, mais on fait des progrès. »

87Il est également important pour la durabilité du dispositif que les utilisateurs allouent une quantité suffisante de bande passante aux téléchargements exécutés au moyen du client Drizzle. Les développeurs choisissent de récompenser la mise à disposition de bande passante de la part de chaque utilisateur en lui attribuant une plus grande rapidité de téléchargement de contenus à partir du cloud P2P. Du point de vue de l’usager, résume Kurt, la motivation à la base de l’allocation de bande passante au service se veut donc assez clairement identifiable et compréhensible : « plus de bande passante vous mettez à disposition des téléchargements des autres, plus grande sera la vitesse de vos téléchargements ».

88La partie la plus problématique pour l’équipe se révèle être, encore une fois, l’implémentation technique de ce principe d’allocation de ressources – ou plus précisément, du mécanisme qui devra monitorer et éviter les « passagers clandestins » ou free-riders [Adar & Huberman, 2000 ; Shirky, 2001], et faire que le système Drizzle ne soit pas formé de nœuds minimisant chacun de leur côté leur contribution de bande passante au système, le transformant en un réseau de « presqu’îles ». Le choix de la réciprocité, « un prêté pour un rendu » («  tit-for-tat ») est laissé de côté au vu de l’asymétrie des intérêts des utilisateurs/nœuds : c’est-àdire, il n’arrive presque jamais que deux nœuds réclament une ressource l’un de l’autre à un même moment. Par ailleurs, l’idée de faire surveiller les transactions par les logiciels clients des utilisateurs eux-mêmes est aussi éliminée, au vu de la relative facilité avec laquelle un utilisateur averti pourrait en truquer les véritables performances :

« le logiciel client suivrait les contributions de différents types d’utilisateurs, puis les rapporterait chaque fois qu’il y a une transaction. Mais bien sûr, ce n’est pas une bonne idée parce que le logiciel client peut facilement être piraté en cette circonstance. Un exemple a été Kazaa. »

89La solution qui est finalement adoptée par Drizzle est un mécanisme de motivation et de réputation qui tire profit de l’aspect distribué du système pour limiter les effets néfastes de fausses informations éventuellement envoyées par les clients. Il est aussi important pour les développeurs que le système soit capable de passer à l’échelle avec une grande quantité de petites transactions.

90La pierre angulaire de ce système de réputation devient donc la capacité de chacun des nœuds du réseau à exécuter de manière automatique un grand nombre de transactions et observations, de garder trace de la bande passante qu’ils ont reçue pendant ces transactions, et de partager cette information avec un nombre limité et prédeterminé de nœuds voisins, plutôt qu’avec l’ensemble du système. Cela, explique Dietrich, limite l’influence des informations qui ne seraient pas fiables, car « si vous cherchez à attaquer le système, vous ne pouvez pas influer sur l’ensemble du réseau, mais seulement sur votre voisin immédiat », et permet une mise à jour progressive de la « réputation » des différents nœuds de stockage – ce qui se traduit, à son tour, par une allocation de bande passante en proportion à la réputation.

91L’importance que le mécanisme de troc assume dans le dispositif rend ses éventuelles défaillances très importantes aux yeux des utilisateurs. C’est la petite équipe de soutien technique de Drizzle qui se trouve, dans ces cas, particulièrement sollicitée. Son responsable, Hans, en arrive à définir son propre travail, pendant la période très délicate entre le closed alpha et le public beta (juillet 2007 – octobre 2008), comme consistant surtout en « relations publiques avec les personnes nous montrant et nous faisant part de problèmes » au sujet du mécanisme de répartition des ressources. Qu’il s’agisse de problèmes dans le calcul de l’espace en ligne attribué à la suite du troc, ou dans le déroulement des opérations de téléchargement des fragments dans le réseau P2P, ces questions démontrent au jour le jour la complexité du système et l’engagement de la communauté dans son progrès :

« Il y a eu, par exemple, un problème de calcul de l’espace. Après la suppression de certains fichiers, ce gars-là ne récupérait pas l’espace de stockage auquel il s’attendait. Il existe un moyen pour Drizzle de recalculer l’espace, mais la requête doit être faite sur ​une base régulière, car on a un bug connu dans le calcul des quotas, ce qui empêche parfois que l’espace figure à nouveau comme libre. […] Cet autre gars poste un message dans lequel il dit qu’il a maintenant beaucoup de gigaoctets de stockage comme il est beaucoup en ligne et troque beaucoup, et […] le téléchargement semble marcher, je veux dire qu’il montrait la vitesse de téléchargement et tout, mais il a toujours l’affichage de 0 % comme pourcentage du téléchargement, le passage d’heures entières ne changeait rien à ce sujet. Nous avons d’abord pensé que c’était un problème d’affichage, mais ce n’était pas le cas et dans ce cas, vous ne savez pas vraiment, en tant que personne qui doit résoudre le problème, même quelles sont les informations qui peuvent vous être utiles et ceux que vous pouvez simplement éviter. En fin de compte, le gars m’a répondu après beaucoup de va-et-vient qu’au bout de trois jours, le téléchargement était finalement affiché et en cours. »

92Au-delà de leurs effets sur la performance technique de l’outil, les problèmes et défaillances du mécanisme de troc sont parfois associés par certains utilisateurs à une idée de « manque de respect », de la part d’autres utilisateurs ou des développeurs eux-mêmes, pour les ressources qu’ils mettent en commun. C’est ce qui pousse l’équipe à inclure dans le site Web de la firme, à l’intention de l’utilisateur, des indications précises quant à la quantité des ressources à mobiliser dans le système. Qu’il s’agisse de mémoire sur disque ou de bande passante, ces indications sont destinées à obtenir un compromis entre le bon fonctionnement du dispositif et une charge du système Drizzle sur la machine de l’utilisateur qui ne soit pas trop importante – c’est-à-dire, un client P2P qui ne soit pas trop « lourd » pour le terminal.

Nuage d’usagers et culture du partage

93Si l’entretien du système dans ses premières et délicates phases de développement se présente depuis le début comme un aspect à ne pas négliger, l’enjeu principal pour le succès du mécanisme de troc semble pourtant être la manière dont les utilisateurs s’en saisiront et se l’approprieront – comment ils réagiront au fait de stocker ses données dans un environnement qui est en même temps local et global, concentré et dispersé. Le « nuage d’usagers » sera-t-il perçu comme une inconnue encore plus grande qu’une plateforme d’entreprise, ou comme une attribution de confiance à sa communauté ? Comment les utilisateurs se saisiront-ils du système distribué ? Le principe de partage sera-t-il reçu majoritairement comme une opportunité ou comme une complication ou incertitude additionnelle ? Telles sont les questions qui inquiètent quelque peu l’équipe Drizzle au fur et à mesure que les avis sur leur service se multiplient à travers le Net, et que celui-ci est examiné, comparé, testé. Dietrich et son équipe estiment que le succès du dispositif dans son ensemble, ainsi que la survie même de l’entreprise à moyen terme, se joueront essentiellement autour de la question du troc. Il remarque : « non seulement c’était “notre truc à nous”, c’était aussi la chose qui était plus susceptible de soulever beaucoup de questions. »

94Les retours de la part des utilisateurs de la première heure semblent effectivement se concentrer sur la manière dont la distribution du modèle au niveau technique a des effets sur le niveau d’implication, participation et « collaboration » des usagers au dispositif, et reconfigure ainsi leur statut de clients. Certains avis révèlent une appréciation de la possibilité de troquer l’espace disque pour l’espace en ligne, et souscrivent très volontiers à l’option qui constitue à leurs yeux la vraie nouveauté du dispositif, capable de déterminer un avantage économique : « Dans l’ensemble, pour ceux d’entre nous avec des ordinateurs domestiques avec de l’espace inutilisé, cela pourrait être une excellente façon d’obtenir du stockage en nuage pour assez peu cher. »

95D’autres considèrent la situation en termes de coûts et de bénéfices non seulement pour les utilisateurs, mais pour l’entreprise elle-même, et notent que des questions techniques telles l’allocation de bande passante et d’espace disque dans le système distribué se traduisent en modifications très « visibles » pour l’expérience utilisateur :

« Un autre avantage de la “grille” P2P de Drizzle est la bande passante quasi illimitée pour les téléchargements, soit en amont qu’en aval […] J’ai soutenu une vitesse de téléchargement de plus de 900Ko/s, la plus élevée que j’ai vu personnellement dans un service de stockage de fichiers en ligne. »

96D’autres encore relient les caractéristiques techniques de Drizzle avec les tendances courantes du marché de l’industrie informatique, à la fois en termes des contraintes posées par les fournisseurs d’accès Internet sur la quantité de bande passante octroyée à chaque internaute, et des coûts décroissants du matériel informatique nécessaire au stockage présent sur les terminaux domestiques :

« Le troc est aussi intéressant car les FAI continuent à essayer d’imposer des plafonds plus sévères pour l’utilisation de bande passante. Il est donc très important de bien gérer les limiteurs de bande passante de Drizzle, surtout au Canada, où de nombreux fournisseurs ont été forcés par Bell à baisser leurs limites de bande passante à 25 Go par mois. »
« Compte tenu de la façon dont le prix des disques durs à baisse, cela semble être un compromis acceptable. Les utilisateurs qui partagent leur espace disque dur local peuvent également désactiver la publicité sur Drizzle. »

97Enfin, certains commentaires semblent indiquer comme raison principale qui les incite à choisir le mécanisme de troc la dynamique de partage et de réseautage préconisée plus ou moins implicitement par le modèle. Le système Drizzle permet de mettre à profit des ressources qui ne seraient en tout cas pas utilisées activement, et pour un utilisateur, cela représente une valeur intrinsèque :

« Je pense que la fonction de troc P2P de Drizzle est sa meilleure caractéristique. Pour moi, cela me réchauffe le cœur de savoir que je vais partager mes 50 Go supplémentaires d’espace disque dur avec le reste du monde. Mon ordinateur est toujours en marche de toute façon, et j’ai l’espace qu’il me faut. Lorsque vous ajoutez un paramètre de QoS pour mettre Drizzle sur une priorité inférieure, vous ne voyez même pas de changement dans la vitesse du réseau. »

98Avec l’augmentation d’essais et de tests effectués par des utilisateurs avertis, le caractère controversé des choix de distribution et de partage faits par Drizzle commence par ailleurs à prendre forme dans nombre d’autres interventions. Les doutes sur la faisabilité, la durabilité et la “prise en main” du modèle Drizzle se concentrent, suivant les mots des utilisateurs, autour de deux grandes questions.

99La première concerne la stabilité socio-technique du dispositif : la mesure dans laquelle un nombre suffisant d’utilisateurs apportera suffisamment de ressources, de façon suffisamment constante, pour que les contenus stockés sur le système soient présents de façon durable et fiable.

« Je crois que plus de 100 millions de fichiers sont stockés sur la grille Drizzle ? On ne devrait donc pas s’inquiéter que le service pourrait mal fonctionner dans un avenir proche ? »
« Attends, ma capacité à accéder à mes fichiers en ligne dépend du fait que d’autres utilisateurs les gardent sur leurs disques durs et restent connectés à l’Internet ? Oui, je souhaite m’inscrire… »

100Un utilisateur s’inquiète aussi de ce qui peut arriver aux données stockées au cas où leur propriétaire change radicalement la quantité de temps qu’il passe en ligne, jusqu’à descendre de façon régulière sous les quatre heures de connexion par jour qui constituent la condition d’entrée dans le mécanisme de troc :

« Étant donné que vous devez être en ligne un certain laps de temps, il y a des conséquences si vous allez hors ligne. Disons que vous partez en vacances et éteignez votre ordinateur pendant quelques semaines. Vous perdrez probablement une bonne partie, sinon la totalité de votre espace de stockage troqué. »

101La deuxième question, particulièrement soulignée par certains usagers, a trait aux frontières « nuageuses », au sens propre et figuré, de l’accès aux données personnelles ou stockées par d’autres utilisateurs. D’après certains, les répercussions de la distribution et la répartition des données et des ressources, inscrites dans l’outil, sur la confidentialité des contenus et la sécurité des équipements, sont peu claires :

« Même avec les solides techniques d’encryptage utilisées par Drizzle, cependant, le fait que certaines informations vont être stockées sur des machines hors de contrôle, même de celui de Drizzle, ne va pas être bien reçu par beaucoup de gens. Alors que la plupart des utilisateurs privés peuvent probablement vivre avec ces risques (qui sont inhérents à toute solution de stockage cloud), les entreprises vont probablement rester très loin de Drizzle. »

102Certains commentateurs expriment à leur tour leur perplexité, non sur le modèle technique et économique de Drizzle lui-même, mais sur la façon dont il pourra être perçu par l’utilisateur lambda qui ne verrait pas un intérêt intrinsèque aux détails des explications fournies par les développeurs. Ars Technica, un des magazines Web les plus réputés pour l’analyse des tendances de l’Internet, se montre sceptique sur le fait que la « culture de partage », dont Drizzle serait un exemple, est suffisante pour qu’un nombre important d’utilisateurs se laissent convaincre par le modèle d’éclatement des données et des ressources proposé par le service :

« Au très important revers de la médaille, cependant, sont les préoccupations de sécurité que Drizzle évoque, non seulement en stockant des parties de fichiers sur des serveurs hors site, mais sur les ordinateurs des utilisateurs aléatoirement à travers le monde. Les utilisateurs occasionnels peuvent ne pas se soucier si leur collection, durement gagnée, de photos d’Hilary Duff tombe entre des mauvaises mains, mais les entreprises et le reste du monde ne peuvent pas être reprochés pour ne pas vouloir toucher Drizzle sauf qu’avec une perche de dix pieds […] Nous sommes sceptiques quant à jusqu’où Drizzle va arriver. Il est vrai que la diffusion des médias sociaux et les sites web mashup préconisent la diffusion d’une culture de partage des données et de [certains] renseignements personnels. Mais le fait que Drizzle stocke des portions de fichiers sur l’ensemble des ordinateurs de ses utilisateurs, peu importe de quelle manière elles seront encryptées, sera probablement un facteur négatif trop important pour la majorité des utilisateurs potentiels. »

103Au-delà des « pionniers » digital-literate de la première heure, qui auraient l’envie et le temps de rentrer dans les détails de l’encryptage et de la fragmentation, le partage et la mise en commun des ressources risquent donc d’avoir un effet boomerang : non seulement parce que un utilisateur aurait l’impression d’avoir ses propres données reparties « de façon aléatoire » sur les machines d’autres utilisateurs, mais aussi parce que ce même utilisateur verrait s’accumuler sur sa propre machine des données de provenance incertaine, et le concept de sécurité offert par Drizzle ne suffirait pas à compenser cette situation d’incertitude.

« Légalité » entre fragments hébergés et surveillance collaborative

104La question – l’hébergement de données crées par d’autres utilisateurs sur son propre ordinateur – se trouve bientôt débattue en termes de « légalité » de ces contenus, et en conséquence, de celle de l’outil qui permet de les stocker et de les partager – ainsi que de la possible responsabilité de ses utilisateurs en cas de violations du droit. À l’automne 2007, le moment où Drizzle démarre en closed alpha, les débats au croisement des questions de propriété intellectuelle, de confidentialité des données personnelles et de partage de fichiers au moyen de réseaux P2P sont particulièrement animés en Europe : un tribunal allemand vient de refuser la demande de certains groupes de l’industrie musicale, que les FAI identifient les comptes suspects d’être utilisés pour violation du copyright par le partage de fichiers en P2P ; la Société civile des producteurs de phonogrammes en France (SCPP) assigne trois éditeurs de logiciels P2P en justice pour ne pas avoir entrepris les actions nécessaires à empêcher les utilisateurs d’accéder à des contenus illégaux ; un avocat-général de la Cour européenne de justice prend officiellement position dans le cas controversé Promusicae vs. Telefónica de España sur la divulgation d’informations de trafic à des fins de poursuite de violations de la propriété intellectuelle.

105Malgré l’étiquette novatrice mais « brûlante » de stockage en « P2P social » qui accompagne Drizzle, de leur côté, les développeurs – fidèles à leur principe de « priorité à la technologie » – ont tout d’abord rapidement écarté le problème avec l’introduction d’une lapidaire FAQ dans le site Drizzle « Ce service est-il légal ? », « Oui, Drizzle est légal. », réponse qui se révèlera bientôt insuffisante pour plusieurs utilisateurs, se demandant et demandant donc à en savoir plus sur le positionnement du dispositif par rapport aux questions juridiques problématiques autour du P2P. Qu’est-ce que fait et de quoi est faite la « légalité » de Drizzle ?

106Ce sont, une fois de plus, les utilisateurs les plus « intéressés » qui influencent le projet et contribuent à le transformer – une histoire qui peut être démêlée et racontée grâce aux « posts » et aux discussions sur le forum Drizzle. Un utilisateur souligne que les fonctionnalités mêmes de Drizzle qui fournissent confidentialité et sécurité – l’encryptage des contenus en tout premier lieu – en font un système de P2P privé qui, comme nombre de darknet [Wood, 2010], faciliterait la prolifération d’activités d’échange illégales. De façon intéressante, d’après cet utilisateur, la question n’est pas tellement que cette multiplication de partages illégaux ait effectivement lieu – mais que au vu de ses caractéristiques, le dispositif puisse être interdit à la suite d’éventuelles décisions juridiques restrictives concernant d’autres outils P2P, notamment de partage de fichiers :

« Il y a aussi la question de savoir comment les gens vont utiliser Drizzle – après tout, le service fournit un stockage quasi illimité et fortement encrypté. Comme Drizzle a peu de contrôle sur ce qui est partagé sur le réseau, celui-ci pourrait se révéler être un refuge pour des activités plutôt louches. »

107Un contributeur d’outre-Atlantique remarque que la définition de la légalité du dispositif pourrait, du point de vue de l’utilisateur, se baser sur le fait que, de facto, aucun fichier n’est stocké dans sa totalité sur la machine d’aucun utilisateur. Cela pourrait suffire à garantir que celui-ci ne stocke pas du matériel illégal, à la différence d’autres applications pour lesquelles l’ouverture au partage est en soi une indication qu’on possède le fichier dans sa totalité. L’utilisateur pose par ailleurs la question du contrôle sur sa machine et explique que, indépendamment de ses propres activités, permettre le troc signifie « accepter volontairement de renoncer à une partie de ce contrôle, et accepter ses éventuelles implications légales. »

108L’enjeu au centre de cette question de la « légalité » est par ailleurs réaffirmé lors d’une discussion sur le forum utilisateurs du principal concurrent « centralisé » de Drizzle, Dropbox : la responsabilité de ce qui circule dans le système peut être moins aisément et moins directement attribuée au fournisseur de service, puisque celui-ci s’est lui-même mis dans la position d’en savoir le moins possible sur ces contenus – jusqu’à ne pas posséder les moyens techniques de les monitorer. Mais est-ce que les utilisateurs peuvent, pour autant, être tenus pour responsables ?

109La discussion s’engage sur certains cas récemment surgis aux États-Unis qui semblent suggérer cette possibilité, conduisant au décryptage « forcé » des données et à la responsabilité subséquente au « simple » stockage de contenus, indépendamment du fait qu’ils soient cryptés ou non, et que les utilisateurs sachent ou pas ce qui est effectivement stocké. Pour certains d’entre eux, une telle éventualité semble être une condition suffisante à se retirer du système :

« Avec Drizzle, vos données sont encryptées, coupées en morceaux, et stockés non seulement sur des centres de données contrôlés par Drizzle, mais aussi par les ordinateurs des utilisateurs. Cette dernière partie […] crée […] un véritable problème juridique. […] La raison a trait à l’acceptation, le stockage et la transmission de contenus illégaux […] Bien que les données soient cryptées et vous ne pouviez en stocker que des morceaux, si le fichier en question est jugée illégal et vous êtes identifié comme ayant le fichier, vous pouvez légalement être en difficulté. »
« Comme les utilisateurs ne stockent que des morceaux aléatoires et disparates de données cryptées sans en connaître la clé de déchiffrement, comment l’utilisateur pourrait-il en aucun cas être tenu pour responsable si les données s’avèrent être illégales ? En outre, puisque les données sont aléatoires, si leur interception était possible et l’utilisateur final pouvait déchiffrer les blocs, ils ne seraient même pas en train de rassembler un fichier complet. »
« Le vrai problème est que l’aspect de stockage social des fichiers, même encryptés, peut être potentiellement brisé. Bien sûr, il n’y a que des bribes de fichiers, mais tout ce qu’il faut, c’est la bonne personne avec le bon ensemble de fragments pour être en mesure de déterminer ce que le fichier peut en réalité contenir. Cela peut créer un problème juridique, même s’il n’existe pas encore dans ces termes. Cela devient encore plus vrai aux États-Unis, où vous avez des cas […] sur le cryptage, les aspects juridiques de forcer quelqu’un à décrypter des données (en supprimant le déni plausible), et si oui ou non le simple stockage de ces données, même encryptées, peut se qualifier en tant qu’implication (dans un crime). Ce sont toutes des préoccupations réelles que, pour ma part, j’hésite à liquider. »

110De leur côté, les développeurs de Drizzle sont conscients qu’un positionnement « officiel » de leur part est nécessaire par rapport aux questions qui entourent l’« étiquette P2P » de Drizzle, et aux inconnues juridiques posées par le système de troc et la mise en commun des ressources. En particulier, il s’agit pour eux de clarifier si et comment les caractéristiques de leur système se rapprochent des dynamiques qui posent problème dans le cas de systèmes classiques de partage de fichiers en P2P. La réponse qu’ils proposent à la communauté d’utilisateurs comporte deux volets, l’un centré sur l’utilisateur et sa machine, l’autre concernant le réseau dans son ensemble, et le rôle de l’entreprise dans la préservation et la maintenance de celui-ci.

111Premièrement, il est question de la nature des contenus stockés, et de la possibilité d’accès à ces contenus de la part d’entités tierces. Comme certains utilisateurs l’avaient déjà évoqué, l’équipe Drizzle se concentre sur la nature éclatée et encryptée des contenus stockés dans le système, qui rend la question « légal/illégal » dépourvue de sens au niveau de la machine de l’utilisateur. Si un utilisateur active le troc de stockage et qu’un fragment de fichier illégal est stocké sur son ordinateur,

« Les fragments individuels sont juste des bits et des octets insignifiants tant que personne ne connait la clé d’encryptage, la procédure de ré-assemblage, et les autres fragments. Les questions à propos des personnes qui ont stocké le fichier sur Drizzle, avec qui le fichier a été partagé et qui ont accédé au fichier sont plus importantes que celles à propos des ordinateurs sur lesquels les fragments individuels d’un fichier illégal ont été stockés. »

112Dans la définition de la légalité de Drizzle, soulignent donc ses développeurs, l’enjeu n’est pas tant la manière dont les ressources partagées par tel ou tel autre ordinateur sont exploitées, de façon automatique, dans les opérations de fragmentation et d’encryptage : les fragments ne sont pas des objets saisissables par le droit dans sa configuration actuelle. L’enjeu réside plutôt dans les opérations de réseautage et partage entre les utilisateurs qui, stockant pour la première fois des contenus dans le système et les échangeant au moyen des clés d’amitié, introduisent ou recomposent la totalité d’un fichier sur leurs machines. Kurt souligne :

« Notre système n’est vraiment pas une question d’anonymat, mais de construire une plate-forme légale […] il pourrait y avoir certaines préoccupations juridiques à venir, c’est sûr, mais ici nous avons exactement le même problème que YouTube. S’il y a un fichier illégal, ou un fichier protège par le droit d’auteur, dans la partie publique de notre système, si quelqu’un nous le signale, nous devons l’enlever. Il existe différentes méthodes pour les utilisateurs de faire le signalement, ils peuvent le signaler directement par e-mail, ils peuvent le marquer comme non convenable au sein du système, et on peut aussi le détecter manuellement, même si cela prend beaucoup de temps ; mais quand il s’agit de fichiers privés […] c’est privé et crypté sur leurs ordinateurs, nous ne pouvons pas voir ces données. Fondamentalement, nous ne voyons pas les fichiers, donc il n’y a rien que nous puissions faire à ce sujet. »

113C’est donc à certains utilisateurs, et non à des entités de surveillance tierces, que la légalité des contenus circulants dans le système est confiée. Ce qui permet – reconnaît Kurt – beaucoup d’abus, comme dans tout système de partage de contenus. Mais cette « surveillance collaborative » entre utilisateurs – plus facilement réalisable dans le cas des fichiers partagés en mode public, et entièrement dépendante de la volonté des utilisateurs dans le cas des fichiers privés – leur semble la seule solution techniquement possible au vu des fonctionnalités relatives à la sécurité et à la privacy du service.

CHANGE LE SERVEUR, CHANGENT LES PAIRS

  • 71 De façon particulièrement éclatante le 28 septembre 2011, quand l’équipe Drizzle annonce, de façon (...)

114Au cours du temps, nombre de modifications ont concerné la présence et le rôle dans le système Drizzle de centres de serveurs appartenant à la firme ; à côté du réseau P2P d’usagers, ces centres de serveurs ont été utilisés tour à tour comme sauvegarde de sécurité ou comme « nœuds stables » afin d’assurer la redondance pendant la phase d’amorçage (c’est-à-dire, jusqu’à ce que le nombre d’usagers adoptant le système ne devienne suffisant pour assurer sa stabilité). Par ailleurs, entre 2007 et 2011, Drizzle réattribue progressivement une importance à la fois symbolique et très « matérielle » à ces centres de serveurs dans l’économie du dispositif71.

115Un des aspects les plus débattus au cours des premières années de vie du dispositif concerne la dépendance plus ou moins importante du système de stockage visà-vis du réseau P2P, et l’importance du recours additionnel à des serveurs. Ces aspects sont largement discutés non seulement au sein de l’équipe, mais avec les usagers – contrairement à d’autres points, pour lesquels l’expression de divergences et leur discussion resteront essentiellement une « affaire interne » à l’équipe de développeurs. Notamment, la (dé)centralisation du dispositif, qui a pu apparaître plus ou moins prononcée aux différents stades de son développement, a fait l’objet de négociations complexes et de choix techniques et économiques vertement discutés au cours des quatre années de vie de Drizzle, jusqu’à se profiler comme la caractéristique dont l’absence pourrait signifier le manque de « potentiel différenciant » de l’entreprise, et même mettre en péril sa survie.

116L’architecture du service Drizzle est pour la première fois expliquée de façon détaillée devant un public (même si très sélectionné comme l’est, certainement, l’audience de Mountain View) lors de la Google Tech Talk, au cours de laquelle Dietrich Poell souligne le rôle central du réseau P2P dans l’organisation technique et économique du dispositif :

« […] Les fragments sont téléchargés dans le réseau P2P, et en plus de cela, certains fragments sont aussi téléchargés dans nos serveurs. Depuis un certain temps, cela a été fait pour démarrer le service, jusqu’à ce que il y aient assez d’utilisateurs dans le réseau P2P. À l’heure actuelle, ce ne serait pas nécessaire, les utilisateurs sont devenus suffisants pour assurer la viabilité du système, mais dans le futur nous pourrions encore le garder juste pour donner une sauvegarde, dans le cas très peu probable que tous les ordinateurs du réseau P2P devaient le quitter en même temps, on serait encore capable de récupérer les fichiers à partir de nos serveurs. »

117Les paroles de Dietrich affirment clairement la « philosophie » de décentralisation sous-tendant Drizzle : le centre, le cœur du système est le réseau P2P. Les serveurs, propriétés de la firme, sont une bouée de sauvetage au cas où le système – encore instable puisque l’ensemble d’utilisateurs et de ressources est en train de prendre forme – serait abandonné par un nombre important d’utilisateurs à un même instant, au point de compromettre son fonctionnement. S’ils auront un rôle dans le futur, les serveurs resteront « peut-être » comme solution de sauvegarde.

118On voit comment, déjà au moment du dévoilement du closed alpha, le degré de décentralisation et de « P2P-isation » du dispositif s’annonce comme l’une des briques les plus importantes sur lesquelles va se fonder le rapport des usagers à Drizzle le dispositif, et Drizzle l’entreprise. Quel rôle pour le serveur ? S’agit-il d’une aide temporaire, en attendant que le système se dote d’assez de nœuds pour assurer sa propre durabilité ? Un « nœud du réseau parmi les autres », juste plus puissant ? Ou encore, une redondance supplémentaire ?

Des nœuds-usagers qui deviendront auto-suffisants…

119Quelques temps après que Dietrich a incité l’audience de la Tech Talk à solliciter une invitation afin d’essayer le closed alpha de Drizzle, quelques réactions commencent à pointer sur les forums, portant sur la faisabilité et la facilité d’usage du « cloud de stockage en P2P ». Si la plupart d’entre elles ont pour objet le mécanisme de troc de l’espace disque pour l’espace en ligne, d’autres réactions concernent les aspects plus spécifiquement liés à l’architecture et à l’infrastructure décentralisée : en quoi le P2P peut-il améliorer la rapidité des téléchargements, augmenter le trafic, ou permettre de ne pas poser de limites à la taille du fichier qu’on veut télécharger :

« J’ai eu l’occasion d’avoir une vitesse d’upload de plus de 900 Ko par seconde et personnellement c’est le maximum que j’aie jamais vu sur un service de stockage de dossier en ligne. »
« Ça a l’air plutôt sympa comme solution. Moi j’avais testé vite fait Skydrive, mais j’avais était dégouté par le fait qu’on était limité en donner par Upload [ sic : le téléchargement vers l’amont] ».

120D’autres encore sont sceptiques quant à l’applicabilité du mécanisme des codes d’effacement au stockage en ligne :

« Le P2P marche généralement assez bien puisque chacun a une copie conforme du fichier [une fois fini de télécharger], ça réduit drastiquement les risques de pertes de données. Par contre tout découper et distribuer, pour du stockage, je suis pas convaincu… »

121Les débats se concentrent majoritairement, comme on peut voir, sur le réseau P2P d’usagers que sous-tend Drizzle. Peut-être à cause de la façon dont Dietrich a présenté le système lors de la Tech Talk, les serveurs Drizzle ne sont presque pas mentionnés par les utilisateurs, qui semblent avoir accepté et saisi leur statut de sauvegarde de sécurité et stabilité [temporaire ?], de « grand nœud » assurant la redondance pendant la phase d’amorçage, jusqu’à ce que le nombre d’usagers adoptant le système ne devienne en lui même suffisant pour assurer sa stabilité.

122En 2010, quelque chose commence à changer dans le vocabulaire utilisé par l’entreprise lorsqu’elle fait référence au modèle technique sous-tendant le dispositif Drizzle. L’équipe présente son travail lors de plusieurs manifestations ; c’est lors de ces événements, qui suivent de près la fusion de Drizzle avec le constructeur français de périphériques de stockage StockFast « pour travailler sur l’avenir du cloud storage » (reporte le site Drizzle), que le réseau d’utilisateurs/ressources sur lequel Drizzle s’appuie commence à être qualifié de « P2P cloud », ou nuage P2P. Ce déplacement lexical amène une partie de la communauté à s’interroger sur ce que la fusion entraîne en termes d’éventuels changements dans la technologie, ce qui amène l’équipe Drizzle à faire un communiqué à l’allure « rassurante » :

« Avec StockFast nous pourrons pleinement réaliser la vision sur laquelle nous nous sommes lancés il y a plus de quatre ans, quand on faisait des recherches sur les fondements de Drizzle […] : la construction d’un nuage de stockage fiable et sécurisée, capable d’intégrer des millions d’appareils dans le monde entier. La fusion avec StockFast nous donne non seulement de nouvelles ressources opérationnelles, mais aussi une abondance de nouvelles idées et visions, qui nous n’aurions pas été en mesure de mettre en œuvre dans une société de logiciels pure. […] Nous allons continuer à faire tous les efforts possibles pour vous écouter comme nous le faisions avant. Vous nous connaissez : nous ne changerons pas cette attitude. »

  • 72 Bien que la définition même de cloud soit actuellement l’objet de vives controverses [une revue sp (...)
  • 73 C’est le cas du « guru du libre » Richard Stallman.

123De façon intéressante, le communiqué se concentre aussi bien sur la valeur ajoutée du partenariat en termes commerciaux, que sur ses implications en termes d’infrastructure et de ressources – tout en réaffirmant le déplacement vers le concept de nuage, qui est en même temps en train d’acquérir un véritable statut de « buzzword » au sein du secteur IT72, mais qui n’est pas la conception de service internet préférée par certains représentants des communautés du logiciel libre et du P2P : ils l’ont déjà qualifiée sans détours de « pire que la stupidité73 ».

… Ou des usagers-ressources, « optimisation » des serveurs ?

124En parallèle, l’importance et le rôle des serveurs d’entreprise dans le modèle semblent avoir été révisés. Une nouvelle version du site Drizzle parue à la mi-2010, en faisant référence à la Google Tech Talk de 2007, signale :

« L’une des différences importantes par rapport à la Tech Talk, quelque peu dépassée, est que nous effectuons maintenant une sauvegarde complète de tous les fichiers – sous forme encryptée – sur nos serveurs. Nous avons mis en place une infrastructure de serveurs robuste, qui garantit que tous les fichiers sont toujours disponibles ».

125Aussi, quand la nouvelle version du site Drizzle rend compte de la raison pour laquelle le dispositif est fiable, le poids des centres de serveurs Drizzle et du nuage/réseau de terminaux utilisateur se voit, une fois de plus, mis en question. La fiabilité du système repose sur la « version complète » stockée sur les serveurs, tandis que le réseau P2P fait figure d’« optimisation ». De surcroît, parmi les clients/usagers de Drizzle figurent pour la première fois des « organisations » plutôt que des individus :

« Nous nous assurons que vos données sont toujours en sécurité. Une sauvegarde complète de vos fichiers encryptés est toujours conservée sur nos serveurs, de sorte qu’ils puissent toujours être accessibles et restaurés. Le nuage Drizzle sert d’optimisation qui nous permet d’exploiter une infrastructure à grande échelle à faible coût et de vous fournir des meilleures prestations. En outre, il permet aux entreprises d’obtenir un accès fiable au stockage en ligne, en fournissant leurs propres ressources au nuage Drizzle. »

126Quelles sont les implications techniques effectives de ce déplacement lexical ? À l’automne 2010, Dietrich fournit une définition de l’architecture Drizzle qui donne beaucoup d’importance à la décentralisation, encore bien présente en tant qu’aspect démarquant du dispositif « dans un marché bondé » :

« Drizzle profite encore de manière significative du réseau de stockage en grille et en P2P. Nous avons décidé de maintenir une sauvegarde complète et redondante sur nos serveurs, mais quand il s’agit de téléchargement, le client Drizzle est programmé pour obtenir autant de fragments possibles de la grille. C’est toujours la façon dont nous réduisons notre bande passante sortante, et aussi nos besoins d’énergie électrique, de façon significative, ce qui fait baisser nos coûts et fait partie intégrante de la façon dont nous cherchons à offrir un meilleur service. »

127En même temps, le manager général de StockFast – avec qui Drizzle a récemment conclu une fusion définie par certains commentateurs comme « acquisition » – exprime son intérêt pour Drizzle de la façon suivante :

« On est en train de mettre en chantier un “réseau Cloud” reposant sur la technologie Drizzle. Elle s’adapte parfaitement à notre désir de construire du stockage en cloud à la fois accessible et sûr par la mobilisation de ressources existantes, car elle fait fonctionner de concert du stockage centralisé et du stockage distribué. […] StockFast apporte des nouveaux marchés pour cette technologie : des entreprises et des utilisateurs professionnels, qui pourront très bientôt tirer avantage des services Drizzle à la fois au sein du cloud et au sein de leur centre de données. Le “ cloud storage” en P2P permet à la fois un échange de données faciles et une flexibilité complète des données. »

128Aux yeux de certains usagers, avec cette stratégie qui semble tenir à la fois du modèle d’affaires de l’entreprise, de ses efforts marketing vis-à-vis de nouveaux publics, et de l’organisation technique du dispositif, Drizzle est en train de se déplacer dans une arène de compromis assez risquée. D’un côté, un modèle prévoyant la présence de serveurs destinés à une « sauvegarde complète » a un intérêt sûr pour les potentiels clients institutionnels ou organisationnels, auxquels les solutions Campus ou Business proposées dès l’automne 2010 sont destinées, et pour lesquels le P2P apparaît peut-être comme une technologie controversée, voir « incertaine ».

129D’un autre côté, au sein de la communauté d’utilisateurs pionniers qui s’étaient initialement intéressés au dispositif au vu de son positionnement dans le marché en tant qu’« alternative » P2P, des questions se posent. L’une d’entre elles, notamment, est beaucoup posée, soulevant toujours la même objection : comment les deux aspects de l’achat de stockage supplémentaire et, surtout, d’une présence des serveurs qui paraît toujours plus imposante, se conjuguent-ils avec la « philosophie de la décentralisation » qui est la pierre angulaire de Drizzle ? L’équipe Drizzle répond bientôt sous forme d’un ajout aux FAQs du site :

« Drizzle est et reste un système de stockage distribué, chaque utilisateur a la capacité de troquer du stockage et de gagner un stockage additionnel proportionnellement à sa contribution au système, sans avoir besoin de payer. Acheter un stockage additionnel est une option pour ces utilisateurs qui ne peuvent ou ne veulent pas troquer, ou qui veulent simplement plus que ce qu’ils peuvent troquer. Par ailleurs, tous les fichiers sont traités de la même manière. Il n’y a pas de différence entre les fichiers des utilisateurs qui utilisent le stockage gratuit, qui troquent du stockage ou ont acheté du stockage. S’il y a plus d’utilisateurs actifs sur Drizzle et s’ils ont plus de stockage, cela est bénéfique à ceux qui troquent, parce que ces derniers peuvent gagner plus de stockage seulement quand les fichiers sont stockés. »

130Cette réponse introduit en effet de nouveaux éléments dans la définition de décentralisation à l’œuvre dans le dispositif Drizzle : celle-ci est pour l’utilisateur un choix et une option afin de profiter de la gratuité tout en conservant ou augmentant son espace de stockage en ligne ; la distribution signifie aussi la neutralité dans le traitement des fichiers, indépendamment de l’option de stockage choisie – et les clients qui choisissent l’approche distribué peuvent tirer profit de l’ensemble de ces options, du fait que celles-ci se traduisent en une plus grande quantité de fichiers présents sur le réseau.

131Les réactions à ce communiqué prolongent la controverse. Pour certains usagers, cela est une indication du fait que la partie de données stockées qui est désormais répartie sur le réseau P2P est en effet mineure, en proportion, de ce qui avait été envisagé dans la phase closed alpha. Impression renforcée par le fait que, comme on l’a vu, le dispositif est distribué, mais il est aussi un logiciel propriétaire – point très important pour la communauté du logiciel libre. L’idée que l’entreprise est maintenant réticente à s’investir pleinement dans la mobilisation des « marges du réseau » en tant que principe fondateur de son infrastructure technique persiste, et pour certains, stabiliser le dispositif d’une façon qui tiendrait à la fois de serveurs gérés de façon centralisée et de plateforme/nuage formée par les utilisateurs serait de facto une forme d’exploitation de ces derniers :

  • 74 Un système de monnaie électronique distribuée.

« Le code source est fermé, et donc je ne sais pas encore très bien comment l’infrastructure est liée à Drizzle la société (si celle-ci disparaissait demain, le réseau existerait-il toujours ?) ».
« Je partage certaines de tes questions. D’après ce que je peux dire, si les serveurs Drizzle tombent en panne, tout le système tombe en panne. Je crois qu’ils détiennent la plupart du stockage et ils sont un peu hésitants à propos de combien ils comptent sur les marges [du réseau]. Espérons que leur priorité maintenant est de rendre le système de stockage le plus solide possible. […] Espérons que leur priorité, après cela, sera de rendre le système aussi indépendant de leurs serveurs que possible ».
« J’aime Drizzle et je veux qu’ils réussissent. Cependant, l’impression que j’ai actuellement de leur architecture, c’est que ça me rappelle beaucoup Mojo Nation74, autour de 2000. En particulier, le détail qui fait qu’ils s’appuient sur ​des serveurs gérés de manière centralisée tout en essayant de profiter des machines des utilisateurs est très familier. »

  • 75 Avant l’annonce de septembre 2011, qui interrompt la fonction de troc.

132C’est ainsi que la plus récente75 intervention sur le blog de l’équipe Drizzle (en la personne de Kurt) sur la question de l’architecture, vise à stabiliser le dispositif en tant qu’hybride entre approches centralisée et décentralisée, dont les frontières se confondent pour un meilleur rendu technique ; un compromis qui aurait été agencé dans le dispositif depuis son démarrage :

« Le plus important est que Drizzle a toujours eu une approche mixte. Notre but est de tirer le meilleur de la technologie peer-to-peer, qui fournit les meilleurs avantages aux utilisateurs, tout en se basant sur des serveurs centraux, qui sont plus efficaces ».

133Le président de StockFast contribue également à stabiliser cette conception de l’architecture et de ses possibilités techniques :

« Alors que d’autres opérateurs de nuages investissent en énormes centres de données, qui consument mégawatts en électricité, pour alimenter leurs serveurs ainsi que les refroidir, Drizzle construit son système de stockage en mobilisant des ressources situées aux “bords” de l’Internet, et notre compétence permet justement de rendre un système de ce genre fiable et sûr, vraiment apte à intégrer des millions d’appareils dans le monde. Cela a de nombreux avantages pour nos utilisateurs, et le résultat est un produit qui réunit l’accès rapide propre du stockage local avec les commodités du stockage en ligne ».

134Cela sera plus tard renforcé par Igor, membre de l’équipe de support utilisateur de Drizzle, comme le montre la réponse qu’il envoie à un membre de la communauté lors d’une demande de clarification sur l’architecture de Drizzle :

« Les données sont enregistrées à la fois sur le réseau des utilisateurs et sur les serveurs Drizzle. Le système P2P permet de télécharger les fichiers très rapidement. Le système est redondant et ne repose essentiellement ni sur l’un ni sur l’autre, ils se renforcent mutuellement ».

135Contrairement à Sladder, le cas de Drizzle nous raconte une histoire de négociations et de compromis entre une architecture centralisée, qui profiterait de la « simplicité » de la concentration et des points de passage obligés, et une architecture distribuée, reposant sur les ressources des usagers. Si l’information stockée sur un pair peut de toute façon être retrouvée ailleurs, sur une machine sous le contrôle direct de l’entreprise, « pour plus de sûreté », le pair est-il encore un égal parmi égaux, ou mieux, l’a-t-il jamais été ? Inversement, si un serveur cesse de se voir attribué un rôle central et incontournable dans le système pour devenir une aide à sa redondance et sa stabilité – aide dotée d’un poids plus ou moins important dans le réseau – est-il encore un serveur ? En cherchant et en négociant la réponse à ces questions, l’équipe Drizzle et ses utilisateurs pionniers discutent du chemin vers une stabilisation du dispositif en tant que point d’équilibre entre deux mondes sociotechniques : hybride depuis le début, mélange de cloud et de P2P depuis le début, vertical et égalitaire depuis le début.

CONCLUSIONS

136Ce chapitre a exploré une approche hybride du P2P, en suivant comment se construit le compromis entre une approche largement dépendante d’une plateforme de serveurs, et une approche d’architecture distribuée et décentralisée, où le fonctionnement du dispositif repose sur la mise à disposition de ressources informatiques de la part des usagers.

137L’architecture P2P devient l’aspect différenciant du dispositif, grâce à un travail sur les « tuyaux » qui reconfigure la sécurité du système, la privacy des données stockées, la vitesse des téléchargements, la rapidité des échanges effectués. Les « fragments encryptés » résultant du traitement des contenus stockés dans Drizzle sont saisis par les développeurs et les utilisateurs, tour à tour, en tant que mécanisme technique qui assure la sécurité des données par rapport non seulement aux utilisateurs non autorisés, mais à la firme elle-même ; ou encore, en tant qu’arène où se joue la controverse entre utilisateurs « méfiants » et « confiants » quant à la capacité du dispositif de maintenir sa promesse de sécurité et de confidentialité. L’articulation des dimensions locale et globale constitue le rôle envisagé de l’utilisateur dans le dispositif Drizzle : « la “localité” et la “centralité” s’échangent en de multiples endroits […] parce que le réseau est agrégateur et qu’en même temps, il est construit sur un compromis » [Akrich, 1989 : 39]. En découle une reformulation du lien entre l’internaute et le fournisseur de service : se dessine un modèle technique où l’encryptage en local d’abord, et la fragmentation après sont proposés par Drizzle comme la preuve que la firme « n’a même pas les moyens techniques » de trahir la confiance des utilisateurs, en rappelant les approches de « privacy par l’architecture » évoqués précédemment. Cette conception de privacy prend forme, tout particulièrement, autour de deux « objets », le mot de passe et la clé d’amitié. En particulier, le mot de passe en vient à constituer une forme de dégagement du fournisseur de service par rapport aux problématiques de sécurité : un détail dont l’importance peut sembler modeste à première vue, mais qui finit par entrainer des changements dans les formes de solidarité technique [Dodier, 1995] qui s’instaurent entre les utilisateurs et fournisseur.

138Le véritable cœur du modèle technique de distribution à l’œuvre dans Drizzle, un mécanisme de troc de son espace disque pour un espace équivalent dans le « nuage » d’utilisateurs, devient aussi le cœur de son modèle socio-économique. De la création d’une double « porte d’entrée » au réseau, mêlant client et démarrage Web, au type de connexion Internet de l’utilisateur comme condition d’utilisation et parfois barrière à l’entrée du système, l’architecture technique fabrique, une fois de plus, des formes de représentation de la demande au sein du service. L’enjeu principal pour le succès du mécanisme de troc semble pourtant être la manière dont les utilisateurs s’en saisissent – leurs réactions au fait de stocker ses données dans un environnement qui est en même temps local et global, concentré et dispersé. Cette question est également à la base des débats sur la « légalité » du dispositif : sa définition prend forme autour de la nature éclatée et encryptée des contenus stockés dans le système, qui rend la question « légal/illégal » dépourvue de sens au niveau de la machine de l’utilisateur, et de la « surveillance collaborative » associée aux opérations de réseautage et partage entre les utilisateurs.

139La (dé)centralisation du dispositif fait également l’objet de négociations complexes et de choix techniques et économiques vertement discutés au cours des quatre années de vie de Drizzle, jusqu’à se profiler comme la caractéristique dont l’absence pourrait signifier le manque de « potentiel différenciant » de l’entreprise, et mettre en péril sa survie elle-même. Au cours du temps, la présence et le rôle dans le système Drizzle de centres de serveurs appartenant à la firme se modifient ; à côté du réseau P2P d’usagers, ces centres de serveurs sont utilisés tour à tour comme sauvegarde de sécurité ou comme « nœuds stables » afin d’assurer la redondance pendant la phase d’amorçage, jusqu’à ce que la firme Drizzle ne leur réattribue progressivement une importance à la fois symbolique et très matérielle dans l’économie du dispositif.

140C’est là que l’on voit les deux cas de Sladder et de Drizzle se différencier le plus, dans la mesure où ce dernier nous raconte une histoire de négociations et de compromis entre une architecture centralisée, qui profiterait de la « simplicité » de la concentration et des points de passage obligés, et une architecture distribuée, reposant sur les ressources de chaque usager. Usager qui s’interroge, à son tour, sur son rôle au sein du dispositif distribué. Egal parmi des égaux, qui va être libéré des points de passage obligés dès que la stabilité du système le permettra ? Contributeur de ressources – « optimisateur », même – pour un système qui reste sous l’autorité d’un groupe de serveurs géré de façon centralisée ? En négociant la réponse à ces questions, l’équipe Drizzle et ses utilisateurs pionniers discutent du chemin vers une stabilisation du dispositif en tant que point d’équilibre entre deux mondes sociotechniques : hybride depuis le début, mélange de cloud et de P2P depuis le début, vertical et égalitaire depuis le début.

141Ce cas est aussi témoin d’un effet intéressant du croisement entre la décentralisation et une dynamique familière aux sociologues de l’innovation : un système décentralisé complique beaucoup la construction autour du service d’un ensemble d’indicateurs, destinés à permettre des ajustements progressifs entre l’offre et la demande. Ceuxci ne peuvent qu’être, à leur tour, rassemblés et mesurés de manière décentralisée, transitoire, temporaire, partielle ; ce sont les développeurs et entrepreneurs, en tout premier lieu, qui ont « des problèmes pour compter », même avant que le sociologue puisse éventuellement se réapproprier de leurs calculs.

142Drizzle constitue, au cours de ses quatre premières années d’existence, une arène d’expérimentation technique à la recherche d’un modèle socio-économique durable pour le stockage distribué. Cette expérimentation a eu lieu à la frontière de la dichotomie client-serveur/pairs, en redéfinissant en même temps la conception et la définition d’un système distribué et décentralisé. Elle travaille au croisement de plusieurs tendances d’organisation et d’appropriation du dispositif – entre centralisation et décentralisation, entre réseaux P2P et réseaux sociaux, entre le local d’un terminal utilisateur et le global du Web. Ce cas fournit une opportunité d’observer comment les marges du réseau, où se déploient l’incertitude technique et l’opportunité socio-économique, ont été mobilisées pour leur richesse de ressources à la fois matérielles et « humaines ». Ressources qui, au-delà de la curieuse appropriation de buzzwords telles que « cloud », ont été saisies par l’entreprise comme la clé pouvant l’aider à trouver sa niche et son succès, au sein d’un secteur à la concurrence farouche. Il est cependant intéressant de noter, trois ans après la conclusion du terrain qui a nourri ce chapitre, que Drizzle a désormais fait le choix de la « recentralisation », suite à la décision de rendre le service rapidement profitable. Et ce en dépit de la réaction des utilisateurs : la désertion en masse, déçus, et le départ d’un service qui était désormais « pareil à tous les autres », tandis que celui-ci commençait à être privilégié par des interlocuteurs business. L’histoire la plus récente de Drizzle pose à nouveau, et avec force, la question des modèles économiques du P2P – une question qui reste sans réponse satisfaisante à ce jour.

Notes

55 Le nom fictif choisi pour l’entreprise signifie « pluie fine » en anglais et souhaite renvoyer aux aspects de fragmentation et distribution des données qui font la spécificité du dispositif.

56 Service permettant à ses utilisateurs de stocker, sauvegarder, consulter et partager des fichiers sur une ou plusieurs machines qu’ils ne contrôlent pas directement, mais connectées à l’Internet.

57 Ce que l’équipe Drizzle souhaite, au contraire, être l’un des points de force du service rendu possible par le réseau P2P.

58 Le système de codage utilisé par Drizzle se reporte aux codes de Reed-Solomon, un code correcteur dont le principe est de suréchantillonner un ensemble de symboles ou données à transmettre dans un système. La redondance que comporte ce suréchantillonnage permet au récepteur des données encodées de les reconstruire, même s’il y a eu des erreurs pendant la transmission.

59 La Google Tech Talk Series est une série de conférences techniques, hébergées par Google dans son site central de Mountain View, en Californie. La plupart d’entre elles sont enregistrées et disponibles au public.

60 Il avait été présenté au Symposium on Reliable Distributed Systems [SRDS] en 2006.

61 Entre autres Apache Commons, Jakarta et Trove.

62 C’est-à-dire que la firme Dropbox possède un certain nombre de serveurs auxquels la totalité des fichiers et des données sauvegardés par les utilisateurs Dropbox sont envoyés.

63 L’expression « No strings attached », qui signifie « sans conditions (déplaisantes) », veut dire littéralement « sans cordes attachées » : en faisant référence au débat médiatique en cours sur les risques que les serveurs « tout-puissants » de Facebook représentent pour la privacy, Dietrich reprend cette formule pour suggérer que le service Drizzle est « sans serveurs attachés », ne dépend pas d’éléments centralisés.

64 On se rappellera les conditions d’utilisation de Drizzle : « L’utilisateur reconnaît que Drizzle peut utiliser le processeur, la bande passante et le disque dur (ou autre support de stockage) de son ordinateur dans le but de stocker, chiffrer, mettre en cache et fournir des données qui ont été stockées dans Drizzle, par l’utilisateur ou tout autre utilisateur. L’utilisateur peut spécifier la mesure dans laquelle les ressources locales sont utilisées dans les paramètres du logiciel client Drizzle. »

65 Le web start de Java (une plateforme permettant d’exécuter des programmes écrits en langage de programmation Java) permet de stocker rapidement une application démarrée depuis le Web sur le disque local de l’utilisateur. Il s’agit donc, pour simplifier, d’une « voie moyenne » entre un client installé en local et une application Web pure.

66 On se rappellera la controverse autour du téléchargement du client P2P dans le cas de Sladder.

67 L’intégration Facebook ne sera pas implémentée par la suite.

68 Ce qui, comme on verra dans la dernière section, sera source de nombreuses controverses quant au statut des utilisateurs et de leurs machines dans le dispositif.

69 Dans cette même perspective de recrutement et d’intéressement, l’offre de base au stade de closed alpha peut aussi être augmentée sans souscrire à l’option de stockage partagé, tout simplement en invitant des amis.

70 Une motivation supplémentaire, qui sera introduite dans la version beta, est la possibilité de gagner du stockage à partir de plusieurs terminaux (par exemple, un fixe, un ordinateur portable et un téléphone portable) qui seraient en ligne à des moments et pour des durées différentes.

71 De façon particulièrement éclatante le 28 septembre 2011, quand l’équipe Drizzle annonce, de façon inattendue pour les utilisateurs que la firme, désormais rachetée par le développeur de matériaux de stockage StockFast, allait interrompre l’implémentation du mécanisme de troc dans l’application – décision qui réduit drastiquement, de facto, la composante collaborative et P2P du système, limitant désormais sa spécificité au système d’encryptage et décryptage en local. Une controverse s’ensuit, illustrée par les discussions enflammées qui ont eu lieu depuis lors dans le forum Drizzle.

72 Bien que la définition même de cloud soit actuellement l’objet de vives controverses [une revue spécialisée a récemment réuni plus de vingt définitions différentes du concept], ce modèle indique généralement que le vendeur fournit l’infrastructure physique et le produit logiciel, abritant ainsi à la fois les applications et les données dans un lieu inconnu de l’utilisateur [le fameux « nuage », cloud en anglais] et interagit avec ce dernier grâce à une interface client. On s’achemine dans ce cas vers un modèle de déportation sur des serveurs distants de traitements informatiques traditionnellement localisés sur le poste utilisateur. Voir aussi [Musiani & Schafer, 2011].

73 C’est le cas du « guru du libre » Richard Stallman.

74 Un système de monnaie électronique distribuée.

75 Avant l’annonce de septembre 2011, qui interrompt la fonction de troc.

Notes de fin

* le User Datagram Protocol [UDP] est l’un des protocoles de télécommunication les plus répandus de l’Internet ; sa fonction est de permettre la transmission de données de manière très simple entre deux entités, chacune définie par une adresse IP et un numéro de port.

© Presses des Mines, 2015

Licence OpenEdition Books

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search