FR 3145430 A1 20240802 FR 2400897 A 20230829 La présente spécification propose une surveillance de l’intégrité des données et une rétroaction dans les plateformes informatiques basées sur le nuage. Bien que ces plateformes soient omniprésentes et fournissent un moyen d’étendre l’informatique à l’échelle mondiale, le besoin d’une intégrité fiable des données augmente également avec l’extension de l’échelle. Un système conforme à un mode de réalisation comporte un moteur de surveillance de l’intégrité des données qui s’intègre aux plateformes informatiques en nuage existantes et qui surveille les événements correspondant à la réception de fichiers et vérifie la fréquence et la taille de ces fichiers. Surveillance de l’intégrité des données et contrôle de rétroaction pour l’informatique basée sur le nuage Arrière-plan L’informatique en nuage offre de puissantes ressources informatiques à travers le monde, y compris la capacité de fournir une normalisation puissante des données provenant de différents serveurs fonctionnant dans des conditions différentes. Les données normalisées qui en résultent peuvent ensuite être utilisées pour contrôler d’autres systèmes. Résumé L’invention divulguée ici est définie par les revendications. Un aspect de la présente divulgation propose un système de surveillance de l’intégrité des données pour une plateforme informatique basée sur le nuage comprenant un serveur en nuage. Le serveur en nuage peut être connecté à un moteur de source de données via un réseau. Le serveur en nuage est doté d’une unité de stockage et d’un serveur de fichier pour recevoir des données du moteur de source de données et pour sauvegarder les données dans l’unité de stockage. Un gestionnaire d’événements peut être connecté au serveur de fichier pour détecter les événements représentant la sauvegarde des données. Un moteur de mise en file d’attente peut être connecté au gestionnaire d’événements pour stocker les métadonnées des événements. Un moteur de surveillance peut également être connecté au serveur en nuage pour traiter des caractéristiques des métadonnées pour déterminer l’intégrité des données d’événement. Le moteur de surveillance est configuré pour initier un processus de réponse si l’intégrité des caractéristiques de métadonnées (ou des caractéristiques de traitement des métadonnées) répond à un critère prédéterminé (ou en d’autres termes, si une erreur (ou une défaillance) de l’intégrité des données se produit). L’intégrité des données peut être basée sur une continuité temporelle attendue de la réception des événements. L’intégrité des données peut être basée sur une quantité de données attendue associée aux événements (une taille attendue des données des événements). Le serveur en nuage peut être connecté à au moins un moteur d’agrégation de données. Le processus de réponse peut contrôler la disponibilité des données de partition associées aux événements pour un moteur qui accède aux données de partition. Le processus de réponse peut être ou comprendre un message d’alarme envoyé à au moins un moteur d’agrégation de données connecté au réseau. Le moteur de surveillance peut être intégré dans le serveur en nuage. Un autre aspect de la présente divulgation propose un moteur de surveillance comprenant une interface d’un réseau pour la connexion, via le réseau, à au moins un moteur de source de données connecté au réseau. Le moteur de surveillance est également destiné à la connexion à un serveur en nuage qui est également connecté au moteur de source de données. Le serveur en nuage comporte une unité de stockage et un serveur de fichier pour recevoir des données du moteur de source de données et sauvegarder les données dans l’unité de stockage. Le serveur en nuage comporte également un gestionnaire d’événements connecté au serveur de fichier pour détecter des événements associés à la sauvegarde des données. Le serveur en nuage comporte également un moteur de mise en file d’attente connecté au gestionnaire d’événements pour stocker les métadonnées des événements. Le moteur de surveillance est configuré pour traiter les caractéristiques des métadonnées pour déterminer l’intégrité des données d’événement. Le moteur de surveillance est également configuré pour initier un processus de réponse si l’intégrité des caractéristiques de métadonnées (ou des caractéristiques de traitement des métadonnées) répond à un critère prédéterminé (ou en d’autres termes, si une erreur (ou une défaillance) de l’intégrité des données se produit). L’intégrité des données peut être basée sur une continuité temporelle attendue de la réception des événements. L’intégrité des données peut être basée sur une quantité de données attendue associée aux événements (une taille attendue des données des événements). Le moteur de surveillance peut comprendre en outre une connexion à au moins un moteur d’agrégation de données connecté au réseau. Le processus de réponse peut contrôler la disponibilité des données de partition associées aux événements pour un moteur qui accède aux données de partition. Le processus de réponse peut être ou comprendre un message d’alarme envoyé au moteur d’agrégation de données. Le moteur de surveillance peut être intégré dans le serveur en nuage. Un autre aspect de la présente divulgation propose un procédé de surveillance de l’intégrité des données qui peut, à l’aide d’un moteur de surveillance ou au niveau de celui-ci, être exploité par le moteur de surveillance connecté, via un réseau, à au moins un moteur de source de données connecté au réseau et à un serveur en nuage connecté au moteur de source de données ; le serveur en nuage étant doté : d’une unité de stockage ; d’un serveur de fichier pour recevoir des données du moteur de source de données et sauvegarder les données dans l’unité de stockage ; d’un gestionnaire d’événements connecté au serveur de fichier pour détecter des événements représentant la sauvegarde des données ; d’un moteur de mise en file d’attente connecté au gestionnaire d’événements pour stocker les métadonnées des événements ; le procédé comprenant : le traitement des caractéristiques des métadonnées pour déterminer l’intégrité des données d’événement ; l’initiation d’un processus de réponse si l’intégrité des caractéristiques de métadonnées (ou des caractéristiques de traitement des métadonnées) répond à un critère prédéterminé (ou en d’autres termes, si une erreur (ou une défaillance) de l’intégrité des données se produit). L’intégrité peut être basée sur une continuité temporelle attendue de la réception des événements. L’intégrité peut être basée sur une quantité de données attendue associée aux événements (une taille attendue des données des événements). Le processus de réponse peut contrôler la disponibilité des données de partition associées aux événements pour un moteur qui accède aux données de partition. Le processus de réponse peut être ou comprendre un message d’alarme envoyé à au moins un moteur d’agrégation de données connecté au réseau. Un autre aspect de la présente divulgation propose un procédé de contrôle d’une réponse à une erreur (ou à une défaillance) de l’intégrité des données comprenant : la détection d’un événement correspondant à une nouvelle partition dans un conteneur préexistant ; la génération d’un ensemble de nouvelles métadonnées représentant les caractéristiques du conteneur ; la comparaison des nouvelles métadonnées avec des métadonnées antérieures représentant les caractéristiques du conteneur avant l’événement ; et l’initiation d’un processus de réponse si la comparaison répond à un critère prédéfini. Le procédé peut avoir lieu au sein d’un serveur en nuage. Les caractéristiques peuvent comprendre une heure d’arrivée de l’événement, et le critère prédéfini est basé sur le moment où le temps entre l’arrivée du nouvel événement et de l’événement précédent est dépassé. Les caractéristiques peuvent comprendre une taille de la partition, et le critère prédéfini est basé sur le moment où une différence entre la taille de la partition du nouvel événement et la taille de la partition de l’événement précédent devient supérieure ou inférieure à un seuil prédéfini. Les caractéristiques peuvent comprendre un nombre de fichiers dans la partition, et le critère prédéfini est basé sur le moment où la différence entre nombre de fichiers dans la partition du nouvel événement et le nombre de fichiers dans la partition de l’événement précédent est supérieure ou inférieure à un seuil prédéfini. Les caractéristiques peuvent comprendre une quantité de données dans la partition, et le critère prédéfini est basé sur le moment où la différence entre la quantité de données dans la partition du nouvel événement et une quantité de données de l’événement précédent est supérieure ou inférieure à un seuil prédéfini. Le processus de réponse peut comprendre le contrôle d’une interface graphique interactive sur un dispositif client pour empêcher une entrée de réponse basée sur un contenu du conteneur associé à l’événement. L’événement peut avoir lieu au sein d’un moteur de gestionnaire d’événements du serveur en nuage, et le conteneur peut être conservé par un serveur de fichier et un stockage au sein du serveur en nuage. La partition peut être alimentée par un moteur de source de données qui se connecte au serveur en nuage, et la partition est préparée par un moteur d’agrégation qui se connecte au serveur en nuage. Le procédé de contrôle d’une réponse à une erreur (ou à une défaillance) de l’intégrité des données peut faire partie du procédé de surveillance de l’intégrité des données (susmentionné), y être intégré ou combiné. Un autre aspect de la présente divulgation propose un appareil ou un système pour réaliser le procédé de contrôle d’une réponse à une erreur (ou à une défaillance) de l’intégrité des données, tel qu’il est décrit ci-dessus (avec ses variantes, ses spécificités, etc.). Brève description des Figures est un diagramme schématique d’un système de surveillance de l’intégrité des données et de contrôle de rétroaction dans une plateforme informatique en nuage. est un schéma de principe d’un exemple de composants internes d’un quel-conque nœud informatique dans la . montre un organigramme décrivant la surveillance et le contrôle de rétroaction de l’intégrité des données dans une plateforme informatique basée sur le nuage. montre le système de la avec les flux de données d’un conteneur allant d’un moteur de source de données à un stockage de fichiers dans la plateforme informatique en nuage. montre un exemple de structures de conteneurs qui peuvent être utilisées dans le système. montre la structure d’un exemple de conteneur de la . montre un organigramme d’un exemple de mode de réalisation de la performance de l’initialisation de la surveillance des métadonnées. montre un graphique représentant la surveillance de la fréquence d’arrivée des données dans la plateforme informatique en nuage. Description détaillée Les plateformes informatiques en nuage sont omniprésentes. Parmi les exemples non limitatifs de plateformes informatiques en nuage populaires, on peut citer les services infonuagiques AzureTM ("Azure"), les services Web AmazonTM ("AWS") et la plateforme infonuagique GoogleTM ("Google Cloud"). L’informatique en nuage offre la possibilité de mettre rapidement en réseau des centaines de milliers de serveurs et d’ordinateurs clients dotés de puissantes ressources informatiques collectives dans diverses zones géographiques. Une telle puissance offre la possibilité de normaliser, de traiter et de générer des sorties qui peuvent être utilisées pour contrôler d’autres ressources informatiques à l’échelle mondiale, souvent en temps réel. La complexité de ces systèmes les rend sensibles aux erreurs de performance. Un seul point de défaillance, que ce soit au sein de la plateforme elle-même ou sur les ordinateurs qui se connectent à la plateforme, peut avoir des conséquences négatives importantes. La surveillance de l’intégrité des données peut s’avérer cruciale pour mettre en œuvre des réponses pour contrôler et atténuer l’effet de ces défaillances. Bien que de nombreuses fonctions d’intégrité des données soient construites dans les plateformes informatiques en nuage, et bien que ces plateformes existent depuis des années et soient de plus en plus matures, de graves manquements à l’intégrité des données peuvent encore se produire. Un exemple d’un manquement spécifique à l’intégrité des données qui peut être atténué à l’aide de la présente invention implique l’agrégation de fichiers de données provenant de différentes sources de données qui dépendent de la synchronisation et/ou de la taille des fichiers de données qui sont reçus de chaque source. Le secteur du voyage est un exemple où certaines erreurs (ou défaillances) d’intégrité des données peuvent être graves. Par exemple, les sources de données du secteur du voyage peuvent inclure des données provenant de serveurs hébergés par des acteurs du voyage tels que les compagnies aériennes, les trains, les bateaux de croisière et d’autres services de transport. D’autres acteurs du voyage peuvent comporter des hôtels, des restaurants, des spas ou d’autres prestataires de services d’accueil. Parmi les exemples d’agrégateurs de données, on peut citer les moteurs de réservation de voyages, ou un intermédiaire agissant pour le compte des moteurs de réservation de voyages. Les voyageurs utilisant leur dispositif client (tel que les ordinateurs portables, les ordinateurs de bureau, les téléphones intelligents et les tablettes) comptent sur l’exactitude des données normalisées provenant de l’agrégateur de données pour évaluer les options, et envoient des demandes de réservation à leur tour. Étant donné que les serveurs de sources de données sont exploités par différentes entités selon des architectures informatiques différentes, des lacunes et/ou des erreurs dans la fréquence ou la taille des transmissions à l’agrégateur peuvent entraîner un effet de cascade fournissant des données erronées aux dispositifs clients. Ces données erronées peuvent par exemple ne pas indiquer les annulations, la disponibilité ou les prix. Il peut en résulter que même une seule défaillance d’un seul acteur du voyage peut saper la confiance dans la fiabilité de l’ensemble des données agrégées. D’un point de vue technique, de telles défaillances entraînent un gaspillage des ressources de trafic réseau et un gaspillage des ressources de traitement informatique dans la plateforme informatique en nuage sur l’ensemble de l’internet lui-même. La montre un système de surveillance de l’intégrité des données et de contrôle de rétroaction indiqué de manière générale par 100. Le système 100 comprend une plateforme informatique en nuage 102 qui comprend à son tour une pluralité de moteurs d’informatique en nuage 104-1, 104-2, …,104-n. Collectivement, les moteurs d’informatique en nuage 104-1, 104-2, …,104-n sont appelés moteurs d’informatique en nuage 104, et de manière générique, moteur d’informatique en nuage 104. Cette nomenclature est utilisée ailleurs dans le présent document. Les moteurs d’informatique en nuage 104 peuvent être des instances multiples et/ou en miroir les unes par rapport aux autres, ou des moteurs d’informatique en nuage 104 autonomes. La plateforme informatique en nuage 102 peut par exemple être basée sur des plateformes connues qui disposent de moteurs d’informatique en nuage 104 pouvant être loués par d’autres entreprises, telles qu’Azure, AWS ou Google Cloud. D’autres plateformes vont maintenant apparaître aux personnes compétentes dans l’art, comportant des plateformes propriétaires où un ou plusieurs moteurs d’informatique en nuage 104 sont la propriété d’une entreprise particulière plutôt que des plateformes louées telles qu’Azure, AWS et Google Cloud. Dans le système 100, la plateforme 102 se connecte à un réseau 106 tel que l’Internet. Le réseau 106 interconnecte la plateforme 102, une pluralité de moteurs de source de données 108, au moins un moteur d’agrégation de données 112, et une pluralité de dispositifs clients 116. On comprendra, à la lumière de la spécification, que le moteur de source de données 108 et le moteur d’agrégation de données 112 peuvent comporter les fonctions l’un de l’autre, que moteur d’agrégation 112 peut comporter la fonctionnalité d’un moteur de source de données 108, et qu’un ou plusieurs des moteurs de source de données 108 peuvent comporter la fonctionnalité du moteur d’agrégation de données 112. Toutefois, à des fins de simplification de l’explication du présent mode de réalisation, la discussion qui suit supposera une distinction nette entre les moteurs de source de données 108 et le moteur d’agrégation de données 112. Une fois cette explication comprise, une personne compétente dans l’art reconnaîtra comment la présente invention s’adapte à des scénarios plus complexes où un moteur de source de données 108 ou un moteur d’agrégation de données 112 donné peut en plus comporter la fonctionnalité de l’autre. Comme nous l’expliquerons plus en détail ci-dessous, chaque moteur de source de données 108 peut être basé sur sa propre architecture informatique et enverra périodiquement des fichiers de données d’un format prédéfini à la plateforme informatique en nuage 102. Dans le présent exemple mode de réalisation, les moteurs de source de données 108 sont exploités par des acteurs du voyage du secteur du voyage, y compris, mais sans s’y limiter, les compagnies aériennes, les systèmes ferroviaires, les agences de location de voitures, les opérateurs de lignes de croisière, les hôtels, les centres de villégiature, et les spas. À son tour, le moteur d’agrégation de données 112 reçoit périodiquement les fichiers de données qui ont été envoyés par les moteurs de source de données 108 via la plateforme informatique en nuage 102. Dans le présent exemple de mode de réalisation, le moteur d’agrégation de données 112 est par exemple exploité ou accessible par un moteur de réservation de voyages. Pour être plus précis, un moteur de réservation de voyages pourrait comporter des moteurs de réservation de voyages bien connus tels que ExpediaTM, TravelocityTM ou Hotels.comTM. Il existe également de nombreux autres moteurs de réservation de voyages. Le moteur d’agrégation de données 112 peut donc être hébergé directement par un tel moteur de réservation de voyages, ou peut être un hébergé par un agrégateur de données de voyage, souvent appelé système mondial de distribution ("GDS" pour Global Distribution System), tel qu’AmadeusTM, SabreTM, TravelportTM, ApolloTM et GalileoTM. Il faut donc comprendre que le moteur d’agrégation de données 112 n’a pas besoin d’avoir la capacité de servir de moteur de réservation, mais plutôt que les enseignements présentés ici peuvent en fin de compte améliorer l’efficacité technologique et l’utilisation des ressources informatiques des moteurs de réservation de voyages et d’autres moteurs (non représentés) qui utilisent les données agrégées par le moteur d’agrégation de données 112. Il convient de souligner à nouveau que les présents exemples axés sur le secteur du voyage ne sont pas limitatifs, et que la présente invention peut s’appliquer à d’autres applications et secteurs de l’informatique en nuage, comportant par exemple le secteur des services financiers et la négociation électronique associée des instruments financiers. Il est entendu que les moteurs de source de données 108 et le moteur d’agrégation de données 112 peuvent eux-mêmes être hébergés sur une plateforme informatique en nuage. Toutefois, à titre d’illustration, dans le système 100, la plateforme informatique en nuage 102 est l’infrastructure technologique qui sert d’intermédiaire entre le flux de données allant des moteurs de source de données 108 au moteur d’agrégation de données 112, et la technologie utilisée pour mettre en œuvre les moteurs de source de données 108 dans le moteur d’agrégation de données 112 n’est pas particulièrement limitée par la présente spécification. Les dispositifs clients 116 peuvent être des ordinateurs portables, des ordinateurs de bureau, des téléphones mobiles, des tablettes et tout autre dispositif qui peut être utilisé par les consommateurs pour recevoir des données agrégées du moteur d’agrégation de données 112. Dans le contexte du secteur du voyage, les dispositifs clients 116 interagissent avec le système 100, en accédant par exemple à des moteurs de réservation de voyages qui s’appuient à leur tour sur les données du moteur d’agrégation de données 112. En ce qui concerne le moteur d’informatique en nuage 104, la montre l’inclusion d’un serveur de fichier 120, d’un stockage 124, d’un moteur de gestionnaire d’événements 128, d’un moteur de mise en file d’attente 132 et d’un moteur de surveillance 136. Le serveur de fichier 120 et le stockage 124 travaillent ensemble comme une unité pour fournir l’accès (comportant des fonctions de lecture, d’écriture et de suppression) aux fichiers de données aux moteurs de source de données 108 autorisées et au moteur d’agrégation de données 112. Le serveur de fichier 120 et le stockage 124 sont donc des composants informatiques qui contrôlent les fonctions de base de stockage et d’accès aux données du moteur d’informatique en nuage 104. Le moteur de gestionnaire d’événements 128 est un service de routage d’événements complet qui gère et surveille les événements ou les changements d’état reçus au niveau de la plateforme informatique en nuage 102, comportant des événements reçus des moteurs de source de données 108 et du moteur d’agrégation de données 112. Lorsque la plateforme informatique en nuage 102 est basée sur Azure, le moteur de gestionnaire d’événements 128 correspond à "Azure Event Grid" de Microsoft. Lorsque la plateforme informatique en nuage 102 est basée sur AWS, le moteur de gestionnaire d’événements 128 correspond au bus d’événements "EventBridge" d’AWS. Lorsque la plateforme informatique en nuage 102 est basée sur Google Cloud, le moteur de gestionnaire d’événements 128 correspond au bus "Eventarc" de Google Cloud. Le moteur de mise en file d’attente 132 est une file d’attente de messagerie qui travaille avec le moteur de gestionnaire d’événements 128 pour hiérarchiser et poursuivre le suivi des messages. Un moteur de mise en file d’attente 132 peut prendre la forme d’une communication asynchrone de service à service utilisée dans les architectures sans serveur et de micro-services. Un moteur de mise en file d’attente 132 peut découpler les applications et les services pour assurer l’équilibrage de charge. Lorsque la plateforme informatique en nuage 102 est basée sur Azure, le moteur de mise en file d’attente 132 correspond à "Azure Service Bus" de Microsoft. Lorsque la plateforme informatique en nuage 102 est basée sur AWS, le moteur de mise en file d’attente 132 correspond à Simple Queue Serve (SQS) d’AWS Amazon. Lorsque la plateforme informatique en nuage 102 est basée sur Google Cloud, le moteur de gestionnaire d’événements 128 correspond au service "Cloud Task" de Google Cloud. Les moteurs d’informatique en nuage 104 comportent également un moteur de surveillance 136 qui n’a pas d’analogue direct dans les plateformes informatiques en nuage 102 existantes. Comme nous l’expliquerons plus en détail ci-dessous, le moteur de surveillance 136 est configuré pour surveiller la taille et la fréquence de réception des fichiers provenant des moteurs de source de données 108 tels qu’ils sont stockés au sein de stockage 124, et pour réaliser des vérifications d’intégrité des données sur celui-ci, et pour générer des messages de rapport concernant toute anomalie. La montre un diagramme schématique d’un exemple non limitatif de composants internes d’un dispositif informatique 200. L’infrastructure du dispositif informatique 200, ou une variante de celle-ci, peut être utilisée pour mettre en œuvre l’un quelconque des nœuds informatiques, comportant le moteur de source de données 108, le moteur d’agrégation de données 112, le dispositif client 116, le serveur de fichier 120, le moteur de gestionnaire d’événements 128, le moteur de mise en file d’attente 132 ou le moteur de surveillance 136. Si cela est souhaité et/ou si le contexte le permet, un ou plusieurs de ces nœuds peuvent être mis en œuvre virtuellement au sein d’un seul dispositif informatique 200. Dans cet exemple, le dispositif informatique 200 comporte au moins un dispositif d’entrée 204 qui peut comporter un clavier. Les entrées provenant du dispositif 204 sont reçues au niveau d’un processeur 208 qui contrôle à son tour un dispositif de sortie 212 tel qu’un dispositif d’affichage ou d’autres dispositifs de sortie. Dans les variantes, des dispositifs d’entrée 204 ou des dispositifs de sortie 212 supplémentaires et/ou autres sont envisageables, ou peuvent être complètement omis si le contexte l’exige. Le processeur 208 peut être mis en œuvre sous la forme d’une pluralité de processeurs ou d’un ou plusieurs processeurs multicœurs. Le processeur 208 peut être configuré pour exécuter différentes instructions de programmation en réponse à l’entrée reçue via les un ou plusieurs dispositifs d’entrée 204, et pour contrôler un ou plusieurs dispositifs de sortie 212 pour générer une sortie sur ces dispositifs. Pour remplir ses fonctions de programmation, le processeur 208 est configuré pour communiquer avec une ou plusieurs unités de mémoire, comportant une mémoire non volatile 216 et une mémoire volatile 220. La mémoire non volatile 216 peut être basée sur n’importe quelle technologie de mémoire persistante, telle qu’une mémoire morte programmable effaçable électriquement ("EEPROM"), une mémoire flash, un disque dur à semi-conducteurs (SSD), un autre type de disque dur, ou des combinaisons de ceux-ci. La mémoire non volatile 216 peut également être décrite comme un support non transitoire lisible par ordinateur. En outre, plusieurs types de mémoire non volatile 216 peuvent être proposés. La mémoire volatile 220 est basée n’importe quelle technologie de mémoire vive (RAM). Par exemple, la mémoire volatile 220 peut être basée sur une mémoire dynamique synchrone à accès aléatoire (SDRAM) à double débit de données (DDR). D’autres types de mémoire volatile 220 sont envisageables. Le processeur 208 se connecte également à une interface réseau 232 qui comporte un tampon, un modulateur/démodulateur ou MODEM, par le biais des diverses liaisons et/ou de l’internet qui connecte l’équipement serveur à un autre équipement serveur. L’interface réseau 232 peut connecter le dispositif 200 à un autre dispositif informatique doté d’un dispositif d’entrée et de sortie, ce qui permet de se passer complètement du dispositif d’entrée 204 et/ou dispositif de sortie 212. Les instructions de programmation sous forme d’applications 224 sont généralement conservées en permanence dans une mémoire non volatile 216 et utilisées par le processeur 208 qui lit et écrit dans la mémoire volatile 220 pendant l’exécution des applications 224. Une ou plusieurs tables ou bases de données 228 peuvent également être conservées dans la mémoire non volatile 216 pour être utilisées par les applications 224. La montre un organigramme décrivant un procédé de surveillance de l’intégrité des données et de contrôle de rétroaction, indiqué généralement par 300. Le procédé 300 peut être mis en œuvre sur le système 100. Les personnes compétentes dans l’art peuvent choisir de mettre en œuvre le procédé 300 sur le système 100 ou des variantes de celui-ci, ou dans certains blocs omis réalisés en parallèle ou dans un ordre différent de celui montré. Le procédé 300 peut donc également être varié. Toutefois, à des fins d’explication, le procédé 300, comme pour l’organigramme de la , sera décrit en relation avec sa réalisation sur le système 100. Le bloc 304 comprend la réception d’un conteneur, et le bloc 308 comprend la sauvegarde du conteneur reçu dans le stockage. Dans le contexte du système 100 le conteneur contient des fichiers de données envoyés d’un moteur de source de données 108-1 au serveur de fichier 120 du moteur d’informatique en nuage 104-1, qui sauvegarde à son tour le conteneur dans le stockage 124. Le conteneur comporte un jeu de données, généralement sous forme de fichiers de données conformes à la norme de la structure de fichiers connue du serveur de fichier 120 et du stockage 124. On peut voir un exemple de réalisation du bloc 304 et du bloc 308 dans la , qui montre l’envoi d’un conteneur 404-1 du moteur de source de données 108-1 au serveur en nuage 104-1 pour la sauvegarde dans le stockage 124 à l’aide de commandes et de contrôles disponibles sur le serveur de fichier 120. La montre un exemple spécifique d’un conteneur 404-1, et d’autres exemples spécifiques utilisent cette nomenclature. Le conteneur 404-1 est un exemple spécifique destiné à faciliter l’explication du présent mode de réalisation, et d’autres conteneurs avec une nomenclature similaire sont fournis à des fins explicatives similaires. De manière générique, les conteneurs sont toutefois appelés conteneurs 404 ou conteneur 404 dans le présent document. Dans le contexte des acteurs du voyage, les conteneurs 404 peuvent inclure la disponibilité des ressources et des horaires correspondant à un acteur du voyage. Par exemple, lorsqu’un acteur du voyage est une compagnie aérienne, le conteneur 404 peut comporter un planning de vol pour la compagnie aérienne comportant la provenance, la destination, la disponibilité des sièges et le prix. Lorsqu’un acteur du voyage est un chemin de fer, le conteneur 404 peut comporter un planning de chemin de fer comportant la provenance, la destination, la disponibilité des sièges et le prix. Lorsqu’un acteur du voyage est un hôtel, le conteneur 404 peut inclure une liste de chambres et d’équipements, comportant les plages de dates de disponibilité et les prix. Le bloc 312 comprend la détection d’un événement dans le conteneur sauvegardé au bloc 308. Dans le contexte du système 100 et de l’exemple dans la , le bloc 312 est réalisé par le moteur de gestionnaire d’événements 128 qui examine le conteneur 404-1 et détermine que le conteneur 404-1 comporte un jeu de données qui est destiné au moteur d’agrégation 112. Le moteur de gestionnaire d’événements 128 détecte de nombreux types d’événements comme le verront les personnes qualifiées dans l’art, mais notamment pour la présente invention, le moteur de gestionnaire d’événements 128 peut détecter la création d’un fichier ou d’un dossier au sein d’un conteneur 404. Facultativement, l’événement détecté au bloc 312 est stocké dans le moteur de mise en file d’attente 132. L’utilisation du moteur de mise en file d’attente 132 est couramment utilisée en raison du grand volume de conteneurs que le système 100 traite régulièrement. Dans le contexte de la mise en œuvre du procédé 300 sur une plateforme informatique en nuage 102 existante telle que, mais sans s’y limiter, Azure, AWS et Google Cloud, une personne compétente dans l’art appréciera que l’infrastructure prenant en charge le bloc 304, le bloc 308 et le bloc 312 est nativement disponible dans ces plateformes existantes. Le bloc 316 comprend une détermination précisant s’il existe des métadonnées concernant la structure du conteneur. Le bloc 316 est généralement réalisé par le moteur de surveillance 136 qui répond au moteur de gestionnaire d’événements 128 et/ou au moteur de mise en file d’attente 132 ayant signalé l’arrivée de conteneur 404-1. Avant d’examiner plus avant le bloc 316, il est utile de préciser le concept d’une structure de conteneur. La structure de conteneur désigne tout ce qui identifie de manière unique le format global d’un conteneur 404 reçu, et dans le présent mode de réalisation, comporte une arborescence attendue de dossiers, de sous-dossiers, de partitions et/ou de fichiers. La montre un premier exemple de structure de conteneur 500 et un deuxième exemple de structure de conteneur 500a connue de l’architecture AzureTM. La structure de conteneur 500 correspond à un premier exemple conteneur 404 générique, tandis que la structure de conteneur 500a correspond à un deuxième exemple conteneur 404a générique. La structure de conteneur 500 et la structure de conteneur 500a comprennent chacune un "dossier normal" au plus haut niveau et un ou plusieurs "dossiers inférieurs" en cascade au-dessous du plus haut niveau. La structure de conteneur 500 comprend également une ou plusieurs "partitions" au niveau le plus bas contenu dans chaque couche de fond "dossier inférieur", qui comprend une pluralité de fichiers individuels. En revanche, la structure de conteneur 500a comprend également une ou plusieurs "partitions" au niveau le plus bas des sous-dossiers, puis, au niveau de la couche de fond, comporte un "fichier d’une partition" qui comprend une pluralité de fichiers individuels. Selon l’exemple spécifique de la , le conteneur 404-1 adhère donc à la structure de conteneur 500 du conteneur 404 générique. La montre un exemple de conteneur 404-1 de manière plus détaillée, et son adhésion à la structure 500, afin d’illustrer davantage le concept des structures de conteneurs. Le conteneur 404-1 contient un dossier de niveau racine 408, un dossier de sous-niveau 412 qui contient une seule partition 416 contenant un fichier individuel 420 – un exemple très simplifié à des fins purement illustratives. Ainsi, pour revenir à la description du bloc 316 dans la , le moteur de surveillance 136 détermine s’il existe des métadonnées de structure de conteneur. Cette détermination peut se faire selon que c’est la première fois ou non que la structure de conteneur spécifique du conteneur 404-1 a été détectée par le moteur de surveillance 136, ou qu’un nombre suffisant d’itérations du conteneur 404-1 a été reçu un nombre suffisant de fois pour s’assurer d’une fréquence d’arrivée attendue pour le conteneur 404-1. Dans l’exemple du conteneur 404-1, une détermination "non" est faite au bloc 316, d’autant plus qu’il s’agit de la première fois que le conteneur 404-1 a été reçu. Ceci amène le procédé 300 au bloc 320 dans lequel la structure de conteneur pour le conteneur 404-1 est déterminée. Les informations dans la sont donc extraites au bloc 320 par le moteur de surveillance 136 et stockées, et le procédé 300 passe au bloc 324. La montre un exemple non limitatif d’un procédé 700 qui peut être utilisé pour mettre en œuvre le bloc 320 du procédé 300. Le bloc 704 comprend la détermination d’une hiérarchie du conteneur. Dans l’exemple du conteneur 404-1, ceci est effectué par l’examen de la hiérarchie dans la et en créant un schéma qui représente la hiérarchie. Le bloc 708 comprend la détermination la catégorisation de chaque niveau dans la hiérarchie, qu’il s’agisse d’un dossier, d’un sous-dossier, d’une partition, d’un fichier, d’un groupe de fichiers ou d’une autre catégorisation de niveau. Le bloc 712 comprend la construction d’une structure arborescente représentant les déterminations du bloc 704 et du bloc 708. La structure arborescente reproduira ainsi la hiérarchie dans une structure arborescente organisationnelle avec une indication, pour chaque nœud de l’arborescence, des attributs de nœud comportant le type, la taille et l’heure d’arrivée. Le bloc 716 comprend la génération d’une liste du contenu de la partition la plus basse du conteneur, associée aux attributs de nœud du bloc 712. Selon la structure de conteneur 500, le contenu de la partition la plus basse sera basé sur la partition correspondant au ou aux fichiers dans le ou les dossiers le ou les plus bas (pour plus de clarté, l’exemple du conteneur 404-1 dans la est utile pour faciliter la compréhension. Dans le conteneur 404-1, la partition la plus basse est la partition 416, et le fichier correspondant à la partition 416 est le fichier 420). Selon la structure de conteneur 500a, le contenu de niveau le plus bas sera basé sur le groupe de fichiers d’une partition. Par commodité, ces niveaux les plus bas, qu’ils soient basés sur des fichiers individuels provenant de la structure de conteneur 500 (comme l’exemple du fichier 420), ou sur une pluralité de fichiers de la structure 500a, seront désignés ci-après de manière interchangeable simplement par "partitions les plus basses" ou "LP" qu’ils proviennent de la structure de conteneur 500 ou de la structure de conteneur 500a. Il convient toutefois de noter que d’autres façons d’effectuer le bloc 320 du procédé 300 sont envisageables. Pour revenir au procédé 300, au bloc 324, un service de surveillance est initialisé pour les métadonnées correspondant au conteneur 404-1. Dans le présent mode de réalisation, le bloc 324 est également réalisé par le moteur de surveillance 136. Dans le contexte d’un conteneur 404 ou d’un conteneur 404a, les métadonnées sont basées sur le contenu des partitions les plus basses ou LP du conteneur 404 tel qu’établi au bloc 716 ou une variante de celui-ci. Dans le présent mode de réalisation, les métadonnées comprennent une métrique de fréquence d’arrivée ("AFM" pour Arrival Frequency Metric) et une métrique de taille ("SM" pour Size Metric) pour le contenu du conteneur 404. La métrique de fréquence d’arrivée ou AFM peut être basée sur divers facteurs. Dans le présent mode de réalisation, la métrique de fréquence d’arrivée ou AFM est basée sur l’examen des partitions les plus basses et sur l’examen des différentes heures d’arrivée pour chaque élément dans la partition la plus basse. Les éléments font référence au ou aux fichiers, ou à leur contenu, dans la partition la plus basse. Il convient de noter que chaque élément dans la partition la plus basse peut avoir sa propre fréquence d’arrivée. Par exemple, dans le secteur du voyage, une compagnie aérienne peut mettre à jour son planning de vol pour un vol quotidien entre deux villes plus fréquemment que pour un vol hebdomadaire entre deux villes différentes. Donc, un conteneur 404 contenant un tel planning peut utiliser deux partitions les plus basses différentes, avec une partition pour chaque vol, et ces deux partitions les plus basses différentes peuvent être mises à jour à des fréquences différentes. Ainsi, chaque élément dans la partition la plus basse peut être mis à jour à des fréquences différentes. En conséquence, les métadonnées AFM peuvent être basées sur une première attribution d’une "arrivée de fréquence de partition" ou "PFA" (pour Partition Frequency Arrival) basée sur un intervalle d’heures d’arrivée entre chaque partition la plus basse, puis sur l’établissement d’une PFA moyenne ou d’une PFA de milieu ou d’une autre PFA métrique combinée pour tous les éléments afin d’arriver à une PFA globale ou GPFA pour le conteneur 404. Nonobstant ce mode de réalisation spécifique, il est entendu que d’autres métriques de fréquence d’arrivée ou AFM sont envisageables dans d’autres modes de réalisation. La métrique de taille ou SM pour le contenu du conteneur 404 peut également être basée sur divers facteurs. Dans le présent mode de réalisation, la métrique de taille ou SM est basée sur l’examen des partitions les plus basses et sur l’examen du nombre d’éléments au sein de chacune des partitions les plus basses (rappelons que les éléments font référence au ou aux fichiers, ou à leur contenu, dans la partition la plus basse). Il convient de noter que chaque élément dans la partition la plus basse peut avoir sa propre taille. Par exemple, dans le secteur du voyage, une compagnie aérienne peut regrouper les vols intérieurs dans une partition la plus basse et les vols internationaux dans une autre partition la plus basse, et donc le nombre de vols dans chaque partition la plus basse sera différent. Donc, un conteneur 404 contenant ces plannings pour deux partitions les plus basses différentes peut avoir des tailles différentes. En conséquence, les métadonnées de métrique de taille ou "SM" peuvent être basées sur la première attribution d’un "nombre de fichiers par partition" ou "NFP" pour chaque partition la plus basse, puis sur l’établissement d’une NFP moyenne ou d’une NFP de milieu, ou d’une autre métrique NFP combinée pour tous les éléments afin d’arriver à une NFP globale ou GNFP pour le conteneur 404. Nonobstant ce mode de réalisation spécifique, il est entendu que d’autres métriques de taille ou SM sont envisageables dans d’autres modes de réalisation. Le bloc 324 peut facultativement comporter la création de mesures de qualité associées à la métrique de fréquence d’arrivée et/ou à la métrique de taille. Les mesures de qualité peuvent refléter la fiabilité de la GPFA et/ou de la GNFP compte tenu de l’ensemble d’échantillons de partitions inférieures qui sont disponibles lors de l’application d’une moyenne, d’un milieu ou d’un autre outil statistique. L’inclusion de ces métriques de qualité peut être employée lorsque l’effort d’application de ces métriques de qualité fournit une amélioration globale de la surveillance de l’intégrité des données envisageables par la présente spécification. Ainsi, à l’issue du bloc 324, il existe désormais un ensemble de métadonnées pour la surveillance de l’intégrité des données d’un conteneur 404 donné. À ce stade, le procédé 300 passe au bloc 326 et il est déterminé si un nouveau conteneur a été reçu. Une détermination "oui" au bloc 326 ramène au bloc 324 où le bloc 304 et le bloc 308 sont réalisés à nouveau pour le conteneur dernièrement reçu. Une détermination "non" au bloc 326 conduit le procédé 300 directement au bloc 312 dans lequel un état d’attente se met en place jusqu’à ce qu’un nouvel événement soit détecté dans un conteneur précédemment sauvegardé. Il convient de noter que dans notre exemple de conteneur 404-1, si la partition la plus basse 416 dans le conteneur 404-1 est mise à jour, alors un nouvel événement dans le conteneur 404-1 sera détecté au bloc 312, et le procédé 300 passera à nouveau au bloc 316. Au cours de cette itération, au bloc 316, une détermination "oui" peut être faite parce que les métadonnées pour la structure de conteneur de conteneur 404-1 existent déjà (dans une variante actuellement moins appréciée, s’il n’existe pas suffisamment de métadonnées pour commencer la surveillance conteneur 404-1, alors le procédé 300 pourrait passer à nouveau par le bloc 320 et le bloc 324 pour le conteneur 404-1, et continuer à itérer jusqu’à ce qu’il y ait suffisamment de métadonnées, jusqu’à ce qu’une détermination "oui" puisse finalement être faite au bloc 316). La détermination "oui" au bloc 316 conduit au bloc 328. Le bloc 328 comprend une détermination précisant si l’événement détecté au bloc 312 correspond à la création d’une partition. La création peut également englober les mises à jour de la partition selon les souhaits d’une personne compétente dans l’art. Une détermination "non" peut se produire au bloc 328, étant donné que de nombreux événements différents peuvent avoir lieu au sein d’un conteneur 404 et que tous les événements ne sont pas pertinents pour la vérification de l’intégrité des données envisageable dans le présent mode de réalisation. Donc une détermination "non" conduit au bloc 332 et l’événement détecté au bloc 312 est ignoré, et le procédé 300 retourne au bloc 326 (dans une variante du procédé 300, le bloc 328 et le bloc 332 peuvent être omis lorsque le bloc 312 est modifié pour ne détecter que les événements correspondant à la création ou à la mise à jour d’une partition). Une détermination "oui" au bloc 328 conduit au bloc 336, et à ce stade, l’événement détecté au bloc 312 est traité en mettant à jour les métadonnées associées au conteneur dans lequel l’événement a été détecté. Là encore, les approches utilisées pour mettre à jour les métadonnées ne sont pas particulièrement limitées, car de nombreuses approches de ce type peuvent s’aligner sur l’objectif d’amélioration de la surveillance globale de l’intégrité des données dans le système 100. Dans le présent mode de réalisation, les mises à jour concernent la GPFA et la GNFP lorsque de nouveaux événements impliquant les partitions les plus basses sont détectés. De manière générale, la mise à jour de la GPFA est basée sur le suivi du temps entre l’heure actuelle où l’événement au bloc 312 s’est produit et l’heure précédente où l’événement au bloc 312 s’est produit. Exprimée différemment, la GPFA est généralement basée sur la différence de temps consécutive entre les déterminations "oui" au bloc 328. Dans un exemple spécifique non limitatif de la manière dont la détermination de la GPFA au bloc 336 peut être effectuée, la montre un graphique 800 se-lon un procédé effectuant des mises à jour de la fréquence d’arrivée de partition globale ou GPFA, selon la formule suivante : Où : n = itération en cours (correspond à l’événement présent) p = nombre de dossiers contenant des partitions GPFA = PFAn PFA = fréquence d’arrivée de partition LPT = Heure d’arrivée de la toute dernière partition dans le conteneur pendant l’événement présent Delta T = LPTn – LPTn-1 Ainsi, selon le graphique 800, les mises à jour de la GPFA sont basées sur un différentiel de temps entre l’événement présent et l’événement précédent selon les formules ci-dessus. Il convient toutefois de souligner que d’autres approches de la détermination d’une GPFA sont envisageables et vont apparaître aux personnes compétentes dans l’art. De manière générale, la mise à jour de la GNFP est basée sur le suivi des changements de la taille des données dans le conteneur 404 associées à l’événement au bloc 312 entre l’itération actuelle du bloc 312 l’itération précédente du bloc 312. Exprimée différemment, la GPFA est généralement basée sur la différence de la taille des données dans le conteneur 404 pertinent consécutive entre les déterminations "oui" au bloc 328. Dans un exemple spécifique non limitatif de la manière dont la détermination de la GNFP au bloc 336 peut être effectuée, le nombre de fichiers dans la partition la plus basse est compté afin d’arriver à une GNFP à l’itération actuelle, qui est ensuite comparée à une GNFP de référence. Notez qu’une GNFP de référence est réalisée lorsqu’un nombre suffisant d’itérations a eu lieu de sorte que la GNFP ne change pas, ou lorsqu’un nombre maximal d’itérations prédéfinies a eu lieu. La GNFP de référence peut être établie soit par des itérations répétées du bloc 324, soit par le bloc 336. Toujours avec le procédé 300, une fois le bloc 336 terminé, le procédé 300 passe au bloc 340, et l’on détermine à ce stade si un critère de seuil de métadonnées a été respecté. En d’autres termes, le bloc 340 comprend la vérification de l’intégrité des données, ce qui permet, si les métadonnées ne respectent pas certains seuils, de considérer qu’une erreur (ou une défaillance) de l’intégrité des données a été détectée. Une détermination "oui" au bloc 340 est qualifiée d’erreur (ou de défaillance) de l’intégrité des données, tandis qu’une détermination "non" signale l’absence d’erreur (ou de défaillance) de l’intégrité des données. Une détermination "non" au bloc 340 ramène au bloc 326 pour que le procédé 300 renouvelle son cycle. Une détermination "oui" au bloc 340 conduit à un processus de réponse au bloc 344. Selon l’exemple spécifique des modes de réalisation examinés ci-dessus, une détermination "oui" au bloc 340 peut se produire lorsqu’une erreur (ou une défaillance) de l’intégrité des données de GPFA est constatée selon le critère dans la . Pour être plus précis, si DeltaT est inférieur à un premier seuil de la GPFA précédente (par exemple environ 85 %, bien qu’un nombre quelconque souhaité puisse être choisi), alors une détermination "oui" a lieu au bloc 340. Si DeltaT est supérieur à un deuxième seuil de la GPFA précédente (par exemple environ 115 %, bien qu’un nombre quelconque souhaité puisse être choisi), alors une détermination "oui" a lieu au bloc 340. En résumé, le temps entre les mises à jour des éléments dans le conteneur 404 était soit trop rapide, soit trop lent, de sorte que l’intégrité de la mise à jour du conteneur 404 soit considérée comme valeur suspecte pour le moteur d’agrégation de données 112. Une détermination "oui" au bloc 340 peut également avoir lieu lorsqu’une erreur (ou une défaillance) de l’intégrité des données de GNFP est constatée. Pour être plus précis, si la GFNP pour une itération actuelle s’écarte de la GPFA de référence, alors une détermination "oui" a lieu au bloc 340 (bien que des plages de seuils de tolérance pour la GPFA ne soient pas proposées pour le mode de réalisation actuellement préféré, il est envisageable que les personnes compétentes dans l’art puissent rencontrer certaines applications qui justifient une tolérance). En résumé, si la taille des éléments dans le conteneur 404 change, alors l’intégrité de la mise à jour du conteneur 404 est considérée comme valeur suspecte pour le moteur d’agrégation de données 112. La détermination "oui" au bloc 340 amène donc le procédé 300 au bloc 344. Une grande variété de processus de réponse au bloc 344 sont envisageables, et bien que quelques exemples actuellement préférés soient décrits, une personne compétente dans l’art sera amenée à la lumière de la présente spécification, à découvrir d’autres types de processus de réponse. Le processus de réponse le plus simple comporte un mécanisme d’alerte ou un message d’avertissement adressé au moteur de source de données 108 qui provient du conteneur 404 douteux, et/ou adressé au moteur d’agrégation de données 112 et/ou adressé aux dispositifs clients 116. Le processus de réponse au bloc 340 peut également inclure des contrôles plus complexes sur le système 100 ou d’autres nœuds informatiques qui se connectent au système 100. Dans le contexte du secteur du voyage, si le conteneur 404 douteux peut être considéré comme présentant des données de planning de compagnie aérienne défectueuses, les moteurs de réservation en ligne qui s’appuient sur ces données peuvent être contrôlés pour empêcher les réservations qui pourraient être basées sur des données défectueuses ou périmées d’une mise à jour précédente du conteneur 404. La prévention de ces réservations peut donc réduire le gaspillage des ressources informatiques et des ressources de bande passante dans le système 100 dû aux réservations erronées et au trafic ultérieur nécessaire pour revenir sur ces réservations erronées. Le processus de réponse au bloc 340 peut également dépendre de certains seuils pour des exceptions de l’intégrité des données. Par exemple, il est possible de créer une place de marché de données où des données de qualité inférieure peuvent avoir un prix inférieur, mais ces données peuvent toujours être acquises tant que les taux d’erreur qu’elles peuvent représenter restent conformes aux attentes d’un projet donné. Un autre processus de réponse pour le bloc 340 peut comporter une notification de retour au moteur de source de données afin de fournir une correction aussi rapidement que possible. Dans le même ordre d’idées, un autre processus de réponse pour le bloc 340 peut comporter une notification de retour au moteur de source de données afin non seulement de régler, mais également d’éviter de devoir retraiter de gros volumes de données historiques à l’avenir. Compte tenu de ce qui précède, il est évident que des variantes sont envisageables. Par exemple, certains aspects de ce qui précède ont été examinés en relation avec le secteur du voyage, mais on comprendra maintenant que les modes de réalisation décrits ci-dessus peuvent être adaptés à d’autres secteurs. Par exemple, le secteur des services financiers propose des négociations en ligne. L’intégrité des données provenant des divers fournisseurs de d’instruments financiers est également importante pour la confiance, la transparence et l’équité globales de la plateforme de négociation en ligne. Les conteneurs dans le contexte du secteur des services financiers peuvent comporter par exemple une liste d’instruments financiers disponibles à la vente ou toute autre donnée qui peut être utilisée pour faciliter une transaction financière. La présente invention ne dépend pas du secteur et peut également inclure le secteur médical, ce qui permet de mettre à jour des documents médicaux de manière centralisée en temps réel. D’autres secteurs d’activités vont maintenant apparaître aux personnes compétentes dans l’art. La présente invention peut être appliquée à plusieurs contextes, notamment lorsque des conteneurs tel que les conteneurs 404 et les mises à jour sont générés pour être agrégés à intervalles réguliers et qu’ils présentent des caractéristiques structurelles sensiblement similaires, telles qu’une quantité de données, qui peut être exprimée en termes de taille de fichier, de taille de données, et/ou d’autres caractéristiques. Diverses applications sectorielles vont maintenant apparaître aux personnes compétentes dans l’art, comportant le secteur du voyage. Dans le secteur du voyage, les intervalles réguliers pour les conteneurs correspondent aux mises à jour régulières et aux modifications des données associées aux ressources de voyage, telles que les sièges de compagnie aérienne qui peuvent devenir indisponibles parce qu’ils ont été vendus. D’autres mises à jour des ressources de voyage de compagnies aériennes comportent l’ajout de nouveaux vols, l’annulation de vols, ou le départ vols. Les caractéristiques de structure de fichiers sensiblement similaires correspondent au fait que les ensembles de ressources de voyage qui composent un conteneur donné sont généralement fixes. C’est plutôt la disponibilité, le planning et la tarification de ces ressources de voyage qui changent. Une personne compétente dans l’art notera également comment la dynamique s’étend à travers le système 100, car les conteneurs tels que le conteneur 404, et leurs conteneurs mis à jour, sont régulièrement générés par chaque moteur de source de données 108 pour être agrégés par le moteur 112. En conséquence, les écarts dans la fréquence d’intervalles et les caractéristiques de structure de fichiers de tous les conteneurs au fil du temps peuvent entraîner des erreurs (ou défaillances) de l’intégrité des données qui peuvent avoir un effet négatif sur le comportement global du système 100, étant donné que les données agrégées présentées aux dispositifs clients 116 peuvent perdre leur fiabilité. Le manque de fiabilité des données agrégées peut entraîner des défaillances potentielles telles que des instructions de réservation erronées. Par exemple, dans le contexte d’un vol de compagnie aérienne, une instruction de réservation erronée pourrait être envoyée par un dispositif client 116 à la suite d’une erreur (ou d’une défaillance) de l’intégrité des données d’un conteneur donné. Par exemple, supposons qu’une mise à jour du conteneur 404 ne soit pas envoyée par le moteur de source de données 108-1, ce qui entraîne une erreur (ou une défaillance) de l’intégrité des données. Supposons également que le conteneur mis à jour contienne des informations de disponibilité de sièges selon lesquelles certains sièges pour un vol donné ont maintenant été réservés par rapport au conteneur 404 original. Le résultat d’une telle erreur (ou défaillance) de l’intégrité des données nécessite alors, au minimum, un gaspillage supplémentaire du trafic de réseau sur le réseau 106 afin de revenir sur la réservation erronée. Ce problème de gaspillage du réseau et des ressources de traitement se répercute donc négativement sur l’ensemble du système 100 pour chaque manquement à l’intégrité des données dans les conteneurs tels que conteneur 404. La présente invention permet de réduire ces manquements et d’accroître ainsi l’efficacité de l’utilisation des ressources de réseau et de traitement. Un autre avantage est que l’intégrité des données est surveillée, par le biais de métadonnées, sans avoir à analyser les données elles-mêmes. Cela simplifie les processus et peut préserver les exigences en matière de confidentialité et de cryptage. Il convient de reconnaître que les caractéristiques et les aspects des divers exemples fournis ci-dessus peuvent être combinés dans d’autres exemples qui entrent également dans la portée de la présente divulgation. En outre, les figures ne sont pas à l’échelle et leur taille et leur forme peuvent être exagérées à des fins d’illustration. Système de surveillance de l’intégrité des données pour une plateforme informatique basée sur le nuage (102), le système comprenant : un serveur en nuage (104-1, 104-2, …, 104-n) connecté à un moteur de source de données (108-1, 108-2, …, 108-n) via un réseau (106) et doté : d’une unité de stockage (124) ; d’un serveur de fichier (120) pour recevoir des données du moteur de source de données et sauvegarder les données dans l’unité de stockage ; d’un gestionnaire d’événements (128) connecté au serveur de fichier pour détecter des événements représentant la sauvegarde des données ; d’un moteur de mise en file d’attente (132) connecté au gestionnaire d’événements pour stocker les métadonnées des événements ; d’un moteur de surveillance (136) connecté au serveur en nuage pour traiter des caractéristiques des métadonnées pour déterminer l’intégrité des données d’événement ; le moteur de surveillance étant configuré pour initier un processus de réponse si l’intégrité des caractéristiques de métadonnées répond à un critère prédéterminé. Système selon la revendication 1, dans lequel l’intégrité est basée sur une continuité temporelle attendue de la réception des événements, et/ou l’intégrité est basée sur une quantité de données attendue associée aux événements. Système selon la revendication 1 ou 2, dans lequel le serveur en nuage peut être connecté à au moins un moteur d’agrégation de données (112). Système selon l’une des revendications 1 à 3, dans lequel le processus de réponse contrôle la disponibilité des données de partition associées aux événements pour un moteur qui accède aux données de partition, et/ou le processus de réponse est ou comprend un message d’alarme envoyé à au moins un moteur d’agrégation de données connecté au réseau. Système selon l’une des revendications 1 à 4, dans lequel le moteur de surveillance (136) est intégré dans le serveur en nuage (104-1, 104-2, …, 104-n). Moteur de surveillance (136) comprenant : une interface pour la connexion, via un réseau (106), à : au moins un moteur de source de données (108-1, 108-2, …, 108-n) connecté au réseau et un serveur en nuage (104-1, 104-2, …, 104-n) connecté au moteur de source de données ; le serveur en nuage (104-1, 104-2, …, 104-n) ayant : une unité de stockage (124) ; un serveur de fichier (120) pour recevoir des données du moteur de source de données et sauvegarder les données dans l’unité de stockage ; un gestionnaire d’événements (128) connecté au serveur de fichier pour détecter des événements représentant la sauvegarde des données ; un moteur de mise en file d’attente (132) connecté au gestionnaire d’événements pour stocker les métadonnées des événements ; dans lequel le moteur de surveillance (136) est configuré pour traiter les caractéristiques des métadonnées pour déterminer l’intégrité des données d’événement ; le moteur de surveillance également configuré pour initier un processus de réponse si l’intégrité des caractéristiques de métadonnées répond à un critère prédéterminé. Moteur de surveillance selon la revendication 6, dans lequel l’intégrité est basée sur une continuité temporelle attendue de la réception des événements, et/ou l’intégrité est basée sur une quantité de données attendue associée aux événements. Moteur de surveillance selon la revendication 6 ou 7, dans lequel le processus de réponse contrôle la disponibilité des données de partition associées aux événements pour un moteur qui accède aux données de partition. Moteur de surveillance selon l’une des revendications 6 à 8, comprenant en outre une connexion à au moins un moteur d’agrégation de données (112) connecté au réseau. Moteur de surveillance selon la revendication 9, dans lequel le processus de réponse est ou comprend un message d’alarme envoyé au moteur d’agrégation de données. Moteur de surveillance selon l’une des revendications 6 à 10, dans lequel le moteur de surveillance est intégré dans le serveur en nuage. Procédé de surveillance de l’intégrité des données, utilisable par un moteur de surveillance, le moteur de surveillance étant connecté, via un réseau, à au moins un moteur de source de données connecté au réseau et à un serveur en nuage connecté au moteur de source de données ; le serveur en nuage ayant : une unité de stockage ; un serveur de fichier pour recevoir des données du moteur de source de données et sauvegarder les données dans l’unité de stockage ; un gestionnaire d’événements connecté au serveur de fichier pour détecter des événements représentant la sauvegarde des données ; un moteur de mise en file d’attente connecté au gestionnaire d’événements pour stocker les métadonnées des événements ; le procédé comprenant : le traitement des caractéristiques des métadonnées pour déterminer l’intégrité des données d’événement ; l’initiation d’un processus de réponse si l’intégrité des caractéristiques de métadonnées répond à un critère prédéterminé. Procédé selon la revendication 12, dans lequel l’intégrité est basée sur une continuité temporelle attendue de la réception des événements, et/ou l’intégrité est basée sur une quantité de données attendue associée aux événements. Procédé selon la revendication 12 ou 13, dans lequel le processus de réponse contrôle la disponibilité des données de partition associées aux événements pour un moteur qui accède aux données de partition, et/ou le processus de réponse est ou comprend un message d’alarme envoyé à au moins un moteur d’agrégation de données connecté au réseau.