Cas 02 · Travaux choisis
Retirer la saisie d’un flux documentaire qui ne pouvait pas s’arrêter
- En production — limité par NDA
Un pipeline hybride OCR et LLM a nettement réduit la saisie manuelle dans un flux de documents maritimes à fort volume, au sein d’une exploitation dont les systèmes sources n’avaient pas d’API et ne pouvaient pas être remplacés.
- Rôle
- Senior Business Process Specialist
- Compétences
- IA appliquée · Automatisation · Responsabilité en production
- Domaine
- Transport maritime de conteneurs — finance et logistique
- Contrainte
- Systèmes sources sans API, et souvent sans interface web exploitable
Contexte
La filiale malaisienne d’un armateur mondial de conteneurs, où j’étais Senior Business Process Specialist. Une petite équipe — l’essentiel du temps un collègue et moi — avec les points de décision dans deux autres pays. Le personnel de la finance et de la logistique lisait chaque jour un volume important de documents d’expédition et saisissait à la main ce qu’il y trouvait.
Problème et zones floues
Personne n’avait de description écrite de la façon dont le travail se faisait réellement, donc la première étape n’était pas l’automatisation mais l’archéologie. Les documents arrivaient dans des états très différents, du fichier propre généré par machine à un matériau si mauvais que l’équipe finance le résolvait par téléphone. Et les systèmes aux deux extrémités étaient indépendants : pas d’API, et souvent pas d’interface web exploitable non plus. Les remplacer n’a jamais été envisagé, pour des raisons de coût.
Mon rôle
Mon rôle : j’ai analysé les processus financiers et logistiques non documentés pour identifier quelles étapes manuelles, répétitives et sources d’erreur méritaient d’être automatisées. J’ai conçu l’architecture du pipeline documentaire, construit ses API backend en Python, et développé puis déployé les flux RPA autour.
Recueil du besoin
S’asseoir avec les gens qui font le travail, cartographier ce qui se passe réellement plutôt que ce que le processus prétend, puis soumettre chaque étape candidate à une seule question : si c’est automatisé et que ça tombe en panne un mardi à 9 h, que fait l’entreprise à la place ?
Architecture et arbitrages
OCR hybride plus LLM, ⛔ pas une extraction purement LLM. C’était une décision datée, et c’était la bonne à l’époque : la vision des LLM n’extrayait pas encore de façon fiable depuis des documents réels, donc l’OCR alimentait des panneaux de lecture par format où les positions de champs connues étaient masquées et extraites par position, et le modèle de langue faisait la partie où il était bon. L’intégration était délibérément non intrusive — lire depuis ce qui existe déjà, ⛔ ne pas demander à une entreprise de remplacer des systèmes centraux qu’elle n’a aucune intention de remplacer. Mon résumé de l’époque était que nous avions beaucoup de contraintes et ne pouvions donc y arriver que par des chemins détournés, et je pense toujours que c’est la description honnête de la plus grande partie de l’IA en entreprise.
Mise en œuvre et intégration
Des API backend en Python servant les panneaux d’extraction par format et la file de relecture, plus une interface opérateur capable de reprendre un traitement là où l’automatisation s’était arrêtée. RabbitMQ pour le traitement asynchrone. Contrôles de validation et journaux d’audit tout du long. Des flux RPA couvrant la capture, la validation et le rapprochement des données en finance et en logistique.
Contrôles en production
C’est la partie que je défendrais le plus fermement. Les valeurs extraites n’allaient jamais directement en base : elles atterrissaient dans une file de relecture humaine, les corrections s’y faisaient, et même les enregistrements propres étaient revérifiés avant écriture. Une collecte pouvait durer des heures et s’interrompre à n’importe quel moment, donc les traitements ont été conçus comme des nœuds à points de reprise qui repartent d’une position enregistrée plutôt que de zéro. Le travail démarrait tôt le matin précisément pour qu’une panne soit visible à l’arrivée du personnel, en lui laissant le temps de revenir au processus manuel et de terminer la passation avant midi. Et l’automatisation n’a jamais été tout ou rien : si la machine arrivait à mi-chemin, une personne pouvait prendre le reste depuis une interface — ⛔ pas depuis un schéma de nœuds, ⛔ pas depuis le code.
Impact
L’essentiel de la saisie manuelle est sorti du flux, et l’exploitation a tourné sans interruption. Aucun chiffre n’est publié pour cette mission — c’est une décision de confidentialité délibérée, et elle vaut aussi à l’oral.
Enseignement réutilisable
La position d’architecture que j’ai formée ici, je la défends encore : pour les entreprises qui ne remplaceront pas leurs systèmes centraux pour des raisons de coût, la bonne intégration est celle qui lit depuis ce qui est déjà à l’écran de l’opérateur. Et une étape de relecture humaine n’est pas une lacune de l’automatisation — c’est ce qui la rend déployable.
Preuves publiques
Tout ce qui précède peut être discuté publiquement. Ce qui est retenu, et ce qui est en préparation :
Une reconstruction en salle blanche sur des documents synthétiques de type maritime, avec panneaux de lecture, file de relecture et traitements à points de reprise, est spécifiée comme projet P4 ; elle n’est pas construite.
Voici la méthode derrière tout ça
Les réponses viennent de ce site. Il vous dira quand un projet ne vaut pas la peine d’être construit.