Ouvrez n’importe quel PDF critique pour votre activité — une facture, une étiquette d’expédition, un relevé mensuel — et consultez les propriétés du document (Cmd+D dans Aperçu sur macOS, Ctrl+D dans Adobe Reader, « Fichier → Propriétés » dans la plupart des visionneuses bureau). Regardez ensuite le champ Producer.

Si le PDF a été généré par une plateforme SaaS via un navigateur headless, vous y verrez souvent quelque chose comme :

$ pdfinfo invoice.pdf
Title:           invoice-20260318.pdf
Subject:
Author:
Creator:         Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (...) Chrome/120.0.0.0
Producer:        Skia/PDF m120
Language:

La page ci-dessus est aux couleurs de l’éditeur SaaS. Les propriétés du fichier, elles, nomment un moteur de navigateur qui n’a rien à voir avec cet éditeur — ni avec le client pour le compte duquel le SaaS livre le document.

C’est précisément cet écart que ce billet traite.

La page est brandée, le fichier ne l’est pas

La génération de PDF en marque blanche est une exigence bien comprise pour les SaaS B2B. L’éditeur laisse le client téléverser un logo, choisir des couleurs de marque, configurer un modèle ; les PDF exportés ressemblent visuellement à la marque du client, pas à celle de l’éditeur.

La plupart des plateformes s’arrêtent là. Elles règlent la couche visible et laissent la couche des propriétés du fichier intacte. Résultat : un document qui affiche « Acme Logistics » sur chaque page mais s’identifie comme « Skia/PDF m120 » dès que quiconque fait clic droit → Propriétés.

Pour un téléchargement B2C ponctuel — un reçu personnel, un billet de cinéma — les propriétés du fichier sont essentiellement cosmétiques. Pour un document B2B, ou pour toute sortie B2C régulée (comptes rendus médicaux, états financiers, informations légales, formulaires d’assurance réglementés), les propriétés du fichier relèvent du document. Elles apparaissent dans :

Adobe Reader, Preview, Foxit, toutes les visionneuses PDF bureau
Les systèmes de gestion documentaire (SharePoint, M-Files, NetSuite Files)
Les aperçus PDF des serveurs de messagerie
Les index de recherche (Spotlight, Outlook, recherche DMS interne)
Les systèmes d’archivage (PDF/A pour la conservation à long terme)
Tout ce qui invoque pdfinfo ou pdftk dump_data dans un pipeline

Un document dont la page dit « Acme » et dont le champ Producer dit « Chromium » se lit pour ces systèmes comme « rendu par Chromium pour quelqu’un qui s’appelle Acme » — et non « rendu par Acme ». Pour les achats et la conformité en entreprise, cette distinction n’échappe pas.

Pourquoi c’est pire pour l’éditeur SaaS que pour un utilisateur direct

Si vous générez un PDF pour vous-même, « Chromium » dans le champ Producer ne regarde que vous.

Si vous êtes éditeur SaaS et que vos clients génèrent des PDF via votre plateforme, la chaîne est plus longue :

Vous avez choisi la pile de rendu.
Votre client livre le PDF résultant à son client.
Le destinataire final — une équipe achats, un transporteur, un service fiscal, une direction financière — voit un champ Producer qui ne nomme ni vous ni votre client. Il nomme le moteur de rendu en amont que vous utilisez.

La marque de votre client sur la page ; un nom d’outil inconnu dans le fichier. Du point de vue du destinataire, le document paraît légèrement décalé sans qu’il puisse le nommer. Du point de vue de votre client, la promesse de marque blanche n’a pas été pleinement tenue.

C’est la partie dans laquelle la plupart des plateformes sous-investissent, parce que la correction n’est pas visible depuis la page d’accueil. Mais le client qui passe un seul pdfinfo sur la sortie de votre fonctionnalité « PDF en marque blanche » va le remarquer.

Quand cela devient vraiment gênant

Voici les situations dans lesquelles le champ Producer s’est révélé être un vrai problème opérationnel, pas une hypothèse :

Questionnaires de sécurité fournisseur. Les achats d’entreprise mènent une revue de risque fournisseur et demandent : « listez tous les outils tiers qui apparaissent dans les documents que vous nous livrez. » L’équipe IT du client passe pdfinfo sur un document échantillon et trouve un nom de moteur de rendu inconnu. Personne ne s’en offusque — mais cela s’ajoute à la liste des sous-traitants, ce qui déclenche une revue de la gestion fournisseur et une série de contrôles distincts.
Recherche DMS / archive. Le système de gestion documentaire du client indexe les PDF par author. Quand les PDF de votre plateforme ont un champ Author vide, l’équipe conformité du client ne peut pas facilement filtrer « les documents de ce fournisseur » plusieurs mois plus tard — ils finissent par ajouter des tags manuels, ce qu’ils ne devraient pas avoir à faire.
Validation des archives à long terme. Un système d’archivage PDF/A signale les documents dont le Producer ne correspond pas à la liste de fournisseurs attendue. L’équipe conformité doit autoriser manuellement « Skia/PDF m120 » et « wkhtmltopdf » comme moteurs de rendu connus — un petit fardeau opérationnel, mais récurrent.
Audits de cohérence de marque. Certaines équipes marketing d’entreprise auditent l’attribution des documents sortants dans le cadre de la gouvernance de marque. Un document attribué à un outil dont l’équipe marque n’a jamais entendu parler devient un point de vigilance.

Aucun de ces incidents n’est critique. Ce sont des frictions qui s’ajoutent à la vente entreprise, à l’intégration fournisseur et aux opérations. Elles s’accumulent sur des milliers de documents par mois.

Ce que les propriétés du fichier exposent réellement

La spécification PDF réserve six champs de métadonnées standard que pratiquement toutes les visionneuses affichent :

Champ	Rôle	Ce qu’une pile défaillante affiche typiquement
`Title`	Titre du document	Nom de fichier auto-généré, ou vide
`Author`	La personne ou l’organisation qui a créé le document	Vide, ou le nom du développeur
`Subject`	Brève description du document	Vide
`Creator`	L’application ayant produit le contenu source	« Chromium », « Mozilla/5.0… », ou le nom d’outil interne de l’éditeur SaaS
`Producer`	L’application ayant produit les octets du PDF	« Skia/PDF m120 », « wkhtmltopdf 0.12.x », « iText 7.x.x »
`Language`	Étiquette de langue BCP-47	Vide, ou locale erronée

Chacun de ces champs est une courte chaîne. Aucun n’est techniquement difficile à renseigner. Si ces champs fuitent par défaut, c’est parce que la bibliothèque de rendu écrit son propre nom dans Producer (correctement — c’est précisément à cela que sert ce champ), et que la plupart des codes applicatifs ne définissent jamais les cinq autres.

La solution est de les définir — délibérément, à chaque rendu, depuis l’application qui sait à quoi sert le document.

À quoi ressemblent des « métadonnées brandées » en pratique

Voici le même bloc de métadonnées tel que gPdf le produit. Six champs, tous remplaçables par l’appelant :

{
  "settings": {
    "metadata": {
      "title":    "Invoice INV-2026-3401",
      "language": "en",
      "author":   "Acme Logistics, Inc.",
      "subject":  "Monthly invoice — 2026-03",
      "creator":  "Acme Billing Platform v7.2",
      "producer": "Acme Billing Platform"
    }
  }
}

Le même pdfinfo sur le PDF obtenu :

$ pdfinfo invoice.pdf
Title:           Invoice INV-2026-3401
Subject:         Monthly invoice — 2026-03
Author:          Acme Logistics, Inc.
Creator:         Acme Billing Platform v7.2
Producer:        Acme Billing Platform
Language:        en

La page s’affiche aux couleurs d’« Acme Logistics » — et les propriétés du fichier disent aussi « Acme Logistics ». Clic droit → Propriétés montre un document qui appartient pleinement à Acme. Le fait que les octets aient été produits par gPdf en périphérie en environ 4 ms n’apparaît nulle part où le destinataire regarde.

Vos clients ne voudront-ils pas savoir que vous utilisez gPdf ?

Cette question revient assez souvent pour mériter une réponse directe.

Oui — vos clients peuvent tout à fait savoir que vous vous appuyez sur gPdf. C’est entre vous et eux, et cela trouve généralement sa place dans votre blog d’ingénierie, votre changelog, vos documents d’architecture sécurité ou votre liste de sous-traitants (sur laquelle gPdf apparaît si cela concerne votre DPA).

Le champ Producer ne relève pas de cette relation. Il concerne le destinataire final du document de votre client — un agent achats, un répartiteur de transporteur, un agent de centre des impôts — qui n’a aucune relation avec votre choix de moteur de rendu et aucune raison de s’y intéresser. Pour cette personne, « Skia/PDF m120 » dans la fenêtre Propriétés est du bruit ; « Acme Billing Platform » est un signal.

Il n’y a rien de malhonnête là-dedans. La spécification PDF définit Producer comme « le nom de l’application qui a produit le PDF d’origine ». Si vous bâtissez un service PDF sur gPdf, votre application a produit les octets que gPdf a livrés. L’écrire dans Producer est exact. La répartition honnête est :

gPdf est l’infrastructure de rendu.
Votre plateforme est le producteur.
Votre client est l’auteur.

Chaque couche reçoit le crédit que la spécification PDF lui destine.

Une note de bas de page sur les chaînes en aval

Si votre PDF de sortie passe par une étape de post-traitement avant d’atteindre le destinataire — Ghostscript sans indicateurs explicites de préservation des métadonnées, un outil de DRM/filigrane d’entreprise, un « optimiseur PDF » — certains de ces outils réécriront discrètement Producer avec leur propre nom et annuleront les métadonnées de marque que vous venez de définir. Testez sur votre chaîne réelle, pas seulement sur la réponse brute de gPdf.

Une note sur ce qui n’est pas dans cet article

Pour rester précis : les six champs standard ci-dessus sont ce que gPdf expose aujourd’hui. C’est suffisant pour mettre en marque blanche les propriétés du document — ce qui est l’objet du discours sur l’identité de marque.

Ce n’est pas suffisant pour planquer un contexte métier arbitraire (UUID de commande, code d’entrepôt, version de modèle) à l’intérieur du PDF afin que les systèmes en aval le lisent. C’est une capacité distincte et complémentaire — métadonnées XMP personnalisées + paires clé-valeur arbitraires — que la spécification PDF prend en charge et que nous suivons comme élément de feuille de route. Si vous en avez besoin aujourd’hui, les données de type identifiant vivent généralement de façon plus fiable dans la base de données de votre propre plateforme, indexées sur le nom de fichier ou un hash du PDF, plutôt que dans le PDF lui-même. Les métadonnées servent à l’identité du document, pas à transporter des données métier structurées à travers des PDF comme s’ils étaient une couche de transport.

Métadonnées de marque (aujourd’hui) ≠ flux de données métier caché (séparé). Il vaut la peine de les garder distincts dans votre propre planification.

La plus petite amélioration possible

Si vous appelez déjà /api/v1/pdf/render en POST et que votre appel actuel ne contient pas de settings.metadata, la plus petite amélioration tient en trois lignes ajoutées au JSON que vous envoyez déjà :

 {
   "pages": [...],
   "settings": {
+    "metadata": {
+      "author":   "Your customer's organisation",
+      "producer": "Your platform"
+    }
   }
 }

Deux champs, une nouvelle clé. Vérifiable avec pdfinfo en quelques secondes. Une fois cela en place, complétez title, language, subject et creator quand vous aurez le temps.

Où cela se traduit dans l’API gPdf

Six lignes dans settings.metadata. Des politiques par jeton peuvent également supprimer ou remplir par défaut ces champs, afin qu’un SaaS multi-tenant impose que chaque PDF généré par ses clients soit correctement attribué sans avoir à faire confiance à chaque appelant d’API pour les définir.

§4.14.2 Métadonnées dans la référence d’API — la référence champ par champ.
Plongée champ par champ — quand chacun de title / language / author / subject / creator / producer compte, ce que les lecteurs en font réellement, et comment vérifier ce que vous avez livré.

La page visible est la moitié de la marque. Les propriétés du fichier sont l’autre moitié. Si votre plateforme livre des PDF au nom de ses clients, les deux moitiés devraient porter leur nom.