La saisie de données aurait dû être résolue
plusieurs fois déjà

Le problème qui persiste

Toute organisation qui traite des documents externes — factures, reçus, contrats, relevés, rapports de laboratoire, manifestes d'expédition — fait face au même problème : les données existent sur papier ou sous forme d'image et doivent exister dans un système. Les documents arrivent dans des formats contrôlés par l'expéditeur, pas par le destinataire. Intégrer ces informations dans le système récepteur de manière fiable, précise et à grande échelle, voilà ce qu'est concrètement la saisie de données.

Ce qui frappe dans l'histoire de la saisie de données, c'est que chaque époque a produit une technologie qui a réellement amélioré la précédente — tout en créant un nouveau goulot d'étranglement au lieu d'éliminer l'ancien. La nature du travail a changé. Le volume de travail, lui, n'a pas diminué.

Les époques

Années 1950 – 1970 : L'ère de la perforatrice

Avant que les ordinateurs ne soient interactifs, la saisie de données était un processus de fabrication physique. Les documents sources — bons de commande, registres comptables, feuilles de paie — étaient convertis en cartes perforées IBM à raison d'un caractère par trou. Un opérateur de perforatrice travaillait sur une machine ressemblant à une machine à écrire, poinçonnant des trous dans des cartes de 80 colonnes. La carte était la donnée.

La précision primait sur la vitesse, car les erreurs n'étaient pas immédiatement visibles. Une passe de vérification — consistant à ressaisir la carte sur une machine distincte signalant les divergences — était une pratique courante. Ensuite, les lots de cartes étaient soumis au centre de calcul, traités pendant la nuit, et les résultats imprimés le lendemain matin. Si une carte était mal perforée, le délai pour la corriger et la soumettre à nouveau était d'une journée entière.

Le goulot d'étranglement résidait dans les mains humaines et la latence des lots. Le travail était qualifié : les opératrices de perforation étaient certifiées, testées et employées dans de vastes pools dédiés. Les grandes organisations maintenaient des étages entiers d'opératrices de perforation comme infrastructure — non pas comme une solution de contournement, mais comme une fonction de production reconnue.

Années 1980 – 1990 : Les tableurs changent la destination, pas la saisie

VisiCalc est arrivé en 1979. Lotus 1-2-3 a suivi en 1983. Au milieu des années 1980, Excel tournait sur Macintosh. Ces outils ont transformé ce qui arrivait aux données après leur saisie — des calculs qui nécessitaient auparavant un traitement par lot s'effectuaient désormais instantanément sur un bureau. Pour la première fois, une seule personne pouvait construire, maintenir et analyser un ensemble de données sans équipe de programmation.

Ce que les tableurs n'ont pas changé, c'est la manière dont les données entraient dans le système. Chaque cellule était toujours tapée par une personne lisant un document source. Le goulot d'étranglement est passé du délai de traitement par lot à la vitesse et à la précision de frappe humaine. La saisie de données s'est démocratisée — quiconque avait un clavier était un opérateur de saisie — mais l'opération fondamentale, une personne lisant un document et tapant des valeurs dans des cellules, était identique à ce que les opératrices de perforation faisaient sur un matériel différent.

L'ère du tableur a aussi introduit un nouveau mode de défaillance : des erreurs de formule cachées dans des cellules d'apparence correcte. Les données pouvaient être transcrites avec exactitude, mais mal utilisées en aval. Le problème de précision s'est scindé en deux : la précision de transcription et la précision des formules. Les deux nécessitaient une relecture humaine, mais désormais, le relecteur était souvent la même personne qui avait saisi les données — un contrôle moins rigoureux que la vérification indépendante de l'ère de la perforation.

Fin des années 1990 – 2000 : La première vague de l'OCR

La reconnaissance optique de caractères a gagné en maturité durant cette période. Les scanners à plat sont devenus des équipements de bureau. Des produits comme ABBYY FineReader pouvaient convertir des documents scannés en texte lisible par machine avec une précision raisonnable sur des sources imprimées propres. La promesse était réelle : en scannant un document, on pouvait sauter complètement l'étape de ressaisie.

L'OCR fonctionnait bien sur les formulaires standardisés — documents fiscaux imprimés selon des modèles gouvernementaux cohérents, relevés bancaires du même établissement chaque mois, formulaires d'assurance inchangés depuis des années. La reconnaissance des caractères était suffisante ; c'était la reconnaissance de la mise en page qui posait problème. Pour tout ce qui n'avait pas une structure fixe et prévisible, l'OCR produisait un flux de texte qui exigeait toujours qu'une personne lise, localise les valeurs pertinentes et les saisisse dans le système cible. La reconnaissance des caractères faisait gagner du temps de frappe ; elle ne faisait pas gagner du temps de compréhension.

Le goulot d'étranglement est passé de la vitesse de frappe à la charge de correction. Le résultat d'un OCR pour un document non standard était souvent plus difficile à traiter qu'une cellule vide — il fallait désormais trouver et corriger les erreurs dans un texte existant plutôt que de simplement taper avec précision. Pour les types de documents avec un volume suffisant et une cohérence de mise en page, l'OCR basé sur des modèles avec des règles de validation fonctionnait. Pour les sources mixtes, il restait souvent plus rapide de ressaisir que de corriger.

Années 2000 – 2010 : Documents numériques et problème d'intégration

Alors que les ERP devenaient une infrastructure standard en entreprise et que les fournisseurs généraient des PDF depuis un logiciel plutôt que d'imprimer du papier, une attente raisonnable a émergé : le passage du numérique au numérique devrait être fluide. Le document source était déjà un fichier. Le système cible était déjà numérique. Le problème de transcription était forcément résolu.

Le problème d'intégration a remplacé le problème de transcription. Chaque ERP avait son propre format d'import. Chaque fournisseur avait son propre modèle de PDF. L'EDI (échange de données informatisé) a standardisé les transactions entre grands partenaires commerciaux — mais uniquement pour les paires d'organisations disposant d'accords d'intégration dédiés et de ressources informatiques pour les maintenir. La longue traîne des petits fournisseurs, des vendeurs ponctuels et des types de documents hors norme EDI a continué d'exiger un traitement humain.

Parallèlement, le format PDF, optimisé pour l'impression plutôt que pour l'extraction de données, a fait que même les documents numériques nécessitaient souvent un travail d'analyse. La main-d'œuvre est passée des dactylos aux équipes informatiques construisant et maintenant des intégrations, tandis que le reste non structuré — factures de fournisseurs ne justifiant pas le coût d'intégration, relevés de petites banques, documents aux formats non standard — était toujours traité manuellement.

Années 2010 : Automatisation basée sur des règles

Les outils d'automatisation robotisée des processus ont abordé le problème de la saisie de données en automatisant ce que faisaient les humains : lire un écran, cliquer sur des champs, saisir des valeurs. Un robot pouvait traiter une facture en quelques secondes plutôt qu'en minutes. Pour les flux de travail répétitifs à volume élevé avec un format source stable, le RPA a apporté de réels gains de productivité — non pas incrémentaux, mais une réduction d'un ordre de grandeur du temps de traitement par document.

La fragilité avait un coût. Les bots RPA fonctionnaient sur des règles : trouver le champ nommé « Numéro de facture » dans la zone X du document, extraire la valeur, la coller dans le champ Y du système. Lorsque la mise en page du document source changeait — un nouveau fournisseur, un modèle PDF repensé, un système comptable différent côté expéditeur — la règle se brisait et le bot cessait de fonctionner. Surveiller les échecs et mettre à jour les règles lors des changements de mise en page est devenu une charge opérationnelle continue.

Les organisations disposant de quelques workflows stables et à volume élevé pouvaient absorber ce coût de maintenance — les économies par document justifiaient une fonction de maintenance dédiée aux bots. Les organisations ayant des sources documentaires diverses et variables ne le pouvaient pas. Le goulot d'étranglement est passé de la saisie manuelle des données à l'ingénierie des règles et à la maintenance des bots. Les opérateurs de saisie sont devenus, en pratique, des développeurs de bots.

Ce qui a réellement changé dans les années 2020

Chaque technologie précédente fonctionnait par correspondance de motifs avec des modèles connus ou des règles prédéfinies. L'OCR trouvait des caractères. Le RPA faisait correspondre des positions de champs. L'EDI mappait des codes de transaction connus. Toutes exigeaient que la mise en page source soit anticipée à l'avance — c'est pourquoi elles échouaient toutes lorsque la mise en page changeait.

L'extraction par IA fonctionne différemment : elle lit un document de manière sémantique, comme le ferait une personne, et comprend le sens d'un champ indépendamment de son libellé ou de sa position. « N° FACTURE », « INV# », « Référence facture » et « Réf : » sur quatre documents provenant de quatre fournisseurs signifient tous la même chose — et un modèle de langage le sait sans qu'on le lui dise. Le nom de colonne que vous définissez (Numéro de facture) est une instruction pour trouver le concept, et non un mot-clé à faire correspondre à une chaîne ou une zone spécifique.

Cela supprime la dépendance à la mise en page qui rendait fragile toute approche antérieure. Une facture d'un nouveau fournisseur n'est pas une nouvelle règle à écrire — c'est juste un document de plus à traiter avec le même jeu de colonnes. Les définitions de colonnes que vous avez écrites pour le premier fournisseur fonctionnent pour le cinquantième, quelle que soit la différence de formatage de leurs documents.

Le goulot d'étranglement, par époque

À quoi ressemble le travail aujourd'hui

L'extraction par IA n'élimine pas la saisie de données — elle en change la nature. La question centrale passe de « comment extraire cette valeur de ce document » à « de quelles valeurs ai-je besoin, de manière cohérente, pour tous les documents ». C'est une compétence différente de la frappe rapide et précise. Cela se rapproche de la conception de schémas.

• La définition des colonnes remplace la lecture des documents. Vous spécifiez une fois ce que vous voulez — Numéro de facture, Nom du fournisseur, Montant dû (chiffres uniquement), Date d'émission (AAAA-MM-JJ) — et cette définition s'applique à chaque document de tous les lots suivants. La lecture et la recherche de champs sont déléguées au modèle.
• Les exigences de format vont dans le nom de la colonne. "Montant (chiffres uniquement, sans symbole monétaire)" est à la fois un nom de colonne et une instruction de formatage. Ce qui nécessitait auparavant une étape de nettoyage post-traitement est géré dès l'extraction.
• La vérification passe du niveau caractère au niveau ligne. Au lieu de vérifier si chaque frappe correspond à la source, vous vérifiez si chaque ligne extraite a du sens — si les montants sont plausibles, si les dates sont dans la bonne fourchette, si le nom du fournisseur correspond à un fournisseur connu. Détection d'anomalies, pas relecture.
• Le volume devient une non-contrainte. Cinquante factures nécessitent la même configuration de colonnes qu'une seule. Le travail qui évoluait auparavant linéairement avec le nombre de documents évolue désormais avec le nombre de schémas de documents distincts — généralement bien inférieur au nombre de documents.

Les modes d'échec sont également différents. L'extraction par IA échoue lorsque les noms de colonnes sont ambigus, lorsque les documents sont dégradés au point d'être illisibles, ou lorsqu'un champ n'existe tout simplement pas dans un document source. Ce sont des échecs de spécification — résolubles en affinant la définition des colonnes — et non des échecs de vitesse de frappe, qui nécessitaient soit des opérateurs plus rapides, soit davantage d'opérateurs.

Questions fréquentes