Résumé exécutif
Le GBIF Ebbe Nielsen Challenge 2026 est un concours annuel dote de 20 000 EUR récompensant des outils innovants exploitant les données de biodiversite du réseau GBIF. La date limite de soumission est le 26 juin 2026.
Niamoto dispose déjà d'atouts solides pour ce challenge : un système d'enrichissement API générique connecté au GBIF, un export Darwin Core Archive complet, et une architecture plugin hautement extensible. Cependant, pour maximiser les chances de succes, il faudrait développer des fonctionnalités spécifiquement orientées vers les besoins du réseau GBIF.
Plusieurs pistes sont envisagées, du générateur de portail GBIF au pipeline complet avec intelligence embarquée. La direction finale reste à décider en équipe.
Le Challenge en detail
Le challenge recherche des outils innovants, nouveaux ou ameliores, qui exploitent les données de biodiversite du réseau GBIF pour faire avancér la science ouverte en soutien à la recherche et aux politiques publiques.
Soumissions acceptees
Critères d'évaluation
Pondération égale entre les 5 critères.
| Critère | Description | Implication Niamoto |
|---|---|---|
| Applicabilité | Pertinence et portée pour les communautés GBIF | Démontrer l'utilite pour differents types d'utilisateurs |
| Bénéfice GBIF | Valeur ajoutee (nouvelles données, communauté, outils) | Enrichir l'écosystème GBIF via portails web + qualité |
| Innovation | Contribution unique, significative pour le challenge | IA locale = première dans l'écosystème GBIF |
| Qualité | Fiabilite, qualité technique, documentation | Architecture plugin mature, Pydantic, tests |
| Ouverture | Code et contenu librement disponibles | Niamoto est open-source + résultats déterministes |
Analyse des gagnants (2019-2025)
Patterns des gagnants
Reduction des barrieres
Rendre GBIF accessible aux non-techniciens
Qualité des données
Améliorer la fiabilité des publications
Publication facilitee
Aider les chercheurs a publier vers GBIF
Visualisation innovante
Presenter les données de maniere nouvelle
Open-source
Tous les gagnants sont open-source
IA / LLM
Tendance forte 2024-2025
Faille strategique : IA cloud des gagnants
Les 2 derniers gagnants IA sont 100% cloud
ChatIPT (2024) et BDQEmail (2025) dépendent d'APIs cloud commerciales (OpenAI GPT-4o). Aucun ne fonctionne hors-ligne, et tous exposent les données utilisateur à des services tiers.
Problème de reproductibilité : les LLM sont non-déterministes — même input peut produire un output différent. Le modèle cloud peut changer à tout moment.
Angle d'attaque strategique pour Niamoto
C'est un différenciant fort, directement aligné avec le critère "Openness and repeatability" du jury. L'IA locale garantit la reproductibilité scientifique.
Capacités actuelles de Niamoto
Ce qui existe déjà
| Capacité | Detail |
|---|---|
| Enrichissement API | GBIF Species API, Tropicos, IPNI, WFO, iNaturalist, Endemia — via YAML |
| Export DwC Archive | DwC-A complet (occurrence.csv, meta.xml, eml.xml) compatible GBIF/IPT |
| Transformation DwC | Mapping complet Darwin Core Occurrence v1.1 |
| Plugins extensibles | 35+ transformers, auto-discovery, config YAML |
| GUI Desktop | Application Tauri + React pour la gestion des données |
| Publication statique | Génération de sites HTML avec visualisations Plotly |
Ce qui manque pour le challenge
| Lacune | Impact |
|---|---|
| Pas d'import GBIF API | Limite la démonstration d'utilisation des données GBIF |
| Pas de validation BDQ | Manque un aspect qualité très valorisé par le jury |
| Pas de publication GBIF | Le pipeline s'arrête à la génération du DwC-A (Registry API à intégrer) |
| Pas d'IA/LLM | Tendance forte des derniers gagnants |
Pistes de proposition
Plusieurs approches sont envisageables pour le challenge. Elles ne sont pas mutuellement exclusives — on peut les combiner. La direction finale reste à décider en équipe.
Générateur de portail GBIF
Coller un identifiant de dataset GBIF (DOI ou clé) → récupérer automatiquement un portail web interactif complet avec cartes, statistiques et visualisations.
Local-First Intelligence
Pipeline complet avec intelligence embarquée : détection de schéma, mapping Darwin Core automatique, validation BDQ, détection d'anomalies — tout en local, déterministe, reproductible. Différenciant fort face aux gagnants 2024-2025 (cloud/non-déterministe).
Première bibliothèque BDQ Python
Il n'existe aucune implémentation Python des tests BDQ TDWG (les seules sont en Java). Être le premier à proposer une bibliothèque Python réutilisable serait un différenciant fort. Les 12 tests Tier-1 couvrent 60% des problèmes réels.
Combinaison : pipeline complet données → portail + publication GBIF
L'approche maximale : combiner A + B + C + publication retour vers GBIF via Registry API. Boucle complète GBIF → Niamoto → portail + retour GBIF. Ambitieux mais risque de scope creep sur 15 semaines.
Note : Ces pistes se complètent. Par exemple, on peut commencer par A (générateur de portail) comme MVP visible, puis enrichir avec B (intelligence locale) et C (validation BDQ) pour la profondeur technique. La question clé : quel angle mettre en avant dans le pitch et la vidéo démo ?
Pipeline envisagé (si piste B ou D)
Pitch (exemple, piste B/D)
"Turn any biodiversity dataset into a validated, enriched, interactive web portal with species distribution models — entirely offline, with deterministic embedded intelligence. No cloud API, no data leaks, no cost. Same input, same output, every time."
Ce pitch est un exemple pour l'angle "Local-First Intelligence". Il sera adapté selon la direction retenue.
Comparaison avec les gagnants
| ChatIPT (2024) | BDQEmail (2025) | Niamoto | |
|---|---|---|---|
| Hors-ligne | ❌ | ❌ | ✔ |
| Cout API IA | Payant (OpenAI) | Payant (LLM cloud) | Gratuit |
| Données locales | ❌ | ❌ | ✔ |
| Publication web | ❌ | ❌ | ✔ |
| Extensible (plugins) | ❌ | ❌ | ✔ |
| Pipeline | Nettoyage seul | Validation seule | Import → Curation → Enrichissement → Publication |
| Reproductibilité | Depend du modèle cloud | Depend du modèle cloud | Identique à chaque exécution |
Architecture : intelligence déterministe
Le cœur de la différenciation de Niamoto : toute l'intelligence est déterministe — même entrée, même sortie, toujours. Aucune dépendance cloud, aucun LLM dans la chaîne de décision.
Couche déterministe (core)
Même entrée = Même sortie4 niveaux d'intelligence locale
ML classique (scikit-learn, aucun GPU)
Fonctionne sur n'importe quel laptop, instantané sur des datasets < 1M lignes.
Fuzzy matching + heuristiques biodiversite
Déterministe, rapide, explicable. Resolution taxonomique via cache local (~3 Go).
Modèles spécialisés biodiversité
OptionnelSpecies Distribution Modeling (SDM)
Bonus fort impactMaxent via elapid (Python, sklearn-compatible). Carte de probabilité de présence dans le portail web.
La carte SDM est un élément visuel très percutant dans une vidéo de démo — le jury comprend en un coup d'œil.
Validation BDQ — Opportunité majeure
Découverte clé
Il n'existe aucune bibliothèque Python implémentant les tests BDQ TDWG. Être le premier est un différenciant fort. Les 12 tests Tier-1 couvrent 60% des problèmes réels — 8 sur 12 ne nécessitent aucune donnée externe.
| Phase | Effort | Tests | Données externes |
|---|---|---|---|
| TIME + OTHER | 2-3 jours | ~25 tests | Aucune (pure Python) |
| SPACE | 3-5 jours | ~20 tests | Natural Earth GeoJSON (15 Mo) |
| NAME (basique) | 1-2 jours | ~10 tests | Aucune |
| NAME (avancé) | 3-5 jours | ~15 tests | GBIF Backbone (3 Go) |
| Total | ~10-15 jours | ~70 tests |
Publication sur GBIF.org
L'IPT (Integrated Publishing Toolkit) est l'outil standard de GBIF pour publier des données. Cependant, l'IPT est une webapp Java avec interface graphique — elle n'expose aucune API d'écriture, ce qui rend impossible l'automatisation de la création de ressources IPT depuis un pipeline.
Pour la publication programmatique, GBIF propose la Registry API : une API REST qui permet d'enregistrer et mettre à jour des datasets directement, sans passer par l'interface IPT. C'est cette API que nous allons intégrer à Niamoto.
Automatisation de la publication
IPT (interface manuelle)
- • Webapp Java à auto-héberger
- • Création de ressources via l'interface web
- • Pas d'API d'écriture (endpoints GET uniquement)
- • Pas intégrable dans un pipeline automatisé
GBIF Registry API (notre approche)
- • REST API standard (HTTP POST/PUT)
- • 2-3 appels = dataset publié sur GBIF
- • Entièrement automatisable depuis Niamoto
- • Environnement de test disponible (gbif-uat.org)
Flux de publication
Prérequis organisationnels
Action immédiate requise
L'organisation doit être enregistrée et endorsée sur GBIF avant de pouvoir publier. Ce processus prend des jours/semaines. À lancer dès maintenant en parallèle du développement.
| Étape | Action | Délai |
|---|---|---|
| 1 | S'inscrire sur gbif.org/become-a-publisher | Immédiat |
| 2 | Être endossé par un nœud GBIF (France ou Pacifique) | Jours à semaines |
| 3 | Demander les droits API a helpdesk@gbif.org | Quelques jours |
| 4 | Obtenir organization_key + installation_key | Avec l'étape 3 |
Implementation dans Niamoto
Un nouveau plugin déployer gbif_publisher, ~200 lignes, reutilisant l'architecture existante (déployers async SSE + CredentialService).
Pour le challenge : "Niamoto génère un DwC-A validé et le publie directement sur GBIF.org via la Registry API — publication automatisée, en une commande."
Alignement avec les critères du jury
6 arguments strategiques pour le jury
Reproductibilité
Même entrée = même résultat. Toujours. Aucune dépendance cloud, aucune boîte noire.
Souveraineté des données
Coordonnées d'especes menacées sensibles : pas d'envoi cloud (RGPD, especes protégées).
Cout zero et pérennité
Pas d'API key, pas de service tiers. L'outil fonctionnera encore dans 10 ans.
Usage terrain
Fonctionne dans les stations de recherche isolees, sur le terrain sans internet.
Accessibilité universelle
S'adapté au hardware : du Raspberry Pi (<1 Go) au workstation (8B).
Institutions publiques
Répond aux exigences de souveraineté numérique des organismes gouvernementaux.
Analyse SWOT
Forces
- Architecture plugin mature (35+ transformers)
- Enrichissement API multi-sources fonctionnel
- Export Darwin Core Archive complet
- DuckDB performant pour gros volumes
- GUI desktop existant (Tauri + React)
- Publication HTML + 5 themes + Plotly
- Philosophie local-first déjà ancrée
Faiblesses
- Pas encore d'import de données GBIF
- Interface technique (config YAML)
- Projet jeune, pas de communauté internationale
- Documentation principalement en francais
- Un seul développéur — capacité limitee
Opportunités
- IA locale = océan bleu dans l'écosystème GBIF
- Souveraineté des données = argument politique fort
- Pipeline "données brutes → site web" = angle peu exploré
- La France est competitive (BAM, 2e prix 2025)
- Modèles ML légers (scikit-learn, embeddings) matures en 2026
- Le jury valorisé les outils réutilisables
Menaces
- Délai serré (15 sem., ~15-20 jours effectifs)
- Regle de nouveaute : partie significative pour le challenge
- Risque de scope créép (IA + portail + GUI + doc)
- Concurrence invisible
- Fatigue IA possible du jury apres 2024-2025
Roadmap : 9 phases en 15 semaines
Budget : 15-20 jours de travail effectif. Checkpoint dur au 30 avril.
CSV/DwC-A → DuckDB. Plugin gbif_occurrence_loader.
Classification automatique des colonnes + suggestion mapping Darwin Core.
Implementation BDQ locale + détection d'anomalies IsolationForest.
Transformations + publication HTML automatique depuis données brutes.
Si le pipeline DOI/CSV → portail ne marche pas end-to-end, réévaluer la candidature.
GBIF API → multi-sources avec cache local DuckDB.
Species Distribution Modeling via elapid. Carte de prediction dans le portail.
Integration du workflow complet dans le GUI desktop Tauri.
README anglais, video de demo 2-3 min, Jupyter notebooks, jeux de données test.
Budget disque
| Composant | Taille | Obligatoire |
|---|---|---|
| GBIF Backbone (DuckDB) | ~3 Go | Oui |
| Embedding all-MiniLM-L6-v2 | 22 Mo | Oui |
| Frontieres pays (Natural Earth) | ~15 Mo | Oui |
| Total | ~3.1 Go |
Conclusion
Décisions à prendre en équipe
Quelle piste retenir ? — Générateur de portail GBIF (A), IA locale (B), bibliothèque BDQ (C), ou combinaison (D) ?
Quel angle pour le pitch ? — Reproductibilité scientifique, accessibilité, souveraineté des données, ou pipeline complet ?
Scope réaliste — 15 semaines, ~15-20 jours effectifs. Rester focalisé, un outil, une histoire, un moment démo.
Checkpoint 30 avril — pipeline end-to-end fonctionnel ou réévaluation.
Présentation — vidéo démo percutante, documentation anglaise, exemples reproductibles.
ROI au-dela du challenge
Même sans gagner, les fonctionnalités développées :
- Renforcent Niamoto comme plateforme de données écologiques
- Ajoutent la détection de schema et le mapping DwC intelligent
- Ouvrent Niamoto a un public international via la compatibilite GBIF
- Positionnent Niamoto dans l'écosystème GBIF (visibilite, communauté)