OCR en entreprise : 7 erreurs qui plombent l’automatisation

L’OCR en entreprise permet de transformer le texte d’un document numérisé en données exploitables. Mais pour arrêter les ressaisies, reconnaître les caractères ne suffit pas : il faut extraire les bons champs, contrôler leur cohérence et transmettre le résultat au bon logiciel. La documentation de Google Document AI distingue ces différentes capacités, de la lecture du texte à l’extraction structurée.

Votre objectif n’est donc pas de fabriquer un PDF dans lequel on peut rechercher un mot. C’est, par exemple, de transformer un bon de commande reçu par email en commande prête à vérifier dans votre outil de gestion.

Voici sept erreurs à éviter pour construire cette chaîne, avec des exemples de fonctionnement, une méthode de budget et les tests à prévoir avant de laisser les documents circuler seuls.

Que peut vraiment automatiser l’OCR en entreprise ?

L’OCR, ou reconnaissance optique de caractères, sert à lire le texte présent dans une image ou un document numérisé. L’extraction documentaire ajoute une autre fonction : identifier des informations comme une référence, une date ou les lignes d’un tableau. Les services documentaires peuvent combiner ces fonctions, comme l’explique la présentation des méthodes d’extraction de Google.

Pour cadrer votre projet, séparez trois objectifs :

• Lire : récupérer le texte d’un document.
• Structurer : ranger les informations dans les champs attendus.
• Agir : créer un brouillon, rapprocher un dossier ou proposer une mise à jour dans votre logiciel métier.

Prenons un exemple de fonctionnement, pas un témoignage client : une PME reçoit des bons de commande de ses acheteurs. Le système lit les documents, extrait les références et les quantités, retrouve le compte client, puis prépare une commande. Une personne vérifie les exceptions avant validation.

Le bon livrable est une opération métier prête à traiter, pas simplement du texte reconnu. Gardez cette distinction lorsque vous regardez une démonstration : demandez à voir le résultat dans l’outil utilisé par l’équipe, pas seulement dans l’interface du moteur OCR.

1. Vouloir traiter tous les documents dès le départ

Bons de livraison, commandes, formulaires, contrats, fiches techniques : ne mettez pas toute l’armoire dans le premier pilote.

Choisissez une famille documentaire et une action précise. Par exemple : « Extraire les références et les quantités des commandes clients pour préparer un brouillon dans l’ERP. » C’est un périmètre testable. « Automatiser notre administratif » ne l’est pas.

Pour sélectionner le premier flux, posez ces questions :

• Quel document déclenche une ressaisie répétitive ?
• Quels champs sont réellement nécessaires à l’action suivante ?
• Qui peut vérifier le résultat sans chercher ailleurs ?
• Quelle conséquence aurait une donnée incorrecte ?

Demandez ensuite des exemples représentatifs : documents propres, photos difficiles, présentations différentes et dossiers incomplets. Microsoft recommande de mener un pilote représentatif du cas d’usage pour évaluer la qualité d’extraction et déterminer les règles de traitement dans sa note de transparence sur Document Intelligence.

Le réflexe utile : écrivez ce qui sera exclu du pilote. Un contrat manuscrit ajouté « tant qu’on y est » doit devenir une décision de périmètre, pas une surprise en cours de développement.

2. Confondre texte reconnu et données utilisables

Lire « référence client » ne signifie pas avoir identifié la référence de commande. Et retrouver tous les mots d’un tableau ne garantit pas que chaque quantité sera associée au bon produit.

La structure mérite donc autant d’attention que les caractères. Google distingue notamment l’extraction de texte, la reconnaissance de mise en page et l’extraction de champs dans sa documentation Document AI.

Avant de tester une solution, définissez votre résultat attendu :

Ces scénarios sont des exemples de conception, pas des garanties de faisabilité pour n’importe quel document.

Le réflexe utile : demandez un exemple de sortie avec les noms exacts des champs de votre logiciel. Une belle transcription qui impose ensuite un copier-coller reste une étape manuelle.

3. Demander au moteur OCR de réparer des documents illisibles

Une page de travers, un texte trop pâle ou un cadrage maladroit méritent un contrôle avant extraction. La documentation officielle de Tesseract décrit plusieurs facteurs qui dégradent ses résultats, dont l’inclinaison des pages, le bruit et les bordures.

Ne répondez pas immédiatement par « changeons de moteur ». Commencez par regarder ce que votre système reçoit vraiment.

Pour un flux photographié sur le terrain, prévoyez une consigne courte : document entier, texte lisible, éclairage sans ombre gênante. Pour un dépôt depuis un ordinateur, demandez le fichier d’origine lorsqu’il est disponible, plutôt qu’une capture d’écran.

Ajoutez ensuite un chemin de secours explicite :

• document exploitable : poursuivre le traitement ;
• document à vérifier : demander une confirmation ;
• document inexploitable : demander un nouvel envoi ou orienter vers la saisie manuelle.

Le réflexe utile : rédigez des messages de rejet actionnables. « La référence produit n’est pas lisible, merci de reprendre la photo » aide davantage que « erreur de traitement ».

Une interface de collecte adaptée peut faire partie d’une application web utilisée par les équipes ou les clients. Le sujet est alors aussi ergonomique : comment obtenir un document exploitable sans compliquer son dépôt ?

4. Faire confiance au score sans vérifier le métier

Certains services renvoient des scores de confiance pour leurs prédictions. Microsoft recommande de les utiliser pour orienter les résultats vers une acceptation automatique ou une revue humaine, et précise que tous les champs ne disposent pas nécessairement d’un score dans sa documentation sur la confiance et la précision.

Pour votre projet, utilisez le score comme un signal parmi d’autres. Ajoutez des contrôles liés à votre activité :

• la référence extraite existe-t-elle dans le catalogue ?
• le client correspond-il au dossier sélectionné ?
• l’unité est-elle compatible avec le produit ?
• la quantité respecte-t-elle les règles définies pour cette commande ?
• un champ obligatoire manque-t-il ?

Exemple de règle à prévoir : si un document mentionne une quantité en cartons alors que le logiciel attend des unités, ne transmettez pas directement le nombre reconnu. Exigez une conversion connue ou une validation.

Le réflexe utile : classez les champs selon la conséquence d’une erreur. Une référence qui déclenche une préparation logistique mérite un contrôle différent d’une observation ajoutée à un brouillon.

Ne fixez pas un seuil universel par intuition. Déterminez vos critères d’acceptation sur les résultats du pilote et sur le risque propre à chaque action.

5. Oublier la connexion avec l’ERP, le CRM ou le logiciel métier

« Nous avons extrait les données » n’est pas une définition suffisante de « terminé ».

Définissez toute la suite du parcours : dans quel outil les données arrivent-elles ? Qui en devient responsable ? Que se passe-t-il si le client est introuvable ou si le logiciel destinataire ne répond pas ?

Pour une première mise en service, privilégiez un brouillon plutôt qu’une opération définitive. La préparation d’une commande doit être distinguée de son acceptation, de sa préparation physique et de son expédition.

Demandez aussi ces protections dans le cahier des charges :

• Une détection des doublons : empêcher qu’un même document déclenche deux créations.
• Une reprise contrôlée : relancer un traitement interrompu sans multiplier les opérations.
• Des statuts lisibles : reçu, à vérifier, transmis, rejeté.
• Une trace de transmission : savoir quelles données ont été envoyées et quel résultat a été reçu.

Il s’agit d’exigences de conception à tester, pas de fonctions à supposer présentes.

Le réflexe utile : faites dessiner le trajet d’un document, de sa réception jusqu’au travail terminé. Pour une intégration à un ERP ou CRM, chaque passage entre outils doit avoir un responsable et une règle d’échec.

6. Prévoir une validation humaine que personne ne veut utiliser

« Un humain vérifiera » est une intention. Il faut maintenant lui donner un écran, une responsabilité et une tâche claire.

Microsoft recommande d’envisager une revue humaine pour les résultats d’extraction dans sa documentation sur les scores de confiance. Pour votre interface, prévoyez de montrer le document original à côté des champs proposés.

L’opérateur doit pouvoir comprendre rapidement :

• ce qui a été extrait ;
• ce qui bloque la transmission ;
• ce qu’il peut corriger ;
• ce que sa validation déclenchera.

Évitez de lui imposer une chasse au trésor entre sa messagerie, un PDF et une liste de valeurs sans contexte. Prévoyez également une option « impossible à traiter » avec un motif, plutôt qu’un bouton de validation obligatoire.

Le réflexe utile : faites tester l’écran de correction par la personne qui traitera les exceptions. Observez la tâche complète, pas seulement son avis sur la maquette.

Conservez les corrections comme matière d’analyse. Elles permettront de décider s’il faut améliorer la collecte, revoir une règle ou adapter l’extraction. Ne promettez pas que le système « apprend tout seul » après chaque modification.

7. Traiter la confidentialité comme un détail de fin de projet

Un formulaire peut contenir des coordonnées, une signature ou des informations relatives à une personne. Lorsqu’un service traite des données personnelles pour votre compte, les obligations de sous-traitance doivent être examinées. La CNIL propose des ressources pour encadrer cette relation.

Avant de transmettre des documents réels, vérifiez notamment :

• les données envoyées et la finalité du traitement ;
• les personnes autorisées à consulter les documents et les résultats ;
• les lieux de traitement et les éventuels transferts ;
• les conditions de conservation et de suppression ;
• les engagements du service concernant la réutilisation des données.

La durée de conservation doit être déterminée en fonction de la finalité et des obligations applicables, comme le rappelle la CNIL dans son guide sur la conservation.

Le réflexe utile : distinguez le document métier à conserver, la copie temporaire utilisée pour le traitement et les traces techniques. Définissez une règle pour chaque catégorie plutôt qu’un unique « on garde tout ».

Pour les tests, privilégiez des documents fictifs ou des copies correctement préparées lorsque les données réelles ne sont pas nécessaires.

Combien coûte un projet OCR pour une PME ?

Un projet OCR doit être chiffré sur l’ensemble du parcours documentaire : collecte, extraction, contrôles, intégration, validation et exploitation. Le prix du moteur ne représente qu’un poste ; certaines offres distinguent aussi la lecture OCR et les fonctions d’extraction, comme le montre la tarification officielle de Google Document AI.

Plutôt qu’une fourchette déconnectée de vos documents, demandez un budget séparant :

1. Le cadrage : analyse du flux et définition des résultats attendus.
2. Le pilote : essais, comparaison aux résultats vérifiés et ajustements.
3. Le développement : collecte, interface de correction et connexion au logiciel.
4. L’exploitation : traitements, stockage, surveillance et maintenance.
5. Le travail interne : préparation des exemples, validation et traitement des exceptions.

Pour comparer les propositions, utilisez le même périmètre et les mêmes documents. Demandez comment sont comptés les pages, les nouveaux essais et les traitements complémentaires.

Mesurez ensuite le coût par dossier correctement traité : dépenses d’exploitation et temps de contrôle, rapportés aux dossiers aboutis. C’est un indicateur de pilotage proposé, pas une norme.

Pour inscrire cette dépense dans la durée, la méthode de planification de la maintenance d’un logiciel métier permet d’élargir la réflexion au support et aux évolutions.

Comment tester un projet OCR avant de le généraliser ?

Testez une chaîne complète sur des documents représentatifs, puis comparez les résultats à une vérification humaine de référence. Le pilote doit montrer ce qui peut passer automatiquement, ce qui demande une correction et ce qui doit rester hors périmètre, conformément à l’approche d’évaluation recommandée par Microsoft pour Document Intelligence.

Voici une grille de recette à adapter :

• Champs : vérifier séparément références, dates, quantités et unités.
• Variations : essayer plusieurs présentations et qualités de document.
• Exceptions : envoyer un dossier incomplet et contrôler son orientation.
• Doublons : déposer deux fois le même document.
• Interruption : simuler un échec de transmission, puis une reprise.
• Correction : vérifier ce qui arrive dans le logiciel après modification.
• Accès : tester les droits avec différents profils utilisateurs.

Suivez le temps de contrôle, les erreurs par champ critique et les dossiers réellement terminés. Ne retenez pas uniquement une moyenne de reconnaissance.

Terminez le pilote par une décision écrite : périmètre accepté, exceptions connues, contrôles obligatoires et personne responsable du suivi. « La démonstration était convaincante » n’est pas un critère de mise en production.

Questions fréquentes

Qui doit piloter un projet OCR dans une PME ?

Désignez une personne responsable du processus documentaire, accompagnée d’un référent technique. La première définit les résultats attendus et valide les cas métier ; le second vérifie l’intégration, les accès et l’exploitation. Faites participer les utilisateurs chargés des corrections dès le pilote.

Faut-il reprendre toutes les anciennes archives ?

Pas nécessairement. Séparez le besoin de traitement des nouveaux documents du besoin de consultation historique. Commencez par les archives liées à un usage identifié : recherche de références, reprise de dossiers ou enrichissement d’un catalogue. Évitez de traiter un stock entier sans savoir comment le résultat sera utilisé.

Peut-on automatiser des documents venant de plusieurs fournisseurs ?

Traitez cette diversité comme un critère de test. Constituez des exemples provenant de chaque famille de présentation, puis vérifiez les champs attendus. Définissez aussi le comportement prévu lorsqu’un nouveau format arrive : revue humaine, rejet explicite ou ajout au périmètre après validation.

Comment éviter de dépendre entièrement du service d’extraction ?

Demandez que vos champs métier soient décrits indépendamment du format de réponse du service. Prévoyez l’export des résultats, des règles documentées et un jeu de tests réutilisable. Vous disposerez ainsi d’une base concrète pour évaluer un remplacement, sans devoir redéfinir tout le processus.

Le prochain document est votre meilleur point de départ

Pour lancer l’OCR en entreprise, prenez un document réellement ressaisi et écrivez trois choses : les champs nécessaires, l’action attendue et les erreurs inacceptables. Construisez puis testez ce parcours jusqu’au logiciel destinataire. Le progrès à rechercher est simple : moins de manipulations, sans perdre le contrôle du travail réalisé.