Faut-il adopter Screenshot pour produire les PDF de devis et de factures d'une application Laravel ? Pas à l'aveugle. Ce package transforme une vue Blade en PDF grâce au vrai moteur d'affichage de Chrome. Il est prometteur, mais récent et peu éprouvé. Un essai sur un document non critique, oui. Un basculement direct de la facturation, non.
De quoi s'agit-il exactement ?
Screenshot, présenté par Laravel News, prend du HTML, une vue Blade (le système de gabarits de Laravel) ou l'adresse d'une page web, et en tire un PDF ou une image PNG ou JPEG. Le résultat peut être enregistré sur le serveur ou sur n'importe quel espace de stockage configuré dans Laravel, un stockage cloud de type S3 par exemple.
L'exemple de la source est un certificat de formation à partager. Pour une PME, le cas parlant est plus terre à terre : le devis, la facture. La source n'en parle pas, c'est une transposition logique, pas un retour d'expérience.
Qu'est-ce que ça change par rapport aux autres outils ?
Le principe est celui du bouton "Imprimer en PDF" de votre navigateur, automatisé : le rendu suit donc ce que vous voyez à l'écran, avec les mêmes polices et les mêmes couleurs.
L'argument principal du package : il pilote Chrome depuis PHP, sans Node.js (l'environnement qui fait tourner du JavaScript côté serveur) ni Puppeteer (l'outil qui le commande d'habitude). Une brique en moins à installer, donc un peu moins de maintenance.
En face, Spatie Laravel PDF v2 propose plusieurs moteurs : Browsershot, qui repose sur Node.js et Chrome, Cloudflare, DOMPDF (écrit en PHP pur, sans navigateur) et Gotenberg. Plus établi, donc plus rassurant sur la durée.
Que faut-il prévoir sur le serveur ?
C'est là que tout se joue. Le package fonctionne avec Laravel 12 (PHP 8.2 ou plus) ou Laravel 13 (PHP 8.3 ou plus). Une commande d'installation télécharge Chrome, à condition que l'extension PHP zip soit présente. On peut aussi pointer vers un Chrome déjà installé.
Le serveur doit ensuite fournir les bibliothèques système de Chrome et les polices de vos documents. Sur un hébergement mutualisé, c'est souvent compliqué. Sur un VPS ou un serveur dédié administré par votre prestataire, c'est faisable si on l'anticipe. Notre page sur l'hébergement et la maintenance détaille ce que cela suppose.
Reste Gotenberg, un service distant qui fabrique les PDF à votre place (version 8.38 ou plus). Mais votre HTML, donc les données de vos clients, y transite. Son hébergement reste à votre charge, et son coût n'est documenté nulle part. Le jeu en vaut-il la chandelle ? Tout dépend de ce que contiennent vos documents.
Quels pièges avant de s'y fier ?
La source en signale plusieurs, très concrets.
- Le JavaScript est désactivé par défaut, et le package n'attend que la fin du chargement de la page. Un tableau qui se remplit après coup ne sera pas capturé.
- Feuilles de style et images doivent être accessibles par adresse complète, sinon Chrome ne les trouve pas.
- Pour un PDF limité à un élément précis de la page, certains sélecteurs CSS peuvent casser, l'élément étant déplacé dans le document.
- Le dossier de destination doit déjà exister.
Et la solidité ? Le dépôt affiche 25 étoiles, 97 commits et aucune release visible. Aucun test indépendant, aucun retour d'usage trouvé : on ignore comment il tient sous charge ou après des mois d'exploitation.
Les PDF sortent en A4 portrait avec 10 mm de marges, réglables. Pour les tests automatisés, un mode simulé existe, à associer à la simulation du stockage.
Pour quelle PME, et par où commencer ?
Votre application génère déjà des documents en Blade et le PDF actuel déçoit, mise en page approximative ou polices qui sautent ? Screenshot mérite un essai sur un document secondaire, une attestation par exemple. Si vos PDF fonctionnent, rien ne presse. Pour un besoin simple et critique, DOMPDF ou Spatie restent le choix prudent.
Nous accompagnons des entreprises de Provence, notamment autour de Salon-de-Provence, sur ce genre d'arbitrage. Si vos documents doivent partir tout seuls, regardez aussi la génération automatique de documents. Et pour choisir entre plusieurs moteurs selon votre serveur, le formulaire de contact est le plus court chemin.
- Screenshot convertit une vue Blade, du HTML ou une page web en PDF ou en image, avec le rendu de Chrome.
- Gratuit (licence MIT), sans Node.js, mais Chrome et ses bibliothèques doivent être installés sur le serveur, ou un service Gotenberg utilisé.
- Compatible Laravel 12 et 13 uniquement, d'après les sources consultées.
- Projet récent, sans retour d'usage indépendant : à tester sur un document non critique, et à comparer à Spatie ou DOMPDF.
Questions fréquentes
Le package Screenshot est-il payant ?
Non, il est publié sous licence MIT, donc gratuit. Le coût réel se situe ailleurs : l'installation de Chrome sur le serveur, ou l'hébergement d'un service Gotenberg si vous choisissez le mode distant. Aucun tarif n'est documenté pour ce second cas.
Faut-il Node.js pour utiliser Screenshot ?
Non. Son driver par défaut pilote Chrome directement depuis PHP, sans Node.js ni Puppeteer. C'est l'une de ses différences avec le driver par défaut de Spatie Laravel PDF, qui s'appuie sur Node.js et Chrome.
Mon application Laravel 11 peut-elle l'utiliser ?
D'après le dossier consulté, le package demande Laravel 12 avec PHP 8.2 ou plus, ou Laravel 13 avec PHP 8.3 ou plus. Une version plus ancienne n'est pas indiquée comme prise en charge.
Peut-on tester l'envoi du PDF sans lancer Chrome ?
Oui, Screenshot::fake() enregistre les captures sans démarrer Chrome. Attention, il écrit quand même les fichiers : on l'associe donc à Storage::fake() pour ne rien laisser sur le disque réel.