Développer une solution d’Earth Intelligence avec l’observation de la Terre et l’IA : guide du topic en deux étapes

Identifiant officiel : HORIZON-CL6-2026-03-GOVERNANCE-01-two-stage
Action : Horizon Europe Research and Innovation Actions (RIA), appel en deux étapes
Budget indicatif : 12 M€ au total ; la présentation institutionnelle indique deux projets attendus, soit environ 6 M€ par projet à titre indicatif.
Calendrier : ouverture le 12 février 2026 ; étape 1 le 15 avril 2026 ; étape 2 le 30 septembre 2026.
Statut au 21 octobre 2026 : LES DEUX ÉTAPES SONT CLÔTURÉES.

Attention à l’identifiant : ce topic en deux étapes est distinct de HORIZON-CL6-2026-03-GOVERNANCE-01, qui porte sur la continuation du partenariat SBEP. Les deux identifiants partagent un préfixe mais relèvent d’appels, de finalités et de modalités différents. Ne pas fusionner leurs fiches, budgets ou contenus.

1. Qu’est-ce que l’Earth Intelligence ?

Le topic vise des applications aval qui transforment des observations de la Terre et des jeux de données pertinents en outils d’aide à la décision pour les acteurs publics ou privés. L’objectif n’est pas simplement d’accumuler des données satellitaires ou d’entraîner un modèle d’IA : il faut produire des démonstrateurs utiles à des cas d’usage concrets, apporter des éléments de preuve pour les décisions et montrer comment les solutions peuvent être testées puis reprises à plus grande échelle.

Les exemples officiels comprennent les risques liés à la météo et au climat, les aléas environnementaux et le reporting sur la biodiversité. Le topic vise notamment la préparation, la résilience, la durabilité, la compétitivité, la prise en compte de la biodiversité et la neutralité climatique dans les opérations, la planification et les politiques publiques.

Une proposition doit donc partir d’un utilisateur et d’une décision réelle : quelle décision doit être améliorée, par qui, à quelle échelle et avec quel délai ? Le choix des données, du modèle d’IA et de l’interface doit découler de cette question. Un démonstrateur techniquement impressionnant mais sans utilisateur identifié ni processus de décision défini risque de rester une preuve de concept sans adoption.

2. Les briques de données à articuler

Le texte officiel attend un usage large et intensif des observations de la Terre et des jeux de données pertinents. Il cite notamment les sorties de Copernicus, les satellites météorologiques européens opérationnels, les systèmes in situ — y compris les infrastructures de recherche européennes — et les données socio-économiques et d’impact.

Le dossier doit expliquer ce que chaque source apporte, comment les jeux de données seront combinés, leur résolution spatiale et temporelle, leur couverture, leurs limites et leurs conditions de réutilisation. Les données socio-économiques ne sont pas un ajout décoratif : elles peuvent aider à traduire un signal environnemental en exposition, vulnérabilité, coût, impact ou décision concrète.

Exemple illustratif : risque d’inondation côtière. Une solution pourrait combiner observations satellitaires, données météorologiques, topographie, infrastructures, population exposée et données de vulnérabilité pour produire des informations utilisables par une autorité territoriale. La proposition devrait définir la décision soutenue, la fréquence de mise à jour, la performance attendue, les erreurs acceptables, les modalités de validation et les limites d’utilisation. Cet exemple n’est pas une exigence spécifique du topic, mais illustre la logique d’intégration attendue.

Exemple illustratif : biodiversité. Un démonstrateur peut relier des observations environnementales à des indicateurs pertinents pour le suivi ou le reporting. Il doit préciser comment les données sont validées, comment l’incertitude est représentée et comment éviter que des différences de résolution ou de couverture conduisent à des conclusions trompeuses.

3. Concevoir un cas d’usage utile, pas seulement un modèle

Chaque cas d’usage devrait être documenté dans une fiche courte comportant :

1. Utilisateur cible : administration, gestionnaire d’infrastructure, opérateur, entreprise ou autre acteur clairement identifié.
2. Décision à améliorer : planification, alerte, allocation de ressources, évaluation du risque, suivi de la biodiversité ou autre usage précis.
3. État de référence : méthode actuelle, limites, coûts, délai ou manque d’information.
4. Données nécessaires : observations de la Terre, données in situ, données socio-économiques et variables contextuelles.
5. Méthode : modèle d’IA, approche de fusion de données, chaîne de traitement et mécanisme d’explication.
6. Validation : jeux de référence, tests hors échantillon, comparaison avec la pratique existante, tests dans des conditions variées et analyse des erreurs.
7. Adoption : intégration dans les procédures du destinataire, formation, exigences d’exploitation, coûts et responsabilités après le projet.

Il faut limiter le nombre de cas d’usage à ceux que le consortium peut réellement démontrer. Une proposition qui promet de couvrir tous les risques environnementaux, tous les pays et tous les utilisateurs avec une seule architecture peut manquer de profondeur de validation. Un périmètre ciblé, avec une trajectoire d’extension crédible, est souvent plus démontrable.

4. Co-conception avec les utilisateurs

Le topic demande une approche de co-conception adaptée aux utilisateurs. Cela signifie que les utilisateurs contribuent à la définition des besoins, à la sélection des cas d’usage, à l’interprétation des résultats et à la validation. Une lettre de soutien ne remplace pas cette participation.

La co-conception doit laisser des traces : ateliers de définition des besoins, spécifications validées, critères de succès convenus, essais avec les utilisateurs, journal des retours et modifications apportées. Elle doit aussi gérer les tensions entre les besoins : une carte utile à un analyste national n’a pas forcément la résolution, le délai ou le niveau d’explication requis par un opérateur local.

Les utilisateurs doivent pouvoir comprendre les limites de la solution. Pour les décisions à enjeu, le système doit indiquer le niveau d’incertitude, les conditions où il fonctionne moins bien et les cas où l’expertise humaine reste nécessaire.

5. Explicabilité, robustesse et reproductibilité

Le texte officiel insiste sur l’explicabilité, la robustesse et la reproductibilité. Il faut traiter ces notions comme des propriétés à tester, pas comme des adjectifs dans le résumé.

• Explicabilité : documenter quelles données ou variables influencent le résultat, quelle interprétation peut être donnée et ce que le modèle ne permet pas de conclure.
• Robustesse : tester le comportement avec des données manquantes, des changements de capteurs, des saisons ou territoires différents, des événements extrêmes et des décalages entre les données d’entraînement et celles d’utilisation.
• Reproductibilité : versionner les données, le code, les paramètres et les modèles ; documenter les étapes de traitement ; permettre de reproduire les résultats lorsque les droits et conditions d’accès le permettent.
• Validation : comparer les résultats avec des références indépendantes et des pratiques existantes ; quantifier les erreurs ; préciser les conditions dans lesquelles le produit peut être utilisé.

Les indicateurs de performance doivent correspondre à la décision. Une bonne précision moyenne peut masquer des erreurs critiques pour un groupe, une région ou un type d’événement. Le dossier doit donc examiner les erreurs selon les contextes pertinents et expliquer les compromis retenus.

6. Écosystème technique européen et complémentarités

Les propositions doivent s’appuyer sur les progrès récents de l’IA appliquée aux observations de la Terre, ainsi que sur les jumeaux numériques, les développements de Destination Earth et les moyens disponibles via EuroHPC et les AI Factories européennes, selon ce qui est pertinent pour le cas d’usage.

La proposition doit expliquer ce qu’elle réutilise, ce qu’elle développe et pourquoi. Une simple mention de Copernicus, Destination Earth ou d’une infrastructure HPC ne suffit pas : préciser les données, services, modèles ou capacités réellement utilisés, et les dépendances associées.

Le topic fait partie de l’initiative EC-ESA Earth System Science. Les projets doivent prévoir une collaboration avec les projets liés au programme FuturEO de l’ESA et affecter des moyens suffisants à cette coordination. Il faut identifier les interactions attendues, les échanges techniques, les responsabilités et le budget-temps associé, plutôt que d’ajouter une phrase générale sur la coopération.

Le texte encourage également l’identification de start-ups et de scale-ups et le développement de modèles économiques et de débouchés, potentiellement en coopération avec le projet lié au topic GOVERNANCE-07. La valorisation doit rester crédible : qui paiera ou adoptera la solution, pour quel service, selon quel modèle et avec quelles contraintes d’achat ou d’intégration ?

7. Du démonstrateur à l’adoption et au déploiement

La proposition doit convaincre qu’elle pourra tester et valider le produit et décrire une trajectoire de reprise et de montée en échelle à l’échelle nationale ou régionale, y compris au-delà de l’Union lorsque pertinent.

Une feuille de route de déploiement peut distinguer : prototype, validation technique, test avec utilisateur, démonstration en conditions réelles, intégration dans le processus métier, puis réplication dans d’autres territoires. Chaque étape doit avoir des critères de passage et une décision explicite. La diffusion du code ou la publication d’un article ne garantit pas à elle seule l’adoption.

Le plan doit traiter les coûts récurrents : accès aux données, calcul, maintenance du modèle, mise à jour des données, cybersécurité, support aux utilisateurs et évolution réglementaire ou opérationnelle. Il doit aussi préciser qui maintiendra le service après la fin de la subvention et quelles ressources rendront cela possible.

8. Le consortium à constituer

Les rôles utiles incluent généralement :

• expertise en observation de la Terre et traitement des données ;
• IA, modélisation et ingénierie logicielle ;
• sciences environnementales correspondant au cas d’usage ;
• données in situ, socio-économiques et d’impact ;
• utilisateurs publics ou privés capables de co-concevoir et tester la solution ;
• spécialistes de validation, de qualité des données, d’incertitude et de reproductibilité ;
• acteurs de valorisation, start-ups ou scale-ups lorsque la trajectoire commerciale est pertinente.

Il n’existe pas de consortium universel. Sa composition doit être justifiée par les cas d’usage et les ressources nécessaires. Un partenaire ne doit pas être inclus uniquement pour afficher une compétence : il faut préciser les tâches, livrables, données, sites de test ou utilisateurs qu’il apporte.

10. Erreurs fréquentes

1. Confondre l’accès aux données Copernicus avec une solution d’Earth Intelligence achevée.
2. Décrire l’IA sans expliquer la décision que le résultat améliorera.
3. Promettre la robustesse sans tests hors échantillon ni analyse des erreurs.
4. Utiliser les données socio-économiques sans justifier leur qualité ou leur pertinence.
5. Traiter la co-conception comme une consultation ponctuelle.
6. Ignorer l’incertitude ou les limites d’usage.
7. Sous-estimer les ressources de coordination EC-ESA et FuturEO.
8. Ne pas prévoir la maintenance, les coûts récurrents ou l’adoption par les utilisateurs.
9. Confondre ce topic avec le topic SBEP single-stage portant le même numéro de base.

11. Check-list de préparation

Vérifier : la décision à soutenir ; les utilisateurs ; les cas d’usage ; les données EO, in situ et socio-économiques ; la méthode IA ; les critères de validation ; les tests d’explicabilité, de robustesse et de reproductibilité ; la co-conception ; l’intégration des infrastructures européennes pertinentes ; la collaboration EC-ESA/FuturEO ; la place des start-ups et scale-ups si pertinente ; le plan de déploiement ; le modèle économique ou d’adoption ; les coûts de maintenance et le responsable après-projet.

12. Statut et sources

Les deux étapes de l’appel sont clôturées : 15 avril 2026 et 30 septembre 2026. Le budget de 12 M€ est l’enveloppe totale indicative du topic, pas une somme automatiquement disponible pour un candidat.

• Page officielle du topic — Horizon Europe France
• Liste officielle du Call 03 two-stage 2026
• Description officielle sur CORDIS — Commission européenne