Index <= Page index / Language => << ENG >>

Réseau crypté résilient des maires – Parcours guidé

Une présentation ordonnée du projet : vision citoyenne, rôle des maires, des autres officiels et des citoyens, puis les moyens techniques pour rester connectés même en coupure totale.

Vision Rôles & priorités Vecteurs Résilience & ferries Blockchain Prototypes & code

Intro

Vision citoyenne

Le projet imagine un réseau blockchain privé des maires, lancé pour la République centrafricaine et transposable en France. Il part d’une conviction simple : le maire, et plus encore le corps des maires, est la voix la plus proche du citoyen. L’ambition est de leur donner un outil moderne, sécurisé et résilient, qui prolonge l’esprit de la palabre locale mais à l’échelle nationale.

Le cœur politique précède la technique : redonner un rôle structurant au corps des maires dans le cycle de la loi, garder une trace immuable des échanges et organiser la continuité du service public en période de crise. Les briques techniques viennent ensuite pour que la promesse tienne, même quand tout le reste tombe.

Ce que le réseau offre

  • un forum des maires pour débattre et voter ;
  • des votes signés, horodatés et vérifiables ;
  • un registre immuable des décisions locales ;
  • une messagerie gratuite ouverte aux citoyens.

Chaque brique vise à être compréhensible par des élus non techniques, tout en restant exploitable par des développeurs et opérateurs réseaux.

Pour tenir en coupure totale, le réseau s’appuie sur des relais locaux, des bulles Wi‑Fi opportunistes et des « ferries » mobiles (bus, motos, ONG, citoyens volontaires) qui transportent des paquets chiffrés entre zones isolées. Cette résilience est un support, pas une fin : elle sert d’abord la gouvernance locale.

1

Rôles, priorités et capacité

Le réseau respecte une priorité naturelle : les élus locaux et les agents essentiels doivent passer en premier sur la file d’urgence, sans exclure les citoyens qui peuvent toujours s’exprimer et s’informer.

Élus et officiels

On attend quelques centaines de responsables (maires, députés, préfets, écoles, santé, sécurité) sur la voie prioritaire. Le volume reste gérable même en coupure longue, tout en gardant de la place pour des équipes de support et des techniciens locaux.

Citoyens

Les citoyens peuvent être plusieurs centaines de milliers à disposer d’un téléphone ou d’un point d’accès. Une fraction significative peut utiliser les services (messagerie, info locale, demandes aux maires) sans saturer les voies réservées, grâce aux vecteurs opportunistes et aux priorités P0→P3.

Cette répartition guide le design : file rapide pour les décisions publiques, file ample pour la société civile, et des mécanismes d’arbitrage automatiques (priorités, TTL, quotas) pour éviter la congestion.

2

Les vecteurs : du plus rustique au plus ambitieux

Chaque vecteur est une porte d’entrée différente. On choisit selon le contexte : coupure totale, mobilité, maillage local ou backbone longue portée. Les maires et officiels y trouvent un canal prioritaire ; les citoyens y trouvent un espace pour relayer et participer.

Nommage global (OBB)

  • Blockchain : OBB_MANET_Blockchain (secteur 0 lancé par les maires).
  • Vecteur 1 – USB/SD (air-gap) : bundles sur clé/SD, utilité en coupure totale. Roadmap V1
  • Vecteur 2 – MANET géo (OBBM) : bulles Wi‑Fi opportunistes, manifest géo-scopé. Présentation · Roadmap V2
  • Vecteur 3 – OBBHFL : stations K/H/S/B, backhaul modéré, services locaux. Roadmap V3
  • Vecteur 4 – OBBHFH + OBBDW : backbone 5 GHz longue portée + corridors FPV Dotted Way. Présentation · Roadmap V4 · Roadmap V4 bis

Choix rapide : V1 (coupure totale), V2 (mobilité opportuniste), V3 (maillage local), V4 (haute portée / relief / fleuve).

Ce que chaque vecteur offre aux maires et aux citoyens

  • Vecteur 1 – Les maires peuvent échanger blocs et décisions via clés USB/SD lors des conseils ou via des courriers sécurisés ; les citoyens peuvent remettre ou récupérer des messages chiffrés en mairie pour qu’ils soient injectés lors du prochain passage.
  • Vecteur 2 – Les maires et agents utilisent leurs téléphones ou boîtiers pour former des bulles Wi‑Fi temporaires dans les marchés, gares ou villages ; les citoyens laissent tourner l’app en tâche de fond pour transporter des « LuckyBlocks » et recevoir l’information locale.
  • Vecteur 3 – Les mairies, écoles, centres de santé servent de hubs fixes (stations K/H/S/B) ; les citoyens se connectent en local pour actualités, demandes et messagerie, même sans internet national.
  • Vecteur 4 – Les antennes longue portée relient les chefs-lieux ou traversent les fleuves ; les maires y trouvent une voie rapide pour synchroniser la chaîne, les citoyens bénéficient d’une diffusion plus rapide des contenus publics.

Chaque vecteur renforce les autres : un ferry USB peut apporter des blocs à une station V3, qui les diffuse ensuite en V2 mobile ; un backbone V4 raccourcit le temps d’attente, mais V1 reste la roue de secours ultime.

3

Résilience, transport opportuniste et priorités

Pour rendre la priorité aux maires concrète sans priver les citoyens, on organise les échanges par classes de service et par portée géographique. La circulation continue même par morceaux, grâce aux ferries humains et aux stations fixes.

Bundles & priorités (P0→P3)

  • P0 : alertes (TTL 7 j, max hops 10).
  • P1 : discussions importantes (TTL 30 j, max hops 6).
  • P2 : bavardages / historiques (TTL 90 j, max hops 4).
  • P3 : archives locales (TTL 180 j, max hops 2).

Lors d’une connexion : échange capacité lien, résumés (blocs/forum), construction liste de bundles à pousser par priorité + scope + quotas.

À faire Définir format manifest bundle (hash, taille, scope, TTL, classe).

Paquets geo-scopés ("Lucky Blocks") / Ferry opportuniste

Transport opportuniste de bundles via bornes fixes et porteurs mobiles (bus, train, voiture, téléphones/boîtiers S) pour franchir les zones sans réseau.

Topologie Station K et transport opportuniste

  • Bundles gzip+base64 avec manifest enrichi (destinations, priorités P0..P3, hashes, TTL).
  • Export/import via API et UI admin (section Bundles) + script carrier (Termux/laptop) pour “USB sur pattes”.
  • ACK pour purge, TTL temps + hops pour éviter saturation.
  • Participation citoyenne : partage Wi‑Fi local, stockage éphémère chiffré, destination déclarée sous pseudo éphémère.
  • Mode porteur “privacy-first” : un carrier n’ouvre rien, ne push que depuis son outbox chiffrée et ne partage aucune donnée personnelle ; validité = ID acceptée par la chaîne (vérifiable sur demande d’un maire). Envois/réceptions perso et portage peuvent être distincts (tu peux porter sans lire).
  • Routage opportuniste : si la destination finale n’est pas sur le trajet, on choisit un hub K proche (gare/bus) ou un proxy ami ; le manifest pourra être enrichi par l’humain pour forcer un regroupement géo avant le prochain saut.
  • À faire UI carte détaillée :
    • Carte OSM/offline, couches activables : bulles S (mobiles), bulles K (fixes), cônes H (directionnels), liens backhaul M3/M5.
    • Représentation radio : bulles avec opacité = SNR/confiance, cônes directionnels (10–30°), portée 10–15 km, backhaul en lignes fines.
    • Routes/transport : polylines colorées bus/train/route, épaisseur = trafic estimé, ETA moyen par segment, chemins favoris imposés par l’opérateur.
    • Bundles (publics) : manifest clair (scope, priorité, TTL, hash/taille), suivi non confidentiel des hubs traversés, option “forcer route via Kx”.
    • Fiche hub : coord approx, portée, backhauls connus, stock inbox/outbox, état lien internet si présent.
    • Visuels : palette actuelle, animations légères (pulsation bulles, dégradé cônes), légende fixe.
    • Données nécessaires : positions approx K/H, angle/puissance antennes dir., portées S/K/H, inventaire backhauls, trafic estimé routes, stats outbox/inbox.

Cette mécanique ferme la boucle : les décisions prises sur la blockchain remontent dans les villages via V2/V3, pendant que les retours citoyens remontent doucement vers les mairies, même sans réseau national.

4

Blockchain locale (réseau des maires)

La blockchain locale sert de colonne vertébrale aux échanges. Elle reste simple pour être maintenable, tout en assurant la légitimité et la traçabilité des décisions.

Ce que la chaîne fait

Ce que la chaîne ne fait pas

Rôles

Genèse / secteur 0 (IDs & quorum)

Identités & clés

Formats

5

Prototypes labo et code à structurer

Avant de déployer à grande échelle, un banc d’essai simple permet de vérifier la circulation des blocs, des bundles et la résilience en coupure simulée.

Prototypes labo (3 laptops + 2 ESP32 + mobile phone)

  • Laptop 1 : nœud central (admin, collecte chain).
  • Laptop 2 : Relais K – Commune A (API, connecte ESP32_A).
  • Laptop 3 : Relais K – Commune B (API, synchro inter-communes).
  • ESP32_A/B : boîtiers S pour chaque commune.

À faire Scripts firewall pour simuler coupure backhaul A↔Central / B↔Central.

À faire Script copie USB simulée (export/import blocs entre laptops).

Arborescence code / dépôts par station

  • devices/station-S/ – firmware ESP32 S (captive portal, API, µSD).
  • devices/station-H/ – dérivé S + gestion antenne dir. + synchro chain.
  • devices/station-K/ – scripts OpenWRT + agent sync + stockage.
  • devices/backhaul-C/ – configs point-à-point, qualité lien, quotas.
  • devices/maire-terminal/ – app tablette (signatures, forum, votes).
  • backend/obambu_node/ – API FastAPI + chain + sync.
  • docs/ – schémas, procédures, BOM.

À faire Créer ces dossiers et y déposer READMEs pour chaque station.