La plupart des comparatifs sur ce sujet sont des listes de fonctionnalités où une colonne se trouve être entièrement verte. Celui-ci s'organise autour des trois questions qui déterminent réellement l'outil que vous pouvez utiliser : leurs réponses éliminent des options bien avant n'importe quelle fonctionnalité.
Réponse courte : demandez-vous (1) si quelque chose doit tourner sur site, (2) qui initie la connexion, et (3) si vous êtes lié à une marque d'imprimante. Une fois ces trois points tranchés pour votre situation, il ne reste généralement qu'une ou deux options.
Les trois questions décisives
1. Quelque chose peut-il tourner en permanence sur site ? Un ordinateur, un terminal de caisse, un Raspberry Pi avec votre logiciel dessus. Si oui, PrintNode et QZ Tray vous sont ouverts. Si non (parce que les locaux appartiennent à vos clients, parce qu'il y en a deux cents, ou parce que personne sur place ne peut redémarrer quoi que ce soit), il vous faut une imprimante qui se connecte seule.
2. Qui initie : votre serveur ou l'imprimante ? Push signifie que votre backend appelle une API et que le service livre. Polling signifie que l'imprimante interroge en boucle un serveur que vous hébergez. Les architectures de polling (CloudPRNT, Epson Server Direct Print) vous remettent la disponibilité, la file d'attente et la sémantique exactement-une-fois.
3. Combien d'intégrations allez-vous maintenir ? Chaque fabricant implémente son propre protocole pour sa propre gamme : CloudPRNT chez Star, Server Direct Print chez Epson. C'est raisonnable de leur côté : ils vendent des imprimantes, pas des couches d'intégration. Mais cela signifie une intégration par marque, et un parc cesse d'être homogène dès l'ouverture d'un deuxième site. Le rôle d'une plateforme d'impression est la couche au-dessus : un endpoint unique quel que soit le matériel, plus les connecteurs entre une commande et un ticket qu'aucun fabricant ne livre.
Face à face
| Tourne sur site | Initiateur | Matériel | Plancher de latence | Vous hébergez | |
|---|---|---|---|---|---|
| IPP / CUPS natif | Serveur d'impression | Push, LAN uniquement | Tous | Réseau | Le serveur d'impression |
| QZ Tray | Applet Java par poste | Navigateur | Tous, en local | Immédiat | Rien (mais un certificat) |
| PrintNode | Client par site | Push | Tous | < 1 s | Rien |
| Star CloudPRNT | Rien | L'imprimante vous interroge | Star uniquement | Intervalle de polling | L'endpoint |
| Epson Server Direct Print | Rien | L'imprimante vous interroge | Epson uniquement | Intervalle de polling | L'endpoint |
| Expedy Print | Rien | Push | Tous (imprimante cloud ou adaptateur Pi) | < 1 s | Rien |
Lire ce tableau honnêtement
Rien ici n'est mauvais. Chaque option est le meilleur choix pour une situation. IPP est la bonne réponse pour un bureau qui imprime des documents sur un seul réseau local, et faire passer cela par une API cloud serait absurde. QZ Tray est la bonne réponse pour un opérateur au comptoir qui envoie de l'ESC/POS brut depuis une web app vers l'imprimante à côté de lui.
La colonne « tourne sur site » décide la plupart des projets. C'est elle qui détermine si votre charge de support croît linéairement avec le nombre de clients. Une application cliente convient quand vous administrez la machine ; elle devient le coût dominant quand ce n'est pas le cas.
La colonne « vous hébergez » est celle qui surprend. Construire un endpoint CloudPRNT prend un après-midi. L'exploiter (disponibilité, file, reprises, livraison exactement-une-fois, astreinte) est continu, et c'est rarement budgété au départ.
La latence ne compte que parfois. Pour une liste de préparation en entrepôt, trois secondes de polling n'ont aucune importance. Pour une cuisine en plein service, c'est la différence entre un ticket qui arrive avec la commande et un ticket qui arrive après le départ du client.
Choisir en un paragraphe
Si tout est sur un même réseau local et qu'une personne clique sur Imprimer : impression native. Si une web app doit atteindre l'imprimante du même bureau avec des commandes brutes : QZ Tray. Si chaque site dispose d'un ordinateur entretenu et allumé en permanence et que vous préférez ne pas toucher au matériel : PrintNode. Si votre parc est entièrement Star ou entièrement Epson et qu'héberger un endpoint vous convient : CloudPRNT ou Server Direct Print. Si votre backend doit imprimer sans surveillance, dans des lieux que vous ne maîtrisez pas, sur le matériel que chaque site possède : une API push neutre.
Expedy Print est conçu pour ce dernier cas : une API REST, des imprimantes cloud qui se connectent en 4G, Wi-Fi ou Ethernet, un adaptateur Raspberry Pi pour les imprimantes USB existantes, et des connecteurs pour Shopify, WooCommerce, HubRise et Zapier. Si vos réponses aux trois questions pointent ailleurs, un autre outil vous servira mieux.
Pour aller plus loin
- Alternative à Google Cloud Print : migrer du service fermé en 2020
- Alternative à PrintNode : quand l'application cliente est la contrainte
- Alternative à Star CloudPRNT : le vrai coût de l'endpoint de polling
- Alternative à QZ Tray : déplacer l'appel du navigateur vers le serveur
FAQ
Quel est le critère le plus important pour choisir une API d'impression cloud ?
Le fait que quelque chose doive tourner sur site ou non. Cette seule question détermine si votre charge de support croît avec chaque client, et elle élimine des options avant toute comparaison de fonctionnalités.
Quelle différence entre impression push et polling ?
En push, votre backend appelle une API et le service livre le travail. En polling, l'imprimante interroge en boucle un serveur que vous hébergez pour savoir s'il y a du travail, ce qui vous rend responsable de sa disponibilité et de sa file d'attente.
Quelles options me lient à une marque d'imprimante ?
Star CloudPRNT exige des imprimantes Star et Epson Server Direct Print des imprimantes Epson. IPP, QZ Tray, PrintNode et Expedy Print sont neutres.
La latence compte-t-elle vraiment ?
Cela dépend de l'usage. Quelques secondes n'ont aucune importance pour une liste de préparation en entrepôt, et sont décisives pour un ticket de cuisine en plein service, où c'est la différence entre un ticket qui arrive avec la commande et un ticket qui arrive après le départ du client.
Peut-on en utiliser plusieurs à la fois ?
Oui, et beaucoup d'équipes le font. Les impressions déclenchées par un opérateur au comptoir peuvent rester sur QZ Tray ou l'impression native pendant que les impressions événementielles passent sur une API push.