Vote Compilation

Application directe de Stratide à la compilation citoyenne de résultats de scrutin

Trois mouvements, neuf entités, audit par convergence — un domaine réel à grande échelle

Le projet

Vote Compilation est un projet de compilation citoyenne des résultats d'un scrutin national. Un mouvement citoyen organise la collecte, la validation et la compilation des chiffres remontés par les bureaux de vote, en parallèle du dépouillement officiel. La légitimité du système repose sur trois propriétés qui le distinguent d'un simple agrégateur.

D'abord l'indépendance des sources. Pour chaque bureau de vote, plusieurs observateurs citoyens distincts remontent ce qu'ils voient affiché par le bureau au moment du dépouillement. Aucun observateur n'est seul à témoigner. Aucun n'a la connaissance préalable de ce que les autres remonteront.

Ensuite la convergence comme critère de validation. Un procès-verbal de bureau n'est validé que si plusieurs observations indépendantes concordent sur les chiffres principaux. La convergence remplace la confiance accordée à une seule source. Ce qui n'est pas convergent reste en attente, ou bascule en litige.

Enfin l'auditabilité complète. Chaque observation, chaque validation, chaque compilation est inscrite avec son moment, sa source, sa donnée. Aucune information n'est mutée. Tout est tracé par succession d'inscriptions, ce qui rend le système rétrospectivement auditable sur toute la période de contestabilité.

L'échelle visée est nationale : environ 30 millions d'habitants, 25 000 à 30 000 bureaux de vote, trois à cinq sources par bureau, soit 75 000 à 150 000 observations totales attendues, dont la moitié probablement reçues dans les quatre premières heures suivant la clôture des bureaux.

Trois mouvements distincts

Le projet Vote Compilation porte trois mouvements distincts au sens de Stratide Flux. Chacun est un triangle complet — source, action, destination — matérialisé par un Contract dédié, avec ses propres règles d'admissibilité et ses propres invariants.

Figure 1 — Les trois mouvements de Vote Compilation, chacun matérialisé par un Contract avec sa source, son action et sa destination. Le mouvement de compilation, mis en évidence, est celui qui produit le résultat publié par le mouvement citoyen. Les deux mouvements précédents le préparent : le recueil collecte la matière brute, la validation la consolide par convergence.

Le recueil est l'opération par laquelle une source citoyenne remonte ce qu'elle a observé. C'est l'entrée du système. La source est en bout de chaîne d'agrément du mouvement ; l'observation est attestée par un identifiant stable et un horodatage, joint à une copie des chiffres affichés par le bureau.

La validation est l'opération par laquelle le système, ayant reçu plusieurs observations pour un même bureau, établit qu'elles convergent et publie un PV validé. Le seuil retenu est de trois observations concordantes sur les chiffres principaux. La règle de convergence est portée par le Contract de validation lui-même, donc auditable et modifiable sans changer le code.

La compilation est l'opération par laquelle le système agrège tous les PV validés pour produire le résultat global du scrutin. Elle peut être provisoire (rafraîchie au fur et à mesure que les bureaux se valident) ou finale (quand tous les bureaux ont une issue). Toutes les compilations coexistent dans le store ; aucune n'efface les précédentes.

Trois familles de notions

Le domaine fait apparaître trois familles de notions au sens de Stratide. Chacune désigne une catégorie d'acteurs ou d'objets stables, dont l'identifiant est produit en dehors du système (listes officielles, processus d'agrément du mouvement, ouverture du scrutin) pour éviter les collisions et permettre le rapprochement avec les données externes.

Figure 2 — Les trois familles de notions et leurs trajectoires d'inscription. Chaque notion-source produit autant d'inscriptions que la source remonte d'observations ; chaque notion-bureau a en général une inscription par PV validé pour ce bureau ; la notion-scrutin s'inscrit à chaque compilation. Les identifiants stables sont produits hors du système, ce qui garantit l'unicité et le rapprochement avec les données externes.

La notion-source désigne un observateur citoyen agréé. Identifiant stable issu du processus d'agrément, nom d'usage. Sa trace dans le système — la liste de toutes ses remontées d'observations à travers le scrutin — constitue une donnée d'audit centrale. Si une source produit des observations systématiquement divergentes des autres pour les mêmes bureaux, sa trace permet de l'identifier et d'arbitrer sur sa fiabilité.

La notion-bureau désigne un bureau de vote. Identifiant stable tiré des listes officielles (code du bureau), nom (commune, arrondissement). Sa trace — toute son histoire dans le système, observations comme validations — permet de retracer par bureau ce qui a été remonté, par qui, à quel moment, avec quels chiffres. Cette trace est essentielle pour l'audit rétrospectif en cas de contestation.

La notion-scrutin est unique pour le scrutin courant. Elle désigne le scrutin lui-même comme objet stable. Elle s'inscrit dans le contexte du Project lors de l'ouverture, puis dans le contexte de chaque compilation produite jusqu'à la compilation finale. Toutes les compilations coexistent dans le store ; la trace de la notion-scrutin reconstitue l'évolution du résultat publié au cours du temps.

L'architecture appliquée

Le projet Vote Compilation projette les neuf entités D10 à D18 du noyau Stratide Flux sur ses besoins propres. Aucune entité n'est inventée. Aucune mécanique nouvelle n'est introduite. Le domaine se construit comme application directe.

Figure 3 — Les neuf entités appliquées au domaine Vote Compilation. Le Project du scrutin gouverne l'ensemble. Les Substrats et Providers portent la persistance durable. Les Datasets définissent les schémas typés des trois sortes de données échangées. Les Endpoints et Contracts matérialisent les triangles de chaque mouvement. Les Leases portent les engagements et les Flows leur exécution effective. ContractApi reste hors périmètre pour ce premier scrutin.

Le Project est l'entité centrale. Il représente le scrutin tout entier. Il gouverne toutes les occurrences inscrites pour ce scrutin et porte les paramètres communs : la liste des bureaux attendus, le seuil de convergence, la fenêtre temporelle d'admission des observations, l'identité de la partie responsable. À l'échelle annoncée — plusieurs centaines de milliers d'occurrences — il n'énumère dans ses champs gouvernés que les occurrences structurelles stables (substrats, endpoints, contracts) qui ne changent pas pendant le déroulement. Les Leases et Flows sont retrouvés par filtrage à la demande.

Les Substrats et Providers portent la persistance durable. Le store mémoire seul ne suffit pas pour conserver des centaines de milliers d'occurrences sur la période de contestabilité. Une implémentation persistante du store, avec rejeu au redémarrage, est requise. Pour la résilience, deux substrats coexistent — un primaire et un miroir géographiquement distinct — avec réplication asynchrone. Chacun est un Substrat distinct au sens de Stratide, et le système applicatif décide lequel est canonique au moment de la lecture.

Les Datasets définissent trois schémas distincts et typés. Le schéma observation-pv-v1 pour ce qu'une source remonte, le schéma pv-valide-v1 pour la donnée consolidée d'un bureau après convergence, le schéma resultat-compile-v1 pour l'agrégation finale ou provisoire. Chaque inscription produit un Dataset typé par son schéma.

Les Endpoints sont au nombre de quatre. Trois sont publics : remonter-observation (où les sources agréées déposent leurs observations), consulter-validation (lecture de l'état de validation par bureau), consulter-resultat (lecture du résultat compilé courant). Un est interne : compilation-interne, le sink des Contracts de validation et de compilation.

Figure 4 — Les trois Contracts qui matérialisent les triangles de Vote Compilation. Le premier est public (de remonter-observation vers compilation-interne). Les deux autres sont des mouvements internes du système (de compilation-interne vers lui-même). Chaque Contract porte son payload typé et ses invariants d'admissibilité, vérifiés à l'inscription du Lease correspondant.

Les Contracts matérialisent les trois mouvements. Le Contract remontee-observation relie l'endpoint public à l'endpoint interne, et porte les règles de validation d'une observation : authentification de la source, totaux cohérents, fenêtre temporelle ouverte. Le Contract validation-pv est un mouvement interne : il porte la règle de convergence, avec son seuil paramétrable. Le Contract compilation-resultat est aussi interne et porte la règle de complétude (tous les bureaux traités) et la cohérence des sommes (la somme du compilé égale la somme des PV validés).

Les Leases sont les engagements de mouvement, instanciés à chaque acte concret. Trois sortes selon le Contract sous lequel ils sont inscrits, chacune portant en transit son payload typé : ObservationPv, PvValide ou ResultatCompile. Les Flows matérialisent leur exécution effective. Si une observation est rejetée par un invariant (source non agréée, totaux incohérents, fenêtre fermée), le Flow est inscrit en état Failed avec un diagnostic. Le rejet lui-même est tracé : le système garde mémoire de ce qui a été refusé, pas seulement de ce qui a été accepté.

Le cycle d'une observation

Pour rendre concret le fonctionnement, voici comment se déroule le cycle d'une observation citoyenne, depuis l'instant où une source observe le PV affiché jusqu'à la consultation publique du résultat compilé final.

Figure 5 — Le cycle d'une observation, du dépouillement à la consultation publique. Les étapes 1 à 4 traitent l'observation individuellement ; l'étape 5, mise en évidence, est le moment où la convergence valide un PV ; l'étape 6 met à jour la compilation publiée. Toute consultation publique ultérieure remonte au résultat compilé courant, qui est lui-même résoluble jusqu'aux observations sources qui l'ont produit.

L'intérêt de ce cycle est qu'il n'efface rien. À aucune étape une donnée précédente n'est mutée. Le PV validé inscrit à l'étape 5 ne remplace pas les observations qui l'ont produit — elles cohabitent dans le store et sont retrouvables par la trace. Si une observation arrive après la validation et la contredit, c'est une nouvelle inscription qui s'ajoute, et qui peut déclencher une nouvelle tentative de validation produisant éventuellement un nouveau PV validé avec une nouvelle convergence. Toutes les versions coexistent.

Cette propriété, héritée de Stratide Flux, est ce qui rend le système auditable jusqu'au bout. À tout moment de la période de contestabilité, on peut remonter du résultat compilé courant à toutes les observations qui l'ont produit, voir qui a remonté quoi à quel moment, et reconstruire intégralement le raisonnement de validation. Aucune décision n'est opaque, aucune ne repose sur une donnée disparue.

L'audit par convergence

La convergence est le geste central qui distingue Vote Compilation d'un simple agrégateur de résultats. Elle remplace la confiance accordée à une seule source par une vérification croisée d'observations indépendantes. Voyons comment elle opère concrètement.

Figure 6 — L'audit par convergence sur l'exemple d'un bureau. Trois sources indépendantes remontent les mêmes chiffres ; la convergence est atteinte ; le PV validé est inscrit avec la liste des observations sources qui l'ont produit. Cette inscription rend le raisonnement de validation auditable rétrospectivement : on peut toujours remonter aux observations originelles, et toute observation ultérieure qui contredirait cohabite avec celles qui l'ont précédée.

Le seuil de trois observations concordantes n'est pas un chiffre arbitraire. Il est porté par les extensions du Contract de validation, et est donc auditable et modifiable par nouvelle inscription du Contract sans toucher au code. Si le mouvement décide qu'un seuil de quatre est plus prudent dans certaines zones, il inscrit une nouvelle version du Contract avec le seuil corrigé. La logique applicative s'adapte automatiquement.

La règle de convergence est aujourd'hui posée comme égalité stricte sur les chiffres principaux (voix par option et votants). Une tolérance numérique est prévue dans les extensions du Contract — actuellement à zéro, mais pouvant être assouplie pour absorber de petits écarts sur les chiffres secondaires (blancs, nuls) qui n'affectent pas la sincérité du résultat. Ce choix relève du mouvement, pas de la technique.

L'audit ne se limite pas à la validation. Toute la chaîne reste traçable : on peut remonter du résultat compilé final au PV validé d'un bureau, du PV validé aux observations qui l'ont produit, des observations à leurs sources, et de chaque source à toutes ses autres remontées. Cette navigation par les références typées entre occurrences est ce qui donne sa solidité au système. Aucun chiffre publié n'est orphelin de son histoire.

Posture finale

Vote Compilation est la première application en production de Stratide Flux distribué. Un projet réel, à grande échelle, dont l'enjeu civique est immédiat : compiler et publier les résultats d'un scrutin national pour environ 30 millions d'habitants, en parallèle du dépouillement officiel. Le mouvement citoyen le déploiera et publiera ses résultats. C'est aussi, pour le programme Stratide, la première mise à l'épreuve opérationnelle du runtime distribué à cette échelle.

Plusieurs chantiers techniques doivent être clos avant le jour du scrutin. Ce ne sont pas des questions d'architecture — celle-ci est posée et stable — mais des conditions de robustesse à l'échelle. La persistance durable doit être en place : le store mémoire ne tient pas la période de contestabilité ni le redémarrage. Le filtrage indexé sur les champs de payload doit être effectif : à plusieurs centaines de milliers d'occurrences, un parcours linéaire ne tient pas le pic de charge. Les tests de charge à 50 000 inscriptions sur quatre heures doivent être exécutés réellement, pas estimés. L'authentification des sources doit être éprouvée sur des effectifs réduits avant d'être déployée à grande échelle. Ces chantiers sont chiffrés et tenables ; ils sont la condition pour que la mise en production soit aussi solide que la portée du projet le mérite.

Plusieurs décisions doivent être arrêtées avec les acteurs avant le déploiement : le mécanisme exact d'authentification des sources, le backend de persistance retenu, la politique appliquée aux bureaux dont les observations divergent durablement, l'identifiant officiel du scrutin. Ces décisions sont politiques ou infrastructurelles, pas architecturales. Elles n'affectent pas la cohérence du modèle qui vient d'être posé, mais elles doivent être tranchées et inscrites dans le Project du scrutin avant l'ouverture des remontées.

Au-delà du scrutin couvert, le projet anticipe par construction les caps suivants. Le format des OccurrenceId est déjà préfixé par l'identifiant d'instance, ce qui permettra une éventuelle fédération inter-instances sans rupture. Les Contracts sont versionnés dès le départ. La sérialisation des payloads passe par des schémas neutres, ce qui ouvre la voie à des implémentations dans d'autres langages que Rust pour les clients mobiles. Les politiques d'isolation par Project, posées dès maintenant, rendraient triviale la cohabitation de plusieurs scrutins ou de plusieurs applications sur la même instance. Aucune de ces anticipations ne coûte au cap actuel ; toutes évitent des ruptures qu'une migration future imposerait sinon.

Le projet sera tracé et ses retours d'usage publiés. Ils constitueront la base empirique sur laquelle s'appuiera la décision d'ouvrir le cap multi-nœuds, puis le cap fédération. Vote Compilation sert le mouvement citoyen pour son scrutin ; et il sert, par ses mesures et ses observations, le programme Stratide pour ses paliers suivants.