FR2989190A1 - Entite de traitement d'un flux de donnees, procede et programme d'ordinateur correspondant - Google Patents

Abstract

Il est proposé une entité de traitement d'un flux de données, comprenant : des moyens d'acquisition du flux de données, comprenant des moyens d'extraction, à partir du flux de données, d'au moins un identifiant d'un type prédéterminé, des moyens de sélection d'au moins une règle de traitement du flux de données, parmi une pluralité de règles de traitement, les moyens de sélection tenant compte d'au moins une information associée à la règle de traitement et représentative d'un historique d'utilisation de la règle de traitement pour le traitement d'un flux de données comportant l'identifiant extrait, - des moyens de fourniture d'au moins une règle de traitement.

Description

Entité de traitement d'un flux de données, procédé et programme d'ordinateur correspondant 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui du traitement de l'information, notamment par des applications logicielles distantes installées sur des serveurs informatiques. Plus précisément, de telles applications sont accessibles par l'intermédiaire d'un réseau de communication interne (par exemple un Intranet) ou par l'intermédiaire d'Internet, comme c'est le cas par exemple des applications de type SaaS ("Software as a Service" selon la terminologie anglaise), c'est à dire des "Logiciel en tant que service", permettant à des clients d'externaliser certains de leurs traitements auprès de fournisseurs, par le biais de logiciels dédiés, offrant une interface internet accessible par exemple au moyen d'un abonnement. De telles applications peuvent être utilisées dans de nombreux départements d'une entreprise, par exemple dans le cadre de la gestion de la relation client (GRC, ou CRM pour "Customer Relationship Management" selon la terminologie anglaise), des services informatiques (organisation de conférences WEB par exemple), du secrétariat (prise de rendez-vous), de la sécurité ou encore de la comptabilité... 2. ARRIÈRE-PLAN TECHNOLOGIQUE On s'attache plus particulièrement dans la suite de ce document à décrire la problématique existant dans le domaine des SaaS, à laquelle ont été confrontés les inventeurs de la présente demande de brevet. L'invention ne se limite bien sûr pas à ce domaine particulier d'application, mais présente un intérêt pour toute technique de traitement de l'information devant faire face à une problématique proche ou similaire. Traditionnellement, les règles de traitement des applications logicielles SaaS mettent en oeuvre des compétences métier et nécessitent d'être paramétrées par le fournisseur du service accessible par le biais de l'application SaaS. Une première solution consiste, pour le fournisseur du service, à effectuer un paramétrage des règles de traitement en fonction des besoins de chaque entreprise cliente, ce qui est coûteux en terme de temps mais permet de disposer d'une solution adaptée au besoin de chaque client.

Par exemple, dans le domaine de la comptabilité, une solution du marché consiste à proposer un paramétrage individuel, effectué pour chaque entreprise cliente, des règles de comptabilité associées à chaque fournisseur de l'entreprise cliente. Il existe aussi des applications SaaS dans lesquelles le fournisseur utilise un même paramétrage (ou étalon) pour l'ensemble de ses clients. Par exemple, dans le domaine de la comptabilité, le fournisseur de services peut définir un paramétrage type (ou étalon) pour encadrer la création et l'usage des comptes du dossier comptable de chacun de ses clients. Ces solutions souffrent de deux inconvénients majeurs : d'une part, l'étalon n'est adapté qu'à un nombre restreint de clients et/ou de situations.

De ce fait, il peut ne pas convenir à un nouveau client, ou ne pas prendre en compte une situation particulière, ce qui oblige alors le fournisseur à effectuer un traitement manuel. d'autre part, chaque fournisseur de service doit définir son propre étalon. De plus, l'étalon est souvent créé par un seul employé du fournisseur, et de ce fait, la connaissance métier n'est pas partagée chez le fournisseur. Ceci fragilise le fournisseur de service en cas de départ par exemple de la personne qui a créé l'étalon. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.

Par exemple, l'un des objectifs d'au moins un mode de réalisation de l'invention est, dans le domaine de la comptabilité, d'éviter à chaque fournisseur de service la nécessité d'un paramétrage personnalisé pour chaque entreprise cliente, et les lourdeurs qui s'ensuivent, tout en lui offrant une souplesse de fonctionnement que n'offre pas un logiciel à paramétrage fixe (ou étalon).

Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui fiabilise la définition des règles de traitement utilisées dans les applications. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui permette un gain en productivité à un fournisseur du service. 4. EXPOSÉ DE L'INVENTION L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur. En effet, l'invention concerne une entité de traitement d'un flux de données, comprenant : des moyens d'acquisition dudit flux de données, comprenant des moyens d'extraction, à partir dudit flux de données, d'au moins un identifiant d'un type prédéterminé, des moyens de sélection d'au moins une règle de traitement dudit flux de données, parmi une pluralité de règles de traitement, lesdits moyens de sélection tenant compte d'au moins une information associée à ladite au moins une règle de traitement et représentative d'un historique d'utilisation de ladite au moins une règle de traitement pour le traitement d'un flux de données comportant ledit au moins un identifiant extrait, des moyens de fourniture de ladite au moins une règle de traitement. Selon une caractéristique particulière de l'invention, l'entité de traitement peut notamment consister en un terminal de communication, ou un serveur applicatif, 15 communiquant avec un terminal de communication par le biais d'un réseau de communication. L'invention permet ainsi de proposer automatiquement, à un utilisateur d'une entité, des règles de traitement d'un flux de données, susceptibles d'être adaptées à un traitement en cours sur l'entité, pour le contexte représenté par l'identifiant extrait d'un flux de données. 20 L'invention permet donc à une entreprise de gagner en productivité dans l'utilisation d'une application, en diminuant le coût de saisies répétitives, ou d'un paramétrage manuel de l'application, ainsi qu'en fiabilité, puisque les règles de traitement fournies sont sélectionnées à partir d'un historique de leur utilisation passée. L'invention permet donc de limiter par exemple les erreurs de saisie. 25 De plus, l'invention permet également une meilleure traçabilité des traitements, puisqu'elle incite à l'utilisateur à opter pour une des règles de traitement proposées, et donc à choisir la même règle de traitement pour un même contexte de traitement (représenté par l'identifiant extrait). En particulier, lorsqu'il s'agit d'opérations de saisie, dans des contextes récurrents, l'invention permet de s'assurer que les saisies seront toujours effectuées de la 30 même façon, de façon à permettre un meilleur suivi ultérieur de ces saisies.

Selon un mode de réalisation particulier de l'invention, lesdits moyens d'extraction appartiennent au groupe comprenant : des moyens de reconnaissance optique de caractères ; des moyens de reconnaissance vocale de caractères ; des moyens d'analyse d'informations numériques structurées, par exemple des documents de type EDI (pour Echange de Données Informatisées, ou Electronic Data Interchange selon la terminologie anglaise), comme des factures EDI, ou des données au format SEPA (pour Single Euro Payments Area), comme des relevés bancaire par exemple; - des moyens de reconnaissance de codes-barres ou de flashcode; une combinaison de plusieurs desdits moyens précités. Selon une caractéristique particulière de l'invention, lesdits moyens de sélection tiennent compte de règles de traitement utilisées par une pluralité de terminaux de communication.

Ainsi l'invention permet à une communauté d'utilisateurs de mutualiser leurs connaissances, et en particulier à un utilisateur novice d'être guidé par les choix faits antérieurement par un utilisateur plus expérimenté. L'invention favorise également l'émergence de standard, par la fourniture de règles communes à une communauté de terminaux, et notamment à des terminaux de différentes entreprises du même domaine technique. Selon une caractéristique particulière de l'invention, lesdits moyens de sélection comprennent des moyens de tri des règles de traitement sélectionnées en fonction d'une probabilité d'utilisation tenant compte desdites informations associées auxdites règles de traitement.

Dans certains modes de réalisation, l'invention permet en particulier de fournir les règles de traitement de façon à privilégier celles dont la probabilité d'utilisation semble la plus forte, c'est-à-dire celles qui potentiellement ont le plus de chance de correspondre aux souhaits de l'utilisateur de l'entité. Selon une caractéristique particulière de l'invention, lesdits moyens de sélection 30 comprennent en outre des moyens de restriction du nombre de règles de traitement sélectionnées à un nombre maximal prédéfini de règles de traitement.

Certains modes de réalisation de l'invention permettent ainsi de limiter le nombre de règles de traitement proposées, de façon par exemple à simplifier le choix d'un utilisateur. Selon une caractéristique particulière de l'invention, lesdits moyens de restriction limitent lesdites règles de traitement sélectionnées aux règles de traitement triées les plus probables. Certains modes de réalisation de l'invention offrent ainsi l'avantage de ne présenter que les règles de traitement les plus pertinentes, de façon par exemple à ne pas proposer de règle correspondant à une pratique isolée, non partagée par une communauté d'utilisateurs, ou représentative d'une utilisation erronée passée.

Selon une caractéristique particulière de l'invention, ladite entité de traitement comprend des moyens préalables de définition dudit nombre maximal prédéfini de règles de traitement à sélectionner. Selon un mode de réalisation particulier de l'invention, ladite entité de traitement comprend en outre des moyens de validation d'une desdites règles de traitement fournies, et des moyens de mise à jour de ladite information associée à ladite règle de traitement validée. Ainsi, la solution de l'invention, dans certains modes de réalisation, permet de tenir compte de l'utilisation d'au moins une des règles fournies, en liaison avec l'identifiant extrait, pour les futures sélections de règles de traitement. Selon une caractéristique particulière de l'invention, ladite entité de traitement 20 comprend en outre des moyens d'enregistrement d'une nouvelle règle de traitement, dans ladite pluralité de règles de traitement. Ainsi, la solution de l'invention, dans certains modes de réalisation, permet de prendre en compte une nouvelle règle de traitement, saisie manuellement par un utilisateur par exemple, et donc d'ajouter dynamiquement cette nouvelle règle à la pluralité de règles de 25 traitement à considérer. Selon une caractéristique particulière de l'invention, lesdits moyens d'enregistrement sont mis en oeuvre automatiquement, lors de chaque utilisation d'une nouvelle règle de traitement. De tels modes de réalisation permettent d'enregistrer systématiquement l'utilisation 30 d'une nouvelle règle, sans aucune action spécifique de l'utilisateur et offrent donc des avantages de termes de simplicité d'utilisation, de productivité et de fiabilité (l'enregistrement étant systématique). Selon une caractéristique particulière de l'invention, lesdits moyens d'enregistrement comprennent des moyens de confirmation mis en oeuvre avant l'enregistrement d'une nouvelle règle de traitement. De tels modes de réalisation permettent à un utilisateur de n'enregistrer que s'il le souhaite une nouvelle règle de traitement qu'il utilise. Ainsi, un utilisateur peut « tester » plusieurs fois une nouvelle règle de traitement avant de l'enregistrer, ou ne pas enregistrer certaines règles, d'application exceptionnelle, ou liées à un savoir-faire jugé confidentiel par exemple. Dans certains modes de réalisation, les moyens de confirmation peuvent également mettre en oeuvre des autorisations spéciales. Selon un autre aspect, l'invention concerne un procédé de traitement d'un flux de données, comprenant : une étape d'acquisition dudit flux de données, comprenant une sous-étape d'extraction, à partir dudit flux de données, d'au moins un identifiant d'un type prédéterminé, une étape de sélection d'au moins une règle de traitement dudit flux de données, parmi une pluralité de règles de traitement, ladite étape de sélection tenant compte d'au moins une information associée à ladite au moins une règle de traitement et représentative d'un historique d'utilisation de ladite au moins une règle de traitement pour le traitement d'un flux de données comportant ledit au moins un identifiant extrait, une étape de fourniture de ladite au moins une règle de traitement. Avantageusement, le procédé de traitement de l'invention comprend des étapes mettant en oeuvre les moyens de l'entité de traitement telle que décrite précédemment, dans l'un quelconque de ses différents modes de réalisation. Selon un autre aspect, l'invention concerne un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 décrit le principe général de l'invention ; la figure 2 illustre la structure d'une entité de traitement selon un mode de réalisation de l'invention ; la figure 3 illustre une mise en oeuvre du procédé selon un mode de réalisation de l'invention. 6. DESCRIPTION DÉTAILLÉE 6.1 Principe général On présente, en relation avec la figure 1, le principe général de l'invention. Dans le mode particulier de réalisation présentée, l'invention est mise en oeuvre par un serveur de communication 100, sur lequel s'exécute une application 102 de type SaaS, adaptée au domaine de la comptabilité.

Une telle entité est connectable à un réseau de communication de façon à ce que l'application 102 soit accessible à un utilisateur d'un terminal de communication 120. Le principe général de l'invention consiste à utiliser les traitements opérationnels effectués par un ou plusieurs fournisseurs de service dans le cadre de l'application SaaS 102, et en particulier les règles applicatives choisies opérationnellement par ces fournisseurs, pour enrichir une base de connaissances des règles de traitement à utiliser, correspondant à des compétences métier communes au domaine technique considéré. Plus précisément, selon l'invention, l'entité de traitement 100 mémorise d'une part les règles de traitement utilisées en les associant au contexte opérationnel de leur application puis, d'autre part, sélectionne des règles de traitement potentiellement adaptées à un traitement en cours d'un utilisateur, en lien avec un contexte particulier, en tenant compte des utilisations précédentes de ces règles en lien avec ce même contexte, pour les proposer à l'utilisateur. En d'autres termes, l'entité de traitement 100 déduit des utilisations passées une probabilité de pertinence de la règle à utiliser, dans le contexte particulier du traitement. En particulier, dans certains modes de réalisation, l'entité de traitement 100 peut fournir 30 uniquement quelques règles considérées comme les plus pertinentes.

Par exemple, dans le cas d'une mise en oeuvre de l'invention dans le domaine de la comptabilité, l'invention permet de fournir, lors de la saisie d'une pièce comptable ayant trait à un fournisseur d'un client, les comptes de charge ayant le plus de probabilité d'être appropriés.

Ainsi, selon l'invention, le compte de charge 626000 peut être proposé, avec une probabilité de 95% de pertinence, en contrepartie d'un numéro de SIRET identifiant un opérateur de télécommunication particulier. Dans au moins un mode de réalisation, l'invention permet notamment à plusieurs fournisseurs de service de partager une même base de connaissance, afin d'enrichir leurs connaissances mutuelles. Ainsi, chaque fournisseur peut bénéficier des apports effectués par l'ensemble des fournisseurs de service utilisant la même application SaaS. Par exemple, dans le cas d'une mise en oeuvre de l'invention dans le domaine de la comptabilité, tous les cabinets comptables utilisant l'application SaaS mise en oeuvre sur l'entité de traitement 100 peuvent partager une base commune de règles de traitement pour certaines connaissances comptables. 6.2 Structure d'une entité de communication selon l'invention On présente, en relation avec les figures 1 et 2, la structure simplifiée d'une entité de traitement selon l'invention.

Une telle entité comprend une mémoire 112 comprenant une mémoire tampon, une unité de traitement 114, équipée par exemple d'un microprocesseur FP, et pilotée par un programme d'ordinateur 116, dont l'exécution met en oeuvre un procédé de traitement d'un flux de données, selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 116 sont par 25 exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 114. L'unité de traitement 114 reçoit en entrée un entête d'un flux de données. Le microprocesseur de l'unité de traitement 114 met en oeuvre les étapes du procédé de traitement d'un flux de données décrit précédemment, selon les instructions du programme 30 d'ordinateur 116. A cette fin, l'entité de traitement comprend, outre la mémoire tampon 112 : des moyens d'acquisition 104 du flux de données, comprenant des moyens d'extraction 106, à partir du flux de données, d'au moins un identifiant d'un type prédéterminé, des moyens de sélection d'au moins une règle de traitement dudit flux de données, parmi une pluralité de règles de traitement, lesdits moyens de sélection tenant compte d'au moins une information associée à ladite règle de traitement et représentative d'un historique d'utilisation de ladite règle de traitement pour le traitement d'un flux de données comportant ledit identifiant extrait, des moyens de fourniture de ladite règle de traitement.

Ces moyens sont pilotés par le microprocesseur de l'unité de traitement 112. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "moyens" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour les moyens concernés. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set- top-box, routeur, etc...) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc...). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. L'entité de traitement décrite ci-dessus est destinée au paramétrage d'applications SaaS, et en particulier, comme présenté dans les figures 1 à 3, à des applications SaaS du domaine de la comptabilité. Il est clair toutefois qu'il peut aisément être adapté à de nombreuses autres applications, sans sortir du cadre de l'invention. On présente à présent, en liaison avec la figure 3, un exemple de mise en oeuvre du procédé de l'invention. 6.3 Description d'un mode de réalisation de l'invention 6.3.1 Fourniture d'une règle de traitement à un utilisateur Dans le mode de réalisation présenté, un utilisateur du terminal de communication 120 transmet à l'entité de traitement 100 un flux de données correspondant à un document numérisé, par exemple par un module de numérisation du terminal 120. Le document numérisé peut ainsi consister en une pièce comptable à saisir, par exemple la facture d'un fournisseur du client de l'application SaaS 102. Ce flux de données est reçu, lors d'une étape d'acquisition 200, par des moyens 104 d'acquisition d'un flux de données de l'entité de traitement. Ces moyens d'acquisition d'un flux de données comprennent notamment des moyens d'extraction 106 d'un identifiant d'un 15 type déterminé du flux de donnés reçu. Dans le mode de réalisation présenté, les moyens d'extraction consistent en des moyens de reconnaissance optique de caractères (ou OCR pour « Optical Character Recognition » selon la terminologie anglaise), qui lui permettent d'extraire, à partir du document numérisé reçu du terminal 120, au moins un identifiant d'un type prédéterminé. Il 20 peut par exemple s'agir d'un identifiant d'une entreprise, comme en France son identifiant auprès du registre du commerce et des sociétés (ou numéro RCS), ou dans un répertoire d'entreprises, comme le numéro de SIREN (pour « Système d'Identification du Répertoire des Entreprises »), identifiant de façon unique une entreprise, ou encore d'un code identifiant l'un de ses établissements (comme, en France, un code SIRET (pour « Système d'Identification du 25 Répertoire des Etablissements »), son secteur d'activité (comme, en France, un code APE (pour « Activité Principale Exercée ») ou NAF (pour « Nomenclature des Activités Française »)) ou un taux de taxe à appliquer (comme, en France, la TVA, (pour « Taxe sur la Valeur Ajoutée »). L'identifiant est par exemple reconnu par le module OCR grâce à un mot clé (« RCS », « SIREN », « SIRET », « APE », « NAF », « TVA » ...) qui le précède. 30 Dans d'autres modes de réalisation, éventuellement complémentaires, les identifiants peuvent être obtenus par d'autres moyens, par exemple du fait d'un positionnement particulier d'au moins un identifiant dans le flux de données, par une saisie manuelle du fournisseur de service ou de son client, par la lecture d'un fichier contenu dans un support électronique (comme un CD ROM, une clé USB, ou un disque dur) ou encore par des moyens de reconnaissance vocale.

Lorsque l'utilisateur se connecte à l'application SaaS et ouvre la pièce numérisée pour saisir l'écriture comptable correspondante, le procédé de traitement comprend une étape de sélection 202, par les moyens de sélection de l'entité de traitement, de certaines règles de traitement. Il s'agit ainsi, dans l'exemple illustré, de la sélection de certaines racines de comptes de charge. Dans le mode de réalisation présenté, cette étape de sélection peut notamment comprendre une étape d'interrogation 202 d'une base de données 108, mémorisant l'ensemble des racines de comptes définies et pour chaque racine de compte, au moins un information représentative de son historique d'utilisation pour le traitement d'une pièce comptable comportant l'identifiant extrait. La base de données 108 peut notamment être partagée par plusieurs cabinets comptables, de façon à mutualiser leurs connaissances. Dans certains modes de réalisation, et en particulier dans le mode de réalisation détaillé, les moyens de sélection de l'entité de traitement 100 peuvent comprendre des moyens de tri des racines de compte en fonction de leur probabilité d'utilisation. Selon les modes de réalisation, la probabilité d'utilisation d'une règle de traitement peut être calculée et mise à jour lors de chaque interrogation de la base de données 108 et/ou lors de chaque mise à jour de la base de données 108, comme commenté plus loin en liaison avec la figure 3. Le procédé de l'invention comprend de plus une étape 204 de fourniture des règles de traitement. Dans l'exemple illustré, les moyens de fourniture des règles de traitement comprennent des moyens de comparaison des racines de compte sélectionnées au plan comptable du client de l'application SaaS 102, afin de déterminer les comptes de charge du client à fournir. Les moyens de sélection peuvent également comprendre, dans certains modes de réalisation, des moyens de restriction du nombre (N) de règles sélectionnées, de façon par exemple à ne présenter que les N règles les plus probables. Dans d'autres modes de réalisation, éventuellement complémentaires, les moyens de restriction des règles sélectionnées peuvent également tenir compte d'un seuil minimum de probabilité d'utilisation. Les moyens de fourniture peuvent également comprendre des moyens d'indications de la probabilité d'utilisation de règles de traitement sélectionnées. Ainsi, dans l'exemple illustré, si le flux de données correspond à la numérisation d'une facture d'un opérateur de télécommunication, l'étape de fourniture 204 aboutira par exemple à la proposition : du compte de charge « 6261000 » avec un taux de taxe applicable (TVA pour « Taxe sur la Valeur Ajoutée » en France) de 19,6%, proposé avec une probabilité de 95% ; du compte de charge « 6263000 » avec taux de taxe applicable de 19,6%, proposé avec une probabilité de 3%. 6.3.2 Enrichissement de l'historique d'utilisation Dans le mode de réalisation présenté, le procédé de traitement comprend une étape 206 de validation d'une règle de traitement. Il peut s'agir d'une règle de traitement choisie parmi les règles de traitement fournies ou d'une nouvelle règle de traitement saisie manuellement par un utilisateur (par exemple parce qu'aucune des règles fournies ne lui convient). Dans l'exemple illustré en figure 3, l'utilisateur choisit l'un des comptes fourni.

L'écran de saisi est alors pré-paramétré en fonction des informations déduites de son plan comptable ou reconnues par le module OCR. Lorsque l'une des règles de traitement fournie est validée (par exemple, dans l'exemple proposé, lorsque l'utilisateur valide l'écran de saisie), les informations associées aux règles de traitement et représentatives de l'historique d'utilisation des règles de traitement sont mises à jour. Par exemple, dans l'exemple illustré, on enregistre une association entre le tiers, identifié par son numéro de SIREN, un taux de TVA à 19,6% et la racine du compte de contrepartie validé. Cette mémorisation peut notamment mettre en oeuvre une étape 208 de mise à jour de la base de données 108. Lorsque l'usage de la règle de traitement, en association avec l'identifiant extrait, est 30 déjà connue, la mise à jour peut par exemple consister en l'incrémentation d'un compteur d'usage d'une règle, ou d'un calcul d'un pourcentage d'utilisation de chaque règle avec cet identifiant. Dans l'exemple présenté, si le fournisseur est déjà connu, la mise à jour peut ainsi consister à incrémenter l'usage du compte « 6261000 » avec l'identifiant SIREN du fournisseur, pour renforcer le taux de certitude d'usage de ce compte de contrepartie, pour les prochaines factures à saisir émises par le même fournisseur. 6.4 Variante de réalisation Dans certains modes de réalisation de l'invention, les moyens de sélection peuvent tenir compte d'informations représentatives de l'historique d'utilisation d'une règle de traitement correspondant à plusieurs types prédéterminés différents d'identifiants. En particulier, les moyens de sélection peuvent tenir compte, pour le choix des types prédéterminés d'identifiants à utiliser, de la valeur de certains identifiants extraits. Par exemple, dans le cadre de l'exemple illustré, un premier identifiant extrait peut représenter la catégorie socio-professionnelle d'un tiers. L'identification de certaines catégories socio-professionnelles peut être suffisante pour déterminer les règles de traitement les plus probables et donc les règles de traitement à fournir. En effet, certains types de tiers (fournisseurs, clients) ont une faible probabilité d'être rencontrés sur d'autres dossiers comptables. C'est le cas par exemple des restaurateurs, ou de clients correspondant à des particuliers, à des artisans ou de très petites entreprises (ou TPE) de certains secteurs d'activité particuliers. Aussi, dans certains modes particuliers de réalisation de l'invention, les moyens de sélection tiendront simplement compte, pour certains codes particuliers NAF, de l'historique d'utilisation des règles de traitement avec ces codes NAF. En d'autres termes, la sélection des règles de traitement sera alors identique pour l'ensemble des flux de données liés à des tiers ayant ce code NAF. L'entité de traitement fournira par exemple à un utilisateur les cinq comptes les plus probables pour un code NAF donné. D'autres codes NAF, qui correspondent par exemple à des fournisseurs représentant des dépenses récurrentes d'un cabinet comptable, auxquelles est associé un compte de charge particulier, ne permettront pas à eux seuls la sélection de règles de traitement. Les moyens de sélection pourront alors tenir compte d'un historique d'utilisation des règles de traitement en relation avec un flux de données associé à un identifiant représentant un unique fournisseur. Dans de tels modes de réalisation, les moyens de sélection pourront comprendre des moyens de comparaison d'identifiants extraits, de types prédéterminés particuliers, avec des valeurs prédéterminées de ces identifiants, permettant de définir les informations associées auxdites règles de traitement à prendre en compte.

Claims (1)

1. REVENDICATIONS1. Entité de traitement d'un flux de données, caractérisée en ce qu'elle comprend : des moyens d'acquisition dudit flux de données, comprenant des moyens d'extraction, à partir dudit flux de données, d'au moins un identifiant d'un type prédéterminé, des moyens de sélection d'au moins une règle de traitement dudit flux de données, parmi une pluralité de règles de traitement, lesdits moyens de sélection tenant compte d'au moins une information associée à ladite au moins une règle de traitement et représentative d'un historique d'utilisation de ladite au moins une règle de traitement pour le traitement d'un flux de données comportant ledit au moins un identifiant extrait, des moyens de fourniture de ladite au moins une règle de traitement. Entité de traitement d'un flux de données selon la revendication 1, caractérisée en ce que lesdits moyens de sélection tiennent compte de règles de traitement utilisées par une pluralité de terminaux de communication. Entité de traitement d'un flux de données selon l'une quelconque des revendications 1 à 2, caractérisée en ce que lesdits moyens de sélection comprennent des moyens de tri des règles de traitement sélectionnées en fonction d'une probabilité d'utilisation tenant compte desdites informations associées auxdites règles de traitement. Entité de traitement d'un flux de données selon l'une quelconque des revendications 1 à 3, caractérisée en ce que lesdits moyens de sélection comprennent en outre des moyens de restriction du nombre de règles de traitement sélectionnées à un nombre maximal prédéfini de règles de traitement. Entité de traitement d'un flux de données selon l'une des revendications 1 à 4, caractérisée en ce qu'elle comprend en outre des moyens de validation d'une desdites règles de traitement fournies, et des moyens de mise à jour de ladite information associée à ladite règle de traitement validée. Entité de traitement d'un flux de données selon l'une des revendications 1 à 5, caractérisée en ce qu'elle comprend en outre des moyens d'enregistrement d'une nouvelle règle de traitement, dans ladite pluralité de règles de traitement.2. 3. 4. 5. 6.7. Entité de traitement d'un flux de données selon la revendication 6, caractérisée en ce que lesdits moyens d'enregistrement sont mis en oeuvre automatiquement, lors de chaque utilisation d'une nouvelle règle de traitement. 8. Entité de traitement d'un flux de données selon l'une des revendications 6 à 7, caractérisée en ce que lesdits moyens d'enregistrement comprennent des moyens de confirmation mis en oeuvre avant l'enregistrement d'une nouvelle règle de traitement. 9. Procédé de traitement d'un flux de données, caractérisé en ce qu'il comprend : une étape d'acquisition dudit flux de données, comprenant une sous-étape d'extraction, à partir dudit flux de données, d'au moins un identifiant d'un type prédéterminé, - une étape de sélection d'au moins une règle de traitement dudit flux de données, parmi une pluralité de règles de traitement, ladite étape de sélection tenant compte d'au moins une information associée à ladite au moins une règle de traitement et représentative d'un historique d'utilisation de ladite au moins une règle de traitement pour le traitement d'un flux de données comportant ledit au moins un identifiant extrait, une étape de fourniture de ladite au moins une règle de traitement. 10. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé selon au moins la revendication 9, lorsque ledit programme est exécuté sur un ordinateur.20