FR 3151675 A1 20250131 FR 2307921 A 20230724 La présente invention concerne un procédé d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données (12) d’un premier serveur (1), caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (21) d’un deuxième serveur (2) : Obtention desdites premières instructions depuis un terminal client (10) ; Traduction desdites premières instructions en un arbre syntaxique abstrait Génération, à partir dudit arbre syntaxique abstrait, de deuxièmes instructions en un langage de programmation orienté objet distinct d’un langage d’exploitation de ladite base de données ; Exécution desdites deuxièmes instructions dans une machine virtuelle mise en œuvre par les moyens de traitement de données (21) de sorte à réaliser ledit traitement analytique souhaité, comprenant le déclenchement de requêtes sur ladite base de données dans ledit langage d’exploitation de la base de données, ladite machine virtuelle utilisant un noyau objet d’interface avec ladite base de données. [Fig. 1] Procédé d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine de l’exploitation des bases de données. Plus précisément, elle concerne d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données. ETAT DE L’ART De nombreuses entreprises travaillent aujourd’hui autour d’une base de données massive contenant toutes les informations utiles à l’entreprise telles que les nomenclatures, les gammes, les matières premières, les capacités de production, les quantités, les commandes, les ventes, etc. Il est nécessaire de disposer des outils permettant efficacement de manipuler une telle base de données (intégration et maintenance de données), et surtout de mettre en œuvre des traitements analytiques des données contenues dans la base sur lesquelles des décisions stratégiques pourront être prise ou alimentant des traitements ultérieurs : tableaux de bords, machine learning, production de nouvelles données, etc. Pour ce faire on a : Soit des langages de programmation spécifiques (dits d’exploitation de base de données) tel que SAS (Statistical Analysis System), SQL ou le module Pandas de Python® qui sont très puissants mais peu accessibles aux néophytes Soit des logiciels métier dédiés dit progiciels (souvent appelés ERP pour enterprise resource planning), qui sont alors couteux et pas toujours évolutifs. Il serait souhaitable de disposer d’une autre solution d’exploitation de bases de données qui a les fonctionnalités des langages habituellement réservés aux professionnels de la donnée et aussi leur puissance, mais qui soit plus accessibles et évolutifs. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données d’un premier serveur, caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données d’un deuxième serveur : Obtention desdites premières instructions depuis un terminal client ; Traduction desdites premières instructions en un arbre syntaxique abstrait ; Génération, à partir dudit arbre syntaxique abstrait, de deuxièmes instructions en un langage de programmation orienté objet distinct d’un langage d’exploitation de ladite base de données ; Exécution desdites deuxièmes instructions dans une machine virtuelle mise en œuvre par les moyens de traitement de données de sorte à réaliser ledit traitement analytique souhaité, comprenant le déclenchement de requêtes sur ladite base de données dans ledit langage d’exploitation de la base de données, ladite machine virtuelle utilisant un noyau objet d’interface avec ladite base de données. Selon des caractéristiques avantageuses et non limitatives : Lesdites deuxièmes instructions sont une transcription des premières instructions dans ledit langage de programmation orienté objet. L’étape (b) est mise en œuvre par un analyseur syntaxique non déterministe. Ledit analyseur syntaxique non déterministe utilise l’algorithme d’Earley, l’algorithme CYK ou l’algorithme GLR. L’étape (b) comprend, si l’analyseur syntaxique soulève une ambiguïté des premières instructions, la génération d’une pluralité d’arbres syntaxiques abstraits, chacun étant une traduction possible desdites premières instructions, l’étape (c) comprend la génération, à partir de chaque arbre syntaxique abstrait, d’un jeu de deuxièmes instructions en ledit langage de programmation orienté objet ; et l’étape (d) comprend une vérification de la validité de chaque jeu de deuxièmes instructions, et l’exécution du seul jeu de deuxièmes instructions valide dans ladite machine virtuelle. Les premières instructions sont traduites à l’étape (b) en un premier arbre syntaxique abstrait, l’étape (c) comprenant la transformation du premier arbre syntaxique abstrait en un deuxième arbre syntaxique abstrait, ledit deuxième arbre syntaxique abstrait étant un arbre d’objets dudit langage de programmation orienté objet, exprimant lesdites deuxièmes instructions. Ledit langage de programmation orienté objet est dérivé de Python® ou C++, et ledit langage d’exploitation de la base de données est choisi parmi Python®, Lisp, SQL ou PowerQuery. L’étape (d) comprend la résolution préalable des identifiants et/ou des types des données de ladite base de données concernées par les deuxièmes instructions, pour générer lesdites requêtes sur la base de données. L’étape (d) comprend la fourniture audit terminal client de données de sortie relatives au résultat dudit traitement analytique souhaité. Le procédé comprend en outre une étape préalable (a0) de configuration de la machine virtuelle et/ou d’un analyseur syntaxique pour la mise en œuvre de l’étape (b) par un module d’intégration externe. Selon un deuxième aspect, l’invention concerne un serveur, dit deuxième serveur, caractérisé en ce qu’il comprend des moyens de traitement de données configurés pour : Obtenir depuis un terminal client des premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données d’un premier serveur ; Traduire lesdites premières instructions en un arbre syntaxique abstrait ; Générer, à partir dudit arbre syntaxique abstrait, des deuxièmes instructions en un langage de programmation orienté objet distinct d’un langage d’exploitation de ladite base de données ; Exécuter lesdites deuxièmes instructions dans une machine virtuelle mise en œuvre par les moyens de traitement de données de sorte à réaliser ledit traitement analytique souhaité, comprenant le déclenchement de requêtes dans ledit langage d’exploitation de ladite base de données, ladite machine virtuelle utilisant un noyau objet d’interface avec ladite base de données. Selon un troisième aspect, l’invention concerne un système comprenant le deuxième serveur selon le deuxième aspect, ledit premier serveur et le terminal connectés. Selon un quatrième et un cinquième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données d’un premier serveur ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données d’un premier serveur. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : [Fig. 1]la [Fig. 1] est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ; [Fig. 2]la [Fig. 2] représente schématiquement l’architecture générale des blocs dans un mode de réalisation du procédé selon l’invention ; [Fig. 3]la [Fig. 3] est un logigramme illustrant les étapes d’un mode de réalisation du procédé selon l’invention ; [Fig. 4a]la [Fig. 4a] représente un exemple de premier AST ; [Fig. 4b]la [Fig. 4b] représente un exemple de deuxième AST obtenu à partir du premier AST de la [Fig. 4a] ; [Fig. 5a]la [Fig. 5a] représente schématiquement un bloc traducteur KNIL dans un mode de réalisation du procédé selon l’invention ; [Fig. 5b]la [Fig. 5b] représente schématiquement un bloc retro-traducteur KINL dans un mode de réalisation du procédé selon l’invention ; [Fig. 6]la [Fig. 6] représente schématiquement un bloc machine KVM dans un mode de réalisation du procédé selon l’invention ; [Fig. 7]la [Fig. 7] représente schématiquement un bloc noyau KOK dans un mode de réalisation du procédé selon l’invention ; [Fig. 8]la [Fig. 8] représente schématiquement un bloc intégrateur KEMI dans un mode de réalisation du procédé selon l’invention ; DESCRIPTION DÉTAILLÉE Architecture La présente invention concerne un procédé d’exécution de premières instructions en langage naturel relatives à un traitement des données d’une base de données, mis en œuvre dans un environnement tel que représenté par la [Fig. 1]. Ladite base de données peut être toute base de données structurée stockée sur des moyens de stockage de données 12 d’un premier serveur 1, typiquement une base de données métier stockée sur un serveur 1 d’une entreprise. Elle peut être constituée de chaines de caractères, nombres, dates, durées, booléens, tables, listes, dictionnaires, etc. Par traitement analytique des données de la base de données, on entend toute opération sur les informations issues de la base de données à des fins d’analyse, typiquement jointures et/ou calculs, potentiellement complexe. Par exemple on peut souhaiter le total des commandes d’un client particulier, le traitement consistant alors à identifier toutes les commandes dudit client dans la base, extraire les montants correspondants, et les sommer. Dans la suite de la présente description on prendra l’exemple plus complexe suivant « Sélectionner les 10% de lignes de commandes dont la quantité est la plus grande, parmi celles dont le prix est supérieur à 100. ». On distinguera ledit traitement analytique de la simple gestion de la base de données (lecture/écriture), bien que le traitement analytique des données implique évidemment l’accès à ces données. Pour reformuler, le présent traitement analytique porte bien sur les données en elles-mêmes, et pas sur la base de données. On suppose qu’on a un langage d’exploitation de ladite base de données, i.e. un langage exécutable par des moyens de traitement de données 11 dudit premier serveur 1 pour mettre en œuvre nativement des traitements des données de ladite base de données, par exemple Python® dans la suite de la présente description, ou encore SQL, Lisp, PowerQuery, etc. Le présent procédé est spécifique en ce que les premières instructions relatives à un traitement analytique souhaité des données d’une base de données (i.e. décrivant ce traitement souhaité), sont en langage naturel, noté KNL, c’est-à-dire la langue « normale » parlée par un être humain et non un langage de programmation structuré, a fortiori pas ledit langage d’exploitation de la base de données. Le langage naturel s’écrit quasiment sans apprentissage préalable, contrairement à tous les langages informatiques, et est « auto-documenté ». Comme l’on expliquera plus loin, pour que le présent fonctionne il suffit que les premières instructions : utilisent des mots ou expressions communes et qui ont une signification claire et unique pour l’utilisateur : Un verbe pour une action Un adjectif pour une valeur modifiée Un substantif pour une nouvelle valeur obtenue par transformation d’une valeur existante Les comportements des verbes sont précisés par des compléments, conformément à la grammaire usuelle. Inversement, qu’un concept utilisateur corresponde à un seul mot ou expression (aux synonymes près) pour éviter toute ambiguïté, mais la syntaxe est la plus souple possible (Les compléments circonstanciels peuvent apparaître dans n’importe quel ordre) Pas besoin de règles de gestion, on peut simplement utiliser « si…alors…sinon », le cas échéant de manière imbriquée Aucune déclaration de type, les types sont déterminés et vérifiés automatiquement. On verra plus loin comment cela est accompli. Comme représenté sur la [Fig. 1], on a en outre un deuxième serveur 2 d’exécution dudit procédé, et un terminal client 10 tel qu’un poste de travail ou un smartphone, présentant une interface et via lequel l’utilisateur va pouvoir interagir. On comprend que le deuxième serveur 2 est connecté au terminal client 10 et au premier serveur 1, par exemple via un réseau 20 tel que le réseau internet. Le deuxième serveur 2 comprend également des moyens de traitement de données 21 tel qu’un processeur de toute nature, et des moyens de stockage de données 22, i.e. une mémoire. A noter que le deuxième serveur 2 peut être confondu avec le terminal client 10 ou avec le premier serveur 1. Principe En référence à la [Fig. 2], le présent procédé utilise astucieusement le passage par un langage de programmation orienté objet « interne », distinct du langage d’exploitation de ladite base de données, et exécuté par une machine virtuelle implémentant un noyau faisant le lien avec ledit langage d’exploitation de ladite base de données. Il est dit interne puisqu’il n’est visible ni de l’utilisateur ni de la base de données et fonctionne de manière agnostique, et l’utilisateur n’a ainsi pas besoin d’en connaître la syntaxe. Ce langage orienté objet, noté KIL, est un miroir exécutable et syntaxiquement vérifié du langage naturel. Comme tout langage, il implémente des règles if-then-else, des systèmes d’adressages, boucles explicites ou implicites, etc. Comme expliqué, il n’a pas besoin d’être compris par l’utilisateur. Il s’agit préférentiellement d’un langage entièrement orienté objet, ce qui signifie que tout est objet, les données comme les fonctions. Chaque objet peut contenir des objets, et tous ces objets héritent de classes fondamentales. C’est cet aspect qui va permettre aisément de manière garantie l’obtention de deuxièmes instructions pour toutes premières instructions sémantiquement correctes (i.e. ayant un sens et non-ambiguës), tout en faisant l’interface avec un langage existant (et donc prédéfini) d’exploitation de la base de données. Ce langage orienté objet est haut niveau, et peut être dérivé de langages orientés objet existants tels que Python® ou C++ (i.e. présenter le même style d’expression), l’homme du métier saura définir un tel langage en partant desdites classes fondamentales et en utilisant des bibliothèques existantes. Les classes fondamentales désignent les concepts élémentaires d’un traitement de données, un faible nombre suffit, et l’homme du métier saura définir un ensemble de casses fondamentales permettant d’exprimer toutes instructions représentatif d’un traitement analytiques des données d’une base de données. Par exemple, une classe fondamentale principale « expression » désigne tous les objets dont sont constituées des expressions mathématiques au sens large, et on peut avoir les sous-classes « constante » (opérande prédéfini), « opérateur binaire » (opération à 2 opérandes), « opérateur unaire » (opération à 1 opérande), « fonction » (toute fonction applicable), avec « constante » ayant les sous-classes « booléen », « chaîne », « Nombre », « manquant » (si le type est manquant), etc. De manière schématisée, on peut avoir par exemple l’arbre d’héritage suivant de la classe fondamentale « expression », les sous-classes se comprenant intuitivement : Expression _ Constant Booleen Chaine Nombre Manquant _OperateurBinaire OpAddition OpSoustraction OpMultiplication OpSuperieurA OpEgalA _OperateurUnaire OpMoins OpNon OpAucun _Fn _FnListee AppelFnSansArg (*1) AppelArgFn AppelFnArg(*3) _FnComposeeListee AppelFnComposeeSansArg (*2) AppelArgFnComposee AppelFnComposeeArg (*4) _FnSansArg AppelFnSansArg (*1) AppelFnComposeeSansArg (*2) _FnArg AppelFnArg (*3) AppelFnComposeeArg (*4) (*1): AppelFnSansArg est en même temps sous classe de _FnListee et de _ FnSansArg. Elle bénéficie d’un mécanisme d’héritage multiple. (*2) (*3) et (*4) relèvent de la même logique. Similairement, de manière schématisée, on peut avoir par exemple l’arbre d’héritage suivant de la classe fondamentale « phrase » (qui désigne tous les objets dont sont constituées des parties textuelles de la requête n’étant pas des expressions), les sous-classes se comprenant intuitivement : _Phrase DefinitionFn Regle Affectation AffectationDVersG AffectationGversD Boucle _AppelProcedureSeche TStop TChrono TReset AppelProcedureCods Procédé On voit un certain nombre de blocs dudit procédé, ou composants, dans la [Fig. 2], qui vont décrits plus en détail. En référence à la [Fig. 3], le présent procédé commence par une étape (a) d’obtention desdites premières instructions (en langage naturel) depuis le terminal client 10. Lesdites premières instructions peuvent être directement saisies par l’utilisateur sur une interface du terminal 10, l’utilisateur ayant en tête le traitement qu’il souhaite accomplir et se contenant de l’écrire (le langage naturel fait que le prototype = la spécification, de sorte que les premières instructions sont « exécutables en production »), ou bien on pourra réutiliser des premières instructions déjà écrites pour le même traitement analytique souhaité, l’utilisateur se contenant de les réutiliser (par exemple pour un traitement qui serait demandé à chaque mois). Dans l’exemple évoqué précédemment, on peut se contenter de saisir « Sélectionner les 10% de lignes de commandes dont la quantité est la plus grande, parmi celles dont le prix est supérieur à 100 », i.e. de décrire littéralement le traitement souhaité. On voit que de telles premières instructions sont sémantiquement correctes, i.e. elles ont un sens et ne sont pas ambiguës. Le procédé comprend ensuite une étape de traduction desdites instructions en un arbre syntaxique abstrait. Par arbre syntaxique abstrait, ou AST, on entend un arbre (graphe acyclique orienté) dont les nœuds internes sont marqués par des opérateurs et dont les feuilles (ou nœuds externes) représentent les opérandes de ces opérateurs. Autrement dit, généralement, une feuille est une variable ou une constante. Un AST constitue la représentation intermédiaire interne des premières instructions. Alors, dans une étape (c), le procédé comprend la génération, à partir dudit arbre syntaxique abstrait, de deuxièmes instructions en ledit langage de programmation orienté objet distinct du langage d’exploitation de ladite base de données. En particulier, il s’agit de la transformation de la structure arborescente de l’AST en expressions KIL, l’ensemble constituant lesdites deuxièmes instructions. Pour reformuler, les deuxièmes instructions correspondent aux premières instructions transcrites dans ledit langage de programmation orienté objet (i.e. les deuxièmes instructions sont relatives au même traitement de la base de données que les premières instructions). En pratique on a avantageusement deux AST successifs : le premier AST (dit AST KNL), obtenu à l’issue de l’étape (b), par analyse syntaxique, puis un deuxième AST (dit AST KIL), correspondant à la transformation du premier AST en arbre d’objets dudit langage de programmation orienté objet (i.e. les feuilles et nœuds du deuxième AST sont des objets dudit langage de programmation orienté objet), constituant en pratique lesdites deuxièmes instructions. Cela est rendu possible par le caractère entièrement orienté objet du langage. En d’autres termes, les deuxièmes instructions peuvent être exprimées sous la forme d’un deuxième AST spécifique audit langage de programmation orienté objet. Les deux AST ont la même structure globale, il s’agit juste d’une traduction en fonction de règles simples. On considère que le deuxième AST peut constituer les deuxièmes instructions, car l’AST KIL est une représentation directe des appels d’objets dudit langage de programmation orienté objet. On comprend ainsi clairement l’intérêt de passer par ledit langage de programmation même de manière complètement interne. Dans l’exemple des premières instructions « Sélectionner les 10% de lignes de commandes dont la quantité est la plus grande, parmi celles dont le prix est supérieur à 100. », on obtient un premier AST tel que représenté par la [Fig. 4a]. On remarque que les feuilles désignent les unités sémantiques des premières instructions, et donc les opérandes (10, %, commandes, quantité, prix, 100). On transforme alors ce premier AST en le deuxième AST visible sur la [Fig. 4b], et ainsi : SelectionnerNtac_1 est un objet de classe SelectionnerNtac SelectionnerNtac_1 contient d’autres objets (Nombre_1, Id_1, AvecPlus_1, OpSuperieurA_1) dont les classes sont obtenues en enlevant le numéro d’ordre le plus à droite. De même AvecPlus_1 contient ID_2 et OpSuperieurA_1 contient Id_3 et Nombre_2 Comme expliqué, l’AST KIL obtenu est l’exacte représentation des appels des objets KIL, et peut donc être exécuté, voir plus loin. Les étapes (b) et (c) sont mise en œuvre au sein du bloc « Traducteur KNIL » (pour Natural vers Internal) visible dans la [Fig. 2]. On comprend que les AST et la génération automatique de code à partir d’AST sont connus de l’homme du métier. En revanche la traduction de langage naturel en AST est bien plus inhabituelle. A ce titre, et en référence à la [Fig. 5a] (qui représente plus en détail le bloc Traducteur KNIL), l’étape (b) est avantageusement mise en œuvre par un analyseur syntaxique non déterministe. L’AST est alors une description sous forme d’arbre des éléments de syntaxe reconnus par l’analyseur syntaxique. En effet, dans le cadre de premières instructions en langage naturel, le rôle de certains mots ne peut être déterminé qu’en lisant les mots suivants et non statiquement par un automate à états, d’où le caractère non déterministe de l’analyseur syntaxique. On pourra utiliser comme méthode d’analyse non déterministe (dans l’analyseur) l’algorithme d’Earley, l’algorithme CYK (Cocke-Younger-Kasami) ou l’algorithme GLR (Generalized Left-to-right Rightmost derivation), qui peuvent analyser n’importe quelle grammaire non contextuelle en un temps raisonnable (polynomial) plutôt que, par exemple, LALR (Look-Ahead Left-to-right Rightmost derivation) habituellement utilisé dans les analyseurs connus car suffisant pour des langages informatiques moins complexes que du langage naturel et plus rapide. Un exemple de grammaire non reconnue par un algorithme LALR(1) et reconnue par Earley est la grammaire suivante: S -> b A c | b d a A -> d Cette grammaire n’est pas compréhensible par LALR car il y a un conflit de réduction/décalage à la lecture de la phrase « b d a ». En effet une fois le début de phrase « b » lu, il doit lire « d ». LALR se trouve dans un état où il ne sait pas s’il doit réduire « A -> d » ou s’il est au milieu de « s -> b d a ». En revanche, l’algorithme d’Earley peut gérer ce conflit en explorant toutes les possibilités. Il se rendra compte que seul « S -> b d a » est possible en regardant plus loin dans la phrase. L’analyseur non déterministe peut être préconstruit, appris en utilisant des algorithmes d’intelligence artificielle, et/ou en utilisant des bibliothèques de grammaire/vocabulaire spécifiques à la langue (afin de prendre en compte les accords, les temps, les idiomes, etc.), mais également de grammaire commune à tout ou partie des langages (un certain nombre de descriptions syntaxiques sont factorisées : adressage des tables, écritures des nombres entiers, chaines de caractères, éléments de ponctuation, etc.) Si l’analyse syntaxique (et la construction de l’AST) est impossible car les premières instructions n’ont pas de sens grammatical (« erreur de syntaxe ») un message d’erreur est renvoyé à l’utilisateur. Par ailleurs, il peut y avoir plusieurs (premiers) AST, i.e. une « forêt » d’AST, en cas de premières instructions ambiguës. Pour reformuler, dans le cas où une ambiguïté des premières instructions ne peut être levée statiquement, on génère avantageusement l’ensemble des AST possibles (forêt), et pour chaque AST on met en œuvre l’étape (c) de sorte à générer pour chaque AST un « jeu » de deuxièmes instructions, et on verra plus loin comme se passe l’exécution d’une telle forêt d’AST. Dans le cas préféré de deuxièmes instructions sous forme d’AST KIL, chaque premier AST et traduit en un deuxième AST. De manière préférée, on a un bloc symétrique du traducteur KNIL dit « retro-traducteur KINL » (pour Internal vers Natural) qui permet optionnellement de regénérer des troisièmes instructions en langage naturel à partir des deuxièmes instructions dans le langage orienté objet. Pour reformuler, les troisièmes instructions correspondent aux deuxièmes instructions transcrites en langage naturel (i.e. les troisièmes instructions sont relatives au même traitement de la base de données que les deuxièmes instructions). On comprend que les troisièmes instructions sont une reformulation des premières instructions. L’intérêt est que les troisièmes instructions sont généralement optimisées (plus simples) par rapport aux premières instructions, et potentiellement dans une autre langue, ce qui permet de partager les premières instructions, pour la mise en œuvre répétée du même traitement y compris dans un environnement international. Plus précisément, en référence à la [Fig. 5b] (qui représente plus en détail le bloc Rétro-traducteur KINL), les instructions d’un programme KIL sont typiquement des objets qui héritent de méthodes d’un module objet de retro-traduction. Ces méthodes produisent le texte en langage naturel à partir des propriétés des instructions KIL et des descriptions syntaxiques, soit spécifique à la langue (à noter le bloc de vocabulaire peut être commun avec le Traducteur KNIL), soit commune à tous les langages. Le formatage final (pretty-printer) permet d’obtenir un texte facilement lisible (indentations, espaces, ponctuations, articles, etc.). Dans une étape (d) principale, lesdites deuxièmes instructions sont exécutées dans une machine virtuelle mise en œuvre par les moyens de traitement de données 21, notée Machine KVM. La machine virtuelle permet d’interpréter le langage KIL des secondes instructions de manière totalement transparente pour l’utilisateur, indépendamment du matériel. En effet, ce langage étant interne, il n’est pas nativement exécutable par le système d’exploitation du deuxième serveur 1. La communication avec le matériel (dont le premier serveur 1 et ses composants) est simplement réalisée par un noyau objet d’interface avec ladite base de données, ou Kernel, noté Noyau KOK. Plus précisément, ledit noyau fait le lien entre la machine virtuelle et le langage d’exploitation, et permet en pratique le traitement de la base de données. En référence à la [Fig. 6], qui représente la machine virtuelle, l’étape (d) comprend avantageusement une vérification de la validité des deuxièmes instructions, en particulier en cas de forêt d’AST (et donc la vérification de la validité de chaque jeu de deuxièmes instructions). L’étape (d) comprend lors l’exécution du seul jeu d’instruction valide dans ladite machine virtuelle. Plus précisément, il y a exécution si et seulement si un seul jeu de deuxièmes instructions est valide : Si aucun n’est valide, il n’y a rien à exécuter et on renvoie un message d’erreur ; S’il y a plusieurs jeux valides c’est qu’il y a plusieurs AST corrects et donc un problème insurmontable d’ambigüité, et on renvoie un message d’erreur. Au contraire, s’il y a un seul jeu de deuxièmes instructions valide, c’est bien qu’on a pu résoudre l’ambigüité, et on exécute les deuxièmes instructions du seul jeu valide. A ce titre, l’étape (d) comprend préférentiellement la résolution préalable des identifiants et/ou des types des données de ladite base de données concernées par les deuxièmes instructions, c’est-à-dire les données de ladite base de données impliquées par le traitement auquel les premières instructions sont relatives. Si on y parvient, alors le jeu de deuxièmes instructions est valide, et sinon c’est qu’il est invalide. Les identifiants sont soit des noms de variables, soit des noms de colonnes, soit des noms de fonctions. Les identifiants permettent aussi l’indirection: un nom de variable qui contient un identifiant. Cette résolution est dite dynamique puisqu’à la volée : les identifiants n’ont pas besoin d’être déclarés. On peut utiliser pour cela un bloc de gestion des portées lexicales des variables qui permet la définition dynamique de fonctions (y compris des fonctions récursives). Les types de données sont également déterminés dynamiquement, de manière connue. A noter qu’on peut vérifier dynamiquement la cohérence des identifiants/types déterminés : Si tout est cohérent (validité confirmée) on passe à l’exécution à proprement parler (s’il y a bien un seul jeu de deuxièmes instructions valides) Si non soit on réessaye de résoudre, soit on renvoie un message d’erreur (en particulier s’il n’y a plus d’autres identifiants/types possibles), visant à guider l’utilisateur. L’exécution des deuxièmes instructions comprend le déclenchement de requêtes dans ledit langage d’exploitation de ladite base de données conformément auxdites deuxièmes instructions, et généralement des opérations sur les données obtenues grâce auxdites requêtes, de sorte à accomplir ledit traitement désiré. On comprend que de telles requêtes sont connues puisque ledit langage d’exploitation de ladite base de données est connu. De plus ces requêtes sont « bas niveau » par opposition aux deuxièmes instructions qui sont « haut niveau ». Ladite exécution utilise avantageusement d’une part des interfaces de fonctions externes (dynamique ou statique) en particulier dans un but collaboratif, et d’autre part un bloc de contrôle définissant en pratique un ordre de déclenchement desdites requêtes, sur la base éventuellement de règles de gestions (elle-même par exemple déclenchées pour chaque ligne d’un tableau) et/ou d’un moteur d’inférence (en particulier en chaînage avant) permet de décider dynamiquement de l’ordre de déclenchement. De manière particulièrement préférée, dans le cas d’un deuxième AST exprimant les deuxièmes instructions, l’exécution des deuxièmes instructions est en pratique l’appel de la méthode « eval » de l’objet racine (SelectionnerNtax_1 dans la [Fig. 4b]), et de manière récursive, l’appel de la méthode eval d’un objet: appelle (si besoin) les méthodes eval des objets contenus. vérifie le type des objets contenus et envoie éventuellement un message d’erreur. vérifie la cohérence de la demande (par exemple l’existence d’une colonne dans une table. Ici : prix dans la table commandes) et envoie éventuellement un message d’avertissement ou d’erreur. effectue le traitement souhaité (ici: une sélection dont les paramètres sont les résultats des évaluations des objets contenus ou les objets contenus eux-mêmes selon les cas). retourne le résultat. Dans le cas d’une forêt d’AST, la méthode eval est appelée pour chaque AST mais exécute seulement les étapes 1 à 3 (vérification dynamique de la validité de l’AST). Si aucun AST n’est valide, on retourne une erreur. Si un seul AST est valide, on continue l’exécution de la méthode eval sur cet AST (étapes 4 et 5). Si plus d’un AST sont valides, on retourne une erreur. Le résultat de l’exécution des deuxièmes instructions à l’étape (d), i.e. les données renvoyées en sortie, ce que l’on appelle la trace d’exécution, est fourni en réponse, par exemple affiché par le terminal 10. On comprend que lesdites données de sortie sont relatives au résultat dudit traitement de la base de données Ainsi, cela permet de formaliser le résultat du traitement d’une base de données désiré, par exemple sous la forme d’un rapport. On note que l’exécution peut en outre comprendre l’émission de messages informatifs représentatifs d’éventuelles anomalies de la base de données. En complément, la [Fig. 7] représente le Noyau KOK. Comme tout noyau, il fournit des mécanismes d’abstraction du matériel et facilite la communication entre les processus. Partant d’éléments d’architecture normalisée (Définition de l’architecture objet de l’ensemble du code : classes de base et comportements communs), le noyau définit : Les structures de données de ladite base, ainsi que les manipulations élémentaires ; Les connecteurs avec ladite base de données + les différents formats de fichier ainsi que les codages de chaines de caractères pour lecture et écriture de fichiers de données ; Les routines d’impression (terminal, fichier texte, etc. en particulier vers gestionnaire HTML pour produire lesdits rapports) ; Un utilitaire de traduction Toutes les fonctionnalités élémentaires utiles ponctuellement : envoi de mail, web scraping, accès à l’horloge interne, etc. en couche supérieure dudit noyau, les classes fondamentales d’objets évaluables : tous les objets utilisés dans le code implémentant ledit procédé, y compris les instructions de la machine virtuelle sont des objets dont la classe hérite de classes fondamentales définies dans ce composant. Selon un mode de réalisation préféré, le procédé comprend une étape préalable (a0) de configuration de la machine virtuelle et/ou de l’analyseur syntaxique par un module d’intégration externe, dit Intégrateur KEMI. L’idée est de pouvoir enrichir de manière très facile ledit procédé, et ce sans modifier le code central. Le module est typiquement connecté à d’autres terminaux. En référence à la [Fig. 8], ledit Intégrateur KEMI est capable d’intégrer les fonctions de modules externes en modifiant/ajoutant respectivement les blocs de description syntaxique/vocabulaire spécifique à la langue du traducteur KNIL et d’interface statique de la machine virtuelle (Les fonctions sont intégrées à la machine virtuelle grâce au typage dynamique et à une interface normalisée d’appel et de passage de paramètres). A noter qu’on peut partir de prototypes de modules externes, permettant l’intégration rapide et homogène de fonctions isolées ou de modules entiers de fonctions Serveur Selon un deuxième aspect, l’invention concerne le deuxième serveur 2 pour la mise en œuvre du procédé selon le premier aspect. Il comprend des moyens de traitement de données 21, des moyens de stockage de données 22 et est connecté au premier serveur 1 et au terminal 10. Les moyens de traitement de données 21 sont configurés pour : Obtenir depuis le terminal client 10 des premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données 12 du premier serveur 1 ; Traduire lesdites premières instructions en un arbre syntaxique abstrait ; Générer, à partir dudit arbre syntaxique abstrait, des deuxièmes instructions en un langage de programmation orienté objet distinct d’un langage d’exploitation de ladite base de données ; Exécuter lesdites deuxièmes instructions dans une machine virtuelle mise en œuvre par les moyens de traitement de données 21 de sorte à réaliser ledit traitement analytique souhaité, comprenant le déclenchement de requêtes dans ledit langage d’exploitation de ladite base de données, ladite machine virtuelle utilisant un noyau objet d’interface avec ladite base de données. Les moyens 21 peuvent en outre être configurés pour générer des données de sortie en langage naturel relatives au résultat dudit traitement analytique souhaité ; et/ou configurer la machine virtuelle et/ou un analyseur syntaxique pour la mise en œuvre de l’étape (b) via un module d’intégration externe (potentiellement connecté à d’autres terminaux). Selon un troisième aspect, l’invention propose un système comprenant le deuxième serveur 2, le premier serveur 1, et le terminal 10, connectés (en particulier via un réseau 20 tel que Internet, les différents équipements pouvant être confondus). Produit programme d’ordinateur Selon un quatrième et un cinquième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 21 du deuxième serveur 2) d’un procédé selon le premier aspect d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données 12 d’un premier serveur(1, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les moyens de stockage de données 22 du deuxième serveur 2) sur lequel on trouve ce produit programme d’ordinateur. Procédé d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données (12) d’un premier serveur (1), caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (21) d’un deuxième serveur (2) : Obtention desdites premières instructions depuis un terminal client (10) ; Traduction desdites premières instructions en un arbre syntaxique abstrait ; Génération, à partir dudit arbre syntaxique abstrait, de deuxièmes instructions en un langage de programmation orienté objet distinct d’un langage d’exploitation de ladite base de données ; Exécution desdites deuxièmes instructions dans une machine virtuelle mise en œuvre par les moyens de traitement de données (21) de sorte à réaliser ledit traitement analytique souhaité, comprenant le déclenchement de requêtes sur ladite base de données dans ledit langage d’exploitation de la base de données, ladite machine virtuelle utilisant un noyau objet d’interface avec ladite base de données. Procédé selon la revendication 1, dans lequel lesdites deuxièmes instructions sont une transcription des premières instructions dans ledit langage de programmation orienté objet. Procédé selon l’une des revendications 1 et 2, dans lequel l’étape (b) est mise en œuvre par un analyseur syntaxique non déterministe. Procédé selon la revendication 3, dans lequel ledit analyseur syntaxique non déterministe utilise l’algorithme d’Earley, l’algorithme CYK ou l’algorithme GLR. Procédé selon l’une des revendications 3 et 4, dans lequel l’étape (b) comprend, si l’analyseur syntaxique soulève une ambiguïté des premières instructions, la génération d’une pluralité d’arbres syntaxiques abstraits, chacun étant une traduction possible desdites premières instructions, l’étape (c) comprend la génération, à partir de chaque arbre syntaxique abstrait, d’un jeu de deuxièmes instructions en ledit langage de programmation orienté objet ; et l’étape (d) comprend une vérification de la validité de chaque jeu de deuxièmes instructions, et l’exécution du seul jeu de deuxièmes instructions valide dans ladite machine virtuelle. Procédé selon l’une des revendications 1 à 5, dans lequel les premières instructions sont traduites à l’étape (b) en un premier arbre syntaxique abstrait, l’étape (c) comprenant la transformation du premier arbre syntaxique abstrait en un deuxième arbre syntaxique abstrait, ledit deuxième arbre syntaxique abstrait étant un arbre d’objets dudit langage de programmation orienté objet, exprimant lesdites deuxièmes instructions. Procédé selon l’une des revendications 1 à 6, dans lequel ledit langage de programmation orienté objet est dérivé de Python® ou C++, et ledit langage d’exploitation de la base de données est choisi parmi Python®, Lisp, SQL ou PowerQuery. Procédé selon l’une des revendications 1 à 7, dans lequel l’étape (d) comprend la résolution préalable des identifiants et/ou des types des données de ladite base de données concernées par les deuxièmes instructions, pour générer lesdites requêtes sur la base de données. Procédé selon l’une des revendications 1 à 8, dans lequel l’étape (d) comprend la fourniture audit terminal client (10) de données de sortie relatives au résultat dudit traitement analytique souhaité. Procédé selon l’une des revendications 1 à 9, comprenant en outre une étape préalable (a0) de configuration de la machine virtuelle et/ou d’un analyseur syntaxique pour la mise en œuvre de l’étape (b) par un module d’intégration externe. Serveur (2), dit deuxième serveur, caractérisé en ce qu’il comprend des moyens de traitement de données (21) configurés pour : Obtenir depuis un terminal client (10) des premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données (12) d’un premier serveur (1) ; Traduire lesdites premières instructions en un arbre syntaxique abstrait ; Générer, à partir dudit arbre syntaxique abstrait, des deuxièmes instructions en un langage de programmation orienté objet distinct d’un langage d’exploitation de ladite base de données ; Exécuter lesdites deuxièmes instructions dans une machine virtuelle mise en œuvre par les moyens de traitement de données (21) de sorte à réaliser ledit traitement analytique souhaité, comprenant le déclenchement de requêtes dans ledit langage d’exploitation de ladite base de données, ladite machine virtuelle utilisant un noyau objet d’interface avec ladite base de données. Système comprenant le deuxième serveur (2) selon la revendication 11, ledit premier serveur (1) et le terminal (10) connectés. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données (12) d’un premier serveur (1), lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données stockée sur des moyens de stockage de données (12) d’un premier serveur (1).