ORBIT 2026 — RUNBOOK OPÉRATIONNEL

Organisation et conduite des sept jours

30 TALENTS · 7 DAYS · 6 MISSIONS · 1 ORBIT

 Manuel d’exécution

1. OBJET DU RUNBOOK

Le présent Runbook définit le déroulement opérationnel de la première édition du SPACESORTIUM ORBIT HACKATHON™.

Il complète notamment :

• le Dossier officiel de lancement ;

• le Règlement officiel ;

• le Cahier des charges des six missions ;

• l’Architecture technique de référence ;

• les spécifications API et Data communes ;

• les règles de sécurité ;

• le référentiel d’évaluation.

Il constitue le document de conduite quotidien pour :

l’organisation, les participants, les Mission Leads, les mentors, le Comité technique, les responsables d’intégration, le jury et les partenaires techniques.

Son objectif est d’assurer que les sept jours ne constituent pas une succession d’activités improvisées, mais une progression contrôlée vers une démonstration intégrée.

2. PRINCIPE DIRECTEUR

La logique générale de la semaine est :

UNDERSTAND → DESIGN → BUILD → CONNECT → INTEGRATE → SECURE → DEMONSTRATE

Chaque journée possède :

• un objectif principal ;

• des livrables obligatoires ;

• des points de contrôle ;

• des réunions communes ;

• des activités de mentorat ;

• des contrôles techniques ;

• un critère de passage à la journée suivante.

Aucune équipe ne doit progresser uniquement en fonction de son propre périmètre.

Le principe reste :

CONSTRUIRE SÉPARÉMENT. CONCEVOIR ENSEMBLE. INTÉGRER EN CONTINU.

3. LES HUIT TEMPS DE L’OPÉRATION

Le Runbook distingue :

J0 — ONBOARDING
Préparer les personnes et les environnements.

J1 — UNDERSTAND & DESIGN
Comprendre, spécifier et concevoir.

J2 — BUILD
Construire les premières fonctions.

J3 — BUILD & CONNECT
Faire émerger les interfaces entre équipes.

J4 — INTEGRATE
Tester réellement les connexions.

J5 — CONSOLIDATE & SECURE
Stabiliser, sécuriser et documenter.

J6 — INTEGRATED DEMO
Assembler et répéter le scénario global.

J7 — ORBIT
Finaliser, démontrer, évaluer et reconnaître.

J0 constitue une journée préparatoire et ne fait pas partie des sept jours officiels de construction.

4. ORGANISATION DE COMMANDEMENT

ORBIT doit être conduit comme une opération multiéquipes.

Je recommande la structure suivante.

ORBIT DIRECTOR

Responsable général de l’événement.

Décisions organisationnelles, arbitrages majeurs, relation avec les partenaires.

TECHNICAL DIRECTOR

Garant de l’architecture globale.

Arbitre :

• architecture ;

• APIs ;

• modèles de données ;

• sécurité ;

• intégration ;

• dérogations techniques.

INTEGRATION LEAD

Responsable transversal de la convergence des six missions.

Il ne dirige pas une équipe particulière.

Sa mission est de s’assurer que les équipes se connectent réellement entre elles.

SECURITY LEAD

Responsable des environnements, accès, secrets, incidents et contrôle de sécurité.

DATA / API LEAD

Garant :

• du Common Data Model ;

• des identifiants ;

• des API Contracts ;

• des formats d’échange.

MISSION LEADS

Un référent par mission :

01 Social Core
02 Nation Digital Twin
03 Natiometric AI
04 Natioscope
05 Citizen
06 Data & Infrastructure

MENTORS

Interviennent pour conseiller, challenger et débloquer.

Ils ne doivent pas réaliser le travail à la place des participants.

5. ORGANISATION DES ÉQUIPES

Chaque équipe d’environ cinq personnes devra répartir au minimum les responsabilités suivantes :

Mission Coordination

Technical Architecture

Development

Integration

Documentation / QA

Certaines responsabilités peuvent être cumulées.

Les missions plus spécialisées pourront également désigner :

AI Lead, Data Lead, Security Lead, UX Lead ou Cloud Lead.

Chaque responsabilité doit être identifiable.

6. CADENCE QUOTIDIENNE STANDARD

Je recommande une structure relativement stable pendant les sept jours.

08:30 — ARRIVÉE / SYNCHRONISATION

Installation et préparation.

09:00 — ORBIT DAILY BRIEF

Réunion commune courte.

Durée cible : 15 à 20 minutes.

Chaque équipe répond à trois questions :

Qu’avons-nous accompli ?
Que devons-nous accomplir aujourd’hui ?
Quel blocage peut empêcher notre intégration ?

09:20 — TRAVAIL PAR MISSION

Construction.

11:30 — TECHNICAL / INTEGRATION CHECK

Synchronisation des responsables techniques.

13:00 — PAUSE

14:00 — BUILD SESSION

Travail intensif.

16:30 — MENTOR / REVIEW WINDOW

Revues techniques, produit, sécurité ou architecture.

18:00 — INTEGRATION WINDOW

Tests croisés obligatoires selon le programme de la journée.

19:00 — DAILY REVIEW

Bilan et mise à jour des livrables.

19:30 — ORBIT CONTROL BOARD

Réunion courte des responsables :

ORBIT Director + Technical Director + Integration Lead + Mission Leads.

Objectif :

GO / GO WITH CONDITIONS / BLOCKED

pour chaque équipe.

Les horaires exacts pourront évidemment être adaptés.

J0 — ONBOARDING & ENVIRONMENTS

Finalité

Faire en sorte que J1 commence par la construction et non par les problèmes administratifs ou techniques.

J0 doit éliminer autant que possible les frictions.

Objectifs

Chaque participant doit :

• connaître son équipe ;

• connaître sa mission ;

• connaître les règles ;

• disposer de ses accès ;

• pouvoir cloner les dépôts ;

• lancer l’environnement ;

• accéder à la documentation ;

• comprendre l’architecture générale ;

• connaître les canaux de support.

Séquence proposée

1. Welcome & Mission Brief

Présentation :

SPACESORTIUM™
SPACESORTIUM BUILDERS™
MISSION ORBIT
BUILD → INTEGRATE → JOIN

2. Présentation des six missions

10 minutes maximum par mission.

3. Présentation des équipes

Nom, profil, compétence principale, rôle initial.

4. Security Onboarding

• comptes ;

• MFA si applicable ;

• secrets ;

• dépôts ;

• données autorisées ;

• signalement des incidents.

5. Technical Onboarding

Accès :

• Git ;

• Cloud ;

• API ;

• bases de données ;

• documentation ;

• outils de communication ;

• tableaux de tâches.

6. Environment Test

Chaque participant doit pouvoir exécuter un scénario minimal.

Exemple :

login → appel API → lecture d’une donnée → affichage d’un résultat.

Livrables J0

L0.1 — Participant access validated

L0.2 — Teams confirmed

L0.3 — Repositories accessible

L0.4 — Development environment operational

L0.5 — Security acknowledgement completed

L0.6 — Mission pack received

GATE J0 — READY TO BUILD

Une équipe ne passe pas en J1 si elle ne dispose pas d’un environnement fonctionnel.

Critère cible :

100 % DES PARTICIPANTS PEUVENT COMMENCER À PRODUIRE.

J1 — UNDERSTAND / SPECIFY / ARCHITECT

Finalité

Ne pas commencer par coder.

Commencer par comprendre ce qui doit être construit et comment cela s’insère dans le système global.

Question du jour

WHAT ARE WE REALLY BUILDING?

Objectifs

Chaque équipe doit clarifier :

• problème ;

• utilisateurs ;

• cas d’usage ;

• périmètre ;

• fonctionnalités prioritaires ;

• architecture ;

• données ;

• interfaces ;

• dépendances ;

• critères de réussite.

Matin — Problem Framing

Chaque équipe produit :

Mission Canvas

Problème

Utilisateur

Valeur

Fonctions critiques

Non-objectifs

Dépendances

Risques

Definition of Done

Après-midi — Architecture

Chaque équipe réalise :

• architecture logique ;

• composants ;

• données ;

• API nécessaires ;

• API exposées ;

• dépendances externes ;

• mécanismes de sécurité ;

• plan de tests.

Réunion clé

ORBIT ARCHITECTURE SUMMIT

Les six équipes présentent leur architecture.

Objectif :

identifier immédiatement :

• doublons ;

• modèles incompatibles ;

• API manquantes ;

• responsabilités ambiguës ;

• dépendances critiques.

Livrables J1

L1.1 — Mission Canvas

L1.2 — Architecture v0.1

L1.3 — Data Model v0.1

L1.4 — API Needs

L1.5 — Integration Dependencies

L1.6 — Backlog priorisé

L1.7 — Risk Register

GATE J1 — ARCHITECTURE READY

Pour passer :

le problème est compris ;
le périmètre est réaliste ;
l’architecture est cohérente ;
les interfaces critiques sont identifiées.

J2 — BUILD THE CORE

Finalité

Construire le minimum fonctionnel réel de chaque mission.

Question du jour

WHAT MUST WORK FIRST?

Chaque équipe doit identifier sa Critical Path Feature.

Exemples :

Social Core

Créer un profil et publier.

Digital Twin

Créer une Nation et relier un territoire.

Natiometric AI

Ingérer une donnée et produire un résultat structuré.

Natioscope

Visualiser un indicateur réel.

Citizen

Soumettre une contribution et suivre son statut.

Data & Infrastructure

Authentifier un utilisateur et exposer une API commune.

Règle du jour

WORKING SOFTWARE BEFORE OPTIONAL FEATURES

Les équipes ne doivent pas multiplier les fonctions tant que le cœur ne fonctionne pas.

Mentorat

Les mentors interviennent principalement sur :

architecture, code quality, data et produit.

Livrables J2

L2.1 — Core Feature opérationnelle

L2.2 — Repository actif

L2.3 — Initial tests

L2.4 — API implementation started

L2.5 — README minimal

GATE J2 — CORE WORKS

Chaque équipe doit pouvoir montrer quelque chose qui fonctionne réellement.

Pas une présentation.

Pas une maquette.

Une fonctionnalité.

J3 — BUILD & CONNECT

Finalité

Faire sortir les équipes de leur périmètre isolé.

Question du jour

CAN ANOTHER TEAM USE WHAT WE BUILT?

C’est la journée des Interface Contracts.

Matin

Poursuite de la construction.

Milieu de journée

API CONTRACT FREEZE v0.1

Les équipes concernées fixent :

• endpoint ;

• méthode ;

• authentication ;

• payload ;

• response ;

• errors ;

• version ;

• responsable.

Pairing interéquipes

Les développeurs de deux missions dépendantes travaillent ensemble.

Exemples :

Social Core ↔ Digital Twin

Digital Twin ↔ Natioscope

Digital Twin ↔ Natiometric AI

Citizen ↔ Social Core

Citizen ↔ Natiometric AI

Toutes ↔ Data & Infrastructure

Premier Integration Smoke Test

Objectif :

obtenir au moins une interaction réelle entre deux missions.

Livrables J3

L3.1 — API Contracts v0.1

L3.2 — Première API consommée

L3.3 — Première API exposée

L3.4 — Integration Smoke Test

L3.5 — Updated Dependency Map

GATE J3 — CONNECTED

Une équipe ne doit plus être considérée comme totalement autonome.

Elle doit avoir au moins un point d’intégration réel ou techniquement validé.

J4 — CROSS TEST & INTEGRATE

Finalité

Faire fonctionner les composants ensemble.

C’est l’une des journées les plus importantes.

Question du jour

DOES THE SYSTEM WORK, NOT JUST THE MODULE?

Integration War Room

Les responsables techniques travaillent ensemble.

Un tableau central affiche :

Tests

Chaque équipe participe à au moins :

1 test d’intégration entrant

et

1 test d’intégration sortant, lorsque possible.

Incident Classification

RED

bloque le système global.

ORANGE

dégradation importante.

YELLOW

problème local.

BLUE

amélioration souhaitée.

Les RED doivent être traités en priorité absolue.

Livrables J4

L4.1 — Integration Test Report

L4.2 — Updated API Contracts

L4.3 — Issue Register

L4.4 — End-to-End Scenario v0.1

L4.5 — Integrated Environment

GATE J4 — SYSTEM CONNECTED

Objectif :

plusieurs composants peuvent réellement échanger.

La priorité passe désormais des fonctionnalités nouvelles à la cohérence du système.

J5 — CONSOLIDATE / SECURE / DOCUMENT

Finalité

Transformer un système qui fonctionne « parfois » en système présentable, compréhensible et reprenable.

Question du jour

COULD SOMEONE ELSE OPERATE WHAT WE BUILT?

Feature Freeze

Je recommande un :

FEATURE FREEZE PARTIEL

À partir d’une heure définie, aucune fonctionnalité non essentielle ne doit être ajoutée sans validation.

La priorité devient :

bugs → sécurité → tests → documentation → intégration.

Security Review

Contrôles :

• secrets ;

• permissions ;

• auth ;

• validation entrées ;

• données ;

• logs ;

• dépendances ;

• endpoints exposés.

Documentation Sprint

Chaque équipe doit mettre à jour :

README
architecture
installation
configuration
API
data model
tests
limitations
known issues
next steps.

Livrables J5

L5.1 — Security Checklist

L5.2 — Documentation Pack

L5.3 — Test Results

L5.4 — Known Issues

L5.5 — Deployment Procedure

L5.6 — Integration Status

GATE J5 — STABLE & DOCUMENTED

Une solution n’est pas considérée comme prête si :

elle fonctionne mais personne ne sait l’installer,
elle expose des secrets,
elle dépend du laptop d’un participant,
ou ses limites sont inconnues.

J6 — INTEGRATED DEMO & REHEARSAL

Finalité

Transformer les six travaux en une seule histoire démontrable.

Question du jour

CAN WE SHOW ONE SPACESORTIUM?

C’est la journée où ORBIT doit cesser de ressembler à six projets.

LE SCÉNARIO INTÉGRÉ

La démonstration peut suivre :

1. IDENTITÉ

Un utilisateur entre dans SPACESORTIUM.

2. PROFIL

Son profil est disponible dans Social Core.

3. NATION / TERRITOIRE

Il explore une Nation ou un territoire.

4. DONNÉES

Il accède aux institutions, événements et indicateurs.

5. INTELLIGENCE

Natiometric AI analyse ou synthétise des données.

6. OBSERVATION

Natioscope visualise les résultats.

7. PARTICIPATION

L’utilisateur effectue une contribution Citizen.

8. INFRASTRUCTURE

L’ensemble est authentifié, enregistré, journalisé et observable.

Répétitions

Je recommande :

Demo Rehearsal 1

fonctionnelle.

Demo Rehearsal 2

chronométrée.

Demo Rehearsal 3

avec simulation d’un incident.

Exemple :

une API devient indisponible.

L’équipe doit savoir comment poursuivre la démonstration ou restaurer le service.

Livrables J6

L6.1 — Integrated Demo v1

L6.2 — Demo Script

L6.3 — Final Architecture

L6.4 — Final Data Flow

L6.5 — Presentation Draft

L6.6 — Backup Demo Plan

GATE J6 — DEMO READY

Critères :

un parcours complet fonctionne ;
les responsabilités sont claires ;
les limites sont connues ;
un plan B existe.

J7 — ORBIT DAY

Finalité

Finaliser, démontrer, évaluer et décider de la suite.

Ce n’est pas uniquement la « journée des prix ».

C’est la journée où sont prises les premières décisions de continuité post-ORBIT.

MATIN — FINAL CONTROL

Code Freeze

Heure officielle.

Après cette heure :

seules les corrections critiques sont autorisées.

Final Security Check

Final Deployment Check

Backup Verification

Contribution Records

Chaque participant confirme ses contributions principales.

PRÉSENTATION DES ÉQUIPES

Chaque présentation doit couvrir :

1. Problème

2. Solution

3. Architecture

4. Fonctionnalités

5. Démonstration

6. Intégration

7. Sécurité

8. Limites

9. Contributions individuelles

10. Next Steps

INTEGRATED ORBIT DEMO

Après les démonstrations des missions :

UNE DÉMONSTRATION GLOBALE DES SIX COMPOSANTES

C’est le moment symbolique central de l’événement.

Il doit montrer que :

6 MISSIONS → 1 SYSTEM

ÉVALUATION

Deux évaluations parallèles.

PROJECT SCORE

Qualité de la mission.

BUILDER SCORE

Qualité individuelle de la contribution.

RECONNAISSANCE

Distinctions possibles :

ORBITAL TEAM OF THE YEAR

SPACESORTIUM INTEGRATION AWARD

ENGINEERING AWARD

NATIOMETRIC AI AWARD

INNOVATION AWARD

SPACESORTIUM BUILDER AWARD

ORBIT CONTINUITY REVIEW

Avant la clôture, le Comité technique classe les composants :

ARCHIVE

CONTINUE

REWORK

INTEGRATE

INDUSTRIALIZE

Et les talents :

FOLLOW-UP

BUILDER CANDIDATE

BUILDER

RECRUITMENT REVIEW

INTEGRATION MISSION

selon les règles applicables.

GATE J7 — ORBIT COMPLETE

L’événement est considéré comme techniquement achevé lorsque :

• les livrables sont remis ;

• le code est centralisé ;

• la documentation existe ;

• les contributions sont tracées ;

• les évaluations sont enregistrées ;

• les composants prioritaires sont identifiés ;

• les suites ont un propriétaire.

Le Hackathon ne doit jamais se terminer sans responsable de l’après-Hackathon.

7. TABLEAU DE PILOTAGE QUOTIDIEN

Je recommande un tableau central unique :

Avec :

🟢 READY

🟠 AT RISK

🔴 BLOCKED

Aucun statut « vert » ne doit être attribué sur simple déclaration : une preuve doit exister.

8. RÈGLE DES BLOCAGES

Tout blocage de plus de 60 minutes sur un élément critique doit être remonté.

Processus :

Developer → Team Lead → Integration Lead / Mentor → Technical Director

Le principe est :

NO SILENT BLOCKERS

Une équipe ne doit jamais perdre quatre heures sur un problème que le groupe pourrait résoudre en vingt minutes.

9. RÈGLE DE DÉCISION TECHNIQUE

En cas de désaccord :

faits → contraintes → options → risques → décision → documentation.

En dernier ressort :

le Technical Director arbitre.

La règle principale reste :

En cas de conflit entre une fonctionnalité locale et l’intégration globale, l’intégration globale prime.

10. SÉCURITÉ OPÉRATIONNELLE

Pendant les sept jours :

Tout incident de sécurité est prioritaire.

Le Security Lead peut demander :

• suspension d’un compte ;

• rotation d’un secret ;

• fermeture d’un endpoint ;

• interruption d’un test ;

• isolement d’un environnement.

Une mesure de sécurité peut temporairement primer sur un objectif de démonstration.

11. MENTORAT

Le mentor ne doit pas devenir un développeur supplémentaire.

Sa fonction est :

challenger → orienter → débloquer → transmettre → évaluer.

Je recommande des créneaux fixes plutôt que des interruptions permanentes.

12. DISCIPLINE DE DOCUMENTATION

La documentation doit être produite pendant la construction.

Pas le dernier soir.

Chaque journée se termine par une mise à jour minimale :

README
architecture
API
known issues
decisions
progress.

13. DEFINITION OF DONE ORBIT

Une contribution n’est pas « Done » lorsqu’elle compile.

Elle est « Done » lorsque :

elle fonctionne ;
elle est testée ;
elle est documentée ;
elle est démontrable ;
elle respecte les conventions ;
elle ne compromet pas la sécurité ;
elle peut être comprise par une autre équipe ;
son niveau d’intégration est connu.

14. LES SEPT GATES OPÉRATIONNELS

Nous obtenons finalement :

G0 — READY TO BUILD

G1 — ARCHITECTURE READY

G2 — CORE WORKS

G3 — CONNECTED

G4 — SYSTEM CONNECTED

G5 — STABLE & DOCUMENTED

G6 — DEMO READY

G7 — ORBIT COMPLETE

C’est, à mon sens, une évolution importante du dispositif : chaque jour se termine désormais par une condition vérifiable de passage, et non simplement par le changement de date.

15. LE RYTHME GLOBAL DES SEPT JOURS

Nous pouvons le résumer ainsi :

J0 — PREPARE

↓

J1 — UNDERSTAND

↓

J2 — BUILD

↓

J3 — CONNECT

↓

J4 — INTEGRATE

↓

J5 — SECURE

↓

J6 — DEMONSTRATE

↓

J7 — ORBIT

CONCLUSION

Le SPACESORTIUM ORBIT HACKATHON™ ne doit pas être conduit comme un événement dans lequel trente participants reçoivent un sujet puis disparaissent pendant plusieurs jours pour réapparaître devant un jury.

Il doit fonctionner comme une organisation d’ingénierie temporaire.

Trente talents.

Six équipes.

Une architecture.

Des standards communs.

Une cadence commune.

Des points d’intégration obligatoires.

Des contrôles de qualité.

Une démonstration collective.

Et une continuité organisée après l’événement.

La réussite du Runbook peut être résumée par une seule transformation :

J0 : 30 INDIVIDUS

vers

J7 : 1 SYSTÈME + 1 COMMUNAUTÉ + DES COMPOSANTS À POURSUIVRE

SPACESORTIUM ORBIT HACKATHON™

ORBIT 2026 — RUNBOOK OPÉRATIONNEL

UNDERSTAND → BUILD → CONNECT → INTEGRATE → SECURE → DEMONSTRATE → ORBIT

BUILD THE INFRASTRUCTURE.
INTEGRATE THE FUTURE.
JOIN THE MISSION.