DocRaptor est un produit compétent. Il enveloppe Prince — le moteur HTML-vers-PDF de référence — dans une API REST hébergée, avec retries, jobs asynchrones et une bonne documentation. Il existe depuis plus de dix ans, et pour beaucoup d’équipes c’est le choix évident « je ne veux pas faire tourner Prince moi-même ».

Nous sommes un outil d’une autre forme. gPdf n’accepte pas du tout le HTML ; il prend du JSON structuré et rend en PDF directement à la périphérie Cloudflare. L’écart de prix affiché à 100K pages/mois : 5 $/mois (gPdf Basic) vs 89 $/mois (DocRaptor Basic) — environ 18×. Cet écart n’est pas une promotion d’introduction. Il est structurel. Cet article explique pourquoi la structure produit ce prix, et où chaque outil convient réellement.

Les deux architectures, côte à côte

Couche	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
Entrée	HTML + CSS (avec extensions Prince paged-media)	JSON `DocumentRequest`
Moteur de rendu	Prince (moteur C++ compilé)	Moteur Rust maison, compilé en WebAssembly
Hébergement	Serveurs centralisés DocRaptor (data center US)	Cloudflare Workers, chaque colo CF (300+ villes)
Démarrage à froid	Pool de workers côté serveur	Boot d’isolate V8, ms à un chiffre
Compute par rendu	Passe de mise en page sur HTML/CSS, puis Prince pagine	Composition directe, pas de passe d’interprétation de mise en page
p50 par rendu	~250–800 ms wall-clock (réseau + rendu)	~3–8 ms (réseau + rendu)
Déterminisme	Élevé (Prince est mature)	Byte-identique (même JSON → mêmes octets)

Si vous lisez ces deux colonnes comme « imprimante HTML générique » vs « moteur de rendu de documents conçu sur mesure », vous avez déjà compris la décision architecturale. Tout le reste (latence, coût, même les listes de fonctionnalités) découle de ce seul choix.

La taxe Prince

Prince est bon. Il fait aussi un travail dont la plupart des workflows facture/reçu/étiquette n’ont pas besoin : implémenter CSS Paged Media — règles de saut de page, en-têtes courants, notes de bas de page, références croisées, contenus générés — pour du HTML arbitraire que l’utilisateur pourrait jeter dedans.

Cette généralité a un coût d’exécution. Pour paginer du HTML arbitraire, le moteur doit :

Parser et valider le HTML
Résoudre la cascade CSS (potentiellement avec les extensions de Prince)
Construire l’arbre de rendu
Faire une mise en page multi-passes (surtout pour les tableaux qui s’étendent sur plusieurs pages, ou les colonnes qui s’équilibrent)
Résoudre les références croisées sur plusieurs pages
Émettre les objets PDF

La plupart de ces passes sont le coût d’accepter HTML comme entrée. Si votre entrée est déjà des données structurées (ce qui est presque toujours le cas — votre facture existe comme objet JSON avant que vous ne l’enveloppiez dans HTML), vous payez ces passes en compute et latence à chaque rendu, et elles n’ajoutent pas de valeur à la sortie.

gPdf saute entièrement l’étape d’interprétation de la mise en page. Le DocumentRequest JSON spécifie déjà la mise en page structurellement — { pages: [{ size, elements: [...] }] }. Le moteur compose les éléments, pagine tableaux/listes de manière déterministe, et émet le PDF. Pas de cascade CSS à résoudre, pas de mise en page de floats à calculer, pas de passe de résolution de références croisées.

Résultat : la même facture d’une page qui prend ~300 ms sur DocRaptor prend ~3 ms sur gPdf. Nous ne sommes pas plus rapides parce que nous avons écrit un Prince plus rapide — nous sommes plus rapides parce que nous ne faisons pas la plupart de ce que Prince fait.

« Trop pas cher pour être vrai » est une vraie objection d’achat

Adressons cela directement parce que cela revient dans chaque appel commercial B2B.

« 5 $/mois pour 100K rendus. DocRaptor c’est 89 $. Anvil c’est 0,10 $/PDF (donc 10 000 $ pour le même volume). Qu’est-ce qui ne va pas chez vous ? »

Trois raisons honnêtes pour lesquelles nous pouvons facturer cela :

1. Nous ne faisons pas tourner de navigateur

DocRaptor amortit l’infrastructure Prince entre clients. gPdf amortit un Cloudflare Worker, qui coûte environ 0,50 $/million de requêtes sur Workers Bundled. Avec une entrée en forme de JSON, notre moteur prend environ 1,5 ms de CPU par rendu. Empilez 50 % de marge et vous êtes encore dans la fourchette des centimes-par-millier-de-rendus. L’arithmétique est le prix.

2. Nous ne faisons pas tourner de control plane

Pas de jobs asynchrones, pas de callbacks, pas de queue de retry, pas de stockage de documents, pas d’UI de lien d’aperçu, pas de base de données multi-tenant. Chaque rendu est un seul aller-retour vers une fonction sans état et retour. Cela retire toute la surface ops que la plupart des entreprises de « API PDF » budgétisent — qui est aussi la surface qui justifie leur prix.

3. Le modèle s’auto-sélectionne hors des charges sur lesquelles nous perdrions de l’argent

Si votre document a vraiment besoin de HTML-vers-PDF (contrat juridique de 60 pages, rapport CSS-Grid complexe), vous rebondirez sur le modèle JSON dans la première heure et irez à DocRaptor de toute façon. Nous n’avons pas à pricer défensivement pour ces charges parce qu’elles s’auto-routent. Nous n’avons à pricer que pour la longue queue étroite des charges « données-structurées-vers-document », où le coût par rendu est vraiment minuscule.

Mis ensemble : 5 $/100K n’est pas un appât à perte, c’est le coût réel des marchandises vendues plus la marge. Nous pouvons le maintenir là indéfiniment parce que la compute sous-jacente est vraiment aussi bon marché lorsque vous n’embarquez pas un navigateur.

Où DocRaptor est le bon choix

Nous essayons de ne pas écrire de comparatifs intéressés. Les cas où DocRaptor gagne vraiment :

Votre entrée est du HTML que vous ne contrôlez pas entièrement. Rapports générés par les utilisateurs, templates tiers, Markdown-de-CMS-rendu-en-HTML. Vous ne voulez pas écrire un mappeur JSON pour des entrées arbitraires.
Vous avez besoin de fonctionnalités CSS Paged Media supportées par Prince. En-têtes/pieds courants par chapitre, reflow complexe de notes de bas de page, sélecteurs de pages nommées, tables des matières générées, index. gPdf a des équivalents structurés pour le sous-ensemble commun, mais si vous vivez dans des sélecteurs @page :left, Prince est votre ami.
Vous avez une équipe de contenu qui écrit du HTML/CSS, pas du JSON. N’imposez pas un workflow d’écriture JSON à une équipe non-ingénieurs. Ils vous détesteront.
Async + callbacks + stockage de documents en service. DocRaptor stocke les PDFs générés et vous donne des URLs signées pour la livraison. gPdf est strictement sans état — votre code stocke le résultat.

Si vous êtes dans l’un de ces seaux, restez sur DocRaptor. C’est le bon outil.

Où gPdf est le bon choix

L’image miroir :

Vos entrées sont déjà des données structurées (lignes de base de données, payloads d’API JSON, messages de queue).
La latence compte — flux interactifs de checkout, impression d’étiquettes en temps réel, génération de relevés à la demande.
Vous tenez à la reproductibilité byte-identique pour les tests / pistes d’audit / conservation de factures électroniques.
Vous êtes sensible au coût à tout volume au-dessus de quelques milliers de rendus/mois.
Vous avez besoin de codes-barres (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode) à précision sub-millimétrique.
Vous avez besoin de PDF/A (1b/2b/3b/4) ou d’attachements Factur-X / ZUGFeRD pour la conformité — particulièrement pertinent pour le mandat français de facturation électronique B2B à partir de septembre 2026 et le mandat allemand déjà en vigueur.
Vous préférez ne pas faire tourner un pipeline JSON-vers-HTML-vers-PDF quand vous pouvez faire tourner un pipeline JSON-vers-PDF.

Note spécifique aux équipes françaises sur Factur-X

Si votre contexte est le mandat français de facturation électronique B2B (obligatoire pour les grandes entreprises à partir de septembre 2026, PME à partir de septembre 2027, via Chorus Pro), gPdf produit le format Factur-X attendu en un seul appel API — PDF/A-3 + XML EN-16931 intégré en une étape :

curl -X POST https://gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "document": { "pages": [{ "size": "a4", "elements": [...] }] },
    "einvoice": {
      "format": "factur-x",
      "profile": "BASIC",
      "xml": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
    }
  }' \
  --output facture.pdf

Pas de post-passe Ghostscript, pas de second outil pour attacher la XML, pas de loterie de validation entre étapes. Les octets de sortie sont byte-identiques entre versions du moteur, donc votre hash de conservation pour l’obligation fiscale 10 ans peut rester stable.

La migration est mécanique, pas stratégique

Une inquiétude commune : « Changer veut dire réécrire tous nos templates ». Généralement non. La plupart des templates HTML-vers-PDF sont 20 % mise en page (qui devient structure JSON une fois) et 80 % interpolation de données (qui est exactement la même quel que soit ce que prend le moteur).

Chemin pratique :

Choisissez un type de document à migrer. Commencez par celui de plus haut volume — plus grandes économies, plus petit blast radius.
Prenez l’interface de données du template HTML (les variables qu’il interpole) et écrivez une petite fonction mapToDocumentRequest(data).
Itérez contre le Playground jusqu’à ce que la sortie corresponde.
A/B en production : routez 5 % du trafic vers gPdf pendant deux semaines. Diffez les PDFs. Comparez les factures.
Roulez en avant ou en arrière sur la base des données, pas du ressenti.

Nous avons vu des équipes faire ce changement en un seul sprint et empocher 90 % de leur facture PDF le mois suivant. Nous avons aussi vu des équipes réaliser que leur charge était en fait le cas HTML-vers-PDF, et rester sur DocRaptor — avec notre bénédiction.

TL;DR

	DocRaptor	gPdf
Meilleur pour	HTML → PDF pour contenu arbitraire	JSON → PDF pour documents structurés
Prix (100K pages/mois)	89 $	5 $
Rendu p50	250–800 ms	3–8 ms
Déployé en périphérie	❌ centralisé	✅ 300+ colos Cloudflare
Async + stockage	✅ inclus	❌ sans état par conception
PDF/A + Factur-X / ZUGFeRD	⚠️ via extensions Prince	✅ intégré

Si vos documents sont des données structurées déguisées en HTML pour un moteur de rendu, vous payez pour une étape de traduction qui n’a pas à exister. Essayez le Playground — décrivez l’une de vos factures en JSON, rendez-la dans votre navigateur en moins de 5 ms, voyez si l’écart correspond à votre intuition.