Alternative à Star CloudPRNT : gardez les imprimantes, retirez le serveur

Le matériel Star n'est pas le problème. Ce que la plupart des équipes veulent remplacer, c'est l'endpoint de polling qu'elles doivent construire et héberger.

Star CloudPRNT est un protocole, pas un service. Les imprimantes Star l'implémentent, et il définit comment une imprimante demande du travail à un serveur. Cette seule distinction explique presque tout ce qui surprend à son sujet.

Réponse courte : ce sont rarement les imprimantes que l'on veut remplacer. Star fabrique du matériel thermique solide : les gammes TSP et mC-Print comptent parmi les imprimantes de comptoir les plus déployées en Europe, et leur langage de commande donne un contrôle précis sur la mise en page des tickets. Ce que les équipes veulent cesser de faire, c'est d'être le serveur. Avec CloudPRNT, l'imprimante interroge un endpoint HTTP que vous écrivez, hébergez et maintenez disponible. Une API push supprime entièrement cet endpoint.

Où se situe réellement le travail

Star CloudPRNT API REST push
Qui initie L'imprimante interroge votre serveur Votre backend appelle l'API
Endpoint à construire et héberger Oui, par vous Aucun
Plancher de latence L'intervalle de polling Moins d'une seconde
File, reprises, exactement-une-fois À votre charge Le service
Fonctionne derrière un réseau restrictif Oui, sortant seulement Oui, sortant seulement
Contrôle fin du ticket Oui Oui

Les deux modèles résolvent le problème réellement difficile : aucun port entrant sur le routeur de la boutique. La différence porte sur qui assume l'ingénierie.

Le matériel n'est pas le sujet

Il vaut la peine de séparer les deux questions, parce qu'on les confond en permanence.

Choisir une imprimante est une question matérielle : entraînement du papier, fiabilité du massicot, connectique, tenue sur un comptoir en plein service. Star s'en sort bien sur tous ces points, et c'est précisément pour cela qu'autant de déploiements CloudPRNT existent. Si vous avez déjà des imprimantes Star, il n'y a aucune bonne raison de les déposer.

Choisir comment les travaux atteignent cette imprimante est une question logicielle, et elle est indépendante. Une imprimante bien construite derrière une architecture de polling que vous devez exploiter reste une architecture de polling que vous devez exploiter.

Si vous achetez du matériel neuf, nous orientons vers des revendeurs spécialisés plutôt que de le vendre nous-mêmes : le marché de l'imprimante est mieux servi par des distributeurs qui portent plusieurs gammes et gèrent le SAV localement.

Ce que coûte réellement l'hébergement de l'endpoint

La spécification CloudPRNT n'est pas difficile, et une première implémentation prend un après-midi. Le coût n'est pas la première implémentation, c'est tout ce qui vient après.

La disponibilité devient la vôtre. Chaque imprimante du parc dépend désormais de l'accessibilité de votre endpoint. Un déploiement, un certificat expiré, un limiteur de débit mal réglé : chacun arrête l'impression partout en même temps.

Vous construisez la file. Les travaux doivent être stockés, distribués exactement une fois, marqués comme livrés, et réessayés si une imprimante prend un travail puis perd son alimentation en cours d'impression. C'est un petit problème de système distribué, facile à rater d'une façon qui n'apparaît qu'en charge.

Le polling fixe votre plancher de latence. Un intervalle de trois secondes, c'est une seconde et demie en moyenne avant que la cuisine ne voie le ticket. Le raccourcir multiplie le volume de requêtes sur tout le parc.

La charge suit le nombre d'imprimantes, pas le nombre d'impressions. Cent imprimantes qui interrogent toutes les quelques secondes constituent une charge permanente, qu'il y ait quelque chose à imprimer ou non.

Rien de tout cela n'est une critique du protocole. CloudPRNT est une conception raisonnable qui vous met délibérément aux commandes. La seule question est de savoir si vous tenez assez à ces commandes pour les exploiter.

Quand garder CloudPRNT tel quel

Deux situations, toutes deux légitimes :

  • Votre endpoint tourne déjà et fonctionne. Un serveur de polling construit il y a deux ans, stable, et que quelqu'un comprend, n'est pas un problème à résoudre. Une migration a aussi un coût.
  • L'imprimante ne doit parler qu'à une infrastructure que vous maîtrisez, pour des raisons de politique interne ou de conformité. Posséder l'endpoint devient alors une exigence, pas une charge.

Si aucun des deux ne s'applique, héberger un serveur de polling est un travail que vous choisissez plutôt qu'un travail nécessaire.

Ce que change une API push

curl -X POST https://www.expedy.fr/api/v2/printers/{printer_uid}/print \
  -H "Authorization: API_SID:API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"printer_msg": "COMMANDE #1043\n2x Margherita", "origin": "caisse"}'

Aucun endpoint à écrire, aucune file à exploiter, aucun intervalle à régler, et aucun serveur à vous dans le chemin au moment où un ticket doit sortir. Une imprimante Star dotée d'un port USB se pilote ainsi dès aujourd'hui via un adaptateur Raspberry Pi, ce qui conserve le matériel déjà acheté et ne déplace que la partie serveur.

Ce qu'un fabricant d'imprimantes ne peut pas faire pour vous

Chaque constructeur implémente son propre protocole pour sa propre gamme : CloudPRNT chez Star, Server Direct Print chez Epson, et ainsi de suite. C'est normal et, de leur point de vue, parfaitement raisonnable : ils vendent des imprimantes, pas des couches d'intégration.

La conséquence est structurelle, pas un défaut. Le protocole d'un fabricant ne peut couvrir que les imprimantes de ce fabricant. Dès que votre parc compte deux marques, vous maintenez deux intégrations, deux jeux d'identifiants et deux familles de pannes. Et aucun fabricant d'imprimantes ne livre une application Shopify ou une extension WooCommerce : ce n'est pas son métier.

C'est précisément la couche pour laquelle une plateforme d'impression existe : un seul endpoint quelle que soit la marque, plus les connecteurs : Shopify, WooCommerce, PrestaShop, HubRise, Zapier, qui se placent entre une commande et un ticket imprimé. Lorsqu'un fabricant expose un transport ouvert comme MQTT, son matériel peut être ramené sous ce même endpoint au lieu de devenir une seconde intégration à maintenir.

Migrer sans bascule brutale

  1. Laissez tourner l'endpoint CloudPRNT et ajoutez l'appel push à côté.
  2. Basculez un site sur la nouvelle voie et comparez les tickets pendant une semaine.
  3. Avancez site par site ; l'endpoint reste votre plan de retour arrière.
  4. Ne démantelez l'endpoint qu'une fois la dernière imprimante migrée.

Le plan gratuit couvre les étapes une et deux avant tout engagement. Et si la conclusion est « notre endpoint fonctionne bien, on le garde », c'est un résultat parfaitement légitime de l'exercice.

FAQ

Star CloudPRNT est-il un service ou un protocole ?

Un protocole implémenté par les imprimantes Star. Il n'y a pas de service hébergé derrière : vous écrivez et hébergez l'endpoint que l'imprimante interroge, donc vous portez sa disponibilité et sa file d'attente.

Dois-je remplacer mes imprimantes Star ?

Non, et en général il ne faut pas. Star fabrique du matériel de comptoir fiable, et les imprimantes sont indépendantes de la façon dont les travaux leur parviennent. Une imprimante Star dotée d'un port USB se pilote via un adaptateur Raspberry Pi pendant que la partie serveur bascule vers une API push.

Quelle latence ajoute le polling ?

En moyenne la moitié de l'intervalle. Un intervalle de trois secondes, c'est environ 1,5 seconde avant même que l'imprimante ne demande le travail. Le raccourcir augmente le volume de requêtes sur tout le parc.

Quand faut-il garder son endpoint CloudPRNT ?

Quand il tourne déjà, qu'il est stable et que quelqu'un le comprend : une migration a aussi un coût. Également quand une politique interne ou une exigence de conformité impose que l'imprimante ne parle qu'à une infrastructure que vous maîtrisez.

Peut-on migrer progressivement ?

Oui. Laissez tourner l'endpoint CloudPRNT, ajoutez l'appel push en parallèle, basculez un site à la fois, et ne démantelez l'endpoint qu'une fois la dernière imprimante migrée.

Pourquoi passer par une plateforme d'impression plutôt que par le protocole du fabricant ?

Parce que le protocole d'un fabricant ne couvre que les imprimantes de ce fabricant, et qu'aucun fabricant ne livre d'application Shopify ni d'extension WooCommerce. Une plateforme d'impression apporte un endpoint unique quelle que soit la marque, plus les connecteurs entre une commande et un ticket imprimé.