Bouygues eDoc.

The problem

Technical drawings carry the information needed to register and submit a document, but that information can be buried in a title block. Re-entering it into eDoc adds repetitive work and creates another opportunity for mistakes.

The extraction task also changes with the input: a PDF containing selectable text needs different processing from a scanned page or an image.

Context & role

I worked on document extraction and backend integration during my PFA internship with Bouygues Construction IT in Casablanca, from July to September 2026. My work connected AI processing with the existing document submission workflow.

The solution

The pipeline separates extraction, classification, and validation. Apache PDFBox reads the native text when it is usable; a language model identifies the title block and its label/value pairs. Scans use a vision path that locates the title block before reading a higher-resolution crop.

The backend maps extracted pairs to the project’s requested fields and checks them against its reference values. Each field is returned as confirmed, requiring review, or missing. The eDoc submission form can then prefill eligible fields for the user to check.

Technical decisions

Prefer native text extraction before rendering images. The Java 17 and Spring Boot engine combines PDFBox with language and vision models through Azure AI Foundry.

Combine constrained model suggestions with fuzzy matching for classification. Validation preserves an unconfirmed value for review instead of silently discarding it, while absent values remain empty. The public standalone engine and the integration documented for eDoc use the same processing responsibilities.

Evidence

The public SYSTEM-OCR README documents the standalone engine, its integration into eDoc, and its evaluation. On a 28-document corpus with the cache cleared, it reports a median latency of 4.3 seconds, compared with 9.6 seconds for the image-based approach. Twenty of those documents used the native text path.

These are repository-reported measurements on that corpus, not independently reproduced results or a general accuracy guarantee. The architecture illustration is sanitized and contains no internal documents or client data.

Limitations

Dense scans still require expensive rendering and image processing. Model responses can vary, and the documented fuzzy-matching thresholds have not been calibrated against a complete ground-truth dataset.

Unclear images, unusual layouts, and ambiguous values need review. The public documentation explains the system, while internal test documents and company systems remain private.

Project access

The source link opens the public SYSTEM-OCR documentation. It explains the standalone engine, the eDoc integration, and the conditions behind its reported measurements. I can discuss these architectural choices without sharing company documents.