Extraction de schémas techniques v0.1.0 : architecture, améliorations et travaux futurs

Les schémas techniques sont la colonne vertébrale du retail, mais leur extraction depuis des PDF reste un défi permanent. Les marketeurs, les responsables merchandising et les développeurs produit perdent souvent un temps précieux à parcourir des documents surchargés pour trouver des schémas essentiels, comme les plans d’implantation en rayon, les maquettes d’emballage ou les schémas techniques des produits. Cette inefficacité ne pèse pas seulement sur les délais des projets : elle fait aussi grimper les coûts.

Chez atronous.ai, nous avons développé le PDF Schematic Extractor, une solution automatisée qui extrait et étiquette avec précision les schémas techniques contenus dans des PDF, des URL ou des fichiers HTML. En simplifiant ce processus, nous aidons les équipes à gagner du temps, à améliorer la précision et à accélérer le développement produit, tout en réduisant le risque de retards coûteux.

À gauche, une page complexe tirée d’un document produit ; à droite, le schéma technique net que nous en avons extrait

Présentation du PDF Schematic Extractor

Le PDF Schematic Extractor est un package Python conçu pour convertir des fichiers (URL, HTML) en PDF et en extraire les schémas techniques à l’aide de PyMuPDF, OpenCV et Tesseract, ainsi que de Gemini pour l’étiquetage. Il propose à la fois une interface en ligne de commande et une interface web basée sur Streamlit, qui permettent aux utilisateurs d’importer des fichiers, d’extraire des schémas techniques et de télécharger les résultats sous forme de fichiers ZIP. Les évolutions récentes ont visé à améliorer le processus d’extraction des schémas techniques, en répondant aux enjeux de précision, d’efficacité et de facilité d’utilisation.

Workflow du PDF Schematic Extractor

Le projet suit un pipeline structuré pour traiter les entrées et extraire les schémas techniques, comme l’illustre le logigramme :

1. Gestion des entrées : l’outil accepte trois types d’entrées (des URL, des fichiers ou chaînes HTML, ou des PDF). Les URL et les entrées HTML sont traitées par les fonctions url_to_pdf et html_to_pdf de core.py, qui s’appuient sur wkhtmltopdf pour les convertir en PDF. Si l’entrée est déjà un PDF, elle est utilisée directement pour la suite du traitement.
2. Conversion du PDF en images : le PDF (qu’il soit fourni directement ou converti depuis une URL ou du HTML) est converti en images à l’aide de PyMuPDF lors de l’étape “Convert PDF into Images” (conversion du PDF en images). Chaque page du PDF est rendue sous forme d’image distincte, afin de faciliter les traitements fondés sur l’image.
3. Traitement d’image et détection du texte : chaque image fait l’objet d’un prétraitement lors de l’étape “Image Processing” (traitement d’image) afin d’en améliorer la qualité (par exemple, en ajustant le contraste). L’OCR (reconnaissance optique de caractères) de Tesseract est ensuite appliquée lors de l’étape “OCR Text Extraction” (extraction du texte par OCR) pour détecter le texte, et une étape “Filter Text-Heavy Areas” (filtrage des zones chargées en texte) identifie et exclut les régions où le texte domine, afin de concentrer l’analyse sur les zones qui s’apparentent à des schémas techniques.
4. Détection et extraction des schémas techniques : l’étape “Contour Detection” (détection des contours) utilise OpenCV pour repérer les régions susceptibles de contenir un schéma technique en détectant les contours. Ces contours sont regroupés lors de l’étape “Group Contours” (regroupement des contours) pour reconstituer des schémas techniques d’un seul tenant, ce qui réduit la fragmentation. L’étape “Extract Schematics from Images” (extraction des schémas techniques à partir des images) isole ces régions sous forme d’images de schémas techniques individuelles.
5. Étiquetage avec Gemini : l’étape “Schematic Validation” (validation des schémas techniques) utilise Gemini pour confirmer que les régions extraites sont bien des schémas techniques. Le texte environnant est extrait lors de l’étape “Get Nearby Text” (récupération du texte environnant), et Gemini génère des étiquettes spécifiques lors de l’étape “Generate Specific Labels with Gemini” (génération d’étiquettes spécifiques avec Gemini), ce qui fournit des étiquettes qui tiennent compte du contexte (par exemple, « Schéma électrique : bloc d’alimentation »).
6. Génération des résultats : les schémas techniques extraits sont enregistrés sous forme d’images lors de l’étape “Schematic Images” (images des schémas techniques). Une option “Debugging with Bounding Boxes” (débogage avec boîtes englobantes) superpose les boîtes englobantes et les étiquettes aux images, pour vérification par l’utilisateur. Le résultat final, métadonnées comprises (par exemple, le numéro de page et l’étiquette), est enregistré dans un fichier JSON et peut être téléchargé sous forme de fichier ZIP depuis l’interface web.

Améliorations de l’extraction des schémas techniques

1. Précision de détection accrue grâce au regroupement des contours et au filtrage : la détection initiale des schémas techniques manquait ou fragmentait souvent les schémas dans les PDF complexes. Nous avons introduit une étape “Group Contours” (comme le montre le logigramme) qui regroupe les contours voisins en schémas techniques d’un seul tenant, en fonction de leur proximité et de leur taille. De plus, une étape “Filter Text-Heavy Areas” qui s’appuie sur l’OCR de Tesseract exclut les régions dominées par le texte, afin de concentrer l’analyse sur les zones qui s’apparentent à des schémas techniques (par exemple, des dessins techniques). La précision de la détection s’en est nettement améliorée, en particulier dans les PDF au contenu mixte.
2. Étiquetage amélioré grâce à l’intégration de Gemini : l’étiquetage souffrait auparavant de résultats d’OCR incohérents. En intégrant Gemini pour les étapes “Schematic Validation” et “Generate Specific Labels with Gemini”, nous avons amélioré la précision des étiquettes. Gemini valide les régions qui contiennent des schémas techniques et génère des étiquettes qui tiennent compte du contexte, en analysant le texte environnant et le contenu visuel. Par exemple, un schéma électrique pourrait désormais être étiqueté « Schéma électrique : bloc d’alimentation » plutôt que « Schéma », ce qui le rend plus exploitable par les applications en aval, comme le catalogage.
3. Prétraitement optimisé pour une extraction plus rapide : le pipeline de prétraitement d’origine était lent sur les PDF volumineux, à cause de conversions redondantes. Nous avons optimisé les étapes “Image Processing” et “Convert PDF into Images” en mettant en place un traitement parallèle pour les PDF de plusieurs pages et en réduisant la résolution des images intermédiaires sans perte de qualité. L’étape “Extract Schematics from Images” utilise désormais un seuillage adaptatif (via le paramètre --threshold), ce qui réduit le temps de traitement tout en préservant la précision.
4. Personnalisation par l’utilisateur et aide au débogage : pour résoudre les cas “No Schematics Extracted” (aucun schéma technique extrait), nous avons renforcé les possibilités de configuration avec des paramètres ajustables (--min-area, --padding, --threshold) accessibles en ligne de commande. Une option de sortie “Debugging with Bounding Boxes” a été ajoutée : elle génère des images de schémas techniques sur lesquelles sont superposées les boîtes englobantes et les étiquettes. Cette transparence aide les utilisateurs à déboguer et à ajuster efficacement les paramètres d’extraction.

Évolutions futures possibles

1. Traitement en temps réel pour l’interface web

   L’application web Streamlit traite les PDF par lots, ce qui est lent pour les fichiers volumineux. Mettre en place un traitement en temps réel, qui extrait et affiche les schémas techniques au fur et à mesure que chaque page est traitée, améliorerait l’expérience utilisateur. Cela pourrait passer par un traitement asynchrone et des entrées en flux continu (streaming), pour un retour plus rapide.

2. Étiquetage amélioré grâce à la compréhension du contexte et aux LLM/SLM locaux

   Si Gemini a amélioré l’étiquetage, il peut mal interpréter le contexte, en raison d’une compréhension limitée du document dans son ensemble et de sa dépendance à une API externe. De futurs travaux pourraient intégrer un modèle de traitement automatique du langage naturel (NLP) chargé d’analyser l’intégralité du texte du PDF, afin de fournir des indices de contexte (par exemple, identifier que le document relève du génie électrique) et d’améliorer la précision de l’étiquetage. Par ailleurs, intégrer des grands modèles de langage (LLM) ou des petits modèles de langage (SLM) locaux, comme LLaMA, Phi-4-multimodal ou DistilBERT, permettrait un traitement directement sur l’appareil, en réduisant la dépendance à des API externes comme Gemini. Cela renforcerait la confidentialité, réduirait la latence et permettrait un fonctionnement hors ligne. Par exemple, un SLM local pourrait être affiné sur la terminologie technique pour étiqueter un schéma technique « Implantation des transistors » avec une plus grande précision, même dans des environnements aux ressources limitées.

3. Prise en charge des schémas techniques 3D et des sorties interactives

   Les PDF modernes contiennent souvent des schémas techniques en 3D ou interactifs. Étendre l’outil pour qu’il les détecte et les extraie, voire les restitue sous forme de modèles 3D interactifs dans l’application web à l’aide de bibliothèques comme Three.js, lui apporterait de la valeur ajoutée. Cela suppose des algorithmes capables d’analyser les données 3D intégrées aux PDF et d’en assurer le rendu dynamique.

4. Compatibilité multiplateforme et déploiement dans le cloud

   L’installation manuelle des dépendances (par exemple, wkhtmltopdf, Tesseract) peut s’avérer difficile pour les utilisateurs. Conteneuriser l’application avec Docker simplifierait le déploiement multiplateforme. Par ailleurs, déployer l’outil sous forme de service cloud sur AWS ou Google Cloud permettrait aux utilisateurs de traiter des PDF sans installation locale, ce qui le rendrait plus accessible.

Conclusion

Le processus d’extraction des schémas techniques du PDF Schematic Extractor a été considérablement amélioré, grâce aux progrès réalisés sur la détection, l’étiquetage, le prétraitement et l’accompagnement des utilisateurs. Ces changements ont rendu l’outil plus précis, plus efficace et plus simple à utiliser. À l’avenir, l’intégration de l’apprentissage automatique (machine learning), du traitement en temps réel, de LLM/SLM locaux et du déploiement dans le cloud peut encore étendre les capacités de l’outil, pour en faire une solution polyvalente d’extraction de schémas techniques, adaptée à des cas d’usage variés.

Pour toute question ou remarque, n’hésitez pas à prendre contact : yagnesh.mangali@atronous.ai