Bouygues eDoc.

Le problème

Les plans techniques contiennent les informations nécessaires à l’enregistrement et au dépôt d’un document, souvent dans un cartouche. Les ressaisir dans eDoc représente un travail répétitif et une source supplémentaire d’erreurs.

Le traitement dépend aussi du document : un PDF avec du texte sélectionnable et une page numérisée ne demandent pas la même approche.

Contexte & rôle

J’ai travaillé sur l’extraction documentaire et l’intégration backend pendant mon stage PFA chez Bouygues Construction IT à Casablanca, de juillet à septembre 2026. Mon travail reliait le traitement IA au processus existant de dépôt des documents.

La solution

La chaîne sépare extraction, classification et validation. Apache PDFBox lit le texte natif lorsqu’il est exploitable ; un modèle de langage identifie le cartouche et ses paires libellé/valeur. Pour les scans, le traitement visuel localise le cartouche avant de lire une zone rendue en haute résolution.

Le backend associe les paires aux champs demandés pour le projet et les vérifie dans les valeurs de référence. Chaque champ est signalé comme confirmé, à revoir ou manquant. Le formulaire eDoc peut alors préremplir les champs concernés pour vérification par l’utilisateur.

Choix techniques

Privilégier le texte natif avant de rendre le document en image. Le moteur Java 17 et Spring Boot associe PDFBox à des modèles de langage et de vision via Azure AI Foundry.

Combiner les suggestions contraintes du modèle et la correspondance floue pour la classification. La validation conserve les valeurs non confirmées pour revue, tandis que les valeurs absentes restent vides. Le moteur autonome public et l’intégration documentée dans eDoc reposent sur les mêmes responsabilités de traitement.

Éléments présentés

Le README public de SYSTEM-OCR décrit le moteur autonome, son intégration dans eDoc et son évaluation. Sur un corpus de 28 documents avec le cache vidé, il rapporte une latence médiane de 4,3 secondes, contre 9,6 secondes pour l’approche par l’image. Vingt de ces documents ont emprunté la voie du texte natif.

Ces mesures sont celles rapportées dans le dépôt sur ce corpus ; elles ne constituent ni une reproduction indépendante ni une garantie générale de précision. Le schéma d’architecture est simplifié et ne contient aucun document interne ni donnée client.

Limites

Les scans denses nécessitent encore un rendu et un traitement d’image coûteux. Les réponses des modèles peuvent varier et les seuils de correspondance floue documentés n’ont pas été calibrés sur une vérité terrain complète.

Les images peu lisibles, les mises en page inhabituelles et les valeurs ambiguës nécessitent une revue. La documentation publique explique le système ; les documents de test internes et les systèmes de l’entreprise restent privés.

Accès au projet

Le lien vers le code ouvre la documentation publique SYSTEM-OCR. Elle présente le moteur autonome, l’intégration eDoc et les conditions des mesures rapportées. Je peux expliquer ces choix d’architecture sans partager de documents de l’entreprise.