DocRaptor est un produit solide. Il expose Prince, le moteur HTML-to-PDF de référence, sous forme d’API REST hébergée, avec reprises, traitements asynchrones et documentation correcte. Le produit existe depuis plus de dix ans, et pour beaucoup d’équipes il reste le choix naturel quand elles ne veulent pas exploiter Prince elles-mêmes.

gPdf a une forme différente. Il n’accepte pas le HTML ; il reçoit du JSON structuré et génère le PDF directement à l’edge Cloudflare. À 100 000 pages/mois, l’écart de prix public est de 5 USD/mois (gPdf Basic) contre 89 USD/mois (DocRaptor Basic), soit environ 18x. Ce n’est pas une promotion de lancement. C’est structurel. Cet article explique pourquoi l’architecture produit ce prix, et dans quels cas chaque outil est réellement adapté.

Les deux architectures, côte à côte

Couche	DocRaptor (HTML -> PDF)	gPdf (JSON -> PDF)
Entrée	HTML + CSS, avec extensions Prince pour les médias paginés	JSON `DocumentRequest`
Moteur	Prince, moteur C++ compilé	Moteur Rust sur mesure, compilé en WebAssembly
Hébergement	Serveurs centralisés de DocRaptor, dans une région de datacenter aux États-Unis	Cloudflare Workers, dans chaque colo Cloudflare, plus de 300 villes
Démarrage à froid	Pool de workers côté serveur	Démarrage d’isolate V8, en quelques millisecondes
Calcul par rendu	Passe de mise en page sur HTML/CSS, puis pagination par Prince	Composition directe, sans passe d’interprétation de mise en page
p50 par rendu	~250 à 800 ms de bout en bout, réseau + rendu	~3 à 8 ms, réseau + rendu
Déterminisme de sortie	Élevé, Prince est mature	Octets identiques, même JSON -> mêmes octets

Si vous lisez ces deux colonnes comme “imprimante HTML généraliste” face à “moteur documentaire spécialisé”, vous avez déjà compris le choix d’architecture. Latence, coût et même listes de fonctionnalités découlent de ce choix.

La taxe Prince

Prince est excellent. Il fait aussi un travail dont la plupart des flux de factures, reçus et étiquettes n’ont pas besoin : implémenter CSS Paged Media, avec règles de saut de page, en-têtes courants, notes de bas de page, références croisées et zones de contenu généré, pour du HTML arbitraire fourni par l’utilisateur.

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

Parser et valider le HTML.
Parser et résoudre la cascade CSS, éventuellement avec les extensions propres à Prince.
Construire un arbre de rendu.
Exécuter une mise en page en plusieurs passes, surtout pour les tableaux sur plusieurs pages ou les colonnes équilibrées.
Résoudre les références croisées entre pages.
Émettre les objets PDF.

La plupart de ces passes sont le coût d’accepter le HTML comme entrée. Si votre entrée est déjà structurée, ce qui est presque toujours le cas avant qu’une facture soit enveloppée dans un modèle HTML, vous payez ces passes en calcul et en latence à chaque rendu sans qu’elles ajoutent de valeur au document final.

gPdf saute entièrement l’étape d’interprétation de mise en page. Le JSON DocumentRequest décrit déjà la page de manière structurée : { pages: [{ size, elements: [...] }] }. Le moteur compose les éléments, pagine tableaux et listes de façon déterministe, puis émet le PDF. Pas de cascade CSS à résoudre, pas de flottants à 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 avec DocRaptor prend ~3 ms avec gPdf. gPdf n’est pas plus rapide parce qu’il aurait réécrit un Prince plus rapide ; il est plus rapide parce qu’il ne fait pas la majeure partie de ce que Prince doit faire.

“Trop bon marché pour être vrai” est une vraie objection d’achat

Il faut le traiter directement, parce que le sujet revient dans presque chaque échange B2B.

“5 USD/mois pour 100 000 rendus. DocRaptor est à 89 USD. Anvil facture 0,10 USD/PDF, donc 10 000 USD pour le même volume. Qu’est-ce qui cloche ?”

Trois raisons honnêtes expliquent ce prix.

1. Nous ne lançons pas de navigateur

DocRaptor amortit une infrastructure Prince entre ses clients. gPdf amortit un Cloudflare Worker, dont le coût est d’environ 0,50 USD par million de requêtes sur Workers Bundled. Avec une entrée déjà structurée en JSON, notre moteur consomme environ 1,5 ms de CPU par rendu. Ajoutez 50 % de marge : vous restez dans un ordre de grandeur de quelques centimes pour mille rendus. L’arithmétique est le prix.

2. Nous n’exploitons pas de plan de contrôle

Pas de traitements asynchrones, pas de callbacks, pas de file de reprise, pas de stockage documentaire, pas d’interface de lien d’aperçu, pas de base multi-tenant. Chaque rendu est un aller-retour unique vers une fonction sans état. Cela retire toute la surface d’exploitation que la plupart des entreprises “PDF API” doivent financer, et qui justifie aussi leur prix.

3. Le modèle écarte naturellement les charges où nous perdrions de l’argent

Si votre document a vraiment besoin de HTML-to-PDF, par exemple un contrat juridique de 60 pages ou un rapport CSS Grid complexe, le modèle JSON vous bloquera dès la première heure et vous irez de toute façon vers DocRaptor. Nous n’avons pas besoin de tarifer défensivement pour ces charges, parce qu’elles se redirigent elles-mêmes. Nous tarifons seulement le long segment étroit des charges “données structurées vers document”, où le coût par rendu est réellement minuscule.

En résumé : 5 USD pour 100 000 pages n’est pas un prix d’appel à perte. C’est le coût de revient réel, marge comprise. Nous pouvons le maintenir parce que le calcul sous-jacent est vraiment aussi peu coûteux quand on n’expédie pas un navigateur.

Où DocRaptor est le bon choix

Nous essayons d’éviter les comparatifs à sens unique. Voici les cas où DocRaptor gagne vraiment :

Votre entrée est du HTML que vous ne maîtrisez pas entièrement. Rapports générés par les utilisateurs, modèles tiers, Markdown de CMS rendu en HTML : vous ne voulez pas écrire un adaptateur JSON pour des entrées arbitraires.
Vous avez besoin des fonctionnalités CSS Paged Media prises en charge par Prince. En-têtes et pieds courants par chapitre, recomposition complexe de notes de bas de page, sélecteurs de pages nommées, tables des matières générées, index. gPdf couvre des équivalents structurés pour le sous-ensemble courant, mais si vous vivez dans des sélecteurs @page :left, Prince est votre ami.
Votre équipe de contenu écrit en HTML/CSS, pas en JSON. N’imposez pas un processus de création JSON à une équipe non technique. Elle vous le fera payer.
Vous voulez asynchrone + callbacks + stockage documentaire comme service. DocRaptor stocke les PDF générés et fournit des URL signées pour la livraison. gPdf est strictement sans état : votre code stocke le résultat.

Si vous êtes dans l’un de ces cas, 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, données d’API JSON, messages de file.
La latence compte : checkout interactif, impression d’étiquettes en temps réel, génération de relevés à la demande.
Vous tenez à une reproductibilité octet pour octet pour les tests, les pistes d’audit ou la conservation de factures électroniques.
Le coût compte dès que vous dépassez quelques milliers de rendus par mois.
Vous avez besoin de codes-barres, GS1-128, QR, Data Matrix, PDF417, Aztec ou MaxiCode, à précision submillimétrique. Prince peut techniquement rendre des codes-barres SVG, mais obtenir une précision globale de 0,1 mm via HTML/CSS n’est pas trivial.
Vous avez besoin de PDF/A (1b/2b/3b/4) ou d’attachements Factur-X / ZUGFeRD pour vos exigences de conformité.
Vous préférez éviter une chaîne JSON -> HTML -> PDF quand une chaîne JSON -> PDF suffit.

La migration est mécanique, pas stratégique

Une inquiétude revient souvent : “Changer veut dire réécrire tous nos modèles.” En général, non. La plupart des modèles HTML-to-PDF sont composés d’environ 20 % de mise en page, qui devient une structure JSON une seule fois, et de 80 % d’interpolation de données, qui reste identique quel que soit le moteur.

Chemin pratique :

Choisissez un type de document à migrer. Commencez par celui au plus fort volume : économies maximales, surface de risque minimale.
Prenez l’interface de données du modèle HTML, c’est-à-dire les variables qu’il interpole, et écrivez une petite fonction mapToDocumentRequest(data).
Itérez dans le Playground jusqu’à obtenir une sortie correspondante.
Testez en A/B en production : envoyez 5 % du trafic vers gPdf pendant deux semaines. Comparez les PDF. Comparez les factures.
Avancez ou revenez en arrière sur des données, pas sur une impression.

Nous avons vu des équipes faire cette migration en un sprint et réduire de 90 % leur facture PDF le mois suivant. Nous avons aussi vu des équipes conclure que leur charge relevait vraiment du HTML-to-PDF et rester sur DocRaptor, avec notre accord.

TL;DR

	DocRaptor	gPdf
Meilleur pour	HTML -> PDF pour contenu arbitraire	JSON -> PDF pour documents structurés
Prix (100 000 pages/mois)	89 USD	5 USD
p50 de rendu	250 à 800 ms	3 à 8 ms
Déployé à l’edge	Non, centralisé	Oui, plus de 300 colos Cloudflare
Asynchrone + stockage	Inclus	Sans état par conception
PDF/A + Factur-X	Via extensions Prince	Intégré

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