Il était encore question du vote électronique il y a peu dans la presse. C’est l’occasion de revenir sur le lien entre ce dossier et les bonnes pratiques de développement informatique, sur lesquelles le CETIC est actif.
Lors des nombreuses discussions, on revient finalement peu au fond du problème : pourquoi recourir au numérique quand il s’agit du vote. Il semble que la demande principale concerne la facilité et rapidité du dépouillement, qui est un processus long, fastidieux, où même l’humain peut commettre des erreurs... et où certaines manipulations restent possibles.
D’autre part, le vote doit bénéficier d’une série de caractéristiques que la mise en œuvre numérique doit respecter. On doit s’assurer, par exemple, que
L’informatisation est très certainement possible, mais diffère néanmoins des solutions informatiques habituelles qui sont plus souvent confrontées à des demandes d’augmentation de l’efficacité que de transparence.
On constate également beaucoup de confusion dans ce processus d’informatisation. En parlant de vote électronique, on se focalise souvent sur l’interface utilisateur (vote électronique = écran tactile représentant le bulletin de vote). Or ceci est plutôt une conséquence d’un choix du concepteur du système. Celui-ci cherche plutôt à collecter les votes sous un format qui se prête au traitement informatique, et qui sera stocké sur un disque, clé USB, carte à puce, bande magnétique, ticket,…
Il est assez surprenant qu’à ce stade, plusieurs systèmes laissent déjà tomber une caractéristique essentielle du vote : le citoyen n’est pas en mesure de vérifier que le bulletin qui sera dépouillé porte bien son choix.
Une analyse des besoins structurée devrait être réalisée. Il existe diverses méthodes, l’analyse orientée but en est une. Les résultats de ce type de processus devraient être publics.
L’affaire qui nous occupe a été révélée par un bug informatique dont l’impact était très visible. Celui-ci a finalement été bien décrit. En résumé, un changement de liste en cours de vote provoquait une erreur dans l’enregistrement du vote.
Tout d’abord, en terme de transition avec la section ci-dessus, on notera que les spécifications du processus de vote, résultant de l’analyse des besoins devraient être également publiées. Avec un vote papier : changer de liste, après un premier vote, demande de changer de bulletin, et d’avoir une procédure d’élimination du bulletin erroné. Avec un vote électronique, il faut définir précisément ce qui doit pouvoir être réalisé.
Ensuite, le résultat doit être testé exhaustivement envers ces cas d’utilisation. On peut également souhaiter que le citoyen puisse participer aux tests. On est évidemment sensible à la possibilité que des bugs informatiques puissent permettre à l’utilisateur de découvrir et exploiter des failles qui permettent de réaliser des opérations qui soient contraires à ce que le vote prévoit, mais ceci doit être évité par le test et non par le secret en ne permettant pas de tester longuement les machines.
Entre ces deux étapes, un point important est à prendre en compte : le code source. On peut envisager ou pas que le code source soit révélé au public. Cela aurait des conséquences sur l’écosystème économique des fournisseurs de solutions de vote électronique. Dans tous les cas, une analyse du code par des outils appropriés est fortement souhaitable et permet d’en savoir plus sur les bonnes pratiques qui ont été suivies pour élaborer le logiciel de vote. Cela permet de cerner également des situations problématiques au cœur du code. Des outils plus avancés peuvent vérifier directement que le code garantit les propriétés demandées.
Il ne s’agit pas de pointer du doigt les développeurs, qui souhaitent livrer le logiciel le meilleur possible, mais de s’assurer que le code puisse être relu par des tiers, et de s’assurer que les développeurs aient pu travailler dans de bonnes conditions organisationnelles et techniques.
Il est finalement assez simple de produire un logiciel qui permette de voter et compter des votes, mais les conditions de transparence et de robustesse sont quant à elles de nature à complexifier et contraindre très fortement la solution à mettre en place, sachant que les moyens de fausser les résultats en informatique sont extrêmement variés et potentiellement sophistiqués. Ces conditions ne semblent pas avoir été considérées à ce jour, mais peut-on laisser ce point au hasard pour une fonction aussi critique que le vote ?
Cette note n’a pas l’ambition d’être une analyse rigoureuse et complète, mais lève le coin sur certains éléments qui manquent à la discussion d’un point de vue informatique. Sachant que des discussions sont toujours en cours à ce sujet.
On notera dans ce cadre :
Il serait souhaitable de garder un meilleur lien entre le besoin initial et la mise en œuvre : un vote qui réponde aux attentes de la démocratie, et un dépouillement rapide par une machine, qui soit facilement vérifiable par un humain.
Pour finir, et pour prendre un peu le contrepied de cet article, il est important de réaliser que la contribution peut aussi se faire dans l’autre sens. Les capacités jusqu’à présent inenvisageables dans le cadre du vote « papier » sont aujourd’hui possibles. Il est par exemple techniquement possible de stocker exhaustivement le résultat d’une élection et de naviguer à travers des millions de bulletins de vote anonymes.
En toute généralité, la situation exposée dans cet article se rencontre dans d’autres solutions informatiques, peut-être moins sensibles, mais où l’informatique apporte des contraintes « parasites » au fonctionnement normal souhaité.