Brevet FR3114889A1 — publié le 20220408

Procédé et dispositif électronique de génération d’une base structurée de données pertinentes pour la gestion d’une mission , programme d’ordinateur associé L’invention a pour objet un procédé de génération, à partir d’un ensemble (15) de base(s) de données (20), d’une base structurée de données (10) associée à une mission, le procédé comprenant les étapes suivantes : - acquisition (110) d’une liste d’action(s) requise(s) et d’un groupe de règle(s) d’extraction de données comportant une loi d’extraction chacune, - génération (120) d’une structure de la base structurée de données (10) comportant au moins une classe de requête(s) infructueuse(s), - envoi (140) de la loi d’extraction de règle(s) d’extraction, à l’ensemble (15) et réception de donnée(s) extraite(s) depuis l’ensemble (15), - rangement (160) de la ou chaque donnée extraite reçue dans une classe de la base structurée (10), et - pour chaque loi d’extraction envoyée, si aucune donnée extraite n’est reçue en réponse de la part de l’ensemble (15), association (170) de ladite loi à la classe de requête(s) infructueuse(s). Figure pour l'abrégé : Figure 2 Procédé et dispositif électronique de génération d’une base structurée de données pertinentes pour la gestion d’une mission, programme d’ordinateur associé La présente invention concerne un procédé de génération, à partir d’un ensemble de base(s) de données, d’une base structurée de données associée à une mission, le procédé étant mis en œuvre par un dispositif électronique de génération. L’invention concerne également un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un tel procédé de génération. L’invention concerne également un dispositif électronique de génération configuré pour générer, à partir d’un ensemble de base(s) de données, une base structurée de données associée à une mission. L’invention s’applique au domaine de l’aide à la décision d’un utilisateur confronté à une situation critique lors d’une mission. Une situation critique est entendue ici au sens d’un évènement au cours de la mission, pour lequel une action est requise afin de ne pas mettre en péril la mission. Dans le domaine aéronautique, une mission est par exemple le vol d’un aéronef pour le transport de passagers entre deux aéroports. Une situation critique serait alors à titre d’exemple : une panne d’un moteur de l’aéronef, un problème de santé d’un passager, ou de mauvaises conditions météorologiques sur le trajet de l’aéronef. La performance de prise de décision d’un utilisateur dépend de sa capacité à évaluer la situation critique. D’après le document « Toward a theory of situation awareness in dynamic systems » de M.R. Ensley au volume 37 du journal Human Factors The Journal of the Human Factors and Ergonomics Society de 1995, une telle évaluation comprend trois étapes : perception des éléments de la situation, compréhension desdits éléments, et détermination d’une décision la plus appropriée parmi un ensemble de décision(s) possible(s). L’étape de perception consiste à acquérir un ensemble d‘éléments décrivant la situation. Cependant, l’environnement risque alors d’être surchargé par des éléments sans intérêt pour l’activité de l’opérateur. La pertinence d’une donnée est entendue ici au sens d’une caractéristique que possède la donnée à être appropriée, ou encore adaptée, pour la compréhension de la situation. Dans le contexte du document précité, les éléments sont entendus au sens de données pertinentes. L’étape de perception est alors essentielle car une erreur lors de cette étape se répercute sur les étapes de compréhension et de détermination, et plus particulièrement sur une sous-étape de projection des états futurs lors de l’étape de détermination. En particulier, l’absence de prise en compte de certaines données pertinentes conduit à une mauvaise compréhension de ces données, provoquant des décisions potentiellement inappropriées. Ainsi, lors de la prise de décision face à une situation critique, l’utilisateur ou le système doit être en mesure d’analyser un ensemble de données dont seulement une partie est pertinente. Pour augmenter la probabilité que les données pertinentes soient accessibles, des bases de données ont été constituées regroupant des ensembles de données les plus exhaustifs possibles. A titre d’exemple, la base ICAO Meteorological Exchange Model regroupe des données météorologiques mondiales. Lorsque la situation rencontrée ne requiert pas une prise de décision rapide, ou que l’utilisateur n’est pas contraint par le stress, la fatigue ou la distraction, il est envisageable pour l’utilisateur de consulter l’ensemble des données. L’utilisateur sélectionne alors les données pertinentes et en déduit la meilleure décision relative à ladite situation. Néanmoins, face à une situation critique contrainte par le temps, ou que l’utilisateur est contraint par l’un des facteurs précités, il n’est plus envisageable pour l’utilisateur d’analyser l’ensemble des données sans ignorer ou oublier certaines données pourtant pertinentes. Pour cela, certains procédés proposent d’extraire automatiquement une partie des données de base(s) de données, dite(s) source(s), selon des règles d’extraction préétablies. Les données extraites sont alors indexées dans une nouvelle base de données, dite cible, plus petite que la ou les bases de données sources. L’apport d’une structure à la base de données cible, organisant les données extraites, permet de représenter les liens entre les données extraites et de simplifier la compréhension de ces données. De tels extractions et indexations sont proposés dans le document « A Method to Identify Relevant Information Sufficient to Answer Situation Dependent Queries » de S. Lu et M. M. Kokar décrivant un procédé de d’extraction automatique d’un ensemble de données d’une base de données source. Le procédé comprend également la création d’une base de données cible et le stockage des données extraites dans cette base. Le choix des données extraites de la base de données source est fonction de la situation rencontrée, et est par exemple déterminé par une analyse basée sur une théorie dite de situation. Le procédé d’extraction et de classification présenté permet de constituer une base de données cible comprenant une plus faible quantité de données que la base de données source. De plus, chaque donnée de la base de données source, considérée comme pertinente vis-à-vis de la théorie de la situation, est bien présente dans la base de données cible. Ainsi la base de données cible est plus facilement traitable, par un utilisateur, pour la compréhension de la situation et la prise de décision Néanmoins, le procédé d’extraction et de génération de Lu et Kokar ne permet pas de générer une base de données cible de manière optimale. Un but de l’invention est alors d’améliorer l’extraction de données et la génération de la base de données cible. A cet effet, l’invention a pour objet un procédé de génération à partir d’un ensemble de base(s) de données, d’une base structurée de données associée à une mission, le procédé étant mis en œuvre par un dispositif électronique de génération et comprenant les étapes suivantes : - acquisition d’une liste d’action(s) requise(s) au cours de la mission, et d’un groupe de règle(s) d’extraction de données de l’ensemble de base(s) de données, chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée et une loi d’extraction de donnée(s) à partir de la ou des bases de données, chaque règle étant associée à une ou plusieurs action(s) requise(s), - génération d’une structure de la base structurée de données comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s), - sélection de règle(s) d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur parmi la liste d’action(s) requise(s), - envoi de la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble de base(s) de données, et réception de donnée(s) extraite(s) de la part des bases de données suite à cet envoi, - rangement de la ou chaque donnée extraite reçue dans la classe de la base structurée correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et - pour chaque loi d’extraction envoyée, si aucune donnée extraite n’est reçue en réponse de la part de l’ensemble de base(s) de données, association de ladite loi à la classe de requête(s) infructueuse(s). Ainsi, le procédé selon l’invention permet de générer une base structurée de données comprenant les données extraites d’un ensemble de base(s) de données, également appelée(s) base(s) source(s). En outre, le choix d’une action requise par un utilisateur et la sélection de règle(s) d’extraction, basée sur ce choix, permet de réaliser un nombre réduit d’extraction(s) tout en permettant que chaque donnée extraite soit appropriée dans le contexte de l’action requise choisie. De plus, la présence dans chaque règle d’extraction d’un premier identifiant de classe permet d’organiser la base structurée de données indépendamment de la structure de la ou chaque base source. De plus, l’étape d’association de la loi d’extraction à la classe de requête(s) infructueuse(s) permet d’identifier l’absence, dans l’ensemble de base(s) source(s), de données répondant à une loi d’extraction envoyée, ce qui permet alors à l’utilisateur de la base structurée de différencier les données absentes de l’ensemble de base(s) source(s) mais considérées comme pertinentes et cherchées par une loi d’extraction, des données absentes de la base structurée car considérées comme non-pertinentes et pour lesquelles aucune loi d’extraction n’a essayé de les extraire. Suivant d’autres aspect avantageux de l’invention, le procédé selon l’invention comprend une ou plusieurs des caractéristiques suivantes prises isolément ou suivant toutes les combinaisons techniquement possibles : - suite à l’envoi d’une loi d’extraction, aucune donnée extraite n’est reçue de l’ensemble des base(s) de données si le ou les messages reçus de l’ensemble de base(s) de données vérifient seulement au moins l’un des cas suivants : - un message d’erreur est reçu de l’ensemble de base(s) de données, - un message comportant un champ de données vide est reçu de la part de l’ensemble de base(s) de données. - l’ensemble de base(s) de données comprend au moins deux bases de données, et lors de l’étape d’envoi, la loi d’extraction incluse dans chaque règle d’extraction sélectionnée est envoyée à chaque base de données, - si les bases de données fournissent au moins deux données extraites différentes en réponse à une même loi d’extraction envoyée, les au moins deux données extraites sont, lors de l’étape de rangement, rangées dans la même classe de la base structurée, correspondant au premier identifiant de classe associé à ladite loi d’extraction, - suite à l'envoi d’une loi d’extraction, chaque donnée reçue comprend : - un jeu de donnée(s) extraite(s) d’une base de données (20), en réponse à la loi d’extraction envoyée, - un ensemble de deuxième(s) identifiant(s) de classe de la base de données depuis laquelle jeu de donnée(s) extraite(s) est issu, chaque deuxième identifiant correspondant à une classe respective de ladite base de données depuis laquelle au moins une donnée extraite respective est issue, et - un groupe de critère(s) d’extraction de données depuis la base de données dont le jeu de donnée(s) extraite(s) est issu, l’ensemble de deuxième(s) identifiant(s) et le groupe de critère(s) étant propre à chaque base de données et étant générés à partir de la loi d’extraction envoyée, lors de l’étape de rangement, l’ensemble de deuxième(s) identifiant(s), le groupe de critère(s) et le jeu de donnée(s) sont rangés dans la classe correspondant au premier identifiant de classe associé à ladite loi d’extraction, lors de l’étape de rangement, au moins une première relation entre une donnée extraite et un deuxième identifiant de classe est en outre rangé dans ladite classe de la base structurée, - la mission est le vol d’un aéronef, l’ensemble d’action(s) requise(s) comprenant de préférence : un démarrage de l’aéronef, un déroutement de l’aéronef et un contournement par l’aéronef d’une zone géographique, - les règles d’extraction associées à l’action requise de déroutement comprennent les lois d’extraction : - trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie, - trouver un aéroport dont les conditions météorologiques correspondent à des conditions prédéfinies, - trouver un aéroport possédant des services d’urgence, et - trouver un aéroport distant de l’aéronef d’au plus une distance maximale prédéfinie , et dans lequel les règles d’extraction associées à l’action requise de contournement comprennent les lois d’extraction : - trouver des coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) les conditions météorologiques correspondent à des conditions prédéfinies, et distant de l’aéronef d’au plus une deuxième distance maximale prédéfinie . - lors de l’étape d’acquisition, des données invariantes au cours de la mission sont en outre acquises, et lors de l’étape d’envoi, au moins une loi d’extraction envoyée est complétée par au moins une donnée invariante au cours de la mission, si la mission est les vol d’un aéronef, les données invariantes au cours de la mission comprenant de préférence un type ou une référence de modèle de l’aéronef, un numéro de vol d’un aéronef, un aéroport de départ de l’aéronef, une quantité initiale de carburant dans l’aéronef, - le procédé comprend en outre, après l’étape de rangement ou d’association : - une étape de récupération d’une demande de la part d’un utilisateur, et - si la demande concerne une loi d’extraction associée à la classe de requête(s) infructueuse(s), une étape de communication d’un message indiquant que la donnée répondant à la demande est absente de l’ensemble de base(s) de données à l’utilisateur. En complément facultatif, chaque loi d’extraction comporte un ensemble de mot(s)-clé(s) apte(s) à être traduit(s) en deuxième(s) identifiant(s) de classe de chaque base de données lors de l’envoi de ladite loi, si au moins deux deuxièmes identifiants, associés à un même mot-clé d’une loi d’extraction, sont reçus alors lors de l’étape de rangement, une deuxième relation est rangée dans la base structurée de données. En complément facultatif encore, lors de l’étape d’association, chaque loi d’extraction envoyée pour laquelle aucune donnée extraite n’est reçue, est qualifiée d’infructueuse, et chaque loi infructueuse est associée à la classe de requête(s) infructueuse(s) selon l’une des deux conditions suivantes : si à chaque mot-clé de la loi infructueuse, est associé un deuxième identifiant, alors rangement dans la classe de requête(s) infructueuse(s) de : chaque deuxième identifiant absent de la base structurée de données, chaque critère d’extraction absent de la base structurée de données, et au moins une troisième relation liant un deuxième identifiant respectif à un critère d’extraction respectif, ou deux desdits deuxièmes identifiants si la loi comprend au moins deux mots-clés, si au moins un mot-clé de la loi infructueuse n’est pas associé à un deuxième identifiant, alors rangement dans la classe de requête(s) infructueuse(s) de : chaque deuxième identifiant absent de la base structurée de données, chaque mot-clé non-associé à un deuxième identifiant, chaque critère d’extraction absent de la base structurée de données, dans chaque critère d’extraction relatif à un mot-clé sans deuxième identifiant, le deuxième identifiant étant remplacé par le mot-clé, et au moins une quatrième relation liant un mot-clé à un critère d’extraction respectif ou à un deuxième identifiant respectif si la loi comprend deux mots-clés. L’invention a également pour objet un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon l’une quelconque des revendications précédentes. L’invention a également pour objet un dispositif électronique de génération configuré pour générer, à partir d’un ensemble de base(s) de données, une base structurée de données associée à une mission, le dispositif étant apte à être relié à un ensemble de base(s) de données, le dispositif électronique de génération comprenant : - un module d’acquisition configuré pour acquérir une liste d’action(s) requise(s) au cours de la mission, et un groupe de règle(s) d’extraction de données de l’ensemble de base(s) de données, chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée et une loi d’extraction de donnée(s) à partir de la ou des bases de données, chaque règle étant associée à une ou plusieurs action(s) requise(s), - un module de génération configuré pour générer une structure de la base structurée de données comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s), - un module de sélection configuré pour sélectionner une ou plusieurs règles d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur parmi la liste d’action(s) requise(s), - un module d’envoi configuré pour envoyer la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble de base(s) de données, et un module de réception de donnée(s) de la part des bases de données suite à cet envoi, - un module de rangement configuré pour ranger la ou chaque donnée reçue dans la classe de la base structurée (correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et - un module d’association configuré pour associer chaque loi d’extraction envoyée, pour laquelle aucune donnée extraite n’est reçue en réponse de la part de l’ensemble de base(s) de données, à la classe de requête(s) infructueuse(s). Ces caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : la est une représentation schématique d’un système de génération d’une base structurée de données selon l’invention, le système comprenant un ensemble de base(s) de données et un dispositif électronique de génération, à partir de l’ensemble de base(s) de données, d’une base structurée de données ; la est un organigramme d’un procédé, selon l’invention, de génération d’une base structurée de données selon l’invention, le procédé étant mis en œuvre par le dispositif électronique de génération de la ; et la est une représentation schématique d’une base structurée de données, générée selon le procédé de génération représenté sur la . Sur la , un système 5 de génération d’une base structurée 10 de données comprend un ensemble 15 de base(s) de données 20 et un dispositif électronique 25 de génération de la base structurée 10. Le dispositif de génération 25 est connecté à l’ensemble 15. Le système de génération 5 est typiquement configuré pour générer une base structurée 10 respective par mission. La mission est par exemple le vol d’un aéronef pour le transport de passager(s). La base structurée de données 10 est par exemple une base de connaissances. La dénomination “base de connaissances” est entendue ici au sens d’une base structurée de données, comportant en outre des éléments de liaison, nommés ci-après relations, permettant d’établir de liens sémantiques entre les données de la base, tel que défini dans le chapitre “ Knowledge Bases vs Databases ” du livre ‘ On Knowledge Base Management Systems ’, publié en 1986, et écrit par Michael L. Brodie et John Mylopoulos. L’ensemble 15 comprend au moins une base de données 20, chaque base de données 20 étant également appelée base source 20 par la suite, et au moins un traducteur 30 propre à chaque base source 20. L’ensemble 15 est susceptible d’évoluer dynamiquement au cours du procédé. Ainsi, la présence de chaque base source 20 n’est pas préalablement déterminée. La présence en continu d’au moins une base source 20 et du traducteur 30 associé, est l’unique contrainte, ou exigence, associée à l’ensemble 15. Le dispositif de génération 25 est configuré pour générer la base structurée 10 à partir dudit ensemble 15. Le dispositif de génération 25 comprend un module d’acquisition 35 configuré pour acquérir au moins une liste d’action(s) requise(s) au cours de la mission et un groupe de règle(s) d’extraction, chacune comportant une loi d’extraction. Le dispositif de génération 25 comprend un module de génération 40 configuré pour générer une structure de la base structurée 10. Le dispositif de génération 25 comprend également un module de sélection 45 configuré pour sélectionner une ou plusieurs règle(s) d’extraction parmi le groupe de règle(s) d’extraction à partir d’une action requise choisie par un utilisateur 47, un module d’envoi 50 configuré pour envoyer, à l’ensemble 15, la loi d’extraction incluse dans chaque règle d’extraction sélectionnée. Le dispositif de génération 25 comprend également un module de rangement 55 configuré pour ranger une ou des données reçues en réponse à la ou aux lois d’extraction envoyées, dans la classe de la base structurée 10 correspondant à un premier identifiant de classe de la règle d’extraction, la règle d’extraction comprenant la loi d’extraction ayant produit la ou les données. Le rangement de chaque donnée dans la classe respective est compris ici comme synonyme d’une indexation, ou encore d’un classement, de ladite donnée dans ladite classe. Le dispositif de génération 25 comprend un module d’association 60 configuré pour associer chaque loi d’extraction envoyée, à une classe de requête(s) infructueuse(s) en l’absence de réponse à ladite loi, de la part de l’ensemble 15. En complément facultatif, le dispositif de génération 25 comprend un module récupération 65 configuré pour récupérer une demande de donnée(s) de la part de l’utilisateur 47, un module de détermination 70 configuré pour déterminer si chaque donnée demandée est présente ou non dans la base structurée 10, et un module de communication 75 configuré pour communiquer un message à partir ce qui est déterminé par le module de détermination 70. Dans l’exemple de la , le dispositif de génération 25 comprend une unité de traitement d’informations 80 formée par exemple d’une mémoire 85 et d’un processeur 90 associé à la mémoire 85. Dans cet exemple de la , le module d’acquisition 35, le module de génération 40, le module de sélection 45, le module d’envoi 50, le module de rangement 55, le module d’association 60, ainsi qu’en complément facultatif le module de récupération 65, le module de détermination 70 et le module de communication 75, sont réalisés chacun sous forme d’un logiciel, ou d’une brique logicielle, et exécutables par le processeur 90. La mémoire 85 du dispositif de génération 25 est alors apte à stocker un logiciel d’acquisition de la liste d’action(s) requise(s) et du groupe de règle(s) d’extraction, un logiciel de génération d’une structure de la base structurée 10, un logiciel de sélection de règle(s) d’extraction à partir de l’action requise choisie par l’utilisateur 47, un logiciel d’envoi de la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, un logiciel de rangement dans la base structurée 10 de la ou chaque donnée extraite reçue, dans la classe correspondant au premier identifiant associé à la loi d’extraction en réponse à laquelle chaque donnée a été reçue, et un logiciel d’association, en l’absence de donnée(s) extraite(s) reçue(s) en réponse à une loi respective d’extraction envoyée, de ladite loi d’extraction à la classe de requête(s) infructueuse(s) de la base structurée 10. En complément facultatif, la mémoire 85 du dispositif de génération 25 comprend un logiciel de récupération de la demande de donnée(s) de la part de l’utilisateur 47, un logiciel de détermination de la présence ou non dans la base structurée 10 de chaque donnée demandée, et un logiciel de communication du message à partir de ce qui est déterminé par le logiciel de détermination. Sur la , les briques logicielles sont reliées par des flèches représentant chacune typiquement un appel de fonction. En variante non représentée, le module d’acquisition 35, le module de génération 40, le module de sélection 45, le module d’envoi 50, le module de rangement 55, le module d’association 60, ainsi qu’en complément facultatif le module de récupération 65, le module de détermination 70 et le module de communication 75, sont réalisés chacun sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglais Field Programmable Gate Array ), ou encore d’un circuit intégré, tel qu’un ASIC (de l’anglais Application Specific Integrated Circuit ). Lorsque le dispositif de génération 25 est réalisé sous forme d’un ou plusieurs logiciel(s), c’est-à-dire sous forme d’un programme d’ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est par exemple, un médium apte à mémoriser les instructions électroniques et à être couplé à un bus d’un système informatique. A titre d’exemple, le support lisible est un disque optique, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non volatile (par exemple EPROM, EEPROM, FLASH, NVRAM), une carte magnétique ou une carte optique. Sur le support lisible est alors mémorisé un programme d’ordinateur comprenant des instructions logicielles. Chaque règle d’extraction comprend une loi d’extraction et un premier identifiant de classe respectifs. Chaque loi d’extraction comprend l’ensemble de mot(s)-clé(s), et au moins une spécificité précisant respectivement une caractéristique de chaque mot-clé ou une dépendance de plusieurs mots-clés le cas échéant. Chaque loi d’extraction est par exemple un élément textuel formant une phrase en langage naturel, chaque spécificité étant, le cas échéant, une expression textuelle liant sémantiquement les mots-clés. En variante, chaque loi d’extraction est sous forme d’un graphe dans lequel chaque mot-clé représente un nœud, et, chaque spécificité de dépendance étant représenté par un arc reliant deux nœuds dans le cas où le graphe comprend plusieurs nœuds. Dans le cas où la loi d’extraction est un élément textuel formant une phrase en langage naturel, des techniques NLU (de l’anglais Natural Language Understanding ) permettent d’identifier les mots clés. Ces techniques NLU sont des techniques d’intelligence artificielle, basées sur un modèle informatique de prédiction de mots-clés. Ces modèles sont entraînés à partir d’un ensemble de corpus de textes en entrée, pour lesquels un mot-clé attendu en sortie est fourni. Chaque base source 20 comprend un ensemble de données, chacune apte à être extraite de la base source 20, suite à une requête dans un langage informatique interprétable par la base source 20. Chaque base source 20 ayant sa propre structure et son propre langage, le traducteur 30 propre à chaque base source 20 est configuré pour traduire une loi respective d’extraction exprimée dans un langage dit naturel, en une requête respective exprimée dans le langage de la base source 20 ou dans un langage interprétable par la base source 20. Un langage naturel est compris ici au sens d’un langage écrit ou parlé, qui n’est pas un langage informatique. Ainsi, les langues française, anglaise et allemande sont des exemples non exhaustifs de langages naturels. Le langage informatique, dans lequel les lois d’extractions sont traduites en requêtes respectives est par exemple le langage dit SPARQL (de l’anglais « SPARQL Protocol And RDF Query Language »). Chaque traducteur 30 est configuré pour générer, à partir de la loi d’extraction reçue, la requête comportant au moins un deuxième identifiant de classe et au moins un critère d’extraction. Chaque deuxième identifiant de classe, aussi nommé argument, correspond à une classe respective de la base source 20, et permet alors d’identifier une telle classe. Dans chaque requête informatique en langage SPARQL, les deuxièmes identifiants de classe sont par exemple repérés par une première dénomination « SELECT » précédant le deuxième identifiant. Chaque critère d’extraction, aussi nommé condition, correspond à une caractéristique discriminante portant sur les données de la classe identifiée par un deuxième identifiant respectif. Ainsi, seulement les données vérifiant chaque critère d’extraction sont extraites. Dans chaque requête SPARQL, chaque critère d’extraction est repéré par une deuxième dénomination « WHERE » précédant ledit critère. Autrement dit, chaque requête SPARQL est apte à extraire, de la base source 20, les données correspondant à chaque deuxième identifiant de classe repéré par la première dénomination « SELECT » et vérifiant chaque critère d’extraction, chaque critère d’extraction portant sur au moins un deuxième identifiant de classe. Une spécificité du langage SPARQL est qu’il n’est pas nécessaire d’introduire préalablement à la deuxième dénomination « WHERE », chaque deuxième identifiant de classe sur lequel s’applique un critère d’extraction respectif. A titre d’exemple le traducteur 30 est du type SPARQL, propre à une base source 20 respective comportant les classes « aérodrome » et « piste d’atterrissage », et est configuré pour traduire la loi d’extraction « Trouver un aéroport dont la longueur de la piste est supérieure à 1,2 km » en une requête SPARQL respective comportant le deuxième identifiant de classe « aérodrome » sous la forme « SELECT aérodrome », et comportant le critère d’extraction sous la forme « WHERE {piste d’atterrissage 1,2 km} ». Seulement la ou les données, correspondant à la classe identifiée par le deuxième identifiant « aérodrome » et pour lesquelles la classe, identifiée par le deuxième identifiant « piste d’atterrissage », comporte des pistes supérieures à 1,2 km, sont extraites par la requête SPARQL. Le traducteur 30 est connu en soi, le projet SWIP proposant notamment un tel traducteur 30. Le traducteur 30 du projet SWIP est apte à traduire une loi respective d’extraction exprimée en langage naturel, en une requête respective SPARQL, à travers un processus de Traitements Automatique du Langage naturel dit « TAL ». En outre, d’autres langages informatiques que le langage SPARQL, tels que le « SPARQL-DL », le « Snap SPARQL », le « OWL-QL », le « SQWRL », ou encore le « DL-Query », sont également adaptés pour l’extraction de données. Selon l’exemple précité dans lequel la mission est le vol d’un aéronef, l’ensemble 15 comprend par exemple au moins l’une des bases sources 20 suivantes : - « ATM Information Reference Model Ontology » (dite AIRM-O) pour le trafic aérien, - « Aeronautical Information eXchange Model » (dite AIXM) pour la gestion et la distribution de données de services d'informations aéronautiques, ou - « ICAO Meteorologial Information Exchange Model » (dite IWXXM) pour les données météorologiques. Le module d’acquisition 35 est configuré pour acquérir la liste d’action(s) requise(s) au cours de la mission. Chaque action requise désigne une intention de l’utilisateur 47 au cours de la mission. Cette intention est dite de haut niveau, en opposition à une décision prise par l’utilisateur 47 après consultation des données pertinentes. Ainsi, les données pertinentes pour prendre la décision dépendent, au moins en partie, de l’action requise choisie, c’est-à-dire de l’intention choisie. Dans l’exemple précité où la mission est le vol de l’aéronef, la liste d’action(s) requise(s) comprend par exemple : un démarrage de l’aéronef, un déroutement de l’aéronef et un contournement par l’aéronef d’une zone géographique. Le module d’acquisition 35 est également configuré pour acquérir le groupe de règle(s) d’extraction. Chaque règle d’extraction est associée à l’action requise de la liste d’action(s) requise(s). Ainsi chaque action requise permet de réaliser un filtrage sur les données qui seront extraites par la loi d’extraction incluse dans chaque règle d’extraction associée à ladite action. Dans l’exemple précité où la mission est le vol d’un aéronef, et avec l’exemple précité de liste d’action(s) requise(s), le groupe de règle(s) d’extraction comporte typiquement les règles d’extraction associées à l’action de déroutement de l’aéronef, dont la loi d’extraction de chacune est par exemple la suivante : trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie, trouver un aéroport possédant des services d’urgence, et trouver un aéroport distant de l’aéronef d’au plus une première distance maximale prédéfinie . Dans le cas de la première loi d’extraction citée ci-dessus, les mots-clés sont par exemple, « aéroport » et « piste ». Dans cet exemple, la liste de règle(s) d’extraction comporte typiquement les règles d’extraction, associées à l’action de contournement par l’aéronef d’une zone géographique, dont la loi d’extraction de chacune est par exemple la suivante : trouver les coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) les conditions météorologiques correspondent à des conditions prédéfinies, et distant de l’aéronef d’au plus une deuxième distance maximale prédéfinie , et trouver les coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) une couverture internet d’une technologie satellite. En variante, la mission est le suivi de patients dans un hôpital. Une action requise respective est alors par exemple de détecter des patients à risque de COVID-19 dans un service d’urgence. Les règles d’extraction sont alors, par exemple, les suivantes : sélectionner tous les patients du service d’urgence n’ayant pas été diagnostiqués porteurs du COVID-19 et âgés de plus de 60 ans, sélectionner les patients du service d’urgence n’ayant pas été diagnostiqués porteurs du COVID-19 et ayant des risques cardio-vasculaires, sélectionner les patients du service d’urgence n’ayant pas été diagnostiqués porteurs du COVID-19 et ayant partagé une chambre avec un patient porteur du COVID-19, sélectionner des patients de l’hôpital dont l’âge est dans un tranche d’âges prédéfinie, telle qu’entre 30 et 50 ans. En variante encore, la mission est le contrôle d’un incendie. L’action requise est alors de déterminer des moyens adaptés pour la gestion de cet incendie. Les règles d’extraction sont alors par exemple : déterminer les véhicules de secours possédant les services d’extinction d’incendie, déterminer les véhicules de secours équipés a minima d’un conducteur, d’un chef agréé et de quatre équipiers, et déterminer les véhicules de secours présents dans la zone de l’accident. En variante encore, la mission est la gestion des accidents par un service de SAMU. Une action requise respective est alors la recherche d’hôpitaux pour prendre en charge une victime, suite à un accident. Une règle d’extraction est alors de déterminer les hôpitaux possédant un service adapté à une pathologie d’une victime à prendre en charge. Le premier identifiant de classe inclus dans chaque règle d’extraction correspond à la classe de la base structurée 10 dans laquelle doit être rangée chaque donnée extraite à l’issue de l’envoi de la loi d’extraction respective. Des explications plus détaillées concernant les classes de la base structurée 10 sont fournies ci-après. Le module d’acquisition 35 est aussi optionnellement configuré pour acquérir un ensemble de donnée(s) invariante(s) au cours de la mission. L’ensemble de donnée(s) invariante(s) comprend, le cas échéant, des données n’évoluant pas au cours de la mission et connues préalablement à la mission, ainsi que le premier identifiant de classe associé à chacune desdites données pour le rangement de ladite donnée dans la base structurée 10. L’ensemble de donnée(s) invariante(s) comprend également des données absentes de l’ensemble 15 permettant de compléter les lois d’extractions. Dans l’exemple précité où la mission est le vol d’un aéronef, les données invariantes comprennent par exemple : un type ou une référence de l’aéronef, une quantité initiale de carburant dans l’aéronef, un numéro de vol de la mission et un aéroport de départ de l’aéronef. Le module de génération 40 est connecté en sortie du module d’acquisition 35, et est configuré pour générer la structure de la base structurée 10. La structure de la base structurée 10 comporte des classes, et notamment une classe respective pour chaque premier identifiant de classe du groupe de règle(s) d’extraction. De manière optionnelle, chaque premier identifiant de classe est choisi parmi les six noms de classe suivants : « sujet », « outil(s) », « communauté », « règle(s)», « division du travail », « visée ». Cette décomposition en six classes est connue en soi, et provient de la théorie de l’activité proposée par Y. Engeström en 1987 dans le document « Learning by expanding: An activity-theoretical approach to developmental research, Helsinki: Orienta-Konsultit ». Cette décomposition est une structure générique permettant de décrire de manière exhaustive un ensemble d’éléments nécessaires d’une activité tout en assurant une distinction objective entre les classes. Si les classes sont les six classes liées à la théorie de l’activité, l’homme du métier observera que la classe « règle(s) » fait référence aux règles métier à appliquer pour la réalisation d’un objectif. Ces règles métier correspondent aux règles d’extraction. Le module de génération 40 est également configuré pour générer la classe de requête(s) infructueuse(s) dans la base structurée 10. Le module de sélection 45 est connecté en sortie du module d’acquisition 35, et est configuré pour sélectionner au moins une règle d’extraction respective d’extraction parmi celle(s) du groupe de règle(s) d’extraction. En fonction de l’action requise choisie par l’utilisateur 47 parmi la liste d’action(s) requise(s), le module de sélection 45 est configuré pour sélectionner, dans le groupe de règle(s) d’extraction, chaque règle associée à ladite action choisie. Si l’action requise choisie est le déroutement de l’aéronef, le module de sélection 45 est configuré pour choisir les règles d’extraction associées à l’action de déroutement de l’aéronef, telles que celles décrites précédemment. Corollairement, si l’action requise choisie est le contournement de l’aéronef, le module de sélection 45 est configuré pour choisir les règles d’extraction qui sont associées à cette action requise. Le module d’envoi 50 est connecté en sortie du module de sélection, et est configuré pour envoyer, à l’ensemble 15, la loi d’extraction de chaque règle d’extraction sélectionnée. Dans le cas où l’ensemble 15 comprend plusieurs bases sources 20, le module d’envoi 50 est configuré pour envoyer la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à chaque base source 20, via le traducteur 30 propre à ladite base source 20. Le module d’envoi 50 est optionnellement configuré pour compléter avant l’envoi, et le cas échéant, une loi respective d’extraction à partir des données déjà rangées dans la base structurée 10. Par exemple, pour la loi d’extraction exprimée sous la forme de l’expression textuelle « trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie », la longueur prédéfinie est de préférence complétée automatiquement en fonction de la donnée invariante correspondant au type ou à la référence de modèle de l’aéronef. Le module de rangement 55 est connecté en sortie du module de sélection 45, et est configuré pour recevoir et ranger, dans la base structurée 10, un ou des éléments du ou des messages reçus en réponse à la ou aux lois d’extraction envoyées à l’ensemble 15. Chaque message reçu comprend par exemple les éléments suivants : un jeu de donnée(s) extraite(s), un ensemble de deuxième(s) identifiant(s) de classe, et un groupe de critère(s) d’extraction. Chaque message reçu comprend plus précisément un champ de données comportant deux tableaux. Un premier tableau comprend le jeu de données extraites. Un deuxième tableau comprend la requête en langage SPARQL ayant permis d’extraire le jeu de données extraites. L’ensemble de deuxième(s) identifiant(s) de classe et le groupe de critère(s) d’extraction sont alors inclus dans le deuxième tableau. Le module de rangement 55 est configuré pour ranger chaque jeu de données extraites, chaque ensemble de deuxième(s) identifiant(s) et chaque groupe de critère(s) d’extraction dans la classe correspondant au premier identifiant associé à la loi d’extraction à l’origine des données reçues. Chaque donnée extraite correspond à une donnée respective d’une base source 20 en réponse à la loi d’extraction envoyée. En complément facultatif, le module de rangement 55 est configuré pour ranger, dans la base structurée 10, au moins une première relation entre une donnée extraite respective et un deuxième identifiant respectif, ou entre une donnée extraite et un critère d’extraction respectif. Le module de rangement 55 est préférentiellement configuré pour ranger, dans la classe appropriée, chaque première relation définissant un lien entre deux éléments rangés. Chaque première relation est par exemple un élément textuel, aussi dit axiome ou triplet de données sémantique. Chaque première relation permet de définir le lien sémantique entre deux éléments rangés dans la base structurée 10. Chaque lien sémantique permet par exemple, de définir un lien d’appartenance, d’interdépendance, ou encore de hiérarchie entre deux éléments. Un tel lien de hiérarchie est assimilable à une notion de sous-classe. Ainsi, par exemple le lien sémantique entre une donnée extraite « Bordeaux » et un deuxième identifiant « aéroport », du type « Bordeaux est un aéroport » est équivalent au fait d’avoir dans la base structurée 10, la sous-classe « aéroport » comprise dans une des classes par exemple issues de la théorie de l’activité, et comprenant la donnée extraite « Bordeaux ». De tels liens sémantiques permettent alors de qualifier la base structurée 10 de base ontologiquement organisée, car elle comprend, outre des données, des liens sémantiques entre ses données. Un tel formalisme de base ontologiquement organisé est dit du type OWL (de l’anglais Ontology Web Language ou Web Ontology Language ). Les précisions ci-dessus concernant chaque première relation sont également applicables à chaque deuxième, troisième et quatrième relations définies ci-après. Chaque première relation se déduit de la loi d’extraction incluse dans la règle d’extraction à laquelle elle est relative, et notamment des spécificités de dépendance entre chaque mot-clé dans ladite loi. En complément facultatif, le module de rangement 55 est configuré pour, en cas de réception de plusieurs données extraites suite à l’envoi d’une loi respective d’extraction, ranger chaque donnée extraite reçue dans la base structurée 10. Ainsi, dans le cas où l’ensemble 15 comprend au moins deux bases sources 20, si des données extraites sont reçues de plusieurs bases sources 20, chaque donnée extraite est rangée dans la classe correspondant au premier identifiant associé à la loi d’extraction à l’origine des données extraites reçues. En complément facultatif encore, le module de rangement 55 est configuré pour, si au moins deux deuxièmes identifiants reçus sont associés à un même mot-clé respectif de la loi d’extraction, ranger une deuxième relation dans la base structurée 10. La deuxième relation indique alors par exemple que les deux deuxièmes identifiants sont synonymes. En complément facultatif, le module de rangement 55 est également configuré pour ranger les données invariantes au cours de la mission dans les classes associées au premier identifiant de chacune, si l’ensemble de données invariantes a été acquis. En complément facultatif encore, le module de rangement 55 est également configuré pour ranger le groupe de règle(s) d’extraction dans la classe « règle(s) », si la base structurée 10 comprend une telle classe. Le module d’association 60 est connecté en sortie du module de sélection 45 et en sortie de l’ensemble 15 de base(s) source(s) 20. Le module d’association 60 est configuré pour associer chaque loi d’extraction, pour laquelle aucune donnée extraite n’est reçue, à la classe de requête(s) infructueuse(s). Le module d’association 60 est optionnellement configuré pour déterminer qu’aucune donnée extraite n’est reçue suite à l’envoi d’une loi respective d’extraction si le ou les messages reçus de l’ensemble 15 vérifient seulement au moins l’un des cas suivants : un message d’erreur est reçu de l’ensemble 15, un message comportant un champ de données vide est reçu de la part de l’ensemble 15. Le module d’association 60 est configuré pour recevoir les requêtes en langage SPARQL en sortie de chaque traducteur 30. Ainsi le module d’association 60 est configuré pour recevoir de la part de l’ensemble 15, pour chaque base source 20 et pour chaque loi d’extraction envoyée, l’ensemble de deuxième(s) identifiant(s) de classe, et le groupe de critère(s) d’extraction. L’ensemble de deuxième(s) identifiant(s) de classe et le groupe de critère(s) d’extraction sont obtenus par le traducteur 30 propre à chaque base source 20. En l’absence de réception de données extraites suite à la ou chaque loi d’extraction envoyée, le module d’association 60 est optionnellement configuré pour qualifier d’infructueuse la loi envoyée. Le module d’association 60 est alors de préférence configuré pour associer chaque loi infructueuse à la classe de requête(s) infructueuse(s) en rangeant dans ladite classe, l’ensemble de deuxième(s) identifiant(s) et le groupe de critère(s) d’extraction associés à ladite loi. Une loi d’extraction sans réponse d’un jeu de donnée(s) extraite(s), c’est-à-dire pour laquelle le premier tableau du message reçu est vide, est considérée comme infructueuse. Ce mécanisme fait référence à une absence des donnée(s) cherchée(s) dans l’ensemble 15 de base(s) source(s) 20. Ces données sont également nommées données manquantes. Plus spécifiquement, pour chaque loi infructueuse, le module d’association 60 est optionnellement configuré pour ranger, dans la classe de requête(s) infructueuse(s): chaque deuxième identifiant absent de la base structurée 10, chaque critère d’extraction, et au moins une troisième relation liant un deuxième identifiant respectif et un critère d’extraction respectif de la loi infructueuse. Le module d’association 60 est préférentiellement configuré pour ranger, pour chaque loi infructueuse, chaque troisième relation liant deux éléments rangés par ledit module 60 et chaque troisième relation liant un deuxième identifiant respectif déjà présent dans la base structurée 10 à un autre élément respectif rangé par ledit module 60. En complément facultatif, le module d’association 60 est optionnellement configuré pour, en cas de qualification d’une loi d’extraction comme infructueuse, distinguer la configuration concernée parmi des première et deuxième configurations possibles. Dans la première configuration, aucune donnée extraite n’est reçue car aucune donnée ne vérifie le groupe de critère(s) d’extraction. Le module d’association 60 est configuré pour effectuer dans ce cas le rangement comme décrit ci-dessus. Dans la deuxième configuration, aucune donnée n’est reçue car aucune base source 20 ne comporte l’ensemble de classe(s) correspondant à l’ensemble de mot(s) clé(s) de la loi d’extraction qualifiée d’infructueuse. Autrement dit, le traducteur 30 de chaque base source 20 n’a pas réussi à traduire chaque mot-clé de la loi d’extraction en un deuxième identifiant de classe de la base source 20 à laquelle il est associé. Le module d’association 60 est dans ce cas, configuré pour, ranger dans la classe de requête(s) infructueuse(s), chaque deuxième identifiant absent de la base structurée 10, chaque mot-clé de la loi infructueuse n’ayant pas de deuxième identifiant associé, chaque critère d’extraction et au moins une quatrième relation liant ledit ou un desdits mots-clés à un deuxième identifiant de la loi infructueuse. Pour chaque critère(s) d’extraction spécifiant une caractéristique d’un mot-clé non-traduit en deuxième identifiant, le deuxième identifiant est remplacé par ledit mot-clé. Le module d’association 60 est préférentiellement configuré pour ranger, pour chaque loi d’extraction infructueuse, toutes les quatrièmes relations existantes entre chaque deuxième identifiant, chaque mot-clé, et chaque critère d’extraction, pris deux à deux. Le module de récupération 65 est configuré pour récupérer une demande de données de l’utilisateur 47. Le module de récupération 65 est par exemple configuré pour récupérer la demande sous forme textuelle. Le module de communication 75 est connecté en sortie du module de détermination 70 et est configuré pour communiquer le message à partir de ce qui a été déterminé par le module de détermination 70, à l’utilisateur 47 ou à un dispositif électronique de traitement, non représenté. Pour cela, le module de communication est par exemple un assistant virtuel comprenant un dialogueur (de l’anglais chatbot ) interagissant avec l’utilisateur 47 au travers de moyens de communication tel qu’un écran d’affichage, un système audio comprenant un microphone et/ou un haut-parleur, un capteur et/ou actionneur haptique, ou toute combinaison possible des moyens de communication précités. Le module de communication 75 est configuré pour communiquer chaque donnée demandée présente dans la base structurée 10 à l’utilisateur 47 ou au dispositif électronique de traitement. Le module de communication 75 est également configuré pour, si la demande concerne un deuxième identifiant de classe respectif, ou le cas échéant, un mot-clé respectif de la classe de requête infructueuse, communiquer un message indiquant que la ou les données demandées concernent une ou des données absentes de l’ensemble 15 de base(s) source(s) 20 à l’utilisateur 47 ou au dispositif électronique de traitement. En complément facultatif, le module de communication 75 est également configuré pour, si la ou les données demandées sont absentes de la base structurée 10 et ne concernent pas un deuxième identifiant respectif ou un mot-clé respectif de la classe de requête(s) infructueuse(s), communiquer un message respectif indiquant que la ou les données demandées n’ont pas encore été recherchées, à l’utilisateur 47 ou au dispositif électronique de traitement. Le module de communication 75 est dans ce cas, typiquement configuré en outre pour envoyer la demande à l’ensemble 15 en tant que loi d’extraction afin d’essayer d’obtenir la ou les données demandées. Ainsi, chaque action requise correspond à l’intention de l’utilisateur 47 au cours de la mission pour laquelle des données sont extraites afin de l’aider à prendre une décision. Chaque règle d’extraction est associée à l’action requise, et comprend la loi d’extraction propre à être envoyée à l’ensemble 15, ainsi que le premier identifiant de classe. Chaque loi d’extraction comprend l’ensemble de mot(s)-clé(s) et au moins la spécificité précisant la caractéristique dudit mot-clé, ou le cas échéant, la dépendance entre deux mots-clés. Le premier identifiant de classe correspond à la classe de la base structurée 10 dans laquelle sont rangées les données issues de l’ensemble 15, suite à l’envoi de la loi d’extraction. Les données invariantes comportent des données n’évoluant pas au cours de la mission et le premier identifiant de classe, propre à chaque donnée, indiquant la classe de la base structurée 10 dans laquelle ladite donnée doit être rangée. Chaque classe est l’élément de la structure de la base structurée 10 correspondant au premier identifiant de classe inclus dans la règle d’extraction. La base structurée 10 comprend également la classe de requête(s) infructueuse(s). Chaque requête correspond à la traduction par le traducteur 30 de la loi d’extraction. Chaque requête comprend l’ensemble de deuxième(s) identifiant(s) respectif et le groupe de critère(s) respectif d’extraction. Chaque deuxième identifiant de classe correspond à la traduction, par le traducteur 30, d’un mot-clé respectif de la loi d’extraction. Chaque deuxième identifiant de classe identifie la classe respective de la base source 20 à laquelle le traducteur 30 est associé. Chaque critère d’extraction correspond à la traduction par le traducteur 30, de la spécificité en la condition pour l’extraction la donnée de la base source 20 à laquelle le traducteur 30 est associé. Chaque message reçu de l’ensemble 15 comprend l’ensemble de deuxième(s) identifiant(s) de classe, le groupe de critère d’extraction, et le cas échéant, le jeu de donnée(s) extraite(s). Chaque donnée extraite est la donnée de la base source 20 respective extraite par la requête. Chaque première relation correspond au lien, rangé dans la base structurée 10, entre la donnée extraite et le deuxième identifiant de classe de la requête associée, ou entre la donnée extraite et le critère d’extraction de ladite requête, ou entre le deuxième identifiant et le critère d’extraction, ou encore le cas échéant entre deux deuxièmes identifiants. Chaque deuxième relation correspond au lien, rangé dans la base structurée 10, entre deux deuxièmes identifiants de classe spécifiant qu’ils sont synonymes, dans le cas où les deux deuxièmes identifiants sont associés à un même mot-clé respectif. Chaque troisième relation correspond au lien, rangé dans la base structurée 10, entre le deuxième identifiant et le critère d’extraction respectifs de ladite requête, ou le cas échéant entre deux deuxièmes identifiants d’une requête respective, en l’absence de donnée extraite par ladite requête. Chaque quatrième relation correspond au lien, rangé dans la base structurée 10, entre un deuxième identifiant respectif ou un mot-clé respectif, et un autre deuxième identifiant respectif ou un autre mot-clé respectif ou encore un critère d’extraction, chacun d’une même requête respective, en cas d’absence de traduction d’un mot-clé en un deuxième identifiant de classe respectif. Le fonctionnement du système de génération 5, et en particulier du dispositif de génération 25 selon l’invention, va être à présent décrit en regard de la représentant un organigramme du procédé, selon l’invention, de génération de la base structurée 10, le procédé étant mis en œuvre par le dispositif de génération 25. Lors d’une étape d’acquisition 110, le dispositif de génération 25 acquiert la liste d’action(s) requise(s) au cours de la mission et le groupe de règle(s) d’extraction de données de l’ensemble 15, via son module d’acquisition 35. Chaque règle d’extraction est associée à une action requise respective. Lors de l’étape d’acquisition 110, le dispositif de génération 25 acquiert optionnellement en outre l’ensemble de donnée(s) invariante(s) au cours de la mission. Le dispositif de génération 25 passe ensuite à une étape de génération 120 dans laquelle il génère la structure de la base structurée 10, via son module de génération 40. Lors de l’étape de génération 120, le dispositif de génération 25 range optionnellement l’ensemble de donnée(s) invariante(s) dans les classes de la base structurée 10, ainsi que le groupe de règle(s) d’extraction dans la classe « règle(s)» si une telle classe est présente. Le dispositif de génération 25 passe ensuite à une étape de sélection 130 dans laquelle il sélectionne, suite au choix par l’utilisateur 47 de l’action requise parmi la liste d’action(s) requise(s), la ou les règles d’extraction associées à l’action requise choisie. Le dispositif de génération 25 passe ensuite à une étape d’envoi 140 dans laquelle, il envoie via son module d’envoi 50, chaque loi d’extraction sélectionnée à l’ensemble 15. Dans le cas où l’ensemble 15 comporte plusieurs bases sources 20, le module d’envoi 50 envoie la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à chaque traducteur 30 de chaque base source 20. En complément facultatif, lors de l’étape d’envoi 140, le dispositif de génération 25 complète les lois d’extraction à partir de données déjà rangées dans la base structurée 10. Le dispositif de génération 25 passe ensuite à une première étape de détection 150, dans laquelle il reçoit, pour chaque loi d’extraction envoyée, un message de la part de l’ensemble 15, et détecte la présence ou non du jeu de donnée(s) extraite(s) dans le message reçu. Pour chaque message reçu comprenant le jeu de donnée(s) extraite(s), le dispositif de génération 25 range, lors d’une étape de rangement 160 et via son module de rangement 55, chaque donnée extraite reçue dans la base structurée 10. Comme décrit précédemment pour le module de rangement 55, lors de l’étape de rangement 160, le dispositif de génération 25 range dans la classe correspondant au premier identifiant associé à la loi d’extraction en réponse à laquelle la ou les données extraites sont reçues, chaque deuxième identifiant encore absent de la base structurée 10, chaque critère d’extraction, chaque donnée extraite, et au moins une première relation respective entre une donnée extraite respective et un deuxième identifiant respectif. Lors de l’étape de rangement 55, le dispositif de génération 25 range de préférence toutes les premières relations entre les données extraites, les deuxièmes identifiants et les critères d’extractions. En complément facultatif, durant l’étape de rangement 160, dans le cas où au moins deux données extraites sont reçues en réponse à la même loi d’extraction envoyée, le dispositif de génération 25 range chaque donnée extraite reçue dans la classe correspondant au premier identifiant associé à ladite loi d’extraction. En complément facultatif encore, durant l’étape de rangement 160, dans le cas où l’ensemble 15 comprend au moins deux bases sources 20, si deux deuxièmes identifiants associés à un même mot-clé respectif de la loi d’extraction sont reçus, le dispositif de génération 25 range une deuxième relation respective dans la classe correspondant au premier identifiant de la règle associée à ladite loi. Pour chaque message reçu ne comprenant pas de jeu de donnée(s) extraite(s), le dispositif de génération 25 passe à une étape d’association 170 dans laquelle il associe la loi d’extraction à l’origine dudit message, à la classe de requête(s) infructueuse(s). En complément facultatif, lors de l’étape d’association 170, le dispositif de génération 25 qualifie ladite loi d’infructueuse. Le dispositif de génération 25 range dans la classe de requête(s) infructueuse(s), chaque deuxième identifiant absent de la base structurée 10, chaque critère d’extraction et au moins une troisième relation respective liant deux deuxièmes identifiants entre eux ou liant un deuxième identifiant respectif à un critère d’extraction respectif. Le dispositif de génération 25 range de préférence toutes les troisièmes relations entre chaque deuxième identifiant et chaque critère d’extraction. En complément facultatif encore, lors de l’étape d’association 170, si l’absence de donnée extraite est due à l’absence de traduction d’un mot-clé respectif de la loi envoyée en un deuxième identifiant respectif d’une base source 20 respective, alors le dispositif de génération 25 range, dans la classe de requête(s) infructueuse(s) : chaque deuxième identifiant de classe absent de la base structurée 10, chaque mot-clé non traduit en un deuxième identifiant respectif, chaque critère d’extraction, au moins une quatrième relation respective liant un deuxième identifiant respectif ou un mot-clé respectif, à un critère d’extraction respectif ou à un deuxième identifiant respectif ou à un mot-clé respectif. Pour chaque critère d’extraction relatif à chaque mot-clé non-traduit en un deuxième identifiant respectif, le mot-clé remplace le deuxième identifiant. Lors de l’étape d’association 170, chaque quatrième relation liant deux éléments rangés est de préférence rangée également dans la base structurée 170. Selon une variante non représentée sur la , le dispositif de génération 25 réitère les étapes d’envoi 140, de rangement 160 et d’association 170 régulièrement, et de préférence périodiquement, pour la mise à jour des données dans la base structurée 10. Le dispositif de génération 25 passe ensuite optionnellement dans une étape de récupération 180 au cours de laquelle il récupère via son module de récupération 65, la demande de donnée(s) de la part de l’utilisateur 47. Le dispositif de génération 25 passe ensuite dans une étape de détermination 190 dans laquelle il détermine, via son module de détermination 70, si chaque donnée demandée est contenue ou non dans la base structurée 10. Pour chaque donnée demandée, si ladite donnée est contenue dans la base structurée 10, le dispositif de génération 25 passe ensuite à une première étape de communication 200 au cours de laquelle il communique, via son module de communication 75, la donnée demandée à l’utilisateur 47 ou au dispositif électronique de traitement. Pour chaque donnée demandée absente de la base structurée 10, le dispositif de génération 25 passe à une deuxième étape de détection 210 dans laquelle il détecte si la demande est relative au(x) élément(s) rangé(s) dans la classe de requêtes(s) infructueuse(s) en détectant si la demande est associée à un deuxième identifiant respectif, un critère d’extraction respectif, une troisième ou encore une quatrième relation respective de la classe de requête(s) infructueuse(s). Si la demande est relative à un ou des éléments de la classe de requête(s) infructueuse(s), le dispositif de génération 25 passe à une deuxième étape de communication 220 dans laquelle il communique un message indiquant que la ou les données demandées sont absentes de l’ensemble 15, à l’utilisateur 47 ou au dispositif électronique de traitement. Si la demande n’est pas relative à un ou des éléments de la classe de requête(s) infructueuse(s), le dispositif de génération 25 passe optionnellement à une troisième étape de communication 230 au cours de laquelle il communique un message indiquant que la ou les données demandées n’ont pas encore été recherchées à l’utilisateur 47 ou au dispositif de traitement. Lors de la troisième étape de communication 230, le dispositif de génération 25 envoie optionnellement la demande à l’ensemble 15 et retourne à l’étape de rangement 160 si une donnée extraite respective est reçue en retour. Sinon, le dispositif de génération 25 passe à l’étape d’association 170. En cas de donnée extraite reçue en retour, le module de rangement 55 range les différents éléments dans une classe de la base structurée 10 choisie par l’utilisateur 47. Le fonctionnement du système de génération 5, et plus précisément du dispositif de génération 25, va maintenant être illustré, en référence aux figures 2 et 3, sur un exemple de mission de vol d’un aéronef. Lors de l’étape d’acquisition 110, l’action requise est par exemple le déroutement de l’aéronef. Lors de l’étape d’acquisition 110, le dispositif de génération 25 acquiert les règles d’extraction, liées à l’action requise de déroutement de l’aéronef, dont les lois d’extraction sont respectivement : « trouver un aéroport dont la longueur de la piste est supérieure à une longueur L prédéterminée», et « trouver un aéroport dont les conditions météorologiques correspondent au standard CAVOK, et distant de l’aéronef d’au plus 50 km», CAVOK (de l’anglais « Cloud And Visibility OK ») correspondant à un standard météorologique dans lequel la visibilité est considérée comme bonne et dans lequel la présence de nuages est limitée. Le premier identifiant contenu dans chacune desdites règles d’extraction est « mission ». Pour la première loi d’extraction, les mots-clés sont : « aéroport » et « piste ». Pour la deuxième loi d’extraction, les mots-clés sont : « aéroport », « conditions météorologiques » et « distant ». Lors de l’étape d’acquisition 110, le module d’acquisition 35 acquiert également les données invariantes relatives à la référence du modèle de l’aéronef, par exemple « Airbus A350 », et à l’aéroport d’origine « aéroport d’origine Toulouse », chaque donnée invariante étant associée au premier identifiant de classe « mission ». Lors de l’étape de génération 120, le dispositif de génération 25 génère la structure de la base structurée 10. La structure doit au moins comprendre la classe « mission », car elle correspond au premier identifiant de classe des règles d’extraction acquises. La structure comprend par exemple les six classes de la théorie de l’activité : « sujet », « outil(s) », « communauté », « division du travail », « visée », et « règle(s)». Dans cet exemple, la classe « mission » correspond alors à la classe « visée », de sorte que les classes « visée » et « mission » forment une seule et même classe. Dans cet exemple également, la classe « sujet » est destinée à contenir des données relatives au pilote de l’aéronef, la classe « outil(s) » est destinée à contenir des données relatives aux moyens pour réaliser la mission, la classe « communauté » est destinée à contenir des données relatives à d’autres entités ou individus qui vont participer au déroulement de la mission comme le copilote, le personnel à bord, ou aux tours de contrôle, la classe « division du travail » est destinée à contenir des données relatives au partage de l’activité avec la communauté, et la classe « visée » est destinée à contenir des données relatives à la mission. La structure générée comprend en outre la classe de requête(s) infructueuse(s), appelée « requête(s) infructueuse(s) ». Sur la les classes sont représentées sous forme de cases grisées chacune rattachée à la racine qui est représentée sous forme d’une case hachurée. Lors de l’étape de génération 120, le dispositif de génération 25 range les données invariantes dans la classe indiquée par leur premier identifiant de classe. Lors de l’étape de génération 120, le dispositif de génération 25 range les règles d’extraction dans la classe « règle(s) ». Sur la figure 3, les règles d’extraction sont respectivement référencées et . Lors de l’étape de sélection 130, le dispositif de génération 25 sélectionne les règles d’extraction associées à l’action requise « déroutement de l’aéronef » choisie par l’utilisateur 47. Lors de l’étape d’envoi 140, le dispositif de génération 25 complète la loi d’extraction de la première règle d’extraction avec la donnée invariante relative à la référence de modèle de l’aéronef, rangée dans la base structurée 10. La loi d’extraction de la première règle d’extraction devient donc par exemple « trouver un aéroport dont la longueur de la piste est supérieure à 1,2 km ». Lors de l’étape d’envoi 140, le dispositif de génération 25 envoie, à l’ensemble 15, les lois d’extraction contenues dans les première et deuxième règles d’extraction. Lors de la première étape de détection 150, le dispositif de génération 25 reçoit pour chaque loi envoyée, un message de la part de l’ensemble 15 et détecte la présence ou non du jeu de donnée(s) extraite(s). Un premier (respectivement deuxième) message correspond au message reçu suite à l’envoi de la loi d‘extraction inclue dans la première (respectivement deuxième) règle d’extraction. Le premier message comprend par exemple les deuxièmes identifiants : « aérodrome » et « piste d’atterrissage », le critère d’extraction « piste d’atterrissage km » et le jeu de donnée(s) extraite(s) « Bordeaux, Limoges » Le deuxième message comprend par exemple les deuxièmes identifiants : « aérodrome » et « météo », et « distance », les critères d’extraction « météo =CAVOK» et « distance km », mais aucun jeu de donnée(s) extraite(s). Pour le premier message, lors de l’étape de rangement 160, le dispositif de génération 25 range, dans la classe « mission » de la base structurée 10, les deuxièmes identifiants, le critère d’extraction et les données extraites. Sur la , les deuxièmes identifiants, le critère d’extraction et les données extraites sont respectivement représentés par des cases en trait pointillé, respectivement de forme elliptique, parallélépipédique, et rectangulaire. Lors de l’étape de rangement 160, le dispositif de génération 25 range dans la base structurée 10, les premières relations : « aérodrome comporte piste d’atterrissage », « Limoges est un aérodrome», « Bordeaux est un aérodrome», « Limoges comporte piste d’atterrissage », « Bordeaux comporte piste d’atterrissage », « piste d’atterrissage km est un type de piste d’atterrissage», « Limoges comporte piste d’atterrissage km » et « Bordeaux comporte piste d’atterrissage km ». Sur la , ces premières relations sont représentées par des segments en trait pointillé reliant chacun deux cases. Pour le deuxième message, lors de l'étape d’association, 170, le dispositif de génération 25 qualifie la loi d’extraction d’infructueuse et range dans la classe « requête(s) infructueuse(s) », les deuxièmes identifiants « météo » et « distance », ainsi que les critères d’extraction « météo=CAVOK» et « distance km ». Le deuxième identifiant « aérodrome » n’est pas rangé dans la classe de requête(s) infructueuse(s) car il est déjà présent dans la classe « mission ». Le dispositif de génération 25 range, également dans la base structurée 10, les troisièmes relations : « aérodrome comporte météo », « aérodrome est à distance » « distance km est un type de distance», « météo= CAVOK est un type de météo » Par souci de lisibilité des dessins, les éléments rangés lors de l’étape d’association 170 ne sont pas représentés sur la . Lors de l’étape de récupération 180, le dispositif de génération 25 récupère les première et deuxième demandes suivantes de la part de l’utilisateur 47 : « Quels sont les aéroports ayant une piste longue d’au moins 1 km ? » et « Quels sont les aéroports ayant une météo CAVOK et à une distance inférieure à 30 km de l’aéronef ? ». Lors de l’étape de détermination 190, le dispositif de génération 25 détermine que la première demande est relative à des données extraites présentes dans la base structurée 10, contrairement à la deuxième demande. Pour la première demande, lors de la première étape de communication 200, le dispositif de génération 25 communique les données « Bordeaux » et « Limoges » à l’utilisateur 47. Pour la deuxième demande, le dispositif de génération 25 passe à la deuxième étape de détection 210 dans laquelle il détecte que la deuxième demande est relative à la classe « requête(s) infructueuse(s) » car si l’ensemble 15 ne comporte aucune donnée vérifiant le critère d’extraction relatif aux conditions météorologiques et étant à une distance inférieure à 50 km de l’aéronef, alors l’ensemble 15 ne comporte aucune donnée vérifiant le même critère sur les conditions météorologiques et distant d’au plus 30 km. Lors de la deuxième étape de communication 220, le dispositif de génération 25 communique à l’utilisateur 47 un message indiquant que la ou les données demandées sont absentes de l’ensemble 15. Le procédé de génération selon l’invention permet alors de générer la base structurée 10 comprenant un nombre plus réduit de données, chaque donnée de la base structurée 10 correspondant à une règle d’extraction respective. De plus, le rangement dans la base structurée 10 de deuxième(s) identifiant(s) de classe, de critère(s) d’extraction, de première(s) relation(s), deuxième(s) relation(s), troisième(s) relation(s) et de quatrième(s) relation(s) permet de contextualiser chaque donnée extraite et donc une meilleure utilisation des données extraites. Lesdits éléments sont qualifiés d’élément(s) de contexte. En effet, cela permet à un utilisateur d’avoir non seulement accès aux données, mais aussi au contexte dans lequel elles ont été extraites, et donc de mieux comprendre la provenance de chaque donnée. Ceci permet entre autres, à un utilisateur 47 de déceler une éventuelle incohérence d’une donnée extraite d’une base source 20, ce qui serait impossible, ou à tout le moins plus difficile, sans lesdits éléments de contexte. En outre, le rangement de chacun des éléments de contexte précités, combiné avec la structure issue de la théorie de l’activité, permet de générer une base de données structurée 10 dédiée et exhaustive, à partir d’un procédé générique applicable à différents domaines. De plus, la sélection de règles d’extraction en fonction de l’action requise choisie par l’utilisateur 47 rend l’extraction plus sélective, s’assurant que les données extraites sont utiles pour la compréhension de la situation. En outre, la classe de requête(s) infructueuse(s) permet de distinguer parmi les données absentes, dans la base structurée 10, celles qui sont supposées non-pertinentes lors de l’établissement de(s) règle(s) d’extraction, de celles qui sont absente de(s) base(s) de source(s) 20. Les étapes optionnelles de récupération 180, de détermination 190 et de communication 200 permettent de communiquer à l’utilisateur 47 les données de la base structurée 10 et, grâce à la classe de requête(s) infructueuse(s) et l’étape d’association 170, de l’informer en outre plus rapidement quant aux éventuelles données absentes de l’ensemble 15. La prise en compte de l’absence de certaine(s) donnée(s) de l’ensemble 15 conduit alors à une meilleure compréhension de la part de l’utilisateur 47 des données qu’il a à sa disposition dans la base structurée 10. En outre, le fait qu’en cas de demande ne concernant ni une donnée contenue dans la base structurée 10, ni un élément de la classe de requête(s) infructueuse, cette demande est préférentiellement néanmoins prise en compte pour interroger l’ensemble 15, permet à l’utilisateur 47 de ne pas être contraint par les seules données considérées comme pertinentes de par le groupe de règle(s) d’extraction. Le fait que les lois d’extraction soient envoyées à l’ensemble 15 dans un langage dit naturel, et que la traduction en langage informatique est effectuée par le traducteur 30 respectif, rend le procédé plus facilement adaptable à différentes bases sources 20 hétérogènes. Il est notamment plus facile d’ajouter une ou plusieurs base sources 20 à l’ensemble 15. En outre, le fait qu’en cas de réception de données distinctes, en réponse à une même loi d’extraction, les données extraites distinctes soient rangées, lors de l’étape de rangement 160, dans la même classe de la base structurée 10, permet de laisser la validation des données extraites à l’utilisateur 47. Cela permet en outre de ne pas risquer d’omettre le rangement d’une donnée pertinente dans la base structurée 10. On conçoit ainsi que le procédé et le dispositif de génération 25 selon l’invention permettent d’améliorer l’extraction de données à partir de la ou des bases sources 20, ainsi que la génération de la base structurée 10 qui optimise les temps de réponses aux questionnements de l’utilisateur 47. Procédé de génération, à partir d’un ensemble (15) de base(s) de données (20), d’une base structurée de données (10) associée à une mission, le procédé étant mis en œuvre par un dispositif électronique de génération (25) et comprenant les étapes suivantes : - acquisition (110) d’une liste d’action(s) requise(s) au cours de la mission, et d’un groupe de règle(s) d’extraction de données de l’ensemble (15) de base(s) de données (20), chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée (10) et une loi d’extraction de donnée(s) à partir de la ou des bases de données (20), chaque règle étant associée à une ou plusieurs action(s) requise(s), - génération (120) d’une structure de la base structurée de données (10) comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s), - sélection (130) de règle(s) d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur (47) parmi la liste d’action(s) requise(s), - envoi (140) de la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble (15) de base(s) de données (20), et réception de donnée(s) extraite(s) de la part des bases de données (20) suite à cet envoi, - rangement (160) de la ou chaque donnée extraite reçue dans la classe de la base structurée (10) correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et - pour chaque loi d’extraction envoyée, si aucune donnée extraite n’est reçue en réponse de la part de l’ensemble (15) de base(s) de données (20), association (170) de ladite loi à la classe de requête(s) infructueuse(s). Procédé selon la revendication 1, dans lequel, suite à l’envoi (140) d’une loi d’extraction, aucune donnée extraite n’est reçue de l’ensemble des base(s) de données (15) si le ou les messages reçus de l’ensemble (15) de base(s) de données (20) vérifient seulement au moins l’un des cas suivants : un message d’erreur est reçu de l’ensemble (15) de base(s) de données (20), un message comportant un champ de données vide est reçu de la part de l’ensemble (15) de base(s) de données (20). Procédé selon la revendication 1 ou 2, dans lequel l’ensemble de base(s) (15) de données comprend au moins deux bases de données (20), et lors de l’étape d’envoi (140), la loi d’extraction incluse dans chaque règle d’extraction sélectionnée est envoyée à chaque base de données (20). Procédé selon la revendication 3, dans lequel si les bases de données (20) fournissent au moins deux données extraites différentes en réponse à une même loi d’extraction envoyée, les au moins deux données extraites sont, lors de l’étape de rangement (160), rangées dans la même classe de la base structurée (10), correspondant au premier identifiant de classe associé à ladite loi d’extraction. Procédé selon l’une quelconque des revendications précédentes, dans lequel suite à l'envoi (140) d’une loi d’extraction, chaque donnée reçue comprend : un jeu de donnée(s) extraite(s) d’une base de données (20), en réponse à la loi d’extraction envoyée, un ensemble de deuxième(s) identifiant(s) de classe de la base de données (20) depuis laquelle jeu de donnée(s) extraite(s) est issu, chaque deuxième identifiant correspondant à une classe respective de ladite base de données (20) depuis laquelle au moins une donnée extraite respective est issue, et un groupe de critère(s) d’extraction de données depuis la base de données (20) dont le jeu de donnée(s) extraite(s) est issu, l’ensemble de deuxième(s) identifiant(s) et le groupe de critère(s) étant propre à chaque base de données (20) et étant générés à partir de la loi d’extraction envoyée, lors de l’étape de rangement (160), l’ensemble de deuxième(s) identifiant(s), le groupe de critère(s) et le jeu de donnée(s) sont rangés dans la classe correspondant au premier identifiant de classe associé à ladite loi d’extraction, lors de l’étape de rangement (160), au moins une première relation entre une donnée extraite et un deuxième identifiant de classe est en outre rangé dans ladite classe de la base structurée (10). Procédé selon l’une quelconque des revendications précédentes, dans lequel la mission est le vol d’un aéronef, l’ensemble d’action(s) requise(s) comprenant de préférence : un démarrage de l’aéronef, un déroutement de l’aéronef et un contournement par l’aéronef d’une zone géographique. Procédé selon la revendication 6, dans lequel les règles d’extraction associées à l’action requise de déroutement comprennent les lois d’extraction : - trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie, - trouver un aéroport dont les conditions météorologiques correspondent à des conditions prédéfinies, - trouver un aéroport possédant des services d’urgence, et - trouver un aéroport distant de l’aéronef d’au plus une distance maximale prédéfinie ( ), et dans lequel les règles d’extraction associées à l’action requise de contournement comprennent les lois d’extraction : trouver des coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) les conditions météorologiques correspondent à des conditions prédéfinies, et distant de l’aéronef d’au plus une deuxième distance maximale prédéfinie ( ). Procédé selon l’une quelconque des revendications précédentes, dans lequel, lors de l’étape d’acquisition (110), des données invariantes au cours de la mission sont en outre acquises, et lors de l’étape d’envoi (140), au moins une loi d’extraction envoyée est complétée par au moins une donnée invariante au cours de la mission, si la mission est les vol d’un aéronef, les données invariantes au cours de la mission comprenant de préférence un type ou une référence de modèle de l’aéronef, un numéro de vol d’un aéronef, un aéroport de départ de l’aéronef, une quantité initiale de carburant dans l’aéronef. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend en outre, après l’étape de rangement (160) ou d’association (170) : - une étape de récupération (180) d’une demande de la part d’un utilisateur (47), et - si la demande concerne une loi d’extraction associée à la classe de requête(s) infructueuse(s), une étape (220) de communication d’un message indiquant que la donnée répondant à la demande est absente de l’ensemble (15) de base(s) de données (20) à l’utilisateur (47). Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon l’une quelconque des revendications précédentes. Dispositif électronique de génération (25) configuré pour générer, à partir d’un ensemble (15) de base(s) de données (20), une base structurée de données (10) associée à une mission, le dispositif (25) étant apte à être relié à un ensemble (15) de base(s) de données (20), le dispositif électronique de génération (25) comprenant : - un module d’acquisition (35) configuré pour acquérir une liste d’action(s) requise(s) au cours de la mission, et un groupe de règle(s) d’extraction de données de l’ensemble (15) de base(s) de données (20), chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée (10) et une loi d’extraction de donnée(s) à partir de la ou des bases de données (20), chaque règle étant associée à une ou plusieurs action(s) requise(s), - un module de génération (40) configuré pour générer une structure de la base structurée de données (10) comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s), - un module de sélection (45) configuré pour sélectionner une ou plusieurs règles d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur (47) parmi la liste d’action(s) requise(s), - un module d’envoi (50) configuré pour envoyer la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble (15) de base(s) de données (20), et un module de réception de donnée(s) de la part des bases de données (20) suite à cet envoi, - un module de rangement (55) configuré pour ranger la ou chaque donnée reçue dans la classe de la base structurée (10) correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et - un module d’association (60) configuré pour associer chaque loi d’extraction envoyée, pour laquelle aucune donnée extraite n’est reçue en réponse de la part de l’ensemble (15) de base(s) de données (20), à la classe de requête(s) infructueuse(s).