Conversion de fichiers pour les graphes de connaissances : transformer les documents en données structurées

Les graphes de connaissances sont passés de curiosités académiques à composants essentiels des moteurs de recherche, des systèmes de recommandation et des plateformes de données d’entreprise. Leur puissance réside dans la représentation d’entités, de relations et d’attributs dans un format lisible par machine et lié — généralement RDF (Resource Description Framework) ou JSON‑LD. Pourtant, la plupart des informations qui alimentent un graphe de connaissances vivent dans des fichiers non structurés ou semi‑structurés : PDF d’articles de recherche, contrats Word, inventaires Excel et archives héritées. Convenir ces fichiers en triplets structurés sans perdre le sens, la provenance ou la conformité légale est un problème d’ingénierie non trivial.

Cet article décrit un flux de travail complet, prêt pour la production, afin de transformer les documents de bureau quotidiens en données exploitables par un graphe de connaissances. Nous abordons le pourquoi, la préparation, les techniques de conversion réelles, la validation, les sauvegardes de confidentialité et, enfin, l’ingestion du résultat dans un magasin de graphes. Les recommandations sont volontairement indépendantes de toute plateforme, mais nous citons convertise.app comme outil pratique, axé sur la confidentialité, pour l’étape initiale de format‑à‑format lorsqu’elle est nécessaire.

Pourquoi la conversion de fichiers compte pour la construction d’un graphe de connaissances

Un graphe de connaissances n’est bon que si les données qu’il ingère le sont. Quand la matière première est un PDF désordonné, une image numérisée ou une feuille de calcul truffée de cellules fusionnées, le processus d’extraction en aval échoue ou produit des triplets bruyants qui dégradent la précision des requêtes. Une conversion de fichiers appropriée sert deux objectifs critiques :

  1. Normalisation de l’entrée — Convertir les PDF en formats recherchables et riches en texte (par ex. PDF‑A → texte brut ou HTML) élimine les goulets d’étranglement OCR. De même, transformer les anciens fichiers binaires Office (.doc, .xls) en leurs variantes Open‑XML (.docx, .xlsx) garantit que les analyseurs peuvent localiser de façon fiable les titres, les tableaux et les métadonnées.
  2. Préservation des métadonnées contextuelles — Les outils de conversion qui conservent l’auteur, la date de création, la version et même des propriétés personnalisées permettent au RDF résultant de porter automatiquement les informations de provenance. Dans un graphe de connaissances, la provenance est un citoyen de première classe ; elle permet l’évaluation de confiance, les pistes d’audit et le respect de réglementations comme le RGPD.

Lorsque la conversion est effectuée avec précision, l’étape sémantique d’extraction en aval peut se concentrer sur ce que les données disent plutôt que sur comment les lire.

Comprendre les cibles sémantiques : RDF, JSON‑LD et CSV

Avant de lancer une campagne de conversion, définissez le format de sérialisation cible. Chacun a ses forces :

  • RDF/Turtle — Idéal pour les vocabulaires complexes, les ontologies personnalisées, et lorsqu’il faut des triplets sujet‑prédicat‑objet explicites. C’est la lingua franca des requêtes SPARQL.
  • JSON‑LD — Une représentation compatible JSON qui intègre le contexte linked‑data directement. Elle est conviviale pour les développeurs, fonctionne bien avec les API web et est de plus en plus prise en charge par les moteurs de recherche pour les extraits enrichis.
  • CSV — Lorsque le graphe de connaissances sera construit à partir de données tabulaires (p. ex. catalogues de produits), un CSV bien structuré peut être directement mappé en RDF à l’aide d’outils comme OpenRefine ou la spécification W3C CSV on the Web.

Le choix dicte le chemin de conversion. Par exemple, un PDF contenant un tableau de composés chimiques sera peut‑être mieux rendu d’abord en CSV, puis mappé en RDF. Un contrat Word qui mentionne parties, dates et obligations profite d’une sortie directe RDF ou JSON‑LD, préservant les clauses imbriquées comme entités séparées.

Préparer les fichiers sources pour l’extraction sémantique

Les fichiers bruts cachent souvent des obstacles qui se manifestent sous forme d’erreurs d’extraction. Une phase de préparation disciplinée rapporte des dividendes.

  1. Détecter l’encodage tôt — Les fichiers texte peuvent être UTF‑8, UTF‑16 ou Windows‑1252 hérité. Utilisez un outil (p. ex. chardet en Python) pour identifier l’encodage et le ré‑encoder en UTF‑8 avant toute conversion. Cela empêche les caractères corrompus dans les littéraux RDF.
  2. Normaliser les fins de ligne — Les mélanges de CR, LF et CRLF cassent les analyseurs qui s’appuient sur le traitement ligne‑par‑ligne, surtout lors de la génération de CSV. Convertissez tout en LF (\n) avec dos2unix ou un utilitaire similaire.
  3. Séparer les médias embarqués — Les PDF intègrent souvent des images contenant des données critiques (graphes, signatures). Extrayez d’abord ces images (avec pdfimages ou un service cloud) et traitez‑les comme actifs séparés pouvant être liés via foaf:Image ou schema:ImageObject dans le graphe.
  4. Aplatir les mises en page complexes — Les tableaux qui s’étendent sur plusieurs pages, les cellules fusionnées ou les listes imbriquées doivent être aplatis. Des outils comme Tabula pour les PDF ou pandoc pour Word peuvent exporter les tables en CSV tout en conservant les en‑têtes de colonnes.
  5. Valider les licences et les autorisations — Assurez‑vous d’avoir le droit de réutiliser le contenu. Lorsqu’il s’agit de documents tiers, stockez l’URL de la licence originale dans un triplet dcterms:license attaché à l’entité source.

Une fois ces étapes de pré‑flight terminées, le fichier est prêt pour une conversion déterministe.

Conversion des documents en formats structurés

Ci‑dessous, nous présentons des pipelines concrets de conversion pour les trois familles de sources les plus courantes.

1. PDF → Texte/HTML → RDF ou JSON‑LD

  • Étape 1 – Extraction du texte : utilisez un convertisseur PDF‑to‑HTML qui préserve la hiérarchie visuelle (titres, listes, tableaux). L’outil open‑source pdf2htmlEX le fait tout en conservant les classes CSS qui correspondent à la structure logique.
  • Étape 2 – Annotation sémantique : appliquez un moteur à règles (p. ex. Apache Tika combiné à des expressions régulières personnalisées) pour baliser les titres comme sections schema:Article, les tableaux comme schema:Table, et les citations en ligne comme références schema:CreativeWork.
  • Étape 3 – Génération RDF : alimentez le HTML annoté dans un moteur de transformation tel que XSLT ou un script Python qui parcourt le DOM, crée des URI pour chaque section (_:section1) et émet des triplets. Un triplet typique pour une ligne de tableau pourrait être :
:compound123 a chem:Compound ;
    chem:hasName "Acetaminophen" ;
    chem:hasMolecularWeight "151.16"^^xsd:float ;
    dcterms:source <file:///documents/report.pdf#page12> .
  • Étape 4 – Emballage JSON‑LD : si le consommateur en aval préfère JSON‑LD, sérialisez le même graphe RDF en utilisant un contexte compact qui mappe les préfixes chem: vers une ontologie partagée publiquement.

2. Word (.docx) → XML structuré → RDF/JSON‑LD

  • Étape 1 – Extraction OOXML : un fichier .docx est une archive ZIP contenant document.xml. Dézippez et parsez le XML avec une bibliothèque XML. La hiérarchie de styles native de Word (Heading1, Heading2) se mappe proprement aux sections d’un graphe de connaissances.
  • Étape 2 – Normalisation des tables : extrayez les éléments <w:tbl>, convertissez‑les en lignes CSV, puis alimentez le CSV dans un script de mapping qui crée des entités schema:Product ou schema:Event en fonction des en‑têtes.
  • Étape 3 – Conservation des propriétés personnalisées : les documents Word stockent souvent des métadonnées personnalisées dans docProps/custom.xml. Capturez chaque élément <property> et ajoutez un dcterms:description ou un prédicat métier correspondant.
  • Étape 4 – Émission RDF : utilisez un système de templates comme Jinja2 pour transformer l’arbre XML en Turtle. Chaque paragraphe devient un schema:Paragraph avec un littéral schema:text ; les titres gagnent schema:headline.

3. Feuille de calcul (XLSX/CSV) → CSV → RDF via fichiers de mapping

  • Étape 1 – Export CSV unifié : pour les XLSX, servez‑vous de xlsx2csv ou de la bibliothèque pandas pour aplatir chaque feuille en CSV séparé, en veillant à ce que les types de cellules (date, nombre) soient convertis en chaînes ISO‑8601 ou en types xsd.
  • Étape 2 – Spécification du mapping — Rédigez un fichier de mapping (YAML ou RML) qui indique comment chaque colonne se mappe aux prédicats RDF. Par exemple :
mapping:
  - source: product_id
    predicate: schema:productID
  - source: price_usd
    predicate: schema:price
    datatype: xsd:decimal
  - source: release_date
    predicate: schema:datePublished
    datatype: xsd:date
  • Étape 3 – Moteur de transformation — Exécutez le mapping avec un processeur RML (p. ex. rmlmapper-java). Le résultat est un flux de triplets Turtle prêt à être ingéré.

Préserver le contexte, l’alignement ontologique et les URI

Une conversion qui produit un RDF syntaxiquement correct mais sémantiquement ambigu est de peu d’utilité. Suivez ces pratiques pour garder le sens intact :

  • URI stables — Dérivez les identifiants à partir d’attributs immuables de la source (DOI, ISBN, ou combinaison de hachage du document + numéro de section). Évitez les noms de fichiers volatils qui pourraient changer lors d’une synchronisation ultérieure.
  • Réutilisation d’ontologies — Avant d’inventer de nouveaux prédicats, cherchez dans les vocabulaires existants (Schema.org, FOAF, DC ou des ontologies spécialisées comme bio:Gene). Réutiliser des termes établis améliore l’interopérabilité et réduit l’effort de mapping en aval.
  • Lien retour à la source — Attachez toujours un triplet dcterms:source pointant vers le fichier original ou la page/section spécifique. Ce lien est inestimable pour les auditeurs et les utilisateurs qui souhaitent vérifier la provenance d’une affirmation.
  • Annotation de version — Lorsque le document source est sous contrôle de version, incluez un triplet schema:version qui référence le hash du commit Git ou le numéro de révision du document.

Gestion de grands corpus : stratégies de conversion par lots

Dans les environnements d’entreprise, il peut être nécessaire de traiter des milliers de PDF et de feuilles de calcul chaque nuit. Faire évoluer le pipeline de conversion requiert une orchestration soigneuse :

  1. Chunking — Divisez la charge de travail en lots de 500 à 1 000 fichiers. Utilisez une file de messages (RabbitMQ, AWS SQS) pour dispatcher les jobs de conversion aux nœuds travailleurs.
  2. Travailleurs sans état — Chaque travailleur doit récupérer un fichier du stockage (p. ex. S3), exécuter la conversion avec une chaîne d’outils conteneurisée (pandoc, pdf2htmlEX, scripts personnalisés) et pousser le RDF résultant vers un endpoint de magasin de triplets.
  3. Idempotence — Concevez le job de façon à ce que le re‑exécution sur le même fichier produise un RDF identique. Stockez le hachage du fichier source et du graphe généré ; si le hachage correspond à une exécution antérieure, ignorez la ré‑ingestion.
  4. Surveillance et nouvelles tentatives — Suivez les taux de réussite avec des métriques Prometheus. Les jobs échoués doivent être retentés avec un back‑off exponentiel, et les échecs persistants consignés pour révision manuelle.
  5. Utilisation de convertise.app — Pour des conversions ponctuelles, surtout pour des formats non pris en charge nativement par votre chaîne (p. ex. conversion de fichiers CorelDRAW anciens en SVG), convertise.app fournit un pont rapide, centré sur la confidentialité, sans code personnalisé.

Assurance qualité : validation, SHACL et tests automatisés

Après la conversion, validez à la fois la conformité syntaxique et sémantique :

  • Vérification syntaxique — Faites passer le RDF dans un parseur (p. ex. rapper de la bibliothèque Redland) pour détecter les Turtle ou JSON‑LD malformés.
  • Contraintes de forme (SHACL) — Définissez des formes SHACL qui capturent la structure attendue de votre graphe. Pour un catalogue produit, une forme peut exiger que schema:price soit un décimal, que schema:productID soit une chaîne non vide, et que schema:availability appartienne à un vocabulaire contrôlé.
  • Tests de conformité SPARQL — Écrivez des requêtes SPARQL ASK qui vérifient l’existence de triplets critiques (p. ex. chaque schema:Person doit posséder un schema:name). Automatisez ces requêtes dans votre pipeline CI.
  • Tests de boucle ronde — Convertissez le RDF en format lisible (p. ex. CSV) et comparez‑le avec la source d’origine à l’aide d’outils diff. Les petites différences révèlent souvent des espaces perdus ou des arrondis de champs numériques.

Confidentialité, licences et considérations éthiques

Lorsque vous convertissez des fichiers contenant des données personnelles, vous devez respecter le RGPD, le CCPA ou d’autres législations locales.

  • Minimisation des données — Extrayez uniquement les champs requis pour le graphe de connaissances. Si un PDF contient une adresse complète mais que le graphe n’a besoin que de la ville et du pays, éliminez les données de niveau rue avant de générer les triplets.
  • Pseudonymisation — Remplacez les identifiants directs (courriel, téléphone) par des versions hachées avec un sel stocké séparément. Conservez un fichier de correspondance dans un coffre sécurisé à des fins d’audit.
  • Propagation de licence — Incluez un triplet dcterms:license qui référence l’URL de la licence du document original. Si la source est sous licence Creative Commons, transmettez cette information à chaque entité dérivée.
  • Politiques de rétention — Décidez combien de temps le RDF converti doit être conservé. Mettez en place une expiration automatisée selon l’âge du document source, surtout pour les contrats sensibles.

Ingestion des données converties dans un magasin de graphe de connaissances

Une fois que vous disposez d’un RDF propre, l’étape finale consiste à le charger dans une base de données graphe. Le processus diffère légèrement entre les magasins de triplets natifs (Blazegraph, GraphDB) et les systèmes de graphes de propriétés (Neo4j avec le plugin RDF).

  1. Chargement en masse — La plupart des magasins acceptent une opération INSERT DATA en bloc ou un chargeur massif qui lit directement les fichiers Turtle/NT. Partitionnez les données en graphes nommés logiques (par ex. graph:finance, graph:research) pour permettre un contrôle d’accès fin.
  2. Ingestion en flux — Pour les pipelines continus, utilisez un UPDATE SPARQL 1.1 avec des instructions INSERT dès qu’un lot est terminé. Des connecteurs Kafka existent pour de nombreux magasins, vous permettant de diffuser les triplets en temps réel.
  3. Indexation — Activez des index plein‑texte sur les littéraux que vous prévoyez de rechercher (titres, abstracts). Certains magasins offrent aussi des index géographiques pour les prédicats schema:geo, utile lorsqu’un fichier source contient des adresses.
  4. Validation des requêtes — Après le chargement, exécutez une suite de requêtes de référence reflétant les cas d’usage en production (p. ex. « Trouver tous les contrats signés après 2020 où la contre‑partie est une société cotée »). Vérifiez les temps de réponse et l’exhaustivité des résultats.

Étude de cas concrète : transformer un rapport annuel en graphe de connaissances

Scénario : un analyste financier souhaite interroger chaque occurrence de « net profit » dans les dix derniers rapports annuels d’une société, publiés sous forme de PDF.

  1. Collecte des PDF — Stockez les PDF dans un bucket S3, indexés par année.
  2. Pré‑flight — Exécutez pdfinfo pour confirmer que chaque fichier est PDF/A‑1b (archivage). Utilisez pdf2htmlEX pour convertir chaque PDF en HTML, en préservant les titres.
  3. Extraction des tableaux — Identifiez les tables contenant le mot « Profit » grâce à la classe HTML table. Exportez chaque tableau en CSV via tabula-java.
  4. Mapping vers RDF — Rédigez un mapping RML qui crée une entité schema:FinancialStatement par année, et pour chaque ligne, génère les triplets schema:Revenue, schema:NetProfit et schema:OperatingExpense, en castant les valeurs numériques en xsd:decimal.
  5. Ajout de provenance — Attachez prov:wasGeneratedBy liant à une prov:Activity qui enregistre la version du script de conversion et l’URI S3 du PDF source.
  6. Validation — Exécutez une forme SHACL qui impose la présence de schema:NetProfit pour chaque schema:FinancialStatement. Toute valeur manquante déclenche un journal pour révision manuelle.
  7. Ingestion — Chargez le Turtle dans GraphDB sous le graphe nommé graph:annual_reports. Créez un index plein‑texte sur les littéraux schema:financialMetric.
  8. Requête — Lancez la requête SPARQL suivante :
SELECT ?year ?netProfit WHERE {
  GRAPH <graph:annual_reports> {
    ?stmt a schema:FinancialStatement ;
          schema:year ?year ;
          schema:NetProfit ?netProfit .
  }
}
ORDER BY ?year

L’analyste obtient ainsi une liste propre et triable des chiffres de bénéfice net sans ouvrir manuellement chaque PDF.

Checklist des meilleures pratiques pour la conversion fichier → graphe

  • Identifier la sérialisation cible (RDF/Turtle, JSON‑LD, CSV) avant toute conversion.
  • Normaliser l’encodage et les fins de ligne pour éviter la corruption de caractères.
  • Extraire séparément les médias embarqués et les lier avec les bons prédicats.
  • Utiliser des formats ouverts pour les étapes intermédiaires (HTML, CSV) afin de garder le pipeline transparent.
  • Conserver les métadonnées originales (auteur, date de création, licence) comme triplets de provenance.
  • Générer des URI stables et respectueux des namespaces basés sur des identifiants immuables.
  • Réutiliser des ontologies établies avant d’inventer de nouveaux prédicats.
  • Valider avec SHACL et des requêtes SPARQL ASK dans une suite de tests automatisée.
  • Appliquer la minimisation des données et la pseudonymisation pour les données personnelles.
  • Documenter la licence sur chaque entité générée.
  • Employer des travailleurs par lots avec des jobs idempotents pour les gros corpus.
  • Surveiller les taux de succès de conversion et conserver les journaux d’audit.
  • Exploiter convertise.app pour les conversions de formats niche qui manquent d’outils natifs.

Conclusion

Convertir les fichiers de bureau quotidiens en données prêtes pour un graphe de connaissances est un processus discipliné qui combine la gestion classique des formats de fichier avec les meilleures pratiques du Web sémantique. En traitant la conversion comme la première porte d’entrée d’une chaîne de qualité des données — normalisation des encodages, extraction des repères structurels, préservation de la provenance et validation via SHACL— vous transformez des PDF et des feuilles de calcul bruyants en un graphe propre et interrogeable.

L’effort rapporte : les analyses en aval deviennent plus rapides, les auditeurs gagnent en transparence de provenance, et les entreprises peuvent réutiliser les mêmes données structurées dans la recherche, la recommandation et les modèles d’IA. Alors que le volume de documentation non structurée continue de croître, maîtriser la conversion de fichiers pour les graphes de connaissances deviendra une compétence essentielle pour les ingénieurs data, les archivistes et quiconque veut libérer la valeur latente cachée dans les PDF, Word et Excel.