article.md

Les couacs du vote électronique, un tremplin bienvenu pour vous parler de résilience

Au lendemain des élections communales, j'observe la vague verte s'écouler dans les quotidiens, et m'amuse de la voir partager l'actualité avec d'autres titres évoquant les (très attendus, j'y viens!) couacs du vote électronique.

A Bruxelles, quarante-sept bureaux de votes ont ouvert avec deux heures de retard ou plus, cinq n'ont semble-t-il jamais ouvert. A Wavre, au delà des files interminables constatées, c'est le décompte qui a été fortement perturbé par une panne d'électricité.

Je suis un professionnel du secteur informatique, en charge du développement et du monitoring de systèmes informatiques souvent complexes, docteur de l'UCL dans l'équipe d'ingénierie informatique et... ces problèmes ne m'étonnent aucunement. J'irai même plus loin: personne ne les règlera jamais, c'est comme cela. Cela vous étonne? Moi pas.

Comme je suis me récemment intéressé à la notion de résilience dans le cadre d'initiatives de transition, je trouve l'occasion excellente d'exposer pourquoi cela ne m'étonne pas, en construisant un pont entre deux de mes mondes.

La résilience, c'est quoi?

La résilience se définit comme la capacité d'un système à surmonter une altération de son environnement. Dans le cas d'un système informatique, on dit souvent que c'est sa capacité à continuer de fonctionner en cas de panne (définition trop réductrice, j'exposerai les raisons plus loin). Parti d'Angleterre, les réseaux en transition invitent par exemple à réfléchir à notre résilience énergétique: en tant que "système humain", comment surmonter la mise à l'arrêt inattendue de cinq centrales nucléaires? Ou de mobilité: comment surmonter l'incapacité grandissante des routes à soutenir le flux permanent de voitures?

Soulignons que ces questions sont loin d'être les turpitudes de quelques écologistes chevronnés. Poser la question de la résilience est une preuve de sérieux, et l'évacuer une forme de stupidité: les centrales sont à l'arrêt, les routes embouteillées, et le vote électronique pas si super que cela. Nier ces "pannes" du système, ou les évacuer avec des réponses simplistes (c'est la faute de l'agence de sécurité nucléaire ; construisons plus de routes ; c'est un soucis de clefs USB) relève au mieux d'une méconnaissance des systèmes en question, au pire d'un nihilisme exaspérant.

S'il est difficile de s'attaquer au nihilisme, il n'est pas inutile d'améliorer collectivement notre compréhension des systèmes qui nous entourent. Je vous invite donc ici à mieux comprendre la question de la résilience d'un système de vote (électronique).

La résilience des systèmes informatiques

Comme je l'écrivais ci-dessus, la résilience d'un système informatique est souvent présentée comme sa capacité à continuer de fonctionner en cas de panne. Un excellent exemple de système résilient est Internet: il est rare de voir l'ensemble d'Internet "à terre", l'a-t-on même jamais vu? Pourtant à tout instant, il y a nombre de serveurs en panne, de routeurs buggés, de lignes de communication coupées, sans qu'aucune de ces pannes ne puisse mettre l'ensemble du réseau en danger. Vous observez, au pire, une interruption de service momentanée, généralement courte, et très locale.

Si on a conçu Internet résilient, on doit pouvoir faire de même pour le vote électronique, non? Et bien non. C'est-à-dire qu'on ne peut rendre le vote électronique résilient sans violer les objectifs même qu'on cherche à atteindre en l'introduisant: une suppression du papier, une plus grande rapidité du vote, un décomptage plus aisé, voire plus précis, etc. Il s'agit d'un cul de sac, en quelque sorte: soit le système n'est pas résilient et le vote est réellement mis en danger parce qu'il ne peut avoir lieu, soit le système est résilient mais c'est exactement au prix de sa rapidité, son aisance, et sa précision.

La journée d'hier est représentative de cette affirmation: le vote électronique a bientôt trente ans, les votes ont eu lieu mais qui peut soutenir sérieusement que la digitalisation du vote nous a fait gagner du temps, de l'aisance ou de la précision? Dès lors qu'on peut également mettre en doute le fait que le système soit plus démocratique (parce que moins facilement contrôlable par le plus grand nombre) ou moins cher, quels avantages un tel système offre-il qui justifient d'encore le conserver?

Pour comprendre cette réalité frustrante pour les technophiles dont je suis, nous devons faire deux choses. D'une part il nous faut mieux définir les concepts de "système" et de "panne" dont on parle. D'autre part, il faut comprendre que pour qu'un système soit résilient, ses concepteurs doivent admettre les pannes et s'efforcer d'y remédier plutôt que d'en nier ou négliger l'existence. Ce que nous appliquerons donc.

Système et pannes

La première chose à faire pour raisonner sur le système de vote électronique, c'est élargir le champ d'analyse. Trop souvent, nous réduisons le système de vote électronique à des clefs USB, des ordinateurs, des algorithmes de comptage, des urnes électroniques, etc. Dans la réalité, cependant, le système contient également nombre d'humains: les concepteurs et développeurs du système, le président de bureau, le citoyen qui vote, etc. L'ensemble forme le système de vote (électronique), et c'est ce système global qui s'expose aux pannes.

Un tel système technico-humain fonctionne si chacun respecte ses obligations. Dans la méthode KAOS d'analyse de tels systèmes, mise en place à l'UCL, on parle:

• d'exigence sur les composants logiciels. Par exemple, "lorsque le citoyen a indiqué son choix, l'ordinateur doit le sauvegarder de manière fidèle sur la carte de vote".

• d'attente sur les êtres humains. Par exemple, "lors d'une copie de clef USB, l'opérateur introduit la clef originale à gauche de l'appareil de copie, la clef vierge à droite".

• d'hypothèse autrement. Par exemple, "l'électricité est disponible durant l'ensemble d'une copie de carte USB", ou "une carte de vote ne s'altère pas sans intervention extérieure".

L'ensemble de ces exigences, attentes et hypothèses permet au système de fonctionner comme attendu... quand tout se passe bien, c'est-à-dire quand chacun respecte ses obligations. Les "pannes" sont quant à elles autant de négations des exigences, attentes, et hypothèses:

• Un bug informatique mène à une violation d'exigence. Le plus souvent, une telle violation est due à l'incapacité des développeurs à implémenter correctement l'exigence elle-même, ou l'incapacité des analystes à la leur exposer correctement et intelligiblement en premier lieu.

• Un acte de malveillance peut refléter la violation d'une attente. Un opérateur peu scrupuleux inverserait par exemple les clefs USB dans le but même de nuire au système. Ce pourrait d'ailleurs - version moins paranoïaque- être une simple faute d'attention.

• Une panne d'électricité introduit une violation d'hypothèse. Si elle met le système à terre, on pourra sans doute incriminer ses concepteurs: ils n'ont pu imaginer que le monde extérieur n'est pas parfait.

Comme on le voit, la définition de résilience informatique donnée plus haut n'est que trop réductrice: en favorisant le terme de "panne" elle évacue de l'équation toutes les faiblesses de conception, les erreurs d'attention, les mauvaises manipulations, et les hypothèses trop simplistes. Ce faisant, elle suggère qu'il s'agit d'investir suffisamment pour que les éléments logiciels soit parfaits (p.ex. pas de bugs, ni de faille de sécurité) pour avoir un système qui répondra sans faille, ce qui n'est bien sûr pas le cas.

Vous comprendrez dès lors qu'il nous faut préfèrer la définition plus générale d'"un système qui surmonte une altération de son environnement", précisément parce qu'il insiste sur l'environnement. Plus précisément, si l'on veut focaliser sur un élement du système en particulier, par exemple un composant logiciel, on pourra dire sans se tromper qu'il est robuste s'il surmonte une altération de son environnement (panne d'électricité, erreur des humains, malveillance, etc.).

Comme le système de vote électronique est composé de multiples logiciels (au sein de la machine de vote, de l'urne, du système de comptage, etc.), de multiples matériels, et de multiples humains on atteindra un système résilient si chacun des composant est robuste, c'est-à-dire si chacun d'eux, y compris les humains, est à même de surmonter une alération de son propre environnement, composé des autres composants et de ce qu'il espère d'eux. Nous avons donc du travail...

Atteindre la résilience

Pour rendre un système résilient, il faut avant tout que ses concepteurs acceptent l'idée que les pannes ont lieu - on parlera plus généralement d'obstacle - et qu'ils offrent à chacun d'eux une résolution adéquate. Il existe deux grandes stratégies complémentaires pour ce faire: l'étude systématique, et la simplification en amont.

Soulignons, en passant, qu'il est rare aujourd'hui de rencontrer des concepteurs et/ou des développeurs, qui ont été correctement formés à cette première étape de réflexion pourtant simple. L'attrait pour la partie plus technique du métier (on focalise sur la machine et le logiciel, moins sur son utilisation dans le monde réel, donc moins sur son environnement) explique en partie cette réalité.

Etude d'obstacles systématique

La première technique consiste donc à étudier exigences, attentes et hypothèses de manière systématique, à imaginer les raisons pour lesquelles elles pourraient être violées, puis à affiner le système - et souvent augmenter sa complexité en passant - soit pour qu'il prête moins le flanc à l'obstacle, soit qu'il se relève avec panache si cet obstacle devait avoir lieu.

Ainsi on pourrait souhaiter rendre la copie de clef USB moins exposée aux risques d'erreurs. Pour ce faire, commençons par imaginer toutes les situations dans lesquelles l'opérateur n'introduit pas correctement les clefs, puis répondons-y adéquatement:

• Obstacle: l'opérateur est malveillant. Résolution: exiger un certificat de bonnes vies et moeurs ou un screening des candidats. Nouvel obstacle: est-ce raisonnable, ou simplement efficace?

• Obstacle: est-il inattentif et/ou pourrait-il être distrait lors de la procédure? Résolution: peut-être devrait-on prévoir la présence de deux opérateurs lors des opérations sensibles.

On peut décider de focaliser plutôt sur le logiciel, pour qu'il se relève avec panache d'une erreur humaine:

• Obstacle: l'opérateur n'introduit pas les clefs correctement. Résolution: le logiciel doit détecter la situation et informer l'opérateur pour qu'il échange les clefs.

Cette stratégie d'analyse est extrêmement efficace, relativement facile à mettre en oeuvre avec de bons avocats du diable, et offre de bons résultats quand elle est appliquée de manière plus guidée que la simple discussion ici. Soulignons néanmoins ses limites: elle n'a généralement pas de fin, peut se révéler coûteuse puisqu'il s'agit d'exposer toutes les faiblesses des humains comme des appareils et des logiciels, et est souvent limitée par l'imagination des analystes et leur expérience.

Pour illustrer ce processus sans fin, poursuivons notre exemple. Prenons l'exigence sur le logiciel d'"avoir tôt ou tard copié le contenu de la clef originale sur la clef vierge dès lors que les clefs USB sont correctement introduites" et imaginons à nouveau:

• Obstacle: une panne d'électricité interrompt le processus. Résolution: l'opérateur recommence la copie plus tard.

• Obstacle: la clef originale a malheureusement été altérée par la panne. Résolution: garantir des clefs originales inaltérables. Commentaire: Bonne chance.

• Résolution alternative: on attend de l'opérateur qu'en cas de panne, il jette la clef originale et reparte d'une autre. Obstacle: Le technicien n'a pas lu la procédure, ou trouve que c'est une perte de temps. Commentaire: Ha.

• Résolution alternative: exigeons du logiciel qu'il vérifie le contenu des clefs après copie, et attendons des opérateurs qu'ils ne conservent que les clefs correctes sur base d'un voyant rouge/vert ajouté à la machine. Obstacle: les opérateurs se trompent ou sont distraits.

Ne haussez pas les épaules, n'évacuez pas la question trop vite ou je vous traite de nihiliste. La discussion ici peut donner l'impression que la responsabilité de résilience système repose sur nos seules épaules de concepteurs, analystes, développeurs et opérateurs. Mais vous faites partie du système également. Quand vous êtes dans l'isoloir, le système attend de vous que vous fassiez votre vote, sans vous tromper, sans être de mauvaise volonté, ni franchement malveillant. Toutes et tous, et sans aide extérieure. Notre rôle est de vous donner le droit de vous tromper, voire d'essayer de tricher, sans mettre l'ensemble du système à mal. Et sans jamais nous tromper, nous? Honnêtement la tâche est ardue, intéressante, mais ardue.

La simplicité, une stratégie alternative

J'ai indiqué qu'il existait deux stratégies pour rendre un système résilient. La première est exposée, je regrette le fait qu'elle ne soit pas (plus) correctement enseignée, même à l'UCL (en passant).

La seconde est bien connue théoriquement, et c'est Albert Einstein qui nous l'enseigne. Avec mes mots: vous souhaitez éviter les pannes? simplifiez.

A ce stade, je dois des excuses à mes étudiants de 2006. Cette année là, nous avions choisi un système de vote électronique comme sujet pour le projet d'ingénierie logicielle. Dans un tel projet, nous demandions aux étudiants d'appliquer les techniques d'analyse KAOS d'abord au vote papier puis au vote électronique. Nous avons ri, beaucoup ri entre assistants, car les analyses de "pannes" du système papier mettaient en scène des isoloirs qui tombaient, des rideaux arrachés, des présidents de bureau vomissant sur les urnes, des citoyens mangeurs de crayons, ...

Un assistant d'université manque de maturité, puisque nous n'y avons pas vu, à l'époque, une indication que le système papier est en fait extrêmement résilient: pour le mettre à mal il faut faire preuve d'une grande imagination (dans un pays démocratique en tout cas). Nous n'avons pas statué en équipe à l'époque sur la résilience du vote électronique, ni même sur notre vision politique de la chose. Je sais juste que nous n'avons plus jamais choisi cette étude de cas durant les nombreuses années où ce projet à encore eu lieu.

Cet anecdote nous enseigne quelque chose. La résilience n'est pas quelque chose d'absolu (le système est résilient ou non résilient). Il faut plutôt la voir comme un outil de raisonnement pour comparer deux systèmes, et leurs pannes potentielles. Nous ne faisions pas autre chose dans la section précédente: partant d'un système, nous en imaginons les pannes et les résolutions qui mènent à un nouveau système, qu'on espère plus résilient aux obstacles que le premier.

A l'étude, le système de vote électronique n'est réellement résilient que lorsqu'à la panne "et donc, ça ne marche pas", on introduit soit la résolution "on sort donc les papiers et les crayons", que le système lui-même cherchait à remplacer, soit la résolution "on fait attendre les gens, que veux-tu?". C'est-à-dire qu'on ne peut rendre le vote électronique résilient sans violer les objectifs même qu'on cherche à atteindre en l'introduisant: une suppression du papier, une plus grande rapidité du vote, un décomptage plus aisé, voire plus précis, etc.

Conclusion

Vous voilà initié.e à l'étude de la résilience des systèmes. C'est donc votre tour. Du vote papier ou du vote électronique, quel système vous semble le plus résilient? Lequel offre le moins le flan aux obstacles, et lequel se relève avec panache quand ils adviennent?

A l'heure où le secteur IT cherche des idées disruptives, des startups innovantes qui vont révolutionner notre monde et changer nos habitudes, c'est aussi des questions comme celle-là qu'il s'agit de poser. Et ce faisant, il faut faire l'exercice de revenir aux objectifs des systèmes étudiés, et reposer les questions essentielles: quel est le but premier d'un système de vote, d'un système de transport, d'un hôtel, d'un restaurant?

Sur la question de la résilience du système de vote, j'observe que la variante électronique ne fait qu'ajouter de nouveaux agents (dévelopeurs, logiciels, matériel, électricité, etc) sans en enlever aucun, et ne fait que s'exposer plus aux pannes que le système papier... Comme concepteur et citoyen, je choisis donc le vote papier, parce qu'il est naturellement plus simple, et beaucoup plus résilient.

Comme technophile et chef d'entreprise par contre, le plaisir technologique et l'attrait financier pourraient m'amener à implémenter le second. Je reconnais cependant que l'objectif qui m'amènerait à le faire est assez éloigné du but premier d'un système de vote. Et j'espère personnellement que demain, la démocratie et l'intelligence collective (par exemple dans les groupes en transition dont je fais partie), permettront de voir toujours plus clairs dans ces choix.