Pipelines documentaires : de DOCX à PDF/A-3 vers une archive signée en un seul appel API
Un pipeline documentaire qui convertit les documents d’entrée en sortie d’archivage conforme semble un problème résolu. En pratique, il produit des échecs silencieux à chaque étape : des polices qui semblent correctes à l’écran mais échouent à la validation PDF/A, des couches de texte détruites lors de la conversion, des métadonnées présentes mais techniquement incorrectes, et des horodatages appliqués à des documents qui ne sont pas encore dans leur forme définitive.
Cet article décrit la chaîne de conversion complète, ce qui se passe mal à chaque étape, et à quoi ressemble un pipeline fiable.
La chaîne complète
Source document (DOCX / HTML / existing PDF)
↓ conversion
PDF (rendered with correct fonts and layout)
↓ PDF/A-3 conformance
PDF/A-3 (embedded fonts, color profiles, XMP metadata, no external references)
↓ structured attachment (for hybrid invoices)
PDF/A-3 with embedded XML (Factur-X, ZUGFeRD, XRechnung attachment)
↓ digital signature
Signed PDF/A-3 (PAdES signature, LTV information embedded)
↓ RFC 3161 timestamp
Timestamped PDF/A-3 (RFC 3161 token from qualified EU TSA)
↓ archive + audit trail
Final archive (WORM storage + hash-chained audit trail + evidence pack)Chaque flèche est une étape pouvant introduire une non-conformité. Chaque étape doit inclure une validation avant l’exécution de l’étape suivante.
Étape 1 : de la source au PDF
Le parcours de conversion le plus courant est DOCX vers PDF. Le risque ici est la substitution de polices : si une police utilisée dans le DOCX n’est pas disponible sur le serveur de conversion, le moteur de rendu lui substitue une police différente. La sortie est similaire à l’écran mais contient une police différente de celle spécifiée. Lorsque la validation PDF/A s’exécute ensuite, elle peut détecter la mauvaise police ou échouer parce que la police intégrée ne correspond pas à la police référencée dans le document.
La mesure d’atténuation : s’assurer que l’environnement de conversion dispose de toutes les polices requises installées, ou utiliser une approche de conversion qui intègre les polices au moment de la conversion. LibreOffice headless et Gotenberg (un wrapper Docker basé sur LibreOffice) sont des options open source fiables pour la conversion DOCX vers PDF. Gotenberg en particulier fournit un environnement isolé prévisible.
Ne convertissez pas DOCX en PDF en imprimant vers un pilote PDF. Les pilotes d’impression rastérisent souvent le texte, ce qui détruit la couche de texte et produit un document visuellement identique mais non lisible par machine ou consultable. Un PDF rastérisé ne peut pas être converti en PDF/A-3 valide sans ré-OCR, ce qui introduit des erreurs supplémentaires.
Pour HTML vers PDF, le rendu par navigateur sans interface graphique (utilisant des moteurs de rendu de navigateur) est généralement plus fiable pour la fidélité de mise en page que wkhtmltopdf. Les moteurs de navigateur modernes gèrent correctement le CSS. Vérifiez que la source HTML a toutes les polices soit intégrées soit spécifiées comme polices web-safe.
Étape 2 : de PDF à PDF/A-3
La conformité PDF/A-3 n’est pas automatiquement atteinte en produisant un PDF depuis une bibliothèque compatible PDF/A-3. Plusieurs problèmes peuvent survenir :
Métadonnées XMP manquantes ou incorrectes : PDF/A requiert un bloc XMP auto-descriptif identifiant le niveau de conformité. Les champs requis :
<rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
<pdfaid:part>3</pdfaid:part>
<pdfaid:conformance>B</pdfaid:conformance>
</rdf:Description>Sans ce bloc, un document n’est techniquement pas PDF/A-3 quelle que soit sa structure. De nombreux convertisseurs produisent un rendu qui ressemble à PDF/A mais omettent ou configurent mal le bloc XMP.
Polices non intégrées : même si la conversion a intégré les polices, certains convertisseurs laissent les polices Type1 ou TrueType partiellement intégrées (métriques seulement, pas les données de glyphes complètes). PDF/A requiert une intégration complète.
Espaces colorimétriques non pris en charge : les images dans le document doivent utiliser des espaces colorimétriques avec des profils ICC intégrés. Une image RVB sans profil ICC échoue à la validation PDF/A. Convertissez les images en sRGB avec un profil intégré avant de les inclure dans le document.
Transparence : PDF/A-1 interdit la transparence. PDF/A-2 et PDF/A-3 la permettent mais requièrent un traitement spécifique. De nombreux documents sources utilisent des ombres douces ou des superpositions translucides qui doivent être aplaties avant la sortie PDF/A-1.
Chiffrement : PDF/A interdit le chiffrement. Un PDF avec un mot de passe utilisateur ou propriétaire n’est pas conforme PDF/A quelle que soit ses autres propriétés.
Exécutez VeraPDF après cette étape pour confirmer la conformité avant de continuer. VeraPDF est le validateur de référence, utilisé par les archives nationales et les régulateurs à travers l’Europe. Il est open source et peut être exécuté dans un pipeline sans interface graphique.
Étape 3 : intégration du XML structuré (documents hybrides)
Pour les factures (Factur-X, ZUGFeRD, XRechnung), le PDF/A-3 doit contenir le XML de facture comme pièce jointe avec des métadonnées spécifiques.
La relation de pièce jointe doit être Alternative pour Factur-X, pas Data ou Unspecified. Ceci est défini dans la spécification Factur-X et constitue l’un des échecs de conformité les plus courants dans les générateurs de factures PDF/A-3.
Le schéma d’extension XMP requis pour la pièce jointe Factur-X :
<fx:ConformanceLevel>EN 16931</fx:ConformanceLevel>
<fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
<fx:DocumentType>INVOICE</fx:DocumentType>
<fx:Version>1.0</fx:Version>Le nom de fichier doit être exactement factur-x.xml pour Factur-X, et les métadonnées XMP doivent référencer ce nom de fichier. Les validateurs qui vérifient la conformité Factur-X (pas seulement PDF/A-3) rejetteront les documents où le nom de fichier ou la référence XMP est incorrect.
Étape 4 : signature numérique
Appliquez une signature PAdES (PDF Advanced Electronic Signatures), et non une signature PDF basique. PAdES est défini dans l’ETSI EN 319 132 et prend en charge l’intégration LTV.
Au moment de la signature, intégrez la chaîne complète de certificats et la réponse OCSP ou l’instantané LCR qui prouve que le certificat de signature était valide au moment de la signature. Il s’agit des informations LTV évoquées dans la validation PDF à long terme. Sans cela, la signature peut devenir invérifiable à l’expiration du certificat de signature.
N’horodatez pas avant de signer. L’ordre correct est : signez d’abord, puis horodatez la signature. Horodater le document avant de signer modifie le hachage du document, ce qui invalide la signature.
Étape 5 : horodatage RFC 3161
Demandez l’horodatage immédiatement après la signature, pendant que le certificat de signature est encore vérifiable en ligne. L’horodatage est appliqué au hachage du document signé et couvre à la fois le contenu du document et la signature.
Stockez le jeton d’horodatage à l’intérieur du PDF (dans le dictionnaire DSS du document) et également dans le Pack de Preuves Légales comme fichier autonome pour une vérification indépendante.
Étape 6 : archive et piste d’audit
Écrivez le document final dans un stockage WORM avec la période de conservation verrouillée. Ajoutez l’événement d’archivage à la piste d’audit à chaîne de hachage.
L’entrée de la piste d’audit pour l’étape d’archivage doit inclure : le hachage du document, l’emplacement de stockage, la période de conservation, l’horodatage de l’événement d’archivage et le hachage de l’entrée d’audit précédente. Cela produit un enregistrement inviolable attestant que le document a été archivé sous cette forme exacte à ce moment précis.
Validation à chaque étape
Le mode de défaillance à éviter est la non-conformité silencieuse : un document qui passe toutes les six étapes et produit un fichier qui semble correct mais échoue à la validation lorsqu’il est présenté à un auditeur.
Validez aux étapes 2, 3 et 5 :
- Après la conversion PDF/A-3 : VeraPDF pour la conformité PDF/A-3
- Après l’intégration XML (le cas échéant) : validateur de profil Factur-X ou ZUGFeRD
- Après l’horodatage : vérificateur PAdES (DSS ou équivalent) pour la validité de la signature et de l’horodatage
Si la validation échoue à une étape, arrêtez le pipeline et renvoyez une erreur structurée. Ne procédez pas à l’archivage avec un document non conforme.
SealDoc comme pipeline documentaire
L’API SealDoc implémente la chaîne complète décrite ci-dessus comme un seul point de terminaison. Vous soumettez le document source (DOCX, HTML ou PDF existant) avec les métadonnées structurées (données de facture, informations sur les parties, catégorie de conservation). L’API exécute la conversion, la validation PDF/A-3, l’intégration XML, la signature, l’horodatage et l’archivage, renvoyant le pack de preuves en cas de succès ou une erreur de validation structurée en cas d’échec.
Chaque étape du pipeline est implémentée pour échouer rapidement : si VeraPDF retourne une erreur de conformité, le pipeline s’arrête et retourne la clause spécifique qui a été violée plutôt que de passer à l’étape suivante avec un document non conforme. Le pack de preuves n’est généré que lorsque toutes les étapes de validation ont réussi.
Pour les organisations qui ont besoin d’intégrer l’archivage documentaire dans des flux de travail existants, l’API accepte des webhooks qui notifient en cas de succès ou d’échec, et le pack de preuves est récupérable sous forme de ZIP contenant tous les composants dans des formats ouverts et vérifiables de manière indépendante.