Primaire sociale-démocrate : la panne du vote en ligne e-votez

Samedi 10 octobre 2026

Julien Béranger

En bref

Le premier tour de la primaire a été perturbé dès son ouverture par une saturation de la plateforme de vote, que les organisateurs attribuent à une attaque par déni de service.
Les votes enregistrés ne seraient pas compromis, mais le scrutin a dû être prolongé d'une journée.
Le prestataire, e-votez, utilise un logiciel propriétaire très probablement développé avec WEBDEV, hébergé chez OVHcloud.
Son protocole est publié, pas son code. Le bulletin est chiffré côté serveur : le secret du vote repose sur la confiance dans l'opérateur et dans l'audit, pas sur une garantie cryptographique vérifiable par l'électeur.
État des informations : samedi 10 octobre 2026 en fin d'après-midi, alors que le vote est encore ouvert.

Ce qui s'est passé

La primaire de la gauche socialiste et démocratique est organisée par le Parti socialiste, Place publique et la Gauche républicaine et socialiste. Cinq candidats sont en lice : Olivier Faure, Raphaël Glucksmann, Jérôme Guedj, Emmanuel Maurel et Ségolène Royal. Le vote est uniquement électronique, y compris dans les points de vote physiques, équipés de tablettes.

Moment	Événement
Lundi 5 octobre	Clôture des inscriptions : 140 282 électeurs
Vendredi 9 octobre, 8 h	Ouverture du scrutin, saturation immédiate de la plateforme
Vendredi, vers midi	Communiqué de la commission d'organisation : « vote ralenti mais pas compromis »
Vendredi, 18 h 45	Retour annoncé à un fonctionnement normal
Vendredi, 19 h	Environ 20 000 votants seulement
Vendredi soir	Scrutin prolongé jusqu'au dimanche 11 octobre à 18 h, au lieu du samedi 20 h
Samedi 10 octobre	Plus de 71 000 votants, soit plus de 50 % de participation

Selon la commission présidée par Patrick Mennucci, des robots ont porté à son maximum le nombre de connexions simultanées, ce qui correspond à une attaque par déni de service. Les électeurs refoulés voyaient une page « Connexion maximum » indiquant que le nombre de connexions autorisées « par le Webmaster » était atteint.

Les trois partis ont saisi la justice et l'ANSSI a été saisie.

Réserve. La thèse de l'attaque vient des organisateurs et du prestataire. Aucune confirmation technique indépendante ni attribution n'a été publiée à ce stade. Un plafond de sessions trop bas face à l'affluence de l'ouverture produirait le même écran.

L'infrastructure

Prestataire. e-votez, éditeur français fondé en 2005, spécialisé dans les élections professionnelles (CSE), les assemblées générales et les référendums d'entreprise. Il revendique plus de 50 000 dépouillements.
Hébergement. Serveurs dédiés chez OVHcloud, dans deux centres de données redondants à Roubaix et Strasbourg, d'après le protocole de vote publié par e-votez.
Pile logicielle. Très probablement WEBDEV de PC SOFT, avec le langage WLangage. Deux indices concordants : le message d'erreur correspond au réglage « nombre maximum de connexions pour un site » du serveur d'application WEBDEV, et l'offre d'emploi d'ingénieur R&D d'e-votez mentionne la connaissance de WINDEV et WEBDEV comme appréciée. e-votez ne l'affirme pas explicitement.
Code source. Aucun dépôt public. Le code est montré à un expert agréé près la Cour d'appel de Paris, pas au public.

Comment fonctionne e-votez

D'après le protocole de vote (version 1.0, mai 2026), publié en application de la recommandation de la CNIL du 19 mars 2026 :

Préparation. Le bureau électoral teste le système, plusieurs de ses membres génèrent chacun une clé de dépouillement, puis le système est scellé par des empreintes SHA-256 de ses composants.
Authentification. L'électeur se connecte en HTTPS avec un identifiant et un code d'accès reçus par courriel.
Vote. Le navigateur ne fait que codifier le choix et l'envoie sous TLS. C'est le serveur qui chiffre ensuite le bulletin avant de le ranger dans l'urne.
Stockage. L'urne, la liste d'émargement et les secrets d'authentification sont dans des bases distinctes, chiffrées en AES-256 avec des clés différentes. L'ordre des bulletins ne peut pas être rapproché de l'horodatage des émargements.
Récépissé. L'électeur reçoit un récépissé lui permettant de vérifier la présence de son bulletin dans l'urne.
Dépouillement. Après la clôture, les membres du bureau présentent leurs clés ; un logiciel distinct déchiffre et compte. Les bulletins sont conservés individuellement, ce qui permet un recomptage.

L'algorithme de chiffrement du bulletin lui-même n'est pas nommé dans le document.

Qui peut savoir qui a voté quoi

Acteur	Peut relier un électeur à son vote ?	Pourquoi
Opérateur du serveur	Pas en fonctionnement normal, mais techniquement possible	Le même serveur authentifie l'électeur puis reçoit son choix en clair avant de le chiffrer. La protection est procédurale : scellement, expertise, alertes au bureau.
Membres du bureau électoral	Non, par conception	Leurs clés ouvrent une urne sans identités. Ils voient qui a voté et les totaux, pas le lien entre les deux.
Électeur lui-même	Ne peut pas vérifier le contenu enregistré	Le chiffrement étant fait par le serveur, il faut croire que le bulletin stocké correspond au clic.

Le modèle de confiance du protocole le dit lui-même : l'expert indépendant et l'hébergeur sont supposés honnêtes. Dans un système à chiffrement dans le navigateur et dépouillement vérifiable, comme Belenios ou Helios, le serveur ne voit jamais un vote lisible.

Coercition et achat de voix

Le récépissé ne prouve pas le choix. Selon le protocole, il ne contient rien qui permette à un tiers de relier l'électeur à son suffrage, et la confirmation est identique quel que soit le vote.
La coercition reste facile par ailleurs. Quelqu'un peut regarder par-dessus l'épaule, exiger une capture vidéo de l'écran, ou récupérer les identifiants envoyés par courriel et voter à la place de l'électeur.
Pas de revote. Le serveur vérifie les émargements déjà réalisés, ce qui implique un seul vote par électeur. Un vote contraint ne peut donc pas être corrigé ensuite.

C'est la faiblesse classique de tout vote à distance, par internet comme par correspondance, et non un défaut propre à e-votez. Le modèle de menace du protocole ne couvre ni la coercition ni l'équipement de l'électeur.

WEBDEV est-il adapté ?

Plutôt non pour un scrutin national de 140 000 électeurs, même si ce n'est pas la cause principale de la panne.

Points faibles

Sessions à état. Un site WEBDEV classique garde un contexte par utilisateur connecté côté serveur. Cela coûte de la mémoire, explique l'existence du plafond de connexions et rend l'épuisement bon marché pour un robot qui ouvre des sessions et les garde.
Environnement d'exécution fermé. L'expert peut auditer le code d'e-votez, pas le serveur d'application propriétaire sur lequel il tourne.
Petit écosystème. Peu de chercheurs en sécurité, peu d'outillage indépendant, vivier de recrutement étroit.
Cryptographie. Les schémas de vote avancés ont des implémentations de référence dans les langages courants, pas en WLangage.

Ce qui nuance

L'outil convient au métier d'origine : des élections professionnelles de quelques centaines ou milliers d'électeurs.
Un déni de service se traite en amont : filtrage du trafic, défi anti-robot, limitation par adresse, salle d'attente. Une pile moderne sans ces protections serait tombée aussi.
Le plafond a tenu son rôle : refuser des sessions plutôt que planter en plein scrutin.
Les faiblesses de fond (chiffrement côté serveur, absence de vérifiabilité du contenu) sont des choix de conception, indépendants du langage.

Le protocole précise être conçu pour des attaquants de niveaux 1 et 2 au sens de la CNIL, avec des mesures complémentaires au cas par cas pour le niveau 3. On ignore quel niveau et quelles mesures ont été retenus pour la primaire.

Recommandations

Deux mesures auraient réduit l'effet de l'incident et le risque de coercition.

Permettre de modifier son vote

Seul le dernier vote compte. Un électeur contraint peut revoter plus tard, seul, ce qui retire presque toute sa valeur à la coercition et à l'achat de voix. C'est le principe retenu en Estonie.

À prévoir : le système doit pouvoir remplacer le bulletin d'un électeur sans jamais révéler lequel est le sien. Cela demande une conception cryptographique spécifique, difficile à greffer sur une urne où bulletins et émargements sont volontairement décorrélés.

Ouvrir le vote pendant environ deux semaines

Une fenêtre longue lisse les pics de connexion et rend un déni de service bien moins rentable : il faudrait le maintenir pendant des jours, et un électeur bloqué revient simplement le lendemain. Combinée au revote, elle laisse aussi le temps de corriger un vote contraint.

À prévoir : les clés du bureau et le scellement doivent rester intègres plus longtemps, la surface d'attaque est exposée plus longtemps, et la campagne se poursuit pendant le vote, ce qui change la dynamique entre candidats.