Brevet FR3107777A1 — publié le 20210903

Le document décrit des systèmes et des procédés pour la mise à jour de logiciels et/ou de bases de données avioniques d’un aéronef, comprenant les étapes consistant à : - maintenir une ou plusieurs chaînes de blocs privée entre plusieurs compagnies aériennes distinctes, une compagnie administrant un ou plusieurs aéronefs ; - une chaine de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs mises à jour de logiciels et/ou de bases de données, dites mises à jour; une mise à jour étant associée à des conditions de validité en temps et/ou en espace ; - téléverser et/ou télécharger puis installer une mise à jour dans un système de maintenance embarqué dans un système de gestion de vol desdits un ou plusieurs aéronefs en fonction de règles contenues dans un ou plusieurs desdits contrats intelligents. Des développements sont décrits. Figure pour l’abrégé : Fig. 3 MISES A JOUR DE LOGICIELS ET DE BASES DE DONNEES EN AVIONIQUE Domaine de l’invention Le document décrit des procédés et des dispositifs pour l’avionique en général, et pour la gestion de configuration de suite avionique en particulier. Etat de la Technique Le déploiement et l’installation de mises à jour logicielles et/ou de bases de données est une opération indispensable au maintien en condition opérationnelle d’un aéronef. Pour exploiter un avion, une compagnie aérienne a obligation de maintenir à jours les logiciels et les bases de données (DB) de la suite avionique (l’ensemble des logiciels et des bases de données embarquées). En particulier, elle doit aussi être en mesure de démontrer que les opérations de mises à jour de ses bases de données ont bien été effectuées. Un logiciel chargeable (« loadable » en anglais) désigne un actif informatique à déployer dans la suite avionique (ensemble des logiciels installés dans un aéronef). Cet actif informatique à déployer peut être ou comprendre une ou plusieurs bases de données (« database », DB) et/ou des logiciels («software», SW). Ces actifs dits «DB et/ou SW» par la suite, ont un format standardisé nommé « Field Loadable Software », acronyme FLS. Plus généralement, l’expression «mise à jour» concerne aussi bien les bases de données que les logiciels. Les normes aéronautiques applicables sont les normes A615, A665, A666 et A667. L’opération dite de chargement de données (« dataloading » en anglais) désigne l’opération consistant à déployer un logiciel chargeable dans la suite avionique (e.g. téléchargement, vérification, installation). Les procédures de mises à jour et notamment les étapes d’acheminement des logiciels à bord sont encore complexes et très peu automatisées. Actuellement, les modalités de mise à jour sont peu sophistiquées (e.g. récupération des mises à jour sur CD-ROM ou via un portail Internet, transfert des actifs logiciels chargeables sur un ordinateur pouvant se connecter au réseau avionique, puis enfin chargement dans la suite avionique). Ces opérations de mises à jour nécessitent la présence physique d’un opérateur dans l’avion pour pouvoir se « brancher » sur l’avionique. Toutes ces manipulations induisent des logistiques complexes et donc des couts pour les compagnies aériennes qui doivent renouveler cette opération très régulièrement (a minima tous les 28 jours pour les bases de donnée de navigation). Cette complexité et l’absence d’automatisation sont la conséquence de l’exigence d’un très haut niveau de sécurité et d’une traçabilité complète. En effet, il est impératif pour la sûreté aéronautique et la sécurité du vol de s’assurer que les actifs logiciels installés (« assets » en anglais, comprenant notamment logiciels et bases de données) ne sont pas corrompus ou piratés. Les vérifications passent aujourd’hui quasi-systématiquement par une vérification manuelle d’un opérateur de maintenance. Les mesures de sécurité consistent essentiellement en des vérifications de valeur de hachage, tout au long de la chaine, puis des vérifications diverses sur les écrans (e.g. MCDU) du système de gestion de vol. La complexité des procédures de mises à jour actuelles induisent deux problèmes majeurs. D’abord, ils impliquent des coûts importants pour les compagnies aériennes qui possèdent des flottes d’aéronefs. Ensuite, ces procédures introduisent une grande «rigidité» dans la configuration des avions. De fait, les mises à jour ne sont faites que lorsque c’est strictement indispensable. A ce jour il n’est pas envisageable de gérer finement la configuration avion (par exemple en activant une option pour certains vols uniquement, charger une base de navigation juste adaptée au besoin d’un vol, etc.). L’État de la technique décrit des recherches ou certains produits commerciaux qui visent à installer des boîtiers connectés à l’intérieur du cockpit, en vue de télécharger puis installer des produits logiciels dans l’avionique, mais ses recherches ou produits présentes des limitations (notamment en matière de sécurité informatique). Il existe un besoin pour des dispositifs ou des procédés avancés pour la distribution de mises à jour de logiciels et ou de bases de données dans un aéronef. Le document décrit des systèmes et des procédés pour la mise à jour de logiciels et/ou de bases de données avioniques d’un aéronef, comprenant les étapes consistant à : - maintenir une ou plusieurs chaînes de blocs privée entre plusieurs compagnies aériennes distinctes, une compagnie administrant un ou plusieurs aéronefs ; - une chaine de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs mises à jour de logiciels et/ou de bases de données, dites mises à jour; une mise à jour étant associée à des conditions de validité en temps et/ou en espace ; - téléverser et/ou télécharger puis installer une mise à jour dans un système de maintenance embarqué dans un système de gestion de vol desdits un ou plusieurs aéronefs en fonction de règles contenues dans un ou plusieurs desdits contrats intelligents. Des développements sont décrits. Avantageusement, l’invention permet un très haut niveau de sécurité informatique. Avantageusement, l’invention permet un transfert sécurisé de mises à jour de logiciels et/ou de bases de données depuis les serveurs de la compagnie vers le système de maintenance dans l’avion. Avantageusement, l’invention permet un transfert sécurisé de la configuration avion depuis le système de maintenance embarqué dans l’aéronef vers les serveurs de la compagnie. Avantageusement, l’invention permet des communications sécurisées entre différents acteurs (compagnies aériennes, systèmes d’information, systèmes de maintenance, etc.) Avantageusement, l’invention permet à une compagnie aérienne de vérifier à tout moment l’état de configuration d’un ou plusieurs aéronefs de sa flotte d’avions. Avantageusement, l’invention permet au pilote de vérifier à tout moment l’état de mise à jour de la suite avionique de l’avion sur lequel il vole. Avantageusement, les modes de réalisation de l’invention permettent d’automatiser le déploiement de mises à jour logicielles et/ou de base de données ce qui peut rendre cette opération extrêmement simple et rapide. Par la suite, de nouvelles approches commerciales deviennent possibles, telles que la vente de fonctionnalités et/ou de données. Jusqu’à présent, les avions d’une compagnie aérienne sont configurés de façon à pouvoir faire toutes les missions possibles. Ainsi, souvent, les compagnies préfèrent charger une base de données de navigation mondiale même si l’avion ne vole que sur un unique continent. Cela permet à la compagnie une bonne flexibilité si elle a besoin de réallouer cet avion rapidement sur une nouvelle ligne. Cependant, cette approche induit des couts supplémentaires car une base de données de navigation mondiale est significativement plus chère qu’une base de navigation européenne. La rapidité de déploiement du système permettrait dans de tel cas de ne charger que le continent concerné et, en cas de besoin, de charger rapidement à distance une carte plus étendue. Avantageusement, l’invention permet une historisation infalsifiable de la configuration avion pouvant servir de preuve de la bonne maintenance auprès des autorités de contrôle. Avantageusement, la traçabilité des transactions effectuées sur une chaîne de blocs permet des facturations à l’usage. 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 du procédé 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 être un mobile 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). Il est décrit un procédé mis en œuvre par ordinateur pour la mise à jour de logiciels et/ou de bases de données avioniques d’un aéronef, comprenant les étapes consistant à :- maintenir une ou plusieurs chaînes de blocs privée entre plusieurs compagnies aériennes distinctes, une compagnie administrant un ou plusieurs aéronefs ;- une chaine de blocs comprenant un ou plusieurs contrats intelligents ; un contrat intelligent gouvernant la gestion d’une ou de plusieurs mises à jour de logiciels et/ou de bases de données, dites mises à jour; une mise à jour étant associée à des conditions de validité en temps et/ou en espace ;- téléverser et/ou télécharger puis installer une mise à jour dans un système de maintenance embarqué dans un système de gestion de vol desdits un ou plusieurs aéronefs en fonction de règles contenues dans un ou plusieurs desdits contrats intelligents. La chaine de blocs utilisée est privée (mais un mode de réalisation à chaine de blocs publique reste possible). 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. Une compagnie aérienne exécute un ou plusieurs nœuds, ou parties de nœuds. Les limitations en temps et en espace permettent une granularité ajustée, cad permettent de manipuler ce qui est strictement nécessaire. Ceci évite ou minimise l’injection de code malveillant ou accidentellement systémique. Les compagnies aériennes ou les fournisseurs de données peuvent être en charge de publier sur la chaine de blocs des packages (ou paquets) de mises à jour auxquels seront associés des conditions de validité. Dans un développement, l’étape consistant à installer une mise à jour est déclenchée après validation humaine, par exemple sur ordre du pilote, ladite validation étant déterminée après un ou plusieurs tests biométriques, de défi-réponse et/ou physiologiques. La distinction entre homme et machine est changeante et le niveau de difficulté doit croître plus rapidement que l’augmentation de la puissance de calcul des machines, de manière à garantir que l’humain reste dans la boucle (« human in the loop »). Le pilote mais également d’autres participants peuvent déclencher la mise à jour. Les tests peuvent donc être multipliés (signature biométrique, etc). Un test défi-réponse comprend notamment un test Captcha, mais aussi toutes ses variantes pour discriminer l’humain et la machine, y compris dans ses développements d’apprentissage automatique. En particulier, les tests peuvent être choisis au hasard (palette unique à chaque fois). Dans un développement, l’étape consistant à installer une mise à jour est effectuée préalablement dans une machine virtuelle isolée du système de maintenance embarqué concerné, un temps minimal de mise en quarantaine étant mis en œuvre avant l’installation effective. Les modifications apportées peuvent être au moins temporairement isolées, afin d’éviter ou de minimiser l’installation de code malveillant. Dans un développement, un ou plusieurs contrats intelligents implémentent des tests logiques portant sur l’intégrité des mises à jour et/ou la cohérence de la mise en œuvre des mises à jour de données, notamment des vérifications de la validité des configurations-avions, une configuration-avion comprenant des combinaisons préalablement autorisées de logiciels et/ou de bases de données. Les tests de compatibilité sont préparés en amont de l’installation (« secured boot », etc), mais peuvent l’être pendant l’installation et continués après mise à jour. Ceci évite ou minimise l’injection de code malveillant ou accidentellement systémique. Par risque systémique, il est signifié qu’un système complexe (un assemblage de codes logiciels) peut voir son comportement global grandement modifié par de petites modifications apportées au code. L’avantage d’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é). Un contrat intelligent pourra fournir des services de vérification automatique de la validité des configurations. 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, les mises à jour de logiciels et/ou de bases de données avioniques sont stockées et/ou transmises de manière chiffrée, le chiffrement étant de type post-quantum. Dans un mode de réalisation, une chaîne de blocs privée est utilisée (e.g. sans épreuve d’admission autre que de l’authentification forte, accessible aux compagnies aérienne et aux systèmes de maintenance des avions. Les mises à jour peuvent potentiellement révéler des patchs, i.e. des vulnérabilités. Un chiffrement post-quantum permet d’éviter la divulgation de failles, mêmes historiques, à un attaquant. Les données « at rest » ou communiquées peuvent être chiffrées. De façon optionnelle, une chaine de blocs peut aussi servir comme moyen de transfert sécurisé des données entre les fournisseurs et les compagnies. Dans un développement, l’intégralité du code avionique est stocké et rendu accessible via lesdites une ou plusieurs chaines de blocs. Ce mode de réalisation renverse la perspective : au lieu de « patcher » (appliquer une mise à jour) un code embarqué existant et monolithique, il s’agit de télécharger et d’exécuter en partant de zéro les seules sous-parties (nécessaires et suffisantes) d’un code monolithique stocké et mis en œuvre dans une chaines de blocs. Plus généralement encore, l’utilisation de plusieurs chaines de blocs permet des modes de réalisation sophistiqués. Par exemple, une chaine de blocs dite principale peut stocker et manipuler le code principal avionique (FMS, FWS, etc), tandis que des chaines de blocs secondaires adresseront des domaines fonctionnels précis. Dans un développement, des requêtes de téléversement et/ou de téléchargement s’effectuent via des publications de l’état des configurations avion et/ou par des abonnements automatiques, par les aéronefs ou les compagnies aériennes, à des types de mises à jour prédéfinis. Les systèmes de maintenance embarqués pourront par la suite automatiquement récupérer les mises à jour depuis la chaine de blocs pour les rendre disponible pour le déploiement dans la suite avionique. Pour répondre aux besoins de traçabilité, le procédé peut inclure un mécanisme régulier de publication de la configuration avion dans la chaine de blocs par le système de maintenance embarqué. Dans un développement, un contrat intelligent comprend du code lisible en clair et une partie de code sous forme chiffrée. Il s’agit ici de conjuguer le meilleur des deux mondes : un contrat intelligent peut contenir à la fois du code ouvert (« open source », auditable) et du code fermé (« binary code »). Le code fermé (chiffré) peut être durci (hardened code, obfusqué) de manière à protéger les informations les plus sensibles. Dans un développement, les mises à jour de logiciels et/ou de bases de données avioniques sont stockées dans une base de données centralisée. Dans un développement, les mises à jour de logiciels et/ou de bases de données avioniques sont échangées de pair à pair entre aéronefs, éventuellement de compagnies aériennes distinctes. Ce mode de réalisation est particulièrement résilient, si la connectivité le permet. Les aéronefs en vol peuvent coopérer pour conduire leurs mises à jour (propagation de proche en proche). Dans un développement, un téléchargement et/ou un téléversement de mise à jour est associée à une transaction avec une contrepartie. La contrepartie peut être un jeton cryptographique, un montant de crypto-monnaie ou un montant exprimé en monnaie fiduciaire. De plus, en s’appuyant sur la traçabilité de la BC, un tel système rend possible la facturation « à l’usage » de fonctionnalités ou de DB avionique. Un tel procédé permettra de largement simplifier le déploiement de mise à jour logicielle ou DB dans le avion ce qui constituera une très source d’économie pour les compagnies aérienne. Dans un développement, le chiffrement est asymétrique, une clef publique étant associée à l’identifiant d’un aéronef et une clef privée étant associé au système de maintenance embarquée dudit aéronef. Dans un développement, un contrat intelligent est multipartite à N parties, les parties comprenant un ou plusieurs parties parmi un fournisseur de données, une compagnie aérienne et une autorité de la régulation aérienne. 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 Il est décrit un système pour la gestion du trafic aérien comprenant des moyens pour la mise en œuvre d’une ou de plusieurs étapes du procédé, notamment: - un ou plusieurs aéronefs, chaque aéronef comprenant un système de maintenance ;- au moins une chaine de blocs, ladite chaine de blocs étant configurée pour l’exécution d’un ou de plusieurs contrats intelligents;- lesdits un ou plusieurs contrats intelligents étant configurés pour - des calculateurs aéronautiques, par exemple un système de gestion de vol ou FMS, associés directement à la chaîne de blocs en lecture et/ou écriture, et/ ou indirectement à la chaîne de blocs par l’intermédiaire desdits un ou de plusieurs contrats intelligents. La 1 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 « 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. 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 aéronef 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). Contrats intelligents 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 »). 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 selon l’invention. Dans un mode de réalisation, les parties à la chaîne de blocs comprennent une ou plusieurs compagnies aériennes et un ou plusieurs aéronefs. Les compagnies aériennes peuvent être en charge de i) définir pour chaque avion une ou des configurations avioniques stockées dans la chaîne de blocs et/ou ii) d’ajouter des conditions de validité (en temps et/ou en espace) à chaque configuration avion Les aéronefs comprennent un système de maintenance embarquée lequel peut être en charge de i) publier périodiquement, et donc d’horodater, sur la chaîne de blocs l’état de sa configuration avion; ii) de récupérer auprès de la chaîne de blocs, la configuration attendue par la compagnie aérienne (en accord avec les conditions de validité) et iii) d’effectuer les mises à jours automatiquement si besoin (incluant la publication de la nouvelle configuration avion sur la chaîne de blocs) Dans un mode de réalisation, ces configurations avion pourront se matérialiser par l’entremise d’un ou de plusieurs contrats intelligents. En particulier, à fin d’assurer la confidentialité des paquets DB et/ou SW, ces derniers pourront être publiés sur la chaîne de blocs de manière chiffrée, par exemple avec la clef publique de l’avion auquel ils sont destinés. Ainsi, suite au téléchargement du paquet DB et/ou SW depuis la chaîne de blocs, le système de maintenance embarquée pourra le déchiffrer en utilisant la clé privée de l’avion à sa disposition. Le système de maintenance embarqué peut être hébergé dans un calculateur du monde ouvert connecté à l’avionique, ou bien directement être hébergé dans le monde avionique. Le système de maintenance à un accès direct ou indirect (via une passerelle sécurisée) au réseau de la chaîne de blocs. Comme dans toute chaîne de blocs, l’identité d’une partie est vérifiée à travers le fait elle possède une clé privée, celle-ci devra donc être implantée et stockée de façon sécurisée dans le système de maintenance de l’avion. Dans un mode de réalisation, une chaîne de blocs est une chaîne de blocs privée, i.e. pour laquelle le mécanisme de consensus est géré par un nombre restreint de nœuds connus. Ces nœuds connus peuvent être administrés par un groupe ou consortium en charge de la gestion de cette chaîne de blocs. Dans un mode de réalisation, les mécanismes de consensus mis en œuvre par ces nœuds seront des mécanismes légers et classiques de type Paxos, RAFT ou algorithme BFT. Les validations par preuve de travail ne sont en effet pas pertinentes pour une chaîne de blocs privés dont les nœuds sont connus et sûrs. Dans un mode de réalisation spécifique (gestion élargie du trafic aérien, notamment ou drone), la chaîne de blocs utilisés peut être de type public et des épreuves d’admission par validation de preuve de travail peuvent être mises en place. Certaines adaptations peuvent être mises en œuvre (e.g. limitations quant au nombre de transactions, limitation du volume de données échangées etc. Dans un mode de réalisation, une paire de clefs est générée pour chaque compagnie aérienne (comprenant une clé publique et une clef privée). La clé privée est conservée par la compagnie aérienne et sert à signer les packages (confer étape 220). La clé publique est l’identifiant de la compagnie sur la chaîne de blocs (à travers sa valeur de hachage). Dans un mode de réalisation, une paire de clefs est générée pour chaque avion ou aéronef. La clé privée est conservée par le système de maintenance embarquée (dans un module informatique de confiance e.g. un TPM, par exemple). La clef publique est l’identifiant de l’avion ou de l’aéronef sur la chaîne de blocs (à travers sa valeur de hachage). Dans un mode de réalisation, un registre distribué sera maintenu à jour, afin d’associer à chaque avion à la compagnie aérienne qui l’administre (dit autrement il existe une table d’association entre l’identifiant avion et l’identifiant compagnie) Ce registre permet au système avion de savoir quelle est l’adresse dans la chaîne de blocs qui dispose du droit de lui les logiciels et/ou bases de données chargeables. dans un mode de réalisation, l’administration de ce registre se fait via un ou plusieurs contrats intelligents. Dans un mode de réalisation, un contrat intelligent permet notamment à une compagnie d’ajouter un nouvel identifiant avion (qui sera associé à son identifiant compagnie) et un contrat qui fait intervenir deux compagnies (signés par les deux compagnies) permettant le transfert de la gestion d’un avion. Dans une variante de réalisation, le registre distribué peut être remplacé par la contraire imposée aux compagnies de stocker l’identifiant de la compagnie aérienne dans le système de maintenance embarqué. Dans un mode de réalisation, un aéronef connaît la signature de sa compagnie, à fin de n’accepter que les ordres (ou commandes ou instructions) de téléchargement, téléversement ou d’installation (d’un ou de plusieurs logiciels et/ou de bases de données). Dans un mode de réalisation, le procédé de mise à jour d’un aéronef comprend les étapes consistant à: A l’étape 210, une compagnie aérienne parmi plusieurs récupère auprès de son fournisseur de données un ensemble de nouvelles DB et/ou SW à déployer (télécharger et installer). Optionnellement, la compagnie aérienne récupère également une période de validité prédéfinie pour les DB et/ou des consignes de compatibilité pour les DB et/ou SW. A l’étape 220, pour un aéronef donné, la compagnie aérienne détermine un paquet de DB et/ou SW à déployer sur ledit aéronef. Ce package est encodé avec la clé publique de l’avion et signé par la compagnie. A l’étape 230, la compagnie aérienne s’assure de la cohérence de la configuration avion une fois les DB et/ou SW installés (compatibilité avec les DB et SW déjà en place). A l’étape 240, la compagnie aérienne publie sur la chaîne de blocs le paquet DB et/ou SW accompagné des métadonnées, comprenant une ou plusieurs des données suivantes: conditions d’utilisation et/ou d’installation (e.g. intervalle temporel et/ou en espace concernant la validité de la configuration avion par exemple), identifiant de l’aéronef destinataire, etc. En effet, il peut parfois être souhaitable de déployer (télécharger, installer), la configuration dans l’aéronef considéré que dans des conditions prédéfinies, par exemple dans d’une zone géographique donnée et ou à une période donnée. La publication de données sur la chaîne de blocs peut être effectuée de diverses manières. Dans un mode de réalisation, les données sont publiées en clair dans la chaîne de blocs. Dans un mode de réalisation, les données sont chiffrées puis publiées dans la chaîne de blocs. Dans un mode de réalisation, les données sont associées à un ou plusieurs contrats intelligents hébergés dans et mis en œuvre par la chaîne de blocs. Tout ou partie des données peuvent en effet être exécutables. Dans un mode de réalisation, certaines données peuvent n’être exécutées que par le système de maintenance de l’aéronef considéré (et exclusivement ce système de maintenance). autrement dit, une fois déclenchée, le contrat intelligent permet au système de maintenance de l’aéronef d’accéder aux DB et/ou SW. Dans un mode de réalisation, un système de notification peut être mis en œuvre. Par exemple, en effectuant une transaction prédéfinie (de jetons cryptographique) entre la compagnie aérienne et le système de maintenance de l’avion, il peut être déterminé qu’une action est attendue de la part du système de maintenance embarquée dans l’avion (en l’espèce le téléchargement et l’installation d’un paquet DB et/ou SW). Dans une variante de réalisation, la compagnie aérienne ne publie dans la chaîne de blocs que les métadonnées et une valeur de hachage du paquet DB et/ou SW. Ledit paquet DB et/ou SW peut être rendu accessible pour le système de maintenance de l’aéronef par d’autres moyens (e.g. serveur centralisé, transfert via des média physiques, etc) Dans un mode de réalisation, le système de maintenance embarqué procède périodiquement à une ou plusieurs vérifications. Une étape de vérification peut notamment comprendre une étape consistant à vérifier l’existence d’un nouveau paquet DB et/ou SW. Ces vérifications peuvent être périodiques (la période de vérification peut être de l’ordre de la minute). Le cas échéant, si un nouveau paquet DB et/ou SW est disponible, le système de maintenance embarqué le télécharge et le stocke à bord de l’avion. Dans le cas où l’aéronef serait hors connexion, le téléchargement pourra se faire de manière opportuniste (cloud avionique, escale, si l’avion est hors connexion il devra attendre pour récupérer le package, il est de la responsabilité de la compagnie de placer publier les package suffisamment tôt dans la BC pour que le système embarqué au pu le télécharger à temps. En se fondant sur les métadonnées associées au paquet, le système de maintenance embarquée peut passer en mode «mise à jour disponible» (« update available » en anglais), par exemple des que les conditions définies dans les métadonnées du paquet sont réunies (critères temporels et/ou d’espace). Si les conditions ne sont plus réunis, le système sort du mode « update available » et l’étape 260 est interdite. Dans un mode de réalisation, si le système de maintenance embarqué est en mode «mise à jour disponible » et si l’avion est dans une phase de sa mission compatible avec le téléchargement et/ou l’installation (par exemple avion au sol, phase de vol compatible, connectivité suffisante, etc.), alors une opération ou confirmation manuelle effectué depuis l’aéronef peut déclencher le déploiement du paquet DB et/ou SW dans la suite avionique. Dans un mode de réalisation, un déclenchement manuel i.e. humain peut être nécessaire pour des raisons de sûreté aéronautique. Avantageusement, l’initiative humaine du déclenchement de la mise à jour peut prévenir tout risque de mise à jour intempestive et gênante, voir dangereuse pour les opérations. Dans d’autres modes de réalisation, moyen terme, ce déclenchement peut être entièrement automatique. Dans un mode de réalisation manuelle, il est parfois requis d’utiliser des stockages sur support amovible (e.g. carte SD, compact flash, etc.) les manipulations de support se font alors par un opérateur (ou un pilote) dans le cockpit. Dans un mode de réalisation, une chaîne de blocs peut également être utilisée comme moyen de transfert des paquets DB et/ou SW, notamment entre les fournisseurs de données et les compagnies aériennes. Les fournisseurs de données, le cas échéant peuvent publier sur la chaîne de blocs les nouvelles versions des paquets qu’ils produisent. À travers l’utilisation d’un ou de plusieurs contrats intelligents, les compagnies aériennes peuvent récupérer ces paquets et les déployer sur leurs aéronefs. Les avantages de ce mode de réalisation dans lequel la chaîne de blocs sert également au stockage des paquets comprennent une sécurité accrue, dans la mesure où le chiffrement peut s’effectuer de bout en bout. La suppression des intermédiaires peut améliorer la sécurité car tout intermédiaire peut être considéré comme un point de vulnérabilité. Dans un mode de réalisation, la chaîne de blocs peut prendre en charge la partie transactionnelle des achats de paquets. Une transaction peut comprendre la communication d’un l’objet avec une contrepartie financière. Dans un mode de réalisation, la cohérence des versions de logiciels dans une suite avionique est un problème technique important à gérer pour les services de maintenance des compagnies. Certaines bases de données ne sont compatibles qu’avec certaines versions de logiciels, certaines versions de logiciels sont incompatibles entre elles, etc. Dans un mode de réalisation, les constructeurs ou intégrateurs avioniques peuvent publier sur la chaîne de blocs des contrats intelligents pour la vérification des configurations avion. 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). 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 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. Procédé mis en œuvre par ordinateur pour la mise à jour de logiciels et/ou de bases de données avioniques d’un aéronef, comprenant les étapes consistant à: - maintenir une ou plusieurs chaînes de blocs privée entre plusieurs compagnies aériennes distinctes, une compagnie administrant un ou plusieurs aéronefs; - une chaine de blocs comprenant un ou plusieurs contrats intelligents; un contrat intelligent gouvernant la gestion d’une ou de plusieurs mises à jour de logiciels et/ou de bases de données, dites mises à jour; une mise à jour étant associée à des conditions de validité en temps et/ou en espace; - téléverser et/ou télécharger puis installer une mise à jour dans un système de maintenance embarqué dans un système de gestion de vol desdits un ou plusieurs aéronefs en fonction de règles contenues dans un ou plusieurs desdits contrats intelligents. Procédé selon la revendication 1, l’étape consistant à installer une mise à jour étant déclenchée après validation humaine, par exemple sur ordre du pilote, ladite validation étant déterminée après un ou plusieurs tests biométriques, de défi-réponse et/ou physiologiques. Procédé selon la revendication 2, l’étape consistant à installer une mise à jour étant effectuée préalablement dans une machine virtuelle isolée du système de maintenance embarqué concerné, un temps minimal de mise en quarantaine étant mis en œuvre avant l’installation effective. Procédé selon la revendication 1, un ou plusieurs contrats intelligents implémentant des tests logiques portant sur l’intégrité des mises à jour et/ou la cohérence de la mise en œuvre des mises à jour de données, notamment des vérifications de la validité des configurations-avions, une configuration-avion comprenant des combinaisons préalablement autorisées de logiciels et/ou de bases de données. Procédé selon la revendication 1, les mises à jour de logiciels et/ou de bases de données avioniques étant stockées et/ou transmises de manière chiffrée, le chiffrement étant de type post-quantum. Procédé selon l’une quelconque des revendications précédentes, l’intégralité du code avionique étant stocké et rendu accessible via lesdites une ou plusieurs chaines de blocs. Procédé selon l’une quelconque des revendications précédentes, des requêtes de téléversement et/ou de téléchargement s’effectuant via des publications de l’état des configurations avion et/ou par des abonnements automatiques, par les aéronefs ou les compagnies aériennes, à des types de mises à jour prédéfinis. Procédé selon l’une quelconque des revendications précédentes, un contrat intelligent comprenant du code lisible en clair et une partie de code sous forme chiffrée. Procédé selon l’une quelconque des revendications précédentes, les mises à jour de logiciels et/ou de bases de données avioniques étant stockées dans une base de données centralisée. Procédé selon l’une quelconque des revendications précédentes, les mises à jour de logiciels et/ou de bases de données avioniques étant échangées de pair à pair entre aéronefs, éventuellement de compagnies aériennes distinctes. Procédé selon l’une quelconque des revendications précédentes, un téléchargement et/ou un téléversement de mise à jour étant associée à une transaction avec une contrepartie de type jeton cryptographique. Procédé selon l’une quelconque des revendications précédentes, le chiffrement étant asymétrique, une clef publique étant associée à l’identifiant d’un aéronef et une clef privée étant associé au système de maintenance embarquée dudit aéronef. Procédé selon l’une quelconque des revendications précédentes, un contrat intelligent étant multipartite à N parties, les parties comprenant un ou plusieurs parties parmi un fournisseur de données, une compagnie aérienne et une autorité de la régulation aérienne. 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 du trafic aérien comprenant des moyens pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 13