Initialisation

màj : 12 oct. 2017
yo

Introduction

L'oeuf ou la poule ?

Nous sommes dans le présent projet confrontés à un paradoxe proche de celui de l'oeuf et de la poule : développer démocratiquement un système de démocratie directe, alors qu'il n'existe pas encore d'outils pour le concevoir et développer démocratiquement. Afin de résoudre ce paradoxe j'applique le principe du meneur de jeu initial et temporaire.

Concrètement, en tant qu'initiateur et concepteur de democratiedirecte.net et tutmondigo.net j'assume de facto la fonction de meneur de jeu, mais tout en oeuvrant au transfert de cette fonction à la communauté le plus rapidement possible. Pour ce faire il faut développer une application de votation en réseau permettant d'exercer collectivement la fonction de meneur de jeu. Mais je n'ai pas les compétences pour le faire seul.

Le but du présent article est d'organiser le développement collectif de cette application de base constituant le noyau applicatif à partir duquel il va être possible de développer collectivement et démocratiquement le système de DD défini au chapitre "Objectif".

  • Rappelons à cet égard qu'il serait très naïf de réduire ce système de DD à un simple logiciel de votation. Dans le chapitre "Méthodologie" nous avons montré à quel point il s'agit bien plus que cela.
  • Il ne faut donc évidemment pas attendre que cette application de base soit développée pour commencer à s'impliquer dans un groupe de travail (pour participer voir l'article "Réalisation"), qu'il s'agissent d'un groupe "blanc" ou "noir" (cf. article "Méthodologie").

Ce noyau applicatif sera géré par le groupe "Logistique", et mis à la disposition des groupes de travail pour leur fonctionnement intra-groupe et inter-groupes (cf. chapitre "Méthodologie"). La section suivante présente ses deux fonctions essentielles.

Noyau applicatif

Le noyau applicatif du système de DD est une application de votation (entendez "de décision collective") en réseau, et composé des deux fonctions fondamentales :

  1. Formulation collective. La formulation de la proposition soumise à votation doit elle-même être réalisée démocratiquement, ce qui implique que :

    • tout utilisateur peut modifier cette formulation (comme s'il s'agissait d'un article de Wikipédia) ;

    • la formulation en cours est soumise à une votation permanente, qui est arrêtée dès que la formulation réuni le suffrage de la majorité des votants (ce qui enclenche la votation proprement dite).

  2. Identification locale. Pour éviter les doubles votes les votations ne peuvent être pratiquées que dans des petites communautés dont tous les membres se connaissent physiquement et sont en outre identifiés individuellement par un validé par la des membres de cette même communauté ().

Cette limitation temporaire de la DD à seulement de petites communautés - en l'occurrence les participants au présent projet - est un passage nécessaire pour réaliser une véritable démocratie, c-à-d applicable même pour des communautés dont les membres ne se connaissent pas tous physiquement. Une problématique fondamentale est donc celle de l'identification des utilisateurs du système de votation.

Identification

Identifications bancales

La plupart des applications de vote/sondage/pétition actuellement disponibles sur Internet sont facilement manipulables par votes multiples car le procédé utilisé pour "identifier" le votant est généralement bancal :

  • par l' : les personnes dont l'abonnement à Internet est de type "adresse dynamique" n'ont qu'à couper puis rallumer la connexion pour obtenir une nouvelle adresse, et donc un droit de vote supplémentaire ... ; il est aussi possible de simuler une série d'adresses IP ;
  • par l'adresse email : en créant un série d'adresses, valides ou invalides ;
  • par : il suffit, via les options du navigateur, de supprimer les témoins ;

Dans chacun de ces cas il n'est pas très compliqué d'écrire un petit programme qui, à partir d'un simple ordinateur portable, va automatiquement voter au nom d'une multitude de "personnes" n'existant pas. Ce type de programme est très difficilement repérable car il peut voter à différents moments définis automatiquement de façon aléatoire, et le faire à partir d'une série d'adresses IP changeant constamment.

Exemple de systèmes de votation avec identification bancale

parliament.uk

Le 25 juin 2016 j'ai pu signer la pétition britannique pour un second référendum Brexit, malgré que je ne suis pas citoyen britannique. L'identification/confirmation se fait par adresse email, et il suffit de cocher une case pour déclarer que l'on est citoyen britannique ! Environ deux heures après mon vote le nombre de signatures avait augmenté de 300.000 (trois cent mille). Le plus grave c'est que le site de pétition en question est un site gouvernemental (!) : petition.parliament.uk/petitions/131215.

g1000.org

En 2011 l'organisation g1000.org (un sous-marin de fédérations patronales belges selon Bert Bultinck, chef du Standaard Week-End, cité dans Le Soir du 05/11/11) a organisé une forme de vote en ligne consistant à "signer" le manifeste de l'association. Pour "signer" il suffisait de mentionner un nom, un code postal et une adresse courriel. Pire, aucune demande de confirmation n'était envoyée à l'adresse courriel, de sorte qu'il suffisait d'inventer des adresses bidons pour voter autant de fois qu'on le souhaite ! Ainsi j'ai signé avec qztgpb@wqmlgt9ey5.com, et le vote a été enregistré.

Solutions possibles

La problématique est ici le contrôle du système d'identification. Il existe deux types de solution :

  • centralisée : (cas de la Belgique, mais pas de la France et d'autres pays) ;
  • décentralisée : .

Le tableau suivant compare ces deux options au niveau de la taille de la communauté, de la technologie d'identification et de validation.

TypeCommunautéIdentificationValidation
centralisé globale
(tout le monde ne se connaît pas)
par carte d'identité électronique ("eID") par un prestataire de service eID
décentralisélocale (tout le monde se connaît) par certificat numérique par signature numérique par une toile de confiance

Commentaires :

  • Global vs local. Un fait très important à retenir de ce tableau est que le système centralisé permet sa globalisation, tandis que le système décentralisé est limité à une utilisation locale.

  • État vs toile de confiance. En fait, dans le système centralisé la validation se fait également via certificats et signatures électroniques. Mais une différence importante est que dans celui-ci l'utilisateur ne doit rien faire pour cela (l'État - qui gère le registre national - se charge de tout), tandis que dans le système décentralisé l'utilisateur doit prendre l'initiative d'acquérir un certificat électronique, et inciter d'autres membres de la communauté à le signer électroniquement (toile de confiance).

  • Échantillon représentatif. En terme de votation les deux systèmes donneront pour une même votation des résultats d'autant plus comparables que la population du système local constituera un échantillon_représentatif de la population globale. Cependant la notion d'échantillon représentatif est controversée.

Les développeurs souhaitant participer à ce travail sont invités à créer le groupe Logistique.

Développement standards

Les développements standards concernent des fonctionnalités :

  • dont on peut se passer lors les premières phases du développement du système de DD ;
  • développées par les groupes standards ;
  • mises à la disposition des groupes de développement (cf. chapitre "Méthodologie").

Les premières de ces fonctions sont la gestion de la confidentialité et de la transparence du système.

Confidentialité

Prenons le cas d'un système d'identification centralisé. Celui-ci ne doit conserver aucune donnée de la carte d'identité. Pour prévenir les doubles votes il suffit de conserver une du numéro de la carte d'identité, rien d'autre. En outre la dans laquelle ces données sont stockées ne doit faire aucun liens entre cette empreinte et les votes (et cela doit être vérifiable en ligne par quiconque).

Autrement dit les seules informations que le système enregistre sont : "le titulaire de la carte d'identité dont l'empreinte du numéro est ... a participé à telle votation". Notez en outre qu'il s'agit du titulaire, et non pas seulement du détenteur de la carte, dès lors que celui-ci doit mentionner le code PIN, au moins pour se connecter la première fois au système de votation - et obtenir d'éventuels codes d'accès (pseudonyme et mot de passe).

Achat de votes. Les codes d'accès évoqués ci-dessus présentent l'avantage que le votant peut désormais voter sans utiliser sa carte eID. Cependant cette facilité induit la possibilité d'achat massif de votes. Par conséquent il faut forcer l'utilisation systématique de la carte pour les votes, et limiter la facilité des codes d'accès pour la seule consultation des résultats.

Transparence

Une seconde fonctionnalité indispensable (et dont vous noterez qu'elle est antagoniste avec la précédente ...) est la transparence du système de votation. Tout utilisateur doit notamment pouvoir vérifier librement :

  1. la confidentialité des données : les tables de la base de données relationnelle sont-elles effectivement indépendantes ? ; est-il vrai que le nom des votants n'est pas enregistré ? ; ... ;

  2. que l'intégrité des données : le résultat des votations n'a-t-il pas été modifié (que ce soit frauduleusement ou accidentellement), ....

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *