Objectifs et indicateurs

Le kickoff fixe cinq attentes à la Ville d'EtherBay. Cette page les transforme en indicateurs mesurables, indique où la donnée existe déjà dans le code, et signale les mesures qui restent à construire. Elle s'appuie sur la reformulation des besoins de l'équipe et sur deux de ses livrables : le dossier de cadrage (« Proposition de valeur ») et le dossier « Budget, acquisition et indicateurs ».

#Des attentes aux indicateurs

Les sections suivantes détaillent chaque attente.

#Éducatif

Le but est que les habitants comprennent ce qu'ils engagent et comment le gagnant est choisi. Le dossier de cadrage retient deux seuils, présentés comme des critères de décision de l'équipe (hypothèse H03) et non comme des objectifs garantis :

Le code contribue à cet objectif sans le mesurer :

• la page publique /transparence (frontend-web/src/app/transparence/page.tsx) et la route GET /api/v1/lottery/transparency-charter exposent une charte vulgarisée ;
• la billetterie web impose de cocher « Je comprends que j'engage des ethers fictifs, sans valeur monétaire, dans un tirage pédagogique » avant de confirmer ;
• la quête READ_TRANSPARENCY_CHARTER rapporte 20 EtherPoints, mais elle est validée sur simple déclaration.

#Engagement

#L'objectif de 10 000 participants

C'est le seul objectif chiffré du kickoff. Il représente environ un quart de la cible principale (42 000 habitants de 18 à 35 ans) et 8 % de la population.

Le livrable « Budget, acquisition et indicateurs » définit le participant confirmé comme une personne éligible distincte ayant au moins un ticket confirmé sur le réseau. Il précise qu'une personne peut détenir plusieurs adresses : compter des comptes n'est pas compter des personnes. Le projet associe un compte à un email vérifié par code, à un portefeuille unique et à une pièce d'identité examinée par la Mairie, ce qui limite les doublons sans les empêcher : rien ne rapproche deux comptes qui présenteraient la même pièce, puisque les images sont effacées après la décision.

#Ce que mesure le code

Requête de contrôle sur la base, tous tours confondus :

SELECT COUNT(DISTINCT "userId") AS participants_confirmes
FROM "Ticket";

Un ticket n'est écrit en base que par l'indexeur, après lecture de l'événement TicketsPurchased du contrat : c'est donc bien un ticket confirmé sur la chaîne.

#Les scénarios de participation de l'équipe

Le livrable budget calcule le nombre de participants selon le nombre de visiteurs uniques éligibles et un taux de conversion supposé (hypothèse H04). Ces chiffres sont des hypothèses de travail sans référence locale.

L'objectif n'est atteint que dans le scénario ambitieux. Le livrable en conclut que l'ambition dépend surtout de la mobilisation des relais locaux, détaillée dans le volet marketing.

#Innovation

L'indicateur technique est le nombre de badges POAP frappés. Chaque frappe émet BadgeMinted et un Transfer depuis l'adresse zéro sur smart-contract/contracts/BlockLuckyPOAP.sol. Le backend frappe un badge par participant et par tour, via la file d'actions on-chain (backend/src/blockchain/chain-actions.ts). Le nombre de badges d'un tour est donc égal au nombre de participants distincts une fois la file vidée.

Les retombées presse et réseaux ne sont pas mesurées par le code. Le suivi des sources d'acquisition (utm_source) en donne une approximation par canal.

#Transparence

Les liens vers l'explorateur ne s'affichent que si EXPLORER_URL est défini (vide en local, https://sepolia.etherscan.io prévu sur Sepolia).

#Collaboration

L'indicateur est la remise des livrables : code, documentation, livrables marketing et UX, soutenance. Le catalogue des fonctionnalités et la grille de compétences servent de pièces justificatives.

#Indicateurs de pilotage de la campagne

Le livrable budget propose un dictionnaire d'indicateurs. Le tableau précise pour chacun si le code fournit déjà la donnée.

#Le parcours instrumenté

Le frontend web envoie six événements de parcours à POST /api/v1/analytics/track, définis dans frontend-web/src/lib/analytics.ts. Ils correspondent aux six étapes du parcours conçu par l'équipe (voir Profils et parcours).

flowchart LR
    A["landing_view"] --> B["rules_view"]
    B --> C["access_started"]
    C --> D["ticket_submitted"]
    D --> E["ticket_confirmed"]
    E --> F["result_view"]

Ces événements sont enregistrés dans la table Analytics avec la source d'acquisition. Le citoyen peut refuser la mesure d'audience depuis /confidentialite ; aucun événement n'est alors envoyé. Le dashboard ne présente pas encore d'entonnoir : la requête suivante le calcule.

SELECT "eventType", COUNT(*) AS evenements, COUNT(DISTINCT "userId") AS comptes
FROM "Analytics"
WHERE "eventType" IN ('landing_view', 'rules_view', 'access_started', 'ticket_submitted', 'ticket_confirmed', 'result_view')
GROUP BY "eventType";

Les étapes antérieures à la connexion sont anonymes (userId nul) : le nombre de comptes distincts n'a de sens qu'à partir de ticket_submitted.

#Indicateurs techniques

Le backend expose sur /metrics le compteur Prometheus business_events_total, dont l'étiquette event distingue ticket_purchased, ticket_indexed, reward_claimed et les crédits et débits d'EtherPoints, en plus des latences par route (backend/src/observability/metrics.ts). Les objectifs de service associés sont dans Objectifs de service et métriques.

#Limites des chiffres du dashboard