PrintNode fait ce qu'il annonce : vous envoyez un travail à son API et une imprimante l'imprime. L'intégration est propre et la documentation est bonne. Si vous cherchez une alternative, ce n'est presque jamais parce que l'API vous a déçu : c'est à cause d'une décision d'architecture.
Réponse courte : PrintNode atteint votre imprimante via une application cliente qui doit être installée et en fonctionnement sur un ordinateur ou un Raspberry Pi du même réseau que l'imprimante. Cette machine fait désormais partie de votre production. Si vous ne pouvez pas garantir un ordinateur allumé, à jour et sans surveillance sur chaque site, il vous faut une architecture où l'imprimante se connecte seule.
La différence structurelle
| PrintNode | Expedy Print | |
|---|---|---|
| Ce qui atteint l'imprimante | Une application cliente sur un poste local | La connexion sortante de l'imprimante |
| Machine nécessaire sur site | Oui, une par site | Non |
| OS à maintenir à jour | Windows, macOS ou Linux | Aucun |
| Fonctionne avec des imprimantes USB existantes | Oui, via le client | Oui, via un adaptateur Raspberry Pi |
| Fonctionne sans aucun ordinateur | Non | Oui, avec une imprimante cloud 4G/Wi-Fi/LAN |
| Unité de facturation | Par ordinateur exécutant le client | Par imprimante |
Les deux sont des API push, les deux mettent les travaux en file, les deux sont légitimes. La seule question est de savoir si un ordinateur par site est acceptable dans votre déploiement.
Quand l'application cliente convient
Soyez honnête sur ce point avant de changer. Le modèle PrintNode convient bien quand :
- Chaque site dispose déjà d'un terminal de caisse ou d'un PC de back-office allumé en permanence et entretenu par quelqu'un.
- Vos imprimantes sont des périphériques USB existants que vous n'avez aucune intention de remplacer.
- Vous avez peu de sites, tenus par des personnes capables de redémarrer quelque chose sur demande.
Dans cette situation, ajouter une imprimante cloud vous apporte peu.
Quand cela devient un passif
Les ennuis commencent avec l'échelle et la distance :
Quelqu'un éteint l'ordinateur. Un portable qu'on referme à 18h, un PC sur une multiprise à interrupteur, une mise à jour Windows qui redémarre sur un écran de connexion et attend. Chacun de ces cas arrête l'impression sans bruit, et la panne se manifeste par une commande manquante plutôt que par une alerte.
Une chose de plus à maintenir par site. Dix sites, c'est dix systèmes d'exploitation, dix politiques d'antivirus, dix jeux d'identifiants, dix machines à remplacer un jour. L'intégration d'impression va bien ; c'est le parc d'ordinateurs qui coûte.
Des sites que vous ne maîtrisez pas. Si vous êtes éditeur SaaS ou agence et que ce sont vos clients qui occupent les locaux, « installez notre client d'impression sur un ordinateur et laissez-le tourner » est une charge de support que vous porterez indéfiniment. C'est la première raison de migration citée par les développeurs.
Une facturation par ordinateur. Quand l'unité de facturation est la machine qui exécute le client, regrouper les imprimantes par site devient un exercice d'optimisation de coût plutôt qu'un choix opérationnel.
Ce qui le remplace
Une imprimante cloud maintient sa propre connexion sortante vers le service d'impression : il n'y a rien à installer localement.
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": "TEST\nLigne 2", "origin": "test-migration"}'
Si vous voulez conserver les imprimantes USB que vous possédez déjà, un adaptateur USB Raspberry Pi joue le rôle que joue le client PrintNode, mais c'est un boîtier dédié plutôt qu'un ordinateur généraliste, sans OS de bureau à corriger ni session à ouvrir.
Migrer une intégration existante
Les formes d'API sont assez proches pour que ce soit généralement une demi-journée :
- Faites correspondre les identifiants. Les ids d'imprimante PrintNode deviennent des
printer_uiddans votre configuration. - Convertissez le payload. Si vous envoyiez de l'ESC/POS brut en base64, vous pouvez continuer ; si vous envoyiez des PDF, voyez l'impression de PDF.
- Déplacez les identifiants. Une paire de clés API remplace la clé PrintNode.
- Faites tourner les deux en parallèle. Imprimez vers les deux services quelques jours, l'ancien restant la référence, et comparez.
- Démantelez les machines clientes en dernier. Elles constituent votre plan de retour arrière.
Lequel choisir
Choisissez PrintNode si chaque site dispose d'un ordinateur que vous maîtrisez et que vous préférez ne pas toucher au matériel. Choisissez une imprimante qui se connecte seule si l'ordinateur est justement la pièce sur laquelle vous ne pouvez pas compter : parce qu'elle est dans le bâtiment de quelqu'un d'autre, parce qu'il y en a cinquante, ou parce que c'est le composant qui tombe le vendredi à 20h.
Un plan gratuit permet de tester la seconde option sur votre charge réelle avant de vous engager.
FAQ
Quelle est la différence principale entre PrintNode et Expedy Print ?
PrintNode atteint les imprimantes via une application cliente exécutée sur un ordinateur présent sur chaque site. Les imprimantes Expedy maintiennent leur propre connexion sortante : rien n'est à installer ni à maintenir en fonctionnement localement.
Puis-je conserver mes imprimantes USB en quittant PrintNode ?
Oui. Un adaptateur USB Raspberry Pi rend une imprimante USB existante adressable en REST. Il remplace la machine cliente par un boîtier dédié, sans OS de bureau à entretenir.
Migrer une intégration PrintNode existante, c'est difficile ?
Généralement une demi-journée. Les deux sont des API push : le travail consiste à faire correspondre les identifiants d'imprimante, à changer les clés, et à faire tourner les deux services en parallèle le temps de prendre confiance.
PrintNode est-il parfois le meilleur choix ?
Oui, quand chaque site dispose déjà d'un ordinateur entretenu et allumé en permanence et que vous ne voulez changer aucun matériel. Le modèle client n'est un passif que lorsque cet ordinateur n'est pas fiable.