MVP et livrables¶
Objectif du hackathon¶
Le hackathon doit produire un MVP ciblé, pas une plateforme complète. On attend une solution end-to-end petite mais fonctionnelle, avec une base de sources claire, un premier modèle de données et une valeur visible pour l’analyse prospective.
Périmètre minimum du MVP¶
| Élément | Exigence minimale |
|---|---|
| Sources de données | intégrer au moins 4 sources de données publiques |
| Schéma commun | couvrir source, dataset, observation, indicator, geography, evidence, version |
| Stockage des données | première logique de stockage versionné pour données brutes ou de travail |
| Structure thématique | p. ex. PMESII-PT, PESTLE ou un cadre comparable |
| Interface utilisateur | tableau de bord ou web app avec au moins 1 carte, 1 timeline et 6 à 10 indicateurs |
| Signaux | trend cards ou weak signals avec références de source visibles |
| Documentation | brève documentation technique sur l’architecture, les sources et la reproductibilité |
Livrables utiles pour la remise¶
- prototype exécutable ou build démontrable
- sources documentées avec URL, format, chemin d’accès et date de récupération
- schéma ou modèle de données pour les entités centrales
- étapes d’ingestion et de traitement documentées
- au moins une visualisation lisible avec valeur analytique
- courte description de la logique des indicateurs et de ses limites
Ce qui doit apparaître dans le résultat¶
- la manière dont différentes sources sont mises en relation
- pourquoi les indicateurs choisis sont pertinents pour la résilience stratégique ou la détection précoce
- comment les weak signals ou changements de tendance sont justifiés
- comment sources, versions et preuves restent visibles dans le produit
Un bon cadrage de hackathon signifie souvent¶
- 4 à 6 sources propres plutôt qu’un grand nombre de sources partiellement intégrées
- 6 à 10 indicateurs bien expliqués
- 1 à 2 types de signaux ou tendances robustes
- 1 chemin clairement documenté entre récupération et visualisation
Non requis¶
- pas de modèle opérationnel complet
- pas de couverture parfaite de tous les thèmes
- pas de paysage de modèles très complexe sans valeur utilisateur visible
- pas d’automatisation exhaustive de toutes les sources possibles
Règle simple
Un bon MVP est suffisamment petit pour fonctionner de manière fiable pendant le hackathon et suffisamment solide pour être réutilisé ensuite.