Application pilote
Premier consommateur réel, critères de sélection, sous-paliers 10.a à 10.e
L'application pilote est le premier consommateur réel de StrateFluxDistr. Elle exerce le modèle endpoint → Contract → Lease → Flow dans un périmètre limité et observable, et fournit les retours d'usage qui orienteront la suite du projet.
Critères de sélection
L'application pilote est sélectionnée selon six critères :
- Périmètre fonctionnel limité, observable, mesurable.
- Volume de données modéré, compatible avec un store mémoire ou un snapshot persistant simple.
- Cycle endpoint → Contract → Lease → Flow bien identifiable dans le cas d'usage.
- Au moins deux endpoints applicatifs distincts qui dialoguent à travers un Contract.
- Au moins un Contract avec admissibilité non triviale (fenêtre temporelle, contrainte de taille, ou champ requis).
- Une partie prenante prête à fournir des retours d'usage réels.
Découpage du palier en sous-paliers
Le palier d'application pilote (palier 10 de la feuille de route immédiate) se déploie en cinq sous-paliers :
10.a — Modélisation. Identification des endpoints applicatifs, définition des Contracts, écriture des scénarios d'Inscribe, Resolve, Trace, Field et List dans le contexte du cas d'usage choisi.
10.b — Configuration runtime. Production du fichier TOML de configuration du serveur pour cette application : acteurs, sources autorisées, Contracts sensibles, politique de trace minimale.
10.c — Implémentation du client minimal. Écriture d'un client applicatif qui se connecte au serveur et exerce les opérations protocolaires nécessaires au cas d'usage.
10.d — Premiers scénarios end-to-end. Vérification que le client et le serveur dialoguent correctement sur les scénarios identifiés, que les invariants sont préservés, que les diagnostics sont stables et exploitables.
10.e — Mesure et retour d'usage. Mesure de la latence par RPC (p50, p95, p99), du taux de réussite, du volume de Lease/Flow inscrits sous trace effective, des diagnostics les plus fréquents, et des cas où la tolérance V0 sur Contract non résolvable est déclenchée.
Invariant à préserver
L'application pilote ne doit jamais imposer un changement du .proto V0. Si elle révèle un manque structurel, ouvrir une nouvelle étape de durcissement plutôt qu'une extension du protocole en cours de pilote.
Limites à acter
L'application pilote reste explicitement expérimentale. Pas de bascule production massive en V0. Pas de contrats SLA contractualisés. L'objectif est de produire des retours d'usage qualitatifs et quantitatifs qui éclaireront la suite, pas de servir un cas critique en environnement de production.
Statut actuel
Le module pilot.rs du serveur de référence porte un plan d'application pilote V0.1. Il décrit la structure attendue d'une application pilote sans imposer de cas d'usage particulier. Le choix de l'application pilote concrète relève d'une décision distincte qui sera tracée dans un cycle de gouvernance dédié.
Cas concret retenu
Le projet Vote Compilation a été retenu comme premier cas d'application pilote concret. Il s'agit de la compilation citoyenne des résultats d'un scrutin national à l'échelle d'environ 30 millions d'habitants. Le projet exerce les sept opérations canoniques du protocole sur un domaine où l'auditabilité et la convergence par sources indépendantes sont des propriétés constitutives du système.
Vote Compilation
Modélisation du projet de compilation citoyenne comme application directe de Stratide Flux. Trois mouvements (recueil, validation, compilation), trois familles de notions, neuf entités projetées, audit par convergence d'observations indépendantes. Six schémas illustratifs.