La saisie de données était censée avoir été résolue
plusieurs fois déjà

Le problème qui n'en finit pas de ne pas être résolu

Toute organisation qui traite des documents externes — factures, reçus, contrats, relevés, rapports de laboratoire, manifestes d'expédition — est confrontée au même problème : les données existent sous forme papier ou image et doivent exister dans un système. Les documents arrivent dans des formats contrôlés par celui qui les envoie, pas par celui qui les reçoit. Faire entrer ces informations dans le système récepteur de manière fiable, précise et à grande échelle, c'est ce que signifie la saisie de données en pratique.

L'histoire de la saisie de données suit un schéma unique : chaque époque a produit une technologie qui améliorait réellement ce qui existait avant, et chacune a créé 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 changé.

Les époques

Années 1950 – 1970 : l'ère des cartes perforées

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, une colonne à la fois. Chacune des 80 colonnes de la carte contenait un seul caractère, encodé en perforant un à trois trous dans cette colonne. Un opérateur de perforation travaillait sur une machine ressemblant à une machine à écrire, faisant avancer la carte d'une colonne à chaque frappe. La carte était la donnée.

La précision importait plus que la vitesse, car les erreurs n'étaient pas immédiatement visibles. Une passe de vérification — re-perforation de la carte sur une machine séparée qui signalait les divergences — était une pratique standard. Ensuite, des lots de cartes étaient soumis au centre de calcul, traités pendant la nuit, et la sortie était imprimée 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 était les mains humaines et la latence des lots. Le travail était qualifié : les opérateurs de perforation étaient certifiés, testés et employés dans de grands pools dédiés. Les grandes organisations maintenaient des étages entiers d'opérateurs 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 — les calculs qui exigeaient auparavant un traitement par lots s'effectuaient désormais instantanément sur un poste de travail. Pour la première fois, une seule personne pouvait créer, maintenir et analyser un ensemble de données sans équipe de programmation.

Ce que les tableurs n'ont pas changé, c'est la façon dont les données entraient dans le système. Chaque cellule était encore saisie par une personne lisant un document source. Le goulot d'étranglement est passé du délai de traitement par lots à la vitesse et à la précision de la frappe humaine. La saisie de données s'est démocratisée — toute personne ayant un clavier était un opérateur de saisie — mais l'opération fondamentale, une personne lisant un document et saisissant des valeurs dans des cellules, était identique à ce que les opérateurs de perforation de cartes avaient fait sur un matériel différent.

L'ère des tableurs a également 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 précision mais utilisées incorrectement 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 exigeaient une vérification humaine, mais désormais, la personne qui vérifiait était souvent celle qui avait saisi les données — un contrôle plus faible que la passe de vérification indépendante de l'ère des cartes perforées.

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

La reconnaissance optique de caractères a mûri 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 : si vous pouviez scanner un document, vous pouviez 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 constants, relevés bancaires de la même institution chaque mois, formulaires de réclamation d'assurance inchangés depuis des années. La reconnaissance des caractères était suffisante ; la reconnaissance de la mise en page était le problème. Pour tout ce qui n'avait pas une structure fixe et prévisible, l'OCR produisait un flux de texte qui exigeait encore qu'une personne lise, localise les valeurs pertinentes et les saisisse dans le système cible. La reconnaissance des caractères évitait la frappe ; elle n'évitait pas la compréhension.

Le goulot d'étranglement est passé de la vitesse de frappe au temps de correction. La sortie OCR d'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 simplement taper avec précision. Pour les types de documents avec un volume et une cohérence de mise en page suffisants, l'OCR basé sur modèle avec règles de validation fonctionnait. Pour les sources mixtes, il était souvent plus rapide de ressaisir que de corriger. Notre analyse de la précision de l'OCR par IA par rapport à l'OCR traditionnel montre où cet écart se creuse.

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

Alors que les systèmes ERP devenaient une infrastructure d'entreprise standard et que les fournisseurs commençaient à générer des PDF à partir de logiciels plutôt que d'imprimer sur 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'importation. Chaque fournisseur avait son propre modèle de PDF. L'EDI (échange de données informatisé) a standardisé les transactions entre les principaux 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.

Entre-temps, le PDF, en tant que format optimisé pour l'impression plutôt que pour l'extraction de données, signifiait que même les documents numériques nécessitaient souvent un travail d'analyse. La main-d'œuvre est passée des dactylographes aux équipes informatiques chargées de créer et de maintenir les intégrations, le reste non structuré — les factures de fournisseurs qui ne valaient pas le coût d'intégration, les relevés de petites banques, les documents aux formats non standard — étant 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 bot pouvait traiter une facture en quelques secondes plutôt qu'en quelques minutes. Pour les flux de travail à volume élevé et répétitifs avec un format source stable, la 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é était le coût. Les bots RPA fonctionnaient selon des règles : trouver le champ intitulé « 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 de PDF redessiné, un système comptable différent côté expéditeur — la règle se brisait et le bot cessait de fonctionner. La surveillance des pannes et la mise à jour des règles lors des changements de mise en page sont devenues une charge opérationnelle continue.

Les organisations disposant de quelques flux de travail stables et à volume élevé pouvaient absorber ces coûts de maintenance — les économies par document justifiaient une fonction dédiée à la maintenance des bots. Les organisations disposant de sources documentaires diverses et variables ne le pouvaient pas. Le goulot d'étranglement est passé de la saisie de données humaine à l'ingénierie des règles et à la maintenance des bots. Les opérateurs de saisie de données sont devenus, en effet, 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 identifiait 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 la signification des champs indépendamment du libellé ou de la position. « INVOICE NO. », « INV# », « Bill Reference » et « Ref: » 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 (Invoice Number) est une instruction pour trouver le concept, pas un mot-clé à faire correspondre à une chaîne ou une région spécifique.

Cela élimine la dépendance à la mise en page qui rendait chaque approche précédente fragile. La facture d'un nouveau fournisseur n'est pas une nouvelle règle à écrire ; c'est simplement un autre document à traiter avec les mêmes colonnes. Les définitions de colonne que vous avez écrites pour le premier fournisseur fonctionnent pour le cinquantième, quelle que soit la différence de format de leurs documents. Pour un aperçu plus détaillé du mécanisme, consultez notre explication sur comment l'IA extrait des données sans modèles.

Le goulot d'étranglement, par époque

Lue de bout en bout, l'histoire de la saisie de données est une séquence de contraintes déplacées : chaque correction d'une époque est devenue la charge de maintenance de l'époque suivante.

À quoi ressemble le travail aujourd'hui

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

• La définition de colonne remplace la lecture de documents. Vous spécifiez ce que vous voulez une seule fois — Invoice Number, Vendor Name, Amount Due (number only), Issue Date (YYYY-MM-DD) — et cette définition s'applique à chaque document de chaque lot suivant. La lecture et la recherche de champs sont déléguées au modèle.
• Les exigences de format sont intégrées au nom de colonne. « Amount (number only, no currency symbol) » est à la fois un nom de colonne et une instruction de formatage. Ce qui nécessitait auparavant une étape de nettoyage post-traitement est désormais géré au moment de 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 plage, si le nom du fournisseur correspond à un fournisseur connu. Détection d'anomalies, pas relecture.
• Le volume cesse d'être une 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 de défaillance sont également différents. L'extraction par IA échoue lorsque les noms de colonnes sont ambigus, lorsque les documents sont trop dégradés pour être reconnus, ou lorsqu'un champ n'existe tout simplement pas dans un document source. Ce sont des défaillances de spécification — résolubles en affinant la définition de colonne — et non des défaillances de vitesse de frappe, qui exigeaient soit des opérateurs plus rapides, soit davantage d'opérateurs.

Questions fréquemment posées