Protocole PRISME-Mesh — réseau edge décentralisé

Projet : PRISME — France 2030

Version : 0.1 (brouillon M12)

Statut : spécification technique + charte ESS — à valider CODIR (post-séminaire 29/07/2026) · COPIL + comité éthique IA (M1+)

Jalon : protocole signé M12 · registre opérationnel M18 · ≥ 3 nœuds M24

Complète : Axe entrepreneurial & edge §4 · IA fédérée Marty · Edge computing & Nœud IA Expérimental · Autonomie & outils souverains · F05 · 05 ia responsable

Principe fondateur : « J'ai des ressources — je les partage lorsque je ne les utilise pas. »

1. Objet et périmètre

1.1 Problème adressé

De nombreuses structures culturelles (compagnies émergentes, jeunes lieux, entrepreneurs de spectacles cat. 1–3) n'ont ni GPU ni administrateur système pour exécuter localement un petit modèle de langage spécialisé (SLM). À l'inverse, certaines structures (fabriques, scènes, hubs réseau) disposent de capacité de calcul inutilisée en dehors des créneaux de production.

PRISME-Mesh mutualise cette capacité sans centraliser les données métier — complément de l'inférence locale (Nœud IA POC / Serveur Outils Grainerie) et de l'apprentissage fédéré Marty (FedAvg).

1.2 Ce que PRISME-Mesh est — et n'est pas

1.3 Distinction avec l'apprentissage fédéré

Les trois mécanismes sont complémentaires et partagent la même gouvernance (charte F05, consentement, comité éthique IA).

1.4 Enjeux du réseau mesh edge — synthèse

Dans un mesh, aucun nœud n'est maître : la valeur du réseau dépend de huit registres indissociables. PRISME-Mesh les traite explicitement — c'est la condition pour passer de POC (TRL 3–4) à pilote filière (TRL 5–6).

Fil conducteur : sans orchestration robuste (1) et confiance (2), le mesh devient chaotique ; sans gouvernance ESS (4) et incitations (6), il ne grandit pas ; sans fiabilité (7) et qualité (8), il n'est pas adoptable par des structures culturelles.

flowchart LR
  subgraph enjeux["8 registres"]
    O[1 Orchestration]
    S[2 Sécurité]
    P[3 Performance]
    G[4 Gouvernance]
    I[5 Interop]
    E[6 Économie]
    R[7 Fiabilité]
    Q[8 Qualité IA]
  end
  subgraph prisme["PRISME-Mesh"]
    ORC[Orchestrateur]
    CHR[Charte ESS F05]
    REG[Registre mesh_nodes]
  end
  O & P & R --> ORC
  S & G & E --> CHR
  I & Q --> REG

Lecture dossier : PRISME ne promet pas un mesh générique — il expérimente un réseau ESS à gouvernance explicite, où chaque enjeu a un artefact (protocole, charte, API, indicateurs F08) et un jalon (M12–M24). Voir §2–§9 ci-dessous.

2. Charte ESS — gouvernance du réseau

2.1 Adhésion

2.2 Créneaux de partage (hubs)

Le contributeur définit des fenêtres de disponibilité :

2.3 Priorisation des bénéficiaires

Ordre de priorité de l'orchestrateur (en cas de contention) :

1. Structure sans nœud GPU local
2. Structure < 5 ETP équivalent numérique
3. Parcours entrepreneur émergent (pépinière CIRC-INO)
4. Membres contributeurs (crédit mesh)
5. Autres membres réseau

2.4 Données et confidentialité

Modes d'inférence mesh :

Mode B est le cas nominal pour l'assistant Marty administratif. Les données Baserow/Calendrier ne quittent pas l'instance spoke.

2.5 Modèle économique ESS

3. Architecture technique

3.1 Vue d'ensemble

flowchart TB
  subgraph spokes["Spokes — structures sans GPU"]
    S1["Compagnie émergente\nCalendrier + Baserow"]
    S2["Jeune lieu\nspoke léger Docker"]
  end

  subgraph control["Couche contrôle PRISME-Mesh"]
    REG["Registre nœuds\n(Baserow mesh_nodes)"]
    ORC["Orchestrateur\nmesh-orchestrator"]
    OIDC["Authentik / OIDC\nfédération identités"]
  end

  subgraph hubs["Hubs — capacité contributive"]
    H1["La Grainerie\nmarty — GPU 48 Go"]
    H2["Scène CIRC-INO\nhub secondaire"]
    H3["Le Filament\ninfogérance CHATONS"]
  end

  subgraph stack["Stack edge par hub"]
    VLLM["vLLM marty-llm\nOpenAI /v1"]
    HER["Hermes Gateway\nprofils marty-*"]
    MON["Monitoring\nkWh · GPU · SLA"]
  end

  S1 & S2 -->|HTTPS mTLS\nsoumission job| ORC
  ORC --> REG
  ORC --> OIDC
  ORC -->|route job| H1 & H2
  H1 --> VLLM & HER & MON
  H2 --> VLLM & HER
  H3 -.->|supervision| H1 & H2
  REG <-->|heartbeat · capacités| H1 & H2

3.2 Topologie logique — trois couches

┌─────────────────────────────────────────────────────────────────────────────┐
│ COUCHE 1 — Métier (par structure) │
│ Calendrier · Baserow · n8n · PostgreSQL — données ICC locales │
├─────────────────────────────────────────────────────────────────────────────┤
│ COUCHE 2 — PRISME-Mesh (mutualisation capacité) │
│ mesh-agent (spoke) · mesh-orchestrator · registre mesh_nodes │
├─────────────────────────────────────────────────────────────────────────────┤
│ COUCHE 3 — Inférence edge (hubs) │
│ vLLM · Hermes · profils marty-grainerie / marty-baserow / marty-calendar │
└─────────────────────────────────────────────────────────────────────────────┘

Héritage technique : le registre PRISME-Mesh étend la table Baserow instances_federees et l'API register déjà spécifiées dans SPEC_ARCHITECTURE_FEDEREE (Calendrier Grainerie).

3.3 Composants

3.4 Schéma réseau — flux de confiance

sequenceDiagram
  participant Spoke as Spoke (structure A)
  participant Orch as Orchestrateur
  participant Reg as Registre mesh_nodes
  participant Hub as Hub GPU (structure B)
  participant VLLM as vLLM / Hermes

  Spoke->>Orch: POST /api/mesh/jobs (JWT OIDC)
  Orch->>Reg: GET nœuds disponibles + créneaux
  Reg-->>Orch: liste hubs (GPU libre, latence, crédit)
  Orch->>Hub: POST /api/mesh/hub/execute (job chiffré)
  Hub->>VLLM: inférence SLM (profil marty-*)
  VLLM-->>Hub: completion
  Hub-->>Orch: résultat + métriques (tokens, kWh)
  Orch-->>Spoke: réponse + job_id
  Orch->>Reg: log métadonnées (sans PII)

3.5 Routage — algorithme (v0.1)

ENTRÉE : job (type, tokens_estimés, profil_marty, priorité_structure)
SORTIE : hub_id ou FILE_ATTENTE

1. Filtrer hubs : status=online · charte_valide · dans share_window
2. Exclure hubs : GPU_util > seuil (80 %) · preempt_mesh_jobs déclenché
3. Scorer chaque hub :
   score = w1·(1/latence) + w2·crédit_disponible + w3·priorité_bénéficiaire
         - w4·empreinte_kWh_estimée
4. Sélectionner hub score max
5. Si aucun hub : mise en file · notification · retry exponentiel (max 3)
6. Timeout job : 120 s (inférence admin) · 600 s (batch)

Principe sobriété : favoriser le hub géographiquement le plus proche et le moins chargé — réemploi de capacité existante (référence E5 Shift Project).

3.6 Hébergement de l'orchestrateur (décision CODIR Q4)

L'orchestrateur mesh est séparé de la couche métier (Calendrier, Baserow, n8n) et de l'inférence GPU (Nœud IA POC). Deux phases :

Règles d'architecture :

• Serveur Outils Grainerie conserve les données métier Grainerie ; l'orchestrateur expérimental n'y accède qu'aux métadonnées mesh_nodes (pas aux bases ICC).
• Le serveur dédié mesh (classe Nœud IA POC : Xeon, 64–128 Go RAM, stockage NVMe — sans obligation GPU pour l'orchestrateur) héberge la couche contrôle ; l'inférence GPU reste sur Nœud IA POC et les hubs contributeurs.
• Bascule M18 : export état registre · bascule DNS mesh.prisme.grainerie.net · tests de non-régression (10 jobs pilotes).

Patrimoine existant : Nœud IA POC (GPU inférence, 10 707 € HT acquis) · Serveur Outils Grainerie (HP DL580 G7, 600 € HT) — voir budget mesh infrastructure.

4. Modèle de données — registre mesh_nodes

Extension de instances_federees :

Heartbeat hub (toutes les 30 s) :

{
  "node_id": "uuid",
  "status": "online",
  "gpu_util_pct": 12,
  "vram_free_gb": 40,
  "mesh_jobs_active": 0,
  "local_jobs_active": 1,
  "accepting_mesh": true
}

5. API PRISME-Mesh (spécification v0.1)

Base URL orchestrateur : https://mesh.prisme.grainerie.net (indicatif — instance Serveur Outils Grainerie ou service dédié).

5.1 Enregistrement nœud

POST /api/mesh/nodes/register
Authorization: Bearer <JWT OIDC>
Content-Type: application/json

Corps (hub) :

{
  "node_type": "hub",
  "endpoint_mesh": "https://marty.grainerie.net/api/mesh/hub",
  "gpu_model": "RTX PRO 5000",
  "vram_gb": 48,
  "share_windows": [
    { "cron": "0 22 * * 1-5", "duration_hours": 9 },
    { "cron": "0 0 * * 0,6", "duration_hours": 24 }
  ],
  "max_concurrent_jobs": 2,
  "charte_version": "0.1"
}

Réponse : 201 Created + node_id

5.2 Soumission job (spoke)

POST /api/mesh/jobs
Authorization: Bearer <JWT OIDC>

Corps :

{
  "profile": "marty-grainerie",
  "mode": "A",
  "prompt": "Résume ce texte en 3 points…",
  "max_tokens": 512,
  "temperature": 0.2,
  "priority": "emergent",
  "callback_url": null
}

Réponse synchrone (hub disponible) :

{
  "job_id": "uuid",
  "status": "completed",
  "hub_node_id": "uuid",
  "completion": "…",
  "metrics": {
    "tokens_in": 120,
    "tokens_out": 89,
    "duration_ms": 2340,
    "kwh_estimated": 0.002
  }
}

5.3 Exécution côté hub

POST /api/mesh/hub/execute
Authorization: Bearer <mesh-internal-token>
X-Mesh-Job-Id: uuid

Le hub invoque marty-llm (completions) ou Hermes Gateway selon le profil — sans persister le prompt au-delà du TTL job (défaut 300 s).

5.4 Statut et métriques

GET /api/mesh/jobs/{job_id}
GET /api/mesh/nodes/{node_id}/metrics?period=30d

6. Sécurité

Garde-fous IA (F05) :

• Profils marty-* à périmètre restreint — pas d'outils destructifs cross-structure
• Relecture humaine obligatoire pour sorties à impact (contrats, RH)
• Pas de jobs mesh pour programmation artistique ou génération de contenu scénique

7. Déploiement — package spoke

PRISME-edge-minimal (Docker Compose) — jalon M18 :

# Extrait indicatif — voir livrable Développer M18
services:
  mesh-agent:
    image: prisme/mesh-agent:0.1
    environment:
      MESH_ORCHESTRATOR_URL: https://mesh.prisme.grainerie.net
      OIDC_ISSUER: https://auth.grainerie.net
    volumes:
      - ./config:/config:ro
  # Optionnel — Calendrier spoke léger sans GPU

Le spoke n'expose pas de port GPU — il délègue l'inférence au mesh.

8. Scénario type — compagnie émergente

flowchart LR
  subgraph emer["Compagnie émergente (spoke)"]
    CAL["Calendrier simplifié"]
    AG["mesh-agent"]
    DATA["Données locales\nBaserow"]
  end

  subgraph mesh["PRISME-Mesh"]
    O["Orchestrateur"]
  end

  subgraph hub["La Grainerie (hub)"]
    M["Nœud IA POC GPU\n22h–7h libre"]
  end

  CAL -->|tâche métier différée| AG
  DATA -->|contexte local| AG
  AG -->|job mode B| O
  O -->|routage| M
  M -->|completion| O
  O --> AG

Étapes :

1. Compagnie issue de la pépinière CIRC-INO — spoke déployé (M18).
2. Besoin : résumer un compte rendu de répétition (mode A — texte déjà anonymisé) — job déposé, pas d'échange conversationnel.
3. mesh-agent soumet le job en arrière-plan — priorité emergent ; délai acceptable (file + routage mesh).
4. Orchestrateur route vers Nœud IA POC (créneau 22h–7h, GPU à 12 %) — latence réseau assumée.
5. Inférence marty-grainerie — notification à la fin du traitement ; relecture humaine si besoin.
6. Métriques observatoire : 0,002 kWh vs ~0,2 kWh GPAI cloud (ordre de grandeur E5).

Posture : PRISME-Mesh privilégie la mutualisation différée et la sobriété — l'inverse de l'accélération et de la facilitation à la demande des GPAI commerciaux.

9. Jalons et critères d'acceptation

10. Indicateurs (F08)

11. Annexes

Annexe A — Charte d'adhésion (modèle)

La structure {nom} adhère au réseau PRISME-Mesh en tant que {hub/spoke/hybride}. Elle s'engage à : - respecter la charte IA PRISME (F05) et le présent protocole ; - ne pas utiliser le mesh pour centraliser des données personnelles ou des œuvres ; - prioriser les jobs locaux sur les jobs mesh (hubs) ; - accepter la quote-part ESS du réseau ; - permettre la révocation sans pénalité avec préavis de 30 jours. Signé à {lieu}, le {date} — Direction / représentant légal.

Annexe B — Profils Marty autorisés sur le mesh (v0.1)

Annexe C — Références techniques

12. Formulation dossier (Word §5 Innovation)

PRISME expérimente un réseau edge décentralisé (PRISME-Mesh) piloté par un registre de nœuds, un orchestrateur de jobs et une charte ESS : les structures dotées de GPU partagent leur capacité en créneaux libres ; les structures sans matériel accèdent à l'inférence de petits modèles spécialisés via l'API mesh — sans centraliser les données métier. Le protocole technique (v0.1, M12) s'appuie sur l'infrastructure existante Nœud IA POC/vLLM/Hermes, l'infogérance Le Filament et l'expertise académique ANITI (conseil orchestrateur · espace B612) pour sécuriser le passage TRL 3–4 → 5–6. Voir Protocole PRISME-Mesh · Partenariat ANITI.

13. Contrôles avant publication M12

• Validation direction La Grainerie / CODIR
• Avis comité éthique IA
• Accord de principe Le Filament (infogérance hubs)
• Accord de principe CIRC-INO (hub pilote secondaire)
• Prise de contact Olivier Simonin (ANITI) — MOU conseil mesh / accès B612
• Revue sécurité — pas d'exposition vLLM Internet
• Alignement F08 indicateurs grille PICXEL