FR 3090928 A1 20200626 FR 1874006 A 20181221 Description Titre de l'invention : SYSTEME DE GESTION DE DONNES SYNCHRONISE ET PROCEDE Domaine technique [0001] De façon générale, l'invention concerne des ordinateurs et des logiciels d'ordinateurs et en particulier des systèmes, des procédés et des produits-programmes d'ordinateur pour gérer des données de façon centralisée. [0002] CONTEXTE [0003] Les systèmes informatisés et les réseaux sont largement utilisés pour améliorer la productivité et optimiser les ressources dans des environnements où d'importants flux de données doivent être échangés entre de multiples dispositifs utilisateurs. Cependant dans certains systèmes de contrôle, tels que les systèmes de tour de contrôle par exemple, un niveau particulier de sécurité peut être nécessaire pour sécuriser les flux de données échangés entre de multiples dispositifs (serveurs, bases de données, dispositifs utilisateurs) tout en assurant que des flux de données particuliers sont reçus de façon ponctuelle et sécurisée par les dispositifs. [0004] Dans ces environnements, on sait qu'un dispositif particulier est dédié à une fonction particulière alors que les flux de données sont décentralisés et échangés directement d'un dispositif à un autre. 100051 Par exemple, dans un système de programmation de données (tels qu'un système de tour de contrôle) comprenant un ou plusieurs dispositifs de planification gérant séparément diverses données qui impactent la planification, un opérateur gérant un des dispositifs peut contacter l'opérateur gérant un autre dispositif via un réseau privé pour demander une mise à jour des données. Si un accord est conclu entre les deux opérateurs, la mise à jour peut être exécutée. Ces deux opérateurs peuvent par ailleurs avoir besoin de contacter séparément un ou plusieurs autres opérateurs de planification en utilisant une communication bidirectionnelle (p. ex. un échange téléphonique) pour échanger des données qui peuvent impacter les données gérées par ces opérateurs de planification. Par conséquent, des données peuvent être échangées uniquement entre chaque paire de dispositifs de planification, de façon décentralisée, afin d'optimiser la sécurité de l'échange et/ou un niveau de sécurité. 100061 Une telle approche décentralisée consomme beaucoup de ressources informatiques et peut entraîner d'importants délais, ce qui s'avère indésirable dans un environnement de données en temps réel. 100071 Des systèmes améliorés, des procédés et des produits-programmes d'ordinateur sont donc nécessaires pour gérer de manière centralisée des données accessibles à partir de 2 multiples dispositifs externes. [0008] RESUME [0009] Pour résoudre ces problèmes et d'autres, un système de gestion de données syn- chronisé pour gérer des données est fourni, le système étant connecté à au moins un dispositif utilisateur connecté au système de gestion de données synchronisé via un réseau. De manière avantageuse, le système comprend un serveur configuré pour recevoir dès requêtes provenant dudit au moins un dispositif utilisateur et une base de données de stockage commune comprenant une unité de stockage maître configurée pour stocker des données. Le système de gestion de données synchronisé peut par ailleurs comprendre une unité de stockage auxiliaire configuré pour stocker des données actualisées, le système de gestion de données synchronisé étant configuré pour transmettre un sous-ensemble de données stockées dans l'unité de stockage maître à un dispositif utilisateur donné en réponse à une requête de mise à jour reçue par le serveur en provenance du dispositif utilisateur. Le système de gestion de données synchronisé est configuré pour stocker une mise à jour faite au sous-ensemble de données et reçue du dispositif utilisateur dans l'unité de stockage auxiliaire, le système de gestion de données synchronisé stockant par ailleurs la mise à jour faite au sous-ensemble de données dans l'unité de stockage maître en réponse à la réception d'une ou plusieurs requêtes de validation provenant d'un ensemble de dispositifs utilisateurs sélectionnés, l'ensemble de dispositifs utilisateurs sélectionnés comprenant au moins un dispositif utilisateur. [0010] Dans un mode de réalisation, le système de gestion de données synchronisé peut être configuré pour envoyer un message incluant une mise à jour stockée dans l'unité de stockage auxiliaire à chaque dispositif utilisateur de l'ensemble des dispositifs utilisateurs sélectionnés. [0011] Le système de gestion de données synchronisé peut comprendre une unité d'encodage configurée pour encoder la mise à jour en utilisant au moins un mécanisme d'encodage et pour envoyer un message incluant la mise à jour encodée à chaque dispositif utilisateur de l'ensemble des dispositifs utilisateurs sélectionnés. [0012] Dans un mode de réalisation, l'unité d'encodage de données est configurée pour encoder la mise à jour dans un format de données pris en charge par le dispositif utilisateur de l'ensemble des dispositifs utilisateurs sélectionnés. [0013] Dans un mode de réalisation, l'unité de stockage auxiliaire peut être située dans l'unité de stockage commune. [0014] De manière avantageuse, la mise à jour faite au sous-ensemble de données peut être associée à un identifiant unique, l'identifiant unique étant stocké dans l'unité de stockage auxiliaire [0015] Le système peut par ailleurs être configuré pour envoyer le sous-ensemble de 3 données à l'unité de stockage maître, associée à la mise à jour, à chaque dispositif utilisateur de l'ensemble des dispositifs utilisateurs sélectionnés. [0016] Le système peut être configuré pour recevoir une version modifiée de la mise à jour faite au sous-ensemble de données provenant d'un dispositif utilisateur de l'ensemble des dispositifs utilisateurs sélectionnés et pour stocker la version modifiée de la mise à jour dans l'unité de stockage auxiliaire. [0017] Dans un mode de réalisation, le serveur comprend une unité de résolution de conflits configure° pour détecter et résoudre un conflit de données entre la mise à jour faite au sous-ensemble de données dans l'unité de stockage auxiliaire et les données maîtres dans l'unité de stockage maître, l'unité de résolution de conflits étant par ailleurs configure° pour fusionner la mise à jour faite au sous-ensemble de données dans l'unité de stockage auxiliaire avec les données maître de l'unité de stockage maître en réponse à la résolution des conflits, avant l'intégration des données fusionnées dans l'unité de stockage maître. [0018] Il est par ailleurs fourni un procédé de gestion de données synchronisé pour gérer des données dans un système informatisé connecté à au moins un dispositif utilisateur via un réseau, dans lequel le procédé comprend la transmission d'un sous-ensemble de données stockées dans une unité de stockage maître du système à un dispositif utilisateur donné en réponse à la réception d'une requête de mise à jour reçue des dispositifs utilisateurs, le procédé comprenant par ailleurs le stockage d'une mise à jour faite au sous-ensemble de données et reçue du dispositif utilisateur dans l'unité de stockage auxiliaire, la mise à jour faite au sous-ensemble de données étant stockée dans l'unité de stockage maître en réponse à une ou plusieurs requêtes de validations reçues d'un ensemble sélectionné de dispositifs utilisateurs comprenant au moins un dispositif utilisateur. Brève description des dessins [0019] Les dessins en annexés qui sont incorporés et constituent une partie de cette spéci- fication, illustrent des modes variés de réalisation de l'invention et, avec la description générale de l' invention ci-dessus et la description détaillée des modes de réalisation donnée ci-après, servent à expliquer les modes de réalisation de l'invention. [0020] La [fig.1] est une vue schématique d'un exemple d'environnement de fonc- tionnement incluant un système de gestion de données synchronisé en communication via un réseau avec de multiples systèmes externes. [0021] La [fig.2] est une vue schématique du système de gestion de données synchronisé selon des modes de réalisation. [0022] La figure 2 représente un exemple d'environnement de fonctionnement du système de gestion de données synchronisé, selon un exemple d'application de l'invention à un système de tour de contrôle. [0023] La [fig.3] illustre un affichage graphique d'un système de contrôle de trafic aérien, selon un exemple de mode de réalisation. [0024] La [fig.4] est un organigramme illustrant un procédé de mise à jour de données dans le système de gestion de données synchronisé, conforme à un mode de réalisation de l' invention. [0025] La [fig.5] est un organigramme illustrant un procédé de revue des mises à jour de données, conforme au mode de réalisation de l'invention. [0026] La [fig.6] est une vue schématique d'un exemple de système d'exploitation pour héberger un composant de l'environnement de la figure 1. Description des modes de réalisation [0027] Faisant référence à la figure 1, il y est montré un exemple d'environnement de fonc- tionnement 100 d'un système de gestion de données synchronisé 10 (également désigné comme «SDMS» dans certaines figures), conforme à des modes de réalisation de l'invention. [0028] L'environnement de fonctionnement 100 comprend un système de gestion de données synchronisé 10 connecté à un ou plusieurs dispositifs utilisateurs 4 via un réseau 5. [0029] Dans certains modes de réalisation, le système de gestion de données synchronisé 10 peut être connecté facultativement à un ou plusieurs dispositifs externes 20 via un réseau 6 fonctionnant comme des dispositifs d'acheminement de données ou des systèmes qui peuvent acheminer des données vers le système de gestion de données synchronisé 10. Les données reçues des dispositifs externes peuvent se présenter dans un ou plusieurs formats de données en fonction des formats de données pris en charge par les dispositifs externes 20. [0030] Un réseau 5 ou 6 peut inclure un ou plusieurs réseaux privés et/ou publics (p. ex. Internet) qui permettent l'échange de données, tels qu'Internet, un réseau de zone locale (LAN), un réseau de zone étendue (WAN), un réseau cellulaire voix/données, une ou plusieurs connexions par bus à haute vitesse et/ou d'autres types de réseaux de communication de ce genre. Le réseau 5 peut utiliser des technologies de communication normales et/ou des protocoles tels que 4G, Ethernet, 802.11, TCP/IP (Protocole de contrôle de transmission/Protocole Internet), HTTP (Protocole de transport hypertexte), FTP (Protocole de transfert de fichier), etc. Les données peuvent être échangées sur le réseau 5 selon des technologies d'échange de données différentes et/ou des formats tels que le langage de balisage hypertexte (HTML) et le langage de balisage étendu (XML, JSON, etc.). [0031] Chaque dispositif utilisateur 4 peut être un dispositif informatique personnel, une tablette informatique, un terminal client léger, un smartphonc et/ou tout autre dispositif informatique qui permettent à l'utilisateur de soumettre des requêtes au dispositif de système de gestion de données synchronisé 10 sur un réseau 5. Chaque dispositif client 4 peut héberger des navigateurs web et/ou un logiciel d'applications personnalisées (p. ex. un système client), et peut inclure une interface utilisateur client 40 (telle qu'une Interface graphique d'utilisateur GUI). [0032] Au moins une partie des dispositifs utilisateurs 4 peuvent collaborer entre eux à travers le système de gestion de données synchronisé 10, en utilisant le réseau 5, pour actualiser des données gérées de manière centralisée par le système de gestion de données synchronisé 10 tout en permettant à un ensemble sélectionné de dispositifs utilisateurs 4 (les dispositifs de revue) pour revoir et valider les mises à jour. [0033] Le système de gestion de données synchronisé 10 peut comprendre un stockage commun 3 tel qu'une base de données configurée pour stocker des données, au moins une partie de ces données pouvant être mises à jour par un ou plusieurs utilisateurs connectés au système de gestion de données synchronisé 10 via un dispositif utilisateur 4. [0034] Dans des modes de réalisation dans lesquels le système de gestion de données syn- chronisé 10 est connecté à un ou plusieurs dispositifs externes 20 agissant comme des dispositifs d'acheminement, les données reçues du dispositif externe 20 par le système de gestion de données synchronisé 10 peuvent être reçues dans un format donné de données sources. Dans ces modes de réalisation, le système de gestion de données synchronisé 10 peut utiliser un analyseur de données 102 pour transformer le format des données reçues de ces dispositifs externes en un format de données cibles prédéfini. Après la transformation, le système de gestion de données synchronisé peut stocker des données reçues du dispositif d'acheminement externe dans le stockage commun 3. [0035] Dans certains modes de réalisation, le stockage commun 3 peut comprendre une unité de stockage maître 30 (également désignée ci-après « stockage maître») configurée pour stocker des données (par exemple des données agrégées de multiples dispositifs d'acheminement externe 20). Le système de données synchronisé peut par ailleurs comprendre une unité de stockage auxiliaire 31 (également désignée ci-après « stockage auxiliaire ») et qui est configurée pour conserver des mises à jour d'au moins une partie des données stockées dans le stockage maître 30, formant des mises à jour préliminaires, chaque mise à jour étant associée à un identifiant ID. Dans certains modes de réalisation, chaque mise à jour dans le stockage auxiliaire peut par ailleurs être associée à un ou plusieurs identifiants de dispositif qui identifient un ou plusieurs dispositifs utilisateurs 4 desquels une mise à jour préliminaire a été reçue. [0036] Dans un mode de réalisation, le stockage maître 30 et le stockage auxiliaire 31 sont tous deux situés dans le même stockage commun 3. La description suivante de certains 6 modes de réalisation fera référence à ces modes de réalisation dans lesquels le stockage commun 3 inclut le stockage maître 30 et le stockage auxiliaire 31 à titre d'illustration. [0037] Chaque utilisateur d'un ensemble d'utilisateurs ayant des droits d'accès au dispositif de système de gestion de données synchronisé 10 prédéfinis peut soumettre une requête au dispositif de système de gestion de données synchronisé 10 sur le réseau 5 en utilisant un dispositif utilisateur 4. [0038] Le dispositif de système de gestion de données synchronisé 10 peut comprendre un serveur 101 pour gérer une requête reçue d'un utilisateur. [0039] L'interface graphique d'utilisateur (GUI) 40 de chaque dispositif utilisateur 4 peut être une application client riche ou une application client web. Chaque dispositif utilisateur 4 peut par ailleurs comprendre un stockage local 41 qui peut par exemple être une base de données côté client ou un système de fichiers. [0040] Dans certains modes de réalisation, chaque dispositif utilisateur 4 peut aussi comprendre une unité de résolution de conflits 42 configurée pour résoudre des données conflictuelles sur la base d'un ensemble de règles basées sur une mise à jour maître et/ou une modification d'un utilisateur. [0041] Un utilisateur de l'ensemble des utilisateurs peut avoir des droits d'accès différents dépendant du champ d'application de l'invention. Par exemple, si l'utilisateur appartient à une organisation telle que, par exemple, le centre opérationnel des compagnies aériennes, l'utilisateur peut avoir des droits d'accès différents dépendant du rôle(s) exercé par l'utilisateur au sein de l'organisation. Des exemples de rôles au sein de l'organisation du centre opérationnel des compagnies aériennes incluent : [0042] - Un contrôleur d'opérations : dans ce cas l'utilisateur est responsable de la gestion des opérations de vol en matière d'attribution des aéronefs. Un contrôleur de créneaux (slots) : Dans ce cas un utilisateur est responsable pour la gestion des créneaux attribués à un vol. Un gestionnaire de la maintenance Dans ce cas, un utilisateur est responsable de la gestion de la planification de la maintenance pour les aéronefs des compagnies aériennes. Un gestionnaire d'équipage : Dans ce cas, un utilisateur est responsable de la gestion de la planification des listes d'équipage pour les vols des compagnies aériennes. Un contrôleur de passagers : Dans ce cas, un utilisateur est responsable de la gestion pour minimiser l'impact des perturbations de vols sur les passagers. [0043] Les droits d'accès attribués à un utilisateur donné incluent un droit de «lecture» et/ ou un droit de « mise à jour» sur les divers sous-ensembles de données contenus dans le stockage maître 30. Cependant, dans certains modes de réalisation, tout changement dans un sous-ensemble de données peut affecter les données d'un autre sous-ensemble 7 créant ainsi une interdépendance. [0044] Pour soumettre une quelconque requête, un utilisateur avec un dispositif utilisateur donné 4 peut au préalable se connecter et s'identifier au système de gestion de données synchronisé 10, par exemple en saisissant ses authentifiants. [0045] Si l'accès est accordé à une vue peut être affichée pour l'utilisateur sur l'interface graphique d'utilisateur 40, permettant à l'utilisateur de saisir des requêtes (télécharger, mettre à jour). [0046] Une requête envoyée par l'utilisateur au système de gestion de données syn- chronisé 10 via le réseau 5 peut par exemple inclure : [0047] - Une requête pour accéder à un sous-ensemble de données stocké dans le stockage maître 30 du stockage commun 3. Une requête pour accéder à une solution préliminaire stockée dans le stockage auxiliaire 31 du stockage commun 3. Une requête pour effectuer des mises à jour en temps réel sur le sous-ensemble de données déjà chargé sur la hase des mises à jour stockées dans le stockage maître 30 et/ou dans le stockage auxiliaire 31. [0048] En plus des requêtes relatives aux données stockées dans le stockage commun 3, un dispositif utilisateur 4 peut par ailleurs demander au serveur 101 des mises à jour en temps réel des données stockées dans le stockage maître 30 après le chargement d'un sous-ensemble de données ou de la dernière requête de mise à jour. [0049] En réponse à un nouvel ensemble de mises à jour reçu par le dispositif utilisateur 4, l'unité de résolution de conflits 42 peut résoudre des conflits entre les mises à jour maîtres en temps réel et les modifications locales sur un dispositif utilisateur 4, le cas échéant. En réponse au traitement effectué par l'unité de résolution de conflits 42, les résultats peuvent être rendus sur l'interface graphique utilisateur 40 du dispositif utilisateur 4. [0050] Un utilisateur utilisant l'interface graphique d'utilisateur 40 du dispositif utilisateur 4 peut faire des modifications à un sous-ensemble de données (également désigné comme « sous-ensemble de données maîtres ») reçu du stockage maître 30 du système de données synchronisé 10 et peut aussi stocker ces changements clans un stockage local 41 pour une référence ultérieure (les changements stockés dans le stockage local 41 seront aussi désignés ci-après « solution préliminaire »). [0051] Une « solution préliminaire» sauvegardée sur le stockage local 41 d'un dispositif uti- lisateur donné 4 peut être partagée en publiant la solution préliminaire dans le système de gestion de données synchronisé 10 (la solution préliminaire étant ainsi une mise à jour du sous-ensemble de données maîtres reçues du stockage maître 30 et chargé sur le dispositif utilisateur 4). En réponse à la publication de la solution préliminaire, le système de gestion de données synchronisé 10 peut stocker une partie de la solution 8 préliminaire correspondant aux modifications effectuées par l'utilisateur sur le sous-ensemble de données maître et potentiellement des informations supplémentaires relatives à la portée des données (également désignée comme « contexte de données ») correspondant aux données contextuelles identifiant les données maîtres du sous-ensemble de données qui a été utilisé pour créer la solution préliminaire dans le stockage auxiliaire 31. Les données stockées dans le stockage commun 3 correspondant à une solution préliminaire publiée par un utilisateur dans le stockage auxiliaire 31 seront désignées ci-après « mise àjour préliminaire ». Le système de gestion de données synchronisé 10 peut par ailleurs attribuer un identifiant unique à la mise à jour préliminaire. Cet identifiant unique attribué à la mise à jour préliminaire peut inclure une description fournie par l'utilisateur avec un identifiant unique généré par le système (ID) et un identifiant d'utilisateur. On remarquera que le sous-ensemble de données maître n'est pas stocké avec la solution préliminaire dans le stockage auxiliaire 31, car il est déjà stocké dans le stockage maître 30. [0052] Lorsqu'une ébauche de mise àjour est publiée ou stockée dans le stockage auxiliaire 31 du stockage commun 3, d'autres utilisateurs utilisant un dispositif utilisateur 4 peuvent accéder à la mise àjour préliminaire, par exemple si un autre utilisateur se sert d'un dispositif qui peut être i mpacté par des modifications incluses dans la mise à jour préliminaire. [0053] En réponse à unc requête reçue d'un utilisateur demandant une solution préliminaire, le serveur 101 peut récupérer la solution préliminaire du stockage auxiliaire 31 et envoyer la solution préliminaire au dispositif utilisateur 40 avec lequel l'utilisateur a demandé la solution préliminaire. [0054] Si le dispositif utilisateur 40 n'inclut pas déjà le sous-ensemble de données maître associé à la mise à jour préliminaire, une requête supplémentaire peut être envoyée par le dispositif utilisateur 4 correspondant au serveur 101 du système de gestion de données synchronisé 10 en utilisant la portée des données incluses dans la solution préliminaire reçue. Le sous-ensemble de données maître et la solution préliminaire peuvent ensuite être envoyés à l'unité de résolution de conflits 42 afin de résoudre des conflits potentiels parmi les données et pour charger les données fusionnées dans l'interface graphique d'utilisateur 40 tout en soulignant les modifications de la solution préliminaire à des fins de revue ou de modification. L'utilisateur peut revoir la mise à jour préliminaire et en fonction de cette revue, l'utilisateur peut utiliser l'interface graphique d'utilisateur 40 du dispositif utilisateur 4 pour : [0055] - effectuer des modifications supplémentaires dans la mise à jour préliminaire ce qui donne une version modifiée de la mise à jour préliminaire et ensuite sauvegarder la version modifiée de la mise à jour préliminaire, cette version modifiée de la mise à jour préliminaire étant ensuite soumise à un ensemble 9 de dispositifs utilisateurs de revue pour revue et validation par les utilisateurs de ces dispositifs utilisateurs de revue ; et/ou effectuer des modifications supplémentaires dans la mise à jour préliminaire, ce qui donne une version modifiée de la mise à jour préliminaire et ensuite publier la version modifiée de la mise à jour préliminaire dans le stockage maître 30; et/ou envoyer une requête au système de gestion de données synchronisé 10 pour publier la mise à jour préliminaire, telle qu'elle, dans le stockage maître 30 afin de notifier la validation des modifications incluses dans la mise à jour préliminaire si l'utilisateur approuve ces modifications ; et/ou notifier un rejet partiel ou complet de la mise à jour préliminaire si l'utilisateur rejette au moins une partie des modifications correspondant à la mise à jour préliminaire. [0056] En réponse à unc requête de publication pour publier dans la mémoire maître une mise à jour préliminaire validée reçue par le système de gestion de données synchronisé 10 d'un dispositif utilisateur 4, le serveur 101 du système de gestion de données synchronisé 10 peut stocker les modifications incluses dans la mise à jour préliminaire validée dans la mémoire maître 30 dans un format de données pris en charge par le système de gestion de données synchronisé 10. [0057] Dans certains modes de réalisation, le système de gestion de données synchronisé 10 peut par ailleurs envoyer un message comprenant des données identifiant les mises à jour correspondant à la mise à jour préliminaire validée (ci-après désignées « données actualisées ») à chaque dispositif externe 20, d'un ensemble sélectionné de dispositifs externes, dans le format de données pris en charge par le dispositif externe 20 via le réseau 6. Le message incluant les données actualisées peut être préalablement encodé en utilisant un mécanisme d'encodage qui utilise une unité d'encodage de données 103 fournie dans le système de gestion de données synchronisé 10, et envoyé au dispositif externe 20 sous forme encodée. L'unité d'encodage de données 103 peut par ailleurs être configurée pour transformer les mises à jour correspondant à la mise à jour préliminaire validée du format de données du système de gestion de données synchronisé 10 dans le format de données pris en charge par le dispositif externe 20. [0058] Autrement, le système de gestion de données synchronisé 10 peut être configuré pour envoyer une notification au dispositif utilisateur 4 qui a initialement effectué la mise à jour préliminaire, chaque fois que la revue de la mise à jour préliminaire est achevé par un des dispositifs de revue 4. [0059] Dans un autre mode de réalisation, le dispositif demandeur 4 peut être configuré pour revoir certaines des modifications incluses dans une version modifiée de la mise à jour préliminaire correspondant à une revue d'un dispositif de revue sélectionné. La nouvelle mise à jour préliminaire ainsi générée peut être notifiée à la liste des dispositifs de revue 4 selon le processus de revue précédent. [0060] Un ou plusieurs composants du système de gestion de données synchronisé 10, tels que le système de gestion de données synchronisé 10 de données, les dispositifs externes 20 et les dispositifs utilisateurs 4 peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, collectivement désignés comme étant un ordinateur. [0061] Les données peuvent être partagées ou publiées conséquemment entre divers dis- positifs utilisateurs 4 et/ou les dispositifs externes 20 sans corrompre les données maîtres de l'unité de stockage maître 31 ou publier les données à d'autres systèmes. [0062] Par ailleurs, les modes dc réalisation de l'invention permettent la revue des mises à jour demandées par un dispositif utilisateur donné 4 par un ou plusieurs utilisateurs équipés de dispositifs de revue respectifs, sans avoir besoin de sauvegarder les données actualisées sur l'unité de stockage maître 31 ou dc les publier directement aux systèmes externes. [0063] Des modes de réalisation de l'invention évitent par ailleurs le besoin de création d'une copie complète des données maîtres comprises dans le stockage maître 30, limitant ainsi les coûts de calcul de la gestion de données centralisée. [0064] Le système de gestion de données synchronisé 10 peut être utilisé dans des champs d'application variés pour permettre à un ensemble de dispositifs utilisateurs autorisés de mettre à jour les données de façon synchrone. Par exemple il peut être utilisé par un ensemble d'utilisateurs dans la même équipe ou groupe de travail pour permettre à ces utilisateurs d'effectuer des modifications de façon collaborative dans un document commun en utilisant leurs dispositifs utilisateurs sans avoir besoin de se rencontrer dans une même salle ou de faire une téléconférence. [0065] Dans un autre exemple d'application de l'invention, le système de gestion de données synchronisé 10 peut être utilisé par un système de contrôle de trafic aérien. [0066] La figure 2 représente un exemple d'environnement de fonctionnement d'un système de gestion de données synchronisé 10 conforme à un exemple d'application de l'invention pour le contrôle du trafic aérien. [0067] L'environnement de la figure 2 inclut une pluralité de dispositifs utilisateurs 4 connectés au système de gestion de données synchronisé 10 via le réseau 5, chaque utilisateur d'un dispositif utilisateur 4 étant affecté à un rôle spécifique de gestion de planification en lien avec le contrôle du trafic aérien. [0068] Chaque dispositif utilisateur 4 peut par ailleurs échanger des données avec d'autres systèmes de contrôle externes tels qu'un système de gestion de ressources d'aviation, un système de gestion de passagers, etc. [0069] Chaque dispositif utilisateur 4 montré dans la figure 2 peut former un outil dédié 11 utilisé par un système de contrôle d'une compagnie aérienne, ces outils étant généralement utilisés pour contrôler des «créneaux » qui correspondent à des fenêtres temporelles dans lesquelles les aéronefs traversent un espace aérien contrôlé. [0070] Dans un exemple d'application de l'invention pour les systèmes de contrôle des compagnies aériennes, des «créneaux » sont émis par les autorités ou les fournisseurs de réseaux de services aériens (ANSP's) sur la hase d'un horaire planifié et d'une attribution (p. ex., premier planifié, premier attribué). Alors que les créneaux sont attribués dans un ordre chronologique, des perturbations peuvent survenir en raison de plusieurs facteurs, cc qui demande une réallocation optimale et dynamique des créneaux attribués pour les divers aéronefs dans un espace aérien donné contrôlé. Par ailleurs les gestionnaires de créneaux doivent non seulement échanger des créneaux entre les vols dans le plan de vol des opérateurs aériens, mais ils doivent également échanger des informations avec d'autres opérateurs de la même compagnie aérienne gérant des outils supplémentaires relatifs au contrôle d'autres paramètres liés au trafic aérien. Des exemples d'outils incluent, par exemple, un outil de planification de vol configuré pour surveiller l'état de la planification d'une compagnie aérienne. Les données gérées par ces outils supplémentaires peuvent être impactécs par un changement de créneau horaire. De façon plus générale, bien que ces outils de gestion de données soient gérés séparément par chaque opérateur associé pour des raisons de sûreté et sécurité, les données gérées par ces outils dépendent les uns des autres dans le sens où un quelconque changement survenant parmi les données gérées par un outil peut impacter un ou plusieurs autres outils. Les compagnies aériennes utilisent ainsi de multiples opérateurs différents pour gérer les données relatives aux planifications de la compagnie aérienne, incluant les gestionnaires de créneaux, les opérateurs de planification, les gestionnaires de maintenance, chacun utilisant un outil de gestion distinct 4 pour gérer les diverses planifications des compagnies aériennes (les planifications de créneaux, les planifications d'équipage, les planifications de maintenance, les plans de vol) de façon à optimiser efficacement et rapidement ces planifications de façon coordonnée dans l'éventualité où un changement dans les données gérées par un des outils surviendrait. Par exemple un outil de créneau horaire générant une vue de la planification d'une compagnie aérienne ainsi qu'une vue distincte des attributions de créneaux peut être fourni à un gestionnaire de créneaux. Lorsqu'un échange de créneaux est identifié, dans les approches d'art antérieur, un gestionnaire de créneaux contacte un gestionnaire de créneaux correspondant d'une autre compagnie aérienne via un réseau privé pour demander un échange de créneaux pour un vol particulier et si un accord est conclu, l'échange de créneaux peut être exécuté. Un coordinateur de créneaux peut aussi être appelé à échanger des données avec un plusieurs autres gestionnaires de planification d'une compagnie aérienne (les gestionnaires d'équipage, les 12 gestionnaires de maintenance, etc.) afin d'échanger des données qui peuvent impacter les données gérées par ces gestionnaires de planification. [0071] Plus spécifiquement, dans l'exemple d'environnement de la figure 2, les dispositifs utilisateurs 4 incluent : [0072] - Un outil de gestion de planification d'une compagnie aérienne 4-1 (également désigné ci-après « outil de planification de compagnie aérienne ») qui est configure pour collecter les données d'autres systèmes afin de suivre l'état de la planification d'une compagnie aérienne ; [0073] - Un outil de gestion PAX 4-2 (également désigné ci-après « outil PAX ») qui est configuré pour agréger les données de passagers relatives à chaque vol de la compagnie aérienne, telles que le nombre de passagers voyageant dans une classe spécifique pour un vol donne ; [0074] - Un outil de gestion de créneaux 4-3 (également désigne ci-après «outil de créneaux ») qui est configuré pour fournir une attribution de créneau horaire (tel que par exemple un créneau horaire pour le décollage ou l'atterrissage) pour chaque vol ; tel qu'il est utilisé ici, un créneau horaire est défini au moins par un horaire de début, un horaire de fin, et un identifiant d'aéroport ; [0075] - Un outil de gestion d'équipage 4-4 (également désigné ci-après « outil d'équipage ») qui est configuré pour agréger les données relatives à l'équipage pour chaque vol, telles que le nombre de personnes attribuées à chaque équipage par catégorie d'équipage (p. ex. pilote) par vol ; [0076] - Un outil de gestion de maintenance 4-5 (également désigné ci-après «outil de maintenance») qui est configuré pour fournir des données de maintenance qui peuvent inclure à la fois les données planifiées et non planifiées pour un aéronef donné (telles que par exemple les vérifications d'unité de puissance auxiliaire (APU). [0077] On remarquera que la liste ci-dessus de dispositifs de gestion de planification 4 n'est pas exhaustive et que le système de gestion de données synchronisé 10 peut se connecter de façon transparente à de nouveaux outils tels que par exemple un outil de gestion de bagages pour surveiller le traitement des bagages des passagers pour chaque vol. [0078] L'outil de planification 4-1 peut gérer un nombre d'aéronefs. L'outil de plani- fication 4-1 peut planifier des horaires différents pour chaque aéronef géré en affectant ces aéronefs aux horaires planifiés. Lorsqu'un aéronef commence un horaire planifié les perturbations au sein d'une compagnie aérienne causées par exemple pal- des conditions météorologiques, des pannes d'aéronefs ou d'autres événements qui peuvent impacter la planification initiale, peuvent survenir. Par conséquent, la planification perturbée peut impacter une autre planification ou des données gérées par d'autres outils 4. Par exemple, une perturbation peut entraîner un retard de vol ce qui 13 peut impactcr la disponibilité dc l'aéronef pour les prochains créneaux, les correspondances des passagers, les planifications d'équipage, etc. [0079] L'outil de gestion d'équipage 4-4 peut comprendre une fonction de planification d'équipage configurée pour déterminer les exigences légales minimums pour les ressources en équipage par vol pour tous plans de planification donnés au cours d'une période en tenant compte de divers paramètres tels que les réglementations nationales et/ou les règlements d'une compagnie, les contraintes d'équipage (p. ex. vacances, journées de repos, formation) et/ou des préférences. Les exigences en matière de ressources équipage peuvent être représentées par hase, flotte ou par catégorie de rang/ fonction individuelle d'équipage. [0080] L'outil de gestion d'équipage 4-4 peut par ailleurs comprendre une fonction d'attribution d'équipage configure° pour générer une affectation d'équipage pour chaque vol en tenant compte de diverses réglementations internationales et/ou nationales, et/ou les règlements de la compagnie, et/ou les demandes et préférences individuelles d'un équipage. [0081] L'outil de gestion d'équipage 4-4 peut aussi comprendre une fonction dc suivi des équipages configurés pour surveiller des ressources de l'équipage d'une compagnie aérienne et identifier de façon dynamique les ressources d'équipage disponibles si des ressources supplémentaires sont nécessaires dans certaines situations. [0082] L'outil de gestion d'équipage 4-4 peut aussi comprendre des enregistrements d'équipage sous forme d'une base de données pour les enregistrements administratifs, médicaux, de formation d'un équipage et des accumulateurs de temps de vol/ responsabilité. [0083] Dans cet exemple d'application de l'invention à un contrôle de trafic aérien, plutôt que de demander, comme dans l'art antérieur, des échanges statiques distincts entre les opérateurs des dispositifs de planification 4, chaque dispositif utilisateur 4 peut émettre une requête au système de gestion de données synchronisé 10, la requête spécifiant au moins : [0084] un plusieurs dispositifs utilisateurs 4 ; un début et une fin de période où date (un jour minimum); une information auxiliaire, telle que le code d'un transporteur (ou d'une compagnie aérienne), le type(s) de flotte(s) d'aéronef(s). [0085] Par exemple, un contrôleur d'opérations de planification peut envoyer une requête de données au système de gestion de données synchronisé 10 via l'outil de planification associé 4-1, en utilisant une requête spécifiant les paramètres suivants : [0086] - dispositif(s) sources = TOUS, [0087] - date de début = 11 -JAN-2018, [0088] - date de fin = 13 -JAN-2018, 14 [0089] - transporteurs = TOUS. [0090] Dans une telle application de l'invention au contrôle du trafic d'une compagnie aérienne, un utilisateur gérant un dispositif utilisateur 4 (également désigné ci-après « opérateur » ou «contrôleur d'opérations » ou «contrôleur ops » ou «partie prenante») désigne l'opérateur responsable pour la gestion d'un aspect des opérations des compagnies aériennes. [0091] Dans certains modes de réalisation, différents droits peuvent être attribués à chaque opérateur contrôleur gérant un des dispositifs externes 20. [0092] Par exemple : [0093] Des droits peuvent être attribués au contrôleur d'opérations gérant l'outil de gestion de planification d'une compagnie aérienne 4-1 pour éditer (c.-à-d. lire/ écrire) des données du stockage commun 3 relatives aux horaires de vol, à un état, à une attribution d'aéronef, etc. Des droits peuvent être attribués au contrôleur d'opérations gérant l'outil de gestion de créneaux 4-3 pour éditer (c.-à-d. lire/écrire) une attribution de créneau horaire pour un vol ; Des droits peuvent être attribués au contrôleur d'opérations gérant l'outil de maintenance 4-5 pour mettre en oeuvre la planification de maintenance sur un aéronef et pour valider (approuver) des changements d'horaires proposés par un ou plusieurs autres contrôleurs d'opérations gérant d'autres dispositifs externes 20. Des droits peuvent être attribués au contrôleur d'opérations gérant l'outil de gestion d'équipage 4-4 pour valider des changements de planification proposée par d'autres contrôleurs d'opérations sur la base de la faisabilité d'une affectation d'équipage dans un système de gestion de ressources d'aviation externe configuré pour contrôler les coûts d'une compagnie aérienne tel que le système ARMS (ARMS est une marque déposée de Sheorey Digital Systems Pvt. Ltd). [0094] La figure 3 illustre un écran graphique d'un exemple d'application au système de gestion de données synchronisé 10 pour le contrôle du trafic aérien. La vue graphique montrée dans la figure 3 est une vue Gantt affichée sur l'interface utilisateur 40. Un ou plusieurs opérateurs peuvent accéder à la vue Gantt simultanément en utilisant leurs dispositifs utilisateurs respectifs 4. [0095] Chaque contrôleur d'opérations gérant le dispositif utilisateur 4 peut se connecter au dispositif utilisateur 4 (par exemple l'outil créneau horaire). L'interface graphique du dispositif externe 4 est ensuite affichée à l'utilisateur. L'utilisateur peut accéder à une interface représentant une vue Gantt pour contrôler les données de planification. La vue Gantt affichée sur chaque dispositif utilisateur 4 peut comprendre des données qui sont communes à tous les dispositifs utilisateurs 4 et les données supplémentaires spécifiques au rôle du dispositif utilisateur. En réponse à une mise à jour du contrôleur d'opérations sur la vue, la vue est auto synchronisée. Par ailleurs, en réponse à la validation d'une mise à jour par le système de gestion de données synchronisé 10, la mise à jour étant demandée par un autre dispositif utilisateur 4 géré par un autre contrôleur d'opérations, la vue Gantt de l'interface graphique de chaque dispositif utilisateur 4 du système 10 est simultanément mise à jour pour refléter les changements. [0096] Comme le montre la figure 3, l'affichage (la vue Gantt) peut comprendre une pluralité d'axes de lignes temporelles horizontales 13, chaque ligne horizontale correspondant à une planification temporelle pour un aéronef donné. [0097] Chaque ligne 13 comprend une identification 1300 de l'aéronef associé (par exemple l'aéronef A319 #17), au commencement de la ligne et un ensemble de cases 1301 cor- respondant à des créneaux horaires. Chaque case 1301 est délimitée par un bord gauche correspondant au départ d'un vol (1302) et un bord droit correspondant à l'arrivée du vol (1303) et est positionnée à un point par rapport à la chronologie compatible avec le départ du vol. Chaque créneau horaire 1301comprend par ailleurs un numéro de vol 1304 représentant le numéro du vol (p. ex. «4431 »). Chaque créneau horaire 1301 est aussi associé à la gauche à une indication 1305 représentant le lieu de départ et à la droite avec une indication 1306 représentant le lieu d'arrivée, dans le format TATA. [0098] Chaque ligne 13 comprend par ailleurs en association avec chaque case de créneau horaire, une indication 1307 du nombre de passagers pour le vol correspondant. Des signalements d'erreur 1308 peuvent être par ailleurs affichés à chaque ligne 13 pour indiquer des en-eurs relatives à la planification, par exemple lorsque le temps de correspondance est trop court. [0099] Par exemple la ligne 13 correspond à l'aéronef A319#17 (référence 1300) et inclut un créneau horaire 1301correspondant au numéro de vol 4527 (référence 1304), un nombre de passagers égal à 104 (référence 1307), un horaire de commencement fixé à «Ilh 25 » (référence 1303) et un horaire final fixé à « 13 h» (référence 1304), un lieu de commencement «CDG» (référence 1305), un lieu final «MRS» (référence 1306). Un signalement d'erreur (1308) est affiché indiquant que le temps de correspondance est trop court (infraction au délai d'escale). [0100] Lorsque le contrôleur d'opérations sélectionne un objet dans la vue (vue Gantt) en utilisant le dispositif utilisateur 4, tel qu'un vol par exemple, cela peut déclencher l'affichage des propriétés du vol dans le coin droit en bas (bloc des propriétés). [0101] L'affichage peut par ailleurs comprendre en bas à droite, des indicateurs clés de per- formance 1310 tels que le retard total d'un vol, la performance en matière de ponctualité OTP, etc. Par ailleurs, l'affichage peut comprendre une indication 1311 du 16 nombre de passagers ayant une correspondance. [0102] Chaque contrôleur d'opérations peut personnaliser la vue selon ses besoins. [0103] Le système de gestion de données synchronisé 10 conformément à des modes de réa- lisation de l'invention peut être implémenté dans un centre d'opérations des compagnies aériennes pour permettre aux divers contrôleurs d'opérations de mettre en oeuvre, de façon collahorative, sûre, ponctuelle et de façon transparente les opérations sur l'ensemble de données conservées dans le stockage commun 3 (telles que les opérations de contrôle, d'accès, de mises àjour) tout en tenant compte des droits de gestion de chaque contrôleur d'opérations par rapport aux données. Cela assure qu'une décision concernant les données prise par un contrôleur d'opérations qui pourrait affecter d'autres dispositifs utilisateurs 4 dans une certaine mesure (avec par exemple un impact mineur ou drastique) peut être appliquée conformément aux droits de gestion de chaque contrôleur d'opérations avec un processus de revue approprié dans le cas des mises à jour. [0104] Dans une telle application, l'invention présente l'avantage d'assurer que les données stockées dans le système de gestion de données synchronisé 10 peuvent être mises à jour de façon collahorative et transparente par un ensemble d'utilisateurs sans aucun conflit de mise àjour. Par exemple, si en raison d'un problème mécanique, un aéronef donné est hors service, deux contrôleurs d'opérations peuvent avoir besoin d'anticiper et envisager diverses solutions/scénarios (solutions exploratrices), telles que par exemple en effectuant des opérations « glisser et déposer » d'un aéronef à un autre dans la vue Gantt. Cependant, ils peuvent souhaiter éviter que les mises à jour soient effectuées sur les données conservées en temps réel dans l'unité de stockage maître 30 parce qu'au final les solutions envisagées ne sont peut-être pas nécessaires, par exemple lorsque l'aéronef peut être réparé. [0105] La description qui suit de certains modes de réalisation de l'invention sera faite prin- cipalement en faisant référence à l'exemple d'application de l'invention aux systèmes de contrôle de trafic aérien à titre d'illustration uniquement, bien que l'homme de métier comprendra aisément que l'invention peut être implémentée dans des applications variées pour permettre à un ensemble d'utilisateurs de modifier des données communes de façon collaborative. [0106] La figure 4 est un organigramme représentant le processus de gestion d'un stockage local 41 sur un dispositif utilisateur 4. [0107] À l'étape 400, un utilisateur équipé d'un dispositif utilisateur donné 4 peut se connecter et s'identifier au système de gestion de données synchronisé 10 en utilisant un processus d'authentification. [0108] Si un accès est accordé à l'utilisateur, à l'étape 402 un affichage de l'interface graphique d'utilisateur 40 peut être généré. 17 [0109] À l'étape 403 un message (également désigné comme requête de synchronisation) peut être reçu par l'utilisateur en provenance du système de gestion de données synchronisé 10, le message comprenant un nouvel ensemble de mises à jour correspondant à un sous-ensemble de données maîtres stockées dans le stockage maître 30. [0110] À l'étape 404 en réponse à la réception du nouvel ensemble de mises à jour reçu du système de gestion de données synchronisé 10, des conflits entre les mises à jour maîtres reçues en temps réel et, des changements locaux sur le dispositif utilisateur sont résolus si un conflit entre les données est détecté. [0111] À l'étape 405, l'utilisateur gérant le dispositif utilisateur 4 qui a reçu une nouvelle mise à jour peut faire un ensemble de modifications au sous-ensemble de données (également désigné comme « sous-ensemble de données maîtres ») reçu du stockage maître 30 du système de données synchronisé 10. [0112] À l'étape 406, ces changements effectués par l'utilisateur peuvent être stockés dans un stockage local 41 du dispositif utilisateur 4, pour s'y référer par la suite, ces changements formant une « solution préliminaire» (également désignée comme « version de mise à jour préliminaire »). [0113] À l'étape 407 la version dispositif mise à jour préliminaire stockée dans le stockage local 41 du dispositif utilisateur 4 peut être partagée en publiant (ou plus généralement en envoyant) la version de mise àjour préliminaire (correspondant à une mise àjour du sous-ensemble de données maîtres reçu du stockage maître 30 et chargé dans le stockage local 41) au système de gestion de données synchronisé 10. [0114] La figure 5 est un organigramme représentant le processus d'un traitement de message correspondant à une solution préliminaire publiée reçue d'un dispositif utilisateur 4 par le système de gestion de données synchronisé 10. [0115] À l'étape 501, en réponse à la réception d'un message correspondant à une version préliminaire de mise à jour publiée reçue d'un dispositif utilisateur 4 au bloc 500 (correspondant à l'étape 407 de la figure 4), au moins une partie de la solution préliminaire, correspondant aux modifications effectuées par l'utilisateur sur le sous-ensemble de données maîtres, est stockée dans le stockage auxiliaire 31. À l'étape 501, des informations supplémentaires relatives au contexte des données (données contextuelles identifiant les données maîtres du sous-ensemble de données qui a été utilisé pour créer la solution préliminaire) peuvent être stockées dans le stockage auxiliaire 31 en association à la solution préliminaire Les données ainsi stockées dans le stockage auxiliaire forment donc une « mise à jour préliminaire». [0116] À l'étape 502, un identifiant unique peut être attribué à la mise à jour préliminaire dans le stockage auxiliaire 31. L'identifiant unique peut être généré à partir d'un identifiant unique généré par le système (ID) et d'un identifiant d'utilisateur. [0117] La mise à jour préliminaire ainsi stockée dans le stockage auxiliaire 31 du stockage 18 commun 3 peut ensuite être accédée par un ensemble d'utilisateurs sélectionnés tels que des utilisateurs gérant un dispositif utilisateur 4 qui peut être impacté par des modifications incluses dans la mise à jour préliminaire. La mise àjour préliminaire correspond donc à un ensemble de mises à jour effectuées par au moins un utilisateur au sous-ensemble de données maître. [0118] En réponse à une requête reçue d'un utilisateur demandant une mise à jour du stockage auxiliaire pour revoir la mise àjour préliminaire (bloc 503), si l'utilisateur est authentifié comme appartenant à un ensemble d'utilisateurs de revue sélectionnés, la mise à jour préliminaire est récupérée du stockage auxiliaire 31 à l'étape 504. [0119] À l'étape 506, la misc à jour préliminaire est envoyée au dispositif utilisateur demandeur 4. Autrement, les étapes 504 et 506 peuvent être remplacées par une étape consistant à envoyer automatiquement la mise à jour préliminaire à un ensemble prédéfini d'utilisateurs de revue sélectionnés, pour revue par ces utilisateurs. [0120] La figure 6 est un organigramme représentant le processus de revue d'une mise àjour préliminaire par un utilisateur demandeur en utilisant le dispositif utilisateur 4 (l'utilisateur demandeur est également désigné « dispositif de revue » ci-après), en réponse à la réception d'une mise àjour préliminaire provenant du stockage auxiliaire 31. [0121] À l'étape 600, la misc à jour préliminaire est reçue par le dispositif demandeur 4. [0122] Si le dispositif utilisateur 4 n'inclut pas déjà le sous-ensemble de données maîtres associé à la mise à jour préliminaire, à l'étape 602, une requête auxiliaire peut être envoyée au système de gestion de données synchronisé 10, la requête auxiliaire identifiant le contexte des données incluses dans la solution préliminaire reçue. [0123] À l'étape 604, en réponse à la requête auxiliaire, un sous-ensemble de données maîtres correspondant au contexte des données peut être reçu par le dispositif utilisateur de revue. [0124] À l'étape 606, la résolution de conflits peut être effectuée sur les données reçues (le sous-ensemble de données maître et la mise à jour préliminaire) pour détecter et résoudre des conflits possibles dans les données actualisées. [0125] À l'étape 608, les mises à jour correspondant aux modifications effectuées au sous- ensemble de données maître peuvent être identifiées par le dispositif utilisateur de revue à partir de la mise à jour préliminaire. Les changements peuvent ensuite être soulignés dans l'interface graphique d'utilisateur du dispositif utilisateur 4 pour permettre une identification rapide et facile des changements par l'utilisateur de revue. [0126] À l'étape 610, l'utilisateur peut être invité à revoir la mise à jour préliminaire, en utilisant l'interface graphique d'utilisateur 40 du dispositif utilisateur 4 utilisé par le dispositif de revue. [0127] À l'étape 612, si l'utilisateur effectue des modifications supplémentaires dans la mise 19 à jour préliminaire (version modifiée de la mise à jour préliminaire), la version modifiée de la mise à jour préliminaire est sauvegardée et à l'étape 614, la version modifiée de la mise jour préliminaire est soumise à un ensemble de dispositifs utilisateurs de revue pour revue et validation par ces utilisateurs. [0128] À l'étape 616, si l'utilisateur effectue des modifications supplémentaires dans la mise à jour préliminaire (version modifiée de la mise à jour préliminaire), la version modifiée de la mise àjour préliminaire est publiée (ou envoyée) au stockage maître 30 (étape 617). [0129] À l'étape 618, l'utilisateur peut autrement envoyer une requête (requête de « va- lidation ») au système de gestion de données synchronisé 10 pour publier la mise àjour préliminaire dans le stockage maître 30. Cela peut correspondre à une notification d'une validation des modifications incluses dans la mise à jour préliminaire moyennant quoi l'utilisateur approuve les modifications. [0130] Autrement, à l'étape 620, l'utilisateur peut envoyer une notification de rejet au système de gestion de données synchronisé 10 pour notifier un rejet partiel ou complet de la mise à jour préliminaire moyennant quoi l'utilisateur rejette au moins une partie des modifications correspondant à la mise à jour préliminaire. [0131] En réponse à la réception d'une requête de validation (étape 618 de la figure 6), le procédé de mise à jour implémenté dans le système de gestion de données synchronisé 10 peut comprendre une étape consistant à stocker l'information relative au message de validation reçu du dispositif utilisateur de l'utilisateur de revue et à attendre les retours des dispositifs de revue restants. Dans un mode de réalisation, la mise à jour préliminaire peut être stockée dans le stockage maître 30 si tous les retours reçus des dispositifs de revue, de l'ensemble sélectionné de dispositifs de revue, comprennent une requête de validation. Dans certains modes de réalisation, des retours de dispositifs de revue peuvent être attendus pendant une durée prédéfinie et seuls les retours d'information reçus au cours de la durée prédéfinie peuvent être pris en compte. Dans certains modes de réalisation, une notification peut être envoyée pour le dispositif utilisateur initiateur 4 qui a initialement effectué la mise à jour préliminaire, chaque fois que la revue de la mise à jour préliminaire est achevé par un des dispositifs de l'ensemble de dispositifs de revue sélectionnés 4. [0132] En réponse à la réception d'une notification de rejet relatif à au moins une partie des mises à jour comprises dans la mise à jour préliminaire (étape 620 de la figure 6), le procédé de mise à jour implémenté dans le système de gestion de données synchronisé 10 peut rejeter la partie des mises à jour identifiée par la notification de rejet. Par conséquent, la partie rejetée des mises à jour ne sera pas stockée dans le stockage maître. [0133] La [fig.7] est un organigramme représentant le processus de publication d'une mise à jour préliminaire validée dans le stockage maître 30 en réponse aux requêtes de validation reçues de tous les utilisateurs de revue de l'ensemble des dispositifs de revue par le système de gestion de données synchronisé 10. [0134] À l'étape 700, il est déterminé si les requêtes de validation pour publier une mise à jour préliminaire validée dans le stockage maître ont été reçues de tous les utilisateurs de revue de l'ensemble des dispositifs de revue. [0135] Dans l'affirmative, à l'étape 702, les modifications incluses dans la mise à jour pré- liminaire validée sont stockées dans le stockage maître 30 dans un format de données pris en charge par le système de gestion de données synchronisé 10. [0136] À l'étape 704, un message comprenant des données identifiant les mises à jour cor- respondant à la mise à jour préliminaire validée (ci-après désignées « données actualisées») peut par ailleurs être envoyé à chaque dispositif utilisateur 4 parmi un ensemble sélectionné de dispositifs utilisateurs via le réseau 5. Le message incluant les données actualisées peut être encodé en utilisant un mécanisme d'encodage, et être envoyé aux dispositifs utilisateur 4 de l'ensemble de dispositifs utilisateurs sélectionnés dans une forme encodée. [0137] La [fig.8] est un diagramme bloc illustrant de façon schématique un ordinateur 60 qui peut être utilisé pour implémenter les composants du système de gestion de données 10 et/ou les dispositifs utilisateurs 4 conformément à des modes de réalisation. [0138] L'ordinateur 60 peut comprendre, par exemple, un plusieurs dispositifs sélectionnés parmi les dispositifs suivants : ordinateur de bureau, ordinateur portable, poste de travail, tablette numérique, smartphone, ordinateur portatif, serveur au niveau de l'entreprise, ou tout autre dispositif informatique de ce genre. Une combinaison de dispositifs différents peut être utilisée dans certains modes de réalisation. [0139] L'ordinateur 60 peut inclure un processeur 32, une mémoire 34, un dispositif de mémoire de masse 36, une interface entrée/sortie (1/0) 38, et une interface homme-machine (HMI) 39. L'ordinateur 60 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources extérieures 42 par l'intermédiaire du réseau 6 (qui peut par exemple être le réseau 21) et/ou de l'interface I/O 38. Les ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau basé sur le cloud, ou toute autre ressource informatique appropriée qui peut être utilisée avec l'ordinateur 60. [0140] Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés : micropro- cesseurs, microcontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques, ou tout autre dispositif servant à manipuler des 21 signaux (analogues ou numériques) basés sur des instructions de fonctionnement enregistrées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment, mais sans s'y limiter, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, r antememoirc (cache memory) ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de niasse 36 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide non volatile, ou tout autre dispositif capable de stocker des informations. Une base de données 44 peut résider sur le dispositif de stockage de masse 36, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits ici. [0141] Le processeur 32 peut fonctionner sous le contrôle d'un système d'exploitation 46 qui réside dans la mémoire 34. Le système d'exploitation 46 peut gérer les ressources de l'ordinateur de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application, tels que l'application 48 qui réside dans la mémoire 34 puisse disposer d'instructions exécutées par le processeur 32. Dans un autre mode de réalisation, le processeur 32 peut exécuter l'application 48 directement et dans ce cas, le système d'exploitation 46 peut être omis. Une ou plusieurs structures de donnée 50 peuvent également résider dans la mémoire 34, et peuvent être utilisées par le processeur 32, le système d'exploitation 46, ou l'application 48 pour stocker ou manipuler des données. [0142] L'interface VO 38 peut fournir une interface machine qui couple le processeur 32 de façon fonctionnelle avec d'autres dispositifs et systèmes, tels que le réseau 6 ou la ressource externe 42. Le serveur d'application 48 peut ainsi collaborer avec le réseau 6 ou avec la ressource externe 42 en communiquant par l'intermédiaire de l'interface 11 0 38 pour fournir les divers éléments, fonctions, applications, processus, modules composant les modes de réalisation de l'invention. L'application 48 peut aussi comporter un code de programme qui est exécuté par une ou plusieurs ressources externes 42, ou repose autrement sur les fonctions ou signaux fournis par d'autres composants de système ou de réseau externes à l'ordinateur 60. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications situées à l'extérieur de l'ordinateur 60, distribuées à des ordinateurs multiples ou à d'autres ressources externes 42 ou fournies par des ressources informatiques (matériel et logiciel) qui sont fournies par un service tel qu'un service informatique cloud, par l'intermédiaire du réseau 6. [0143] Le HMI 39 (tel que le HMI 40 dans l'implémentation de la figure 1 du dispositif client 4) peut être couplé de façon fonctionnelle au processeur 32 de l'ordinateur 60 d'une façon connue pour permettre à un utilisateur de l'ordinateur 60 d'interagir directement avec l'ordinateur 60. Le HMI 39 peut inclure un affichage vidéo ou alphanumérique, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. Le HMI 39 peut aussi inclure des dispositifs d'entrée et des contrôles tels qu'un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoirs, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des saisies dc l'utilisateur, et de les transmettre au processeur 32. [0144] Une base de données 44 peut résider sur le dispositif de mémoire dc masse 36, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits ici. La base de données 44 peut inclure des données ainsi que les structures de donnée qui les accommodent pour stocker et organiser les données. En particulier, la base de données 44 peut être aménagée avec toute organisation ou structure de base de données, notamment, mais de façon non restrictive, une base de données relationnelle, une base de données de type hiérarchique, une hase de données en réseau, une base de données orientée objet, ou des combinaisons de celles-là. Un système de gestion de base dc données sous forme de logiciel informatique d'application qui s'exécute sous la forme d'instructions sur le processeur 32 peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la base de données 44 en réponse à une interrogation, lorsqu'une interrogation peut être déterminée de façon dynamique et exécutée par le système d'exploitation 46, les autres applications 48, ou un ou plusieurs modules. Bien que des modes de réalisation de l'invention puissent être décrits ici en utilisant une terminologie de base de données relationnelle, hiérarchique, de réseau, orientée-objet, ou autre terminologie dans des cas spécifiques, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent utiliser tout modèle de gestion de base de données approprié, et ne sont pas limités à un quelconque type particulier de base de données. [0145] Alors que l'invention présente des avantages particuliers dans le domaine des systèmes de tours de contrôle des compagnies aériennes, on notera que l'invention s'applique également à la gestion de données accessibles par de multiples dispositifs externes, quasiment dans un environnement en temps réel où chaque dispositif externe gère un type de planification de données, la planification de données gérée par un dispositif externe donné étant impactée par les données gérées par un plusieurs autres dispositifs externes. [0146] En général les routines exécutées pour mettre en oeuvre les modes de réalisation de 23 l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ces facteurs, peuvent être désignées « code de programme informatique» ou simplement «code de programme». Un code de programme comporte typiquement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l'ordinateur à effectuer des d'opérations nécessaires à l'exécution d'opérations et/ou d'éléments propres à la mise en oeuvre des aspects variés des modes de réalisation de l'invention. Les instructions d'un programme, lisibles par ordinateur, pour mettre en oeuvre les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage, ou encore un code source ou un code objet écrit en combinaison avec un ou plusieurs langages de programmation. [0147] Divers codes de programme décrits ici peuvent être identifiés, selon l'application dans laquelle ils sont implémentés, dans des modes de réalisation spécifiques de l'invention. Cependant, il doit être notéque toute nomenclature d'un programme particulier est utilisée ici uniquement par convenance, et que donc l'utilisation de l'invention ne peut être limitée uniquement à toute application spécifique identifiée et/ ou impliquée par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d'allouer les fonctionnalités d'un programme aux diverses couches de logiciels qui sont hébergés dans un ordinateur typique (p. ex., les systèmes d'exploitation, les bibliothèques, les interfaces d'application de prograrmne (APIS), les applications, les petites applications (applets) etc.), il doit être noter que les modes de réalisation de l'invention ne sont pas limités à l'organisation et à l'allocation spécifiques des fonctionnalités de programme décrites ici. [0148] Le code de programme mis en oeuvre dans une/un quelconque des applications/ modules décrit(e)s ici peut être distribué individuellement ou collectivement comme un produit-programme d'ordinateur, sous une variété de formes. En particulier, le code de programme peut être distribué en utilisant un support de stockage lisible par ordinateur, disposant d'instructions de programme lisibles par ordinateur en lui-même, permettant à un processeur de mettre en oeuvre des aspects des modes de réalisation de l'invention. [0149] Les supports de stockage lisibles par ordinateur, qui sont intrinsèquement non tran- sitoires, peuvent inclure des supports tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage 24 d'information, tels que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires RAM, ROM, à lecture exclusivement, programmable et effaçable (EPROM), à lecture exclusivement, programmable et effaçable électriquement (EEPROM), une mémoire flash, ou toute technologie de support solide de mémoire (disque compact portable doté d'une mémoire à lecture seule [CD-ROM], ou tout autre stockage optique, cassettes magnétiques, bandes d'enregistrement magnétique, disque de stockage magnétique, autres dispositifs de stockage magnétique, ou tout autre support pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme signaux transitoires en soi [par exemple, des ondes radio ou toutes autres ondes électromagnétiques se propageant entre un support de transmission telle qu'un guide d'ondes, ou des signaux électriques transmis par câble]. Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par ordinateur, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau. [0150] Les instructions de programme lisibles par ordinateur, enregistrées sur un support lisible par ordinateur, peuvent être utilisées pour amener un ordinateur, d'autres types d'appareils programmables de traitement de données, ou d'autres dispositifs, à fonctionner d'une façon particulière, de sorte que les instructions stockées sur le support lisible par ordinateur produisent un article de fabrication incluant les instructions qui mettent en oeuvre les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies à un ou plusieurs processeurs d'un ordinateur à usage général ou un ordinateur dédié ou un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu'elles sont exécutées à l'aide du ou des processeurs, accomplissent une série de calculs pour mettre en oeuvre les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs. [0151] Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, il n'est pas dans l'intention du demandeur de restreindre ou de limiter de quelque manière que ce soit le champ d'application des revendications annexées à de tels détails. Des avantages et des modifications supplémentaires apparaîtront aisément aux hommes de métier. Bien que les modes de réalisation des figures 4 à 7 aient été décrits selon un ordre de traitement particulier, l'homme de métier comprendra aisément que l'invention n'est pas limitée à cette séquence d'étapes et que certaines étapes peuvent être implémentées dans un ordre différent. De façon générale, dans certains autres modes de réalisation, les fonctions, les actions et/ou des opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou des diagrammes blocs peuvent être ré-ordonnées, traitées en série, et/ou traitées en même temps conformément aux modes de réalisation de l'invention. De plus, tout organigramme, diagramme séquentiel et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés, tout en restant cohérents avec les modes de réalisation de l'invention. 26 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4]