FR 3000195 A1 20140627 FR 1262722 A 20121221 La présente invention concerne la configuration à bord d'un système de gestion d'un aéronef (par exemple un avion). Il s'agit par exemple d'un système de gestion de vol, un système de navigation, un système de gestion d'un avion au sol, d'un système de gestion de maintenance ou autre. Pour effectuer un vol, l'équipage dispose d'un certain nombre de documents qui peuvent être directement disponibles à bord de l'aéronef ou qui peuvent être apportés par celui-ci à bord de l'aéronef à chaque vol. Les documents disponibles à bord sont par exemple: - la documentation technique de l'aéronef (description des 10 systèmes et des procédures, tolérances (MEL, sigle de Minimum Equipment List, CDL, sigle de Configuration Deviation List, ou autre), - la documentation opérationnelle de la compagnie exploitant l'aéronef, - les performances de décollage, d'atterrissage et en vol, et/ou 15 - les cartes de navigation et d'aérodromes. Les documents apportés par le pilote pour un vol donné sont par exemple le dossier de vol (plan de vol, cartes météo, ou autre). Dans les aéronefs, le système de gestion de vol (FMS, sigle de « Flight Management System » en terminologie anglo-saxonne) permet de 20 construire et suivre un plan de vol en prenant en compte les contraintes de navigation aéronautiques et les performances relatives à l'aéronef et à son environnement. Le système de gestion de vol fait partie du système avionique de l'aéronef intégré à la station de pilotage (ou « cockpit » en terminologie anglo25 saxonne), c'est-à-dire le système électronique embarqué dans l'aéronef ayant été certifié pour le pilotage. Par exemple, pour paramétrer ce système de gestion de vol, l'équipage dispose d'une documentation pour le calcul des performances de l'aéronef au décollage et à l'atterrissage. 30 Cette documentation papier se présente sous la forme de tables et d'abaques. Elle permet d'estimer les paramètres de performance utiles à la configuration du système de gestion de vol pour la réalisation du décollage et de l'atterrissage, à partir des données aéronef et environnementales. Les données aéronefs sont par exemple : - les paramètres de chargement de l'aéronef : masse et répartition 5 de masse, quantité de carburant embarqué, et/ou - la configuration de l'aéronef : systèmes utilisés impactant les performances de l'aéronef (dispositifs consommant de la puissance des moteurs ou dégradant les performances aérodynamiques de l'aéronef) et systèmes en panne ou absents et affectant les performances. 10 Les données environnementales sont par exemple : - les paramètres de la piste utilisée : état du revêtement (type de revêtement et état en fonction de la météorologie), pente, type d'approche utilisé dans le cas d'un atterrissage, obstacles le long de la trajectoire de montée ou de descente, et/ou 15 - les conditions météorologiques : température, pression atmosphérique, vent. Les données d'un vol ne sont pas forcément exactement celles proposées comme entrée des tables et abaques. L'équipage choisit alors dans sa documentation les valeurs se rapprochant le plus de sa situation réelle pour 20 estimer les paramètres de performances au décollage et à l'atterrissage. Les performances de décollage et d'atterrissage estimées sont utilisées notamment pour : - s'assurer que la longueur de piste disponible est suffisante, et/ou - procéder à la manoeuvre de décollage ou d'atterrissage aux 25 vitesses et pentes proposées par le calcul. Ces données' peuvent également être entrées dans le FMS pour la gestion du plan de vol. Anciennement, la documentation était transportée par les pilotes dans une sacoche. Ceux-ci utilisaient uniquement le format papier pour 30 effectuer des calculs de paramètres pour configurer le système de gestion de vol. Le pilote choisissait une valeur d'entrée parmi celles proposées dans les tables de la documentation papier, en essayant de s'approcher le plus possible de celle dont il avait besoin. Le pilote estimait ensuite une valeur approchée à ses résultats en les minorant ou majorant en fonction de l'écart par rapport à ses données d'entrée. Au final les résultats obtenus n'étaient pas totalement optimisés. En outre, un nombre limité de paramètres d'entrée pouvait être pris en compte. Rajouter des paramètres pour affiner les résultats nécessitait de rajouter davantage de tables et d'étapes de calcul, ce qui rendait la configuration plus complexe. Avec l'utilisation du format papier, le calcul des paramètres était complètement séparé de la gestion de vol avec l'avionique de l'aéronef. En effet, le pilote devait reprendre les données d'entrée venant de ses systèmes dans sa documentation papier, effectuer son calcul à la main puis recopier les données de performance dans l'interface du système de gestion de vol. Cela créait un risque d'erreur et rompait le flux de travail avec le système avionique de l'appareil, ce qui limitait l'ergonomie de la station de pilotage. Plus récemment, la documentation contenue dans une sacoche a été remplacée par un dispositif informatique désigné sous le sigle EFB (pour « Electronic flight bag »). Les EFB permettent de réaliser des calculs de grande précision grâce à l'utilisation de formules de calcul plus complexes et précises, ce qui n'est pas possible avec le format papier et l'utilisation d'abaques. Un EFB actuel, comme illustré par la figure 1, se présente sous la forme d'un ordinateur 10 (par exemple un PC portable, une tablette ou autre) avec un écran dédié permettant la visualisation des documents et cartes ainsi que l'utilisation de logiciels de calcul de performance pour chaque phase de vol (masse et centrage, performances de décollage, performances d'atterrissage, performances en vol, ou autre). Les EFB peuvent être connectés au système avionique, par exemple 30 via un câble de connexion 12 afin de récupérer certains paramètres avioniques généraux comme l'origine et la destination du vol par exemple. Cette connexion se fait donc dans un sens unique, les données allant du système avionique vers l'EFB. L'EFB est considéré comme un système appartenant au « monde ouvert», c'est-à-dire qu'il n'appartient pas au système avionique. Les systèmes du monde ouvert peuvent être disposés dans un aéronef pour un usage dédié au pilotage ou à l'apport de fonctionnalités dans la cabine passager. Ils peuvent être certifiés ou non. Ces systèmes peuvent ne pas nécessiter de certification au sens de la norme DO 178B. Cependant, pour pouvoir être utilisés en vol, une approbation opérationnelle délivrée par une autorité aérienne peut être nécessaire. En outre, le développement des systèmes du monde ouvert peut reposer sur des technologies grand public, telles que les technologies dites « COTS » (sigle de « Commercial Off-The-Shelf »). Ce développement repose parfois sur des ordinateurs de type « PC » (sigle de « Personal Computer »). Les systèmes du monde ouvert peuvent permettre l'intégration d'applications développées par d'autres que le constructeur du système (par exemple des compagnies aériennes, des sociétés spécialisées ou autre). L'EFB est un dispositif approuvé opérationnellement par les autorités locales de chaque pays. L'EFB est ainsi indépendant du système avionique intégré à la station de pilotage. L'EFB étant approuvé opérationnellement, il jouit d'une flexibilité dans la gestion de ses données et de ses mises à jour ainsi que dans les évolutions de son interface utilisateur. Cependant, la communication avec le système avionique (qui lui est certifié) est restreinte. L'EFB peut recevoir des données du système avionique sans en envoyer. Ainsi, un EFB actuel de classe I ou II ne peut pas insérer de données dans le système avionique, par exemple pour configurer un système de gestion de vol avec des paramètres qu'il a calculés. L'incapacité à insérer des données EFB dans le système avionique conduit à une procédure équipage où après l'insertion des résultats effectuée par le PF (Pilot Flying) dans le système avionique, le PNF (Pilot Non Flying) doit vérifier l'exacte similarité entre les données insérées dans le système avionique et les données calculées et disponibles dans l'EFB. Du fait de cette communication dans un seul sens, le pilote doit nécessairement reporter les paramètres calculés par l'EFB dans le système 5 avionique (par exemple le système de gestion de vol). En revanche l'EFB est un équipement du « monde ouvert » qui ne bénéficie pas du même niveau de sureté que les éléments du système avionique embarqué comme le système de gestion de vol FMS. Il peut donc récupérer certaines données d'entrée depuis l'avionique mais ne peut pas en 10 renvoyer, en raison des risques de corruption des données. Le pilote doit donc recopier à la main ses résultats de calcul dans l'interface utilisateur du système de gestion de vol FMS. En outre, la quantité de données d'entrée qui peuvent être récupérées depuis l'avionique dépend du type d'EFB et de l'aéronef. Les 15 limitations inhérentes au bus de données principal limitent fortement la communication avec un ordinateur conventionnel. Les bus de données dans les aéronefs ne sont pas toujours compatibles avec les bus de données des ordinateurs conventionnels (c'est-à-dire non spécifiques aux systèmes avioniques). 20 Par ailleurs, l'interface utilisateur de l'EFB est présentée sur un écran différent de celui du FMS. C'est également le cas du clavier (non représenté) et du pavé tactile (ou « touchpad » en terminologie anglo-saxonne, non représenté) de l'EFB qui sont une interface indépendante du clavier 13 et de la boule de commande (ou « trackball » en terminologie anglo-saxonne, non 25 représentée) du FMS. Il y a donc ici aussi une rupture du flux de travail qui oblige le pilote à passer d'un périphérique à l'autre pour préparer son plan de vol sur le FMS, faire son calcul de performances sur l'EFB et inclure les résultats de calcul dans le FMS. Enfin, la puissance de calcul des systèmes avioniques est limitée, ce 30 qui peut écarter les solutions où le calcul de performance optimisé serait complètement intégré au système avionique. Les calculs à effectuer ne le seraient pas dans des conditions optimales, comme c'est le cas avec les ordinateurs du monde ouvert qui eux, disposent de la puissance de calcul nécessaire. Ainsi, il existe un besoin pour améliorer la configuration du système de gestion des aéronefs, notamment les systèmes de gestion de vol. La présente invention s'inscrit dans ce cadre. Un premier aspect de l'invention concerne un procédé de configuration d'un système de gestion d'aéronef comportant les étapes suivantes, mises en oeuvre par un module de configuration intégré au système avionique de la station de pilotage de l'aéronef: - obtention d'au moins une donnée de calcul d'au moins un paramètre de configuration du système de gestion, - transmission, à destination d'un module de calcul indépendant du système avionique de la station de pilotage de l'aéronef, d'une requête de calcul dudit au moins un paramètre à partir de ladite au moins une donnée de 15 calcul, - réception, de la part dudit module de calcul, dudit au moins un paramètre calculé, et - configuration dudit système de gestion avec ledit au moins un paramètre calculé reçu. 20 Le procédé selon le premier aspect offre un compromis entre d'une part, l'utilisation d'un module de calcul dans le « monde ouvert » (c'est-à-dire ne faisant pas partie du système avionique) pour effectuer le calcul des paramètres et, d'autre part, une continuité du flux de travail pour le pilote. Par exemple, le système de gestion est un système de gestion de 25 vol, un système de navigation, un système de gestion d'un avion au sol, d'un système de gestion de maintenance ou autre. Le procédé repose sur une architecture partagée entre le système avionique et le monde ouvert. L'interface avec le pilote et le système de gestion est gérée dans le système avionique. Les calculs de paramètres sont effectués 30 à l'extérieur du système avionique. Ainsi, on conserve les capacités de calcul importantes offertes dans le monde ouvert tout en offrant au pilote une interface pour la configuration du système de gestion intégrée au système avionique. Le procédé peut en outre comporter, préalablement à la transmission de ladite requête de calcul, une étape de transmission, à destination dudit module de calcul, d'une requête de vérification de cohérence de ladite au moins une donnée de calcul, afin que la transmission de la requête de calcul soit faite en fonction de ladite vérification de cohérence. Ainsi, il est possible de détecter avant le lancement du calcul de 10 paramètres, des erreurs dans les données à traiter. Cela évite au système avionique de recevoir des paramètres erronés. Cette mesure renforce la communication entre le module de configuration dans le système avionique et le module de calcul qui lui, fait partie du monde ouvert. 15 Par exemple, ladite requête de vérification de cohérence concerne un bloc comprenant une pluralité de données de calcul. Ainsi, on optimise le flux de communication entre le module de configuration et le module de calcul. En outre, il est ainsi possible d'effectuer une vérification de 20 cohérence des données entre elles, par exemple en détectant deux données de calcul incompatibles entre elles. Cette mesure peut également renforcer la communication entre le système avionique et le module de calcul qui lui n'en fait pas partie. Elle peut permettre de traiter les erreurs de saisie du pilote au fur et à mesure de leur 25 entrée dans le système avionique. Elle évite ainsi une accumulation d'erreurs tout au long du processus de saisie par le pilote, qui au final peut devenir difficile à corriger de manière logique du fait du nombre trop important d'erreurs. Suite à la réception dudit au moins un paramètre calculé, le procédé peut en outre comporter une étape de vérification de corruption des données de 30 calcul. Cette étape permet de renforcer la sécurité de la communication du système avionique en le préservant d'erreurs dues à la transmission du paramètre calculé. La vérification peut par exemple se faire au sein du système avionique. Par exemple, ledit au moins un paramètre calculé est accompagné d'au moins une donnée de calcul utilisée par le module de calcul pour le calculer, et ladite étape de vérification de corruption des données de calcul comporte la comparaison de ladite au moins une donnée de calcul déterminée et de ladite au moins une donnée de calcul utilisée pour calculer ledit au moins un paramètre calculé. Le procédé peut en outre comporter une étape de vérification de l'intégrité dudit au moins un paramètre calculé reçu. Ainsi, avant d'accepter le paramètre calculé par le module de calcul, le module de configuration peut vérifier que celui-ci a été calculé conformément à sa requête. Cette mesure permet encore d'assurer une communication plus sûre avec le module de calcul du monde ouvert. Par exemple, ladite vérification d'intégrité comporte une comparaison de deux écritures, du même au moins un paramètre calculé, reçues de la part du module de calcul. Ces deux écritures peuvent par exemple appartenir à un même message transmis par le module de calcul. L'étape d'obtention de la donnée de calcul peut comporter la réception de celle-ci via une interface utilisateur du module de configuration. Alternativement, ou en combinaison, elle peut comporter la réception de celle-ci, via une interface de communication avec un module de fourniture de données de calcul. La donnée est alors obtenue automatiquement, sans intervention du pilote. Ce mode d'obtention peut être mis en oeuvre lorsque par exemple, le pilote a déjà saisi cette donnée dans un système autre que le système de configuration. Un deuxième aspect de l'invention concerne un dispositif pour mettre en oeuvre un procédé selon le premier aspect. Par exemple, un tel dispositif de configuration d'un système de gestion d'aéronef, est intégré au système avionique d'une station de pilotage de l'aéronef et il comporte: - une unité de traitement configurée pour obtenir au moins une 5 donnée de calcul d'au moins un paramètre de configuration du système de gestion, l'unité de traitement étant en outre configurée pour configurer ledit système de gestion avec ledit au moins un paramètre calculé reçu, et - une unité de communication configurée pour transmettre, à destination d'un module de calcul indépendant du système avionique de la 10 station de pilotage de l'aéronef, une requête de calcul dudit au moins un paramètre à partir de ladite au moins une donnée de calcul, l'unité de communication étant en outre configurée pour recevoir, de la part dudit module de calcul, ledit au moins un paramètre calculé. Un troisième aspect de l'invention concerne un système pour la 15 mise en oeuvre d'un procédé selon le premier aspect. Par exemple, un tel système de configuration de système de gestion d'aéronef comporte: - un dispositif de configuration intégré au système avionique d'une station de pilotage de l'aéronef, le dispositif comportant : 20 - une unité de traitement configurée pour obtenir au moins une donnée de calcul d'au moins un paramètre de configuration du système de gestion, l'unité de traitement étant en outre configurée pour configurer ledit système de gestion avec ledit au moins un paramètre calculé reçu, et - une unité de communication configurée pour transmettre, à 25 destination d'un dispositif de calcul indépendant du système avionique de la station de pilotage de l'aéronef, une requête de calcul dudit au moins un paramètre à partir de ladite au moins une donnée de calcul, l'unité de communication étant en outre configurée pour recevoir, de la part dudit dispositif de calcul, ledit au moins un paramètre calculé, 30 et le système comporte en outre : - ledit dispositif de calcul indépendant du système avionique de la station de pilotage de l'aéronef, le dispositif de calcul comportant : - une unité de traitement configurée pour calculer, à partir de données de calcul reçues, ledit paramètre de configuration, et - une unité de communication configurée pour recevoir, de la part du dispositif de configuration, ladite requête de calcul, et pour transmettre, audit dispositif de configuration, ledit paramètre de configuration calculé. Un quatrième aspect de l'invention concerne un aéronef comportant un dispositif et/ou un système selon les deuxième et/ou troisième aspects. Un cinquième aspect de l'invention concerne un programme d'ordinateur ainsi qu'un produit programme d'ordinateur et un support de stockage pour de tels programmes et produit, permettant la mise en oeuvre d'un procédé selon le premier aspect lorsque le programme est chargé et exécuté par un processeur d'un dispositif et/ou un système de configuration de système de gestion d'aéronef. Les objets selon les deuxième, troisième, quatrième et cinquième 15 aspects de l'invention procurent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la présente description détaillée qui suit, à titre d'exemple non limitatif, et des figures annexées parmi lesquelles, en outre la figure 1 : 20 la figure 2 illustre schématiquement une architecture selon des modes de réalisation; la figure 3 illustre un exemple d'installation d'un système selon des modes de réalisation; la figure 3 illustre les interactions d'un module de configuration selon 25 des modes de réalisation; la figure 4 illustre les interactions d'un module de configuration avec un module de calcul selon des modes de réalisation; les figures 5 et 6 sont des organigrammes d'étapes mises en oeuvre selon des modes de réalisation; 30 les figures 7a et 7b illustrent la vérification de cohérence de données de calcul selon des modes de réalisation; les figures 8 et 9 illustrent des mécanismes de vérification de résultats de calcul; les figures 10 à 14 illustrent des interfaces utilisateur selon des modes de réalisation ; et la figure 15 illustre schématiquement des dispositifs selon des modes de réalisation. Le mode de configuration du système de gestion d'un aéronef décrit dans la suite repose sur l'exécution du calcul de paramètres de configuration par un module de calcul du monde ouvert (les ordinateurs du monde ouvert disposent en général de la puissance suffisante pour effectuer les calculs dans un délai raisonnable) et sur la gestion de l'interface utilisateur sur un ordinateur du domaine avionique. La suite de la description prend l'exemple d'un système de gestion de vol. Le mode de configuration du système de gestion de vol présenté dans la suite permet de disposer des avantages d'une solution de calcul totalement intégrée au système avionique (interface unique), tout en évitant les problèmes de performances liés au portage du moteur de calcul sur un ordinateur de l'avionique. La solution aux problèmes de sécurité du transfert de données entre monde ouvert EFB et domaine avionique ainsi qu'au problème de rupture du flux de travail consistant à intégrer le logiciel de calcul de performance de décollage et d'atterrissage directement dans l'avionique peut ne pas être optimal. La puissance de calcul embarquée sur un ordinateur du domaine avionique est nettement inférieure à celle disponible sur un ordinateur du monde ouvert. Le temps nécessaire au calcul de performance sur un ordinateur du domaine avionique ne serait pas acceptable opérationnellement. D'autre part, le portage des algorithmes de calcul de performance sur une plateforme certifiée (par exemple de type DO-178) serait extrêmement complexe, et dégraderait les performances de l'algorithme. En effet, les compilateurs certifiés couramment utilisés pour l'avionique sont basés sur les langages C ou ADA, et ne sont pas aussi performants que des langages comme Fortran pour des algorithmes récursifs. Or, ce type de langage est fortement utilisé pour les calculs de paramètres de configuration de système de gestion de vol (algorithmes récursifs). Les systèmes et dispositifs intégrés au cockpit font partie du domaine avionique. L'intégration au cockpit s'entend donc comme l'intégration au système avionique. Un dispositif du monde ouvert peut être physiquement installé dans le cockpit sans pour autant appartenir au système avionique et donc être « intégré » à celui-ci au sens où on l'entend dans la suite de la description. L'architecture décrite ci-après repose donc à la fois sur le système avionique et sur un système externe, indépendant du cockpit et appartenant au monde ouvert (c'est-à-dire non-avionique). Il s'agit ainsi d'une architecture hybride entre ces deux types de systèmes. Cette architecture est schématiquement représentée dans la figure 2. Un module de configuration 200 fait l'interface avec le pilote 201. Celui-ci peut saisir des données de calcul 202 pour calculer des paramètres de configuration 203 d'un système de configuration de vol 204 (FMS, sigle de « Right Management System »). Le module de configuration peut en outre afficher une interface 205 pour le pilote afin qu'il lise les données entrées et les paramètres calculés. Le module de configuration communique avec le système de gestion de vol pour transmettre les paramètres de configuration calculés. Il peut en outre recevoir des données 206 du système de gestion de vol, pour les afficher au pilote et/ou les utiliser pour le calcul des paramètres. L'interface entre le pilote et le système de gestion de vol peut toutefois être maintenue. Le pilote peut continuer à obtenir directement des données depuis le système de gestion de vol. Le pilote peut aussi continuer à entrer directement des données dans le système de gestion de vol. Cette interface est représentée par la flèche 211. L'interface entre le pilote et les autres systèmes avioniques peut aussi être maintenue. Le pilote peut continuer à obtenir directement des données depuis les autres systèmes avioniques. Le pilote peut aussi continuer à entrer directement des données dans les autres systèmes avioniques. Cette interface est représentée par la flèche 211. Le module de configuration peut en outre communiquer avec 5 d'autres systèmes avioniques 207. Il peut par exemple s'agir de l'AOC (sigle de Airline Operational Control) pour récupérer et décoder le contenu de messages météo (METAR, sigle de METeorological Aerodrome Report) et ainsi remplir automatiquement les conditions météo nécessaires au calcul de paramètre. Cela peut permettre par exemple, lors d'une panne en vol, de 10 récupérer les données de panne provenant de l'ECAM (sigle de Electronic Centralized Aircraft Monitoring) et de présélectionner les items MEL ou CDL concernés dans le module de configuration pour l'atterrissage ou le prochain décollage. Le pilote peut alors calculer sa capacité à atterrir sur le terrain initialement prévu et décider le cas échéant d'un déroutement ; ou bien le pilote 15 peut également calculer sa capacité à redécoller du terrain initialement prévu et décider de la nécessité d'une réparation. Le module de configuration communique par ailleurs avec un module de calcul 208 (qui peut par exemple être un ordinateur du monde ouvert) chargé d'effectuer les calculs de paramètres demandés par le pilote, via le 20 module de configuration. A cet effet, le module de configuration transmet au module de calcul des requêtes 209, éventuellement accompagnées de données de calcul. En retour, le module de configuration reçoit de la part du module de calcul des paramètres calculés 210 et/ou des messages d'erreur. Le module de calcul peut contenir diverses bases de données (non 25 représentées), et/ou communiquer avec de telles bases de données externes (non représentées). Il peut notamment s'agir: - d'une base aéroport qui contient les paramètres (par exemple la longueur, ou autre) de toutes les pistes utilisées pour le calcul, - d'une base de données avion qui contient des paramètres sur les 30 performances de l'avion et qui sont utilisées par le moteur de calcul, et/ou - des données de personnalisation qui vont par exemple donner le contenu des listes déroulantes utilisées dans l'interface du module de configuration. L'ensemble des données de configuration et de personnalisation 5 peuvent être stockées au sein du module de calcul, dans le monde ouvert, pour faciliter l'administration et la mise à jour du système. Un outil d'administration sur ordinateur séparé que l'on connecte au module de calcul peut permettre d'administrer ces données. Par exemple encore, un outil d'administration peut générer un ensemble de fichiers signés 10 électroniquement pouvant être téléchargés dans le NSS afin de rafraîchir ou modifier les données de configuration et de personnalisation utilisées par le module de calcul. Ainsi, on peut facilement mettre à jour un nombre important de paramètres ayant un effet sur le calcul de paramètre, l'interface, ou les bases utilisées par le pilote (pistes, bases de données de performances, ou 15 autre). Etant donné que les modules de configuration et de calcul peuvent respectivement s'interfacer avec les systèmes du domaine avionique et du monde ouvert, il est possible d'augmenter l'interactivité du calcul de paramètre. Par exemple, le module de calcul peut récupérer les éléments 20 MEL/CDL (sigle de Minimum Equipment List/Configuration Deviation List) de la documentation de l'aéronef stockée dans le monde ouvert et transférer les éléments utiles au module de configuration. Cela peut par exemple permettre, lors d'une panne ECAM (sigle de Electronic Centralized Aircraft Monitoring) en vol de récupérer dans le calcul les éléments MEL associés pour le prochain 25 décollage. En fonction de la possibilité d'une réparation à la prochaine étape, le pilote peut alors vérifier ses capacités à redécoller de cette étape avec cette panne. Dans la suite, on prend à titre d'illustration, la configuration d'un système de gestion de vol avec le calcul des performances de décollage et 30 d'atterrissage de l'aéronef, ce calcul sera désigné par le sigle TOPOC (pour « TakeOff and landing Performance Optimization Computation » en terminologie anglo-saxonne). Dans la suite, le module de configuration intégré au système avionique est appelé TOPOC-HMI. Ce module gère l'affichage sur écran de la station de pilotage et les interfaces avec les autres systèmes avioniques comme le système de gestion de vol FMS. Par ailleurs, le module de calcul indépendant de la station de pilotage et du système avionique est appelé TOPOC-NSS. Ce module héberge le moteur de calcul des paramètres de configuration. Il peut en outre comporter des bases de données utilisées pour le calcul ainsi que les données de configuration de l'interface utilisateur du module TOPOC-HMI. Alternativement, ces bases de données sont extérieures au module de calcul et celui-ci peut communiquer avec elles. La communication entre les deux modules repose sur plusieurs mécanismes fonctionnant séparément : - un mécanisme d'initialisation de l'application, - un mécanisme de vérification de la cohérence des données rentrées par le pilote, et - un mécanisme de vérification de la corruption des données. Ces mécanismes permettent l'utilisation de données provenant du monde ouvert dans le domaine avionique avec un niveau de sureté acceptable. Le module de configuration TOPOC-HMI permet de proposer une expérience utilisateur intégrée au reste de l'équipement avionique (en termes de tâches opérationnelles pour le pilote et d'interface utilisateur). Par exemple, comme illustré par la figure 3, le module « TOPOCHMI » est constitué de deux entités identiques et indépendantes 30, 31, dédiées chacune à un pilote. Chaque entité agit comme un client permettant au pilote de consulter sur des écrans 32, 33 ses données de performance, de les modifier, d'exécuter des calculs et de les intégrer à son plan de vol dans le système de gestion de vol FMS 34. Chaque entité est installée sur un ordinateur avionique standardisé couramment désigné CPIOM (sigle de Core Processing Input/Output Module). Le module de configuration communique avec le système d'affichage CDS (sigle de Control and Display System) du système avionique pour proposer une interface au pilote. Par exemple, cette interface apparait sur le même écran que celui affichant l'interface du système de gestion de vol FMS. Le pilote peut alors passer simplement d'une interface à l'autre à l'aide de raccourcis (boutons dans l'interface). Le module de configuration TOPOC-HMI peut également communiquer avec d'autres systèmes avioniques. Par exemple, il peut communiquer avec le système de gestion de vol FMS pour récupérer des informations de plan de vol (piste utilisée, données de chargement, ou autre) et ainsi éviter d'effectuer des saisies en double. Il peut également communiquer avec le système de gestion de vol FMS pour envoyer des résultats de calcul (configuration volets, vitesses de manoeuvres, ou autre) et ainsi éviter la lourdeur de la tâche de recopie, éviter les erreurs de copie, éviter la procédure opérationnelle qui demande au PNF (sigle de Pilot Non-Flying) d'effectuer une vérification entre les données insérées par le PF (Pilon Flying) et ses résultats. Deux pilotes peuvent effectuer deux calculs indépendants et vérifier la similarité de leurs résultats, afin d'éviter une erreur de saisie dans les entrées du calcul. Par exemple encore, le module de configuration TOPOC-HMI peut communiquer avec le système d'alerte de vol FWS 35 (sigle de « Flight Waming System » en terminologie anglo-saxonne) pour générer des alarmes 20 en cas de panne empêchant le calcul TOPOC. Le module de configuration TOPOC-HMI peut en outre communiquer avec d'autres systèmes ou dispositifs de l'aéronef tels que l'imprimante 36 pour imprimer des résultats de calcul, le système de maintenance 37 pour enregistrer les pannes rencontrées, ou autre. 25 Par exemple, toutes ces communications se font par un bus 38 de type Ethernet certifié AFDX (sigle de Avionics Full Duplex Switch Ethernet). Les ordinateurs CPIOM utilisés pour le module de configuration n'ont généralement pas la puissance nécessaire aux calculs de paramètres. Ainsi, le module de configuration gère l'interface avec le pilote et avec les autres 30 systèmes mais ne gère pas ces calculs. Ceux-ci sont délégués au module de calcul externe appartenant au monde ouvert TOPOC-NSS. Comme illustré par la figure 4, ce module de calcul 40 peut être installé dans un ordinateur 41 désigné par le sigle NSS (« Network Server System » en terminologie anglo-saxonne). Le module de calcul peut être installé dans la baie avionique ou non. Le module TOPOC-NSS est un module indépendant de la baie avionique, du système avionique ou de la station de pilotage. Pour autant, cette indépendance ne signifie pas que ce module ne peut pas être intégré physiquement (ou fixé) à la station de pilotage. L'utilisation d'un module monde ouvert permet l'emploi de langages informatiques plus variés, de manière plus flexible (par exemple les langages java ou .net). L'utilisation d'un module avionique impose parfois l'utilisation de langages qui peuvent être moins adaptés aux calculs de paramètres que ceux disponibles pour les systèmes informatiques appartenant au monde ouvert. Ainsi le développement et la maintenance des applications du module de calculs sont facilités. La flexibilité est aussi accrue. Le code informatique embarqué dans le module de calcul peut également être plus optimisé (emploi de compilateurs et de langages efficaces, comme par exemple le Fortran, bien plus rapide pour des calculs récursifs comme ceux effectués par le module de calcul que le langage C tel que certifié). En outre, un module de calcul appartenant au monde ouvert peut utiliser des composants électroniques et informatiques beaucoup plus puissants que le matériel utilisé sur les CPIOM. Le module TOPOC-NSS communique avec les modules de 25 configuration TOPOC-HMI 42, 43 mis en oeuvre dans le domaine avionique par des ordinateurs CPIOM 44, 45. Le module TOPOC-NSS communique aussi avec certaines bases de données 46 installées dans le NSS. Par exemple la base de données contenant tous les paramètres des aéroports et pistes nécessaires au calcul de 30 performance. L'architecture hybride du système de configuration peut par exemple mettre en oeuvre un mécanisme type client-serveur : les clients TOPOC-HMI fournissent une interface à l'équipage et aux applications avioniques. Elles communiquent ensuite avec le serveur TOPOC-NSS qui se charge des calculs de paramètre. Le NSS dispose aussi d'une passerelle 47, le SCI (sigle de Secure Communication Interface), qui lui permet de communiquer par AFDX avec les systèmes avioniques. Cette passerelle permet de mettre en oeuvre des communications entre le domaine avionique et le monde ouvert. Au sein du NSS, c'est-à-dire derrière le SCI donc dans le monde ouvert, les communications ne se font plus par AFDX. Des mécanismes peuvent permettre de transférer des données du monde ouvert vers le monde avionique et de transférer des données du monde avionique vers le monde ouvert. Ces mécanismes visent par exemple à assurer une sécurité suffisante pour l'utilisation des données dans le domaine avionique, permettant ainsi de garantir un usage des données avec le même risque d'erreur que lors d'une saisie manuelle comme c'est le cas avec une documentation papier (ou un EFB classique). La figure 5 est un organigramme général d'étapes mises en oeuvre dans des modes de réalisation pour l'obtention d'un paramètre calculé. Par exemple, ces étapes sont mises en oeuvre par un module de configuration tel 20 que discuté précédemment. Lors d'une étape 500, sur action du pilote, la fonction de calcul de paramètre de configuration du système de gestion de vol de l'aéronef est appelée. Le pilote sélectionne alors le calcul de paramètre lors d'une étape 501. Par exemple, le pilote clique sur un bouton d'interface. Ensuite, les données de 25 calcul sont récupérées par le module de configuration, soit automatiquement auprès d'autres systèmes, soit suite à des entrées du pilote sur une interface (clavier, écran tactile ou autre). Lorsqu'une nouvelle donnée (ou groupe de données) est récupérée (étape 503, OUI) une requête de vérification de la cohérence de cette (ou ces) 30 donnée(s) est envoyée au module de calcul lors d'une étape 504. Une étape d'attente 505 de la réception d'un message d'erreur est ensuite mise en oeuvre. En cas de réception d'un tel message (OUI), une étape d'affichage 506 d'un message d'erreur est exécutée. Sinon (NON), le processus reprend à l'étape 503, en attente de la récupération d'une nouvelle donnée. Le processus est aussi repris à l'étape 503, après l'étape 506, une fois que la cause du message d'erreur a disparu. Lorsqu'il n'y a plus de nouvelle donnée à récupérer (étape 503, NON), une étape 507 de lancement du calcul de paramètre est mise en oeuvre. Par exemple, le pilote clique sur un bouton à cet effet. Une requête de calcul de paramètre est alors transmise au module de calcul. Lors d'une étape 508, le paramètre calculé est reçu de la part du module de calcul. La figure 6 est un organigramme général d'étapes mises en oeuvre dans des modes de réalisation pour la vérification des paramètres calculés. Par exemple, ces étapes sont mises en oeuvre par un module de configuration tel que discuté précédemment. Ces étapes font par exemple suite à celles présentées en référence à la figure 5. Lors de l'étape 600, il est déterminé si le paramètre calculé est corrompu. Si tel est le cas (OUI), un message d'erreur est affiché au pilote lors d'une étape 601. Sinon (NON), le paramètre calculé est affiché lors d'une étape 602. L'insertion de ce paramètre dans le système de gestion de vol FMS est ensuite lancée lors d'une étape 603. Par exemple, le pilote clique sur un bouton. A titre de vérification, il peut être déterminé avant l'insertion complète du paramètre dans le système de gestion de vol si les données de calcul 25 utilisées pour calculer le paramètre sont cohérentes avec les données déjà présentes dans le système de gestion de vol. Cette vérification est opérée lors de l'étape 604. Si les données ne sont pas cohérentes (NON), un message d'erreur est affiché lors de l'étape 605. Sinon (OUI), le paramètre est finalement inséré dans le FMS et affiché lors d'une étape 606. 30 Les mécanismes de vérification évoqués ci-dessus, peuvent permettre de minimiser les risques d'erreurs provenant de l'utilisation dans un module certifié de données provenant d'un module monde ouvert. Ces mécanismes sont détaillés dans la suite. La figure 7a illustre la vérification de cohérence des données envoyées au module de calcul lors de l'étape 504 décrite précédemment et illustrée par la figure 5. Par exemple, lorsque le pilote rentre des données dans l'interface de calcul de performance dans le monde avionique, il y a un risque d'erreur de saisie. Pour limiter ce risque, les données saisies sont régulièrement 10 envoyées par le module de configuration 70, dans un message 71, au module de calcul 72 dans le monde ouvert qui vérifie leur cohérence suivant un ensemble de règles. En cas d'incohérence, un message d'erreur est envoyé à l'interface dans le domaine avionique pour l'afficher au pilote. Ce dernier peut alors 15 corriger les données en cause. La figure 7a présente le cas où le pilote a fini d'entrer des données météo 73, 74. Les données d'entrée sont alors envoyées au module TOPOCNSS pour vérifier leur cohérence. Dans cet exemple, le pilote a rentré une température de 40°C et a indiqué la présence de neige sur la piste. 20 Une telle température étant incompatible avec la présence de neige, une incohérence est détectée. La figure 7b, qui reprend les éléments de la figure 7a, présente la réaction du système dans le cas où le test de cohérence échoue. Le module TOPOC-NSS envoie un message d'erreur 75 adapté à l'incohérence détectée. 25 Dans l'exemple présenté ci-avant, un message invite le pilote à vérifier les conditions de piste qu'il vient d'entrer. Il s'agit par exemple d'un message en anglais 76 « CHECK RUNWAY CONDITION ». Le pilote peut alors analyser les données d'entrée et éventuellement corriger une erreur. En plus d'éviter une erreur, ce mécanisme permet également de 30 gagner du temps en évitant de lancer un calcul avec des données d'entrée incorrectes. Ce mécanisme permet aussi d'éviter une accumulation d'incohérences difficile à corriger de manière logique par le pilote et dans un temps acceptable. Outre ce risque d'erreur, il existe un risque de corruption de données 5 lors du transfert du domaine avionique vers le monde ouvert et inversement du monde ouvert vers le domaine avionique. La figure 8 illustre un test pour limiter ce risque. Le module de configuration TOPOC-HMI 80 vérifie systématiquement l'intégrité des données d'entrée et des résultats de calcul d'un traitement du module de calcul TOPOC- 10 NSS 81. Ces mécanismes peuvent permettre d'atteindre un niveau d'intégrité acceptable par les autorités d'approbation opérationnelles et ainsi passer avec succès les tests de l'analyse de risque (tests ORA, sigle de « Operational Risk Analysis » en terminologie anglo-saxonne). Les données d'entrée (données de calcul) 82 sont envoyées par le 15 module de configuration TOPOC-HMI au module de calcul (par exemple après mise en forme). Le module de calcul fait par exemple une copie 83 des données qu'il a effectivement utilisées et les joint aux résultats de calcul 84. L'ensemble est alors envoyé au module de configuration TOPOC-HMI (par exemple après mise en forme). 20 Ainsi, à la réception du message de sortie, le module de configuration TOPOC-HMI peut vérifier que la copie des données d'entrée correspond à ce qui a été envoyé au module de calcul TOPOC-NSS. S'il y a correspondance, le module de configuration TOPOC-HMI peut estimer que les données n'ont pas été corrompues lors de leur transfert et 25 leur traitement par le module de calcul TOPOC-NSS et donc que le calcul a été effectué avec les bonnes données d'entrée. S'il n'y a pas correspondance, il est possible que le traitement ait été effectué avec des données d'entrée corrompues. Dans ce cas, un message d'erreur peut être affiché et le calcul TOPOC peut être annulé. 30 La figure 9 illustre le mécanisme de vérification du résultat du calcul de paramètre. Cette figure reprend les éléments communs avec la figure 8. Les résultats de calcul 90 sont écrits deux fois et les deux copies sont envoyées au module de configuration. Par exemple, les résultats sont écrits à deux endroits différents 91, 92 du même message de sortie du module de calcul TOPOCNSS. A la réception de ce message, le module de configuration TOPOC- HMI vérifie que les deux écritures 91, 92 sont identiques. S'il y a correspondance, le module de configuration TOPOC-HMI peut estimer que les données n'ont pas été corrompues lors de leur transfert depuis le module de calcul TOPOC-NSS et qu'il n'y a pas eu d'erreurs de recopie dans le message de sortie. S'il n'y a pas correspondance, le module de configuration peut en déduire qu'une corruption de données a eu lieu, auquel cas un message d'erreur est par exemple affiché et le calcul TOPOC est annulé. Dans la suite, l'interface avec le pilote est décrite en détails. Le pilote appelle la fonction de calcul TOPOC sur l'écran du système avionique. La fonction est par exemple appelée depuis le FMS. Elle peut aussi par exemple être appelée manuellement depuis le panneau de contrôle des systèmes avioniques. La figure 10 présente la page de performances décollage du FMS. Le pilote peut appeler la fonction de calcul TOPOC en cliquant sur le bouton 20 100 «T.0 PERF COMPUTATION ». Le pilote récupère les données utiles à son calcul (paramètres de la piste, météo, configuration et pannes de l'avion, ou autre) depuis les autres systèmes avioniques, par exemple le FMS. Par exemple, il appuie sur le bouton « retrieve FM data » représenté sur la figure 11. Il peut également rentrer ces 25 données manuellement ou les modifier. Alternativement ou en combinaison, ces données peuvent être récupérées automatiquement par le module de configuration. La figure 11 présente la page du logiciel de calcul de performances ide décollage (« TAKEOFF ») juste après avoir récupéré (automatiquement ou 30 manuellement) les données du FMS pour un plan de vol complet. Le pilote peut compléter les informations manquantes (dans l'exemple présenté, il s'agit de l'état de la piste 110 et le vent 111), et modifier les informations proposées. Il dispose d'une feuille de calcul de décollage et d'atterrissage par plan de vol FMS (ACTIVE, SEC1, SEC2, SEC3). La figure 11 représente la page active pour le décollage. Le pilote peut ainsi lancer des calculs sur l'ensemble des données de ses plans de vol FMS, ou utiliser les pages non utilisées comme brouillon, par exemple pour tester un itinéraire. Au fur et à mesure que le pilote rentre des blocs de données d'entrée cohérents dans le module de configuration TOPOC-HMI, des requêtes de vérification de la cohérence de ces blocs sont envoyées au module de calcul 10 TOPOC-NSS. En cas d'incohérence dans les données d'entrée, un message d'erreur aide le pilote à détecter et corriger l'erreur. La figure 12 présente le cas d'un calcul de performances à l'atterrissage (« LANDING »). Dans cet exemple, le pilote a sélectionné une 15 descente raide 120 « STEEP » avec un mode d'atterrissage automatique 121 « AUTOLAND » ce qui n'est pas une configuration valide. Un message d'erreur 122 informe alors le pilote de cette incohérence. Lorsque toutes les données nécessaires au calcul sont entrées et sont cohérentes, le pilote lance le calcul en cliquant sur le bouton 123 20 (« COMPUTE »). Le calcul s'effectue dans le module de calcul qui fait partie du monde ouvert, puis les résultats s'affichent sur l'écran avionique. En cas de corruption de données, un message d'erreur s'affiche et le calcul TOPOC est annulé. 25 Si les données ne sont pas corrompues, le pilote peut consulter les résultats dans une page de résultat illustrée par la figure 13, et les transmettre au FMS en cliquant sur le bouton 130 « INSERT IN T.0 PAGE » ou « INSERT IN APPR PAGE » (selon que le calcul est un calcul de décollage ou d'atterrissage). 30 Le module de configuration TOPOC-HMI vérifie alors que l'aéroport 131, la piste 132 et la masse 133 (masse de décollage ou masse à l'atterrissage suivant le type de calcul) utilisés pour le calcul sont bien les mêmes que ceux utilisés par le FMS. Si ce n'est pas le cas un message d'erreur 134 est affiché au pilote et l'insertion des données dans le FMS, c'est-à-dire la configuration, est annulée. Dans la figure 13, le message est celui qui s'affiche lorsque la piste utilisée par le plan de vol du FMS et celle utilisée pour le calcul de performance TOPOC sont différentes. Si les données de l'aéroport, de la piste et de la masse sont cohérentes entre le calcul TOPOC et le FMS, le module de configuration envoie les paramètres calculés au FMS. Le FMS peut alors reprendre la main sur l'affichage. Le FMS peut alors vérifier une nouvelle fois que l'aéroport, la piste et la masse sont cohérents avec ses propres données. Si c'est le cas, le FMS affiche une fenêtre permettant au pilote de vérifier une dernière fois les données qui vont être rentrées dans le FMS. La figure 14 illustre un exemple d'insertion des résultats dans le FMS. Les données calculées 1400-1405 sont proposées à côté des données existantes 1406-1411. Le pilote peut alors les comparer et s'assurer qu'elles sont correctes avant de les prendre en compte. Par exemple, les données calculées sont affichées dans une couleur différente des données existantes. Au vu de ce qui précède, il apparait que le transfert de données de calcul de performance bidirectionnel entre le monde ouvert et le domaine avionique permet de concilier les avantages d'une solution de calcul électronique dans le monde ouvert et l'ergonomie et les capacités d'intégration d'un logiciel intégré à l'avionique. Par rapport à la documentation papier, l'invention permet un usage simplifié et une utilisation d'entrées de calcul exactes, ce qui évite de réaliser des interpolations (comme sur abaque) et des imprécisions. De plus, les marges de calcul peuvent être réduites pour plus de précision et un résultat optimisé. La solution décrite ci-avant offre une rapidité d'exécution du calcul et une facilité de conception et de mise à jour du logiciel de calcul grâce à l'installation dans le monde ouvert. Il est offert la possibilité de diagnostiquer en temps réel les erreurs de saisie grâce au test de cohérence. Pour le pilote, le flux de travail n'est pas interrompu. Le pilote peut facilement passer de la préparation de son plan de vol sur FMS à son calcul de performance, sur le même écran avec la même ergonomie. Cela facilite aussi le travail en conditions de vol délicates (turbulences, ou autre), le pilote n'ayant pas à utiliser un manuel papier ou un ordinateur portable fixé sommairement qui risque de lui échapper ou d'obstruer son champ de vision. Le fait d'utiliser le système d'affichage (CDS) de l'avionique permet de proposer la même interface que les autres systèmes comme le FMS. Ainsi l'équipage se trouve dans un environnement de travail connu, ce qui réduit les risques de mauvaise manipulation ainsi que le coût de formation. La solution décrite ci-avant permet également d'automatiser le travail grâce à la récupération des données d'entrée de calcul et à l'export des résultats de calcul avec d'autres systèmes avioniques. Un programme d'ordinateur pour la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention peut être réalisé par la personne du métier à la lecture des organigrammes des figures 5 et 6 et de la présente description détaillée. La figure 15 illustre un dispositif pour mettre en oeuvre un module de configuration et/ou un module de calcul selon des modes de réalisation. Le dispositif 150 comporte une unité de mémoire 151 (MEM). Cette unité de mémoire comporte une mémoire vive pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé selon un mode de réalisation. L'unité de mémoire comporte par ailleurs une mémoire non volatile (par exemple du type EEPROM) pour stocker par exemple un programme d'ordinateur selon un mode de réalisation pour son exécution par un processeur (non représenté) d'une unité de traitement 152 (PROC) du système. La mémoire peut également stocker d'autres données évoquées ci-avant. Le dispositif comporte par ailleurs une unité de communication 153 30 (COM) pour mettre en oeuvre des communications, par exemple pour communiquer avec des systèmes avioniques, des bases de données, ou autre, comme évoqué ci-avant. Un système selon des modes de réalisation peut comporter un module de configuration et un module de calcul ayant chacun une structure telle que décrite en référence à la figure 15 pour fonctionner comme décrit en détails ci-avant. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes, modes de réalisation et combinaisons de caractéristiques peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. Pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications ou adaptations. Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention. REVENDICATIONS1. Procédé de configuration d'un système de gestion (206, 34) d'aéronef comportant les étapes suivantes, mises en oeuvre par un module de configuration (200, 30, 31, 42, 43, 70, 80) intégré au système avionique d'une station de pilotage de l'aéronef: - obtention (502) d'au moins une donnée de calcul (202) d'au moins un paramètre (203) de configuration du système de gestion, - transmission (507), à destination d'un module de calcul (208, 40, 72, 81) indépendant du système avionique de la station de pilotage de l'aéronef, d'une requête de calcul (209) dudit au moins un paramètre à partir de ladite au moins une donnée de calcul, - réception (508), de la part dudit module de calcul, dudit au moins un paramètre calculé, et - configuration (603) dudit système de gestion avec ledit au moins un paramètre calculé reçu. 2. Procédé selon la revendication 1, comportant en outre, préalablement à la transmission de ladite requête de calcul, une étape de transmission (504), à destination dudit module de calcul, d'une requête de vérification de cohérence de ladite au moins une donnée de calcul, et dans lequel la requête de calcul est transmise, en fonction (505) de ladite vérification de cohérence. 3. Procédé selon la revendication 2, dans lequel, ladite requête de vérification 25 de cohérence concerne un bloc d'une pluralité de données de calcul. 4. Procédé selon l'une des revendications précédentes, comportant en outre, suite à la réception dudit au moins un paramètre calculé, une étape de vérification de corruption (600) des données de calcul. 30 5. Procédé selon la revendication 4, dans lequel, ledit au moins un paramètre calculé est accompagné d'au moins une donnée de calcul (83) utilisée par lemodule de calcul pour le calculer, et dans lequel, ladite étape de vérification de corruption des données de calcul comporte la comparaison de ladite au moins une donnée de calcul déterminée et ladite au moins une donnée de calcul utilisée pour calculer ledit au moins un paramètre calculé. 6. Procédé selon l'une des revendications précédentes, comportant en outre une étape de vérification de l'intégrité dudit au moins un paramètre calculé reçu. 7. Procédé selon la revendication 6, dans lequel ladite vérification d'intégrité comporte une comparaison de deux écritures (91, 92), du même au moins un paramètre calculé, reçues de la part du module de calcul. 8. Procédé selon l'une des revendications précédentes, dans lequel ladite étape 15 d'obtention comporte la réception de ladite au moins une donnée de calcul via une interface utilisateur du module de configuration. 9. Procédé selon l'une des revendications précédentes, dans lequel ladite étape d'obtention comporte la réception de ladite au moins une donnée de calcul via 20 une interface de communication avec un module de fourniture de données de calcul. 10. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications précédentes lorsqu'il 25 est chargé et exécuté par un processeur d'un dispositif ou d'un système de configuration d'un système de gestion d'aéronef. 11. Dispositif (200, 30, 31, 42, 43, 70, 80, 150) de configuration d'un système de gestion d'aéronef (206, 34), ledit dispositif étant intégré au système 30 avionique d'une station de pilotage de l'aéronef, le dispositif comportant : - une unité de traitement (152) configurée pour obtenir au moins une donnée de calcul (202) d'au moins un paramètre (203) de configuration du système degestion, l'unité de traitement étant en outre configurée pour configurer ledit système de gestion avec ledit au moins un paramètre calculé reçu, et - une unité de communication (153) configurée pour transmettre, à destination d'un module de calcul (208, 40, 72, 81) indépendant du système avionique de la station de pilotage de l'aéronef, une requête de calcul (209) dudit au moins un paramètre à partir de ladite au moins une donnée de calcul, l'unité de communication étant en outre configurée pour recevoir, de la part dudit module de calcul, ledit au moins un paramètre calculé. 12. Système de configuration de système de gestion d'aéronef comportant : - un dispositif de configuration intégré au système avionique d'une station de pilotage de l'aéronef, le dispositif comportant : - une unité de traitement configurée pour obtenir au moins une donnée de calcul d'au moins un paramètre de configuration du système de gestion, l'unité de traitement étant en outre configurée pour configurer ledit système de gestion avec ledit au moins un paramètre calculé reçu, et - une unité de communication configurée pour transmettre, à destination d'un dispositif de calcul indépendant du système avionique de la station de pilotage de l'aéronef, une requête de calcul dudit au moins un paramètre à partir de ladite au moins une donnée de calcul, l'unité de communication étant en outre configurée pour recevoir, de la part dudit dispositif de calcul, ledit au moins un paramètre calculé, le système comportant en outre : - ledit dispositif de calcul indépendant du système avionique de la station de pilotage de l'aéronef, le dispositif de calcul comportant : - une unité de traitement configurée pour calculer, à partir de données de calcul reçues, ledit paramètre de configuration, et - une unité de communication configurée pour recevoir, de la part du dispositif de configuration, ladite requête de calcul, et pour transmettre, audit dispositif de configuration, ledit paramètre de configuration calculé. 13. Aéronef comportant un dispositif selon la revendication 11 ou un système selon la revendication 12.