Participation et cadre¶
Règles contraignantes¶
- Seules les sources de données et documents publiquement disponibles peuvent être utilisés.
- Les données internes, opérationnelles, sensibles ou classifiées ne font pas partie de ce challenge.
- Chaque source doit être documentée avec URL, format, chemin d’accès et date de récupération.
- Les API officielles ou téléchargements officiels doivent être clairement préférés au scraping.
- Les sorties basées sur des LLM ne sont acceptables que si les sources sous-jacentes restent visibles et traçables.
- Le focus est un MVP petit mais fonctionnel.
- Code, schéma, logique d’accès et documentation devraient rester réutilisables après le hackathon.
Obligatoire pour toutes les équipes
Les participantes et participants doivent sélectionner et documenter leurs propres sources de données publiques. Ce site fournit une orientation et des exemples, mais pas un dataset complet.
Manière de travailler attendue¶
| Sujet | Attente |
|---|---|
| Choix des données | base de sources volontairement limitée et justifiée |
| Intégration des données | étapes de mapping et de transformation traçables |
| Transparence | preuves visibles et références de source claires |
| Technologie | prototype pragmatique et maintenable plutôt que sur-ingénierie |
| Documentation | compacte mais reproductible |
Focus d’évaluation¶
La configuration exacte du jury peut varier, mais les points suivants devraient être visibles dans une bonne soumission :
| Domaine | Ce qui compte |
|---|---|
| Adéquation au problème | alignement clair avec l’analyse prospective de l’environnement et les indicateurs de résilience |
| Clarté des sources | documentation propre, origine traçable et chemins d’accès clairs |
| Qualité d’intégration | modèle de données robuste et traitement cohérent sur plusieurs sources |
| MVP fonctionnel | flux end-to-end démontrable avec interface utile |
| Valeur analytique | indicateurs compréhensibles, trend cards ou weak signals avec preuves |
| Réutilisabilité | architecture, code et documentation restent exploitables |
| Visualisation | information lisible et explicable pour des utilisateurs métier |
Recommandation pratique¶
- limiter tôt le périmètre
- stabiliser d’abord interfaces et modèle de données
- conserver les références de source dès le début
- élargir la visualisation seulement lorsque la chaîne de preuve est fiable
Ainsi, le résultat a plus de chances d’être non seulement démontrable, mais aussi exploitable analytiquement après le hackathon.