QZ Tray résout bien un problème précis : une application web doit envoyer de l'ESC/POS ou du ZPL brut vers une imprimante physiquement raccordée à la machine sur laquelle tourne le navigateur, sans boîte de dialogue d'impression. Les navigateurs en sont délibérément incapables ; QZ Tray installe donc une petite application Java localement, et la page dialogue avec elle par socket.
Réponse courte : QZ Tray est côté client par conception. Il exige Java sur chaque poste, et un certificat de signature de code si vous voulez que l'impression se fasse sans confirmation. Si l'impression est déclenchée par un événement métier plutôt que par l'utilisateur devant l'écran, déplacer l'appel vers votre serveur supprime ces deux contraintes.
Deux modèles, deux surfaces de panne
| QZ Tray | API d'impression côté serveur | |
|---|---|---|
| D'où part l'appel | Le navigateur | Votre backend |
| Installation locale | Java + QZ Tray, par poste | Aucune |
| Certificat pour l'impression silencieuse | Oui | Non |
| Fonctionne sans session ouverte | Non | Oui |
| Fonctionne sur tablette ou téléphone | Non | Oui |
| L'imprimante doit être raccordée physiquement | Oui, à ce poste | Non, joignable par internet |
| ESC/POS et ZPL bruts | Oui | Oui |
Quand QZ Tray est le bon outil
Ne changez pas simplement parce que la liste des prérequis paraît longue. QZ Tray convient bien quand :
- La personne qui déclenche l'impression est physiquement à l'imprimante : un comptoir, une paillasse, un poste d'expédition.
- Vous imprimez sur du matériel local non adressable par le réseau, comme une imprimante d'étiquettes ou de cartes avec un pilote propriétaire.
- Le nombre de postes est faible et quelqu'un les administre.
Dans ces cas, le composant local n'est pas une contrainte, c'est l'objectif.
Où cela devient douloureux
Le certificat. Sans requête signée, QZ Tray affiche une confirmation à chaque impression. S'en débarrasser suppose d'acheter un certificat de signature de code, de garder la clé privée sur votre serveur, de le renouveler, et de gérer le jour où il expire, ce qui se manifeste généralement par « tout le monde a soudain une popup ».
Java sur chaque poste. Un JRE à installer, à maintenir à jour, et à défendre en revue de sécurité. Dans les organisations qui ont passé des années à retirer Java des postes, c'est souvent un blocage net.
L'utilisateur doit être là. Rien ne s'imprime quand le navigateur est fermé, la session expirée, ou quand la commande arrive à 3h du matin. Tout workflow qui doit réagir à un événement plutôt qu'à un clic s'y prête mal.
Le coût de support à distance. Si vos utilisateurs sont des clients plutôt que des collègues, vous supportez désormais des installations sur des machines que vous ne voyez pas.
Déplacer l'appel vers le serveur
Quand l'impression est la conséquence de quelque chose (une commande payée, une expédition créée, un ticket assigné), l'endroit naturel de l'appel est là où cet événement est déjà traité :
await fetch(`https://www.expedy.fr/api/v2/printers/${printerUid}/print`, {
method: 'POST',
headers: {
Authorization: `${process.env.API_SID}:${process.env.API_TOKEN}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({ printer_msg: ticket, origin: `commande-${orderId}` }),
});
Aucune installation, aucun certificat, aucun navigateur. L'imprimante est atteinte via sa propre connexion sortante : imprimante cloud, ou imprimante USB existante derrière un adaptateur Raspberry Pi, qui est l'équivalent le plus proche de ce que QZ Tray faisait localement.
Un entre-deux utile
Vous n'êtes pas obligé de trancher globalement. Beaucoup d'équipes gardent QZ Tray pour les impressions déclenchées par un opérateur au comptoir, et déplacent vers le serveur les impressions déclenchées par un événement : confirmations de commande, tickets cuisine, étiquettes d'expédition générées par un traitement par lot. Les deux coexistent sans conflit, et c'est la voie serveur qui continue de fonctionner la nuit.
Commencez par imprimer un ticket de test sur le plan gratuit depuis le backend qui traite déjà l'événement.
FAQ
Pourquoi QZ Tray a-t-il besoin d'un certificat ?
Sans requête signée, l'utilisateur reçoit une confirmation avant chaque impression. Un certificat de signature de code permet à votre application de signer les requêtes pour une impression silencieuse, ce qui suppose d'acheter, de stocker et de renouveler ce certificat.
Peut-on imprimer depuis un navigateur sans logiciel local ?
Pas de l'ESC/POS brut vers une imprimante raccordée : les navigateurs l'interdisent délibérément. En revanche, votre serveur peut envoyer le travail à une imprimante joignable par le réseau, ce qui sort complètement le navigateur du chemin.
Une API côté serveur gère-t-elle l'ESC/POS et le ZPL bruts ?
Oui. Les données de commande brutes peuvent transiter par l'API d'impression, donc les formats d'étiquettes et de tickets que vous générez déjà continuent de fonctionner.
Puis-je garder QZ Tray pour certaines impressions ?
Oui, et c'est souvent la bonne conception. Gardez-le pour les impressions déclenchées par un opérateur au comptoir et déplacez vers le serveur celles déclenchées par un événement ; les deux ne s'opposent pas.