FR 3061337 A1 20180629 FR 1663314 A 20161223 1 MOTEUR DE REGLES UNIVERSEL ET OPTIMISE POUR LE TRAITEMENT DE DOCUMENTS DE GESTION DOMAINE DE L'INVENTION L'invention concerne le domaine de l'analyse automatique de documents de gestion au sein d'une entreprise. Elle s'applique particulièrement bien à l'analyse automatique de factures, notamment à des fins de contrôle de cohérence ou de classification. CONTEXTE DE L'INVENTION Les entreprises ont à gérer un nombre très important de documents de gestion. Ces documents « de gestion » regroupent l'ensemble des documents relatifs à la gestion d'une entreprise, et que l'on peut donc distinguer des documents purement métiers et relatifs à l'activité de l'entreprise. Cela comprend notamment les factures, les relevés de consommation, les fiches de paie, la gestion des commandes, des documents comptables, etc. Dans une entreprise de taille importante, le volume de ces documents est tel qu'il est dès lors impossible de procéder à un contrôle manuel de ces documents. Pourtant la problématique de l'analyse des documents de gestion est extrêmement importante pour les entreprises. Des incohérences peuvent en effet entraîner des risques légaux, notamment du fait des règlements comptables et fiscaux. On peut par exemple citer les erreurs sur les cotisations versées aux différentes caisses que l'analyse des feuilles de paie peut permettre de détecter. On peut également citer, parmi de nombreux autres exemples, les erreurs sur les taux de TVA dans les factures. 3061337 2 Une autre conséquence de ces incohérences est d'entraîner le paiement de sommes indues par exemple, si les montants figurants sur des factures sont erronés. 5 En outre les documents de gestions sont de natures très variées, et correspondent à des types d'analyse également très variées. Chaque type documents de gestion fait donc appel à des expertises spécifiques, de sorte que les outils informatiques permettant l'automatisation de l'analyse sont, très généralement, dédiés à un type de documents, et utilisés par un corps de 10 métier (comptabilité, service paie, direction des achats, etc.) Il n'existe donc pas d'outils universels, c'est-à-dire à même de s'adapté à tout type de documents de gestion. Compte tenu du volume important de données à traiter, un tel outil 15 doit atteindre des performances élevées afin d'être utilisable. Il doit également proposer une adaptation au fonctionnement de l'entreprise afin de prendre en compte les spécificités de son activité et des processus internes. Il n'existe en outre pas d'outils généralistes visant à optimiser les dépenses de l'entreprise, en procédant à l'analyse des documents de gestion. 20 L'invention vise à proposer une solution alternative permettant l'analyse de tout type de documents de gestion, afin d'optimiser les dépenses d'une entreprise, et avec des performances permettant de traiter un très grand nombre de documents en un temps très court. Elle vise en outre 25 l'optimisation des dépenses de l'entreprise utilisatrice, en permettant une meilleure analyse des documents de gestion, notamment par l'utilisation de règles personnalisables et adaptables au métier de l'entreprise et à son fonctionnement par un expert du domaine concerné. 30 RESUME DE L'INVENTION 3061337 3 Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités. A cette fin, la présente invention propose un procédé pour l'analyse de 5 documents de gestion relatifs à une entreprise, lesdits documents de gestion étant stockés dans une base de données relationnelle sous la forme d'un ensemble de données, le procédé comportant : la récupération de règles à partir d'une base de règles, par un moteur de règles, puis, 10 de façon itérative, pour chacune desdites règles, la transmission par ledit moteur de règles d'au moins une requête associée à ladite règle vers un système de gestion de ladite base de données, la comparaison du résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat 15 attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, l'exécution d'une action associée à ladite règle. Suivant des modes de réalisation préférés, l'invention comprend une 20 ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : - les règles sont générées à partir d'un langage haut-niveau ; - les règles récupérées sont transformés en requêtes exprimés 25 selon ledit système de gestion en utilisant le schéma de ladite base de données ; - lesdites requêtes transformées sont exprimées en SQL ou PL/SQL et exécutée dans ledit système de gestion de données ; - lesdits documents de gestion sont des factures et lesdites actions 30 sont prévues pour vérifier la cohérence des données dudit ensemble ; 3061337 4 - ladite action peut alimenter une base de résultat, fonctionnellement distincte de ladite base de données - ladite action peut déclencher l'exécution d'une fonction par un dispositif extérieur audit moteur de recherche ; 5 - ladite base de règles est un entrepôt de règles. Un autre objet de l'invention est un produit logiciel comportant des instructions exécutables par une plateforme de traitement de l'information pour mettre en oeuvre le procédé tel que précédemment décrit. 10 Un autre objet de l'invention concerne un système pour l'analyse de documents de gestion relatifs à une entreprise, comportant un outil de prétraitement adapté pour structurer lesdits documents en un ensemble de données associant un identifiant de champ à au moins une valeur de champ, 15 puis à stocker lesdites données dans une base de données relationnelle, et comportant également un moteur de règles adapté pour récupérer des règles à partir d'une base de règles selon un ordonnancement qui est fonction de métadonnées associées auxdites règles, 20 pour chacune desdites règles, transmettre une requête associée à ladite règle vers un système de gestion de ladite base de données, comparer ledit résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, 25 exécuter une action associée à ladite règle. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. 30 3061337 5 BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement une architecture fonctionnelle selon un mode de réalisation de l'invention. 5 La figure 2 représente schématiquement un organigramme d'un procédé selon un mode de réalisation de l'invention. La figure 3 représente un exemple de schéma d'une base de règles selon un mode de réalisation de l'invention. 10 DESCRIPTION DETAILLEE DE L'INVENTION L'invention repose sur une base de données contenant des données issues de documents de gestion. Comme il a été évoqué en introduction, ces documents de gestion peuvent être de différentes natures : factures, 15 documents de paie, de consommation, relevés de compteurs, etc. Toutes sortent de données traités dans la vie d'une entreprise peuvent être considérés et entrer dans ce cadre de « documents de gestion ». Le contenu de la base de données peut être constitué de différentes façons. Par exemple, il peut être transféré depuis une base de données du 20 client, ou bien importé via des fichiers au format CSV (pour « Comma- Separated Values », en langue anglaise). D'autres mécanismes de « population » de la base à partir de documents de gestion numérisés sont bien évidemment possibles et accessibles à l'homme du métier. Par ailleurs, il est possible de construire la base à partir de documents 25 de gestion au format papier et de les numériser. Une phase de prétraitement peut alors être mise en oeuvre pour numériser ses documents et pour en analyser le contenu afin de structurer l'information contenue dans ces documents de gestion. Ce prétraitement peut utiliser les techniques existantes de 30 reconnaissance optique de caractères ou OCR, pour « Optical Character Recognition» en langue anglaise. Une mise en oeuvre de l'invention peut se 3061337 6 baser sur un module logiciel implémentant une telle technique, et fournissant un ensemble de documents numériques, chacun représentant un document de gestion. Le prétraitement peut également comporter une sous-étape de 5 correction et de structuration de ces documents numériques. En effet, les différentes techniques de reconnaissance optique de caractères sont imparfaites et produisent des erreurs en reconnaissance. Il est alors possible de tirer profit de la sémantique et du formalisme des documents de gestion. Par exemple, si le document de gestion est une facture, le système sait 10 qu'une facture répond à un certain formalisme et possède une certaine structure. En utilisant ces informations, il est donc possible de détecter et de corriger certaines erreurs en reconnaissance de caractères. Par exemple, si on reconnait qu'une information représente un prix, on peut en déduire qu'elle est formée de chiffre et éventuellement d'un symbole d'une 15 monnaie. Cette information permet d'aiguiller la correction d'une erreur en reconnaissance sur un caractère de ce champ. D'une façon générale, les factures contiennent des informations correspondant à une structure attendue : on sait qu'une facture doit contenir une adresse d'émetteur, une adresse de facturation, une date, un numéro de 20 facture, un total facturé, un taux de TVA, etc. On sait aussi qu'une facture contient un élément facturé par ligne. Toutes ces informations, à la fois sémantiques et de forme, peuvent non seulement guider la correction des erreurs, mais aussi peuvent servir à structurer les données correspondant à une facture numérique. 25 En outre, les factures sont des documents dans lesquels l'information est structurée selon une hiérarchie des données. Par exemple, il est possible de définir une hiérarchie correspondant aux prix figurants dans une facture : chaque élément facturé représente le niveau inférieur de la hiérarchie, tandis que le total facturé représente le niveau haut ; des sous-totaux peuvent 30 représenter des niveaux intermédiaires. 3061337 7 Le prétraitement peut consister à utiliser une connaissance du type d'information attendue dans une facture pour construire une structure de données, voire pour construire une structure hiérarchique des données. Une étape de lemmatisation peut également être mise en place afin de 5 détecter les racines des mots et de comparer plusieurs variances lexicales à partir de ces racines pour les informations textuelles comme le titre, l'objet, les libellés des factures, etc. Ce prétraitement ne représente qu'un mode de réalisation possible 10 pour construire le contenu de la base de données des documents de gestion et l'invention est donc indépendante de la présence ou non de ce prétraitement et de la façon dont est construit le contenu de la base de données. L'invention se base en effet sur une base de données constituée et peut être adaptée à tout type de formats et de schéma de cette base de 15 données. Dans le cadre de l'invention, il est uniquement supposé qu'elle soit suffisamment structurée pour permettre l'application de règle. La figure 1 schématise de façon fonctionnelle et haut niveau une architecture possible d'un système selon l'invention. 20 La structure de données représentant les documents de gestion est stockée dans une base de données relationnelle, référencée 100 sur cette figure 1. De façon connue en soi, cette base de données 100, nommée base de travail ODS (pour « Operational Data Store » en anglais), peut être mise en 25 oeuvre par une structure 101, sous la forme d'un ensemble de tables pouvant être liées les unes aux autres via des clés, dans lequel est stockée la structure de données, et qui est associé à un système de gestion 102 permettant d'assurer l'interface entre le contenu de la base et le monde extérieur. Ce système de gestion 102 reçoit typiquement en entrée des requêtes 30 qui sont, assez généralement, décrite en langage SQL (« Structured Query Language ») ou en une de ses variantes. 3061337 8 Classiquement, un système de gestion de base de données 102 (SGBD ou DBMS pour « Database Management System) comporte un processeur de requêtes pour recevoir et exécuter ces requêtes sur le contenu 101 de la base de données. 5 L'exécution de la requête sur les données stockées dans la base génère en général des données de résultat. Ce résultat peut alors être retourné à l'émetteur de la requête. Le système de gestion 102, et notamment le processeur de requêtes, est intiment lié à la structure même de la mémoire 101. Il interprète les 10 requêtes (SQL ou autres) et les exécute en tirant profit de la connaissance qu'il possède de la structure de la base, de sorte à ce que l'interaction entre le système de gestion et la base elle-même soit optimisée. Une structure distincte 170 permet de stocker les résultats, tel qu'il sera décrit plus loin. 15 La base de données 101 possède en général un schéma 103 qui décrit les métadonnées de sa base : les noms des tables, les colonnes, les relations entre elles. Ce schéma est récupérable par un mécanisme de rétro-ingénierie (ou «reverse engineering » en langue anglaise). Cette information de schéma peut permettre au moteur de règles de construire correctement les 20 requêtes, SQL ou autres, ainsi qu'il sera vu plus loin. Selon l'invention, une base de règles 120 permet de stocker un ensemble de règles à appliquer sur les données représentatives des documents de gestion stockées dans la base 100. Ces règles visent à analyser ces données afin de les classifier ou d'en vérifier la cohérence. 25 La base de règles 120, nommée entrepôt de règles (ou « Rule Store » en anglais) peut être mise en oeuvre en utilisant l'API appropriée. Cette notion d'entrepôt de règles est connue en soi et est notamment décrite dans le brevet U57356522 ou dans la demande de brevet U520090171903. 30 Les règles peuvent être en partie des règles prédéfinies et communes au traitement de tout document de gestion d'un même type. Mais d'autres 3061337 9 règles peuvent être plus spécifiques à des documents de gestion particuliers traités par l'entreprise, ou aux modes de fonctionnement de cette entreprise. Par exemple dans le cadre du contrôle de cohérence de factures, des règles peuvent concerner: 5 la cohérence mathématique de chaque facture. Il s'agit de vérifier que la somme des éléments facturés correspond bien au total de la facture, ou que le produit d'un prix unitaire multiplié par la quantité correspond bien au montant total par ligne. Il peut aussi s'agir de vérifier qu'une même mention est présente sur l'ensemble des 10 factures d'une même série (pour détecter une erreur dans un numéro de référence ou de bon de commande, par exemple). Dans ce même cadre d'une série de factures, il peut aussi s'agir de vérifier qu'il n'y a pas d'incohérence entre des périodes de facture d'une facture à l'autre ; 15 la détection d'anomalies comme des informations manquantes ou bien possiblement erronées par rapport à un gabarit d'informations attendues. Il peut par exemple s'agir d'un taux de TVA erroné, voire manquant, d'un rabais annuel non-appliqué, de l'absence d'un élément de facturation attendu... Il est également possible de définir 20 des règles pour comparer des montants facturés par rapport à des moyennes et d'ainsi détecter des dépassements importants par rapport à une moyenne ; le respect de la législation. Selon les lois applicables, des mentions particulières doivent obligatoirement apparaître sur une facture, 25 notamment la date d'émission, un numéro de référence, l'identité des parties, etc. Des règles peuvent être prévues pour vérifier la présence de ces mentions et leur conformité à la législation ; le respect d'un catalogue de tarification. Il peut en effet être possible de définir des règles pour comparer les montants indiqués dans les 30 factures avec des catalogues de prix et de déterminer des incohérences. 3061337 10 Il ressort de ces exemples qu'il existe une grande variété de règles possibles, et que certaines ne peuvent être définies que par l'utilisateur. Un des avantages de l'invention réside justement dans la possibilité pour les 5 utilisateurs de définir ou d'adapter leurs propres règles. Des outils peuvent être prévus pour faciliter la définition de ces règles, et notamment par des personnes qui ne sont pas des spécialistes en informatique et/ou en gestion de base de données. Il est important, en effet, que l'outil puisse permettre à des personnes responsables de la comptabilité 10 de l'entreprise de rédiger leurs propres règles en fonction des contrôles qu'elles veulent effectuer sur les documents de gestion, factures ou autres. Aussi, un outil de conversion 130 peut être prévu afin de générer des règles exploitables par un moteur de règles 110. Ces règles générées 15 peuvent être exprimés dans un langage de type DSL (« Domain Specific Language») intitulé DRDL (« Dhatim Rule Definition Language »). Les languages DSL sont par exemple explicité dans l'encyclopédie participative en-ligne wikipedia : http s ://en.wikip edi a. org/wiki/Domain- specific language 20 L'outil de conversion 130 peut convertir des règles issues d'une base tierce 150, qui peut notamment être un catalogue de règles disponibles. En pratique, ce catalogue peut être mis en oeuvre par une même base que la base de règles 120, mais les deux sont fonctionnellement séparées. 25 L'outil de conversion peut également convertir des règles exprimées en un langage de haut niveau, notamment au travers d'une interface homme-machine 140. Les deux mécanismes peuvent avantageusement être combinés. Sur l'organigramme de la figure 2, on voit que dans un premier temps des règles 30 peuvent être importées, 210, depuis la base tierce 150 vers la base de règles, puis celles-ci peuvent être éditées, 211, au moyen de l'interface homme- 3061337 11 machine 140 et réintroduites, sous une forme adaptée, dans la base de règles 120. Cette interface homme-machine 140 est classiquement appelée environnement de développement intégré (ou IDE pour « Integrated Development Environment » en anglais). 5 Le langage de haut-niveau peut être du langage naturel ou seminaturel. Il peut également s'agir d'un langage visuel. Une interface graphique 141 peut être proposée au sein de l'interface homme-machine 140 du système de l'invention, pour permettre aux utilisateurs de définir leurs 10 règles. Il est possible de mettre en place des mécanismes d'auto-complétion qui consiste à proposer un mot ou une séquence de mots à l'utilisateur, lorsque celui-ci saisit les premiers caractères d'un mot. Ces suggestions peuvent se baser sur un dictionnaire standard mais 15 aussi sur le schéma 103 de la base de données 100. Le contenu des données de gestion (factures...) peut ainsi fournir un vocabulaire lexicographique qui peut être ainsi proposé à l'utilisateur via l'interface 140, 141 afin d'adapter plus facilement ses règles au contenu des données à traiter. Ce vocabulaire peut être utilisé tel quel dans la définition des règles ou bien être surchargé 20 selon l'application. En outre dans le cadre de la fonction d'auto-complétion, ce vocabulaire peut être présenté à l'utilisateur par d'autres moyens, par exemple en affichant une liste des mots ou expressions les plus représentées dans la base sur l'interface 140. 25 Ces règles exprimées dans un langage haut-niveau peuvent alors être converties pour générer des règles utilisables par un moteur de règle 110. Ainsi, le système est universel et peut s'adapter à n'importe quelle base de données de travail et est indépendant de cette base 100. Moyennant 30 l'adaptation de l'outil de conversion 130, il peut être déployé sur tout type de base de données relationnelle 100. 3061337 12 Dans certains cas complexes, le moteur de règles peut disposer d'un mécanisme de description pour guider la génération de bonnes requêtes SQL dans ces bases de travail : par exemple jointure de deux tables n'ayant pas de liens directs, résolution de conflits en cas d'ambiguïté d'un même 5 nom de colonnes présent dans plusieurs tables, navigation entre les données pour certains opérateurs particuliers de règles, etc. La notion de moteur de règles est connue en soi. A titre d'exemples informatifs, on peut citer le brevet U57761397 ou les demandes de brevet 10 W01989011684 ou U520040034848. Le brevet U55664173 et les demandes de brevets U520060206468 et U520030212657 concernent plus particulièrement l'application de moteurs de règles à des bases de données. Des moteurs de règles ont été développés pour différents domaines : contrôle d'accès, gestion des risques, traitement de flux de données RSS, 15 etc. L'invention est relative à l'utilisation d'un moteur de règles pour le contrôle des documents de gestion au sein d'une entreprise. Les règles sont stockées dans une base de règles 120. Il peut être prévu d'associer les règles à des droits d'accès afin de permettre la 20 mutualisation de la base de règles 120 entre plusieurs utilisateurs et plusieurs applications, tout en permettant leur cloisonnement. Les règles peuvent prendre différentes formes et être adaptées selon différentes applications. 25 La figure 3 illustre un schéma permettant de stocker les règles au sein de la base de règles 120. Les tables Ti, T2 sont des tables permettant d'organiser plusieurs ensembles de règles au sein d'une même base de règles, pouvant correspondre à plusieurs applications, plusieurs profils d'utilisateurs, etc. Un 30 premier niveau, Ti, correspond à un projet, et le second niveau T2 permet de spécifier plusieurs ensembles de règles par projet. 3061337 13 La table T3 correspond aux règles proprement dites et permettent notamment d'associer à chaque règle des informations associées, notamment un nom (« name ») et certaines métadonnées immutables de la règle. 5 Selon un choix d'implémentation, les informations plus détaillées sont associées à une autre table, T4, tenant l'historique de la règle avec la définition et les métadonnées associées. Cette table possède des pointeurs vers la table mère T3, mais aussi vers elle-même afin de permettre une arborescence entre les versions. 10 Ces informations plus détaillées, ou métadonnées, permettent d'associer à chaque révision de règle, des informations permettant notamment d'en guider l'exécution par le moteur de règles. Un certain nombre de ces métadonnées sont techniques et peuvent être propres aux mises en oeuvre techniques du moteur de règles. 15 Ces métadonnées peuvent comprendre un identifiant, ou nom, de la règle, une description et des informations permettant de déterminer un ordre entre les règles. Il peut s'agir de priorités (« priority ») ou d'un numéro d'ordre. Il est ainsi possible d'influencer, lors de la conception des règles, l'ordre dans lequel elles seront exécutées sur un ensemble de données, soit 20 en les regroupant par priorités, soit en en fixant un ordre bien défini. La métadonnée « description » peut par exemple permettre d'afficher des informations aux utilisateurs via l'interface 140. En plus des métadonnées prédéfinies, par exemple tels que représentés sur la figure 3, les tables Ti, T2, T3 et T4 peuvent comporter des 25 métadonnées flexibles (champs « metadata ») définis par l'utilisateur. Elles peuvent être exprimées en un format extensible tel que le format JSON (« JavaScript Object Notation ») En sus des métadonnées, la table T4 mémorise les informations 30 définissant la règle elle-même, c'est-à-dire un corps de règle pouvant comporter une seule ou plusieurs parties. 3061337 14 Par exemple : Une règle complète : SI ALORS Une règle fonctionnelle pour grouper plusieurs règles techniques 5 Une règle de contrôle des montants dans les factures peut avoir deux parties : une partie correspondant à une règle de détection des incohérences et une partie correspondant au formulaire de calcul quand l'erreur est trouvée par la règle en question. D'une façon générale, les règles permettent d'associer des conditions 10 et des actions. La prémisse d'une règle peut contenir une ou plusieurs clauses qui peuvent elles-mêmes prendre la forme d'un couple associant une requête à un résultat attendu. La clause est remplie lorsque le résultat de l'exécution de la règle est égal au résultat attendu. Les clauses peuvent être reliées entre 15 elles selon des connecteurs logiques (« et », « ou »...), de façon classique en soi. Les actions peuvent être choisies dans un catalogue d'actions types, prédéfinies. Il peut s'agir de requêtes également. Les actions visent à créer un ensemble de données 170 représentatives 20 de l'analyse des documents de gestion représentés dans la base de données 100. Une partie des actions consistent donc à mettre à jour cet ensemble de données 170 au fur et à mesure de l'exécution des règles sur la base 101. Ces actions peuvent donc être des requêtes visant à mettre à jour une base de données de résultats, représentant cet ensemble de données. 25 Selon un mode de réalisation, cette base de résultats forme une entité 170 fonctionnellement distincte de la base de données 101, de sorte que le moteur de règles 110 ne modifie jamais le contenu de la base de données 101, constituée des documents de gestion, et ne fasse qu'alimenter une base de résultats 170. 30 Typiquement, dans le cas d'un contrôle de documents de gestion, cette base de résultats 170 est progressivement alimentée par les détections 3061337 15 d'erreurs de cohérence au sein des documents de gestion, déterminées par l'application des règles. Une partie des actions possibles consistent donc à générer des erreurs, 5 ou autres informations destinées à alimenter la base de résultats 170. En langage très haut-niveau, on peut exprimer de telles règles sous la forme : SI ALORS Des informations complémentaires sur le type d'erreur à créer ou, pour 10 complémenter les informations qui seront associés à l'erreur dans la base de résultats 170, peuvent être définies dans les métadonnées associées à la règle. D'autres types d'actions peuvent consister à créer des catégories ou autres actions de classements des données. Une telle règle peut s'exprimer 15 sous la forme générique : SI ALORS Une telle règle permet d'ajouter une nouvelle catégorie dans la base de résultats 170 pour tous les enregistrements de la base de données 101 remplissant la ou les conditions. 20 Il est également possible de définir des règles sous la forme générique : SI ALORS fonction (paramètres) 25 Une telle règle fait appel à une action extérieure au moteur de règles 110, en lui passant des paramètres. Ces actions peuvent être définies par l'utilisateur, via une implémentation externe et intégrable au moteur lors de 1 ' exécution. 3061337 16 Le moteur de règles 110 a pour charge d'appliquer les règles sur les données stockées dans la base de données 100, c'est-à-dire d'exécuter les requêtes associées à chaque règle sur ces données. Pour ce faire, le moteur de règle peut accéder à la base de règles 120. 5 Cette base de règles 120 et le moteur de règles 110 peuvent être localisés, c'est-à-dire déployés sur un même système de traitement de l'information. Ils peuvent également être répartis sur plusieurs dispositifs de traitements connectés entre eux. Il est toutefois important que pour le moteur de règles l'accès à la base de règles soit rapide, afin d'assurer de bonnes performances 10 au système global. L'accès aux règles peut se faire par les métadonnées attachées à chaque règle. Si l'on revient à la figure 2, on voit que dans un premier temps, le 15 moteur de règle 110 récupère les règles de la base de règles 120 dans une étape 212. Dans une étape 213, le moteur de règles procède à un traitement de ces règles récupérées. Notamment, il peut procéder à leur ordonnancement. Cet 20 ordonnancement peut être guidé par les métadonnées, et notamment par la métadonnée « priorité » attachée à chaque règle stockée dans la base de règles. D'autres critères de tri des règles récupérées par le moteur de règles 110 sont évidemment possibles et envisageables. Le schéma de la base de données peut être récupéré, dans une étape 25 214, par le moteur de règles 110 afin que celui-ci puisse générer les règles en un format exploitable par le système de gestion 102. Le moteur de règles 110 peut alors mettre en place un processus itératif (zone en pointillés « Loop ») selon lequel chaque règle récupérée est traitée individuellement, de façon ordonnée. 30 Tout d'abord, dans une étape 2015, en utilisant le schéma de la base de données 101, le moteur de règles 110 peut transformer la règle en requêtes 3061337 17 exprimés selon le langage et le format propre à la base de données. Typiquement, cette conversion consiste à transformer les règles exprimées en langage DRDL, comme évoqué précédemment, en un langage plus « bas niveau », comme le langage SQL. Il peut notamment s'agir de l'évolution 5 PL/SQL (« Procedural Language / Structured Query Language »). D'autres mises en oeuvre sont toutefois possibles. Ensuite, dans une étape 216, le moteur de règles peut transmettre la requête vers le système de gestion de la base de données 102. Ce-dernier 10 exécute alors la requête sur le contenu de la base de données 101 et renvoie le résultat vers le moteur de règles 110, dans une étape 217. Celui-ci peut alors le comparer avec une valeur attendue associée à la règle. En fonction du résultat de cette comparaison, la ou les actions associées peuvent être exécutés. 15 Comme on l'a vu plus haut, une action possible consiste à alimenter le contenu de la base de résultats 170 (étape 218). Une autre action possible consiste à exécuter une fonction par un dispositif 160, extérieur au moteur de règles 110 proprement dit (étape 219). 20 Ainsi, le traitement se fait règle par règle. Le moteur de règles peut récupérer un ensemble de règles depuis la base de règles, mais les requêtes associées sont transmises et exécutées par le système de gestion de base de données une après l'autre. 25 Ce procédé se distingue fortement des mécanismes habituels de traitement massif de données, dans lesquels les données contenues dans la base de données sont récupérées dans la mémoire associée au moteur de règles afin d'y être localement traitées. Ce mécanisme correspond à un grand nombre d'outils du commerce pour le traitement de données basés sur 30 des règles et notamment : 3061337 18 - les solutions de la société IBM, tels qu'ODM (Operational Decision Manager) - des solutions en "source ouvert" (open source) ou sous forme de logiciels libres (freewares ») telles que celles décrites dans 5 l'article « Enhanced Design of a Rule Based Engine Implemented using Structured Query Language » de J Sawar Mohammad, Abdullah Unmair et Ahmed Aftab, in «Proceedings of the World Congress on Engineering", 2010, volume 1 Ces différentes solutions nécessitent typiquement la création d'objets 10 de travail (par exemple un objet Java) pour chaque donnée récupérée, et une implémentation spécifique pour le chargement de ces données selon chaque application. Selon l'invention, les données des documents de gestion ne sont pas récupérées dans la mémoire associée au moteur de règles 120, et il n'y a 15 donc pas de création d'objets de travail en mémoire (notamment d'objets Java). Tout le calcul est délégué au système de gestion de base de données 102. Seul le résultat de la requête retourné par le système de gestion 102 occupe la mémoire locale associée au moteur de règles, soit un volume 20 d'information très réduit en comparaison de la totalité de l'ensemble des données correspondant aux factures à traiter. Dans la mesure où le volume de données à traiter peut être extrêmement important, le mécanisme de l'invention permet d'économiser un temps de traitement considérable en évitant la création, et donc la 25 gestion, d'un grand nombre d'objets de travail en mémoire. Il n'est pas non plus nécessaire de transmettre ce grand volume de données entre la base de données 101 et la mémoire associée au moteur de règles 120. Selon l'invention, uniquement des requêtes et des résultats sont transmis, ce qui représente des volumes de données bien moindre. On peut 30 ainsi économiser un temps substantiel en évitant le transfert d'un important 3061337 19 volume de données ayant potentiellement à transiter sur un réseau de communication. Cette économie est d'autant plus importante que dans le cadre de l'invention, qui consiste à appliquer des règles sur des données de gestion, 5 les règles sont relativement peu nombreuses (la plupart étant définie par des opérateurs humains). En outre, dans la mesure où le système de gestion 102 est adapté au mieux à la base de données 101, on obtient une haute performance d'exécution de la requête, au détriment d'un échange d'information pour 10 chaque règle. Toutefois comme l'impact de ces transmissions d'information est très réduit, comme nous venons de le voir, le bilan global est très largement positif Ainsi, des tests ont été effectués afin de comparer les performances du 15 mécanisme selon l'invention et un mécanisme basé sur une solution consistant à récupérer les données depuis la base 101 et à créer des objets de travail en mémoire, telle que celle d'IBM ou des solutions Open Source. Il en résulte que l'invention permet d'atteindre un gain très substantiel pouvant dépasser un facteur 10. 20 Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. REVENDICATIONS1. Procédé pour l'analyse de documents de gestion relatifs à une entreprise, lesdits documents de gestion étant stockés dans une base de données relationnelle (101), sous la forme d'un ensemble de données, comportant : la récupération de règles à partir d'une base de règles (120), par un moteur de règles (110), puis, de façon itérative, pour chacune desdites règles, la transmission par ledit moteur de règles (110) d'au moins une requête associée à ladite règle vers un système de gestion (102) de ladite base de données, la comparaison du résultat de l'exécution de ladite requête sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, l'exécution d'une action associée à ladite règle. 2. Procédé selon la revendication précédente, dans lequel les règles sont générées à partir d'un langage haut-niveau. 3. Procédé selon l'une des revendications précédentes, dans lequel les règles récupérées sont transformés en requêtes exprimés selon ledit système de gestion en utilisant le schéma (103) de ladite base de données. 4. Procédé selon la revendication précédente, dans lequel lesdites requêtes transformées sont exprimées en SQL ou PL/SQL et exécutée dans ledit système de gestion de données. 3061337 21 5. Procédé selon la revendication précédente, dans lequel lesdits documents de gestion sont des factures et dans lequel lesdites actions sont prévues pour vérifier la cohérence des données dudit ensemble. 5 6. Procédé selon l'une des revendications précédentes, dans lequel ladite action peut alimenter une base de résultat (170), fonctionnellement distincte de ladite base de données (101). 7. Procédé selon l'une des revendications précédentes, dans lequel 10 ladite action peut déclencher l'exécution d'une fonction par un dispositif (160) extérieur audit moteur de recherche (110) 8. Procédé selon l'une des revendications précédentes dans lequel ladite base de règles (120) est un entrepôt de règles. 15 9. Produit logiciel comportant des instructions exécutables par une plateforme de traitement de l'information pour mettre en oeuvre le procédé selon l'une des revendications précédentes. 20 10. Système pour l'analyse de documents de gestion relatifs à une entreprise, comportant un outil de prétraitement adapté pour structurer lesdits documents en un ensemble de données associant un identifiant de champ à au moins une valeur de champ, puis à stocker lesdites données dans une base de données relationnelle, et comportant également un moteur de 25 règles (110) adapté pour récupérer des règles à partir d'une base de règles (120) selon un ordonnancement qui est fonction de métadonnées associées auxdites règles, pour chacune desdites règles, transmettre une requête associée à ladite règle vers un système de gestion (102) de ladite base de données, comparer ledit résultat de l'exécution de ladite requête 3061337 22 sur ledit ensemble de données avec un résultat attendu associé à ladite règle, et, en fonction du résultat de ladite comparaison, exécuter une action associée à ladite règle. 5