Interview avec Giancarlo Ruffo (Università di Torino): Sur la gouvernance des architectures décentralisées

• Comment voyez-vous la relation entre gouvernance et contrôle dans les architectures décentralisées?

Il est facile d’imaginer un système de gouvernance qui ne délègue pas le contrôle à une ou plusieurs entités. Internet en est un parfait exemple : si on observe la manière dont Internet a évolué au cours des années, on remarque que de nombreux acteurs ont proposé des protocoles (adoptés au niveau local) qui ont contribué à la construction du réseau. Tout individu peut créer un nouveau réseau (ou un nouveau réseau dans le réseau) qui obéit à certaines règles dictées par un protocole donné, et qui subsiste indépendemment des règles dictées par les autres protocoles. La plupart de ces protocoles imposent leurs propres règles au sein d’architectures spécifiques, mais ne permettent à aucune entité d’exercer un contrôle totalitaire sur ces architectures.

En ce qui concerne les architectures décentralisées, il est donc important de distinguer entre “gouvernance” et “contrôle” car il s’agit de deux notions complètement différentes, bien que souvent interdépendantes. Ainsi, bien que ces architectures soient pllus difficiles à gouverner, elles sont aussi plus difficiles à contrôler. La distinction entre gouvernance et contrôle est d’autant plus pertinente dans le cas des réseaux pair-à-pair dont les protocoles établissent un système d’auto-gouvernance par l’intermédiaire de règles techniques qui opèrent de manière autonome, sans qu’aucun de ces pairs ne soit dépendant ou contrôlé par les autres.

Dans un système centralisé, la distinction s’estompe puisque c’est la même entité qui s’occupe à la fois d’établir les règles de gouvernance et de contrôler la correcte application des règles dans une architecture donnée. Ainsi, bien qu’un système de gouvernance soit relativement facile à établir dans une architecture centralisée, il se fonde souvent sur une structure hiérarchique où une ou plusieurs entités centrales contrôlent le fonctionnement de tout le dispositif et assurent la légitimité des communications. Cela entraîne des repercussions potentiellement négatives sur certains droits fondamentaux comme le droit au respect de la vie privée et à la liberté d’expression.

 

• Quels sont les differents modes de gouvernance qui permettent de faire appliquer des règles (légales ou autres) au sein des architectures distribuées ?

(1) Governance by design : régulation par le code (Code is law)

 

Une façon de réguler les architectures décentralisées est d’incorporer les règles directement au sein de l’architecture technique de réference – sur le modèle des DRM (digital rights management systems).

En effet, Internet est un réseau entièrement décentralisé, qui peut être régulé par une pluralité de mécanismes technologiques. Tout internaute a la possibilité de proposer des règles techniques – qui s’appliquent à un réseau local, ou à l’intérieur d’un système autonome – sans que cela n’empêche les autres acteurs de proposer des règles différentes.

Cela peut se faire au niveau du:

 

• Protocole

La conception du protocole représente l’étape fondamentale pour le développement d’un dispositif ou d’un résau pair-à-pair. Avant même de penser à l’implémentation du réseau, il faut penser au “design” du protocole qui va determiner les principes de base sur lesquels il sera ensuite possible de développer des logiciels ou des interfaces utilisateurs. La plupart des protocoles actuellement utilisés sur Internet ont été conçus et développés dans une approche pair-à-pair par l’intermédiaire des RFC (request for comments) : des documents techniques qui invitaient la communauté d’internautes à fournir des commentaires sur les protocoles proposés, afin de les améliorer au fur et à mesure.

Le protocole est important car il constitue la structure sous-jacente d’une architecture, dont les caractéristiques iront influencer la conception et le développement de nouveaux dispositifs (en termes d’anonymat, de liberté d’expression, etc). Le protocole représente ainsi le “goulot de la bouteille” (bottle neck) de l’architecture dans la mesure où les règles qui définissent un protocole prévalent invariablement sur les règles imposées par les logiciels ou les interfaces. Ainsi, si le protocole permet de faire quelque chose que l’interface ne permet pas, il sera possible de développer des interfaces alternatives qui permettront de bénéficier des fonctionalités ou d’exploiter les défaults du protocole sous-jacent.

Cela s’est produit à plusieurs reprises dans le cas des résaux pair-à-pair :

Par exemple, le protocole SMTP (le protocole traditionnellement utilisé pour envoyer des e-mails) présente plusieurs défauts de conception (dus à un manque de préoccupation à l’époque où le protocole était développé) qui permettent notamment d’envoyer des e-mails provenant de sources inexistantes. Ce problème – qui est relativement facile à résoudre dans une architecture centralisée – ne peut pas être facilement résolu dans le cas d’un protocole décentralisé.

De même, dans le cas de Gnutella (un réseau pair-à pair pour l’échange de fichiers), étant donné que l’interface officielle du résau (LimeWire) ne permettait pas le téléchargement simultané des fichiers (une fonctionnalité cependant permise au niveau du protocole), les utilisateurs du résau ont développé des logiciels plus performants – exerçant ainsi une pression indirecte sur les concepteurs de Gnutella qui ont rapidement incorporé cette fonctionalité en plus dans l’interface officielle.

• Logiciel ou interface

La conception du logiciel ou de l’interface utilisateur est une étape importante qui va déterminer l’utilisabilité d’un système, mais qui va aussi définir les contours de ce qui peut ou ne peut pas être fait sur ce système. Alors que le protocole définit les règles de base d’un réseau (les règles du jeu); des logiciels ou interfaces sont nécessaires afin de permettre aux utilisateurs de bénéficier des fonctionnalités du réseau. Ces interfaces traduisent implémentent une nouvelle couche de règles (logicielles) qui iront étoffer les règles (préliminaire) du protocole afin de fournir des outils plus fonctionnels aux utilisateurs – dans les limites des règles imposées par le protocole sous-jacent.

Pour reprendre l’exemple du protocole SMTP, il est très difficile d’établir un système de filtrage pour limiter le nombre de courriels indésidérables (spam), car il est impossible de contrôler la reception d’un message a priori : tout courriel indésidérable ne pourra être filtré que a posteriori par l’intermédiaire d’un logiciel ou d’une interface qui propose des fonctionalités additionnelles de filtrage non prévues au sein du protocole original.

De même, dans le cas des navigateurs web, bien que Internet Explorer et Google Chrome fonctionnent sur le même protocole (HTML), ces navigateurs fournissent des fonctionnalités différentes aux utilisateurs – qui pourront ainsi sélectionner le navigateur qui réponde le mieux à leurs besoins spécifiques.

La notion de “Governance by design” est donc un principe fondamental pour la gouvernance des architectures décentralisées en ligne, qui présente cependant à la fois des avantages et des désavantages.

Les avantages principaux de cette approche se retrouvent dans la transparence des règles (qui sont accessibles par le code) et l’égalité entre pairs (due à absence d’un pouvoir central fondé sur une structure hiérarchique).

Cependant, il faut faire attention à ce que les “règles techniques” ne soient pas perçues comme un inconvénient par les utilisateurs. Les technologies DRM sont une solution qui a échoué à cause de sa complexité : ces technologies n’ont pas été acceptées par les utilisateurs dans la mesure où elles rendaient leur vie plus compliquée. Il est possible d’établir des règles techniques extremement sophistiquées, mais plus le système est compliqué, plus il sera difficile pour les utilisateurs de l’utiliser.

Les désavantages résident dans le manque de flexibilité dû au fait que les règles – une fois incorporées dans le protocole – ne peuvent plus être changées. Les utilisateurs n’ont pas la possibilité de négocier ; ils sont obligés de respecter les règles du protocole afin de pouvoir interagir avec les autres pairs du réseau. Bien qu’il soit toujours possible de créer de nouveaux protocoles qui seront potentiellement supérieurs au protocole préexistant, les effets de réseaux sont tels qu’ils réduisent la probabilité que ces protocoles soient effectivement adoptés par une majorité d’internautes. Ainsi, les problèmes identifiés dans le cas d’un protocole décentralisé tel que l’SMTP ne peuvent pas être résolus sans créer des incompatibilités importantes avec les utilisateurs du réseau – même si de tels problèmes identifiés dans un système de communication centralisé (e.g. Facebook) auraient été résolu en quelques heures.

Il est aussi important de tenir compte d’un problème intrinsèque à tout système de régulation par la technique : il existe un compromis entre la manière dont les règles sont formalisées (i.e. leur degré de précision) et leur portée d’application. Ainsi, plus grande est la généralité des règles, plus grande sera leur ampleur, mais plus il sera difficile de les interpréter ; alors que plus les règles sont précises et formalisées, plus il sera facile de les interpréter par l’intermédiaire de dispositifs technologiques, mais plus il sera facile de les violer.

Par exemple, dans le cas des discours d’incitation à la haine qui sont interdits par la loi, la généralité de la règle de droit est telle qu’elle lui donne une portée très large, mais qui ne pourra être effectivement interprétée que par l’intermédiaire d’un “juge”. Cette règle sera donc appliquée au cas par cas et interprétée de façon différente selon des circonstances. Cette même règle formalisée en termes extrêmement précis afin de pouvoir être interprétée par un ordinateur (e.g. en rendant certains mots illégaux) aura une portée plus restreinte et sera aussi beaucoup plus susceptible d’être contournée.

(2) Self-governance : Social norms

 

Le concept de “Governance by design” ne doit pas se limiter au protocole, mais aussi aux services offerts par ce protocole. Pour assurer la bonne gouvernance d’un réseau décentralisé, il faut donc accompagner les règles techniques incorporées dans le protocole ou le logiciel avec des règles communautaires qui iront déterminer ce que les utilisateurs ont le droit de faire avec ce logiciel.

Une fois les règles du protocole établies il faut déterminer les règles de la communauté qui se construisent autour de ce dispositif. La communauté doit établir, par exemple, quels sont les comportements acceptables et quels sont les types de contenu appropriés au sein d’un réseau. La plupart de ces règles ne pourront être que partiellement implémentées par la technique. Il est impossible, par exemple, de prévenir les discours d’incitation à la haine uniquement par le biais de dispositifs technologiques. D’autres mécanismes devront donc être adoptés pour s’assurer que ces règles soient respectées par tous les membres de la communautés : l’établissement d’un mécanisme de monitorage (logging), l’introduction d’un garant qui supervise les communications, etc.

Enfin, si l’on accepte le fait que la plupart des règles techniques (protocoles ou logicielles) seront de toute façon contournées, il ne faut pas craindre de demander l’aide de la communauté pour faire appliquer les règles qui ne peuvent pas être correctement implementées par la technique. Avec le développement d’un système de réputation fondé sur le feedback des utilisateurs,  par exemple, la communauté devient ainsi responsable du fait de punir les utilisateurs qui ne respectent pas les règles ou qui se comportent mal sur le réseau.

Ce système n’est toutefois pas entièrement fiable, puisqu’il est toujours possible de tricher (par exemple en utilisant des faux identifiants ou des mécanismes qui permettent de manipuler les données) et qu’il est souvent difficile d’identifier ce genre de tricheries. De la même façon que l’on peut contourner les règles techniques par la technique, il est toujours possible de détourner les règles communautaires en s’appuyant sur certains membres de la communauté ayant des intérêts divergents. Ainsi, avant que les architecture distribuées puissent effectivement s’auto-gouverner, il faut d’abord obtenir une “masse critique” d’utilisateurs avec de bonnes intentions qui iront s’assurer que le système fonctionne correctement.

Pour assurer le fonctionnement et le respect des règles dans un réseau décentralisé, il est important que les règles du réseau soient en accord avec les objectifs des utilisateurs. Dans une société globalisée telle que la société dans laquelle nous vivons, il arrive cependant que certains utilisateurs aient des intérêts radicalement différent. C’est pour cela qu’il est parfois utile d’incorporer des mécanismes qui ameneront les utilisateurs à se comporter de manière appropriée en suivant les règles établies par la communauté en question. En effet, un système bien conçu de récompenses et de sanctions (adapté à la façon dont chaque individu utilise le réseau) peut souvent résoudre des problèmes que la technologie seule ne pourrait pas résoudre. Un système d’incentifs (économiques ou autres) peut ainsi fournir des outils supplémentaires pour faciliter l’auto-régulation de la communauté, en fournissant un feedback positif aux utilisateurs qui se comportent bien et une sanction à ceux qui ne respectent pas les règles du jeu. Ces mécanismes peuvent être incorporés directement au niveau du protocole même – tels que BitTorent qui propose un système de rationalisation des transferts afin de ne permettre aux utilisateurs de télécharger des fichiers que s’ils permettent aux autres de télécharger les leurs – mais aussi au niveau de l’interface, ou de la communauté. C’est le cas, par exemple, de Tripadvisor, qui permet aux utilisateurs de voter pour les meilleurs récensions de voyage, afin d’augmenter la réputation des auteurs qui obtiendront donc une plus grande reconnaissance au sein de la communauté.

---

---