SPACESORTIUM ORBIT HACKATHON™

Cahier des charges fonctionnel et technique des six missions

Première édition — 2026

Version 0.1

Préambule

Le présent cahier des charges définit le cadre fonctionnel, technique, organisationnel et opérationnel des six missions de la première édition du SPACESORTIUM ORBIT HACKATHON™.

Il complète :

• le Dossier de lancement officiel de la première édition ;

• le Règlement officiel de participation, de contribution et d’évaluation ;

• les éventuelles fiches techniques, documentations, APIs, chartes de sécurité et consignes communiquées pendant l’Opération.

Son objectif est de permettre aux participants de comprendre précisément :

• les problèmes à traiter ;

• les résultats attendus ;

• les fonctionnalités prioritaires ;

• les contraintes techniques ;

• les interfaces entre les missions ;

• les livrables à produire ;

• les critères de réussite ;

• les perspectives d’intégration dans SPACESORTIUM™.

La première édition ne vise pas à achever l’ensemble de l’infrastructure mondiale de SPACESORTIUM™. Elle vise à construire, tester et démontrer des fondations technologiques cohérentes, capables d’être poursuivies après l’Événement.

Le principe directeur est le suivant :

Chaque équipe ne construit pas un projet isolé.
Chaque équipe construit une composante d’un même système.

TITRE I — CADRE GÉNÉRAL

Article 1 — Finalité du cahier des charges

Le présent document a pour finalité de transformer les six axes de l’Opération en missions concrètes de développement.

Il sert de référence commune :

• aux équipes ;

• aux participants ;

• aux mentors ;

• aux responsables techniques ;

• aux partenaires ;

• au jury ;

• aux responsables de l’intégration post-Hackathon.

Il permet notamment d’éviter :

• la dispersion des efforts ;

• le développement de fonctionnalités sans cohérence globale ;

• la duplication des travaux ;

• la production de démonstrateurs impossibles à intégrer ;

• l’absence de documentation ;

• la confusion entre prototype, preuve de concept et produit exploitable.

Article 2 — Périmètre de la première édition

La première édition est centrée sur six fondations :

1. Social Core ;

2. Nation Digital Twin ;

3. Natiometric AI ;

4. Natioscope ;

5. Citizen ;

6. Data & Infrastructure.

Les équipes doivent privilégier :

• la cohérence ;

• la simplicité ;

• la démontrabilité ;

• l’interopérabilité ;

• la sécurité ;

• la documentation ;

• la possibilité de poursuite après l’Événement.

Article 3 — Horizon technologique

La première édition prépare progressivement l’intégration future des modules spécialisés de la Natiométrie, notamment :

• NATIOMÈTRE ;

• NATIOTRON ;

• NATIOVAULT ;

• NATIOSCOPE ;

• NATIOSPECTRE ;

• NATIOCIVIS ;

• NATIOTECH.

Ces modules ne constituent pas nécessairement des livrables autonomes de la première édition. Ils représentent l’horizon technologique vers lequel les fondations développées devront pouvoir évoluer.

Article 4 — Principe d’architecture commune

Les six missions doivent être pensées selon une architecture intégrée :

DATA & INFRASTRUCTURE
constitue le socle transversal de l’ensemble.

Sur ce socle s’appuient :

• le SOCIAL CORE ;

• le NATION DIGITAL TWIN ;

• le NATIOMETRIC AI ;

• le NATIOSCOPE ;

• le CITIZEN.

Les équipes doivent prévoir, lorsque cela est pertinent :

• des APIs ;

• des modèles de données communs ;

• des identifiants cohérents ;

• des mécanismes d’authentification ;

• des interfaces d’intégration ;

• des formats d’échange documentés.

Article 5 — Niveau attendu

Les productions peuvent prendre la forme :

• d’un prototype fonctionnel ;

• d’une preuve de concept ;

• d’un démonstrateur intégré ;

• d’un module réutilisable ;

• d’une architecture technique ;

• d’une interface exploitable ;

• d’un service déployable ;

• d’une documentation permettant la poursuite du développement.

Le niveau attendu n’est pas nécessairement celui d’un produit commercial finalisé. En revanche, chaque équipe doit démontrer que sa solution est :

• fonctionnelle sur son périmètre ;

• techniquement cohérente ;

• compréhensible ;

• documentée ;

• intégrable ;

• améliorable.

TITRE II — ARCHITECTURE FONCTIONNELLE COMMUNE

Article 6 — Principaux objets du système

Les missions peuvent s’appuyer sur un ensemble commun d’objets numériques, notamment :

• utilisateur ;

• profil ;

• organisation ;

• Nation ;

• territoire ;

• institution ;

• communauté ;

• publication ;

• interaction ;

• événement ;

• indicateur ;

• observation ;

• donnée ;

• source ;

• contribution ;

• demande citoyenne ;

• service ;

• notification ;

• rôle ;

• permission ;

• projet ;

• module ;

• ressource.

Les équipes doivent éviter de créer plusieurs modèles incompatibles pour un même objet.

Article 7 — Identifiants et relations

Lorsque cela est possible, les objets doivent disposer :

• d’un identifiant unique ;

• d’un type clairement défini ;

• d’un statut ;

• d’une date de création ;

• d’une date de mise à jour ;

• d’un propriétaire ou responsable ;

• d’un historique minimal ;

• de relations documentées avec les autres objets.

Article 8 — Interopérabilité

Les solutions développées doivent privilégier :

• des APIs documentées ;

• des formats d’échange courants ;

• des structures de données lisibles ;

• une séparation claire entre interface et logique métier ;

• des composants réutilisables ;

• des mécanismes d’import et d’export ;

• une architecture permettant l’évolution.

Article 9 — Documentation commune

Chaque équipe doit produire une documentation minimale comprenant :

• description de la solution ;

• architecture ;

• installation ;

• configuration ;

• dépendances ;

• variables d’environnement ;

• structure des données ;

• endpoints ou interfaces ;

• procédure de lancement ;

• procédure de test ;

• limites connues ;

• perspectives d’évolution.

TITRE III — MISSION ORBIT 01

SOCIAL CORE

Article 10 — Intitulé

ORBIT 01 — SOCIAL CORE

Article 11 — Finalité

La mission SOCIAL CORE consiste à concevoir les fondations sociales et relationnelles de SPACESORTIUM™.

Elle doit permettre à des utilisateurs, organisations, communautés et institutions de :

• créer une présence numérique ;

• publier des contenus ;

• interagir ;

• suivre des acteurs ;

• rejoindre des communautés ;

• échanger ;

• recevoir des notifications ;

• participer à un environnement social structuré.

Le Social Core doit être conçu comme une infrastructure réutilisable par les autres composantes de SPACESORTIUM™.

Article 12 — Problématique

Une plateforme numérique ne peut fonctionner durablement sans un socle social cohérent.

Les équipes doivent donc répondre à plusieurs questions :

• Comment représenter un utilisateur ou une organisation ?

• Comment organiser les relations entre acteurs ?

• Comment publier et consulter des contenus ?

• Comment gérer les interactions ?

• Comment structurer les communautés ?

• Comment garantir un niveau minimal de sécurité et de modération ?

• Comment permettre au Social Core de communiquer avec le jumeau numérique, le système citoyen et les outils d’intelligence artificielle ?

Article 13 — Objectifs fonctionnels

La solution devra idéalement permettre :

1. la création d’un profil ;

2. la consultation d’un profil ;

3. la publication d’un contenu ;

4. la consultation d’un fil d’actualité ;

5. l’interaction avec une publication ;

6. le suivi d’un utilisateur ou d’une organisation ;

7. la création ou l’adhésion à une communauté ;

8. la réception de notifications ;

9. la gestion de rôles ou de permissions ;

10. la modération élémentaire.

Article 14 — Fonctionnalités prioritaires

14.1 Profils

Le système pourra gérer :

• profils individuels ;

• profils d’organisations ;

• profils institutionnels ;

• nom ou identifiant public ;

• description ;

• image ou avatar ;

• domaine d’activité ;

• localisation générale ;

• liens ;

• statut ;

• préférences de visibilité.

14.2 Publications

Les utilisateurs doivent pouvoir :

• créer une publication ;

• modifier ou supprimer leurs propres publications ;

• consulter une publication ;

• associer du texte, une image ou un lien, selon le périmètre retenu ;

• identifier l’auteur ;

• afficher la date de publication ;

• signaler un contenu.

14.3 Interactions

Les interactions peuvent comprendre :

• réaction ;

• commentaire ;

• partage ;

• enregistrement ;

• suivi ;

• mention ;

• signalement.

L’équipe doit privilégier un modèle extensible permettant d’ajouter d’autres types d’interaction.

14.4 Fil d’actualité

Le fil d’actualité doit proposer une première logique de classement :

• chronologique ;

• par pertinence simple ;

• par communauté ;

• par suivi ;

• ou selon une règle clairement documentée.

Il n’est pas nécessaire de développer immédiatement un algorithme complexe de recommandation.

14.5 Communautés

Le système peut permettre :

• la création d’une communauté ;

• la définition d’un nom et d’une description ;

• l’adhésion ;

• la publication dans la communauté ;

• la gestion d’un administrateur ;

• la modération de base.

14.6 Notifications

Les notifications peuvent concerner :

• une nouvelle interaction ;

• un commentaire ;

• une mention ;

• une invitation ;

• une demande d’adhésion ;

• une publication importante ;

• une action institutionnelle ou citoyenne.

Article 15 — Périmètre minimal attendu

Le livrable minimal devra comporter :

• un modèle utilisateur ;

• un modèle publication ;

• une interface de consultation ;

• une interface de création ;

• au moins un mécanisme d’interaction ;

• un mécanisme simple de suivi ou d’abonnement ;

• une API ou une interface d’accès documentée ;

• une démonstration fonctionnelle.

Article 16 — Contraintes techniques

La solution devra prévoir :

• une séparation entre données, logique métier et interface ;

• une gestion minimale des permissions ;

• une protection contre les entrées malveillantes ;

• une traçabilité des actions importantes ;

• une structure de données compatible avec les autres missions ;

• une possibilité d’évolution vers une architecture plus large.

Article 17 — Interfaces avec les autres missions

Le Social Core devra pouvoir communiquer avec :

• NATION DIGITAL TWIN, pour relier les utilisateurs aux territoires, Nations et institutions ;

• NATIOMETRIC AI, pour analyser certains contenus ou signaux autorisés ;

• NATIOSCOPE, pour visualiser des activités ou indicateurs ;

• CITIZEN, pour gérer les interactions citoyennes ;

• DATA & INFRASTRUCTURE, pour les données, APIs, identités et services transversaux.

Article 18 — Livrables attendus

L’équipe devra remettre :

• le code source ou le dépôt autorisé ;

• la documentation d’installation ;

• le schéma des données ;

• la description des APIs ;

• une démonstration ;

• une liste des fonctionnalités réalisées ;

• une liste des fonctionnalités non réalisées ;

• les limites et perspectives.

Article 19 — Critères de réussite

La mission sera considérée comme réussie si :

• un utilisateur peut accéder à un profil ;

• une publication peut être créée et consultée ;

• une interaction peut être enregistrée ;

• les données sont persistantes ;

• les permissions principales sont respectées ;

• la solution peut être reliée aux autres missions ;

• le code est compréhensible et documenté.

TITRE IV — MISSION ORBIT 02

NATION DIGITAL TWIN

Article 20 — Intitulé

ORBIT 02 — NATION DIGITAL TWIN

Article 21 — Finalité

La mission NATION DIGITAL TWIN consiste à concevoir une première représentation numérique structurée et évolutive d’une Nation.

Cette représentation doit permettre d’organiser et de relier :

• les territoires ;

• les populations ;

• les institutions ;

• les infrastructures ;

• les événements ;

• les indicateurs ;

• les ressources ;

• les acteurs ;

• les relations entre les différents éléments.

Le jumeau numérique ne doit pas être réduit à une simple fiche descriptive. Il doit constituer une structure dynamique pouvant accueillir des données, des observations et des évolutions.

Article 22 — Problématique

Les informations relatives à une Nation sont souvent dispersées entre plusieurs systèmes.

La mission doit explorer une architecture permettant de :

• réunir les informations pertinentes ;

• relier les acteurs aux territoires ;

• représenter les institutions ;

• visualiser les infrastructures ;

• suivre les événements ;

• associer des indicateurs à des entités ;

• préparer des analyses comparatives.

Article 23 — Objectifs fonctionnels

La solution devra idéalement permettre :

1. de créer une fiche Nation ;

2. de représenter ses subdivisions territoriales ;

3. d’associer des institutions ;

4. d’associer des populations ou groupes d’acteurs ;

5. d’enregistrer des infrastructures ;

6. d’ajouter des événements ;

7. d’associer des indicateurs ;

8. de consulter les relations entre les objets ;

9. de visualiser l’évolution d’un élément ;

10. d’exposer les données par API.

Article 24 — Modèle de données minimal

Le modèle peut comprendre les entités suivantes :

• Nation ;

• territoire ;

• ville ou zone ;

• institution ;

• organisation ;

• population ;

• infrastructure ;

• événement ;

• indicateur ;

• observation ;

• source ;

• période ;

• relation.

Chaque entité doit pouvoir être identifiée et reliée aux autres.

Article 25 — Fonctionnalités prioritaires

25.1 Fiche Nation

La fiche Nation peut comprendre :

• nom ;

• identifiant ;

• description ;

• territoire ;

• population ;

• institutions principales ;

• indicateurs ;

• événements ;

• sources ;

• date de mise à jour.

25.2 Représentation territoriale

Le système peut permettre :

• l’organisation hiérarchique des territoires ;

• l’affichage d’une carte ou d’une représentation schématique ;

• l’association de données à un territoire ;

• la navigation entre niveaux territoriaux.

25.3 Institutions et acteurs

La solution doit permettre de relier :

• une institution à une Nation ;

• une institution à un territoire ;

• une organisation à une institution ;

• un utilisateur à une organisation ;

• un événement à un ou plusieurs acteurs.

25.4 Événements

Les événements peuvent être :

• politiques ;

• économiques ;

• sociaux ;

• scientifiques ;

• culturels ;

• environnementaux ;

• institutionnels ;

• technologiques.

Chaque événement peut comporter :

• un intitulé ;

• une date ou période ;

• une localisation ;

• une description ;

• des acteurs associés ;

• des sources ;

• des conséquences ou relations.

25.5 Indicateurs

Le système doit pouvoir associer un indicateur à :

• une Nation ;

• un territoire ;

• une institution ;

• une période ;

• une catégorie ;

• une source.

Article 26 — Périmètre minimal attendu

Le livrable minimal devra comporter :

• un modèle de Nation ;

• un modèle territorial ;

• un modèle institutionnel ;

• un mécanisme d’association d’indicateurs ;

• une interface de consultation ;

• au moins une visualisation ;

• une API ou un mécanisme d’échange ;

• une démonstration sur des données d’exemple.

Article 27 — Contraintes techniques

La solution devra prévoir :

• des relations explicites entre entités ;

• une gestion des dates et périodes ;

• une distinction entre données et sources ;

• une structure permettant l’ajout de nouveaux indicateurs ;

• une possibilité de comparaison entre plusieurs Nations ou territoires ;

• une gestion claire des données fictives, synthétiques ou réelles autorisées.

Article 28 — Interfaces avec les autres missions

Le Nation Digital Twin devra pouvoir communiquer avec :

• SOCIAL CORE, pour relier les profils et communautés aux territoires et institutions ;

• NATIOMETRIC AI, pour fournir des données à analyser ;

• NATIOSCOPE, pour visualiser les indicateurs ;

• CITIZEN, pour rattacher les contributions citoyennes à un territoire ou une institution ;

• DATA & INFRASTRUCTURE, pour le stockage, les APIs et la sécurité.

Article 29 — Livrables attendus

L’équipe devra remettre :

• le modèle de données ;

• le schéma des relations ;

• le code source ;

• les données d’exemple ;

• la documentation ;

• une interface de consultation ;

• une démonstration ;

• une description des extensions possibles.

Article 30 — Critères de réussite

La mission sera considérée comme réussie si :

• une Nation peut être créée et consultée ;

• ses territoires peuvent être représentés ;

• des institutions peuvent lui être associées ;

• des indicateurs peuvent être ajoutés ;

• les relations entre objets sont compréhensibles ;

• les données peuvent être exploitées par une autre mission ;

• l’architecture permet une évolution future.

TITRE V — MISSION ORBIT 03

NATIOMETRIC AI

Article 31 — Intitulé

ORBIT 03 — NATIOMETRIC AI

Article 32 — Finalité

La mission NATIOMETRIC AI consiste à développer une première couche d’intelligence artificielle capable d’assister l’exploitation, la classification, l’analyse et la restitution de données relatives aux Nations, aux territoires, aux institutions et aux indicateurs.

Cette mission ne vise pas à remplacer les référentiels scientifiques ou doctrinaux de la Natiométrie. Elle vise à construire des outils technologiques capables de :

• traiter des données ;

• organiser des informations ;

• identifier des relations ;

• produire des synthèses ;

• faciliter l’analyse ;

• préparer de futures intégrations avec les modules natiométriques spécialisés.

Article 33 — Principes directeurs

La solution devra respecter les principes suivants :

• traçabilité des données utilisées ;

• distinction entre donnée, interprétation et hypothèse ;

• vérification humaine ;

• transparence relative aux limites ;

• absence de présentation abusive d’une estimation comme un fait établi ;

• protection des données ;

• possibilité d’expliquer ou de documenter les résultats.

Article 34 — Objectifs fonctionnels

La solution devra idéalement permettre :

1. l’ingestion de données ;

2. la classification de documents ou d’informations ;

3. l’extraction d’éléments structurés ;

4. la recherche dans une base de connaissances ;

5. la comparaison de données ;

6. la détection de tendances simples ;

7. la génération de synthèses ;

8. la production de rapports ;

9. une interaction conversationnelle ;

10. la conservation des sources utilisées.

Article 35 — Fonctionnalités prioritaires

35.1 Ingestion

L’équipe peut développer un mécanisme d’import à partir :

• de textes ;

• de fichiers structurés ;

• de données tabulaires ;

• d’APIs autorisées ;

• de documents d’exemple.

35.2 Classification

La solution peut classer les informations selon :

• leur nature ;

• leur thème ;

• leur territoire ;

• leur période ;

• leur source ;

• leur niveau de fiabilité ;

• leur relation avec un indicateur.

35.3 Extraction structurée

Le système peut extraire :

• entités ;

• dates ;

• lieux ;

• institutions ;

• valeurs ;

• indicateurs ;

• événements ;

• relations ;

• mots-clés ;

• sources.

35.4 Recherche augmentée

La solution peut proposer :

• recherche sémantique ;

• recherche par mots-clés ;

• recherche par entités ;

• recherche par période ;

• recherche par territoire ;

• restitution accompagnée des sources.

35.5 Synthèse et rapport

Le système peut produire :

• une synthèse courte ;

• une fiche analytique ;

• un rapport structuré ;

• une comparaison ;

• une liste de tendances ;

• une liste de questions ouvertes ;

• une indication des données manquantes.

35.6 Interface conversationnelle

Une interface conversationnelle peut permettre de demander :

• une synthèse ;

• une comparaison ;

• une explication ;

• une recherche ;

• une visualisation ;

• une extraction ;

• une préparation de rapport.

Les réponses doivent, autant que possible, distinguer :

• les données disponibles ;

• les déductions ;

• les hypothèses ;

• les limites ;

• les sources.

Article 36 — Périmètre minimal attendu

Le livrable minimal devra comporter :

• un mécanisme d’ingestion ;

• un traitement ou une classification ;

• une base de données ou de connaissances ;

• une fonction de recherche ou d’analyse ;

• une restitution structurée ;

• une interface utilisateur ou API ;

• une documentation ;

• un exemple complet de traitement.

Article 37 — Contraintes techniques

La solution devra prévoir :

• la protection des clés et accès ;

• la traçabilité des sources ;

• la gestion des erreurs ;

• la limitation des hallucinations ;

• la possibilité de vérifier les résultats ;

• la séparation entre données sources et résultats générés ;

• une architecture permettant de remplacer ou d’améliorer le modèle d’IA.

Article 38 — Interfaces avec les autres missions

La mission NATIOMETRIC AI devra pouvoir communiquer avec :

• NATION DIGITAL TWIN, pour exploiter les données structurées ;

• NATIOSCOPE, pour produire des indicateurs ou alimenter des visualisations ;

• SOCIAL CORE, pour analyser certains contenus autorisés ;

• CITIZEN, pour traiter des contributions ou demandes ;

• DATA & INFRASTRUCTURE, pour les modèles, données, services et journaux.

Article 39 — Livrables attendus

L’équipe devra remettre :

• le code source ;

• la description du pipeline ;

• la documentation des données ;

• la description du modèle ou des services utilisés ;

• les prompts ou règles importantes, lorsqu’ils existent ;

• un exemple d’entrée ;

• un exemple de sortie ;

• les mécanismes de vérification ;

• les limites connues.

Article 40 — Critères de réussite

La mission sera considérée comme réussie si :

• des données peuvent être ingérées ;

• le système produit une sortie structurée ;

• les résultats peuvent être vérifiés ;

• les sources sont conservées ;

• les erreurs sont identifiables ;

• la solution peut être reliée à une autre mission ;

• l’équipe documente clairement les limites de son système.

TITRE VI — MISSION ORBIT 04

NATIOSCOPE

Article 41 — Intitulé

ORBIT 04 — NATIOSCOPE

Article 42 — Finalité

La mission NATIOSCOPE consiste à concevoir une première interface d’observation et de visualisation des données relatives aux Nations, aux territoires, aux institutions et aux indicateurs.

Elle doit permettre à un utilisateur de :

• comprendre une situation ;

• explorer des données ;

• comparer des entités ;

• observer des évolutions ;

• détecter des anomalies ;

• accéder à des informations détaillées ;

• relier les visualisations à leurs sources.

Article 43 — Problématique

Les données ne deviennent réellement utiles que lorsqu’elles peuvent être comprises et explorées.

La mission doit donc rechercher un équilibre entre :

• richesse de l’information ;

• simplicité de lecture ;

• précision ;

• interactivité ;

• cohérence graphique ;

• performance ;

• accessibilité.

Article 44 — Objectifs fonctionnels

La solution devra idéalement permettre :

1. l’affichage d’un tableau de bord ;

2. la sélection d’une Nation ou d’un territoire ;

3. l’affichage d’indicateurs ;

4. la visualisation d’une évolution temporelle ;

5. la comparaison de plusieurs entités ;

6. l’affichage d’une carte ou représentation territoriale ;

7. l’utilisation de filtres ;

8. l’accès aux données sources ;

9. l’affichage d’alertes ou d’anomalies ;

10. l’export ou le partage d’une vue.

Article 45 — Fonctionnalités prioritaires

45.1 Tableau de bord

Le tableau de bord peut comprendre :

• indicateurs principaux ;

• graphiques ;

• cartes ;

• tendances ;

• événements récents ;

• alertes ;

• sources ;

• date de mise à jour.

45.2 Comparaison

L’utilisateur doit pouvoir comparer :

• deux ou plusieurs Nations ;

• plusieurs territoires ;

• plusieurs périodes ;

• plusieurs indicateurs ;

• plusieurs institutions.

45.3 Évolution temporelle

La solution doit permettre de visualiser :

• une série temporelle ;

• une variation ;

• une progression ;

• une rupture ;

• une tendance ;

• une période de référence.

45.4 Cartographie

Lorsque les données le permettent, l’interface peut afficher :

• territoires ;

• points d’intérêt ;

• institutions ;

• infrastructures ;

• événements ;

• indicateurs territorialisés.

Une représentation schématique peut être utilisée si une cartographie complète n’est pas disponible.

45.5 Sources et traçabilité

Chaque indicateur important doit pouvoir être associé à :

• une source ;

• une date ;

• une unité ;

• une méthode de calcul ;

• un niveau de fiabilité ou de précision, lorsqu’il est connu.

Article 46 — Périmètre minimal attendu

Le livrable minimal devra comporter :

• un tableau de bord fonctionnel ;

• au moins un graphique ;

• au moins une fonction de filtre ;

• une vue détaillée ;

• une comparaison ou une évolution temporelle ;

• un mécanisme d’accès aux sources ;

• une documentation.

Article 47 — Contraintes techniques

La solution devra prévoir :

• une interface responsive ;

• des visualisations lisibles ;

• une gestion cohérente des unités ;

• une distinction entre données réelles, fictives et estimées ;

• une mise à jour contrôlée ;

• une architecture permettant l’ajout d’autres indicateurs.

Article 48 — Interfaces avec les autres missions

Natioscope devra pouvoir communiquer avec :

• NATION DIGITAL TWIN, pour les entités et relations ;

• NATIOMETRIC AI, pour les résultats d’analyse ;

• CITIZEN, pour certains indicateurs de participation ;

• SOCIAL CORE, pour les activités ou signaux autorisés ;

• DATA & INFRASTRUCTURE, pour les données, APIs et services.

Article 49 — Livrables attendus

L’équipe devra remettre :

• le code source ;

• les maquettes ou interfaces ;

• la structure des données affichées ;

• les composants de visualisation ;

• la documentation ;

• un jeu de données d’exemple ;

• une démonstration ;

• les perspectives d’évolution.

Article 50 — Critères de réussite

La mission sera considérée comme réussie si :

• un tableau de bord peut être consulté ;

• les indicateurs sont lisibles ;

• au moins une comparaison est possible ;

• une évolution temporelle peut être observée ;

• les filtres fonctionnent ;

• les sources sont identifiables ;

• l’interface peut être alimentée par une autre mission.

TITRE VII — MISSION ORBIT 05

CITIZEN

Article 51 — Intitulé

ORBIT 05 — CITIZEN

Article 52 — Finalité

La mission CITIZEN consiste à concevoir les premières fonctions numériques de participation, de contribution et d’interaction entre les citoyens, les organisations et les institutions.

Elle doit explorer les moyens de permettre à un utilisateur de :

• participer ;

• exprimer une opinion ;

• transmettre une contribution ;

• consulter une information ;

• accéder à un service ;

• suivre une demande ;

• interagir avec une institution ;

• contribuer à la connaissance d’un territoire.

Article 53 — Principes directeurs

La solution devra privilégier :

• la simplicité ;

• l’accessibilité ;

• la traçabilité ;

• la protection des données ;

• la clarté des procédures ;

• la neutralité des interfaces ;

• la distinction entre participation, consultation et décision ;

• la responsabilité des acteurs institutionnels.

Article 54 — Objectifs fonctionnels

La solution devra idéalement permettre :

1. la création d’un espace citoyen ;

2. la consultation d’informations ;

3. la participation à une consultation ;

4. l’envoi d’une contribution ;

5. le signalement d’un problème ;

6. la création d’une demande ;

7. le suivi de son traitement ;

8. la réception d’une réponse ;

9. l’accès à des services ;

10. la consultation de l’historique des actions.

Article 55 — Fonctionnalités prioritaires

55.1 Espace citoyen

L’espace citoyen peut comprendre :

• profil ;

• territoire de rattachement ;

• préférences ;

• historique des contributions ;

• demandes en cours ;

• notifications ;

• services disponibles.

55.2 Consultations

Le système peut permettre :

• la présentation d’une consultation ;

• la description de son objet ;

• la définition d’une période ;

• la collecte de réponses ;

• la limitation d’une participation multiple ;

• l’affichage de résultats selon les règles définies.

55.3 Contributions et signalements

L’utilisateur peut transmettre :

• une suggestion ;

• une observation ;

• un signalement ;

• une proposition ;

• une question ;

• une contribution documentaire.

Chaque contribution peut comporter :

• un objet ;

• une description ;

• une localisation ;

• une catégorie ;

• une date ;

• un statut ;

• un historique de traitement.

55.4 Services et demandes

La solution peut permettre :

• la présentation d’un service ;

• la création d’une demande ;

• l’attribution d’un numéro de suivi ;

• la gestion d’un statut ;

• la transmission à un responsable ;

• la réponse ;

• la clôture.

55.5 Transparence et suivi

L’utilisateur doit pouvoir comprendre :

• ce qui a été transmis ;

• à qui ;

• à quelle date ;

• dans quel état se trouve la demande ;

• quelle réponse a été apportée ;

• quelles étapes restent à accomplir.

Article 56 — Périmètre minimal attendu

Le livrable minimal devra comporter :

• un espace utilisateur ;

• une fonctionnalité de consultation ou de participation ;

• un mécanisme de contribution ou de signalement ;

• un suivi de statut ;

• une interface institutionnelle ou administrative minimale ;

• une documentation ;

• une démonstration.

Article 57 — Contraintes techniques

La solution devra prévoir :

• des rôles distincts entre citoyen et institution ;

• des permissions ;

• une protection des données personnelles ;

• une traçabilité des actions ;

• une gestion des statuts ;

• une possibilité de notification ;

• une distinction entre données publiques et données privées.

Article 58 — Interfaces avec les autres missions

La mission Citizen devra pouvoir communiquer avec :

• SOCIAL CORE, pour l’identité et les interactions ;

• NATION DIGITAL TWIN, pour rattacher les contributions aux territoires et institutions ;

• NATIOMETRIC AI, pour classer ou synthétiser certaines contributions autorisées ;

• NATIOSCOPE, pour visualiser des indicateurs de participation ;

• DATA & INFRASTRUCTURE, pour les données, identités et services.

Article 59 — Livrables attendus

L’équipe devra remettre :

• le code source ;

• le modèle de données ;

• les rôles et permissions ;

• les parcours utilisateurs ;

• la documentation ;

• une démonstration ;

• les règles de traitement ;

• les limites et perspectives.

Article 60 — Critères de réussite

La mission sera considérée comme réussie si :

• un utilisateur peut transmettre une contribution ;

• une institution ou un responsable peut la consulter ;

• un statut peut être attribué ;

• l’utilisateur peut suivre l’évolution de sa demande ;

• les données personnelles sont protégées ;

• les interactions sont traçables ;

• la solution peut être reliée au reste de l’écosystème.

TITRE VIII — MISSION ORBIT 06

DATA & INFRASTRUCTURE

Article 61 — Intitulé

ORBIT 06 — DATA & INFRASTRUCTURE

Article 62 — Finalité

La mission DATA & INFRASTRUCTURE constitue le socle transversal de la première édition.

Elle vise à concevoir les bases techniques permettant aux autres missions de fonctionner ensemble dans un environnement cohérent, sécurisé, documenté et évolutif.

Cette mission peut couvrir :

• architecture logicielle ;

• APIs ;

• bases de données ;

• cloud ;

• déploiement ;

• sécurité ;

• authentification ;

• interopérabilité ;

• observabilité ;

• performance ;

• sauvegarde ;

• continuité de service.

Article 63 — Problématique

Des fonctionnalités pertinentes ne peuvent être intégrées durablement sans infrastructure adaptée.

La mission doit donc répondre à plusieurs enjeux :

• comment organiser les services ?

• comment stocker et échanger les données ?

• comment gérer les accès ?

• comment déployer les composants ?

• comment surveiller le système ?

• comment protéger les secrets ?

• comment permettre l’évolution de l’architecture ?

Article 64 — Objectifs fonctionnels

La solution devra idéalement permettre :

1. la définition d’une architecture commune ;

2. la mise à disposition d’une base de données ;

3. la création d’APIs ;

4. la gestion des identités ;

5. la gestion des rôles ;

6. le déploiement d’au moins un service ;

7. la journalisation ;

8. la surveillance minimale ;

9. la gestion des erreurs ;

10. la documentation de l’environnement.

Article 65 — Fonctionnalités prioritaires

65.1 Architecture

L’équipe doit proposer :

• une architecture monolithique modulaire ou distribuée ;

• une séparation des responsabilités ;

• une stratégie de communication entre services ;

• une organisation des dépôts ;

• une gestion des configurations ;

• une stratégie de versionnement.

Le choix architectural doit être justifié par les besoins réels de la première édition.

65.2 Données

La solution doit prévoir :

• un modèle de données commun ;

• des règles de nommage ;

• des identifiants cohérents ;

• des mécanismes de validation ;

• une stratégie de migration ;

• des mécanismes d’import et d’export.

65.3 APIs

Les APIs peuvent permettre :

• la création et la consultation d’objets ;

• l’authentification ;

• la recherche ;

• la transmission de données ;

• l’accès aux indicateurs ;

• la communication entre missions.

Chaque API doit être documentée.

65.4 Authentification et autorisation

Le système doit prévoir :

• l’identification des utilisateurs ;

• la gestion des sessions ou jetons ;

• les rôles ;

• les permissions ;

• la protection des routes ;

• la révocation ou l’expiration des accès.

65.5 Déploiement

L’équipe peut mettre en place :

• un environnement de développement ;

• un environnement de démonstration ;

• une procédure de déploiement ;

• une gestion des variables d’environnement ;

• une configuration reproductible ;

• une procédure de restauration.

65.6 Observabilité

La solution doit prévoir, selon le niveau de maturité :

• journaux ;

• indicateurs de santé ;

• surveillance des erreurs ;

• suivi des performances ;

• alertes élémentaires ;

• informations de diagnostic.

Article 66 — Périmètre minimal attendu

Le livrable minimal devra comporter :

• une architecture documentée ;

• une base de données ou un mécanisme de stockage ;

• au moins une API ;

• un mécanisme d’authentification ou de contrôle d’accès ;

• un environnement de déploiement ;

• une documentation technique ;

• une procédure de lancement ;

• une démonstration de communication entre au moins deux composants.

Article 67 — Contraintes techniques

La solution devra respecter :

• la protection des secrets ;

• la séparation des environnements ;

• la limitation des accès ;

• la validation des données ;

• la gestion des erreurs ;

• la traçabilité ;

• la documentation ;

• la possibilité de reprise et d’évolution.

Article 68 — Interfaces avec les autres missions

Data & Infrastructure doit fournir un socle utilisable par :

• SOCIAL CORE ;

• NATION DIGITAL TWIN ;

• NATIOMETRIC AI ;

• NATIOSCOPE ;

• CITIZEN.

L’équipe devra travailler en coordination avec les autres groupes afin d’éviter les architectures incompatibles.

Article 69 — Livrables attendus

L’équipe devra remettre :

• un schéma d’architecture ;

• le code et les fichiers de configuration autorisés ;

• le modèle de données ;

• la documentation des APIs ;

• les procédures de déploiement ;

• les règles de sécurité ;

• les journaux ou mécanismes d’observabilité ;

• une démonstration d’intégration.

Article 70 — Critères de réussite

La mission sera considérée comme réussie si :

• les composants peuvent communiquer ;

• les données sont stockées de manière cohérente ;

• les accès sont contrôlés ;

• un service peut être lancé et déployé ;

• les erreurs principales sont identifiables ;

• la documentation permet à une autre équipe de se connecter au socle ;

• l’architecture peut évoluer.

TITRE IX — LIVRABLES COMMUNS

Article 71 — Livrables obligatoires de chaque équipe

Chaque équipe doit remettre au minimum :

1. un prototype ou démonstrateur fonctionnel ;

2. le code source ou l’accès au dépôt autorisé ;

3. une documentation d’installation ;

4. une description de l’architecture ;

5. un schéma de données ou de flux ;

6. une liste des fonctionnalités réalisées ;

7. une liste des fonctionnalités non réalisées ;

8. une présentation finale ;

9. une démonstration ;

10. une liste des limites et perspectives.

Article 72 — Livrables techniques complémentaires

Selon la mission, l’organisation peut demander :

• schéma UML ou équivalent ;

• diagramme d’architecture ;

• documentation API ;

• modèle de données ;

• maquettes UX/UI ;

• tests automatisés ;

• rapport de sécurité ;

• procédure de déploiement ;

• guide utilisateur ;

• journal des décisions techniques ;

• registre des contributions.

Article 73 — Démonstration

La démonstration doit présenter un parcours cohérent.

Elle doit éviter de se limiter à :

• des écrans statiques ;

• des fonctionnalités simulées sans indication ;

• des affirmations non vérifiables ;

• des résultats non documentés.

Lorsqu’une fonctionnalité est simulée, l’équipe doit le préciser clairement.

Article 74 — Documentation des limites

Chaque équipe doit identifier :

• les fonctionnalités incomplètes ;

• les dépendances externes ;

• les risques ;

• les problèmes connus ;

• les données manquantes ;

• les hypothèses ;

• les travaux nécessaires à la mise en production.

La reconnaissance des limites constitue un élément positif de l’évaluation lorsqu’elle est précise et honnête.

TITRE X — INTÉGRATION ENTRE LES MISSIONS

Article 75 — Principe d’intégration

Les équipes doivent rechercher une intégration minimale entre leurs productions.

Cette intégration peut prendre la forme :

• d’une API commune ;

• d’un modèle de données partagé ;

• d’un mécanisme d’authentification commun ;

• d’un échange de données ;

• d’une visualisation alimentée par une autre mission ;

• d’un parcours utilisateur transversal.

Article 76 — Scénario d’intégration recommandé

Un scénario d’intégration peut suivre le parcours suivant :

1. un utilisateur crée un profil dans le SOCIAL CORE ;

2. il est rattaché à un territoire ou une organisation dans le NATION DIGITAL TWIN ;

3. il consulte des informations ou indicateurs ;

4. le NATIOMETRIC AI traite certaines données autorisées ;

5. le NATIOSCOPE restitue les résultats ;

6. l’utilisateur transmet une contribution via CITIZEN ;

7. les données sont stockées et sécurisées par DATA & INFRASTRUCTURE.

Article 77 — Contrats d’interface

Lorsque deux équipes doivent échanger des données, elles doivent définir :

• les objets échangés ;

• les champs ;

• les formats ;

• les méthodes d’accès ;

• les règles d’authentification ;

• les erreurs possibles ;

• les exemples de requêtes et réponses ;

• les responsabilités de chaque équipe.

Article 78 — Réunions d’intégration

Des réunions techniques communes peuvent être organisées afin de :

• vérifier la compatibilité des modèles ;

• identifier les dépendances ;

• résoudre les conflits d’architecture ;

• coordonner les démonstrations ;

• préparer le scénario final.

TITRE XI — CRITÈRES TRANSVERSAUX DE QUALITÉ

Article 79 — Fonctionnalité

La solution doit répondre à un besoin clairement identifié et démontrer un fonctionnement réel sur son périmètre.

Article 80 — Qualité technique

Sont notamment appréciés :

• lisibilité du code ;

• organisation ;

• modularité ;

• cohérence ;

• gestion des erreurs ;

• tests ;

• maintenabilité ;

• justification des choix.

Article 81 — Intégrabilité

Une solution intégrable doit :

• disposer d’interfaces claires ;

• utiliser des données structurées ;

• être documentée ;

• limiter les dépendances inutiles ;

• respecter les règles communes ;

• pouvoir être reprise par une autre équipe.

Article 82 — Sécurité

Sont notamment appréciés :

• contrôle des accès ;

• protection des secrets ;

• validation des entrées ;

• protection des données ;

• absence de vulnérabilités évidentes ;

• journalisation ;

• gestion des permissions.

Article 83 — Expérience utilisateur

L’interface doit être :

• compréhensible ;

• cohérente ;

• accessible ;

• responsive lorsque cela est nécessaire ;

• adaptée au public visé ;

• suffisamment simple pour être démontrée rapidement.

Article 84 — Documentation

La documentation doit permettre à une personne extérieure à l’équipe de :

• comprendre la solution ;

• l’installer ;

• la lancer ;

• l’utiliser ;

• identifier ses limites ;

• poursuivre son développement.

TITRE XII — HORIZON DES ÉDITIONS FUTURES

Article 85 — Deuxième édition

La deuxième édition pourra être consacrée à l’intégration approfondie des modules spécialisés de la Natiométrie, notamment :

• NATIOMÈTRE ;

• NATIOTRON ;

• NATIOVAULT ;

• NATIOSCOPE ;

• NATIOSPECTRE ;

• NATIOCIVIS ;

• NATIOTECH.

Elle pourra comporter des missions dédiées :

• au calcul et à la représentation natiométrique ;

• à la simulation ;

• à la mémoire et à la traçabilité ;

• à l’observation avancée ;

• à l’analyse spectrale ;

• aux services civiques ;

• aux infrastructures technologiques spécialisées.

Article 86 — Troisième édition et industrialisation

Les éditions ultérieures pourront porter sur :

• l’intelligence civilisationnelle globale ;

• l’industrialisation des plateformes ;

• l’interopérabilité internationale ;

• les infrastructures souveraines ;

• les services destinés aux institutions ;

• les applications territoriales ;

• les jumeaux numériques avancés ;

• la recherche et l’innovation ;

• le déploiement international.

Article 87 — Principe de continuité

Les productions de la première édition doivent être conçues, autant que possible, comme des fondations pouvant être :

• améliorées ;

• réutilisées ;

• intégrées ;

• documentées ;

• transférées ;

• industrialisées.

TITRE XIII — DISPOSITIONS FINALES

Article 88 — Référentiel évolutif

Le présent cahier des charges constitue un référentiel évolutif.

L’organisation peut préciser ou ajuster :

• les fonctionnalités prioritaires ;

• les technologies recommandées ;

• les jeux de données ;

• les APIs ;

• les contraintes d’intégration ;

• les livrables ;

• les critères de démonstration.

Toute modification substantielle doit être communiquée aux équipes.

Article 89 — Liberté technologique encadrée

Les participants disposent d’une liberté de choix technologique, sous réserve :

• de la compatibilité avec les objectifs ;

• de la sécurité ;

• de la maintenabilité ;

• de la disponibilité des outils ;

• de la documentation ;

• de l’intégrabilité ;

• du respect des licences.

Le choix d’une technologie doit être justifié par son utilité et non par son caractère simplement nouveau.

Article 90 — Principe de responsabilité

Chaque équipe est responsable de la qualité, de la sécurité, de la documentation et de la présentation de sa contribution.

La contribution collective ne dispense pas les membres de pouvoir expliquer leur travail individuel.

Article 91 — Entrée en vigueur

Le présent cahier des charges entre en vigueur à compter de sa communication aux équipes sélectionnées.

Il demeure applicable pendant toute la durée de la première édition et constitue la base de référence pour l’évaluation technique et la préparation des suites de l’Opération.

Conclusion

Le SPACESORTIUM ORBIT HACKATHON™ ne repose pas sur six projets indépendants, mais sur six composantes complémentaires d’une même infrastructure.

Le SOCIAL CORE construit les relations.

Le NATION DIGITAL TWIN structure la représentation numérique des Nations.

Le NATIOMETRIC AI apporte les capacités d’analyse et d’assistance intelligente.

Le NATIOSCOPE rend les données visibles, comparables et interprétables.

Le CITIZEN ouvre les voies de participation et de contribution.

Le DATA & INFRASTRUCTURE assure la cohérence, la sécurité et l’interopérabilité de l’ensemble.

La logique de la première édition peut être résumée ainsi :

SOCIALISER LES ACTEURS.
STRUCTURER LES DONNÉES.
REPRÉSENTER LES NATIONS.
AUGMENTER L’INTELLIGENCE.
OBSERVER LES ÉVOLUTIONS.
ORGANISER LA PARTICIPATION.

Et, au-delà de la compétition :

Construire les fondations aujourd’hui pour intégrer les instruments spécialisés de la Natiométrie demain.

SPACESORTIUM ORBIT HACKATHON™
BUILD THE INFRASTRUCTURE. INTEGRATE THE FUTURE. JOIN THE MISSION.