SPACESORTIUM ORBIT HACKATHON™

ORBIT TEAM DESIGN FRAMEWORK

Référentiel de constitution, d’équilibrage et d’affectation des équipes

Première édition — 2026
Version 0.1 — Talent & Team Engineering Framework

30 TALENTS · 6 TEAMS · 6 MISSIONS · 1 SYSTEM

PRÉAMBULE

Le SPACESORTIUM ORBIT HACKATHON™ repose sur trente talents organisés en six équipes d’environ cinq participants.

La performance du dispositif ne dépend cependant pas uniquement du niveau individuel des personnes sélectionnées.

Une équipe composée de cinq excellents développeurs backend peut se révéler moins efficace qu’une équipe réunissant :

software + architecture + data + infrastructure + produit + intégration + leadership.

La constitution des équipes doit donc être considérée comme une véritable opération de Team Engineering.

Le présent référentiel définit une méthode permettant de transformer :

30 TALENTS INDIVIDUELS

en

6 ÉQUIPES COMPLÉMENTAIRES

capables de travailler séparément tout en contribuant à un même système SPACESORTIUM™.

1. OBJECTIF DU FRAMEWORK

Le dispositif doit permettre de répondre à cinq questions.

1. De quelles compétences chaque mission a-t-elle réellement besoin ?

2. Quel est le profil multidimensionnel de chaque candidat ?

3. Quelles combinaisons de cinq personnes produisent une équipe fonctionnelle ?

4. Comment éviter la concentration excessive des compétences rares ?

5. Comment maximiser à la fois la performance des missions et l’intégration globale ?

L’objectif n’est donc pas de produire :

la meilleure équipe possible

puis cinq équipes restantes.

L’objectif est de produire :

SIX ÉQUIPES VIABLES ET ÉQUILIBRÉES.

2. PRINCIPE FONDAMENTAL

COMPLEMENTARITY BEFORE CONCENTRATION

Une compétence rare ne doit pas être concentrée inutilement dans une seule équipe lorsque plusieurs missions en dépendent.

Exemple :

si ORBIT dispose de quatre bons profils Cloud, les affecter tous à DATA & INFRASTRUCTURE fragiliserait les cinq autres équipes.

La logique recherchée devient :

expertise centrale + capacité distribuée.

ORBIT 06 peut concentrer la compétence Cloud la plus forte tout en maintenant, dans les autres équipes, une capacité suffisante pour :

• consommer des services ;
• comprendre le déploiement ;
• gérer les configurations ;
• participer aux tests d’intégration.

3. L’UNITÉ DE CONCEPTION : UNE ÉQUIPE DE 5 BUILDERS

Chaque équipe doit idéalement réunir cinq personnes capables de couvrir collectivement plusieurs responsabilités.

Une structure générique pourrait être :

BUILDER 1 — SOFTWARE / ARCHITECTURE

Développement principal, architecture, qualité technique.

BUILDER 2 — DOMAIN SPECIALIST

AI, Data, Digital Twin, Social, Citizen ou infrastructure selon la mission.

BUILDER 3 — DATA / INTEGRATION

Modèle de données, API, contrats, intégration interéquipes.

BUILDER 4 — PRODUCT / UX

Usage, parcours, produit, interface et valeur fonctionnelle.

BUILDER 5 — DELIVERY / QUALITY / LEADERSHIP

Coordination, tests, documentation, fiabilité et suivi.

Il ne s’agit pas de cinq postes rigides.

Chaque Builder pourra couvrir plusieurs fonctions.

4. LE MODÈLE « T-SHAPED BUILDER »

Les meilleurs profils ORBIT ne doivent pas nécessairement être hyperspécialisés.

Nous recherchons des profils en T :

PROFONDEUR

Une ou deux compétences fortes.

LARGEUR

Capacité à comprendre plusieurs domaines voisins.

Exemple :

AI Engineer — N4
Data — N3
Software — N3
Cloud — N2
Product — N1

Ce profil peut être plus utile à ORBIT qu’un spécialiste N5 incapable de travailler en dehors de son périmètre.

5. LES DIX DIMENSIONS DE BASE

Pour la première édition, je recommande d’utiliser dix axes communs.

On pourrait ajouter une onzième dimension :

INT — Integration

car elle est tellement centrale à ORBIT qu’elle mérite probablement d’être évaluée séparément.

6. ÉCHELLE DE COMPÉTENCE

Nous réutilisons le référentiel BUILDERS :

N0 — Initiation

N1 — Débutant

N2 — Junior opérationnel

N3 — Autonome confirmé

N4 — Avancé

N5 — Expert

N6 — Principal / stratégique

Chaque candidat obtient donc un Skill Vector.

Exemple :

Candidate A

SWE N4

ARC N3

AI N2

DATA N3

CLD N2

SEC N1

UX N1

PRD N2

DOC N3

LEAD N3

INT N4

7. LE PROFIL ORBIT DU CANDIDAT

Le niveau technique seul ne suffit pas.

Chaque candidat devrait posséder une fiche comprenant également :

Compétences

Niveaux N0–N6.

Expérience

Étudiant, junior, confirmé, senior, expert.

Orientation

Builder / Research / Product / Infrastructure / Leadership.

Style de travail

Autonome, collaboratif, analytique, exploratoire, structurant.

Expérience équipe

Faible / moyenne / forte.

Capacité de leadership

Niveau observé.

Capacité d’intégration

Compréhension des API, systèmes et dépendances.

Préférences de mission

1er choix, 2e choix, 3e choix.

Contraintes éventuelles

Technologies, disponibilité ou autres limites pertinentes.

8. LES COMPÉTENCES CRITIQUES COMMUNES

Quelle que soit la mission, une équipe ORBIT doit disposer collectivement d’un minimum de capacité en :

SOFTWARE

Quelqu’un doit pouvoir construire.

ARCHITECTURE

Quelqu’un doit pouvoir structurer.

INTEGRATION

Quelqu’un doit pouvoir connecter.

PRODUCT

Quelqu’un doit comprendre l’utilisateur et le besoin.

DOCUMENTATION / QA

Quelqu’un doit pouvoir expliquer, tester et transmettre.

LEADERSHIP

Quelqu’un doit pouvoir organiser le collectif.

Une équipe qui ne couvre pas l’un de ces six domaines présente un risque structurel.

9. SEUILS MINIMAUX D’ÉQUIPE

Je propose un premier seuil indicatif.

Au moins un membre de chaque équipe devrait atteindre :

Ces seuils sont collectifs.

Une personne peut en couvrir plusieurs.

10. MATRICE DES SIX MISSIONS

Les missions n’ont évidemment pas les mêmes besoins.

Échelle :

5 = critique
4 = très important
3 = important
2 = utile
1 = secondaire

Cette matrice constitue le premier Mission Skill Profile.

11. PROFIL CIBLE — ORBIT 01 SOCIAL CORE

L’équipe Social Core devrait idéalement posséder :

très fort

Software
Product
Integration

fort

UX/UI
Architecture
Security

utile

Data, Cloud et documentation.

Une configuration possible :

1 Full-stack / Architect

1 Backend / Integration

1 Frontend / UX

1 Product / Community Systems

1 QA / Security / Delivery

12. PROFIL CIBLE — ORBIT 02 NATION DIGITAL TWIN

Priorités :

Data
Architecture
Integration
Software
Geospatial / Modeling

Configuration possible :

1 Software Architect

1 Data Engineer

1 Geospatial / Digital Twin Builder

1 Backend / API Builder

1 Product / Visualization / QA

13. PROFIL CIBLE — ORBIT 03 NATIOMETRIC AI

Priorités :

AI
Data
Software
Integration
Research

Configuration possible :

1 AI Engineer

1 Data Engineer

1 Backend / API Engineer

1 Research / Natiometric Builder

1 Product / QA / Integration Builder

Il est important de ne pas constituer cette équipe uniquement avec cinq spécialistes ML.

14. PROFIL CIBLE — ORBIT 04 NATIOSCOPE

Priorités :

Data
UX/UI
Visualization
Software
Integration

Configuration possible :

1 Frontend / Visualization Builder

1 Data Engineer

1 Backend / API Builder

1 UX/Product Builder

1 Integration / QA Builder

15. PROFIL CIBLE — ORBIT 05 CITIZEN

Priorités :

Product
UX
Software
Security
Integration

Configuration possible :

1 Full-stack Builder

1 UX/UI Builder

1 Product / Citizen Services Builder

1 Backend / Security Builder

1 Integration / QA / Documentation Builder

Cette équipe devra être particulièrement attentive aux :

données personnelles, permissions, accessibilité et confiance utilisateur.

16. PROFIL CIBLE — ORBIT 06 DATA & INFRASTRUCTURE

Priorités :

Architecture
Data
Cloud
Security
Integration

Configuration possible :

1 Systems Architect

1 Cloud / DevOps Builder

1 Data / Database Engineer

1 Security / IAM Builder

1 API / Integration Engineer

Cette équipe joue un rôle transversal.

Elle doit donc également présenter une forte capacité :

à communiquer avec les cinq autres équipes.

17. LES COMPÉTENCES RARES

Avant l’affectation, ORBIT doit identifier les compétences rares.

Exemple :

Security N4+ = 2 candidats

Cloud N4+ = 3

 AI N4+ = 4

Architecture N4+ = 3

UX N4+ = 2

Data N4+ = 5

Une compétence est considérée comme critique lorsqu’elle est :

nécessaire à plusieurs équipes

et

présente chez peu de candidats.

Ces compétences doivent être réparties avec précaution.

18. PRINCIPE DE DISTRIBUTION

Nous pouvons établir une règle :

NO TEAM SHOULD OWN ALL OF A SCARCE SKILL

Sauf justification spécifique.

Exemple :

si trois Security Builders N4 existent :

• un peut rejoindre Data & Infrastructure ;
• un Citizen ;
• un Social Core ou Digital Twin.

Les autres équipes pourront bénéficier du Security Lead transversal.

19. LES EXPERTS TRANSVERSAUX

Toutes les compétences n’ont pas besoin d’être dupliquées six fois.

Certains experts peuvent intervenir comme :

ORBIT SHARED EXPERTS

par exemple :

Security Lead

API/Data Lead

Integration Lead

Cloud Architect

UX Mentor

AI / Research Mentor

Ils ne remplacent pas la compétence interne des équipes.

Ils permettent de compenser les écarts.

20. L’ÉQUILIBRE DES NIVEAUX

Les équipes ne doivent pas être composées selon :

5 seniors contre 5 juniors.

Une équipe équilibrée pourrait comprendre :

1 profil avancé/expert

2 profils autonomes

1 ou 2 profils juniors à fort potentiel

Le niveau moyen des six équipes devrait être relativement proche.

21. LEADERSHIP DISTRIBUÉ

Chaque équipe doit disposer d’au moins un participant capable de :

• organiser ;
• communiquer ;
• arbitrer ;
• identifier les blocages ;
• maintenir la cohésion.

Mais les six meilleurs leaders ne doivent pas être concentrés dans deux équipes.

Le Leadership Score fait donc partie des contraintes d’équilibrage.

22. LA VARIABLE « INTÉGRATION »

Je recommande de créer un score spécifique :

INTEGRATION READINESS

de 0 à 5.

Il mesure :

0

Ne connaît pas les concepts d’intégration.

1

Comprend les principes.

2

A déjà consommé une API.

3

A conçu ou exposé des API.

4

A travaillé sur des systèmes multi-services.

5

A déjà piloté des architectures distribuées ou multiéquipes.

Chaque équipe devrait posséder :

au moins un profil INT 4+

ou deux profils INT 3.

23. LA VARIABLE « BUILDER MINDSET »

Au-delà des compétences techniques, ORBIT doit évaluer :

curiosité
fiabilité
collaboration
initiative
humilité technique
documentation
apprentissage.

Je proposerais un :

BUILDER MINDSET SCORE — 0 à 5

Ce score ne doit pas devenir psychométrique.

Il représente uniquement une synthèse d’éléments observables pendant la sélection.

24. LES PRÉFÉRENCES DES CANDIDATS

La préférence du candidat compte.

Mais elle ne peut pas être le seul critère.

Chaque candidat classe :

Choice 1

Choice 2

Choice 3

L’objectif est de respecter autant que possible les préférences sans compromettre l’équilibre global.

25. SCORE DE MISSION DU CANDIDAT

Pour chaque candidat c et chaque mission m, nous pouvons calculer :

MISSION FIT SCORE

basé sur :

50 % — compétences techniques

Adéquation Skill Vector / Mission Profile.

15 % — expérience

Expérience pertinente.

10 % — intégration

Integration Readiness.

10 % — Builder Mindset

Capacité collaborative.

10 % — préférence candidat

Motivation pour la mission.

5 % — potentiel de progression

Capacité à apprendre rapidement.

26. TEAM COVERAGE SCORE

Une fois cinq candidats regroupés :

combien de compétences critiques sont réellement couvertes ?

Exemple :

Software 5/5

Architecture 4/5

AI 2/5

Data 4/5

Cloud 3/5

Security 3/5

UX 4/5

Product 4/5

Integration 5/5

Leadership 4/5

On obtient un :

TEAM COVERAGE SCORE — 0 à 100

27. TEAM BALANCE SCORE

La couverture ne suffit pas.

Une équipe pourrait posséder une excellente couverture grâce à une seule personne surchargée.

Le Balance Score mesure notamment :

• répartition des compétences ;
• dépendance à une seule personne ;
• niveaux d’expérience ;
• leadership ;
• multidisciplinarité.

28. TEAM DESIGN SCORE

Je propose finalement :

Mission Fit — 30 %

Critical Skill Coverage — 25 %

Team Balance — 15 %

Integration Capacity — 10 %

Leadership & Reliability — 10 %

Candidate Preferences — 5 %

Learning / Development Potential — 5 %

Résultat :

TEAM DESIGN SCORE / 100

29. CONTRAINTES DURES

Certaines règles ne peuvent pas simplement être compensées par une bonne note.

Exemples :

HARD CONSTRAINT 01

5 participants maximum par équipe.

HARD CONSTRAINT 02

Chaque candidat appartient à une seule équipe.

HARD CONSTRAINT 03

Chaque équipe possède au moins un Software Builder N3+.

HARD CONSTRAINT 04

Chaque équipe possède une capacité Integration N3+.

HARD CONSTRAINT 05

Chaque équipe possède une personne capable d’assurer le leadership opérationnel.

HARD CONSTRAINT 06

Aucune mission critique ne doit rester sans compétence principale correspondant à sa nature.

30. CONTRAINTES SOUPLES

Exemples :

• préférence mission ;
• équilibre juniors/seniors ;
• UX dans chaque équipe ;
• dispersion des profils rares ;
• diversité des expériences ;
• familiarité avec la stack retenue.

Une Soft Constraint peut être violée si l’équilibre global l’exige.

31. PROCESSUS DE CONSTITUTION

Je propose sept étapes.

STEP 1 — PROFILE

Évaluer les 30 Skill Vectors.

STEP 2 — MAP

Comparer les profils aux six Mission Profiles.

STEP 3 — PROTECT RARE SKILLS

Identifier les compétences rares.

STEP 4 — PLACE ANCHORS

Placer les profils structurants.

Exemples :

AI Lead → ORBIT 03.

Cloud Architect → ORBIT 06.

Digital Twin expert → ORBIT 02.

STEP 5 — COMPLETE

Compléter chaque équipe avec des compétences complémentaires.

STEP 6 — BALANCE

Comparer les six Team Design Scores.

STEP 7 — HUMAN REVIEW

Revue finale par le Comité de constitution.

32. LES « ANCHOR BUILDERS »

Chaque mission peut disposer d’un :

ANCHOR BUILDER

Profil particulièrement aligné avec le cœur de la mission.

Il sert de point d’ancrage à la composition de l’équipe.

Mais l’Anchor Builder n’est pas automatiquement :

Team Lead

ni nécessairement :

le profil le plus senior.

33. L’ALGORITHME D’AFFECTATION

À terme, le framework peut devenir logiciel.

Entrées :

30 Candidate Profiles

6 Mission Profiles

Skill Levels

Preferences

 Scarcity Scores Constraints

Traitement :

Calculate Mission Fit

Generate feasible teams

Optimize global balance

Penalize skill concentration

 Reward complementary coverage

Check hard constraints

Produce candidate solutions

Sortie :

Team Configuration A

Team Configuration B

Team Configuration C

Le Comité humain choisit ensuite la configuration finale.

34. L’ALGORITHME NE DÉCIDE PAS SEUL

C’est un principe essentiel.

L’outil peut optimiser ce qui est quantifiable.

Il ne perçoit pas nécessairement :

• deux personnes qui travaillent mal ensemble ;
• une dynamique de leadership ;
• la maturité humaine ;
• une motivation exceptionnelle ;
• une capacité de transmission ;
• un profil atypique.

La règle sera donc :

ALGORITHM PROPOSES. HUMANS DECIDE.

35. LE COMITÉ TEAM DESIGN

Je recommande un comité restreint composé de :

ORBIT Director

Technical Director

BUILDERS Talent Lead

Integration Lead

éventuellement un représentant RH / People

Ils valident la configuration finale.

36. TEST DE ROBUSTESSE DES ÉQUIPES

Avant validation, le comité doit poser plusieurs questions.

Que se passe-t-il si le meilleur développeur de cette équipe est absent ?

L’équipe peut-elle encore avancer ?

Qui comprend l’intégration ?

Qui comprend l’utilisateur ?

Qui peut documenter ?

Qui peut présenter ?

Qui peut arbitrer techniquement ?

Existe-t-il une dépendance excessive à une seule personne ?

Une bonne équipe doit survivre à une difficulté.

37. REDUNDANCY MINIMUM

Pour les compétences critiques, il est préférable d’éviter :

single point of human failure

Par exemple, si une seule personne comprend le backend de toute l’équipe, celle-ci est fragile.

Les connaissances fondamentales doivent être partagées par au moins deux personnes lorsque possible.

38. TEAM RISK SCORE

Chaque équipe devrait également recevoir un score de risque.

Facteurs :

• compétence critique absente ;
• trop forte dépendance à un expert ;
• manque de leadership ;
• manque de capacité d’intégration ;
• trop faible niveau software ;
• déséquilibre senior/junior ;
• incompatibilité stack ;
• trop nombreuses compétences nouvelles simultanément.

Résultat :

LOW RISK

MODERATE

HIGH

CRITICAL

Une équipe CRITICAL doit être recomposée.

39. ÉQUILIBRE GLOBAL DE L’ORBITE

Nous devons également calculer :

ORBIT TEAM EQUITY

Mesure :

l’écart entre la meilleure et la moins bien équipée des six équipes.

Nous cherchons à réduire cet écart.

L'objectif n'est pas :

Team 1 = 96 / Team 6 = 54

mais plutôt :

Team 1 86

Team 2 84

Team 3 82

Team 4 85

Team 5 81

Team 6 84

À compétences disponibles constantes.

40. DOCUMENT DE SORTIE

Chaque équipe reçoit avant J0 une :

ORBIT TEAM CARD

contenant :

Mission

Membres

Compétences principales

Rôles initiaux

Anchor Builder

Mission Lead

Points forts

Risques

Dépendances

Équipes partenaires

41. EXEMPLE DE TEAM CARD

ORBIT 03 — NATIOMETRIC AI

Builder A
AI N5 · Data N4 · Research N3

Builder B
Data N4 · Software N3 · Integration N3

Builder C
Backend N4 · Cloud N3 · API N4

Builder D
Natiometry N4 · Research N4 · Product N2

Builder E
Product N3 · QA N3 · Documentation N4 · Leadership N3

Strengths

AI, Data, Research.

Risks

Security limited.

Mitigation

Security Lead transversal + review J3/J5.

Voilà la logique recherchée.

42. L’ÉQUIPE PEUT ÉVOLUER

La configuration initiale n’est pas nécessairement immuable.

J0 ou J1 peut révéler :

• une mauvaise affectation ;
• un besoin critique ;
• une indisponibilité ;
• une incompatibilité majeure.

Le ORBIT Director pourra exceptionnellement décider :

swap

reassignment

shared specialist support

Toute modification doit être documentée.

43. CE QU’IL FAUT ÉVITER

ERREUR 1

Constituer les équipes par affinité.

ERREUR 2

Répartir uniquement par métier.

ERREUR 3

Mettre tous les meilleurs profils dans une équipe.

ERREUR 4

Considérer les préférences comme des droits d’affectation.

ERREUR 5

Oublier produit, documentation ou UX parce que « ce sont des développeurs ».

ERREUR 6

Confondre seniorité et leadership.

ERREUR 7

Créer des équipes sans capacité d’intégration.

44. PHILOSOPHIE DU TEAM DESIGN

Une équipe ORBIT doit posséder :

DEPTH

une expertise réelle.

BREADTH

plusieurs disciplines.

BRIDGES

des personnes capables de relier les disciplines.

LEADERSHIP

la capacité d’agir collectivement.

RESILIENCE

la capacité de continuer malgré les problèmes.

45. DE 30 TALENTS À UNE ORGANISATION

La transformation recherchée est :

30 PROFILS

↓

30 SKILL VECTORS

↓

6 MISSION PROFILES

↓

6 ÉQUIPES COMPLÉMENTAIRES

↓

INTERFACES ENTRE ÉQUIPES

↓

1 ORGANISATION D’INGÉNIERIE TEMPORAIRE

↓

1 SPACESORTIUM EN CONSTRUCTION

46. INDICATEURS DE QUALITÉ DU TEAM DESIGN

Avant validation, nous devrions mesurer :

100 % des équipes avec Software N3+.

100 % avec Integration N3+.

100 % avec capacité Leadership.

100 % couvrant leurs trois compétences mission-critical.

Écart maximal raisonnable entre les Team Design Scores.

Nombre de compétences rares concentrées.

Taux de satisfaction des préférences candidats.

Nombre de Single Points of Human Failure.

47. APRÈS ORBIT

La matrice ne doit pas disparaître après les sept jours.

Elle permettra d’observer :

profil pré-ORBIT

versus

comportement réel pendant ORBIT.

Nous pourrons alors améliorer progressivement :

• le référentiel ;
• les pondérations ;
• le modèle de sélection ;
• l’algorithme d’affectation.

Chaque édition alimentera la suivante.

48. LE FUTUR ORBIT TEAM ENGINE

À terme, nous pourrions intégrer ce framework directement dans SPACESORTIUM™.

Le système pourrait disposer d’un :

ORBIT TEAM ENGINE

capable de :

• lire les profils BUILDERS ;
• récupérer leurs certifications ;
• analyser leurs contributions antérieures ;
• connaître leurs niveaux ;
• intégrer leurs préférences ;
• comparer avec les besoins d’une mission ;
• proposer plusieurs configurations optimales.

Cela dépasserait même ORBIT.

Le même moteur pourrait être utilisé ultérieurement pour :

projets, Research Labs, Integration Missions, Venture Teams et missions internationales.

CONCLUSION

La sélection d’excellents talents ne garantit pas une excellente équipe.

Et six excellentes équipes indépendantes ne garantissent pas un excellent système.

La constitution d’ORBIT doit donc être pensée simultanément à trois niveaux :

INDIVIDUAL FIT

La bonne personne.

TEAM FIT

La bonne combinaison.

SYSTEM FIT

La bonne répartition entre les six missions.

Le principe fondamental peut être résumé ainsi :

**SELECT TALENT.

DESIGN TEAMS.
BALANCE CAPABILITIES.
CONNECT MISSIONS.
BUILD ONE SYSTEM.**

La véritable unité de construction d’ORBIT n’est donc ni le candidat ni même l’équipe prise isolément.

C’est le réseau des six équipes.

SPACESORTIUM ORBIT HACKATHON™

ORBIT TEAM DESIGN FRAMEWORK

30 TALENTS → 6 COMPLEMENTARY TEAMS → 1 INTEGRATED SYSTEM

DIFFERENT TALENTS.
COMPLEMENTARY SKILLS.
SHARED MISSION.
ONE ORBIT.

Cette V0.1 crée également les fondations d’un futur composant particulièrement intéressant de SPACESORTIUM BUILDERS™ : l’ORBIT TEAM ENGINE, qui pourrait transformer le référentiel de compétences des Builders en véritable système intelligent de constitution d’équipes.