TITRE : Procédé d'extraction Semi Automatique de données sensibles dans des documents, soumis à une stricte confidentialité de ces données

[0001] La présente invention se rapporte au domaine de l'extraction de données issues de documents matériels (papier) ou digitaux (fichiers images informatiques) de type Document Tabulaire Référencé dont les cases sont remplies de données en caractères d'imprimerie.

[0002] Dans de nombreux domaines, il importe de pouvoir extraire de manière automatisée ou semi-automatisée de telles données pour alimenter en données des processus ultérieurs.

[0003] On utilise classiquement à cette fin des outils de reconnaissance de caractères, dits d'OCR (Optical Character Recognition), permettant d'engendrer des chaînes de caractères de type ASCII (American Standard Code for Information Interchange) à partir de fichiers images des documents à traiter.

[0004] Les données extraites de ces fichiers résultant de l'OCR peuvent ensuite faire l'objet de traitements informatiques adaptés à différents besoins.

[0005] Ces traitements peuvent comprendre par exemple des opérations de vérification, de calculs ou d'évaluations.

[0006] Un exemple d'application de ce qui précède concerne le domaine de la finance et de la comptabilité.

[0007] Dans ce domaine, des Documents Tabulaires Référencés doivent être édités par les entreprises, par exemple pour déclarer leurs résultats annuels, ou pour éditer des bulletins de salaire. Ce remplissage peut s'effectuer par des frappes dactylographiques positionnées sur les bonnes cases du Document Tabulaire Référencé vierge ou, plus modernement, à travers des logiciels d'édition de Documents-images basés sur, en fond de page, le modèle standardisé, et les données concernées extraites des Bases de données de l'entreprise, et inscrites dans les cases concernées. [0008] Ces Documents Tabulaires Référencés se présentent comme des successions répertoriées de pages de tableaux constituées de lignes et de colonnes où les données numériques (financières, salariales ou comptables) sont renseignées par les utilisateurs dans des cases rectangulaires matérialisées et dont la nature est indiquée par des rubriques alphanumériques en tête de lignes et de colonnes. Chaque case est ainsi identifiée comme l'intersection d'une ligne et d'une colonne.

[0009] Souvent, le Document Tabulaire Référencé associe aux lignes, des Identifiants figurant en tête de ligne, à droite de la rubrique alphanumérique, mais ce n'est pas toujours le cas (exemple des bulletins de salaires, où, pour les besoins de l'invention, on devra définir arbitrairement de tels identifiants), alors que, pour les colonnes, on devra dans pratiquement tous les cas, convenir d'identifiants arbitraires. Parfois, certaines cases sont précédées d'un identifiant individuel la caractérisant, mais c'est trop exceptionnel pour baser le procédé sur ceux-ci. On sera donc amené à attribuer à toute case un identifiant- case composé de l'identifiant-ligne concaténé à l'identifiant-colonne de la case.

[0010] Le sujet de l'invention est le dépouillement de ces Documents Tabulaires Référencés pour en extraire les valeurs aux fins de calculs divers de nature financière, comptable ou administrative afin de répondre à des besoins spécifiques (par exemple, les calculs de crédit d'impôt Recherche à partir des Bulletins de salaires des chercheurs).

[0011] En traitant les Documents Tabulaires Référencés ainsi remplis avec des outils d'OCR, on peut tenter d'en extraire les couples identifiant/valeur de chaque case remplie, ces couples étant placés dans un fichier de résultats structuré en vue d'une exploitation ultérieure, sous réserve de possibles erreurs d'OCR, les techniques d'OCR ne pouvant jamais garantir l'exactitude des caractères reconnus, réserve qui devra être levée par le Procédé inventé.

[0012] Cette exploitation peut comprendre, selon un autre exemple lié aux résultats financiers, l'utilisation du fichier de résultats par le département d'évaluation des risques d'une banque : les couples identifiant/montant extraits des comptes d'une entreprise permettent en effet de reconstituer immédiatement et automatiquement le profil de risque financier associé à cette entreprise, par application de ratios et de calculs classiques dans le domaine de la finance.

[0013] En fonction du profil de risque obtenu, l'établissement bancaire pourra par exemple décider d'accorder ou non un prêt bancaire à l'entreprise concernée.

[0014] Il existe une forte demande notamment de la part des établissements bancaires pour que les données extraites des Documents Tabulaires Référencés remplis par les entreprises soient fiables, c'est-à-dire qu'elles aient fait l'objet d'une vérification.

[0015] Il existe en effet un certain nombre de facteurs qui peuvent conduire à la production d'erreurs dans les couples identifiant/montant extraits avec les outils de traitement automatisé ou semi-automatisé disponibles dans l'état de la technique.

[0016] Parmi ces facteurs d'erreur, on compte les erreurs inhérentes à l'utilisation d'outils d'OCR : par exemple, un chiffre détérioré par l'impression dans une case du Document Tabulaire Référencé alimenté par l'entreprise peut donner lieu à une mauvaise interprétation par l'outil d'OCR (on parle alors de « substitution »).

[0017] Un autre facteur d'erreur est lié à la variabilité des Documents Tabulaires Référencés utilisés par les entreprises.

[0018] Il existe en effet des Modèles de Documents Tabulaires conçus par l'Administration Française - désignés par formulaires « CERFA » que l'on a pris l'habitude d'utiliser comme documents de référence pour les résultats financiers des Entreprises (« Bilans »), ayant l'avantage d'exister et d'être normalisés et gérés par l'Etat.

[0019] Cependant, les formulaires CERFA sont des Modèles de Documents Tabulaires à finalité fiscale, et non comptable, et les éditeurs de Bilans Comptables sont conduits à créer des versions « modifiées » pour répondre à leurs besoins « métiers ». Ils sont ainsi amenés à créer des Documents Tabulaires Référencés qui sont des documents mixtes jouant le double rôle de Documents envoyés à l'Administration Fiscale comme déclaration d'impôts, et de Document Comptable reflétant l'évolution financière de l'Entreprises. [0020] De ce fait, les Documents Tabulaires Référencés s'inspirent des formulaires CERFA tout en y ajoutant des informations financières complémentaires, selon des formes non réglementées, introduisant une variabilité non contrôlée, l' Administration fiscale acceptant ces Documents Tabulaires Référencés du moment où elle y trouve ce qu'elle demande, mais les ajouts comptables compliquent, par leur variabilité non contrôlée, leur extraction automatique de données aux fins d'analyses financières.

[0021] Ces Documents Tabulaires Référencés, modifiés par rapport aux Modèles de Documents Tabulaires, peuvent comprendre des commentaires, des cases, des lignes, des colonnes supplémentaires. A titre d'exemple, sur la figure 3, une 4éme colonne est souvent ajoutée pour reporter les résultats de l'année précédente, que l'on peut comparer à ceux représentés sur la 3éme colonne, permettant de mesurer le sens et la valeur de l'évolution d'une année sur l'autre. L'intitulé du titre des deux dernières colonnes se prête à des formes variables, telles que « N », « N-l » ou « |31 | 12 | 2021 | », « | 31 | 12 | 2020 | », dates de clôture représentées en râteaux donc sujettes à erreurs de lecture de chiffres. D'autres perturbations du même ordre peuvent apparaitre sur les autres pages ou à d'autres endroits (inversion des colonnes N et N-l, etc ...). A cela s'ajoute l'existence de variantes terminologiques, abréviatives et synonymiques dans les Rubriques alphanumériques des lignes et les titres des colonnes, et parfois, des lignes supplémentaires ou inversées.

[0022] Cette variabilité peut conduire notamment à l'association d'un mauvais identifiant à un montant lors du traitement des données résultant de l'OCR.

[0023] Ainsi, pour répondre à la demande de fiabilité des fichiers de résultats structurés transmis aux établissements bancaires, des sociétés prestataires de services de vérification doivent recourir à différentes méthodes de vérification, tant pour les Identifiants que pour les valeurs des montants contenus dans ces cases.

[0024] Certaines de ces méthodes, entièrement automatisées et reposant notamment sur l'intelligence artificielle, permettent d'améliorer la fiabilité des données transmises aux établissements bancaires, sans toutefois atteindre le niveau de fiabilité à 100 % requis par ces établissements. [0025] D'autres méthodes, semi-automatisées, permettent d'atteindre un niveau de fiabilité supérieure.

[0026] Ces méthodes font intervenir des personnes vérificatrices qui s'assurent, sur des écrans d'interface appropriés, que les montants résultant de l'océrisation du formulaire rempli par l'entreprise ne comportent pas d'erreur, et qu'ils sont associés aux bons identifiants de cases.

[0027] Cette vérification humaine permet ainsi de s'assurer que la valeur du montant et son affectation sont corrects.

[0028] Ces méthodes semi-automatisées supposent par construction que les personnes vérificatrices aient sous les yeux les montants et les identifiants associés.

[0029] A partir de cette visibilité, les personnes vérificatrices peuvent donc avoir accès à toutes les informations comptables d'une entreprise.

[0030] Or, il existe une demande croissante de la part des Autorités bancaires pour que les opérations de vérification des données structurées du type identifiant/montant, puissent être effectuées de manière totalement confidentielle, c'est-à-dire en évitant, autant que faire se peut, qu'il puisse y avoir des fuites de données de la part d'une personne vérificatrice mal intentionnée, partant du principe que dans cette vérification elle est amenée à voir ces données, alors que les informations comptables d'une entreprise, sont considérées a priori comme lui appartenant sans qu'aucun organisme ne puisse s'arroger le droit d'en décider autrement.

[0031] Cette demande croissante découle notamment de directives émises par l'EBA (European Bank Authority Autorité Bancaire Européenne), qui conduit en particulier à interdire aux établissements bancaires de l'UE toute sous-traitance à des sociétés extérieures de saisie susceptibles, comme dit plus haut, de causer des fuites de données, les obligeant à internaliser cette vérification/correction, partant du principe que cette internalisation permet à la Banque de mieux contrôler les risques de fuite de données sensibles. Cette obligation de confidentialité s'applique aussi à des Documents Tabulaires Référencés initiaux qui peuvent être des Bulletins de Salaires contenant des données personnelles qui sont, depuis 2016, protégées, pour les citoyens européens, par des règles de Confidentialité définies dans un Règlement Général de Protection des Données (RGPD, Règlement n° 2016/679 du Parlement Européen et du Conseil du 27 avril 2016).

[0032] Dans les deux exemples précédents, les valeurs numériques à extraire sont des données monétaires (en € pour l'UE), soumises au double impératif d'exactitude rigoureuse et de confidentialité garantie, incompatibles l'un avec l'autre puisque l'exactitude ne peut être garantie qu'à travers une vérification humaine, ouvrant la voie à de possibles fuites de données.

[0033] Le but de la présente invention est d'apporter une solution à cette contradiction apparente à travers un Procédé de saisie inédit contournant le problème par la combinaison de concepts nouveaux contredisant le préjugé d'une telle incompatibilité.

[0034] Les services proposés par les sociétés de saisie/vérification des données comptables et financières, actuellement disponibles sur le marché, sont incompatibles avec ces obligations de confidentialité, eu égard notamment à l'intervention de personnes vérificatrices qui ont accès en clair aux montants et à leurs identifiants associés figurant dans les Documents remplis par les entreprises.

[0035] La présente invention se rapporte à un procédé d'extraction semi-automatique de données situées dans un document tabulaire référencé papier ou digital, comprenant des cases, des identifiants de ces cases et des montants remplis dans ces cases, comprenant les étapes consistant à : a. envoyer un fichier image du document tabulaire référencé rempli dans un ordinateur noyau sécurisé sans qu'une personne vérificatrice puisse y avoir accès, c. enlever au moyen de cet ordinateur noyau tous les montants remplis dans les cases du document tabulaire référencé, conduisant à un document tabulaire référencé dit « défiguré », e. renseigner les bons identifiants à l'intérieur des cases concernées vidées de leurs montants, f. faire extraire par l'ordinateur noyau les images de chaque chiffre composant chacun desdits montants, g. associer au moyen de l'ordinateur noyau à chacune desdites images le chiffre correspondant obtenu par océrisation du document tabulaire référencé rempli, h. faire vérifier par une personne vérificatrice sur une interface de pilotage si la conversion de l'image du chiffre en chiffre océrisé a été effectuée sans erreur, par lecture et comparaison de chiffres isolés dont la personne vérificatrice ne peut identifier l'origine, i. si ce n'est pas le cas, faire corriger par la personne vérificatrice sur l'interface de pilotage la valeur erronée,

- j. réactualiser au moyen de l'ordinateur noyau les valeurs associées auxdites images, k. faire parcourir par l'ordinateur noyau toutes les cases du document tabulaire référencé dans lesquelles les identifiants vérifiés ont étés remplis à l'étape e), et faire associer par l'ordinateur noyau à chacun de ces identifiants les montants sous-jacents reconstitués par cet ordinateur noyau.

[0036] Par « océriser dans cet ordinateur noyau le document tabulaire référencé», on entend océriser le fichier image du document tabulaire référencé rempli.

[0037] Le document tabulaire référencé peut être le document tabulaire référencé rempli.

[0038] L'invention peut aussi comporter les caractéristiques suivantes prises seules ou en combinaison.

[0039] Selon une caractéristique, le procédé comprend en outre l'étape suivante :

- b) océriser dans cet ordinateur noyau ce document tabulaire référencé.

[0040] Selon une caractéristique, le procédé comprend en outre l'étape suivante :

- d) stocker ces montants en mémoire dans l'ordinateur noyau, de sorte qu'ils deviennent sous-jacents, c'est-à-dire non accessibles à la personne vérificatrice.

[0041] Selon une caractéristique, le procédé comprend une étape de génération du fichier image du document tabulaire référencé rempli. [0042] De manière avantageuse, cela permet d'océriser le fichier image ultérieurement.

[0043] Selon une caractéristique, on regroupe lesdites images de chiffre par classe de proximité de forme.

[0044] Par « classes de proximité de forme », on entend des classes de similitude dans lesquelles sont regroupés des chiffres ou caractères ayant une forme similaire.

[0045] Selon une caractéristique, le procédé comprend une étape de comparaison des images de chiffre les unes aux autres.

[0046] Selon une caractéristique, la comparaison des images de chiffre se fait en fonction de la composition en pixels desdites images de chiffre afin d'identifier des similitudes dans les compositions en pixels des images de chiffres.

[0047] La composition en pixels d’une image est le nombre de pixels et la disposition des pixels compris dans l'image.

[0048] De manière avantageuse, cela permet d'identifier des images de chiffre sensiblement similaires de manière simple afin de grouper les images correspondant au même chiffre dans un même groupe.

[0049] Selon une caractéristique, le procédé comprend une étape de répartition des images de chiffre dans des classes de similitude en fonction d'un résultat de la comparaison de leur composition en pixels, de sorte que deux images dont les compositions en pixels sont sensiblement identiques soient comprises dans une même classe de similitude.

[0050] Par « classe de similitude », on entend une collection d’objets, par exemple d'images, qui partagent une propriété commune. Par exemple, une classe qui se rapporte au chiffre « 8 » comprend une pluralité d'images qui monte le chiffre « 8 ».

[0051] Par « compositions en pixels sensiblement identiques », on entend par exemple des compositions en pixels qui ne diffèrent en nombre de pixels dans la composition que par un nombre de pixels inférieur à 10, et de préférence inférieur à 4, et de préférence inférieur à 2.

[0052] De manière avantageuse, cela permet de réduire le nombre d'images de chiffres à vérifier par une personne vérificatrice.

[0053] Selon une caractéristique, on détermine les classes de proximité de forme en regroupant les images qui ne se distinguent les unes des autres que par quelques pixels isolés. Par « quelques pixels isolés » on entend par exemple au moins 2 pixels, par exemple 2 pixels, 3 pixels ou 4 pixels.

[0054] Selon une caractéristique, le procédé comprend une étape de modification d'au moins un paramètre d'une image de chiffre avant la comparaison de ladite image de chiffre avec une autre image de chiffre.

[0055] Le « paramètre d'une image de chiffre », peut être choisi parmi : une dimension de l'image comme une largeur ou une longueur de l'image, un nombre de pixels dans l'image, ou encore une disposition des pixels de l'image.

[0056] De manière avantageuse, cela permet de rendre la comparaison entre les images de chiffre plus précise.

[0057] Selon une caractéristique, l'au moins un paramètre est une dimension de l'image de chiffre.

[0058] La dimension d'une image en pixels est la taille de l'image, exprimée par exemple en nombre de pixels. Les pixels sont les éléments les plus petits qui composent une image numérique. Ils sont disposés en lignes et en colonnes, et la dimension d'une image est définie par exemple par le nombre de pixels sur la largeur et le nombre de pixels sur la hauteur de l'image.

[0059] De manière avantageuse, cela permet de s'assurer qu'une image de chiffre est bien classée dans la classe où elle devrait être classée en dépit d'une différence dans sa composition de pixels qui serait due à une variation fortuite de la taille de l'image de chiffre. [0060] Selon une caractéristique, on fait remplir les bons identifiants à l'étape e) par une personne vérificatrice.

[0061] Selon une caractéristique, on fait préremplir au moins en partie les bons identifiants (33, 35) à l'étape e) par l'ordinateur noyau, et on fait vérifier par une personne vérificatrice que les identifiants pré remplis par l'ordinateur noyau sont exacts.

[0062] Selon une caractéristique, on réalise l'étape e) en transférant sur les cases vides du document tabulaire référencé défiguré des identifiants correspondants renseignés dans les cases d'un modèle de document tabulaire dit « augmenté » et figeant les choix décidés pour ces identifiants pour le modèle considéré.

[0063] Selon une caractéristique, on conserve dans l'ordinateur noyau un dossier dit « révélateur » associé au document tabulaire référencé, par exemple référencé vérifié, conformément à l'une quelconque des revendications précédentes, ce dossier révélateur comprenant un fichier de localisation physique des identifiants dans ledit document tabulaire référencé et un fichier des chiffres vérifiés par la personne vérificatrice, ce dossier révélateur ne contenant aucun des montants figurant dans les cases du document tabulaire référencé rempli, et lors d'un passage du document tabulaire référencé, on détecte ce passage au moyen de l'ordinateur noyau (27) et on charge dans la mémoire de l'ordinateur noyau le dossier révélateur permettant de régénérer à l'identique les résultats vérifiés par la personne vérificatrice.

[0064] Selon une caractéristique, le procédé comprend l'étape suivante : regrouper les images de chiffres extraites dans d) en classe de similitude de forme par un algorithme ayant la propriété que deux images regroupées dans la même classe ne peuvent pas représenter deux chiffres différents.

[0065] Selon une caractéristique, le procédé comprend l'étape suivante : utiliser l'algorithme de coïncidence forte comme algorithme de proximité de forme ayant la même propriété.

[0066] Selon une caractéristique, l'étape h) comprend faire vérifier (49) par une personne vérificatrice sur une interface de pilotage (31) si la conversion de ces images (51) en chiffres océrisés (53) a été effectuée sans erreur, par visualisation de ces chiffres labélisés présentés à l'écran par ordre de leurs valeurs reconnues sur plusieurs lignes d'un tableau, ne permettant pas, à la personne vérificatrice de reconstituer les montants d'origine.

[0067] L'invention se rapport en outre à un procédé d'extraction semi-automatique de données situées dans un document tabulaire référencé papier ou digital, comprenant des cases, des identifiants de ces cases et des montants remplis dans ces cases, comprenant les étapes consistant à : a. envoyer un fichier image du document tabulaire référencé rempli dans un ordinateur noyau sécurisé sans qu'une personne vérificatrice puisse y avoir accès, c. enlever au moyen de cet ordinateur noyau tous les montants remplis dans les cases du document tabulaire référencé, conduisant à un document tabulaire référencé dit « défiguré », e. renseigner les bons identifiants à l'intérieur des cases concernées vidées de leurs montants, f. regrouper les images de chiffres extraites dans d) en classe de proximité de forme par un algorithme ayant la propriété que deux images regroupées dans la même classe ne peuvent pas représenter deux chiffres différents, h. faire vérifier par une personne vérificatrice sur une interface de pilotage si la conversion de ces l'images en chiffres océrisés a été effectuée sans erreur, par visualisation de ces chiffres labélisés présentés à l'écran par ordre de leurs valeurs reconnues sur plusieurs lignes d'un tableau, ne permettant pas, à la personne vérificatrice de reconstituer les montants d'origine, i. si ce n'est pas le cas, faire corriger par la personne vérificatrice sur l'interface de pilotage la valeur erronée,

- j. réactualiser au moyen de l'ordinateur noyau les valeurs associées auxdites images, k. faire parcourir par l'ordinateur noyau toutes les cases du document tabulaire référencé dans lesquelles les identifiants vérifiés ont étés remplis à l'étape e), et faire associer par l'ordinateur noyau à chacun de ces identifiants les montants sous-jacents reconstitués par cet ordinateur noyau. [0068] Selon une caractéristique, le procédé peut comprendre l'une ou plusieurs des caractéristiques présentées plus haut, selon l'une quelconque de leurs combinaisons techniquement possibles.

[0069] Selon une caractéristique, le procédé peut comprendre : g. associer au moyen de l'ordinateur noyau à chacune desdites images le chiffre correspondant obtenu par océrisation du document tabulaire référencé rempli, et/ou utiliser l'algorithme de coïncidence forte comme algorithme de proximité de forme ayant la même propriété.

[0070] L'invention se rapporte en outre à un programme informatique comportant des instructions pour la mise en œuvre du procédé décrit précédemment lorsque le programme est exécuté par un processeur.

[0071] La présente invention se rapporte donc à un procédé d'extraction semi- automatique de données situées dans un document tabulaire référencé papier ou digital, comprenant des cases, des identifiants de ces cases et des montants remplis dans ces cases, comprenant les étapes consistant à : a. envoyer un fichier image du document tabulaire référencé rempli dans un ordinateur noyau sécurisé sans qu'une personne vérificatrice puisse y avoir accès, b. océriser dans cet ordinateur noyau le document tabulaire référencé, c. enlever au moyen de cet ordinateur noyau tous les montants remplis dans les cases du document tabulaire référencé, conduisant à un document tabulaire référencé dit « défiguré », d. stocker ces montants en mémoire dans l'ordinateur noyau, de sorte qu'ils deviennent sous-jacents, c'est-à-dire non accessibles à la personne vérificatrice, e. renseigner les bons identifiants à l'intérieur des cases concernées vidées de leurs montants, f. faire extraire par l'ordinateur noyau les images de chaque chiffre composant chacun desdits montants, g. associer au moyen de l'ordinateur noyau à chacune desdites images le chiffre correspondant obtenu par océrisation du document tabulaire référencé rempli, h. faire vérifier par une personne vérificatrice sur une interface de pilotage (31) si la conversion de l'image du chiffre en chiffre océrisé a été effectuée sans erreur, par lecture et comparaison de chiffres isolés dont la personne vérificatrice ne peut identifier l'origine, i. si ce n'est pas le cas, faire corriger par la personne vérificatrice sur l'interface de pilotage la valeur erronée,

- j. réactualiser au moyen de l'ordinateur noyau les valeurs associées auxdites images, k. faire parcourir par l'ordinateur noyau toutes les cases du document tabulaire référencé dans lesquelles les identifiants vérifiés ont étés remplis à l'étape e), et faire associer par l'ordinateur noyau à chacun de ces identifiants les montants sous-jacents reconstitués par cet ordinateur noyau.

[0072] La présente invention a ainsi notamment pour but de fournir les moyens permettant de vérifier les données structurées extraites de Documents Tabulaires Référencés remplis, tout en respectant les obligations de confidentialité décrites ci-dessus, en dépit d'intervention de personne vérificatrice.

[0073] La présente invention concerne ainsi un procédé d'extraction semi- automatique de Données numériques sensibles, telles que des montants financiers ou salariaux dans des Documents Tabulaires Référencés, qui sont des fichiers images remplis de caractères imprimés, où le repérage de telles Données peut être assuré automatiquement par un Ordinateur Noyau, lorsque la reconnaissance de ces données, par un OCR incorporé au Noyau par exemple, requiert une vérification par des personnes vérificatrices afin d'assurer un « sans faute » tout en garantissant une Totale Confidentialité, en dépit du fait que ces personnes vérificatrices sont susceptibles de transgresser cette exigence si elles les voient, ce procédé comprenant les étapes consistant à : a) créer une image « défigurée » du Document Tabulaire Référencé où tous les montants sensibles ont été effacés par le Noyau, ce Document Tabulaire Référencé défiguré étant le seul Document présenté aux personnes vérificatrices, rendant alors impossible toute fuite de donnée, mais leur permettant d'effectuer leur travail d'identification de chaque Donnée au vu de leur environnement textuel et structurel, et à b) faire extraire automatiquement par le Noyau sur l’image non défigurée tous les chiffres composant lesdites données et à présenter leurs images « en pièces détachées » et en ordre dispersé aux personnes vérificatrices, qui vérifient et saisissent leurs valeurs individuelles sans pouvoir reconstituer les montants, le Noyau se chargeant de reconstituer lesdites données à réception de ces résultats.

[0074] Suivant d'autres caractéristiques optionnelles du procédé selon l'invention :

[0075] - les images de chiffres extraites des montants par le Noyau sont regroupées en

Modèles de chiffres à travers une relation d'équivalence réalisée par un algorithme de proximité de forme assurant que deux images équivalentes ne peuvent pas représenter des chiffres différents, permettant de réduire la reconnaissance par OCR à un représentant de chaque classe d'équivalence, le Noyau recomposant les montants en extrayant à nouveau les images des chiffres de chaque case dudit Document Tabulaire Référencé rempli, en trouvant pour chacun d'eux à quel Modèle de chiffre il appartient, par comparaison à travers l'algorithme de proximité, ce procédé réduisant d'autant la vérification par un opérateur humain des résultats trouvés par l'OCR, la réduction pouvant être une division par au moins 100, le gain quantitatif devenant qualitatif à ce niveau de réduction.

[0076] Afin de pouvoir associer au moyen de l'ordinateur noyau à chacune desdites images le chiffre correspondant obtenu par océrisation du document tabulaire référencé rempli, l'ordinateur noyau peut mettre en œuvre une répartition des images de chiffre dans des classes de similitude.

[0077] Par ordinateur noyau, on entend par exemple un ordinateur qui ne dispose que d'un noyau de système d'exploitation et dans lequel il n'y a pas d'application ou de pilote installé.

[0078] Afin de générer des modèles de chiffre (ou des classes de similitude) comme indiqué par exemple dans l'étape g), les images de chiffre générées peuvent être parcourues par l'ordinateur noyau. La première image peut être choisie comme représentative d'une première classe de similitude. [0079] Puis une deuxième image peut être comparée à la première image. Par « deuxième image comparée à la première image », on entend que la composition en pixels des deux images est comparée, autrement dit le nombre de pixels qui constitue l'image et la disposition des pixels (les coordonnées des pixels).

[0080] Si la deuxième image est similaire à la première image, la deuxième image peut être classée dans la même classe de similitude que la première image.

[0081] Sinon, une deuxième classe de similitude peut être créée, et la deuxième image peut être classée dans la deuxième classe de similitude et peut devenir l'image représentative de cette deuxième classe de similitude.

[0082] Pour le classement d'une nouvelle image, la nouvelle image peut être comparée à l'image de la première classe et à l'image de la deuxième classe afin de déterminer la classe dans laquelle elle peut être classée. Si la nouvelle image n'est similaire à aucune des images représentatives des classes existantes, alors une nouvelle classe de similitude peut être créée et la nouvelle image peut être classée dans cette nouvelle classe de similitude. Ce procédé de classement par classes de similitude peut continuer jusqu'à ce que toutes les images de chiffre soient classées dans des classes de similitude.

[0083] Un exemple particulier de réalisation de l'algorithme de proximité de forme qui peut s'exécuter dans l'étape g) par exemple et qui peut opérer ce classement en classes de similitude est l'algorithme appelé « coïncidence forte ». Ainsi, l'association au moyen de l'ordinateur noyau à chacune desdites images du chiffre correspondant obtenu par océrisation du document tabulaire référencé rempli revient à classer les images de chiffre en classes de similitude.

[0084] L'algorithme de coïncidence forte est le suivant :

[0085] Soient A et B les images de chiffre testées par l'algorithme de la coïncidence forte.

[0086] Une première étape de l'algorithme de coïncidence forte peut consister à vérifier si A et B ont une même dimension, par exemple une même largeur ou une même hauteur, ou encore si la différence de composition en pixels des images A et B est inférieure à une valeur limite de différence. Par « valeur limite de différence », on entend que les images A et B peuvent être considérées comme similaires si la différence en nombre de pixels entre les images A et B est inférieure ou égale à quatre pixels par exemple.

[0087] Si ce n'est pas le cas, alors la sortie de l'algorithme peut être que les images A et B ne sont pas en coïncidence forte, autrement dit les images ne sont pas sensiblement similaires.

[0088] Une deuxième étape de l'algorithme de coïncidence forte peut consister à modifier un paramètre de l'image A ou de l'image B, par exemple une dimension de l'image A ou une dimension de l'image B. Ceci afin de s'assurer de prendre en compte dans la comparaison un écart fortuit dû à une variation de la taille de l'image suite à l'océrisation.

[0089] A cette fin, on peut créer une image A0 en inscrivant l'image A dans un cadre blanc d'un pixel d'épaisseur (l'image A0 voit ses largeurs et hauteurs augmentées de 2 pixels par rapport à celles de A), et on peut créer une image B0 en inscrivant l'image B dans un cadre blanc d'un pixel d'épaisseur (l'image B0 voit ses largeurs et hauteurs augmentées de 2 pixels par rapport à celles de B). Ensuite, on peut modifier l'image A0 en noircissant les 8 pixels entourant tout pixel noir de l'image. L'image A0 devient An et on peut modifier l'image B0 en noircissant les 8 pixels entourant tout pixel noir de l'image. L'image B0 devient Bn.

[0090] Le principe de la vérification peut consister à comparer l'image A dans ses deux représentations A0 et An à l'image B dans ses deux représentations B0 et Bn, en superposant l'image B au-dessus de l'image A avec un possible décalage de 1 pixel selon une première dimension x et/ou selon une deuxième dimension y, et en trouvant s'il existe un positionnement dans lequel :

- aucun pixel noir de B0 n'est superposé à un pixel blanc de An,

- aucun pixel noir de A0 n'est superposé à un pixel blanc de Bn. [0091] Ceci peut revenir à vérifier s'il existe au moins un positionnement de B par rapport à A où les contours extérieurs et intérieurs des images A et B ne diffèrent pas de plus de 1 pixel l'un de l'autre. Si ce n'est pas le cas, la sortie de l'algorithme peut être que les deux images A et B ne sont pas en coïncidence forte, autrement dit que les images A et B ne sont pas sensiblement similaires.

[0092] La relation de coïncidence forte peut être est une relation d'équivalence au sens mathématique du terme, autrement dit si A coïncide avec B, alors B coïncide avec A (symétrie) et si A coïncide avec B et si B coïncide avec C alors A coïncide avec C (transitivité).

[0093] Sur la base de cet algorithme de coïncidence forte, les images de chiffres peuvent ainsi être regroupées dans des classes de similitude.

[0094] De manière avantageuse, sur la base de l'algorithme de coïncidence forte, deux images de chiffre appartenant à une même classe de similitude correspondent nécessairement au même chiffre, quand bien même on ne saurait pas encore lequel.

[0095] De manière avantageuse, l'algorithme de coïncidence forte permet de garantir que les images dont les compositions en pixels sont reconnues comme similaires (et donc que les images sont en coïncidence forte) ne peuvent pas représenter deux chiffres différents.

[0096] De manière avantageuse, grâce à l'algorithme de coïncidence forte, le procédé décrit peut répondre à des obligations du secteur de la finance, notamment à une obligation de garantir une exactitude des montants financiers saisis, et garantir une confidentialité des données financières des entreprises, par exemple contre toute possibilité de fuite de données par des opérateurs humains.

[0097] De manière avantageuse, le procédé peut se limiter à la reconnaissance de chaque classe de similitude trouvée à travers un OCR interne de l'ordinateur noyau appliqué à l'une des images représentatives de la classe, au lieu de devoir reconnaître par exemple 3000 ou 4000 chiffres contenus dans un document. [0098] De manière avantageuse, l'algorithme de coïncidence forte peut permettre de limiter une vérification par un opérateur humain de l'exactitude des reconnaissances sur un nombre réduit de « modèles » (un modèle de chiffres est l'association de l'image d'une classe et de son chiffre reconnu par un OCR interne). Le temps de vérification humaine peut être divisé par un facteur par exemple d'au moins 100, et l'intervention des opérateurs de vérification/correction se limite à une cinquantaine de modèles à vérifier. A ce niveau de réduction l'amélioration n'est plus quantitative mais qualitative.

[0099] L'algorithme de coïncidence forte peut permettre en outre, de résoudre des cas particuliers comme une présence fortuite d'un pixel blanc isolé qu'il faut savoir éliminer ou un trait noir fin qui se rompt en son milieu sur une image digitalisée qu'il est souhaitable de réparer. Le pixel blanc isolé est noirci sur l'image An par l'extension d'un des pixels noirs qui le touchent ; le trait rompu peut être réparé par l'algorithme de coïncidence forte lorsque la rupture est de 1 ou 2 pixels (les deux pixels noirs qui se font face vont noircir ces deux pixels blancs qui chacun vont toucher un de ces pixels noirs. Les ruptures n'excédant pas 2 pixels sont ainsi réparées.)

[00100] Si l'algorithme de coïncidence forte ne détecte pas la similitude de deux images de chiffres similaires, un modèle de plus sera à vérifier par un opérateur humain. En tout état de cause, le nombre de modèles à vérifier par l'opérateur humain reste réduit par rapport aux milliers de chiffres qu'il faudrait sinon vérifier un à un.

[00101] Lorsque le procédé est appliqué à des Documents Tabulaires Référencés relevant d'un Modèle de document tabulaire : a) on associe à ce Modèle de document tabulaire un ensemble d'identifiants pour chaque case susceptible d'être remplie avec des valeurs numériques de montants à extraire, ces identifiants pouvant être définis semi-arbitrairement par le gestionnaire de l'application en s'inspirant de ceux apparaissant éventuellement sur le Modèle de document tabulaire, pour les lignes de tableaux par exemple, b) on crée une version du Modèle de document tabulaire, dite Modèle Augmenté, où chaque case concernée est remplie par l'identifiant qui lui est attribué, c) le procédé consiste alors à transférer sur les cases mises à blanc du Document Tabulaire Référencé défiguré les Identifiants correspondants du Modèle Augmenté, soit automatiquement par le Noyau si ses algorithmes d'intelligence Artificielle lui permettent de reconnaître par l'environnement structurel et textuel des cases les identifiants concernés, soit par action de transfert depuis le Modèle Augmenté effectuée par l'intelligence humaine de la personne vérificatrice, les résultats finaux étant générés par le Noyau sous la forme d'une liste de couples <identifiant, valeur>.

[00102] - on utilise une interface intelligente permettant aux personnes vérificatrices de transférer les identifiants du Modèle Augmenté vers le Document Tabulaire Référencé défiguré afin de compléter/corriger les manques et erreurs éventuels du Noyau, dans lequel on utilise un poste « opérateur » constitué de deux écrans jointifs contrôlés par la même souris passant de l'un à l'autre, permettant des opérations de « Prendre et Déposer » (« Pick and Drop ») des Identifiants du Modèle Augmenté vers le Document Tabulaire Référencé défiguré ;

[00103] - on donne aux personnes vérificatrices des moyens d'actions optimisées selon les spécifications suivantes : a) transfert d'un identifiant d'une case du Modèle Augmenté en cliquant sur cette case, puis sur l'emplacement du Document Tabulaire Référencé défiguré où il faut le déposer, b) transfert d'un pavé rectangulaire de cases du Modèle Augmenté vers le Document Tabulaire Référencé défiguré, en cliquant sur le coin supérieur gauche, puis sur le coin inférieur droit du rectangle à transférer, puis en cliquant sur le coin supérieur gauche du Document Tabulaire Référencé défiguré où la personne vérificatrice souhaite placer les identifiants du pavé rectangulaire, le pilote d'interface complétant le transfert par une mise à jour des cases apparaissant sur le Document Tabulaire Référencé défiguré en dehors du rectangle transféré, susceptibles d'être remplies par un reliquat d'identifiants par ailleurs transférés en les effaçant, afin de respecter la règle de non ubiquité des Identifiants ; [00104] - ledit Noyau (27) archive, sous une indexation liée au Document Tabulaire

Référencé (par exemple, Siren de la Société et année, ou matricule et date d'un bulletin de salaire) un Dossier Révélateur contenant deux fichiers : a) le fichier du Document Tabulaire Référencé défiguré rempli par les identifiants comme dit dans les étapes décrites ci-dessus, b) le fichier des Modèles de chiffres labélisés et vérifiés par une personne vérificatrice comme dit ci-dessus, ces deux fichiers pouvant être archivés sans transgresser l'obligation de confidentialité des montants puisqu'ils ne peuvent pas permette de les reconstituer à eux seuls ;

[00105] - lorsque le Noyau détecte, par son indexation, qu'un Document Tabulaire

Référencé s déjà été traité lors d'un passage précédent, il réactive les résultats obtenus lors de ce premier passage tels qu'archivés dans son Dossier Révélateur et Dépouille les résultats comme il l'avait fait lors de ce premier passage ;

[00106] - on peut lire ledit Dossier Révélateur des Documents Tabulaires Référencés remplis et archivés pour effectuer des sélections de Documents Tabulaires Référencés remplis à travers des expressions conditionnelles s'exprimant en termes algébriques désignant les postes impliqués à travers leurs identifiants du Modèle Augmenté et en parcourant les Documents Tabulaires Référencés remplis originaux archivés dans une base de Données ultra-protégée, la réunion éphémère du Dossier Révélateur et du Document Tabulaire Référencé non défiguré permettant de régénérer les montants numériques et de vérifier si les expressions conditionnelles sont satisfaites, puis effacer les montants régénérés, rendant improbable une intrusion malveillante dans ce très court laps de temps ;

[00107] - l'invention propose aussi la possibilité aux personnes vérificatrices de vérifier si des relations arithmétiques sont satisfaites entre certaines cases des Documents Tabulaires Référencés, sans voir les montants remplis dans ces cases, au moyen d'une Calculatrice Virtuelle qui permet au Noyau de vérifier, à travers les montants sous-jacents si les relations arithmétiques sont satisfaites et d'informer les personnes vérificatrices du résultat.

[00108] La présente invention se rapporte également à un système pour la mise en oeuvre du procédé conforme à ce qui précède, comprenant : a) au moins un noyau sécurisé (27) équipé de moyens permettant notamment de défigurer ledit Document Tabulaire Référencé rempli, d'extraire de cases remplies les images de chiffres composant les montants numériques, de produire des images élémentaires (51) desdites données, d'océriser lesdites données, de stocker ces images élémentaires et ces données océrisées, b) au moins une interface de pilotage (31) communiquant avec ledit noyau sécurisé équipée de moyens permettant de saisir à l'écran les identifiants, de comparer lesdites données océrisées (53) auxdites images élémentaires (51), d'apporter les corrections nécessaires, et de renvoyer audit noyau sécurisé (27) lesdits identifiants et lesdites corrections (55).

[00109] La présente invention se rapporte également à un programme informatique comportant des instructions pour la mise en œuvre du procédé conforme à ce qui précède lorsque le programme est exécuté par un processeur.

[00110] D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description qui suit, en référence aux figures annexées, qui illustrent :

[Fig. 1] : sous forme de logigramme les principales étapes du procédé selon l'invention ;

[Fig. 2] : un exemple de Modèle de document tabulaire, de type CERFA ;

[Fig. 3] : un Document Tabulaire Référencé rempli, qui est une version modifiée remplie du formulaire de la figure 2 ;

[Fig. 4] : une version défigurée du Document Tabulaire Référencé de la figure 3 ;

[Fig. 5] : une version identifiée du Document Tabulaire Référencé de la figure 4 ; [Fig. 6] : une version augmentée du Modèle de document tabulaire de la figure 2 ;

[Fig. 7] : une version pré-identifiée par le Noyau du Document Tabulaire Référencé de la figure 4;

[Fig. 8] : un exemple de lignes de chiffres images et océrisés à comparer;

[Fig. 9] : un exemple de Calculatrice Virtuelle pouvant être mise en œuvre dans le cadre de l'invention.

[00111] Pour plus de clarté, les éléments identiques ou similaires sont repérés par des signes de référence identiques ou similaires sur l'ensemble des figures.

[00112] Les références numériques indiquées entre parenthèses renvoient au logigramme de la figure 1, et les références numériques qui ne sont pas entre parenthèses renvoient aux figures 2 à 8.

[00113] Pour plus de clarté également, il importe de définir précisément les termes suivants, utilisés dans le cadre de la description et des revendications de la présente invention :

[00114] - océrisation : conversion d'une image de chiffre, de lettre, de chaîne de chiffres ou de lettres, en caractères codés de type ASCII ;

[00115] - chiffre, lettre, document océrisés : chiffre, lettre, document résultant de l'océrisation ;

[00116] - Modèle de document tabulaire : Document de référence d'un Document

Tabulaire Référencé sous une forme matérielle (papier) ou numérique (fichier), tel qu'un formulaire CERFA de l' Administration, montrant les tableaux de Référence et leurs structures cellulaires vides de toutes valeurs, indiquant la structure cellulaire que le Document Tabulaire Référencé devra suivre en vue d'être rempli par action du Noyau et/ou des Opérateurs humains de saisie ;

[00117] - Document Tabulaire Référencé : forme s'inspirant du Modèle de document tabulaire, mais pouvant contenir des variantes, telles que du texte ajouté, des lignes ou des colonnes supplémentaires, et des versions lexicographiques, synonymiques et/ou abréviatives des rubriques alphanumériques de gauche, édité et rempli par les Entreprises à travers leurs bases de données de gestion choisies;

[00118] - case : matérialisation, souvent sous la forme d'un rectangle, du champ à remplir sur le Modèle de document tabulaire ou sur le Document Tabulaire Référencé ;

[00119] - identifiant : code, sous forme de plusieurs lettres ou chiffres associés à une case, et renseignant sur la nature de l'information contenue par la case ;

[00120] - Modèle Augmenté : Modèle de document tabulaire dont les cases ont été renseignées par des identifiants correspondants figeant le choix décidé pour ces identifiants pour le Modèle considéré ;

[00121] - Document Tabulaire Référencé rempli : Document Tabulaire Référencé dont les cases ont été remplies avec des montants par les logiciels de gestion de l'entreprise et ainsi lisibles pour tout être humain ;

[00122] - montant : valeur monétaire ou salariale (nombre) renseigné dans une case du

Document Tabulaire Référencé rempli ;

[00123] - chiffre : chacun des chiffres composant le montant ;

[00124] - personne vérificatrice : être humain en charge de la vérification de l'exactitude des montants extraits du Document Tabulaire Référencé rempli, et de la bonne affectation des identifiants à ces montants ;

[00125] - noyau : espace logiciel et/ou matériel sécurisé, c'est-à-dire auquel notamment les personnes vérificatrices n'ont pas accès;

[00126] - sous-jacent : non accessible à la personne vérificatrice, mais stocké dans le noyau au même emplacement que le Document Tabulaire Référencé rempli ;

[00127] - Document Tabulaire Référencé défiguré : Document Tabulaire Référencé dont les cases ont été nettoyées de leurs montants par le noyau, ceux-ci étant stockés de manière sous-jacente dans un fichier structuré associé à ce Document Tabulaire Référencé défiguré et non visible par une personne vérificatrice ;

[00128] - Document Tabulaire Référencé identifié : Document Tabulaire Référencé contenant des identifiants ajoutés par une personne vérificatrice et/ou par le noyau ;

[00129] - interface de pilotage : ensemble logiciel et/ou matériel, gérant les interactions de la personne vérificatrice avec l'écran de vérification de données et les retours d'informations vers le Noyau selon l'invention ;

[00130] - client final : donneur d'ordre auquel sont destinées les données vérifiées grâce au procédé selon l'invention ;

[00131] - fichier résultat : fichier contenant les données structurées vérifiées du type couples <identifiant/montant>, exploitables par le client final.

[00132] On se reporte à présent à la figure 2, sur laquelle on peut voir un exemple de Modèle de document tabulaire de type CERFA de déclaration de bilan pour une entreprise, fourni par l' Administration fiscale.

[00133] Dans cet exemple illustratif et non limitatif, le Modèle de document tabulaire est un formulaire pour la déclaration du bilan d'une entreprise.

[00134] Bien entendu, ce Modèle de document tabulaire pourrait concerner tout autre sujet, et constituer par exemple un modèle de feuille de salaire.

[00135] En se reportant donc à ce Modèle de document tabulaire fourni à titre d'exemple, on peut voir qu'il comporte des zones 1, 3... d'identification de l'entreprise et de l'exercice comptable, ainsi qu'un certain nombre de libellés textuels 5, 7... se rapportant en l'espèce à l'actif de l'entreprise considérée.

[00136] Ce Modèle de document tabulaire comporte par ailleurs des cases 9, 11... disposées en face des libellés textuels 5, 7..., organisées sous forme de lignes et de colonnes, et destinées à être remplies par les services de comptabilité de l'entreprise. [00137] Au moins une partie de ces cases est identifiée par des codes à plusieurs lettres ou chiffres 13, 15..., dont la signification est indiquée par le libellé textuel associé à ces cases, et permettant d'identifier la nature du montant rempli dans la case concernée.

[00138] Sur la figure 3, on peut voir une version modifiée de ce Modèle de document tabulaire cette version modifiée du Modèle de document tabulaire de base, désignée par Document Tabulaire Référencé et fournie au cabinet d'expertise-comptable de l'entreprise par les éditeurs de documents Comptables, se distingue essentiellement du Modèle de document tabulaire de la figure 2, en ceci qu'il comprend une colonne supplémentaire 17 permettant de visualiser les montants relatifs à l'année N-l.

[00139] Dans le cas d'espèce de la figure 3, le Document Tabulaire Référencé a été rempli avec les montants 19..., 21... relatifs respectivement aux exercices des années 2022 (colonne 3 -référence 23) et 2021 (colonne 4 - référence 17).

[00140] La problématique est donc la suivante : le Document Tabulaire Référencé rempli de la figure 3 va faire l'objet d'une extraction automatique de données, par exemple au moyen d'un outil d'OCR, et la personne vérificatrice aurait pour responsabilité de vérifier l'exactitude des montants du Document Tabulaire Référencé rempli océrisé, et leur bonne correspondance avec les identifiants - sans qu'à aucun moment cette personne vérificatrice ne puisse avoir accès à ces montants, de manière à respecter les obligations de confidentialité décrites ci-dessus.

[00141] Pour cela, un fichier image du Document Tabulaire Référencé rempli est générée. Cela permet d'océriser le fichier image ultérieurement.

[00142] Puis le fichier image du Document Tabulaire Référencé rempli est envoyée (25) dans le noyau (27) du système selon l'invention sans que la personne vérificatrice puisse y avoir accès.

[00143] Le fichier image du Document Tabulaire Référencé rempli est ensuite océrisé (29), et tous les montants remplis dans les cases du fichier image du Document Tabulaire Référencé rempli sont enlevés (30), et stockés en mémoire dans le noyau (27) : ils deviennent donc sous-jacents. [00144] Le premier travail de la personne vérificatrice va consister à vérifier que les identifiants 13, 15... sont situés au bon endroit, c'est-à-dire chacun à côté d'une case 9, 11... dont le libellé textuel 5, 7... correspond bien à cet identifiant.

[00145] Selon une première variante, le noyau (27) renvoie sur l'interface de pilotage (31) de la personne vérificatrice le Document Tabulaire Référencé défiguré visible sur la figure 4, c'est-à-dire le Document Tabulaire Référencé avec des cases vides et d'autres remplies par le Noyau.

[00146] La tâche de la personne vérificatrice consiste à renseigner (32) les bons identifiants à l'intérieur des cases concernées : ce remplissage peut venir confirmer l'identifiant faisant partie du Document Tabulaire Référencé défiguré rempli par le Noyau (auquel cas, elle laisse les choses en l'état), ou bien le corriger s'il y a erreur.

[00147] Pour s'aider dans cette tâche de vérification, la personne vérificatrice peut utiliser le Modèle Augmenté de la figure 6 : dans les cases de ce modèle ont été renseignés une bonne fois pour toute des identifiants permettant d'identifier de manière univoque la nature de ces cases (des identifiants additionnels du type AC_1 sont créés pour les cases dépourvues d'identifiants officiels, comme c'est le cas des cases de la 3ème colonne du Modèle de document tabulaire de la figure 6).

[00148] La personne vérificatrice peut alors procéder à des opérations de « cliquer et déposer » (« click and drop ») sur des cases ou des groupes de cases du Modèle de document tabulaire pour les déposer dans les zones appropriées du Document Tabulaire Référencé défiguré.

[00149] A l'issue de cette intervention de la personne vérificatrice, on obtient le Document Tabulaire Référencé identifié de la figure 5, dont les cases pertinentes ont été remplies avec les identifiants 33, 35... choisis par la personne vérificatrice.

[00150] A noter, comme cela est visible sur cette figure 5, que la personne vérificatrice a laissé la dernière colonne 17 vide : cette colonne 17 relative à l'exercice de l'année N-l a en effet été ajoutée sur le Document Tabulaire Référencé par rapport au Modèle de document tabulaire et ne fait pas partie des données demandées. Cet exemple supposant que le Noyau n'a rien trouvé en préliminaire.

[00151] Il importe donc d'ignorer les montants figurant dans cette colonne supplémentaire, ce qui sera automatiquement fait par le Noyau lors de l'édition des résultats puisqu'aucune de ces cases n'est remplie par un identifiant.

[00152] Le cas échéant, les modifications des identifiants apportées par la personne vérificatrice sont retournées au noyau (27) qui se met à jour, assurant une parfaite cohérence avec l'image sur l'écran.

[00153] Selon une autre variante possible, les identifiants 33, 35... peuvent être au moins en partie préremplis par le noyau (27) dans les cases du Document Tabulaire Référencé défiguré : à titre d'exemple, ce Document Tabulaire Référencé ainsi prérempli peut apparaître sur l'interface de pilotage (31) de la personne vérificatrice sous la forme visible à la figure 7.

[00154] Le travail de la personne vérificatrice va alors consister à vérifier que les identifiants préremplis par le noyau (27) dans les cases sont exacts.

[00155] Dans l'exemple représenté à la figure 7, on peut de plus voir que des identifiants 41, 43... ont été placés par le noyau dans la dernière colonne 17 du Document Tabulaire Référencé prérempli, relative à l'exercice de l'année N-l, alors qu'ils auraient dû être placés dans l'avant-dernière colonne, relative à l'exercice de l'année N.

[00156] Une tâche supplémentaire de la personne vérificatrice va donc consister à sélectionner sur le Modèle Augmenté de la figure 6 la dernière colonne en cliquant sur son coin supérieur gauche (clic 1) puis sur son coin inférieur droit (clic 2) puis à cliquer, sur le Document Tabulaire Référencé de la figure 7, sur le coin supérieur gauche de la 3ème colonne (clic 3), ce dernier clic provoquant le transfert, par le pilote d'interface, de la 3ème colonne du Modèle Augmenté de la figure 6 vers la 3ème colonne du Document Tabulaire Référencé de la figure 7. [00157] Le pilote d'interface devra ensuite corriger les identifiants transférés ailleurs depuis le Modèle Augmenté qui restent donc dans la 4ème colonne et doivent donc être effacés, appliquant la règle de non-ubiquité des identifiants.

[00158] Dit de manière plus générale, lors d'un tel transfert d'identifiant du Modèle Augmenté au Modèle Tabulaire Référencé, le pilote d'interface devra s'assurer que les identifiants repositionnés ne restent pas visibles sur leur position avant transfert.

[00159] En effet, la copie de la 3ème colonne transférée va automatiquement effacer les éventuels identifiants qui figuraient dans cette colonne mais un reliquat de ces mêmes identifiants pourrait subsister ailleurs, par exemple dans la 4ème colonne. Dans ce cas de figure les identifiants qui se trouvaient erronées dans la 4ème colonne sont restés en place et devront être effacés par le pilote.

[00160] Autre exemple : deux lignes consécutives sont inversées ; dans ce cas on prendra par exemple la ligne inférieure sur le Modèle Augmenté, et on la déposera sur la ligne supérieure, la ligne inférieure sera alors effacée. On devra alors prendre sur le Modèle Augmenté la ligne supérieure et on la transférera sur la ligne inférieure

[00161] Le deuxième travail de vérification par une personne vérificatrice va consister à assurer la reconnaissance des montants des cases sensibles du Document Tabulaire Référencé rempli auquel seul le Noyau (25) a accès, la personne vérificatrice devant effectuer ce travail sans jamais les voir. Deux méthodes sont successivement proposées, la première Basique, la seconde Optimale.

[00162] Méthode Basique : la Reconnaissance des chiffres en Pièces Détachées anonymement dispersées. Pour réaliser cette vérification, le Noyau (27) récupère les images de chaque chiffre composant chaque montant situé dans chaque case du Document Tabulaire Référencé rempli, et associe (45) à chacune de ces images le chiffre correspondant obtenu par océrisation du Document Tabulaire Référencé rempli.

[00163] L'ensemble des couples <image du chiffre/valeur océrisée> sont alors regroupés par ordre croissant de valeurs reconnues et envoyés (47) vers l'interface de pilotage (31), où la personne vérificatrice peut vérifier (49) si la conversion de l'image du chiffre en chiffre océrisé a été effectuée sans erreur et si ce n'est pas le cas, elle corrige à l'écran la valeur erronée. Ce faisant, elle ne peut en déduire aucun renseignement sur la position originelle de ces chiffres dans telle ou telle case, préservant la Confidentialité requise.

[00164] Méthode Optimale : Le regroupement en Modèles de chiffres. Avantageusement, pour limiter le nombre de vérifications à effectuer, on peut regrouper les images de chiffres par classes de proximité de forme, toutes les images d'une même classe se distinguant les unes des autres par de très faibles différences, par exemple une différence sur quelques pixels isolés. Par « quelques pixels isolés » on entend par exemple au moins 2 pixels, par exemple 2 pixels, 3 pixels ou 4 pixels.

[00165] Le regroupement en modèles de chiffre (ou en classe de similitude) peut se faire sur la base de l'algorithme de coïncidence forte décrit précédemment.

[00166] Le procédé d'extraction des données qui utilise l'algorithme de coïncidence forte peut comprendre donc une étape de comparaison des images de chiffre les unes aux autres, possiblement en fonction de la composition en pixels desdites images de chiffre afin d'identifier des similitudes dans les compositions en pixels des images de chiffres, ainsi qu'une étape de répartition des images de chiffre dans des classes de similitude en fonction d'un résultat de la comparaison de leur composition en pixels, de sorte que deux images dont les compositions en pixels sont sensiblement identiques soient comprises dans une même classe de similitude.

[00167] De manière avantageuse, cela permet d'identifier des images de chiffre sensiblement similaires de manière simple afin de grouper les images correspondant au même chiffre dans une même classe de similitude.

[00168] Néanmoins, du fait de l'océrisation, une image de chiffre générée peut présenter des différences fortuites de pixels par rapport à une autre image de chiffre similaire. Afin de pallier ce problème, le procédé d'extraction peut comprendre une étape de modification d'au moins un paramètre d'une image de chiffre avant la comparaison de ladite image de chiffre avec une autre image de chiffre. L'au moins un paramètre peut être une dimension de l'image de chiffre. De manière avantageuse, cela permet de rendre la comparaison entre les images de chiffre plus précise. De manière avantageuse, cela permet de s'assurer qu'une image de chiffre est bien classée dans la classe où elle devrait être classée en dépit d'une différence dans sa composition de pixels qui serait due à une variation fortuite de la taille de l'image de chiffre.

[00169] L'inventeur du présent Procédé a développé un algorithme propriétaire dit de « coïncidence forte » : deux images coïncidant fortement sont placées dans la même classe, et la propriété de la relation de coïncidence forte est qu'elle est une relation d'équivalence au sens mathématique du terme : deux images reliées par la Relation de coïncidence forte correspondent toujours au même chiffre, quand bien même on ne connaît pas encore la valeur de ce chiffre. Chaque classe relève alors du concept mathématique de Modèle, et chaque Modèle est alors océrisé sur une image quelconque le représentant.

[00170] Par regroupement de ces images en Modèles de chiffres, on peut ainsi diminuer substantiellement le nombre de vérifications des couples <image du chiffre/chiffre océrisé>, à effectuer par la personne vérificatrice : on passe typiquement d'une vérification de plusieurs milliers à seulement quelques dizaines de couples à vérifier. A ce niveau, le gain quantitatif peut être considéré comme qualitatif.

[00171] A titre illustratif, la figure 8 montre deux lignes de chiffres représentatifs des Modèles de chiffres définis par l'algorithme de Coïncidence forte devant faire l'objet d'une vérification par la personne vérificatrice : la ligne supérieure 51 reproduit les Modèles d'images de chiffres, à travers leurs représentants, et la ligne inférieure 53 comprend les chiffres obtenus par océrisation de chacune des images de la ligne supérieure : le travail de la personne vérificatrice consiste donc à vérifier visuellement que les chiffres de la ligne inférieure correspondent bien aux images de la ligne supérieure.

[00172] Si un chiffre de la ligne inférieure 53 ne correspond pas à l'image du chiffre de la ligne supérieure 51, comme cela est visible en 55 sur la figure 8 (chiffre 9 sur la ligne inférieure et image d'un 4 sur la ligne supérieure), la personne vérificatrice corrige le chiffre de la ligne inférieure par un 4 sur son interface de pilotage. [00173] Cette correction est transmise au noyau (27), qui va alors réactualiser les valeurs associées aux Modèles de chiffres corrigés.

[00174] Les montants de chaque case peuvent alors être reconstitués automatiquement et sans erreur par le Noyau en extrayant les images réelles des chiffres de la case, en les « reconnaissant » successivement par comparaison avec les images de chaque Modèle de chiffre à travers l'algorithme de Coïncidence forte, retenant la valeur numérique associée au Modèle de chiffre Coïncidant.

[00175] La personne vérificatrice a alors accompli sa tâche assurant l'extraction sans erreurs des valeurs des cases sensibles sans jamais avoir accès à ces montants ni à pouvoir les reconstituer d'une quelconque manière.

[00176] Une fois que les deux étapes de vérification décrites ci-dessus ont été réalisées, le noyau (27) parcourt toutes les cases du Document Tabulaire Référencé dans lesquelles les identifiants vérifiés ont été remplis, et associe (57) à chacun de ces identifiants les montants sous-jacents reconstitués par le Noyau (27) comme dit plus haut.

[00177] On obtient de la sorte une série de couples <identifiant/montant> vérifiés, qui peuvent être structurés à l'intérieur d'un fichier de résultats vérifié (59), édité au format demandé par le client final, c'est-à-dire celui du Logiciel d'Analyse Financière qu'il utilise, et qui ne dépend en général pas de lui, mais du professionnel de l'Analyse Financière éditeur/concepteur de ce logiciel. A ce titre, cet Editeur peut choisir deux modes de formats d'entrée de résultats : un mode de type <identifiant/montant>, les identifiants lui étant propres, et dans ce cas, il y a lieu pour le Prestataire de disposer d'un dictionnaire traduisant ses propres Identifiants en ceux demandés par le logiciel d'Analyse Financière, un mode « Mapping » donnant l'ordre d'apparition des résultats numériques demandés sur un fichier monovaleur, la traduction pouvant s'effectuer à partir d'une grille indiquant la liste des identifiants du Prestataire correspondant à chaque position de l'Editeur du logiciel d'Analyse Financière.

[00178] On comprend donc que l'invention permet de vérifier la fiabilité des couples <identifiant/montant> sans jamais accéder à des informations permettant de reconstituer ces montants : l'interface de pilotage (31) permet d'effectuer cette vérification de manière indirecte, par lecture et comparaison de chiffres isolés dont la personne vérificatrice ne peut identifier l'origine.

[00179] A l'issue des deux étapes de vérification décrites ci-dessus, le noyau (27) conserve dans la base de données du prestataire, et pour le Document Tabulaire Référencé rtraité, un Dossier Révélateur associé à ce Document, composé : d'un fichier de localisation physique des identifiants dans les cases du Document Tabulaire Référencé, et du fichier des Modèles de chiffres vérifiés par la personne vérificatrice, ce Dossier Révélateur étant indexé de manière univoque par tout moyen approprié tel que la combinaison d'un numéro d'immatriculation de l'entreprise (SI REN/SI RET) avec la date d'édition du fichier de résultats vérifié, ou, plus anonymement, par un numéro chronologique dont le Noyau (27) a la clé de dépouillement.

[00180] Ce Dossier Révélateur ne contient aucun des montants figurant dans les cases du formulaire rempli, ce qui renforce la demande de confidentialité des données puisqu'aucun de ces montants n'est archivé.

[00181] Lorsque que le Prestataire reçoit un nouveau document à traiter, il regarde dans sa base de données si un précédent passage du même document a été enregistré, ce que le Noyau (27) détecte à travers l'indexation des Dossiers Révélateurs déjà archivés, cela permet de charger immédiatement dans la mémoire du noyau (27) le Dossier Révélateur susmentionné, et ainsi, par son exhumation, de retrouver les résultats transmis à l'époque par les opératrices et de rééditer les résultats finaux à l'identique de ce qu'il avait fait à l'époque en toute confidentialité, cela : sans que les montants situés dans les cases du Document Tabulaire Référencé rempli n'aient été stockés à aucun endroit du système, et sans nécessiter une quelconque nouvelle opération de vérification de la part de la personne vérificatrice.

[00182] A titre d'illustration, si, entre les passages initiaux et ultérieurs du Document Tabulaire Référencé rempli dans le système selon l'invention, certains montants avaient été modifiés, le fichier de Résultats à nouveau généré tiendrait compte de ce changement.

[00183] Naturellement, l'invention est décrite dans ce qui précède à l'aide d'exemples. Il est entendu que la personne du métier est à même de réaliser différentes variantes de réalisation de l'invention sans pour autant sortir du cadre de l'invention.

[00184] C'est ainsi par exemple que l'invention pourrait s'appliquer à la vérification de données autres que des couples <identifiant/montant> : il pourrait s'agir de la vérification de triplets, quadruplets, n-uplets de données chiffrées ou lettrées, voire d'éléments graphiques.

[00185] C'est ainsi également que l'on peut prévoir que le Noyau ignore les caractères alphanumériques autres que les 10 chiffres en caractères droits/italiques/normaux/gras, et notamment les lettres et caractères spéciaux en majuscules/minuscules droits/italiques/normaux/gras, permettant ainsi de réduire le nombre de caractères à vérifier d'au moins 400 à 40.

[00186] C'est ainsi également que l'on pourrait remplacer une intervention humaine pour la deuxième étape décrite ci-dessus de vérification des chiffres associés à chaque Modèle de chiffre, par l'envoi des images de ces Modèles de chiffres, ordonnées par ordre croissant des valeurs trouvées pour ces chiffres par l'OCR interne à un prestataire extérieur spécialisé disposant de moyens d'OCR très puissants, tel que , remplaçant l'opératrice humaine vérifiant ces valeurs par une totale automaticité. [00187] C'est ainsi également que l'on pourrait prévoir que le noyau (27) accomplisse des vérifications complémentaires en effectuant des opérations sur les montants sous- jacents aux identifiants renseignés dans le Document Tabulaire Référencé rempli.

[00188] Ces opérations peuvent être par exemple du type XX1_2 + XX2_2 + XX3_2 + ... XXn_2 = TOT_2 (exemple pour la colonne _2, où XXi_2 désigne l'identifiant de la ligne i), ou YY2 1 -YY2 2 = YY2 3 (exemple pour la ligne 2, où YY2_i désigne l'identifiant de la colonne i).

[00189] C'est ainsi également que l'on pourrait prévoir d'utiliser les Dossiers Révélateurs stockés dans le noyau pour effectuer des Sélections d'Entreprises selon certains critères exprimés sous forme d'expressions algébriques conditionnelles utilisant les Identifiants des postes impliqués, et un archivage hyperprotégé contenant l'historique des Documents Tabulaire Référencés initiaux traités, permettant de re-générer furtivement les montants des cases comme indiqué en [0095] pour un deuxième passage, le temps d'utiliser les données régénérées pour la sélection programmée.

[00190] Exemple : recherche des entreprises dont le chiffre d'affaires (identifiant XX) est compris entre tel et tel montant : l'espace de temps où les montants régénérés pour chaque Document Tabulaire Référencé traité pourraient être piratés de l'extérieur se réduit à quelques millisecondes, rendant ce risque improbable.

[00191] C'est ainsi également que l'on pourrait encore augmenter le niveau de sécurité de l'invention, en prévoyant de rapprocher de manière éphémère, dans un autre noyau sécurisé, le Document Tabulaire Référencé rempli et le Dossier Révélateur associé, uniquement pendant le temps très court durant lequel on interroge le Dossier Révélateur pour effectuer une recherche particulière, telle qu'une recherche par chiffre d'affaires.

[00192] C'est ainsi également que l'on peut ajouter des outils périphériques au procédé de l'invention, procédant du même esprit général de masquage des données aux personnes vérificatrices.

[00193] Un exemple d'un tel outil, qui se révèle très pratique à l'usage, est une Calculatrice Virtuelle (que l'on pourrait aussi appeler Calculatrice Défigurée), permettant aux personnes vérificatrices de vérifier si des relations arithmétiques entre certaines cases des Documents Tabulaires Référencés sont satisfaites, sans voir les montants remplis dans ces cases.

[00194] La Calculatrice Virtuelle tient dans une ligne placée en bas de page de l'écran de vérification des Documents Tabulaires Référencés, comme une note en bas de page et reste fixe, l'écran d'affichage réservé au Document Tabulaire Référencé traité étant limité à l'encadrement de la pleine page, qui se rafraîchit à chaque passage à la page suivante du Document, et peut, aussi, avoir une navette verticale si nécessaire.

[00195] La Calculatrice Virtuelle est composée de trois cases rectangulaires qui se suivent sur la ligne, entrecoupées de deux symboles à choix multiples : signes arithmétiques et signes de relation entre montants. Une case carrée contenant le sigle « OK » termine la ligne. Les trois cases rectangulaires sont remplies d'une couleur de fond de case spécifique à chacune d'elles : à titre d'exemple, bleu pour la première, vert pour la deuxième, rose pour la troisième, comme indiqué sur la figure 9.

[00196] Le principe de la Calculatrice Virtuelle est que la personne vérificatrice indique les cases de la page affichée du Document Tabulaire Référencé dont le montant doit être transféré dans chacune des cases colorées. La coloration différenciée des cases sert à afficher sur le Document la case choisie pour y transférer sa valeur : elle se colorie de la couleur de la case réceptrice. En effet, les cases du Document Tabulaire Référencé ne sont pas forcément remplies d'un identifiant, bien au contraire, sinon, il n'y aurait pas lieu de lever une ambigüité.

[00197] Lorsque la personne vérificatrice a désigné les cases correspondant à chaque couleur, et a choisi les signes arithmétiques et ceux de relation entre montants, elle clique sur la case carrée « OK », ce qui provoque l'envoi au Noyau de la localisation des cases colorées du Document Tabulaire Référencé, et des signes arithmétiques et relationnels choisis, Noyau qui : extrait les montants sous-jacents aux cases colorées, effectue les calculs arithmétiques demandés, vérifie la relation numérique entre montants, avec une tolérance deux unités monétaires (€ par exemple), renvoie son résultat au pilote d'interface, à réception, le pilote d'interface remplit la case OK : en vert si le résultat est positif, en rouge s'il est négatif.

[00198] La personne vérificatrice n'a plus qu'à effectuer ses choix en fonction du résultat, et continuer sa vérification.

[00199] MODE DE REALISATION : en se référant à la figure 9, la référence D désigne le Document Tabulaire Référencé, et C la Calculatrice Virtuelle.

[00200] Au départ, les trois cases de la Calculatrice Virtuelle sont mises à blanc.

[00201] Puis :

Clic 1 : la case se remplit de bleu ;

Clic 2 : la case cliquée sur le Document se remplit de bleu ;

Clic 3 : la case se remplit de vert;

Clic 4 : la case cliquée sur le Document se remplit de vert ;

Clic 5 : la case se remplit de rose ;

Clic 6 : la case cliquée sur le Document se remplit de rose ;

Clic 7 : choix de l'opérateur arithmétique ;

Clic 8 : choix de la relation logique ;

Clic 9 : la case « OK » se remplit de vert : envoi de la requête au Noyau. [00202] Retour des résultats du Noyau au Pilote d'interface : si OK, la case « OK » se remplit de jaune ; si pas OK, a case « OK » se remplit de rouge.