FR 3159458 A1 20250822 FR 2401547 A 20240216 La présente invention concerne un procédé de traitement automatique d’un document stocké par un deuxième serveur (2), conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document, le procédé comprenant la mise en œuvre, par un premier serveur (1), d’étapes de : Obtention de ladite au moins une commande utilisateur en langage naturel et d’un identifiant dudit document ; Transmission audit deuxième serveur (2) d’une requête d’au moins une partie dudit document sous forme d’un fichier texte, ladite requête comprenant ledit identifiant obtenu, et réception en retour dudit fichier texte, Mise en œuvre d’une requête textuelle de traitement du document, dite requête textuelle principale, par un modèle de langage génératif, ladite requête textuelle principale comprenant : La commande utilisateur ; Le contenu dudit fichier texte ; Restitution d’une réponse textuelle à ladite requête textuelle principale. Fig 1. Procédé de traitement automatique d’un document conformément à une commande en langage naturel. DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine de l’intelligence artificielle. Plus précisément, elle concerne un procédé de traitement automatique d’un document conformément à une commande en langage naturel. ETAT DE L’ART L’intelligence artificielle et notamment les modèles de langage génératifs de type grand modèle de langage (LLM, pour Large Language Model) permet aujourd’hui d’obtenir en quelques secondes le traitement d’une donnée textuelle et notamment la réponse à des questions. Une application visée est notamment l’analyse automatisée de documents d’état de la technique telles que des publications scientifiques ou des demandes de brevet publiées, pour par exemple savoir si ces documents divulguent une caractéristique donnée. Le problème principal est celui de l’accès par les LLM à ces documents, dans la mesure où les données sur lesquelles les LLM ont été entraînées ne les inclut pas, et donc que leur contenu est inconnu. Certains serveurs implémentant des LLM permettent un accès à internet, mais c’est en pratique insuffisant au LLM pour trouver le document et identifier son contenu même s’il est publié en ligne (par exemple sur Espacenet). Par exemple, si je demande à ChatGPT l’analyse d’une demande de brevet, il reconnait que le document visé est une demande de brevet mais m’invite à « consulter la base de données européenne des brevets ou d’autres sources similaires en ligne ». Certains LLM sont capable d’accepter en entrée un PDF (sur lequel ils vont mettre en œuvre une technique de reconnaissance optique de caractère, dite OCR). On peut donc, si l’on souhaite analyser un document d’état de la technique, aller télécharger manuellement son PDF et le téléverser sur le serveur implémentant un LLM de ce type afin de poser des questions. Outre le fait qu’une telle manipulation est fastidieuse, on constate que les documents sous format PDF et notamment les publications de demandes de brevet ont une mise en forme complexe (plusieurs colonnes, des pages de d’en-tête), des figures, etc., qui perturbent un LLM, de sorte que le résultat est mauvais. L’invention vient améliorer la situation. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé de traitement automatique d’un document stocké par un deuxième serveur, conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données d’un premier serveur connecté au deuxième serveur par un réseau de communication, d’étapes de : Obtention de ladite au moins une commande utilisateur en langage naturel et d’un identifiant dudit document, depuis une interface utilisateur ; Transmission audit deuxième serveur d’une requête d’au moins une partie dudit document sous forme d’un fichier texte, ladite requête comprenant ledit identifiant obtenu, et réception en retour dudit fichier texte ; Mise en œuvre d’une requête textuelle de traitement du document, dite requête textuelle principale, par un modèle de langage génératif, ladite requête textuelle principale comprenant : La commande utilisateur ; Le contenu dudit fichier texte ; Restitution, par ladite interface utilisateur, d’une réponse textuelle à ladite requête textuelle principale. Selon des caractéristiques avantageuses et non limitatives : Ledit modèle de langage génératif est implémenté par un troisième serveur connecté au premier serveur par ledit réseau de communication, l’étape (c) comprenant la transmission de ladite requête textuelle au troisième serveur, et la réception en retour de ladite réponse textuelle. Ladite requête textuelle principale comprend en outre une phrase définissant que l’action souhaitée du modèle de langage génératif est le traitement conformément à la commande utilisateur du contenu du fichier texte, la commande utilisateur étant désignée par un premier identifiant, le contenu dudit fichier texte étant désigné par un deuxième identifiant, et les premiers et deuxième identifiants étant repris dans ladite phrase. Ladite requête textuelle est de la forme : « P(I1 ; I2) I1 : CU I2 : DOC » Où I1 et I2 sont les premiers identifiants ; P(I1 ; I2) ladite phrase définissant l’action souhaitée du modèle de langage génératif et reprenant les identifiants I1 et I2 ; DOC le texte contenu dans le fichier texte, et CU la commande utilisateur. L’étape (a) comprend la saisie par l’utilisateur d’une part dudit identifiant et d’autre part de ladite commande utilisateur en langage naturel. Ladite commande utilisateur contient ledit identifiant, l’étape (a) comprenant l’extraction de l’identifiant du document dans ladite commande utilisateur. L’étape (a) comprend la mise en œuvre d’une requête textuelle de pré-traitement de ladite commande utilisateur textuelle, dite requête textuelle préliminaire, par ledit modèle de langage génératif, de sorte à extraire ledit identifiant. Ladite requête préliminaire est une requête de transcription de ladite commande utilisateur textuelle, par ledit modèle de langage génératif, en un fichier structuré contenant : - ledit identifiant du document ; - une version générique de ladite commande utilisateur ne contenant plus ledit identifiant ; - Optionnellement, une désignation d’une partie cible du document à traiter ; Ladite requête textuelle principale mise en œuvre à l’étape (c) comprend ladite version générique plutôt que la commande utilisateur d’origine contenant ledit identifiant. Si ledit fichier structuré contient la désignation d’une partie cible du document à traiter, ladite requête transmise à l’étape (b) est une requête de ladite partie cible dudit document. Ladite requête textuelle préliminaire comprend : - la commande utilisateur ; - soit un modèle du fichier structuré ; soit une paire d’une commande de référence en langage naturel, et d’un fichier structuré de référence en ledit langage de balisage prédéfini, correspondant à la transcription attendue de ladite commande de référence par ledit modèle de langage génératif. Le modèle de langage génératif est un grand modèle de langage, LLM, en particulier un modèle de type transformateur génératif pré-entraîné, GPT. Le procédé comprend la mise en œuvre des étapes (a) à (d) pour une première commande utilisateur de sorte à obtenir une première réponse textuelle ; puis la mise en œuvre, pour une deuxième commande utilisateur, de l’étape (a), d’une étape (c’) de mise en œuvre d’une deuxième requête textuelle principale, par le modèle de langage génératif, comprenant la deuxième commande utilisateur mais pas le contenu dudit fichier texte, et de l’étape (d). Selon un deuxième aspect, l’invention propose un serveur de traitement automatique d’un document conformément à au moins une commande utilisateur en langage naturel, connecté à un deuxième serveur stockant ledit document par un réseau de communication, caractérisé en ce qu’il comprend des moyens de traitement de données configurés pour : Obtenir depuis une interface utilisateur la commande utilisateur en langage naturel, décrivant ledit traitement attendu du document, et d’un identifiant dudit document ; Transmettre audit deuxième serveur une requête d’au moins une partie dudit document sous forme d’un fichier texte, ladite requête comprenant ledit identifiant obtenu, et réception en retour dudit fichier texte, Mettre en œuvre une requête textuelle de traitement du document, dite requête textuelle principale, par un modèle de langage génératif, ladite requête textuelle principale comprenant : La commande utilisateur ; Le contenu dudit fichier texte ; Restituer, par ladite interface utilisateur, une réponse textuelle à ladite requête textuelle principale. Selon un troisième aspect, l’invention propose un système comprenant ledit premier serveur 1, ainsi que le deuxième serveur 2, et un éventuel troisième serveur 3, connectés via de le réseau communication 20. Selon un quatrième et un cinquième aspects, l’invention propose un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de traitement automatique d’un document stocké par un deuxième serveur, conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document ; 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 de traitement automatique d’un document stocké par un deuxième serveur, conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document. 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 est un logigramme illustrant les étapes d’un mode de réalisation du procédé selon l’invention ; FIG. 3 la FIG. 3 représente schématiquement la mise en œuvre d’un mode de réalisation préféré du procédé selon l’invention. DESCRIPTION DÉTAILLÉE Architecture La présente invention concerne selon un premier aspect un procédé de traitement automatique d’un document conformément à au moins une commande utilisateur en langage naturel, dans un système tel que représenté par la FIG. 1 . Par « commande » utilisateur on entend toute donnée d’entrée formant un input de la part de l’utilisateur, et décrivant le traitement attendu du document. Généralement, ledit traitement est une analyse du document de sorte à extraire une information du document. Ladite commande est alors typiquement une question portant sur le contenu du document, à laquelle l’utilisateur souhaite la réponse. Alternativement, tout traitement sur le document pourra être requis y compris le résumé, la traduction, la réécriture, voire des traitement plus formels. La ou les commandes sont langage naturel, c’est-à-dire la langue « normale » parlée par un être humain et non un langage informatique structuré. Le langage naturel s’écrit sans apprentissage préalable, contrairement à tous les langages informatiques. Il peut y avoir une pluralité de commandes utilisateur, le cas échant successives, décrivant en pratique chacune des traitements successifs attendus dudit document, mais il est tout à fait possible d’avoir une deuxième commande utilisateur qui vient préciser la première commande utilisateur. Comme représenté sur la FIG. 1 , on a un premier serveur 1 d’exécution dudit procédé, et avantageusement un terminal client 10 tel qu’un poste de travail ou un smartphone, présentant une interface utilisateur 13 et via lequel l’utilisateur va pouvoir interagir. A noter qu’il peut ne pas y avoir de terminal 10 distinct du premier serveur (voire le premier serveur 1 être directement un terminal client tel qu’un smartphone – en d’autres termes ces équipements sont confondus), i.e. l’interface 13 être celle du premier serveur 1. On a en outre au moins un deuxième serveur 2 pour le stockage dudit document. De manière préférée ledit document n’est pas stocké par le premier serveur 1, i.e. il est disponible seulement en ligne. Le document pourra être de toute nature, notamment un article, une publication scientifique, un document de brevet, etc. Selon un mode de réalisation préféré, le document est un document de brevet (demande ou brevet) et le deuxième serveur 2 est un serveur de publication de documents de brevets, par exemple le serveur d’un Office des brevets. On a un (ou plusieurs) éventuel(s) troisième(s) serveur(s) 3 pour la mise en œuvre de modèle(s) d’intelligence artificielle décrit(s) plus loin. On comprend que le premier serveur 1 est connecté au moins au deuxième serveur 2, et le cas échéant à l’éventuel terminal client 10 et/ou au(x) troisièmes(s) serveur(s) 3, par exemple via un réseau de communication 20 tel que le réseau internet. Les premier/deuxième/troisième serveurs 1, 2, 3 comprennent des moyens de traitement de données 11, 21, 31 tel qu’un processeur de toute nature, et des moyens de stockage de données 12, 22, 32 i.e. une mémoire. C’est donc les moyens de stockage de données 22 du deuxième terminal 2 qui stockent ledit document. Procédé En référence à la FIG. 2 , le présent procédé est mis en œuvre par les moyens de traitement de données 11 du premier serveur, et commence par une étape (a) d’obtention de ladite au moins une commande utilisateur en langage naturel et d’un identifiant dudit document, depuis une interface utilisateur 13 (potentiellement depuis le terminal client 10 si c’est lui qui comprend ladite interface utilisateur 13). Par identifiant du document, on entend une référence permettant au deuxième serveur 2 d’identifier de manière unique le document. L’identifiant est généralement un code alphanumérique, par exemple un numéro de publication pour une demande de brevet. Il est important de comprendre qu’il suffit que l’identifiant soit interprétable par les moyens de traitement de données 21 du deuxième serveur 2, mais il peut ne pas avoir de sens pour un humain. Selon un premier mode de réalisation, ledit identifiant et ladite commande utilisateur peuvent être chacun saisis séparément par l’utilisateur sur l’interface 13, l’utilisateur ayant en tête le traitement qu’il souhaite, par exemple dans deux champs séparés. L’étape (a) comprend alors la réception (par le premier serveur 1) de l’identifiant et de la commande utilisateur comme deux objets numériques indépendants (la commande vocale sous la forme d’un fichier texte). Par exemple, l’utilisateur peut saisir comme identifiant le numéro de publication d’une demande de brevet et comme commande utilisateur la phrase « Est-ce que le document divulgue un modèle d’IA de type GPT ? ». Selon un deuxième mode de réalisation, bien plus naturel et bien plus ergonomique, ladite commande utilisateur en langage naturel contient directement ledit identifiant, l’étape (a) comprend la saisie par l’utilisateur de cette seule commande utilisateur (i.e. sans saisie séparée de l’identifiant, mais il peut y avoir plusieurs commande utilisateurs saisies), et l’extraction de l’identifiant dans ladite commande. Par exemple, l’utilisateur peut directement saisir la commande utilisateur « Est-ce que le document EPXXXXXXXX divulgue un modèle d’IA de type GPT ? ». Cette extraction pourra être faite par toute technique connue, mais de manière préférée, selon un mode de réalisation qui sera décrit plus loin, cette extraction implique déjà l’utilisation d’un modèle de langage génératif A noter que dans tous les cas, ladite commande utilisateur (et le cas échéant l’identifiant) pourrait alternativement être simplement prononcée par l’utilisateur, et enregistrée par un microphone (par exemple du terminal 10). L’étape (a) comprendrait alors la transcription écrite dudit signal audio vocal en la commande utilisateur. En d’autres termes, les moyens 11 obtiennent la commande utilisateur par la mise en œuvre d’une transcription écrite dudit signal audio vocal. Cette transcription peut être faire via toute technique connue de reconnaissance vocale, en particulier des modèles d’intelligence artificielle, par exemple le modèle Whisper. Le procédé comprend ensuite une étape (b) de transmission audit deuxième serveur 2 d’une requête d’au moins une partie dudit document (dite partie cible) sous forme d’un fichier texte, ladite requête comprenant ledit identifiant obtenu, et réception en retour dudit fichier texte. Plus précisément, la requête est générée par les moyens de traitement de donnée 11 du premier serveur en fonction d’au moins ledit identifiant, et potentiellement également ladite commande utilisateur. On utilise ici un formalisme de requêtes défini par ledit deuxième serveur 2, généralement conformément à des API publiées, par exemple Open Patent Services si le deuxième serveur 2 est un serveur d’Espacenet. En d’autres termes, il s’agit d’une requête informatique classique et non une requête textuelle (en langage naturel) pour un LLM. Ladite requête comprend au moins ledit identifiant de sorte à ce que le serveur 2 puisse identifier le document souhaité, ainsi que d’éventuels attributs relatifs par exemple à la langue souhaitée (s’il y a plusieurs langues dans lesquelles le document est disponible – à noter que la langue peut être prédéfinie ou bien être celle de la commande utilisateur), à ladite partie cible (si elle est définie), etc. Ladite partie cible du document est la partie à traiter. De manière générale ladite partie cible peut être le contenu textuel complet du document, en l’état, dit texte intégral (en anglais fulltext), mis à disposition par le serveur 2, à l’exception d’éventuelles parties purement biographiques ou annexes, ainsi que des contenus non textuels. Par exemple, le texte intégral d’une demande de brevet contient généralement la description les revendications et l’abrégé, mais pas les figures (qui sont des contenus graphiques). Alternativement, ladite partie cible peut être plus restreinte, par exemple seulement la description d’une demande de brevet. Cela peut être prédéfini, ou déterminé à partir de la commande utilisateur on verra plus loin comment. Selon un mode de réalisation préféré, le texte intégral est requis par défaut sauf si la commande utilisateur permet de déterminer une partie cible. Par exemple : suite à la commande « Est-ce que le document EPXXXXXXXX divulgue un modèle d’IA de type GPT ? », alors il n’y a pas de précision quant à la partie du document qui est à traiter, et donc une requête texte(EPXXXXXXXX, français) peut être transmise au serveur 2 ; suite à la commande « Est-ce que la description du document EPXXXXXXXX divulgue un modèle d’IA de type GPT ? », alors la partie du document qui est à traiter est spécifiquement la description, et donc une requête texte(EPXXXXXXXX, français, description) peut être transmise au serveur 2. En réponse, le serveur 2 traite ladite requête de manière connue et fournit un fichier texte contenant ladite partie (nommé fichier_texte_document.txt à titre d’exemple plus loin), si possible dans la langue souhaitée si la requête désignait la langue et si cette langue est disponible (sinon le texte est récupéré dans la langue disponible faute de mieux). On rappelle qu’un fichier texte est un fichier dont le contenu représente uniquement une suite de caractères, par exemple de format .txt ou .rtf. On note que la commande utilisateur est elle-même typiquement fournie sous la forme d’un fichier texte (nommé commande_utilisateur.txt à titre d’exemple plus loin). Le procédé comprend alors une étape (c) principale de mise en œuvre d’une requête textuelle de traitement du document, par un modèle de langage génératif. Cette requête sera dite « principale » dans la suite de la description. Ladite requête textuelle est généralement appelée « prompt », il s’agit d’un texte en entrée du modèle de langage génératif, définissant ce qui lui est demandé. Ledit modèle de langage génératif est un modèle d’intelligence artificielle, capable de générer un texte en sortie à partir d’un prompt. Le modèle de langage génératif généralement est typiquement un grand modèle de langage (LLM), en particulier un modèle de type transformateur génératif pré-entraîné (GPT), par exemple GPT-4, LaMDA, LLaMA, BLOOM, etc. De manière préférée, le LLM est implémenté par un troisième serveur 3 de sorte que cette requête lui est transmise. Plus précisément, l’étape (c) comprend la transmission de ladite requête textuelle principale au troisième serveur 3, et la réception en retour d’une réponse textuelle. De manière très astucieuse, on choisit une requête textuelle (le prompt) comprenant : La commande utilisateur ; Le contenu dudit fichier texte reçu à l’étape (b), i.e. le texte intégral d’au moins une partie du document sur laquelle le traitement conforme à ladite commande utilisateur est attendu ; En d’autres termes, le prompt comprend directement le texte dudit document à traiter, de sorte que le LLM a directement toutes les données nécessaires pour mettre en œuvre le traitement sans devoir accéder à internet. Pour reformuler, la requête textuelle principale est définie comme requête textuelle de traitement du document, mais en pratique le LLM ne sait même pas que le texte fourni est celui d’un document existant, publié sur internet. De plus le contenu fourni est d’excellent qualité car il est directement fourni par le deuxième serveur 2 (c’est le texte officiel si le serveur 2 est un serveur de publication d’un office des brevets) et non obtenu par exemple par OCR. A noter que le mode de réalisation dans lequel on ne récupère si possible que le texte d’une partie du document est avantageux car on limite la taille du prompt, et donc le nombre de « tokens », c’est-à-dire d’unités d’informations utilisées par le LLM, et donc le temps/coût pour obtenir une réponse à la requête textuelle. En ce qui concerne la structure de la requête textuelle, il suffit que le modèle de langage génératif soit capable de comprendre que l’on souhaite mettre en œuvre ladite commande utilisateur sur ledit texte du document. Ainsi, de manière particulièrement préférée, ladite requête textuelle principale comprend en outre une phrase définissant que l’action souhaitée du modèle de langage génératif est le traitement conformément à la commande utilisateur du contenu du ficher texte (i.e. le texte inséré dont on rappelle qu’il est de ladite partie du document récupéré depuis le deuxième serveur 2), la commande utilisateur étant désignée par un premier identifiant, et le contenu dudit fichier texte étant désigné par un deuxième identifiant, et les premiers et deuxième identifiants étant repris dans ladite phrase. Ladite requête textuelle est en particulier par exemple de la forme : « P(I1 ; I2) I1 : CU I2 : DOC » Où I1 et I2 sont les premiers identifiants ; P(I1 ; I2) ladite phrase définissant l’action souhaitée du modèle de langage génératif et reprenant les identifiants I1 et I2 ; DOC le texte contenu dans le fichier texte, et CU la commande utilisateur. Ainsi, en supposant que le squelette du fichier structuré attendu texte du document DOC est dans le fichier fichier_texte_document.txt (i.e. le fichier renvoyé par le deuxième serveur 2), on peut par exemple utiliser la requête textuelle (prompt) suivante, avec en gras des commentaires et explications qui ne font pas partie de cette requête : Réponds à la Question à propos du Document. [Phrase P définissant l’action souhaitée, « Question » est le premier identifiant I1 et « Document » est le deuxième identifiant I2] Question: commande_utilisateur.txt [Identifiant I1 + CU à incorporer] Document: fichier_texte_document.txt [Identifiant I2 + DOC à incorporer] L’étape (c) comprend typiquement la génération de la requête textuelle principale par le premier serveur 1, et dans le mode de réalisation préféré où le modèle de langage génératif est implémenté par un troisième serveur 3 connecté au premier serveur 1, l’étape (c) comprend avantageusement en outre la transmission de ladite requête textuelle principale au troisième serveur 3, et la réception en retour d’une réponse textuelle à ladite requête textuelle principale. Par exemple si la commande utilisateur était « Est-ce que le document divulgue un modèle d’IA de type GPT », la réponse textuelle à la requête contenant cette commande et le texte intégral de la demande EPXXXXXXXX peut être « Oui, au paragraphe [0127] ». Enfin, dans une étape (d) ladite réponse textuelle est restituée par ladite interface 13, à destination de l’utilisateur (par exemple affichage si l’interface est l’écran d’un terminal de type smartphone). A ce titre, la réponse peut le cas échéant être transférée du premier serveur 1 vers l’éventuel terminal 10. Requête textuelle préliminaire Comme expliqué, selon un mode de réalisation préféré et bien plus ergonomique, on a une commande utilisateur contenant directement ledit identifiant, et l’étape (a) comprend l’extraction de l’identifiant du document dans ladite commande utilisateur. Pour ce faire, de manière particulière préférée, l’étape (a) comprend la mise en œuvre d’une requête textuelle de pré-traitement de ladite commande utilisateur textuelle, dite requête textuelle préliminaire, par ledit modèle de langage génératif, de sorte à extraire ledit identifiant. En d’autres termes, on utilise également un LLM (préférentiellement le même que pour requête textuelle principale, mais pas nécessairement) pour pré-traiter la commande utilisateur, sans l’exécuter, pour obtenir l’identifiant. Par exemple, si commande utilisateur est « Est-ce que le document EPXXXXXXXX divulgue un modèle d’IA de type GPT ? » le prompt Quel est le numéro de document mentionné dans: commande_utilisateur.txt ? renvoie la réponse textuelle EPXXXXXXXX, qui peut être utilisée dans l’étape (b). A nouveau, l’étape (c) comprend à ce titre avantageusement la transmission de ladite requête textuelle préliminaire à un troisième serveur 3 (le même ou un autre), et la réception en retour d’une réponse textuelle. La commande utilisateur peut être utilisée en l’état dans l’étape (c), mais on note qu’elle peut créer de la confusion puisqu’elle contient encore l’identifiant. On peut alternativement utiliser astucieusement la requête textuelle préliminaire pour, en même temps que l’extraction de l’identifiant, réécrire la commande utilisateur. Plus précisément, on peut générer à partir de la commande utilisateur, une version générique de cette commande utilisateur ne contenant plus ledit identifiant. A noter que ladite version générique peut être « normalisée » notamment de sorte à présenter un formalisme prédéterminé, par exemple toujours sous la forme d’une question, de sorte à faciliter la rédaction de la requête textuelle principale. Ainsi partant de la commande utilisateur d’origine « Détermine si le document EPXXXXXXXX divulgue un modèle d’IA de type GPT », on peut obtenir la version générique « Est-ce que le document divulgue un modèle d’IA de type GPT ? ». De manière très avantageuse, on peut même profiter de ce prétraitement pour tenter d’obtenir d’autres paramètres de la requête du document envoyée à l’étape (b), tels qu’une désignation de la partie cible ou encore la langue. Ce qui est très puissant ici, c’est que ladite partie cible n’a pas besoin d’être explicitement mentionnée, les LLM peuvent dans certains cas comprendre qu’une partie suffit même si ce n’est pas explicitement indiqué. Par exemple si la commande utilisateur est « Est-ce que le document EPXXXXXXXX revendique un modèle d’IA de type GPT ? », alors le pré-traitement permet de réaliser qu’on peut se contenter des revendications comme partie cible. On comprend qu’on a plusieurs outputs à obtenir (identifiant, version générique, langue, partie cible, etc.), donc on peut exécuter séquentiellement autant de requêtes préliminaires sur la commande utilisateur que des actions différentes désirées (l’extraction de l’identifiant, la réécriture, la détermination de la partie cible, etc.). De manière beaucoup plus efficace, on peut avoir un output unique sous la forme d’un fichier structuré décrivant la commande utilisateur (i.e. contenant toutes ses informations), dit fichier structuré utilisateur, en mettant en œuvre une unique requête textuelle préliminaire. Par fichier structuré on entend un fichier formaté conformément à un modèle attendu, i.e. fichier « vide » ou squelette, par opposition à la commande utilisateur qui est non-structurée, notamment dans un langage de balisage prédéfini tel que XML. Ainsi, il sera très facile pour le premier serveur 1 de lire ce fichier structuré. Par exemple on peut décrire une commande utilisateur avec la structure suivante XXX , où XXX est la version générique de la commande utilisateur, et langue et partie des attributs optionnels. Alors, si on prend en entrée la commande utilisateur « Détermine si le document EPXXXXXXXX revendique un modèle d’IA de type GPT », on peut obtenir le fichier structuré utilisateur « Est-ce que le document revendique un modèle d’IA de type GPT ? » . En effet, un fichier structuré n’est pas en langage naturel mais son code (dans ledit langage de balisage) reste une suite de caractères, et un LLM est capable de construire automatiquement et efficacement un tel fichier. Ainsi, dans ce mode de réalisation, ladite requête préliminaire est avantageusement une requête de transcription de ladite commande utilisateur textuelle, par ledit modèle de langage génératif, en un fichier structuré (en d’autres termes la construction, à partir de ladite commande utilisateur textuelle, du fichier structuré) contenant : - ledit identifiant du document ; - une version générique de ladite commande utilisateur ne contenant plus ledit identifiant ; - Optionnellement, une désignation d’une partie cible du document à traiter (on note qu’il est possible que le LLM ne parviennent pas à déterminer de partie cible, alors on récupérera typiquement tout le contenu textuel du document) ; - Encore plus optionnellement, la langue souhaitée du document. Ledit fichier structuré peut être exploité par les moyens de traitement de données 11 du premier serveur 1 aux étapes (b) et (c). Ladite requête textuelle principale mise en œuvre à l’étape (c) comprend alors comme expliqué le cas échéant ladite version générique (extraite du fichier structuré utilisateur) plutôt que la commande utilisateur d’origine contenant ledit identifiant. Et, si ledit fichier structuré contient la désignation d’une partie cible du document à traiter, ladite requête transmise à l’étape (b) est une requête de ladite partie cible dudit document. En ce qui concerne le format de la requête textuelle préliminaire, selon une première variante, elle contient - la commande utilisateur ; - un modèle du fichier structuré Alors, similairement à la requête textuelle principale, ladite requête textuelle préliminaire peut comprend en outre une phrase définissant que l’action souhaitée du modèle de langage génératif est la transcription de la commande utilisateur en ledit fichier structuré conformément audit squelette, la commande utilisateur étant désignés par un premier identifiant, et le squelette du fichier structuré utilisateur étant désigné par un deuxième identifiant, et les premiers et deuxième identifiants étant repris dans ladite phrase. A noter que ledit modèle du fichier structuré pourra être un squelette ou bien un document descriptif de la structure attendue du fichier structuré, par exemple un fichier DTD (document type document) si le fichier structuré est un fichier XML Ainsi, en supposant que la commande utilisateur est dans un fichier commande_utilisateur.txt à incorporer et que le modèle du fichier structuré est dans le fichier commande_utilisateur.dtd, on peut utiliser la requête textuelle préliminaire (prompt) suivante : Transcris la Commande en un fichier structuré conforme au Modèle, la version générique de la Commande mentionnée dans le Modèle étant une reformulation de la Commande sous forme de question ne mentionnant pas d’identifiant de document. Commande: commande_utilisateur.txt Modèle: commande_utilisateur.tdt Selon une deuxième variante, la requête textuelle préliminaire contient - la commande utilisateur ; - au moins une paire d’une commande de référence en langage naturel, et d’un fichier structuré de référence en ledit langage de balisage prédéfini, correspondant à la transcription attendue de ladite commande de référence par ledit modèle de langage génératif. Par commande et fichier de référence, on entend des exemples prédéterminés. Ladite paire (dite paire de référence) correspond implicitement à une paire d’apprentissage, équivalente au fait d’inclure un modèle complet (et souvent plus simple à générer). Alors, similairement à la proposé dans la première variante, ladite requête textuelle préliminaire peut comprend en outre une phrase définissant que l’action souhaitée du modèle de langage génératif est la transcription de la commande utilisateur en ledit fichier structuré, mais cette fois la commande utilisateur et la commande de référence sont désignées par un premier identifiant, le fichier structuré attendu et le fichier structuré de référence sont désignés par un deuxième identifiant, et les premiers et deuxième identifiants sont repris dans ladite phrase. Ainsi, en supposant que la commande utilisateur est dans un fichier commande_utilisateur.txt, que la commande de référence est dans un fichier commande_reférence.txt à incorporer et que le fichier structuré de référence est, on peut utiliser la requête textuelle préliminaire (prompt) suivante : Transcris la Commande en un fichier structuré XML. Commande: commande_référence.txt XML: fichier_reference.XML Commande: commande_utilisateur.txt XML: Grâce à cette structure, le LLM comprend qu’il doit générer le XML qui est à la commande utilisateur ce que le fichier structuré de référence est à la commande de référence. On note qu’il n’y a même pas besoin de décrire ce qu’on veut par « version générique » de la commande utilisateur car le LLM le comprend tout seul grâce à la paire de référence. On note qu’il est tout à fait possible de mettre plusieurs paires de référence pour améliorer les performances. En tout état de cause, la taille de la requête textuelle préliminaire est dérisoire par rapport à celle de la requête textuelle principale de sorte que son coût et son temps de traitement sont négligeables. En référence à la FIG. 3 , un mode de réalisation préféré du procédé est résumé de la sorte : Le premier serveur 1 obtient une commande utilisateur comprenant un identifiant de document Le premier serveur 1 transmet à un troisième serveur 3 une requête textuelle (dite préliminaire) de transcription, par un modèle de langage génératif, de la commande utilisateur en un fichier structuré ; Il reçoit en réponse le fichier structuré contenant au moins l’identifiant du document et la version générique de ladite commande utilisateur ne contenant plus ledit identifiant ; Le premier serveur 1 transmet à un deuxième serveur 2 une requête d’au moins une partie dudit document sous forme d’un fichier texte, comprenant ledit identifiant fourni dans le fichier structuré, et la désignation de ladite partie cible si elle est présente dans le fichier structuré ; Il reçoit en réponse ledit fichier texte Le premier serveur 1 transmet au troisième serveur 3 une nouvelle requête textuelle (dite principale) de traitement du document, par le modèle de langage génératif, ladite requête textuelle principale comprenant : La version générique de la commande utilisateur fournie dans le fichier structuré ; Le contenu dudit fichier texte ; Il reçoit la réponse textuelle Il restitue cette dernière sur l’interface 13 (1) à (3) correspondent à l’étape (a), (4) et (5) à l’étape (b), (6) et (7) à l’étape (c) et (8) à l’étape (d). Enchainement de commandes Selon un mode de réalisation, il peut y avoir plusieurs commandes utilisateur. Bien évidemment, si l’utilisateur souhaite traiter un nouveau document il faut recommencer le procédé. Alternativement, l’utilisateur peut requérir un nouveau traitement du même document (s’il pose une nouvelle question), et on peut simplifier le procédé. Plus précisément, le procédé comprend avantageusement la mise en œuvre des étapes (a) à (d) pour une première commande utilisateur de sorte à obtenir une première réponse textuelle (i.e. première exécution normale du procédé), puis la mise en œuvre, pour une deuxième commande utilisateur, de l’étape (a) ; d’une étape (c’) de mise en œuvre d’une deuxième requête textuelle principale, par le modèle de langage génératif, comprenant la deuxième commande utilisateur mais pas le contenu dudit fichier texte ; et de l’étape (d) (i.e. deuxième exécution simplifiée). En effet, on n’a normalement pas besoin de remettre en œuvre l’étape (b), sauf si l’étape (a) conclut que la partie du document à traiter n’est pas la même ou du moins n’est pas incluse dans la partie disponible (et alors il faut recommencer). Plus précisément, soit la deuxième commande utilisateur ne contient pas d’identifiant de document, et on peut supposer que le même document est visé, soit la deuxième commande utilisateur contient un identifiant de document, extrait grâce à la requête textuelle préliminaire, et il suffit de le comparer avec l’identifiant obtenu pour la première commande utilisateur. On peut répéter l’étape (c) telle qu’elle, mais on rappelle que cela impliquerait de transmettre à nouveau le contenu du document, ce qui est massif. Or, les LLM ont généralement une mémoire de la discussion en cours, de sorte qu’il n’y a pas besoin en pratique que la deuxième requête textuelle principale comprenne encore le contenu dudit fichier texte, d’où l’étape (c’) au lieu de l’étape (c), de mise en œuvre d’une deuxième requête textuelle principale « simplifiée », par le modèle de langage génératif, dans la mesure où elle ne comprend la deuxième commande utilisateur mais pas le contenu dudit fichier texte. Comme la ou les requêtes préliminaires, une telle deuxième requête textuelle simplifiée a une taille dérisoire par rapport à celle de la requête textuelle principale de sorte que son coût en tokens et son temps de traitement sont négligeables. Pour reformuler seule la première commande utilisateur est couteuse, ensuite l’utilisateur peut ainsi enchaîner les questions sur le document sans aucune restriction. Serveur Selon un deuxième aspect, l’invention concerne le premier serveur 1 pour la mise en œuvre du procédé selon le premier aspect. Ainsi, ce premier serveur 1 comprend comme expliqué au moins des moyens de traitement de données 11 et une mémoire 12. Il comprend une interface utilisateur 13 ou est connecté à un terminal 10 ayant une telle interface Il s’agit typiquement d’un serveur de traitement automatique de documents. Les moyens de traitement de données 11 sont configurés pour mettre en œuvre, pour un document, des étapes consistant à : Obtenir depuis l’interface utilisateur 13 la commande utilisateur en langage naturel, décrivant ledit traitement attendu du document, et d’un identifiant dudit document ; Transmettre audit deuxième serveur 2 une requête d’au moins une partie dudit document sous forme d’un fichier texte, ladite requête comprenant ledit identifiant obtenu, et réception en retour dudit fichier texte, Mettre en œuvre une requête textuelle de traitement du document, dite requête textuelle principale, par un modèle de langage génératif, ladite requête textuelle principale comprenant : La commande utilisateur ; Le contenu dudit fichier texte ; Restituer, par ladite interface utilisateur 13, une réponse textuelle à ladite requête textuelle principale. Selon un troisième aspect, l’invention propose un système comprenant ledit premier serveur 1, ainsi que le deuxième serveur 2, et un éventuel troisième serveur 3, connectés (via le réseau 20). 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 11 du premier serveur 1) d’un procédé selon le premier aspect de procédé de traitement automatique d’un document stocké par un deuxième serveur 2, conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document ; ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les moyens de stockage de données 12 du premier serveur 1) sur lequel on trouve ce produit programme d’ordinateur. Procédé de traitement automatique d’un document stocké par un deuxième serveur (2), conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (11) d’un premier serveur (1) connecté au deuxième serveur (2) par un réseau de communication (20), d’étapes de : Obtention de ladite au moins une commande utilisateur en langage naturel et d’un identifiant dudit document, depuis une interface utilisateur (13) ; Transmission audit deuxième serveur (2) d’une requête d’au moins une partie dudit document sous forme d’un fichier texte, ladite requête comprenant ledit identifiant obtenu, et réception en retour dudit fichier texte, Mise en œuvre d’une requête textuelle de traitement du document, dite requête textuelle principale, par un modèle de langage génératif, ladite requête textuelle principale comprenant : La commande utilisateur ; Le contenu dudit fichier texte ; Restitution, par ladite interface utilisateur (13), d’une réponse textuelle à ladite requête textuelle principale. Procédé selon la revendication 1, dans lequel ledit modèle de langage génératif est implémenté par un troisième serveur (3) connecté au premier serveur (1) par ledit réseau de communication (20), l’étape (c) comprenant la transmission de ladite requête textuelle au troisième serveur (3), et la réception en retour de ladite réponse textuelle. Procédé selon l’une des revendications 1 et 2, dans lequel ladite requête textuelle principale comprend en outre une phrase définissant que l’action souhaitée du modèle de langage génératif est le traitement conformément à la commande utilisateur du contenu du fichier texte, la commande utilisateur étant désignée par un premier identifiant, le contenu dudit fichier texte étant désigné par un deuxième identifiant, et les premiers et deuxième identifiants étant repris dans ladite phrase. Procédé selon la revendication 3, dans lequel ladite requête textuelle est de la forme : « P(I1 ; I2) I1 : CU I2 : DOC » Où I1 et I2 sont les premiers identifiants ; P(I1 ; I2) ladite phrase définissant l’action souhaitée du modèle de langage génératif et reprenant les identifiants I1 et I2 ; DOC le texte contenu dans le fichier texte, et CU la commande utilisateur. Procédé selon l’une des revendications 1 à 4, dans lequel l’étape (a) comprend la saisie par l’utilisateur d’une part dudit identifiant et d’autre part de ladite commande utilisateur en langage naturel. Procédé selon l’une des revendications 1 à 5, dans lequel ladite commande utilisateur contient ledit identifiant, l’étape (a) comprenant l’extraction de l’identifiant du document dans ladite commande utilisateur. Procédé selon la revendication 6, dans lequel l’étape (a) comprend la mise en œuvre d’une requête textuelle de pré-traitement de ladite commande utilisateur textuelle, dite requête textuelle préliminaire, par ledit modèle de langage génératif, de sorte à extraire ledit identifiant. Procédé selon la revendication 7, dans lequel ladite requête préliminaire est une requête de transcription de ladite commande utilisateur textuelle, par ledit modèle de langage génératif, en un fichier structuré contenant : - ledit identifiant du document ; - une version générique de ladite commande utilisateur ne contenant plus ledit identifiant ; - Optionnellement, une désignation d’une partie cible du document à traiter ; Ladite requête textuelle principale mise en œuvre à l’étape (c) comprenant ladite version générique plutôt que la commande utilisateur d’origine contenant ledit identifiant. Procédé selon la revendication 8, dans lequel, si ledit fichier structuré contient la désignation d’une partie cible du document à traiter, ladite requête transmise à l’étape (b) est une requête de ladite partie cible dudit document. Procédé selon l’une des revendications 8 et 9, dans lequel ladite requête textuelle préliminaire comprend : - la commande utilisateur ; - soit un modèle du fichier structuré ; soit une paire d’une commande de référence en langage naturel, et d’un fichier structuré de référence en ledit langage de balisage prédéfini, correspondant à la transcription attendue de ladite commande de référence par ledit modèle de langage génératif. Procédé selon l’une des revendications 1 à 10, dans lequel le modèle de langage génératif est un grand modèle de langage, LLM, en particulier un modèle de type transformateur génératif pré-entraîné, GPT. Procédé selon l’une des revendication 1 à 11, comprenant la mise en œuvre des étapes (a) à (d) pour une première commande utilisateur de sorte à obtenir une première réponse textuelle, puis la mise en œuvre, pour une deuxième commande utilisateur, de l’étape (a) ; d’une étape (c’) de mise en œuvre d’une deuxième requête textuelle principale, par le modèle de langage génératif, comprenant la deuxième commande utilisateur mais pas le contenu dudit fichier texte ; et de l’étape (d). Serveur (1) de traitement automatique d’un document conformément à au moins une commande utilisateur en langage naturel, connecté à un deuxième serveur (2) stockant ledit document par un réseau de communication (20), caractérisé en ce qu’il comprend des moyens de traitement de données (11) configurés pour : Obtenir depuis une interface utilisateur (13) la commande utilisateur en langage naturel, décrivant ledit traitement attendu du document, et d’un identifiant dudit document ; Transmettre audit deuxième serveur (2) une requête d’au moins une partie dudit document sous forme d’un fichier texte, ladite requête comprenant ledit identifiant obtenu, et réception en retour dudit fichier texte, Mettre en œuvre une requête textuelle de traitement du document, dite requête textuelle principale, par un modèle de langage génératif, ladite requête textuelle principale comprenant : La commande utilisateur ; Le contenu dudit fichier texte ; Restituer, par ladite interface utilisateur (13), une réponse textuelle à ladite requête textuelle principale. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 12 de traitement automatique d’un document stocké par un deuxième serveur (2), conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document, 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 à 12 de traitement automatique d’un document stocké par un deuxième serveur (2), conformément à au moins une commande utilisateur en langage naturel, décrivant ledit traitement attendu du document.