Brevet FR3107775A1 — publié le 20210903

Le document concerne des systèmes et des procédés pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à : maintenir une chaîne de blocs; ladite chaine de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs bases de données. valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaine de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS. Des développements décrivent notamment l’utilisation de correctifs, de contrats intelligents, de scores (notamment de fiabilité), l’obsolescence des données ou de bases de données avioniques. Des aspects de logiciel sont décrits. Figure pour l’abrégé : Fig.2. MANIPULATIONS DE BASES DE DONNEES PAR REGISTRES DISTRIBUES Domaine de l’invention Le document décrit des procédés et des dispositifs dans le domaine technique de l’avionique, et en particulier des bases de données distribuées. Etat de la Technique L’État de la technique repose généralement sur des bases de données centralisées, contrôlée par un ou plusieurs acteurs. Ces bases de données sont mises à jour par un acteur privilégié, validées ensuite par chaque acteur qui l’utilise, sans partage, ni mesure de qualité. Dans le domaine avionique, le partage de données n’est pas la règle. La concentration des données générées par un seul acteur (intermédiaire) est parfois nécessaire mais le manque de réciprocité est souvent néfaste en ce qu’il ne permet pas un traitement égalitaire entre les fournisseurs et utilisateurs, les rôles des uns et des autres pouvant d’ailleurs être échangé. Dans des environnements de travail de plus en plus complexe, il existe un intérêt majeur à une mise en commun des données : les analyses de données tirent profit d’une consolidation de ces données, à laquelle poussent notamment les approches Big Data contemporaines et la connectivité accrue entre systèmes embarqués et au sol. Plus généralement, il existe un intérêt pour le partage d’informations brutes issues de calculateurs aéronautiques dans une communauté de fournisseurs de calculateurs, de créateurs de données, ou d’utilisateurs (ou consommateurs) de données de ces calculateurs, afin d’améliorer les mises à jours de données aéronautiques, tant en matière de «fraicheur» que d’intégrité des informations qui sont transmises. Dans le secteur aéronautique, les acteurs (créateurs/valideurs ou producteurs/consommateurs) de données peuvent être variés. Une liste non exhaustive de ces acteurs comprend notamment des fournisseurs de calculateurs, des avionneurs, des concepteurs de bases de données d’aérodynamique, des motoristes, des organisations étatiques (concepteurs de procédures de navigation), des chercheurs, des géologues, des concepteurs des modèles de déclinaison magnétique du globe, des compagnies aériennes, ou des météorologistes. Parvenir à faire coopérer ces acteurs est tâche complexe. Les problèmes techniques qui se posent sont nombreux et peuvent notamment se formuler comme suit. Comment inciter les acteurs précédemment mentionnés à participer à une mise à jour coopérative des bases de données aéronautiques? Comment structurer techniquement les échanges? Comment assurer une rétribution juste et certaine de ces acteurs pour leur contribution? La littérature brevet adresse peu ou mal ces préoccupations. Le document de brevet EP3367137 intitulé “ Systems and methods of gathering and distributing critical weather event information“ décrit par exemple un système de partage d’informations de météorologie critique entre plusieurs avions. Un serveur au sol agissant en tant qu’intermédiaire est chargé de gérer les demandes entre les différents avions (à la fois fournisseurs et consommateurs de données). Cette approche présente des limitations (e.g. centralisation, connectivité, intégrité et pertinents et données, etc). Le document concerne des systèmes et des procédés pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à : maintenir une chaîne de blocs; ladite chaine de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs bases de données. valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaine de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS. Des développements décrivent notamment l’utilisation de correctifs, de contrats intelligents, de scores (notamment de fiabilité), l’obsolescence des données ou de bases de données avioniques. Des aspects de logiciel sont décrits. Avantageusement, les modes de réalisation de l’invention permettent d’améliorer sur le fond les bases de données aéronautiques. Avantageusement, les modes de réalisation de l’invention permettent de faire émerger des services à valeur ajoutée pour les opérations aériennes (e.g. estimation des retards, des surconsommations, optimisation des trajectoires, anticipation des flux, de la météorologie, la gestion des flottes «dispatch» etc). Avantageusement, les modes de réalisation de l’invention permettent d’améliorer la sûreté aéronautique, ainsi que la sécurité des vols, par analyse des flux et détection anticipée d’anomalies difficilement prédictibles a priori. Avantageusement, les modes de réalisation de l’invention permettent d’améliorer la gestion de mission d’un aéronef lorsque de nombreux appareils sont engagés dans l’espace (e.g. avions, drones, etc). Avantageusement, les modes de réalisation de l’invention permettent de manipuler des données issues de plusieurs calculateurs, de divers fournisseurs. L’invention permet notamment de dépasser le cadre contractuel et technique classique « bipartite». L’invention permet de gérer la variabilité, l’évolution rapide des acteurs et/ou des données Avantageusement, les modes de réalisation de l’invention permettent un traitement global, quasiment en temps réel, des données entre les acteurs. Avantageusement, les procédés et les systèmes de validation d’informations de bases de données selon l’invention permettent d’assurer une transmission fluide des données (actualisées et intègres) des calculateurs vers les utilisateurs. Par construction, le partage peut être quantifié (les échanges sont traçables). Avantageusement, les modes de réalisation selon l’invention améliorent le partage d’informations brutes issues de calculateurs aéronautiques dans une communauté de fournisseurs de calculateurs ou d’utilisateurs de ces calculateurs, afin d’en tirer des infirmations enrichies ayant une valeur, tout en assurant l’intégrité des informations qui sont transmises et l’égalité de traitement entre les acteurs (juste rétribution de celui qui met à disposition la donnée). Avantageusement, l’utilisation de mécanismes d’échanges horodatés et vérifiés par consensus (via des règles de validation dépendant de la qualité des aéronefs et membres d’équipage pour valider des modifications en temps réel de bases de données) permettent d’assurer le même niveau d’intégrité que les processus classiques, et au partage de ces bases en temps réel. Description des figures D’autres caractéristiques et avantages de l’invention apparaîtront à l’aide de la description qui suit et des figures des dessins annexés dans lesquels: illustre le fonctionnement d’une chaîne de blocs; illustre des exemples d’étapes d’un mode de réalisation selon l’invention. Description détaillée de l’invention Selon les modes de réalisation de l’invention, un « mobile » ou « aéronef » peut être un drone, ou un avion commercial, ou un avion de fret, ou bien encore un hélicoptère, embarquant ou non des passagers. Le mobile peut piloté, télé-piloté ou autonome ; tel qu’un aéronef (avion, hélicoptère, ou tout autre appareil soumis aux lois de l’aéronautique). Dans d’autres modes de réalisation, le mobile peut être terrestre, de surface (e.g. bateau), submersible (sous-marin), orbitale (satellite), etc. Plus généralement, le terme « aéronef » dans la description ci-après peut être remplacé par les termes de véhicule, voiture, camion, bus, train, moto, bateau, robot, sous-marin, jouet, etc. ou tout élément étant susceptible d’être télé-piloté (par liaison radio, satellite, ou autre), au moins partiellement (de manière intermittente, ou périodique, ou même opportuniste au cours du temps). Les calculateurs embarqués dans un aéronef utilisent massivement un grand nombre de bases de données pour effectuer leurs tâches. Plusieurs de ces bases de données sont décrites ci-après (liste non exhaustive). Bases de données de Navigation Ces bases de données dites « NAVDB » sont utilisés par les calculateurs embarqués (FMS pour « Flight Management System »), afin de construire les plans de vol des aéronefs. Au standard international AEEC ARINC 424, ces bases contiennent et déterminent notamment la structuration des routes aériennes et des procédures de décollage et atterrissage pour tous les types d’aéronef, notamment les aéroports et pistes associées en 2D, 3D; les points de passage en 2D ou 3D, les procédures standardisées de décollage (« SID ») et d’atterrissage « STAR », « VIA », « APP », les routes aériennes « Airways », les balises de radionavigation en 2D/3D avec leur fréquence et leur type : « VOR », « DME », « TACAN », etc. Bases de données de déclinaison magnétique Cette base de données mondiale dite « MAGVAR » contient les corrections de déclinaison magnétique. Elle est fournie par exemple par l’administration américaine (« National Oceanic and Atmosphéric Administration », acronyme NOAA). Elle modélise le globe terrestre, et en particulier l’écart entre le cap vrai (« True Heading» ) et le cap magnétique (« Magnetic Heading» ). Elle est utilisée par les systèmes de gestion de vol FMS mais aussi par les systèmes de localisation inertiels ( « Inertial Reference Systems », acronyme IRS) pour calculer en tout point de la trajectoire de l’aéronef les caps magnétiques et vrais. Base de données de performances Cette base de données dite « PERFDB » est généralement fournie par le constructeur de l’aéronef et contient la modélisation du comportement de l’aéronef (modélisation de son aérodynamique e.g. trainée, portance, …), de ses moteurs (consommation, poussée). Elle est utilisée par les systèmes FMS ou PA (Pilotes Automatique) ou par les systèmes de surveillance (TAWS pour la surveillance terrain, TCAS pour la surveillance entre appareils) pour calculer la trajectoire 3D de l’aéronef, ses capacités en latéral, en vertical, en vitesse, son enveloppe de vol, sa consommation de carburant, etc. Base de données aéroportuaire Cette base de données dite « AOF-DB » est au standard international AEEC ARINC 816. Elle et contient et détermine la structuration des surfaces aéroportuaires (ou hélipad) et est utilisée par les calculateurs de roulage (AOF pour Airport Operation Function) ou FMS. Elle contient les positions des pistes, des taxiways, des hangars, des points de parking, etc. Base de données terrain et/ou obstacles Cette base de données dite « TAWS-DB » est au standard international AEEC ARINC 762, et contient une modélisation du terrain terrestre (élévation par rapport à une géodésie choisie). C’est un maillage du globe terrestre, plus ou moins fin selon les sources d’informations, comprenant notamment l’élevation au-dessus du niveau moyen des mers, par maille. Base de données météorologique Cette base de données dite « WXR-DB » contient une modélisation des prévisions météorologiques (e.g vents, températures, convections, activités volcaniques) sur un horizon de temps donné. Bases de données de constellations satellitaires Cette base de données dite « GNSS-DB » contient entre autre les éphémérides des constellations GNSS (e.g. GPS, GALILEO, GAGAN, GLONASS …) et est utilisée par les récepteurs GNSS pour calculer la position avion, ou par les systèmes FMS pour calculer la disponibilité prédite des réceptions satellitaires tout au long du plan de vol. Base de données de secteurs aériens Cette base de données dite « ATC-DB » contient des polygones 3D qui correspondent à des secteurs aériens, et des fréquences associées, mais aussi des heures d’ouverture/fermeture desdits secteurs, des autorisations de vol différentes selon les catégories d’aéronefs qui les traversent, etc. Mises à jour des bases de données Les mises à jours, longues et complexes, des bases de données sont soumises à de nombreuses contraintes de testabilité, de preuve de déterminisme et d’intégrité (procédures de « qualification » ou « certification »). Ainsi le document du RTCA DO200 précise-t-il les processus longs et coûteux qui permettent de garantir la non- corruption des données brutes lors des étapes de transformation qui conduisent à la génération des bases de données à embarquer. i. Cycles Selon les sources, les cycles temporels de mise à jour peuvent être très différents. La base de données météorologique dite WXR DB est mise à jour avant chaque vol. Les données sont mises à jour dans le monde toutes les six heures pour certaines compagnies aériennes, toutes les heures pour d’autres. Pour un vol d’une durée de quelques heures, ce cycle peut être insuffisant, la météorologie pouvant évoluer très vite. Par exemple, la base de donnée dite NAVDB est mise à jour tous les 28 jours (cycle AIRAC pour « Aeronautical Information Regulation and Control ») une mise à jour actualise par exemple l’ouverture de nouvelles pistes, la publication de points de passage, la modification de balises de radionavigation, etc. Un même cycle d’actualisation est observé pour la base de donnée dite AOF-DB. A ce jour, les modifications entre deux cycles distincts sont gérées manuellement (utilisation de bulletins papiers), ce qui entraîne des incompréhensions et des risques pour la sûreté aéronautique. La base de données DB (terrain / Obstacles) est mise à jour tous les un à cinq ans selon les fournisseurs. La partie relative aux obstacles peut être mise à jour avec des cycles plus courts. Cependant, ces mises à jour ne prennent pas en compte les modifications topographiques du globe, et les constructions d’envergure (e.g. pylônes haute tension, immeubles …). Les systèmes d’alerte (TAWS par exemples) peuvent donc être moins précis, intègres, ou générer de fausses alarmes. La base de donnée MAGVAR est mise à jour tous les cinq ans pour les aéronefs. Elle comporte un modèle de prédiction pour calculer, à une date donnée, la déclinaison réelle. En pratique, les variations réelles dans le temps ne correspondent pas toujours au modèle, et de plus la déclinaison magnétique évolue plus erratiquement et plus rapidement que prévu, à cause d’évènements cosmiques ou climatiques. Les systèmes embarqués qui l’utilisent sont donc biaisés (perte de précision) voir faussés. ii. Tests. Chaque modification doit être testée avant d’être déployée. Dans certains cas, un pilote expérimenté va voler la procédure modifiée, à la main, tout en observant la manière dont les calculateurs concernés souhaiteraient voler cette même procédure, afin de la valider, et d’autoriser les autres avions à l’utiliser par la suite. La base de données dite PERFDB est mise à jour via des essais en soufflerie et des modélisations, une fois au démarrage du programme avion et évolue ensuite très peu (sauf correctifs majeurs). Sur certains appareils, il est prévu une correction d’erreur constante ou linéaire grâce à différents facteurs (correction de débit moteur, de performance moteur, de trainée liée au vieillissement de l’avion ou à la maintenance, etc). Malgré tout, ces correctifs ne prennent pas en compte le vieillissement de l’avion, et des imprécisions de modélisations peuvent entraîner des biais systématiques pour les calculateurs qui les utilisent. Il est décrit un procédé mis en œuvre par ordinateur pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à :- maintenir une chaîne de blocs; - ladite chaine de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs bases de données.- valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaine de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS. L’avantage d’utiliser un contrat intelligent réside dans le fait que le code est auditable, et surtout que l’exécution de ce code est inéluctable (exécutions effectuées en parallèle sur les nœuds de la chaine de blocs, et résultat final validé par consensus distribué). L’usage d’une chaine de blocs permet la mise en œuvre de mécanismes de consensus distribué. L’utilisation des données concernées peut être confirmée comme étant valide par M autres utilisateurs parmi N. Dans un développement, lesdits calculateurs aéronautiques effectuent des tests logiques de validation et/ou apportent des preuves de déterminisme et d’intégrité des calculs des tests de validation. Dans un mode de réalisation, un ou plusieurs contrats intelligents peuvent servir d’intermédiaires pour implémenter des tests logiques portant sur l’intégrité des mises à jour et/ou la cohérence de la mise en œuvre de ces mises à jour de données. Des essais en soufflerie et/ou des modélisations peuvent aussi être invoqués. Dans un développement, le procédé comprend en outre une étape consistant à modifier une ou plusieurs mises à jour de données, par apport de correctifs constants, linéaires ou non-linéaires. Dans un développement, la validation de tout ou partie d’une base de données, ou d’une mise à jour de données, est en outre déterminée par un tiers de confiance prédéfini, notamment une autorité de contrôle de la navigation aérienne. Dans un développement, un contrat intelligent gouverne les droits d’accès, de lecture et/ou d’écriture dans les bases de données et/ou la chaine de blocs, notamment par la gestion de clefs de chiffrement. L’utilisation de contrats intelligents, c’est-à-dire de programmes exécutés en parallèle dont l’exécution est auditable et sûre, permet d’organiser les échanges de données, de manière qualitative et/ou quantitative, dans le temps et/ou dans l’espace. Un contrat intelligent pourra ainsi fournir des services de vérification automatique de la validité des configurations (par classe d’avion par exemple, mais aussi selon une granularité allant jusqu’à la configuration-avion propre à chaque appareil). Un contrat intelligent peut en effet contrôler les mises à jour, directement (gérer) ou indirectement (gouverner, e.g. par l’intermédiaire de règles). Les contrats intelligents peuvent appliquer ou déclencher l’application d’un ou de plusieurs tests sur les données concernées (e.g. intégrité, absence de code malveillant, cohérence ou consistant systémique c’est-à-dire compatibilité des ajouts ou retraits, etc.). Un contrat intelligent peut chiffrer, déchiffrer et/ou chiffrer à nouveau les données (e.g. empêcher les collusions ou parasitismes, etc). Dans un mode de réalisation, le chiffrement est asymétrique, une clef publique étant associée à l’identifiant d’un aéronef et une clef privée étant associe à l’aéronef. Dans un développement, un contrat intelligent gouverne les communications des mises à jour des bases de données entre fournisseurs de bases de données et les compagnies aériennes ou aéronefs consommant lesdites mises à jour. De façon optionnelle, une chaine de blocs pourra aussi servir comme moyen de transfert sécurisé des DB et/ou SW entre les fournisseurs et les compagnies et pourra fournir des services de vérification automatique de la validité des configurations. Dans un développement, un ou plusieurs contrats intelligents déterminent un score de fiabilité associés aux parties à la chaine de blocs. Dans un développement, le score de fiabilité est déterminé en fonction de paramètres intrinsèques associés aux données communiquées, comprenant notamment la durée de vie des données, la rareté d’existence des données, une haute fréquence d’usage des données, la criticité d’une procédure associée aux données, une performance associée aux données, notamment en matière de réduction de la consommation de carburant, de la réduction du bruit ou de réduction du risque de collision entre aéronefs. Dans un développement, le score de fiabilité est déterminé en fonction de paramètres extrinsèques associés aux sources des données communiquées, comprenant notamment une réputation variable ou prédéfinie, un ratio entre téléversement et/ou téléchargement de données, ou une transaction avec une contrepartie pour augmenter ledit score de fiabilité. Dans un développement, une base de données et/ou une mise à jour d’une base de données sont stockées dans une base de données centralisée et/ou directement dans la chaine de blocs décentralisée ou distribuée. Dans un développement, une base de données est sélectionnée dans le groupe comprenant une base de données de Navigation NAVDB, une base de données de déclinaison magnétique MAGVAR, une base de données de performances PERFDB, une base de données aéroportuaire AOF, une base de données terrain et/ou obstacles TAWS, une base de données météorologique WXR, une base de données de constellations satellitaires GNSS, ou une base de données de secteurs aériens ATC. Dans un développement, des données des bases de données sont des données non avioniques, provenant de sources ouvertes, comprenant notamment des données du périmètre AISD, des données issues de sacs de vol électroniques ou EFB, des données issues de systèmes cabine ou IFE, et/ou des données issues de systèmes au sol. Dans un développement, une chaine de blocs est publique, avec des critères d’admission et/ou de participation du type validation par preuve de travail. Dans un mode de réalisation, la chaine de blocs est privée (tous les appareils sont préalablement connus, et un nouvel appareil doit s’enregistrer par exemple auprès d’une autorité de régulation du trafic aérien). Dans un mode de réalisation, la chaine de blocs est publique et de nouveaux appareils peuvent s’enregistrer modulo une épreuve d’admission. Il est décrit un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer une ou plusieurs étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur. Il est décrit un système pour la gestion de mises à jour de bases de données aéronautiques: - au moins une chaine de blocs, ladite chaine de blocs étant configurée pour exécuter ou de plusieurs contrats intelligents; - lesdits un ou plusieurs contrats intelligents étant configurés pour valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaine de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS. Dans un mode de réalisation, un aéronef ou drone 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 les équipements 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. Dans un mode de réalisation, le système comprend en outre une base de données centralisée et/ou une chaîne de blocs dite secondaire comprenant les données aéronautiques, lesdites données étant référencées ou indexées dans la chaîne de bloc privée dite principale. La illustre le fonctionnement d’une chaîne de blocs. 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, lesquels blocs 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 chainage 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ées 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 nœuds 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 »). 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 nœuds 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 « sidechains », lesquelles augmentent aussi les capacités de stockage. Dans le cadre du consensus distribué, une chaîne de blocs peut utiliser une validation par preuve de travail (« proof 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". Les nœuds « 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 substitution) 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. Une chaîne de blocs peut être publique ou privée, ou selon des gouvernances intermé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 nœuds participants au consensus qui sont définis à l'avance puis authentifiés. Ses règles de fonctionnement peuvent être éventuellement extrinsèques. 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 est 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. 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 nœuds de l’architecture mettant en œuvre 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. Comme pour tout programme ou code informatique, différents langages de programmation 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, floue, combinatoire, intuitionniste, modale, 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 auditable ou vérifiable par les parties ou les tiers. Un contrat intelligent peut combiner des parties en source ouverte (e.g. auditables, 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 (« hardened »). Les techniques cryptographiques peuvent être diverses : symétrique, asymétrique, « post-quantum », « quantum-safe », avec utilisation de « Quantum-Key-Distribution », etc). Un contrat intelligent peut être lisible par l’homme et/ou la machine (“human and/or machine readable »). La montre 4 blocs de données B1 à 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 (111, 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ées 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 hash1 (son oncle 122) et le hash-sommet (131). Un bloc de données peut comprendre un ou plusieurs codes ou programmes ou contrats intelligents 140. Concrètement, un contrat intelligent 140 peut mettre un œuvre un ou plusieurs mécanismes : (a) d’accès aux données ou parties de données (portant notamment sur les plans de vol): -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) ; 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). Une partie ou entreprise ou consommateur peut être le constructeur de l’avion, un assembleur, 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. Une partie peut être « producteur » de données et/ou « consommateur » de données. Un consommateur de données peut être dénommé « client » ou « demandeur » ou « receveur » par la suite. Un producteur peut être dénommé « émetteur » ou « serveur » ou « fournisseur » 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 technique ou autre. 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 notamment concerner des plans de vol et/ou leurs attestations associées, des notifications NOTAM, des alertes diverses, des statistiques de routage ou sur les plans de vol etc. Enfin, une grande diversité de parties 153 peuvent consommer ou produire des données utiles : météorologiques, des services d’analyse (« analytics »), etc. Dans certains modes de réalisation, différentes couches ou niveaux de régulation peuvent intervenir: une première couche de métadonnées ou chaîne de blocs 100 ; héritant des propriétés inhérentes à une chaîne de blocs (e.g. intégrité, in-falsifiabilité, etc) ; la chaîne de blocs 100 est essentielle, les autres niveaux sont optionnels. La chaine de blocs est essentielle en ce qu’elle peut «tout» contenir (ici les données de plan de vol, 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 chaine de blocs également (« sidechains »), ou pas i.e. sans utilisation de chaine de blocs ; une deuxième couche de données (non représentées) appelées ou référencées par la chaîne de blocs 100 (chiffrée en partie ou en totalité). Ces données, notamment de plans de vol, peuvent être stockées dans la base de données selon différents formats de (.txt, .doc, .rtf, .xml, .json, etc). Les données 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 ou de consommateur, 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 optionnelle peut enfin réguler les contrats intelligents eux-mêmes (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, l’entité 140 peut représenter ou être associé à un ou plusieurs validateurs (ou « oracles », lesquels peuvent correspondre à une validation indépendante humaine et/ou machine i.e. encodée algorithmiquement). Dans un mode de réalisation, la chaîne de blocs 100 de données (de plans de vol) 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 est privée : chaque participant est préalablement agréé (par contrat ou accord et dispose techniquement de clefs ou moyens d’authentification. Une validation par preuve d’enjeu (« proof-of-stake » ou PoS) est alors possible. Additionnement 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 des plans de vols (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. Dans un mode de réalisation, le procédé utilise un ou plusieurs « contrats intelligents ». Les données peuvent être partagées sur une chaîne de blocs afin d’en assurer l’horodatage et l’immuabilité. Dans un mode de réalisation, l’utilisation que souhaite faire un consommateur des données de plans de vol d’un bloc est gouverné (directement ou indirectement via des règles) par un contrat intelligent. 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). 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. 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). 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. 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 »). 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 d’un client ou demandeur ou Value Score est positif). 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 être envoyée au client ; qui pourra lire et exploiter les données désirées. Dans un mode de réalisation, une pluralité d’acteurs partagent des données, e.g. de plans de vols, 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 du demandeur, 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. Dans un mode de réalisation, il n’y a pas de contrats intelligents (modèle direct). En effet, dans cette 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 premier acteur peut recevoir une demande de vol ou d’attestation de vol de la part d’un consommateur et si la transaction aboutit (consensus distribué), il peut la communiquer directement audit acteur. Dans un mode de réalisation, la chaîne de blocs ne contient pas les données de plans de vol en en elles-mêmes mais seulement la description qui est faite de ces données (les données sont stockées dans des chaines secondaires ou une base de données centralisée off-chain ). Ce mode de réalisation est avantageux en ce que les données répliquées dans la chaîne de blocs principale sont significativement moins volumineuses. Dans un mode de réalisation, par abonnement ou «agrément de pair-à-pair», un aéronef ou drone 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 de plan de vol, 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. Dans certains modes de réalisation, chaque aéronef est en mesure de déterminer des intersections ou risques de collision: le trafic s’autorégule. Certains appareils ne disposant pas de moyens de calculs suffisants peuvent émettre des signaux avertissant de leur défaut ou absence de vérification temporaire ou permanente. 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. Dans un mode de réalisation, un intermédiaire est ajouté (validation externe): un validateur de données (non représenté), typiquement un calculateur de l’autorité de la régulation du trafic aérien. 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). 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 nœuds 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 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 nœud ou la partie de validation. Dans certains modes de réalisation, le tiers validateur est «internalisé» : 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) ; b) 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 …); en particulier, la séquence des vérifications du quadruplet opérateur/plan de vol/avion/pilote peut être mise en œuvre par un ou plusieurs contrats intelligents. Dans la perspective de la consommation de données, un consommateur peut s’abonner ou se déclarer intéressé pour récupérer des données (e.g. ordre de transaction directement sur la chaîne de blocs ou via un ou un contrat intelligent). Le contrat intelligent concerné peut vérifier si le demandeur 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 au demandeur, 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 au demandeur. 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 œuvre 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 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 illustre des exemples d’étapes d’un mode de réalisation de l’invention. La figure montre des exemples d’échanges de bases de données entre un producteur 210 et un consommateur 220, par l’entremise d’une ou de plusieurs chaînes de blocs 100, hébergeant et exécutant un ou plusieurs contrats intelligents 140. Les rôles de producteur et de consommateur peuvent être endossés successivement ou simultanément pour un acteur aéronautique. Dans un mode de réalisation, le procédé de mise à jour d’une ou de plusieurs bases de données d’un aéronef comprend différentes étapes. Un producteur ou fournisseur de base de données 210 communique une ou de plusieurs bases de données, à mettre à jour ou à déployer (télécharger et installer). La base de données centralisée 240 et/ou la chaine de blocs 100 est enrichie de tout ou partie des nouvelles données mises à jour. Le producteur publie sur la chaine de blocs de la mise à disposition des nouvelles données dans un nouveau bloc. Un nœud de validation vérifie l’intégrité du bloc proposé et le met à disposition dans la chaine de blocs 230. Un aéronef consommateur 220 effectue une demande de données auprès de la chaines de blocs (e.g. un contrat intelligent). Les mises à jours sont récupérées directement depuis la base de données centralisée 240 et/ou via la chaine de blocs 100. Contrats intelligents (optionnels) L’utilisation de contrats intelligents reste entièrement optionnelle (e.g programmes informatiques dont l’exécution n’est pas parallélisée, existence de nœuds administrateurs ou privilégiés, etc). De manière optionnelle, le mécanisme de partage et/ou de validation peut être encodé dans un ou plusieurs contrats intelligents. Le module de partage peut contrôler des communications entre divers utilisateurs et/ou fournisseurs de données (contrôle du graphe social). Ce module peut être encodé par contrat intelligent. Dans un mode de réalisation, le système selon l’invention comprend un module de validation et/ou de partage (collaboratif /coopératif) de données, notamment issues des calculateurs embarqués dans l’aéronef, lequel module est configuré pour mesurer, qualifier, quantifier, évaluer, simuler, calculer ou autrement manipuler ces bases de données. Un ou plusieurs contrats intelligents 240 peuvent contrôler les mises à jour. En particulier les tests précédemment décrits peuvent être internalisés par ces contrats intelligents (e.g. gestion des confirmations ou informations manuelles du pilote, tests sur la PERFDB via des communications avec des essais en soufflerie au sol, tests via des modélisations, corrections par constantes ou selon des fonctions linéaires.). Les contrats intelligents peuvent réaliser différentes actions, notamment la validation 230 d’un ou de plusieurs blocs. La validation peut être effectuée par consensus distribué, par exemple en appliquant un ou plusieurs tests sur les données concernées (e.g. intégrité, absence de code malveillant, cohérence ou consistant systémique c’est-à-dire compatibilité des ajouts ou retraits, etc.). L’utilisation de contrats intelligents, c’est-à-dire de programmes exécutés en parallèle dont l’exécution est auditable et sûre, permet d’organiser les échanges de données, de manière qualitative et/ou quantitative, dans le temps et/ou dans l’espace. Ces programmes exécutables permettent optionnellement de manipuler les indices de fiabilité des différents contributeurs. Les contrats intelligents peuvent gérer les droits d’accès, de lecture et/ou d’écriture dans les bases de données. Concernant les données de procédure de vol, par exemple, la « qualité » des aéronefs et/ou des membres d’équipage peut être prise en compte. Les bases de données de performance peuvent être (par exemple exclusivement) manipulées par des équipementiers, ou des avionneurs ou des aérodynamiciens. Les bases de données terrain ou MAGVAR peuvent être manipulé par des géologues ou des institutions (e.g. Institut National de l'information Géographique et forestière). Dans un mode de réalisation, ces entités peuvent être intégrées finement dans le processus de validation et valider en temps réel, ou en quasi temps réel/flux tendus, les modifications apportées aux bases de données. En particulier, les autorités de contrôle de la navigation aérienne peuvent contrôler le flux de données (e.g. prioriser, censurer, autoriser, confirmer, infirmer, corroborer, modifier, altérer, enrichir, croiser, etc). Dans un mode de réalisation, un contrat intelligent peut permettre d’assurer une égalité de traitement entre les contributeurs. Un exemple d’utilisation d’un contrat intelligent est décrit ci-après. L’exécution d’un contrat intelligent peut être déclenchée automatiquement (e.g. Oracle). Il peut lire des données externes ou internes à la chaîne de blocs, et déclencher la réalisation d’actions prédéfinies si les conditions préalablement codées sont satisfaites (par exemple si son solde (Value Score) est positif. le cas échéant, le contrat intelligent peut émettre une requête de récupération des données, laquelle requête peut conduire à la création d’un nouveau bloc dans la chaîne de blocs. il est également possible de causer la communication d’une clef de déchiffrement pour le bloc requis. Stockage centralisé ou distribué De manière générale, les données peuvent être stockées directement sur la chaîne de blocs 100 et/ou sur la base de données centralisée 240. En d’autres termes, dans un mode de réalisation, la totalité des données peut être stockée directement sur la chaîne de blocs. Dans un mode de réalisation, la totalité des données peut être stockée directement sur la base de données centralisées 240. Dans d’autres modes de réalisation, les données sont stockées pour partie dans la chaîne de blocs 100 et pour partie dans la base de données centralisée 240. Dans un mode de réalisation, les données peuvent être stockées dans une base de données centralisée et partagée 140. Cette base de données peut être chiffrée, par exemple après vérification de l’intégrité et/ou de l’authenticité du producteur. Un bloc de la chaîne de blocs 100 peut contenir des données ajoutées ou modifiées ou supprimées ou remplacées de la chaîne de blocs 100 et/ou de la base de données centralisée 240. Validation Dans un mode de réalisation, le procédé selon l’invention comprend une étape consistant à valider tout ou partie d’une base de données utilisées par les calculateurs aéronautiques (ou par une multitude d’acteurs intéressés par leurs mises à jours). Par exemple, les organisations étatiques peuvent contribuer à valide les actualisations de la base MAGVAR. Des fournisseurs de données peuvent contribuer à valider des jeux de données, associés ou non avec des offres de services (e.g. analyses, alertes, croisements, enrichissements, etc.). La validation des données produites peut être faite par consensus (utilisation validée avec un score de « pertinence » par plusieurs consommateurs, taux d’utilisation) ou par validation d’un ou plusieurs acteurs reconnus comme fiable dans la chaîne de blocs. Quelques informations comme le format et le résumé du contenu du bloc (i.e. des données cryptées) peuvent être laissées en clair dans un espace de stockage (dans la chaîne ou en dehors de la chaîne), afin qu’un consommateur ou aéronef intéressé puisse savoir si le bloc l’intéresse ou non. La traçabilité des échanges peut être déterminée. Les échanges de données peuvent être horodatés et/ou vérifiés par consensus distribué, par exemple via des règles de validation dépendant de la «qualité» des acteurs. Cette qualité peut être quantifiée de diverses manières, statiques (voire prédéfinies) ou dynamiques (score de réputation, indice de fiabilité, etc.). Chiffrement Dans un mode de réalisation, toutes les données peuvent être stockées en clair (c’est-à-dire sans chiffrement). Dans un mode de réalisation, les données peuvent être chiffrées (par exemple selon un chiffrement post quantum). Les données produites peuvent également être masquées ou cachées (stéganographie, masquage, dissimulation, etc.). Dans un mode de réalisation, un aéronef peut s’«abonner» à un ou plusieurs canaux de données (RSS, NOTAM, ou autres), agissant en tant qu’Oracles. Cet aéronef peut par exemple recevoir les informations le concernant de manière automatique (e.g. météorologie, trafic aérien, déroutement, etc). Valeur d’une mise à jour La valeur d’une mise à jour est fonction (e.g. somme, fonction analytique, paramétrique, calculable par algorithme) de la valeur extrinsèque des données (celle du producteur de bases de données) et de la valeur intrinsèque des données (objectivée via des tests logiques, des simulations, des références à ces listes de compatibilités, etc). i. Scores de fiabilité (valeur extrinsèque) Dans un mode de réalisation, des scores de fiabilité sont manipulés en fonction des historiques de téléchargement et/ou de téléversement de données, d’un point de vue quantitatif (fournisseurs actifs) et/ou qualitatif (e.g. qualité des données, fiabilité, exactitude, ou au contraire données erronées, voire malicieuses). Par le biais de la gestion de ces indices, des acteurs malveillants peuvent être exclus, d’autres récompensés, etc. Dans un mode de réalisation, un membre du réseau peut se voir attribuer un score de valeur (Value Score, acronyme VS) pour lui permettre de participer aux échanges (en tant que producteur et/ou consommateur de données). Ce score VS peut être fonction de la valeur des informations qu’il produit VS_PROD et de la valeur des informations qu’il consomme VS_CONS. La valeur VS peut s’exprimer sous forme d’un score, d’une crypto monnaie, d’une monnaie réelle. Dans un mode de réalisation, la VS peut être modifiée par des versements de monnaie, pour qu’un demandeur se procure le droit de consommer, ce qui peut par exemple être utile s’il en consomme plus de données qu’il n’en produit. Dans un mode de réalisation, un nœud ou acteur peut inversement transformer sa VS en monnaie fiduciaire ou en crypto-monnaie. Dans un mode de réalisation, le score VS est amené à évoluer en fonction de l’attractivité des données produites (nombre d’abonnés par exemple, ou nombre de téléchargements, ou quantités de téléchargement), de la valeur des données qu’il consomme, et des achats/ventes dans l’alternative monétisée. Les valeurs VS_PRED et VS_CONS peuvent être calculées de plusieurs manière, par exemple en quantité (e.g. au Mégabyte), en qualité (e.g. fonction de la criticité du calculateur ou de la fonction embarquée concernée), par consensus sur un prix (proposition par un consommateur, validation par le producteur ou proposition par un producteur vs. acceptation/refus par un consommateur, ou négociation), en fonction de l’historique d’utilisation, du cours du jour, de la fixation a priori de bornes min/max, du consensus a priori sur les valeurs des différentes données entre acteurs, etc. ii. Valeur d’une mise à jour (intrinsèque) En particulier, la valeur de la mise à jour d’une base de données peut être déterminée en fonction de la difficulté à produire la donnée de la base. Pour une base de données de navigation, la publication et validation d’une procédure peut avoir une valeur différente selon que la procédure sera fréquemment utilisée par la suite par les autres acteurs. Mais la valeur peut également dépendre de la criticité de la procédure ; par exemple une approche nécessitant une performance de navigation élevée ( « Low RNP » pour Low Required Navigation Procédure ) peut avoir une valeur plus élevée qu’une procédure traditionnelle ayant de moindres besoins de précision. Le contenu qui est mis à jour est la structure de la procédure au format standardisé et partagé par exemple (Arinc 424, Arinc 816). Pour une base de données de type MAGVAR, la valeur peut être liée à la rareté du point publié (routes aériennes faiblement traversées). Le contenu mis à jour est la déclinaison magnétique au point géographique considéré (latitude/longitude), par utilisation de capteurs à bord (e.g. GPS, centrales inertielles, magnétomètres …). Pour une base de données terrain ou obstacles, la valeur peut être liée à la criticité de la modification par rapport aux risques de collision: présence de grues à proximité d’un axe d’approche d’un aéroport par exemple, changement de place d’obstacles, etc. La valeur peut être liée également à la présence d’artefacts dans la base de données terrain (e.g. erreurs dans la base, altitude réelle différente de l’altitude codée, finesse du maillage de la base mise à jour, etc). La valeur peut etre être supérieure aux alentours de zones de décollage et atterrissage par rapport à des zones de survol. Le contenu mis à jour est une élévation du terrain / obstacle pour un point donné (latitude/longitude). Pour un obstacle, son type peut également être mise à jour, ainsi que des données géométriques (rayon, épaisseur …). Pour une base de données météo, le contenu peut être la mesure de vents et températures en un point donné de l’espace (latitude/longitude/altitude) ; cela peut être la présence de convections (polygone nuageux en 3D), etc. La valeur peut dépendre des performances que le phénomène météo peut engendrer (e.g. gain de carburant pour des vents forts arrière par exemple, risques de confort pour des zones de turbulence, etc). La donnée étant plus évolutive, la valeur peut être liée à la fraicheur de cette dernière (e.g. heure de publication de la donnée). La valeur d’une mise à jour peut également être convertie en monnaie réelle, ou en allègement de taxes ou un quelconque autre avantage. Dans le cas d’une base de données de navigation, la validation d’une procédure de vol liée à un aéroport peut se traduire par une réduction des taxes d’atterrissage pour la compagnie qui est à l’origine de la validation, sur cet aéroport. Elle peut aussi se traduire par des avantages sur les créneaux de décollage/atterrissage, des priorités sur des survols de routes aériennes fréquentées. Toute combinaison de ces modes de calcul est envisageable. Dans un mode de réalisation, les modalités de calcul de ces valeurs sont inscrites dans un contrat intelligent. Le contrat peut-être bipartite (accord entre 2 acteurs) ou multipartite (accord entre 1..N fournisseurs et 1..M consommateurs). Exemples de mode de réalisation - Architectures Différentes architectures informatiques sont possibles. Un exemple d’architecture informatique est décrit ci-après. Des fournisseurs de données remplissent tout d’abord leurs bases de données avec de nouvelles données. Un contrat intelligent de « mise à disposition » détecte les nouvelles données stocke des métadonnées dans une chaîne de blocs (identification, date, émetteur, score, hash du contenu des données) ; lors de la récupération (« retrieval »), un contrat intelligent de « consommation » de données se déclenche, vérifie le score de valeur de l’acheteur potentiel, vérifie (option) la réalité, la valeur ou l’intégrité de la donnée « mise à disposition » , la télécharge et l’envoie à l’aéronef demandeur. Le contrat intelligent peut également envoyer les informations du bloc correspondant de la chaîne de bloc, et le hash du contenu des données (ce qui permet à l’aéronef demandeur de vérifier l’intégrité des données). Dans un mode de réalisation, les fournisseurs producteurs de bases de données remplissent une base partagée et stockent les «hash» (fonction de hachage, e.g. CRC) des données, ainsi que les données horodatées dans une chaîne de blocs; lors d’un demande ou requête, un contrat intelligent se déclenche pour vérifier le score de valeur du consommateur et/ou producteur, et lui indique la position des données dans la base de données partagée (ou dans la chaine de blocs, avec les clefs de déchiffrement). Pour éviter des partages de clefs entre aéronefs ou les collusions, un contrat intelligent peut chiffrer à nouveau les données. Différents mécanismes DRM peuvent être implémentés (e.g. nombre d’usages capé, durée de validité, etc). De nombreuses variantes d’échanges sont possibles (stockage direct dans un contrat intelligent, une base de données tierce et/ou temporaire non représentée, clefs de chiffrement éphémères, etc). Dans un mode de réalisation, la chaine de blocs contient en temps réel le score de VS pour chaque acteur du réseau : lorsque le score d’un acteur est mis à jour, la chaine de blocs l’est également, l’utilisation de la chaine de blocs permet d’avoir cette information distribuée sur plusieurs nœuds et donc de la rendre immuable et sécurisée (ainsi que de posséder un historique certain). Ainsi lorsqu’ un fournisseur publie un jeu de données (dans la base de données ou dans un bloc de la chaîne de bloc selon les alternatives), sont ajoutés (directement par l’émetteur ou via un contrat intelligent) son VS, un timestamp (horodatage), et un moyen d’identification de la source (ID) et un moyen de valider l’intégrité du jeu de données (hash du jeu de données). Lorsqu’un consommateur récupère un jeu de données dans la chaîne de blocs, après vérification de l’intégrité (hash recalculé), cela met à jour le VS du fournisseur (ajout de la somme si le bloc est validé, retrait d‘une somme si le jeu de données était corrompu) et sa propre VS (d’une valeur inverse à celle de l’émetteur). Cette transaction peut être dans la chaîne de blocs. Dans un mode de réalisation, trois acteurs se départagent les rôles: les producteurs de mises à jour de bases de données (par exemple un fournisseur de données météorologiques ou un fournisseur de données aéroportuaires (CCI, CFMU, Eurocontrol …), les consommateurs de mises à jour (e.g. les aéronefs, les compagnies aériennes) et les entités de validation des données (e.g. les autorités de contrôle, ATC, compagnies aériennes). Un exemple de mode de réalisation est décrit ci-après. Un fournisseur décide de publier sa mise à jour d’une base de données dans la chaîne de blocs. Les données sont envoyées avec un identifiant qui permet d’identifier la source d’envoi des données, et un résumé du contenu (paramètres, unités, quantité, format) et la date. Cet ensemble forme un « bloc » à valider. Pour une mise à jour de procédure d’une base de données de navigation, il faut en général plusieurs tests, selon les catégories d’appareil (lourd, moyen, léger), les performances doivent donc être validées par classe d’appareil. Dans le système et le procédé selon l’invention, les données sont reçues et des tests sont conduits: la validation est effectuée soit par consensus ou par un « valideur » de confiance : d’autres fournisseurs ou utilisateurs des nœuds 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 nœuds ayant participé à la validation. Ce peut être le consommateur qui vérifie l’intégrité du bloc (hash). Dans une variante, le consommateur peut « noter » l’attractivité du bloc reçu (son intérêt pour lui-même). Dans une variante, cette note est donnée par le consommateur. Dans une autre option, la note est calculée par comptage du nombre de téléchargements du jeu de données et/ou par le nombre de consommateurs intéressés. Dans une variante, la note est fixée par des besoins réglementaires, par exemple, la validation d’une procédure de navigation nouvelle sur un grand aéroport fréquenté peut avoir une note élevée. Dans un mode de réalisation, la note est fixée par des besoins internationaux de couverture mondiale (cas des MAGVAR par exemple). Si les données sont déclarés comme invalides, alors la chaine de blocs peut être 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. Si les données sont considérées comme intègres, alors un nouveau bloc est créé, qui contient le lien vers les données, et une augmentation de VS_PROD d’un certain montant pour le nœud valideur. Dans un mode de réalisation, des vérifications d’intégrité sont effectuées directement et automatiquement par un contrat intelligent: à chaque nouvelle entrée dans la base (et tentative d’écriture de bloc), un contrat peut vérifier : a) si le producteur est déclaré (si il s’agit d’une chaîne de consortium); b) faire rentrer son score VS dans l’évaluation de son intégrité; c) faire rentrer sa « note » dans cette même évaluation; d) effectuer des vérifications fonctionnelles sur les données (e.g. des données issues d’un aéronef donné peuvent être corrélées/croisées avec d’autres sources d’information 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 (heure de décollage, statut (en vol, au sol, en croisière …), position courante. Du côté du consommateur, un consommateur peut s’abonner ou se déclarer intéressé pour récupérer une donnée (requête ou demande sur la chaine de blocs, ou contrat intelligent). Un contrat intelligent vérifie si l’acheteur a les moyens (VS) pour télécharger les données ; dans une alternative, le bloc d’achat est mis à disposition de valideurs qui effectuent cette vérification. Si la transaction est valide, le jeu de données (chiffré) est transmis au demandeur qui a la possibilité de vérifier son intégrité (hash récupéré dans la chaine de blocs). Si le jeu de données est réputé valide, des clefs de déchiffrement (stockées dans la chaine de blocs) sont récupérées par le contrat et transmises au demandeur. La transaction est écrite dans la chaine de blocs par le contrat intelligent. Dans des variantes de réalisation, le procédé selon l’invention comprend un mécanisme de rétribution et de validation lorsque les informations sont considérées comme valides. Dans des variantes de réalisation, le procédé selon l’invention comprend un mécanisme de notation pour rétribuer les émetteurs de données les plus utiles. Dans un mode de réalisation, un plusieurs acteurs (consommateur, producteur, validateur) peut intégrer les nouvelles données à des données existantes dans le but d’effectuer un traitement « Big Data » par des techniques d’Intelligence artificielles. Les analyses qui sont alors effectuées sur les données consolidées sont partagées (ou pas). Dans un mode de réalisation, le procédé et/ou le système selon l’invention comprend une ou plusieurs étapes de validation et/ou de mise à jour de bases de données par des équipages et/ou calculateurs embarqués dans un aéronef utilisant une chaîne de blocs , le système comprenant au moins un aéronef « émetteur » de la modification de la base de données ; au moins un acteur « consommateur de données » (ndlr : acteur = compagnie, aéronef, AOC, ATC, entreprise ….) ; des ressources de mémoire et/ou de calcul, accédées localement et/ou à distance, pour manipuler et stocker des données de l’ « émetteur », lesdites données comprenant au moins une identification des données (format, nommage, datation et/ou qualité) et leur emplacement (cloud, adresse, directement dans la chaine de blocs, le hachage des données, des clefs de chiffrement et/ou de compression, et ; des ressources de mémoire et/ou de calcul pour horodater de manière certaine des données comprenant au moins la date de mise à disposition des données et l’authentification de l’émetteur (soir en clair, soit via un « login ») ; un score de valeur étant lié au jeu de données mises à jour dans la base de données ; un mécanisme de « consommation » de la base de données mise à jour ; des ressources de calcul pour vérifier l’intégrité du jeu de données de l’émetteur (hash par ex) ; un mécanisme de rétribution de l’émetteur positif pour le score de valeur si le jeu de données est reconnu au moins intègre et négatif ou nul sinon ; un mécanisme de paiement du « consommateur », négatif ou nul pour le score de paiement si le jeu de données est reconnu au moins intègre, et négatif sinon. Dans un mode de réalisation, l’horodatage est effectué par inscription dans une chaîne de blocs, qui met en écriture le bloc lorsqu’il est produit par l’émetteur, le bloc comprenant au moins la date de mise à disposition, l’authentification de l’émetteur, et l’identification des données ainsi que leur emplacement. Optionnellement, un score est attribué à l’émetteur d’une mise à jour de la base de données fonction de la date de mise à jour et de la qualité de la validation de l’émetteur. Mise en œuvre logicielle et/ou matérielle La présente invention peut s’implémenter à partir d’éléments matériels et/ou logiciels. 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 œuvre par chaîne de blocs ne fait pas obstacle à l’existence d’une ou de plusieurs nœuds 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). Procédé mis en œuvre par ordinateur pour la gestion de bases de données aéronautiques, comprenant les étapes consistant à : - maintenir une chaîne de blocs; - ladite chaine de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs bases de données. - valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaine de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS. Procédé selon la revendication 1, lesdits calculateurs aéronautiques effectuant des tests logiques de validation et/ou apportant des preuves de déterminisme et d’intégrité des calculs des tests de validation. Procédé selon l’une quelconque des revendications précédentes, comprenant en outre une étape consistant à modifier une ou plusieurs mises à jour de données, par apport de correctifs constants, linéaires ou non-linéaires. Procédé selon l’une quelconque des revendications précédentes, la validation de tout ou partie d’une base de données, ou d’une mise à jour de données, étant en outre déterminée par un tiers de confiance prédéfini, notamment une autorité de contrôle de la navigation aérienne. Procédé selon l’une quelconque des revendications précédentes, un contrat intelligent gouvernant les droits d’accès, de lecture et/ou d’écriture dans les bases de données et/ou la chaine de blocs, notamment par la gestion de clefs de chiffrement. Procédé selon l’une quelconque des revendications précédentes, un contrat intelligent gouvernant les communications des mises à jour des bases de données entre fournisseurs de bases de données et les compagnies aériennes ou aéronefs consommant lesdites mises à jour. Procédé selon l’une quelconque des revendications précédentes, un ou plusieurs contrats intelligents déterminant un score de fiabilité associés aux parties à la chaine de blocs. Procédé selon la revendication 7, le score de fiabilité étant déterminé en fonction de paramètres intrinsèques associés aux données communiquées, comprenantnotamment la durée de vie des données, la rareté d’existence des données, une haute fréquence d’usage des données, la criticité d’une procédure associée aux données, une performance associée aux données, notamment en matière de réduction de la consommation de carburant, de la réduction du bruit ou de réduction du risque de collision entre aéronefs. Procédé selon la revendication 8 ou 7, le score de fiabilité étant déterminé en fonction de paramètres extrinsèques associés aux sources des données communiquées, comprenant notamment une réputation variable ou prédéfinie, un ratio entre téléversement et/ou téléchargement de données, ou une transaction avec une contrepartie pour augmenter ledit score de fiabilité. Procédé selon l’une quelconque des revendications précédentes, une base de données et/ou une mise à jour d’une base de données étant stockées dans une base de données centralisée et/ou directement dans la chaine de blocs décentralisée ou distribuée. Procédé selon l’une quelconque des revendications précédentes, une base de données étant sélectionnée dans le groupe comprenant une base de données de Navigation NAVDB, une base de données de déclinaison magnétique MAGVAR, une base de données de performances PERFDB, une base de données aéroportuaire AOF, une base de données terrain et/ou obstacles TAWS, une base de données météorologique WXR, une base de données de constellations satellitaires GNSS, ou une base de données de secteurs aériens ATC. Procédé selon l’une quelconque des revendications précédentes, des données des bases de données étant des données non avioniques, provenant de sources ouvertes, comprenant notamment des données du périmètre AISD, des données issues de sacs de vol électroniques ou EFB, des données issues de systèmes cabine ou IFE, et/ou des données issues de systèmes au sol. Procédé selon l’une quelconque des revendications précédentes, une chaine de blocs étant publique, avec des critères d’admission et/ou de participation du type validation par preuve de travail. Un 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. Système pour la gestion de mises à jour de bases de données aéronautiques: - au moins une chaine de blocs, ladite chaine de blocs étant configurée pour exécuter ou de plusieurs contrats intelligents; - lesdits un ou plusieurs contrats intelligents étant configurés pour valider tout ou partie d’une base de données, ou d’une mise à jour de ladite base de données, par consensus distribué parmi les parties associées à la chaine de blocs, lesdites parties étant associées à un ou plusieurs calculateurs aéronautiques, notamment des systèmes de gestion de vol FMS.