FR 3142020 A1 20240517 FR 2211885 A 20221115 L'invention concerne un procédé permettant d’extraire des données saisies dans un document tout en préservant la confidentialité de ces données. Le document dans lequel les données ont été saisies est envoyé dans un noyau sécurisé (27) où il est défiguré (30). Par l’intermédiaire d’une interface de pilotage (31), une personne vérificatrice peut saisir des identifiants permettant de déterminer la nature des données, et vérifier la cohérence d’images élémentaires extraites des données avec des caractères résultant de l’océrisation des données. Une fois ces vérifications effectuées, le noyau sécurisé (27) associe (57) les identifiants vérifiés aux données corrigées, permettant l’obtention d’un fichier de résultats vérifié (59). (Fig. 1) Procédé d’extraction Semi Automatique de données sensibles dans des documents, soumis à une stricte confidentialité de ces données 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. 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. 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. 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. Ces traitements peuvent comprendre par exemple des opérations de vérification, de calculs ou d’évaluations. Un exemple d’application de ce qui précède concerne le domaine de la finance et de la comptabilité. 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. 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. 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. 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). 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é. 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. 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. 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. 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. 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 »). Un autre facteur d’erreur est lié à la variabilité des Documents Tabulaires Référencés utilisés par les entreprises. 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. 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. 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. 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 , 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-1 » 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-1, 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. Cette variabilité peut conduire notamment à l’association d’un mauvais identifiant à un montant lors du traitement des données résultant de l’OCR. 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. 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. D’autres méthodes, semi-automatisées, permettent d’atteindre un niveau de fiabilité supérieure. 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. Cette vérification humaine permet ainsi de s’assurer que la valeur du montant et son affectation sont corrects. 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. A partir de cette visibilité, les personnes vérificatrices peuvent donc avoir accès à toutes les informations comptables d’une entreprise. 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. 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). 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. 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é. 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. 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. 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 à : 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 à 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. Suivant d’autres caractéristiques optionnelles du procédé selon l’invention : - 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 ; - lorsque le procédé est appliqué à des Documents Tabulaires Référencés relevant d’un Modèle de document tabulaire : 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 reconnaitre 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 . - 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é ; - on donne aux personnes vérificatrices des moyens d’actions optimisées selon les spécifications suivantes : 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 ; - 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 : 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 ; - lorsque le Noyau détecte, par son indexation, qu’un Document Tabulaire Référencé a 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 ; - 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 ; - 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. La présente invention se rapporte également à un système pour la mise en œuvre du procédé conforme à ce qui précède, comprenant : 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). 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. 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 : : sous forme de logigramme les principales étapes du procédé selon l’invention ; : un exemple de Modèle de document tabulaire , de type CERFA ; : un Document Tabulaire Référencé rempli, qui est une version modifiée remplie du formulaire de la ; : une version défigurée du Document Tabulaire Référencé de la ; : une version identifiée du Document Tabulaire Référencé de la ; : une version augmentée du Modèle de document tabulaire de la ; : une version pré-identifiée par le Noyau du Document Tabulaire Référencé de la ; : un exemple de lignes de chiffres images et océrisés à comparer ; : un exemple de Calculatrice Virtuelle pouvant être mise en œuvre dans le cadre de l’invention. 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. Les références numériques indiquées entre parenthèses renvoient au logigramme de la , et les références numériques qui ne sont pas entre parenthèses renvoient aux figures 2 à 8. 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 : - 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 ; - chiffre, lettre, document océrisés : chiffre, lettre, document résultant de l’océrisation ; – 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 ; - 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 ; - 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é ; - 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 ; - 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é ; - 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 ; - montant : valeur monétaire ou salariale (nombre) renseigné dans une case du Document Tabulaire Référencé rempli ; - chiffre : chacun des chiffres composant le montant ; - 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 ; - noyau : espace logiciel et/ou matériel sécurisé, c’est-à-dire auquel notamment les personnes vérificatrices n’ont pas accès ; - 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 ; - 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 ; - 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 ; - 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 ; - client final : donneur d’ordre auquel sont destinées les données vérifiées grâce au procédé selon l’invention ; - fichier résultat : fichier contenant les données structurées vérifiées du type couples , exploitables par le client final. On se reporte à présent à la , 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. 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. Bien entendu, ce Modèle de document tabulaire pourrait concerner tout autre sujet, et constituer par exemple un modèle de feuille de salaire. 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. 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. 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. Sur la , 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 , en ceci qu’il comprend une colonne supplémentaire 17 permettant de visualiser les montants relatifs à l’année N-1. Dans le cas d’espèce de la , 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). La problématique est donc la suivante : le Document Tabulaire Référencé rempli de la 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. Pour cela, le Document Tabulaire Référencé rempli est envoyé (25) dans le noyau (27) du système selon l’invention sans que la personne vérificatrice puisse y avoir accès. Ce Document Tabulaire Référencé rempli est ensuite océrisé (29), et tous les montants remplis dans les cases 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. 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. 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 , c’est-à-dire le Document Tabulaire Référencé avec des cases vides et d’autres remplies par le Noyau. 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. Pour s’aider dans cette tâche de vérification, la personne vérificatrice peut utiliser le Modèle Augmenté de la : 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 ). 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é . A l’issue de cette intervention de la personne vérificatrice, on obtient le Document Tabulaire Référencé identifié de la , dont les cases pertinentes ont été remplies avec les identifiants 33, 35… choisis par la personne vérificatrice. A noter, comme cela est visible sur cette , que la personne vérificatrice a laissé la dernière colonne 17 vide : cette colonne 17 relative à l’exercice de l’année N-1 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. 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. 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. 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 . 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. Dans l’exemple représenté à la , 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-1, alors qu’ils auraient dû être placés dans l’avant-dernière colonne, relative à l’exercice de l’année N. Une tâche supplémentaire de la personne vérificatrice va donc consister à sélectionner sur le Modèle Augmenté de la 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 , 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 vers la 3ème colonne du Document Tabulaire Référencé de la . 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. 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. 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. 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 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. 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. L’ensemble des couples 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. 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. 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 connait 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. Par regroupement de ces images en Modèles de chiffres , on peut ainsi diminuer substantiellement le nombre de vérifications des couples , à 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. A titre illustratif, la 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. 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 (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. Cette correction est transmise au noyau (27), qui va alors réactualiser les valeurs associées aux Modèles de chiffres corrigés. 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. 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. 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. On obtient de la sorte une série de couples 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 , 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. On comprend donc que l’invention permet de vérifier la fiabilité des couples 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. 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 (SIREN/SIRET) 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. 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é. 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. 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. 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. C’est ainsi par exemple que l’invention pourrait s’appliquer à la vérification de données autres que des couples : 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. 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. 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 GOOGLE®, remplaçant l’opératrice humaine vérifiant ces valeurs par une totale automaticité. 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. 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). 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. 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. 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. 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. 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. 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 rafraichit à chaque passage à la page suivante du Document, et peut, aussi, avoir une navette verticale si nécessaire. 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 . 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é. 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. La personne vérificatrice n’a plus qu’à effectuer ses choix en fonction du résultat, et continuer sa vérification. MODE DE REALISATION : en se référant à la , la référence D désigne le Document Tabulaire Référencé , et C la Calculatrice Virtuelle. Au départ, les trois cases de la Calculatrice Virtuelle sont mises à blanc. 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. 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. Procédé d’extraction semi-automatique de données situées dans un document tabulaire référencé papier ou digital comprenant des cases (9, 11), des identifiants (13, 15) de ces cases (9, 11) et des montants (19, 21) remplis dans ces cases (9, 11), comprenant les étapes consistant à : envoyer (25) le fichier image du document tabulaire référencé rempli dans un ordinateur noyau sécurisé (27) sans qu’une personne vérificatrice puisse y avoir accès, océriser (29) dans cet ordinateur noyau (27) ce document tabulaire référencé, enlever (30) au moyen de cet ordinateur noyau (27) tous les montants (19, 21) remplis dans les cases (9, 11) du document tabulaire référencé, conduisant à un document tabulaire référencé dit « défiguré », stocker ces montants (19, 21) en mémoire dans l’ordinateur noyau (27), de sorte qu’ils deviennent sous-jacents, c’est-à-dire non accessibles à la personne vérificatrice, renseigner (32) les bons identifiants (33, 35) à l’intérieur des cases concernées vidées de leurs montants, faire extraire par l’ordinateur noyau (27) les images de chaque chiffre composant chacun desdits montants, associer (45) au moyen de l’ordinateur noyau à chacune desdites images (51) le chiffre correspondant (53) obtenu par océrisation du document tabulaire référencé rempli, faire vérifier (49) par une personne vérificatrice sur une interface de pilotage (31) si la conversion de l’image du chiffre (51) en chiffre océrisé (53) a été effectuée sans erreur, par lecture et comparaison de chiffres isolés dont la personne vérificatrice ne peut identifier l’origine, si ce n’est pas le cas, faire corriger par la personne vérificatrice sur l’interface de pilotage (31) la valeur erronée (55), réactualiser au moyen de l’ordinateur noyau (27) les valeurs associées auxdites images (51), faire parcourir par l’ordinateur noyau (27) toutes les cases du document tabulaire référencé dans lesquelles les identifiants vérifiés (33, 35) ont étés remplis à l’étape e), et faire associer (57) par l’ordinateur noyau (27) à chacun de ces identifiants (33, 35) les montants sous-jacents reconstitués par cet ordinateur noyau (27). Procédé selon la revendication 1, dans lequel on regroupe lesdites images de chiffres par classes de proximité de forme. Procédé selon la revendication 2, dans lequel 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. Procédé selon l’une quelconque des revendications précédentes, dans lequel on fait remplir les bons identifiants (33, 35) à l’étape e) par une personne vérificatrice. Procédé selon l’une quelconque des revendications précédentes, dans lequel on fait préremplir au moins en partie les bons identifiants (33, 35) à l’étape e) par l’ordinateur noyau (27), et on fait vérifier par une personne vérificatrice que les identifiants préremplis par l’ordinateur noyau (27) sont exacts. Procédé selon l’une quelconque des revendications précédentes, dans lequel 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é. Procédé selon l’une quelconque des revendications précédentes, dans lequel on conserve dans l’ordinateur noyau un dossier dit « révélateur » associé au document tabulaire 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 le document tabulaire référencé concerné 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 nouveau passage du document tabulaire référencé, on détecte ce nouveau passage au moyen de l’ordinateur noyau (27) et on charge dans la mémoire de l’ordinateur noyau (27) le dossier révélateur permettant de régénérer à l’identique les résultats vérifiés par la personne vérificatrice. Programme informatique comportant des instructions pour la mise en œuvre du procédé conforme à l’une quelconque des revendications 1 à 7 lorsque le programme est exécuté par un processeur.