FR 3095277 A1 20201023 FR 1904183 A 20190419 Description Titre de l'invention : REGISTRES DISTRIBUES POUR LA GESTION DE DONNÉES MÉTÉOROLOGIQUES EN AERO- NAUTIQUE Domaine de l'invention 100011 Le document concerne en général le domaine technique du traitement de l'information. En particulier, le document décrit des systèmes et des procédés pour la gestion de données météorologiques en aéronautique, en utilisant notamment des bases de données distribuées. Technique antérieure [0002] Dans l'écosystème complexe de l'avionique, la gestion de données météorologiques (parfois notées 147x par la suite) soulève de nombreux problèmes techniques. [0003] En particulier, le partage d'informations météorologiques constitue un problème critique. Plus précisément, comment est-il possible d'optimiser le partage d'information météorologique, tout en assurant l'intégrité des informations qui sont transmises à un pilote en vol, en s'appuyant sur diverses sources de données météorologiques ? [0004] Actuellement, les informations météorologiques non-critiques sont partagées entre les pilotes d'une même compagnie. Les différentes compagnies aériennes ne souhaitent généralement pas partager leurs informations avec d'autres compagnies. Par ailleurs, dans certaines zones, il se peut que les sources de données météorologiques ne soient. pas très fiables, quand bien même il en existerait.. Enfin, il se peut que les conditions météorologiques annoncées avant le vol se révèlent différentes de celles rencontrées par le pilote. [0005] De manière générale, le partage de données entre acteurs industriels d'un même secteur est toujours un enjeu, où coopération et concurrence se mélangent. Des motivations à partager les données se heurtent souvent à des velléités de constituer un corpus privé, à des fins exclusives. Indépendamment des stratégies des acteurs industriels, sur le fond, pour l'extraction de données de valeur, il reste avantageux d'accumuler de grandes quantités de données (e.g. croisements, corrélations, apprentissage, etc). [0006] Théoriquement, afin d'améliorer cc partage de données météorologiques, il serait avantageux de s'appuyer sur une pluralité de sources fournissant des données météorologiques, lesquelles seraient ensuite partagés à plusieurs clients. [0007] En pratique, plusieurs obstacles se présentent. L'utilisation de sources de données météorologiques relevant du « monde ouvert » (e.g. Internet), ou bien d'instruments de 2 mesure appartenant. à des compagnies tierces, pose la question générale de l'intégrité des données. Comment. en effet s'assurer que les informations météorologiques transmises sont correctes ? Des données erronées - voire malveillantes - peuvent, en effet être injectées, qui retarderaient ou fausseraient inutilement les trajectoires des vols, entraîneraient des surconsommations de carburant, etc. [0008] Le document de brevet US20180074189 décrit un découpage de l'espace en voxels, puis détermine la meilleure source de données météorologiques pour chaque voxcl. chaque information météorologique se voit donc attribuer un l'indice de fiabilité. ce document n'enseigne pas la manière dont les données sont communiquées entre aéronef, et ne considère pas la provenance des données. Cette approche présente des limitations et ne résout pas les problèmes techniques évoqués précédemment. [0009] Le document de brevet EP3367137 décrit un système de partage d'informations critiques de météorologie entre plusieurs avions. Un centre au sol (intermédiaire) est chargé de gérer les demandes entre les différents avions (clients et fournisseurs). Cette solution est satisfaisante dans certaines situations mais présente des limitations au regard d'une coopération élargie. Par exemple, les exemples décrits prévoient la présence d'un intermédiaire, qui s'ajoute donc dans l'écosystème déjà complexe de l'aéronautique. Par ailleurs, le transfert d'informations ne s'effectue qu'entre avions; il ne s'appuie notamment pas sur des ressources (pourtant beaucoup plus nombreuses) issues du « monde ouvert » (i.e. au-delà du cadre règlementairc, e.g. données interne°. Le type de base de données utilisé n'est pas explicité. Seules les informations météorologiques sont considérées comme critiques. Les informations d'optimisation de vol ne sont par exemple pas considérées, or ces informations peuvent avoir une grande « valeur ». 11 existe un besoin pour des systèmes et des procédés avancés pour le partage et la gestion de données météorologiques en aéronautique. Résumé de l'invention [0010] Le document décrit des systèmes et des procédés mis en oeuvre par ordinateur pour le partage dc données météorologiques, un procédé comprenant notamment les étapes consistant à collecter des données lors de vols d'aéronefs, recevoir des données relatives à la trajectoire d'un aéronef client; en fonction de ladite trajectoire, sélectionner des données météorologiques pertinentes dans une base de données météorologique partagée comprenant les données météorologiques collectées; en réponse à une requête de l'aéronef client, communiquer les données météorologiques sélectionnées en fonction d'un mécanisme de contrôle des échanges. Des développements décrivent un mécanisme de contrôle des échanges de données météorologiques utilisant des contrats intelligents, l'utilisation de scores de confiance, des calculs de 3 corrélation entre météorologie déclarée et mesurée en vol, l'utilisation de droncs comme sondes, l'utilisation de sources ouvertes, d'apprentissage automatique, de gestion de la validité en temps et/ou en espace des données météorologiques. [0011] En résumé l'invention est un système qui permet le partage d'informations entre plusieurs types d'acteurs, qu'ils appartiennent au monde avionique/aviation (A/C pour Aircraft, ATC pour Contrôle du trafic de la navigation aérienne, Aéroport) ou bien au monde dit « ouvert » (tout type de source ouverte ou non régulée, e.g. Internet). [0012] Les informations météorologiques peuvent être stockées dans une base de données classique, cependant chaque acteur qui contribue à cette base se voit attribuer un score relatant son niveau de confiance, en fonction de la qualité de ses contributions. C'est à l'aide d'une DLT (« Dist ributed Ledger Technology ») ou « chainc de blocs » (en anglais « blockchain ») que les informations sur les contributeurs sont stockées. De plus, selon l'invention, un mécanisme de rétribution peut être mis en oeuvre pour déterminer et encourager les meilleurs contributeurs. Ces informations partagées peuvent ensuite être communiquées aux aéronefs qui sont concernés par les informations météorologiques partagées. [0013] Dans un mode de réalisation, une ou plusieurs chaînes de blocs sont utilisées pour stocker et partager les données météorologiques (en assurant donc leur qualité (e.g. horodatagc, intégrité, validation par consensus, etc). Optionnellement, le partage de ces données (e.g. transactions) est géré (ou permise ou contrôlée) par un ou plusieurs contrats intelligents (e.g. accès aux données par les utilisateurs, gestion des droits, etc.). [0014] Avantageusement, l'authenticité et l'intégrité des données manipulées sont garanties du fait de l'emploi d'une chaîne de blocs. [0015] Avantageusement, les échanges (ou contributions) peuvent être surveillés, inscrits et suivis de manière claire et transparente, de telle manière que les incitations à partager s'en trouvent renforcées. Avantageusement, le partage d'information météorologique est encouragé, par construction, en plus d'être sécurisé. [0016] Avantageusement, le réseau des contributeurs peut être étendu à des sources dites du monde ouvert », et ceci sans avoir à gérer les problèmes d'intégrité, de confiance ou de validité des données. Des données météorologiques nouvelles, complémentaires, additionnelles, récentes, ou autrement enrichies peuvent ainsi être manipulées. [0017] Avantageusement, l'invention permet d'augmenter la capture de données, et par suite la qualité des analyses qui en est dérivée (« analytics »). D'échanges sous-optimaux, l'invention permet des échanges fluides et transparents entre acteurs, dans lesquels les incitations à partager sont assainies, les partages étant rétribués et les parties étant notées de manière transparente sinon prédictible. [0018] Avantageusement, l'application de technologies d'Intelligence Artificielle (essentiellement d'apprentissage automatique) couplées au déploiement massif de la connectivité entre les aéronefs et/ou le sol permet des analyses massives et approfondies (approche dite « Big Data »), à des fins avantageuses et diverses e.g. estimation des consommations de carburant, optimisation des trajectoires, anticipation de la météorologie à traverser, amélioration de la sécurité et/ou de la sûreté des vols, etc. [0019] En intégrant d'une manière spécifique (i.e. appropriée cu égard aux problématiques métiers de l'aéronautique), les technologies relatives aux chaînes de blocs et aux contrats intelligents, les procédés et systèmes selon l'invention permettent in fine d'améliorer la sûreté aéronautique. Cette sûreté est fondamentale dans cette industrie. Les architectures aéronautiques existantes sont très fermées (il existe peu de liens existant entre systèmes, du fait de crainte de corruptions de données, d'attaques, de risques systémiques, etc) ; la solution proposée peut améliorer significativement la gestion technique de données inter-systèmes, en augmentant les surfaces d'analyse (quantité de données) et la qualité des analyses conduites. Description des figures [0020] D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la des- cription qui suit et des figures des dessins annexés dans lesquels: [0021] [fig.1] illustre le fonctionnement d'une chaîne de blocs; [0022] [fig.21 illustre un mode de réalisation de l'invention; [0023] [fig.3[ illustre un mode de réalisation de l'invention ; [0024] [fig.4[ illustre des exemples d'étapes d'un mode de réalisation du procédé selon l' invention. Description détaillée de l'invention 100251 Données météorologiques 100261 En avionique, les données météorologiques peuvent être classées en plusieurs ca- tégories : i) la météorologie dite "réglementaire" ou "normative" d'une part, ii) la météo dite "informative" ou "stratégique" et iii) la météo "radar", mesurée par des appareils embarqués). 100271 Concernant la météo dite réglementaire, les observations météorologiques et les prévisions sont intégrées dans un dossier météorologique réglementaire dit « briefing » qui est fourni au pilote avant le décollage de l'avion. Cette météo réglementaire est limitée. La forme et le format est basique (code textuel et graphiques en noir et blanc) et les données ne sont généralement valides que pour un intervalle temporel restreint (de l'ordre de trois à six heures). Cette obsolescence inévitable des données météorologiques entraîne des complications significatives et notamment certains risques pour la sûreté du vol. 100281 Concernant la météo dite "informative" ou "prévisionniste" ou "stratégique", les données de ce type sont généralement présentées sous forme de données graphiques. Elles ont la particularité de venir en complément des données réglementaires nécessaires à l'opération du vol. La météo prévisionniste ou informative a pour but de donner une information de conseil au niveau stratégique, là où ni le radar météo n'a de portée suffisante et où l'information de « briefing » n'est plus à jour. [0029] Concernant la météorologie de radar, elle est de portée limitée par les appareils de mesure (i.e. à courte distance). Elle sert directement pour le pilotage. [0030] Les données météorologiques peuvent être segmentées (avec recouvrement) ou parti- tionnées (avec recouvrement) selon différents niveaux de « qualité » ou de « service ». Selon l'invention, des sources de données tierces (à la météorologie réglementaire) peuvent être prises en compte dans la synthèse météorologique du procédé selon l'invention. Par exemple, une source de données indiquant la présence d'oiseaux migrateurs dans un secteur donné peut contribuer à améliorer la compréhension « météorologique » au sens large. Un certain nombre de données, de type stratégique et informative, différentes de celles réglementaires issues du dossier de vol, peuvent être rafraîchies et consultées en vol. en provenance de capteurs internes à l'aéronef ou accessibles par téléchargement en provenance du sol via des moyens de communications (satellite ou autre). Dans un mode de réalisation, une ou plusieurs données de type nonrèglementaire peut être requalifiée en données d'un niveau équivalent à celui des données réglementaires. [0031] La capitalisation sur des sources de type « monde ouvert » est désormais également possible. Actuellement le DATALINK du FMS permet par exemple de transmettre des informations de type Température & Vents : ces informations sont intéressantes mais un système s'appuyant en plus sur des sources ouvertes peut permettre la transmission d'information plus récentes et/ou plus complètes. En particulier, dans un mode de réalisation, les informations météorologiques traversées localement (i.e. réellement) par un aéronef (e.g. AirData, Wx Radar, etc) peuvent être transmises aux autres aéronefs proches de sa zone (ou dont ceux dont la trajectoire va présenter un ou plusieurs points d'interception avec la trajectoire de l'aéronef considéré). Et ce d'une manière sécurisée, en utilisant une ou plusieurs chaines de blocs et/ou contrats intelligents. De nombreuses sources ouvertes peuvent être utilisées, notamment des données CoCoRaHS (Community Collaborative Rai, Hall & Snow Network), des données sur les orages et la foudre (lightningmaps.org fr.blitzortung.org), etc. [0032] Validité des données météorologiques et modèles [0033] Les conditions météorologiques évoluent dans l'espace au cours du temps, de manière variable selon les phénomènes météorologiques. Ces courants d'altitude peuvent par exemple perdurer plus longtemps que des épisodes nuageux plus évanescents. Les données météorologiques peuvent donc être associées à des données 6 d'évolution (dynamique) et/ou de validité (fin, début) en espace et/ou en temps. [0034] Dans un mode de réalisation, les données d'évolution et/ou de validité associées aux données niétérologiques peuvent être des attributs des données, lesquelles sont déterminées nativement lors de leur communication, ou bien déterminées a posteriori (application de modèles). Dans un mode de réalisation, les paramètres de validité temporelle comprennent une seule date e.g. fin, expiration, péremption, date limite d'utilisation. Dans un mode de réalisation, les paramètres de validité comprennent plusieurs dates (e.g. date de début et date de fin, modulo des tolérances, etc) et/ou plusieurs informations (e.g. risque quantifié, fiabilité, intervalles de confiance, notation de la source, etc). De même, les paramètres de validité d'espace comprennent divers attributs (e.g. permanent, épisodique, transitoire, etc) sur différentes échelles d'espace (e.g. micro-cellule, cellule, zone, région, pays, continent, hémisphère ou zones de vol) [0035] Dans un mode de réalisation, les données météorologiques communiquées par les aéronefs ou drones sont associées à des dates ou des intervalles de validité en espace et/ou en temps, lesquelles sont stockées dans la base 210. [0036] Dans un mode de réalisation, les données météorologiques peuvent être manipulées par un ou plusieurs modèles météorologiques. Les modèles peuvent être un ou plusieurs modèles parmi le modèle GFS (Global Forccast System), le modèle CEPMMT (Centre européen pour les prévisions météorologiques à moyen ternie), le modèle WRF (Weather Research and Forccasting) , modèle ARPEGE (monde), le modèle ARPEGE (Action de Recherche Petite Echelle Grande Echelle), le modèle AROME (Application of Research to Operations at MEsoscale), le modèle CES (Seasonal Climate Forecast). Dans certains modes de réalisatrion, ces modèles peuvent modifier (e.g. ajouter, supprimer, substituer) les dates de validité en temps et/ou en espace. [0037] Dans un mode de réalisation, une boucle de communication ou de rétroaction (avec le régulateur, un ATC ou un organisme certifié et/ou autorisé) peut permettre de (re)qualifier l'information météorologique. Par exemple, la présence d'oiseaux migrateurs à côté d'un aéroport donné peut être « avalisée » par le régulateur approprié. [0038] « Big data » [0039] L'expression anglaise "Big data" désigne la collecte et l'analyse de données, ef- fectuées de manière massive. Ce concept est associé avec des caractéristiques de nature technique qui comprennent: le volume (e.g. grandes collections de données, même si elles sont redondantes), la variété (e.g. de nombreuses sources différentes sont utilisées), la vélocité (e.g. les données sont « fraiches » ou constamment mises à jour dans des environnements changeants ou dynamiques), attestant d'une certaine véracité (e.g. les signaux faibles qui sont noyés dans le bruit ne sont pas supprimés et peuvent par suite être détectés ou amplifiés), pour représenter in fine une certaine valeur (par 7 exemple d'utilité du point de vue technique et/ou métier i.e. business). [0040] Registres distribués ou chaînes de blocs [0041] Selon la définition donnée par Wikipédia, une chaîne de blocs (« blockchain » en anglais) ou un registre distribué (DLT pour « Distributed Ledger Technology » en anglais) est une base de données distribuée et sécurisée par des techniques cryptographiques. Les transactions échangées sont groupées en « blocs » à intervalles de temps réguliers, de manière sécurisée par cryptographie, qui forment une chaîne. Après avoir enregistré les transactions récentes, un nouveau bloc est généré et analysé. Si le bloc est valide (consensus distribué), le bloc peut être horodaté et ajouté à la chaîne de blocs. Chaque bloc est lié au précédent par une clé de hachage. Une fois ajouté à la chaîne de blocs, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l'authenticité et la sécurité du réseau. Le chainagc utilise des fonctions de hachage et des arbres de Merkle. Un arbre de hachage est constitué par un ensemble de sommes de contrôle interdépendantes. Des sommes de contrôles sont concaténécs selon une structure en arbre. Un arbre de hachage permet de pouvoir vérifier l'intégrité d'un ensemble de données sans disposer nécessairement de la totalité des données au moment de la vérification. Les enregistrements dans une chaîne de blocs sont protégés contre la falsification ou la modification par les noeuds de stockage : falsifier un bloc nécessite de falsifier l'ensemble de la chaîne, de sorte que le coût total devient prohibitif et garantit un niveau de confiance en la non-falsification de l'ensemble de la chaîne de blocs. Les transactions sont visibles dans l'ensemble du réseau (sauf élagage dit « pruning »). [0042] Le temps est un facteur important pour les chaînes de blocs (notions de broadcasting, de propagation, de latence, etc.). Le consensus distribué de l'ensemble des noeuds du réseau peut prendre un temps très variable selon les technologies utilisées. Il peut être accéléré en utilisant diverses techniques, notamment des « siclechains », lesquelles augmentent aussi les capacités de stockage. [0043] Dans le cadre du consensus distribué, une chaîne de blocs peut utiliser une validation par preuve de travail (« pro« of work »). Du point de vue mathématique, une preuve de travail est « difficile à fournir mais facile à valider ». Les systèmes de validation par preuve sont généralement asymétriques: le calcul qui est requis en contrepartie d'une demande de service est couteux pour le demandeur mais demeure facilement vérifiable par un tiers. Différentes techniques peuvent être utilisées, notamment hashcash ou un "client-puzzle". [0044] Les noeuds « mineurs » ou de « minage » sont des entités dont le rôle est d'alimenter le réseau en puissance de calcul, pour permettre la mise à jour de la base de données décentralisée. Ces mineurs peuvent être rétribués par la distribution de jetons cryptographiques (« tokens »). D'autres modes de compensation (en complément ou par sub- 8 stitution) prévoient des commissions sur les transactions. Des « mineurs » ne sont pas toujours nécessaires : dans le cas des chaînes de blocs privées par exemple, les participants à la chaîne de blocs maintiennent eux-mêmes la base de données distribuée. [0045] Une chaîne de blocs peut être publique ou privée, ou selon des gouvernances inter- médiaires, qui peuvent utiliser différentes barrières à l'entrée (validation par preuve de travail). Une chaîne de blocs « publique » fonctionne sans tiers de confiance (modèle dit « trustless »), généralement avec une validation par preuve de travail complexe (e.g. hashcash). Une chaîne de blocs publique ne définit généralement pas d'autre règle que celle du code constitué par la technologie protocolaire et logicielle qui la compose. Une chaîne de blocs « privée » comprend des noeuds participants au consensus qui sont définis à l'avance puis authentifiés. Ses règles de fonctionnement peuvent être éventuellement extrinsèques. [0046] Les chaînes de blocs peuvent être ou devenir programmables par l'emploi de « contrats intelligents » (« smart contracts » en anglais). Les contrats intelligents sont des logiciels ou protocoles informatiques qui facilitent, vérifient et exécutent la négociation ou l'exécution d'un contrat. Ils visent à émuler ou approcher la logique des clauses contractuelles (droit des contrats). Les contrats intelligents ne sont pas strictement équivalents à des accords contractuels. Ils contribuent à rendre la violation d'un accord coûteux car ils contrôlent un bien par le biais de moyens numériques. Ils peuvent prévoir - ou pas - l'intervention de tiers au contrat pour suivre son exécution (par exemple des machines ou « oracles » ou services d'oracle. Un contrat intelligent sont un code logiciel qui est stocké et est exécuté sur/par une chaîne de blocs et est déclenché par des données externes qui lui permet de modifier d'autres données, dans la chaîne de blocs ou ailleurs. [0047] L'exécution d'un contrat intelligent est prédictible/prévisible; à tout le moins le code et donc la nature des calculs ou tests effectués par ce code sont connus. Le code d'un contrat intelligent est stocké sur ou dans la chaîne de blocs ; l'exécution du contrat intelligent est effectué lors de la validation des blocs (les ressources de calcul sont distribuées, ce qui signifie que l'exécution d'un contrat intelligent est sûre en elle-même : le code du contrat intelligent est répliqué en plusieurs noeuds de l'architecture mettant en oeuvre la chaîne de blocs ; étant déterministe, les résultats des différentes exécutions doivent être identiques. Par suite, le code ainsi que l'exécution du code sont sûres. [0048] Comme pour tout programme ou code informatique, différents langages de pro- grammation sont disponibles, avec différents modèles de sécurité et de régulation (contrat-cadre régissant d'autres contrats, contrats en cascade, etc). Les formes prises par les contrats intelligents peuvent être diverses (e.g services, agents, snippets, scripts, SOA, API, add-ons, plug-ins, extensions, DLC, etc). La logique mathématique (les prises de décisions opérant sur les données) peut être celle de la logique classique, 9 floue, combinatoire, itztuitiontziste, tnoclale,propositionnelle, partielle, para-consistante, etc ou une combinaison de ces logiques. Le logiciel peut être codé en partie ou en totalité sur forme matérielle (e.g. FPGA). Un contrat intelligent peut être en totalité ou en partie en source ouverte (« open source") et/ou en source fermée (" closed source »). Dans le cas de source ouverte, le code est auditablc ou vérifiable par les parties ou les tiers. Un contrat intelligent peut combiner des parties en source ouverte (e.g. auditablcs, vérifiables, améliorables, etc) avec des parties fermées (propriétaires, secrètes, sensibles, etc). Une source fermée peut être un binaire, éventuellement obfusqué ou durci (« hardetzed »). Les techniques cryptographiques peuvent être diverses : symétrique, asymétrique, « pos(-quantum », « quantum-safe », avec utilisation de « Quantum-Key-Distribution », etc). Un contrat intelligent peut être lisible par l'homme et/ou la machine ("hutnan and/or machine readable »). [0049] Des modes de réalisation de l'invention sont décrits ci-après. Dans un mode dc réalisation, il est décrit un procédé mis en oeuvre par ordinateur pour le partage dc données météorologiques, comprenant les étapes consistant à: collecter des données météorologiques lors des vols d'une pluralité d'aéronefs, lesdites données météorologiques; recevoir des données relatives à la trajectoire d'un aéronef client; en fonction de ladite trajectoire, sélectionner des données météorologiques pertinentes dans une base de données météorologique partagée 210 comprenant les données météorologiques collectées; en réponse à une requête dc l'aéronef client, authentifié comme une partie parmi plusieurs parties participantes à une chaîne de blocs 100, communiquer les données météorologiques sélectionnées en fonction d'un mécanisme de contrôle des échanges de données météorologiques. Une partie participante à une chaine de blocs peut être associée à un ou plusieurs aéronefs (compagnie aérienne), dans certains cas à aucun appareil (station au sol). A défaut de contrats intelligents, le mécanisme de contrôle des échanges peut être implémenté dans un logiciel unique (par exemple centralisé) ou distribué en pair-à-pair (e.g. entre avions). Les données météorologiques peuvent être agrégées, au sens où les données météorologiques mesurées peuvent être celles mesurées lors d'un ou de plusieurs vols passés d'un ou de plusieurs aéronefs associés à une ou plusieurs parties prédéfinies participantes à la chaîne de blocs. Dans un mode de réalisation, le procédé comprend une étape consistant à comparer les trajectoires des avions qui sont en vol avec les données météorologiques fournies (localisation, valeurs, etc), i.e. l'intersection des données. Dans un mode de réalisation, l'étape consistant à sélectionner des données météorologiques pertinentes comprend des comparaisons en temps et en espace, notamment les étapes consistant à comparer les zones d'espace associées à la trajectoire dans des intervalles de temps compatibles avec l'intervalle de temps de validité associé aux données météorologiques. Dans un mode de réalisation, le mécanisme de contrôle des échanges de données météorologiques étant déterminé par un ou plusieurs contrats intelligents. Un contrat intelligent comprend un programme d'ordinateur stocké dans (et/ou exécuté par) ladite chainc de blocs (ou une autre chainc de blocs associée). L'utilisation de contrats intelligents sur la chainc de blocs (ou sur une chainc de blocs secondaires) garantit l'exécution sûre des programmes associés, et permet dans certaines conditions r auditabilite du code source. Dans un mode de réalisation, un ou plusieurs contrats intelligents implémentent des règles d'échanges suivant des conditions de type FRAND, soit des prix justes, raisonnables et non-discriminatoires. Dans certains modes de réalisation, les contrats intelligents sont eux-mêmes régulés (par exemple par une autorité de régulation). Dans un mode de réalisation, le procédé comprend une étape consistant à déterminer un score dc confiance associé à une partie prédéfinic participante à la chainc de blocs. Par exemple, une station au sol fournissant des données météorologiques peut participer à l'écosystème de partage, et être continûment « notée ». Dans un mode de réalisation, le score de confiance d'un aéronef est déterminé en fonction de la corrélation existante entre les données météorologiques mesurées par ledit aéronef d'une part et les données météorologiques mesurées par un autre aéronef d'autre part. Les aéronefs peuvent agir comme autant de « sondes » qui ajoutent, vérifient, mettent à jour confirment ou autrement modifient la base de données de météorologie (objet changeant par définition). Dans les zones de trafic denses, de nombreux recoupements sont donc possibles. Dans les zones peu couvertes, les aéronefs en vol fournissent de l'information météorologique rare (ce qui est toujours mieux qu'aucune information du tout). Des mécanismes de valorisation peuvent compenser ces aspects, et valoriser la fourniture de données le cas échéant. Il est implicite que les données météorologiques peuvent présenter différents intervalles de validité dans le temps et/ou dans l'espace (évanescence d'objets, déplacement de phénomènes orageux, etc). Dans un mode de réalisation, le score de confiance CS associé à un aéronef peut être diminué (par exemple proportionnellement aux écarts constatés, ou selon une fonction par exemple analytique). Dans des variantes de réalisation, le score de confiance peut être manipulé algorithmiquement, i.e. par application de règles se déroulant dans le temps. Avantageusement, ce système de notation et de suivi de la confiance, de surcroît sécurisé par l'emploi d'une chaine de blocs permet de réduire ou d'empêcher l'injection de météorologie « malicieuse ». Dans un mode de réalisation, un score de confiance peut être accompagné de différents 11 autres scores, notamment destinés à refléter un excédent ou d'un déficit dc télé-versement ou dc téléchargement de données, ou bien encore le nombre d'utilisations cumulées des jeux de données partagés, etc. Dans un mode de réalisation, une communication dc données est associée à une transaction financière. Dans un mode de réalisation, le prix des données météorologiques communiquées est fixe et prédéfini. Dans un mode de réalisation, le prix est variable et déterminé dynamiquement, par exemple par voie d'enchères, ou par cotation avec carnet d'ordres. Dans un mode de réalisation, les échanges de données sont contrôlés, par exemple capés, par application d'un ou de plusieurs seuils ou plages de seuils, notamment en fonction d'un ratio téléversement/téléchargement de données. Dans un mode de réalisation, le procédé comprend en outre une étape consistant à afficher dans le cockpit d'un aéronef un ou plusieurs scores dc confiance associés à une ou plusieurs parties associées à un ou plusieurs aéronefs. Dans certains modes de réalisation, les origines dc certaines données météorologiques peuvent être au moins partiellement affichées. Dans un mode de réalisation, l'origine des informations peut être indiquée (e.g. couleur, icône, texte « données communautaires », etc). Ce mode de réalisation présente l'avantage de permettre au pilote de contextualiser l'information météorologique. Dans un mode de réalisation, des données météorologiques proviennent de sources dites ouvertes. Une source ouverte est une source qui n'est pas certifiée (ou pas régulée). La sûreté qui émerge du procédé selon l'invention permet précisément de manipuler des données provenant de sources ouvertes (ce qui n'aurait pas été possible avec des mécanismes n'utilisant pas la gestion de la réputation au travers d'une chaine de blocs). En particulier des stations au sol peuvent pousser de l'information météorologique. Dans un mode de réalisation, le procédé comprend en outre l'étape consistant à ce qu'une autorité du contrôle de la navigation aérienne valide des données météorologiques parmi les données météorologiques partagées. Dans un mode de réalisation, le procédé comprend en outre une ou plusieurs étapes d'apprentissage automatique conduites sur les données météorologiques partagées. Dans un mode de réalisation, l'apprentissage automatique est non-supervisé, ou est appliqué sur différentes techniques d'apprentissage automatique mises en concurrence. Dans un mode de réalisation, des données météorologiques sont associées à des paramètres de validité en temps et/ou en espace, par exemple sont géolocalisées et/ou horodatées. Dans un mode de réalisation, un ou plusieurs modèles météorologiques modifient lesdits paramètres de validité en temps et/ou en espace, et déterminent les données mé- 12 téorologiques pertinentes. Les modèles météorologiques peuvent déterminer les données météorologiques qui sont pertinentes (applicables, qui ont un effet sur) les trajectoires déclarées (ou prédites ou simulées ou révisées). Par exemple les données météorologiques d'une zone d'espace adjacente à un segment de plan de vol peuvent indiquer le déplacement d'un phénomène orageux sur la trajectoire. L'intervention d'un modèle météorologique permet donc la prise en compte de la dynamique météorologique (si les données ne contiennent ou ne sont pas associées pas nativement à ces informations d'évolution). Le terme « pertinent » peut être remplacé par l'expression « applicable en excès d'un ou de plusieurs seuils prédéfinis ». Dans un mode de réalisation, il est décrit un système pour le partage de données aéronautiques comprenant : une chainc de blocs 100 maintenue par une pluralité de parties prédéfinics comprenant des ressources de calcul et de stockage, ladite chainc de blocs étant contigu& pour exécuter un ou plusieurs contrats intelligents déterminant le contrôle des échanges de données météorologiques; une base de données 210 comprenant des données météorologiques référencées par la chainc de blocs 100 ; au moins un calculateur d'aéronef configure pour demander et/ou recevoir des données météorologiques. Dans un mode de réalisation, une partie participante à la chainc de bloc étant un drone (inhabité) configure pour mesurer des données météorologiques. Dans un mode de réalisation, il est décrit un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer une ou plusieurs des étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur. [0050] La figure 1 illustre le fonctionnement d'une chaîne de blocs. [0051] La figure 1 montre 4 blocs de données BI à B4 (101, 102, 103, 104). L'arbre de hachage est constitué par un ensemble de valeurs de hash interdépendantes. Les feuilles de l'arbre sont les valeurs de hash de chacun des blocs de données initiales (III, 112, 113, 114). Dans un arbre de Merkle (binaire), ces valeurs de hachage sont alors concaténés deux à deux pour pouvoir calculer un nouveau hash parent (121, 122). Ainsi de suite jusqu'au sommet de l'arbre ou on obtient un hash-sommet (131). Pour garantir l'intégrité d'un bloc par rapport à l'ensemble des données, il suffit de posséder les valeurs de hash des frères, les valeurs de hash des oncles et le hash-sommet. De plus, seul le hash-sommet (131) doit être récupéré de manière sure pour garantir l'intégrité de l'ensemble des données représenté par l'arbre. Par exemple, si on veut vérifier l'intégrité du block B2, il suffit d'avoir récupéré le hash 0-0 (son frère 111), le hashl (son oncle 122) et le hash-sommet (131). [0052] Un bloc de données peut comprendre un ou plusieurs codes ou programmes ou 13 contrats intelligents 140. [0053] Concrètement, un contrat intelligent 140 peut mettre un oeuvre un ou plusieurs mé- canismes : (a) d'accès aux données ou parties de données : -i) gestion des droits d'accès et partages des clefs de chiffrement (dans le cas d'un chiffrement asymétrique la clef privée est secrète et connue du seul utilisateur ou la clef publique peut être connue d'un registre) ; des mécanismes de chiffrement matériel peuvent être utilisés (TPM ou HSM, carte à puce, etc) ; ii) abonnement par unité de temps (journalier, hebdomadaire, mensuel, annuel, etc) et/ou par volume de données (e.g. au Mo octets de données téléchargées) ; des systèmes de crédits ou de points peuvent être utilisés ; b) de paiement ; les transactions peuvent être réglées en unité de compte (crypto-monnaie ou monnaie fiduciaire e.g. USD ou EUR) ; [0054] Les blocs de données (101, 102, 103, 104) sont produits puis consommés, i.e. accédés, en lecture et/ou écriture, par des parties ou entreprises (e.g. illustrées par 151, 152, 153). [0055] Une partie ou entreprise ou consommateur peut être le constructeur de l'avion, un as- sembleur, un équipementier, un client ou une compagnie aérienne, une société fournisseur de données météorologiques, une autorité de régulation, etc. [0056] Une partie peut être « producteur » de données e//ou « consommateur » de données. Un consommateur de données peut être dénommé « client » ou « demandeur » ou « receveur » ou « acheteur » par la suite. Un producteur peut être dénommé émetteur » ou « serveur » ou « fournisseur » ou « vendeur » par la suite. L'expression « et/ou » souligne le fait que la production et la consommation peuvent être successives ou alternatives, ou même simultanées. Comme chaque partie peut acheter et/ou vendre, prendre licence et/ou concéder licence, céder ou donner ou partager des données qui lui sont propres, elle peut aussi accéder aux données partagées par les autres parties. La mise en partage des données permet de créer d'autres données, dont certaines peuvent avoir de la valeur marchande ou technique ou autre. [0057] Comme autre exemple de producteur/consommateur de données, les autorités de contrôle du trafic aérien 152 peuvent produire et consommer des données. Les données peuvent concerner des notifications NOTAM, des alertes diverses, des statistiques de routage ou sur les plans de vol etc. [0058] Enfin, une grande diversité de parties 153 peuvent consommer ou produire des données utiles : météorologiques, des services d'analyse (« analytics »), etc. [0059] La figure 2 illustre un mode de réalisation de l'invention. [0060] L'illustration permet d'appréhender les différentes couches ou niveaux intervenant dans les procédés ou systèmes selon l'invention : - une première couche de métadonnées ou chaîne de blocs 100 ; héritant des 14 propriétés inhérentes à une chaîne de blocs (e.g. intégrité, in-falsifiabilité, etc) ; la chaîne de blocs100 est essentielle, les autres niveaux sont optionnels. La chainc de blocs est essentielle en ce qu'elle peut « tout » contenir (ici les données météorologiques, les métadonnées, bases de données tierces etc) mais elle peut être allégée, notamment en déportant les données non-critiques ou volumineuses dans des bases de données secondaires, sous forme de chainc de blocs également (« sidcchains »), ou pas i.e. sans utilisation de chainc de blocs ; - une deuxième couche de données 210 appelées ou référencées par la chaîne de blocs 100 (chiffrée en partie ou en totalité) ; ces données DB 210 comprennent en particulier les données météorologiques partagées, téléversécs et/ou téléchargées. Les données météorologiques comprennent les données météorologiques standard (e.g. altitudes, pressions, vitesses. QFE/QNH, etc). Ces données peuvent être stockées dans la base de données 210 selon différents formats de (.txt, .doc, .rtf, .xml, .json, etc). Les données 210 peuvent aussi comprendre des métriques de téléversement, de téléchargement, d'utilisations, etc lesquelles peuvent à leur tour déterminer des scores ou autres quantifications (au moyen de circuits de décision logiques e.g. des ordinateurs) ; - une troisième couche de coordination ou de régulation entre acteurs (qui jouent tour à tour des rôles de producteur P 201 ou de consommateur C 202, lisant et/ou écrivant sur la chaîne de blocs 100. Les accords entre participants à la chaîne de blocs peuvent être des contrats écrits (hors technique), ou bien partiellement - ou en totalité - transcrits via des contrats intelligents de type 140 ; - une quatrième couche 220 optionnelle peut réguler les contrats intelligents (contrats liés, contrats indépendants, contrat cadre modifiant d'autres contrats en aval, ou à l'inverse en amont, boucles de rétroaction multiples entre contrats, feedforward, etc). Optionnellement, ce bloc 220 peut représenter un ou plusieurs validateurs (ou oracles », lesquels peuvent correspondre à une validation indépendante humaine et/ ou machine i.e. encodée algorithmiquement). [0061] Un grand nombre de modes de réalisation de l'invention sont possibles. Quelques exemples sont décrits ci-après. [0062] Chaînes publiques ou privées [0063] Dans un mode de réalisation, la chaîne de blocs 100 de données météorologiques est publique. Il est notamment possible d'implémenter une validation par preuve de travail (« proof-of-work » ou PoW e.g. hashcash ou variante). Dans un mode de réalisation, la chaîne de blocs de données météorologiques est privée : chaque participant est préalablement agréé (par contrat ou accord 201-202) et dispose techniquement de clefs ou moyens d'authentification. Une validation par preuve d'enjeu (« proof-of-stake » ou PoS) est alors possible. [0064] Chaînes de blocs secondaires ou dérivées [0065] Additionnemcnt ou en substitution, une ou plusieurs chaînes de blocs secondaires (non représentées) peuvent être utilisées. Par exemple, une chaîne de blocs principale peut contenir les métadonnées relatives aux données météorologiques (i.e. y compris les valeurs de hachage des données), tandis qu'une chaîne secondaire peut contenir les données elles-mêmes. [0066] Encodage algorithmique des échanges [0067] Pour encadrer une concurrence libre et non faussée, des limites ou autres garde-fous peuvent être encodés de manière algorithmique. Par exemple, s'il s'avère qu'il n'existe qu'un seul fournisseur pour une catégorie de données météorologiques, alors des mécanismes d'ajustement automatiques des prix ou tarifs peuvent être imposés par les contrats intelligents : des prix « raisonnables » peuvent être appliqués, sans condition d'accès (non-discrimination). Des entités de notation indépendantes (« oracles ») agréées par les participants à la chaîne de blocs peuvent contribuer aux scores et/ou aux modes de régulation des transactions. [0068] Divers mécanismes de rétribution (ou de compensation ou de rémunération) peuvent être mis en oeuvre. Différents modèles d'incitation peuvent également être mis en oeuvre. Dans certains cas, les mécanismes peuvent être statiques et prédéfinis. Dans d'autres, cas ces mécanismes peuvent être dynamiques. Dans certains modes de réalisation, les mécanismes peuvent tendre vers une égalité de traitement entre les acteurs participants (a priori) ou des rétributions « justes » (constatées et/ou adaptées a posteriori). [0069] Régulation des échanges [0070] Les échanges peuvent être régulés de manière algorithmique i.e. de manière claire, impartiale et prédéfinie, e.g. détermination et manipulation des scores des participants à la chaîne de blocs. [0071] Dans un mode de réalisation, chaque participant est associé à un ou plusieurs scores, par exemple de « confiance ». Ces scores peuvent évoluer dans le temps (e g mises à jour régulières, après chaque transaction, etc). Dans un mode de réalisation, les scores d'une partie sont résumées en un score synthétique (« rang A », « rang AA », etc) d'une pluralité de critères (comprenant la quantification de la qualité des données envoyées mesurées par exemple par leur nombre d'utilisation par les pairs, les sommes engagées dépensées ou reçues, etc). [0072] Dans un mode de réalisation, un noeud ou participant à la chaîne de blocs est associé à un score synthétique VS (acronyme de Value Score), lequel peut gouverner les accès aux échanges (en tant que producteur et/ou de consommateur de données). [0073] Dans un mode de réalisation, ce score VS peut être fonction de i) la « valeur » des in- formations qu'il produit VS_PROD et ii) de la « valeur » des informations qu'il consomme VS_CONS. La valeur VS peut s'exprimer sous forme d'un score (chiffré), 16 d'un symbole, de valeur dans une crypto-monnaie, d'une monnaie réelle (fiduciaire), etc. Le score VS peut notamment être fonction d'un score de confiance CS et/ou d'un score de véracité (infra). [0074] Le ternie « valeur » désigne une quantification effectuée selon des critères prédéfinis, cette quantification visant à interpréter l'utilité absolue et/ou relative des données partagées par le participant. L'utilité peut en effet être absolue (certaines données de performances peuvent être rares, ou au contraire publiques et d'utilité nulle), mais également relative (des données de changement de niveaux de plan de vol en fonction des centres ATC et de consommations de carburant peuvent aider significativement des procédés d'apprentissage automatique en multipliant les enveloppes de trajectoires, etc). La quantification extrinsèque de la valeur relative peut être difficile voire impossible à établir (dépendante du contexte d'utilisation non maitrisé et extérieur à l'objet de l'invention), néanmoins tout effort de quantification peut ne pas être vain et des estimations plancher peuvent être établies, notamment du fait de la structuration en place de marché (la valeur du cours d'un type de données peut refléter son utilité en aval). [0075] Dans un mode de réalisation, un client ou consommateur achète pour un montant VS MONEY de droit de consommer (e.g. crédits) pour pouvoir ultérieurement consommer des données (ce qui peut être utile s'il en consomme plus qu'il n'en produit). Une autre partie à la chaîne de blocs peut transformer sa VS (Value Score) en monnaie réelle (ou en crypto-monnaie), e.g. pour d'autres usages hors invention. Sa VS est alors diminuée du montant VS_MONEY. Le score VS d'une partie à la chaîne de blocs est donc amené à évoluer en fonction de l'attractivité des données que cette partie produit et partage. Différentes méthodes de quantification, éventuellement considérées en combinaison, sont possibles. Les critères peuvent comprendre un ou plusieurs des éléments comprenant: le nombre d'abonnés, le nombre de téléchargement et/ou de téléversement des paquets de données (« datasets »), des résultats de votes ou de notes attribuées par un ou plusieurs consommateurs, le volume en giga-octets de données partagées, etc. [0076] Les valeurs VS_PROD (valeur des données produites) et VS_CONS (valeur des données consommées) peuvent être calculées de diverses manières, notamment en quantité (volume de données) et/ou en qualité (e.g. criticité du calculateur ou de la fonction embarquée), en valeur relative résultat d'une confrontation offre/demande (e.g. cotation, carnet d'ordres consensus sur un prix, proposition, contre-offre, acceptation, refus, négociation, etc), prise en compte de l'historique d'utilisation, du cours à un instant donné en fonction de paramètres prédéfinis, de la prise en compte de prix minimum et maximum, tels que déterminés par exemple par un circuit de décision logique émulant des conditions d'accès FRAND (juste, raisonnable et non- 17 discriminatoire), etc. Les valeurs ou modalités de calcul peuvent être inscrites ou dé- terminées par un contrat intelligent, lequel peut être bipartite (accord entre deux acteurs) ou multipartitc (accord entre N fournisseurs et M consommateurs). [0077] Dans un mode de réalisation, la chaîne de blocs peut déterminer (par exemple en temps réel) le score d'une partie participant à la chaîne de blocs. Ce score étant inscrit dans la chaîne de blocs hérite de ses propriétés (valeur non falsifiable, historique certain). [0078] Dans d'autres modes de réalisation, divers services d'analyse ou de méta-analyse peuvent être déterminés : historique et palmarès des contributcurs, calcul de risques d'injection de données fausses (i.e. simplement erronées) ou malicieuses (intentionnellement fausses pour affaiblir ou fausser les calculs réalisés par les tiers, etc). La chaîne de blocs étant transparente quant au moins à certaines données (métadonnécs descriptives, historiques des transactions, etc), une partie éventuellement malicieuse sera rapidement déterminée comme telle et éjectée du noyau de confiance entre parties authentifiées. A contrario, la transparence du système dont la gouvernance est au moins en partie auditablc encourage les parties prenantes à abandonner une certaine souveraineté sur les données, en contrepartie d'accès à des données tierces et/ ou de compensation financière. [0079] Quand un producteur publie un ou plusieurs jeux de données météorologiques dans une base 210, en publiant les valeurs de hachage correspondants dans la chaîne de blocs 100, les métadonnées correspondantes sont ajoutées dans un bloc, lequel est horodaté. Le bloc permet l'identification de la source (authentification réussie) et apporte une garantie quant à l'intégrité des données déposées (valeurs de hachage). Quand un consommateur récupère un jeu de données météorologiques depuis la base 210 associée à la chaîne (le blocs, le score du producteur est réévalué (e.g. ajout de la somme déterminée si le bloc est validé, retrait de la somme si le jeu de données est corrompu ou faux ou vide ou autrement non valide) ainsi que son propre score (d'une valeur par exemple inverse de celle créditée au producteur, mais diverses pondérations peuvent être appliquées). Cette transaction comprenant ces écritures crédit/débit, données d'identification, etc sont écrites dans la chaîne de blocs. De cette manière, les parties apparaissent soient en excédent soit en déficit de fourniture de données. 11 se peut que des situations de déficits permanents ou intermittents soient acceptables (e.g. compensables par des flux financiers) : l'essentiel est que les arbitrages soient transparents et sûrs, i.e. traçables et non-falsifiables. [0080] Modes de réalisation avec contrats intelligents [0081] Dans un mode de réalisation, le module de partage collaboratif peut s'appuyer sur un ou plusieurs « contrats intelligents », le contrat permettant par exemple d'assurer l'égalité de traitement (en valeur) entre les parties prenantes. Les données sont 18 partagées sur une chaîne de blocs afin d'en assurer l'horodatage et l'immuabilité. [0082] Dans un mode de réalisation, toutes les données des blocs sont écrites en clair (e.g. les droits d'accès sont protégés). Dans un mode de réalisation, une partie des données sont écrites en clair (certaines informations sont lisibles par tout le monde, d'autres informations à plus haute valeur ajoutée sont protégées par exemple par chiffrement). Dans un mode de réalisation, les données des blocs sont chiffrées (e.g. symétrique, asymétrique, etc). Dans certains cas les données des blocs sont masquées en plus d'être chiffrées (l'existence des données est cachée, ce qui fournit une protection supplémentaire). [0083] Dans un mode de réalisation, les données sont stockées dans une ou plusieurs bases de données partagées, chiffrées en tout ou partie, après vérification de leur intégrité et de l'authenticité du producteur. [0084] Dans un mode de réalisation, la validation des données produites est effectuée par consensus distribué (e.g. utilisation validée avec un score de « pertinence » par plusieurs consommateurs, mesure et suivi du taux d'utilisation, etc) et/ou par validation d'un pair participant à la chaîne de blocs reconnu comme fiable dans la chaîne (qualification technique ou de nature administrative). [0085] Dans un mode de réalisation, quelques informations (comme le format et/ou le résumé du contenu du bloc chiffré sont laissées en clair dans un espace de stockage (dans la chaîne ou en dehors de la chaîne), afin qu'un consommateur intéressé puisse savoir si le bloc l'intéresse ou non. [0086] Dans un mode de réalisation, l'utilisation que souhaite faire un consommateur des données d'un bloc est gouvernée (directement ou indirectement via des règles) par un contrat intelligent. Dans un mode de réalisation, un contrat intelligent peut lire des données de blocs en clair et déclencher une ou plusieurs opérations, par exemple si le client ou demandeur ou consommateur est valablement abonné au type de données du bloc considéré ou si des conditions prédéfinies sont satisfaites. [0087] Dans certains modes de réalisation, les droits sur les données de blocs peuvent être conditionnels à des critères de contribution (notamment de ratio téléversement/téléchargement en anglais « upload/download » ou « seed/leech »). [0088] Dans un mode de réalisation, l'accès aux données ou les droits sur ces données peuvent être régis de manière conditionnelle (par exemple si le solde du client ou Value Score est positif). [0089] Le cas échéant, si l'accès conditionnel est accordé (ou si les conditions prédéfinies sont satisfaites), le contrat intelligent exécuté peut émettre une transaction ou demande de récupération des données, laquelle transaction s'insèrera (parmi plusieurs autres) dans un nouveau bloc. Si le consensus distribué confirme le bloc comprenant la transaction, une clef de chiffrement permettant la lecture des données souhaitée peut 19 être envoyée au client ; qui pourra lire et exploiter les données désirées. [0090] Exemple de mise en oeuvre d'un contrat intelligent [0091] Dans un mode de réalisation, un fournisseur remplit une base de données avec de nouvelles données météorologiques. Un contrat intelligent de « mise à disposition » détecte les nouvelles données et stocke des métadonnées dans une chaîne de blocs (e.g. identification, date, émetteur, score, hash du contenu des données, etc). Les données sont mises en vente ou mises à disposition gratuitement (mécanismes de mise aux enchères, premier venu-premier servi, mécanisme DRM de licence spécifiant le nombre d'utilisations, etc). Le prix de la chose peut être déterminé, selon des mécanismes variés (e.g. calcul de valeur intrinsèque aux données par exemple selon un ou plusieurs modèles préétablis, calcul de la valeur par la création d'un marché, e.g. cotation et carnet d'ordre, enchères, enchères inversées, etc). Si un accord sur la chose et sur le prix est trouvé entre la chaîne de blocs (via un contrat intelligent) et un client, alors une transaction peut être effectuée (données contre données ; données contre paiement en monnaie e.g. fiduciaire, privée, unités de compte, crédits internes à la chaîne de blocs). Un contrat intelligent de « consommation » peut alors se déclencher, par exemple vérifier diverses conditions ou critères (e.g. éligibilité, score de l'acheteur, réputation quantifiée, droits d'accès, solde, etc). Un contrat intelligent de « mise à disposition » des données peut alors se déclencher et communiquer les données achetées ou mises en licence au client. Par exemple, les informations d'un ou de plusieurs blocs de données (e.g. adresses, clef de déchiffrement, valeurs de hachage des contenus des données, etc). Le client, une fois en possession des données désirées peut les exploiter (par exemple techniquement, e.g. pour améliorer des statistiques, enrichir ou alimenter des systèmes d'apprentissage automatique). Les usages des données peuvent, outre les mesures techniques de protection, être encadrés juridiquement (par contrat) ; par exemple, le client peut avoir l'obligation contractuelle de détruire les copies des données dont il dispose après l'expiration (l'une certaine date ; il peut lui être interdit par contrat de diffuser les données accédées, etc). [0092] Dans une variante de réalisation, une pluralité de fournisseurs partagent des données et stockent les valeurs de hash des données, ainsi que des informations relatives au format des données, dans une ou plusieurs chaînes de blocs. Après réalisation d'une transaction, un ou plusieurs contrats intelligents vérifient le « score » de valeur de l'acheteur, lui indiquent la position des données dans la base de données partagée, ainsi que les clefs de déchiffrement des données. [0093] Dans une variante de réalisation, un ou plusieurs contrats utilisent des mécanismes de compte séquestre ou dépôt fiduciaire, etc (en anglais « escrow payment » etc). En particulier les données peuvent être chiffrées à nouveau, etc. [0094] Mode de réalisation direct, sans contrats intelligents [0095] Dans une variante de réalisation, les producteurs et ou consommateurs peuvent se passer de contrats intelligents, par lecture et/ou écriture (directe) dans la chaîne de blocs. Par exemple, un producteur peut recevoir un ordre d'achat de la part d'un consommateur et si la transaction aboutit peut communiquer directement au consommateur. De ce fait la chaîne de blocs ne contient pas les données en elles-mêmes mais seulement la description des données. Ce mode de réalisation est avantageux en ce que les données répliquées dans la chaîne de blocs sont significativement moins volumineuses. [0096] D'autres modes de réalisation sont décrits ci-après. [0097] Abonnement(s) [0098] Dans un mode de réalisation, un aéronef peut, par exemple tour à tour, publier de l'information à destination des autres membres du réseau ou bien « s'abonner » (en anglais « subscribe ») au réseau, par exemple via un contrat intelligent, et recevoir les informations le concernant de manière automatique. Par exemple, un avion peut partager ses informations météorologiques (par exemple non règlementaire, ou les conditions traversées localement), de manière sûre et intègre, avec d'autres aéronefs (appartenant à d'autres compagnies aériennes, précisément). Les modes d'abonnement peuvent comprendre des modes push et/ou pull, de désinscription, etc/ [0099] Modes de réalisation avec validation externe [0100] Dans un mode de réalisation, un intermédiaire est ajouté : un validatcur de données (non représenté). Dans une première étape, de production, une source décide de publier des données dans la chaîne de blocs (directement ou indirectement via la base 210). Les données sont envoyés avec un identifiant (qui permet d'identifier la source d'envoi des données) et un résumé du contenu (e.g. paramètres, unités, quantité, format, etc) ainsi que la date des données (e.g. création, validité, etc) Cet ensemble forme un « bloc » à valider. Le sous-système de validation reçoit les données. La validation est effectuée soit consensus ou par un « validateur» externe et « de confiance » : d'autres fournisseurs ou utilisateurs vérifient l'intégrité des données (et en option l'authenticité de l'émetteur). Ceci peut donner lieu à rétribution (en VS) pour le ou les noeuds ayant participé à la validation. Ce peut être le consommateur qui vérifie l'intégrité du bloc (hash). Dans un mode de réalisation, le consommateur peut « noter » (unilatéralement) l'attractivité du bloc reçu (son intérêt estimé pour et par lui-même). Dans un mode de réalisation, la note est donnée par le consommateur. Dans un mode de réalisation, la note est calculée par comptage du nombre de téléchargements du jeu de données considéré et/ou par le nombre de consommateurs intéressés ou acheteurs/licenciés effectifs. Si les données sont déclarées comme étant invalides alors la chaîne de blocs est mise à jour avec une baisse du VS_PROD d'un certain montant pour le producteur, et une augmentation du VS_PROD pour celui qui a détecté l'anomalie. Dans un mode 21 de réalisation, si les données sont considérées comme valides/intègres alors un nouveau bloc est créé, qui contiendra le lien vers les données (e.g. adresses, clefs), et une augmentation de VS PROD d'un certain montant pour le noeud ou la partie de validation. [0101] Modes de réalisation avec validation interne [0102] Dans certains modes de réalisation, le tiers validatcur est internai isé : les vérifications sont effectuées directement et automatiquement par un ou plusieurs contrats intelligents. A chaque nouvelle entrée dans la base (et tentative d'écriture de bloc), un ou plusieurs contrats intelligents peuvent exécuter diverses tâches, notamment a) vérifier si le producteur est déclaré (s'il s'agit d'une partie au consortium ou chaîne de blocs) ; h) modifier le score VS de la source c) noter ou évaluer les données entrées (directement ou indirectement) ; éventuellement d) effectuer directement des vérifications fonctionnelles sur les données (par exemple, des données issues d'un aéronef de modèle X peuvent être corrélées/croisées avec d'autres sources d'informations sur l'aéronef (e.g. sources publiques ou privées de la compagnie, du contrôle aérien) émises en temps réel et correspondant à l'état de l'aéronef (e.g. heure de décollage, statut courant e.g. en vol, au sol, en croisière, position courante ...). [0103] Dans la perspective de la consommation de données, un consommateur s'abonne ou se déclare intéressé pour récupérer des données (e.g. ordre d'achat directement sur la chaîne de blocs ou via un ou un contrat intelligent). Le contrat intelligent concerné peut vérifier si l'acheteur a le solde suffisant (VS) pour télécharger les données. Dans une variante de réalisation, le bloc acheté est mis à disposition d'un ou de plusieurs validateurs humains et/ou machines qui effectuent cette vérification. Si la transaction est valide, le jeu de données (par exemple chiffré) est transmis à l'acheteur, qui peut par exemple avoir la possibilité de vérifier son intégrité (valeur de hash récupérée dans la chaîne de blocs). Si le jeu de données est déterminé ou réputé valide, des clefs de déchiffrement (stockées dans la chaîne de blocs) sont récupérées par le contrat intelligent et transmises à l'acheteur. La transaction est ensuite inscrite dans la chaîne de blocs par le contrat intelligent. Dans un mode de réalisation, des mécanismes de compensation et/ou d'évaluation et/ou de rétribution et/ou de validation peut être mis en oeuvre si les données sont déterminées comme étant valides (mécanisme de notation et/ou de réputation pour identifier ou rétribuer les émetteurs de données les plus « utiles » (notion relative à une ou plusieurs objectifs pouvant être objectivés et internalisés). Le consommateur demandeur i.e. initiateur de la transaction peut par exemple importer les données obtenues et les croiser ou intégrer à des données existantes dans le but d'effectuer un traitement de type « Big Data » par des techniques d'Intelligence artificielles (notamment d'apprentissage automatique). La figure 3 illustre un exemple de mode de réalisation de l'invention. Dans un mode de réalisation, le système selon l'invention comprend un système (sous forme matérielle et/ou logicielle) pour le partage d'informations météorologiques, entre différents producteurs (ou fournisseurs) et/ou consommateurs (ou clients). [0104] Dans un mode de réalisation, la chainc de blocs 100 (« BK » ou blockchain ou « distributcd ledger ») est distincte de la base de données 210 (« DB » ou base de données e.g. SQL, Oracle, etc). Il peut en effet être avantageux de stocker les informations météorologiques en tant que telle dans une base de données dédiée (ou une « sidcchain ») 210 d'une part, et les métadonnées ou les transactions dans la chainc de blocs 100 d'autre part (e.g. acteurs, identifiants, transactions, valeurs VS. CS et autres). Les données stockées dans la chainc de blocs 100 sont en effet répliquées de multiples fois, et il est généralement non-efficient de stocker des données météorologiques dont l'obsolescence peut être rapide. [0105] Dans un mode de réalisation, les communications entre aéronefs sont exclusivement indirectes, e.g. passent par l'intermédiaire de la chainc de blocs 100. Dans un mode de réalisation, les communications entre aéronefs sont en partie directes 399, et en partie indirectes (396, 397). Dans un mode de réalisation, l'implémentation est locale (i.e. embarquée dans l'aéronef et des échanges peuvent se faire de pair-à-pair 399). Dans un mode de réalisation, l'implémentation est au moins en partie réalisée par accès distant (e.g. système hébergé dans le Cloud 390 et accessible depuis de multiples platcforrnes clients 397, 398 e.g. EFB, application web au sol, etc). Dans un mode de réalisation, l'implémentation est hybride locale/distante (e.g. les capacités de communication de pair-à-pair sont complétées par des ressources d'informatique dans les nuages). [0106] Dans un mode de réalisation, chaque aéronef peut tour à tour partager de l'information avec les autres membres du réseau, ou bien « s'abonner au réseau » et recevoir les informations le concernant de manière automatique. [0107] Dans un mode de réalisation, chaque membre du réseau (de la chaine de blocs) se voit attribuer un « score de confiance » (en anglais « Confidence Score », acronyme CS) qui correspond à la qualité des informations qu'il envoie, ce score étant amené à évoluer en fonction de la qualité des prédictions/informations que la source envoie au réseau. La chaîne de blocs contient à tout instant (modulo le temps de propagation des mises en jour) le score de CS associé à chaque acteur du réseau. Lorsque le score d'un acteur est mis à jour, la chaîne de blocs l'est aussi (l'utilisation de la blockchain permet d'avoir cette information distribuée sur plusieurs noeuds et donc de la rendre immuable et sécurisé ainsi que de posséder un historique certain). Lorsqu'un producteur P (e.g. 301) envoie des informations météorologiques locales (et/ou distantes), ainsi qu'un ou plusieurs identifiants, ces informations sont ajoutées à son score CS. [0108] Envoi d'information météo (mode « Producteur ») [0109] Une source, par exemple une station au sol 301, décide de partager des informations 23 météorologiques à son réseau de partage. Les données météorologiques sont envoyées avec un identifiant ou après authentification. Les données peuvent optionnellement être vérifiées sur le fond et/ou la forme, par exemple par un module embarqué ou un module au sol 311 ou 312 (e.g. vérification de l'intégrité des données en matière de format, etc). Si les données sont déclarés comme invalides, alors la chainc de blocs 100 est mise à jour avec une baisse du CS (d'un certain montant prédéfini) pour la source considérée. Cette vérification fond/forme peut être optionnellement effectuée dans ou par un contrat intelligent (exécutions en parallèle des copies distribuées, garantissant l'exécution sûre du code auditablc). Si les données sont considérées comme intègres, alors une nouvelle entrée peut être faite dans la base dc données DB 210, qui contiendra les données météorologiques ainsi que des informations relatives à la source de données 301, au numéro de bloc, de version etc. A chaque nouvelle entrée dans la base de données DB 210, le procédé selon l'invention comprend une étape qui consiste à comparer les données météorologiques fournies (localisation, valeurs, etc) avec la trajectoire des avions qui sont en vol. Si aucun avion actuellement en vol n'a de trajectoire qui intercepte la localisation de ces informations météo vis-à-vis d'un certain seuil alors aucune action n'est prise. Si au contraire un des avions en vol à une trajectoire qui passe à une distance « proche » (i.e. selon des tolérances souillées) de ce point météorologique alors des vérifications peuvent être effectuées. Parmi ces vérifications, il est possible de : a) corréler l'information reçue avec les données déjà présentes dans la base ou bien celles envoyées par 1'ATC/A0C, etc et estimer si elles sont « proches » ou non ; b) qualifier les informations reçues en fonction de la quantité de données disponibles dans cette zone, si les données sont fournies pour des zones ou les infos météorologiques sont rares (e.g. dernière mise à jour ancienne, peu de stations météorologiques dans la zone courante etc). En fonction des vérifications déterminées et du score de confiance, il est possible de déterminer une ou plusieurs actions. [0110] Dans un mode de réalisation, une fois que le vol est terminé ou bien que l'avion a dépassé la zone géographique en lien avec les informations fournies, des informations de « confirmation » ou d' « infirmation » peuvent être envoyées par l'avion afin de qualifier la qualité des informations. Si les informations sont vraies ou correctes (modulo des tolérances selon un ou plusieurs seuils ou plages de seuils prédéfinis), alors la source concernée peut voir son score de confiance CS être mis à jour et augmenté. Au contraire, si les informations sont trop éloignées de celles rencontrées de manière réelle, le score de confiance CS peut être diminué (par exemple proportionnellement aux écarts constatés, ou selon un fonction par exemple analytique). Avantageusement, ce système permet de réduire ou d'empêcher l'injection de météorologie malicieuse ». [0111] Dans un mode de réalisation, la chaine de blocs met à jour les scores CS des dit- 24 férentes sources, par exemple lors de l'ajout d'un nouveau bloc. [0112] Dans un mode de réalisation, le procédé comprend un mécanisme de rétribution. Par exemple, à certains instants temporels prédéfinis, les meilleurs contributcurs peuvent être déterminés (selon des règles ou des critères prédéfinis). Par exemple, des informations fournies pour une zone associée à peu d'informations peuvent être valorisées, au contraire de données fournies pour des zones très fréquentées. Des informations permettant d'éviter des phénomènes météorologiques dangereux peuvent ex post justifier des bonus ou gratifications ou autres améliorations du score de confiance. D'autres mécanismes issus de la gestion de la e-réputation (parfois appelée wcbréputation, cyber-réputation, réputation numérique) peuvent être utilisés (agence de notation, veille, moteur de recherche spécifique, agrégateurs RSS, assurance, etc) [0113] Réception d'informations météorologiques (Mode « consommateur ») [0114] Dans un mode de réalisation, le procédé selon l'invention comprend une étape dans laquelle un aéronef déclare sa trajectoire courante ou future (prévue). Les informations météorologiques géo localisées partagées et stockées dans la base de données 210 sont alors considérées et il est déterminé quels événements vont concerner ledit aéronef Les informations pertinentes sont alors communiquées à l'avion. Ce dernier peut prendre en compte, ou non, ces données (si elles sont plus précises et/ou plus récentes). Certaines de ces données peuvent être au moins partiellement affichées. Dans un mode de réalisation, l'origine des informations peut être indiquée (e.g. couleur, icône, texte « données communautaires », etc), ce qui peut aider le pilote à interpréter contextuellement ou à synthétiser la météorologie. Par exemple, les détails des sources de données peuvent être indiqués ou être accessibles. [0115] Dans un mode de réalisation, un ou plusieurs aéronefs transmettent les données mé- téorologiques réellement traversées et mesurées. Les informations réelles peuvent alors servir à évaluer les informations issues d'un partage collaboratif. [0116] En d'autres termes, il est possible de déterminer la véracité des informations com- muniquées par une source donnée. Selon les modes de réalisation, la véracité peut être binaire (vraie ou fausse), exprimée selon des graduations discrètes (« plutôt vraie », « plutôt fausse », etc) ou quantifié de manière continue (score entre 0 et 100). [0117] Dans un mode de réalisation, en fonction de la différence entre les données réelles mesurées et les données communiquées partagées, un score peut être attribué ou associé à ces données communiquées ou partagées et/ou au score CS associé à la source des données. De manière indirecte, l'attribution d'un score aux données déclarées peut déclencher un mécanisme (fonction) ou des règles complexes contenues dans un contrat intelligent qui pourra modifier le score CS de la source, par exemple en fonction du score de véracité obtenu par les données. Le score CS d'une source peut donc être le résultat d'une fonction (analytique) ou bien d'un algorithme (exécution d'un programme dans le temps). Dans un mode de réalisation, un contrat intelligent peut déclencher une nouvelle transaction dans la chainc de blocs (mise à jour du score CS de la source de donnée). [0118] Dans un mode de réalisation, les informations servant à établir la véracité des données météorologiques peuvent provenir d'un « Oracle » ou d'un service d'Oracle, fourni par une partie tierce. La partie tierce peut notamment comprendre une entité du contrôle du trafic de la navigation aérienne (en d'autres termes il peut y avoir une boucle de validation de la météorologie partagée par ce type d'organisation avant dissémination de l'information). [0119] Diversité des Oracles [0120] Dans un mode de réalisation, un Oracle ou service d'Oracle vise à fournir ou garantir que les informations météorologiques sont « correctes », i.e. suffisamment proches de la réalité. Dans un mode de réalisation, un Oracle est un programme ou logiciel (analyse satellite, etc). Dans un mode de réalisation, un Oracle est un programme sécurisé, par exemple un contrat intelligent. Dans un mode de réalisation, un contrat intelligent est en réalité le résultat d'un assemblage d'une pluralité de contrats intelligents (les contrats intelligents peuvent s'imbriquer les uns dans les autres e.g. contrat cadre, avenant, etc). [0121] Dans un mode de réalisation, un ou plusieurs Oracles et/ou parties participantes à la chainc de blocs peuvent être des drones (inhabités) qui volent les trajectoires prévues des aéronefs. Dans certains modes de réalisation, des dirigeables ou des ballons stationnaires ou quasi-stationnaires peuvent être utilisés pour mailler l'espace et corroborer les communications de données, en surcroît de ce que les avions explorent eux-mêmes. [0122] Dans un mode de réalisation, un Oracle peut être (le fait d') une institution (un office national de la météorologie e.g. Météo France, un « National Weather Service », etc) [0123] Dans un mode de réalisation, un nouveau bloc (ajouté à la chaine de blocs) peut comprendre une ou plusieurs transactions. Dans un mode de réalisation, une transaction peut comprendre une ou plusieurs des valeurs parmi les valeurs comprenant: a) la valeur de hash, de hachage, du bloc précédent, b) une valeur d'horodatage (« timestamp » en anglais), c) l'identification de la source, d) le score de véracité des informations météorologiques partagées, e) le pointeur ou l'identification des données météorologiques dans la base de données 210, f) l'incrément ou le décrément quant au score de confiance CS (par exemple +10 ou -10, en fonction du score de véracité des informations téléversées), g) l'incrément ou le décrément quant au score VS à ajouter (par exemple en fonction de la qualité des données). [0124] Dans un mode de réalisation de l'invention, le procédé selon l'invention peut comprendre différentes étapes de vérification de l'intégrité des données. Par exemple, 26 le format des données peut être vérifié (sémantique, etc). La cohérence de la source vis-à-vis des informations précédemment envoyées (par exemple pour une station au sol, donc théoriquement immobile, il est possible de déterminer si les informations de géolocalisation sont cohérentes au cours du temps, si les valeurs sont plausibles i.e. dans des intervalles réalistes, etc. [0125] Dans un mode de réalisation de l'invention, le procédé selon l'invention peut comprendre différentes étapes de vérification de la validité des données métérologiques. Dans un mode de réalisation, la base de données 210 peut être régulièrement « nettoyée » en supprimant les données obsolètes (e.g. données périmées). Toutefois, il peut être avantageux de conserver des données historiques à des fins d'apprentissage : dès lors, les données obsolètes marquées comme telles peuvent ne pas être prises en compte par les modèles météorologiques éventuellement invoqués mais servir à des fins statistiques ou d'apprentissage. A cet effet les données obsolètes ou périmées peuvent être déplacées dans une base de données d'archive (non représentée). [0126] La figure 4 illustre des exemples d'étapes selon un mode de réalisation de l' invention. [0127] Dans un mode de réalisation, le procédé comprend une étape 401 dans laquelle une source de données transmet de nouvelles données météorologiques au système (ces données sont riches, i.e. peuvent être associées directement ou indirectement avec un ou plusieurs intervalles de validité, de taux de confiance, etc). L'identité de la source est vérifiée à l'étape 402. A l'étape 410, il est testé si la source est connue ou pas. Le cas échéant, les informations 412 relatives à la source des données météorologiques sont extraites de la chaine de blocs 100. A défaut, la source de données est considérée comme étant une nouvelle source de données 411 ; cette dernière commence alors avec un paramètre CS par défaut. Si la source de données est connue, il est testé à l'étape 420 si le rapport CS /info est favorable, par exemple s'il est supérieur à un seuil prédéfini. Le cas échéant, de manière optionnelle, l'intégrité des données est vérifiée à l'étape 430. Si les données sont intègres, à l'étape 450, les données météorologiques sont ajoutées dans la base de données 210. A défaut, le paramètre CS de la source de données est diminué à l'étape 440. Enfin, le procédé peut comprendre une étape 460 consistant à déterminer si les données météorologiques concernent un ou plusieurs aéronefs, par exemple dans un intervalle de temps compatibles avec l'intervalle de temps de validité des données météorologiques. En d'autres termes, à l'étape 460, il peut être déterminé l'intersection entre les trajectoires présentes et futures des aéronefs d'une part, et le présent et l'avenir à brève échéance des phénomènes météorologiques d'autre part. Certains phénomènes météorologiques peuvent subsister plusieurs jours mais la plupart des événements subsistent quelques heures ou moins. [0128] Si les données concernent un aéronef A/C en cours de vol (e.g. par recoupement géo- 27 graphique modulo une distance ou tolérance), alors le procédé peut comprendre une étape consistant à attribuer un score aux informations météo, par exemple en fonction de la dernière mise à jour connue sur la zone considérée, du paramètre CS de la source etc. Par suite, il peut être identifié un ou plusieurs aéronefs dont le plan de vol inclut un passage par la zone géographique concernée par les données. Les données sont ensuite transmises aux aéronefs identifiés. Différents affichages sont ensuite possibles via les interfaces homme-machine (e.g. symbologies différentes, utilisation de réalité augmentée et/ou virtuelle). Dans un mode de réalisation particulier, une fois que les aéronefs ont traversés les zones annotées, il est possible que lesdits aéronefs qualifient la véracité des informations météorologiques reçues, a posteriori. La qualification peut être binaire (vrai, faux) ou selon des qualifications discrètes (e.g. modulations, nuances, etc). Il est alors possible de mettre à jour les paramètres CS des différentes sources de données. [0129] Mise en oeuvre logicielle et/ou matérielle La présente invention peut s'implémenter à partir d'éléments matériels et/ou Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. L'ordinateur peut être un rack ou une tablette ou un EFB (sac de vol électronique) ou une partie logicielle intégrée dans le FMS (système de gestion de vol), etc. Le support peut être électronique, magnétique, optique, ou électromagnétique. Matériellement, les modes de réalisation de l'invention peuvent être réalisés par ordinateur. Par exemple, une architecture distribuée du type «informatique dans les nuages » (« cloud computing » en anglais). Des serveurs en pair-à-pair, entièrement ou partiellement distribués (existences de centres) peuvent interagir. Une chaîne de blocs repose sur une architecture décentralisée, qui peut être plus ou moins distribuée. Une mise en oeuvre par chaîne de blocs ne fait pas obstacle à l'existence d'une ou de plusieurs noeuds privilégiés, quand il s'agit de cloud privé ou de chaîne de blocs privée. Les accès peuvent être multiplateformes (e.g. depuis EFB, WebApp, accès sol, etc). [0130] Dans un mode de réalisation, un aéronef est équipé d'un module de communication et de partage collaboratif de données issues des calculateurs embarqués dans l'aéronef. Ce module matériel peut être en relation avec divers utilisateurs (consommateurs) et/ou fournisseurs (producteurs) de données. Les équipements avioniques peuvent interagir (communication bilatérale) avec des équipements non-avioniques. Dans certains cas, les communications peuvent être unilatérales (depuis l'avionique vers le non-avionique, mais pas l'inverse, i.e. pour éviter l'injection de données erronées ou malicieuses du monde ouvert vers le monder avionique certifié). Des systèmes de gestion de vol FMS peuvent être mis en réseau entre eux, également avec des EFB. 28 REVENDICATIONS[Revendication 1] Procédé mis en oeuvre par ordinateur pour le partage de données météo- rologiques, comprenant les étapes consistant à : - collecter des données météorologiques lors des vols d'une pluralité d'aéronefs; - recevoir des données relatives à la trajectoire d'un aéronef client; - en fonction de ladite trajectoire, sélectionner des données météorologiques pertinentes dans une base de données météorologique partagée 210 comprenant les données météorologiques collectées; - en réponse à une requête de l'aéronef client, authentifié comme une partie parmi plusieurs parties participantes à une chaîne de blocs 100, communiquer les données météorologiques sélectionnées en fonction d'un mécanisme de contrôle des échanges de données météorologiques. [Revendication 2] Procédé selon la revendication 1, le mécanisme de contrôle des échanges de données météorologiques étant déterminé par un ou plusieurs contrats intelligents. [Revendication 3] Procédé selon l'une quelconque des revendications précédentes, comprenant une étape consistant à déterminer un score de confiance associé à une partie prédéfinie participante à la chaine de blocs. [Revendication 4] Procédé selon la revendication 3, le score de confiance d'un aéronef étant déterminé en fonction de la corrélation existante entre les données météorologiques mesurées par ledit aéronef d'une part et les données météorologiques mesurées par un autre aéronef d'autre part. [Revendication 5] Procédé selon l'une quelconque des revendications précédentes, une communication de données étant associée à une transaction financière. [Revendication 6] Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à afficher dans le cockpit d'un aéronef un ou plusieurs scores de confiance associés à une ou plusieurs parties associées à un ou plusieurs aéronefs. [Revendication?] Procédé selon l'une quelconque des revendications précédentes, des données météorologiques provenant de sources dites ouvertes. [Revendication 8] Procédé selon l'une quelconque des revendications précédentes, comprenant en outre l'étape consistant à ce qu'une autorité du contrôle de la navigation aérienne valide des données météorologiques parmi les données météorologiques partagées. [Revendication 9] Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une ou plusieurs étapes d'apprentissage au- 29 tomatique conduites sur les données météorologiques partagées. [Revendication 10] Procédé selon la revendication 9, l'apprentissage automatique étant non- supervisé, ou étant appliqué sur différentes techniques d'apprentissage automatique mises en concurrence. [Revendication 11] Procédé selon l'une quelconque des revendications précédentes, des données météorologiques étant associées à des paramètres de validité en temps et/ou en espace, par exemple étant géolocalisées et horodatées. [Revendication 12] Procédé selon la revendication précédente, un ou plusieurs modèles mé- téorologiques modifiant lesdits paramètres de validité en temps et/ou en espace, et déterminant les données météorologiques pertinentes. [Revendication 13] Système pour le partage de données aéronautiques comprenant : - une chainc de blocs 100 maintenue par une pluralité de parties pré-définies comprenant des ressources de calcul et de stockage, ladite chainc de blocs étant configurée pour exécuter un ou plusieurs contrats intelligents déterminant le contrôle des échanges de données météorologiques; - une base de données 210 comprenant des données météorologiques référencées par la chainc de blocs 100 ; - au moins un calculateur d'aéronef configure pour demander et/ou recevoir des données météorologiques. [Revendication 14] Système selon la revendication 13, une partie participante à la chaine de bloc étant un drone inhabité configuré pour mesurer des données météorologiques. [Revendication 15] Produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.