ConoCard
Émission de cartes nativement réseau pour la Zebra ZC350 — sans pilote, y compris la lecture sans contact de l'UID, un serveur pour plusieurs imprimantes, tout OS.
Qu'est-ce que ConoCard ?
ConoCard résout un problème très spécifique et difficile : piloter la Zebra ZC350 via le réseau sans pilote, depuis n'importe quel OS — y compris la lecture sans contact de l'UID dans la même session. C'est exactement là où la pile standard de Zebra vous force à un poste Windows par imprimante avec un câble USB, et où des alternatives comme Silex SX Virtual Link exigent des installations de pilote propriétaires par machine.
Une émission se déroule comme un flux end-to-end en un seul appel REST : POST /api/issue → le serveur imprime le design, encode la puce, lit l'UID sans contact et l'enregistre comme nouvelle carte dans 2N Access Commander (ou via webhook dans un autre système de contrôle d'accès ou PMS). La réponse est du JSON avec l'UID et le statut — immédiatement utilisable par le système qui a initié la demande. L'API est authentifiée par bearer-token, et chaque émission atterrit dans un journal d'audit JSON-Lines append-only, directement ingérable par un SIEM.
Sous le capot, un binaire Rust statique sans runtime, sans GC et sans blocs unsafe : la même codebase compile et tourne sur Linux (vérifié sur Ubuntu 24.04) et Windows, et sert plusieurs imprimantes concurremment via un plan de contrôle partagé avec démultiplexage IP source. Pas d'installations de pilote kernel, pas de maintenance par poste, pas de tether USB.
Fonctionne avec la Zebra ZC350
ConoCard est construit autour d'une imprimante de cartes spécifique : la Zebra ZC350. Nous la pilotons entièrement via le réseau par une réimplémentation du protocole USB-over-IP Silex SX-200 — sans la pile pilote propriétaire de Zebra ni CardStudio. Voici où en est la v1 :
| Imprimante | Statut v1 | Sans pilote via IP | Lecture UID sans contact |
|---|---|---|---|
| Zebra ZC350 (avec puce Silex) | Supportée | Oui | Oui |
| Zebra ZC300 (avec puce Silex) | Scope par deal | Attendu oui | Attendu oui |
| Zebra ZC100 | Scope par deal | À vérifier | Pas d'encodeur NFC |
| Magicard, Evolis, IDP Smart | Sur demande | Sur demande | Sur demande |
Les variantes ZC300 et ZC100 avec option réseau utilisent la même puce Silex que la ZC350 ; le fonctionnement est donc probable mais non garanti sans vérification physique. Demandez un projet scopé pour les deals concrets.
API REST Zebra ZC350
La spécification REST complète avec exemples curl, Python et PHP.
Alternative à CardStudio
Côté serveur au lieu d'un outil par poste — quand CardStudio coince.
ZC350 + 2N Access Commander
Émission end-to-end : impression, encodage, lecture UID, enregistrement en un appel.
Logiciels comparés
Comparaison honnête vs CardStudio, FARGO Connect, CardExchange, Entrust et Silex.
Ce qu'il fait — ce qui est solide aujourd'hui
Pilotage ZC350 sans pilote
Contrôle complet de la Zebra ZC350 via IP — pas de pile pilote fournisseur, pas de tether USB, pas de poste local par imprimante. Prouvé en direct sur l'imprimante physique.
Lecture sans contact de l'UID
L'UID de la carte émise est lu sans contact dans la même session et renvoyé dans la réponse API. Pas de lecteurs séparés, pas d'étape supplémentaire.
Émission complète en un appel REST
POST /api/issue → impression, encodage, lecture UID et enregistrement dans 2N Access Commander se font côté serveur en un seul flux. JSON retourné avec UID et statut.
Enregistrement 2N Access Commander
L'UID capturée est enregistrée immédiatement comme nouvelle carte dans 2N Access Commander — l'utilisateur a l'accès en quelques secondes.
API REST avec auth bearer-token
Secure by default : le service refuse de démarrer sans token configuré et compare les tokens en temps constant. Pas de réseaux ouverts requis, pas de reverse proxy séparé juste pour ajouter l'authentification.
Journal d'audit — JSON-Lines
Enregistrement append-only de chaque émission (succès et échec), avec UID, horodatage et source. Directement ingérable par un SIEM — pas de parseurs, pas de conversions de schéma.
Sortie webhook vers d'autres systèmes
Webhook générique derrière la même couche d'intégration (trait AccessSystem) : à côté de 2N, vous pouvez alimenter tout système parlant HTTP — Salto, Dormakaba, HID, Nedap, un PMS ou des outils internes.
Un serveur → plusieurs imprimantes
Plan de contrôle partagé avec démultiplexage IP source : une instance peut servir plusieurs ZC350 concurremment. Pas de relation 1-pour-1 entre serveur et imprimante.
Multiplateforme : Linux et Windows
Un binaire Rust statique qui compile et tourne sur les deux. Vérifié sur Ubuntu 24.04 et Windows ; 87 tests verts sur chacun. TLS intégré.
Rust — qualité production
Sûr en mémoire, pas de runtime, pas de GC, et zéro unsafe dans la codebase. Pas d'enfer DLL, pas de JVM, pas d'interpréteur.
API REST comme surface d'intégration
Systèmes RH, gestion des visiteurs, app de réception, PMS ou scripts — tout ce qui parle HTTP peut demander une émission. Pas de couplage UI requis.
Déployable comme un seul binaire
Tournez sur une VM Linux, un serveur Windows, un Raspberry Pi/mini-PC, ou comme service systemd / Windows. Pas d'installation client sur les postes, pas d'installation de pilote kernel.
Pour qui — quatre cas d'usage, un moteur
Le même moteur Rust est déployé de quatre façons différentes. Ce qui fait la différence dans votre situation n'est pas quelle "édition" vous achetez, mais comment nous déployons, intégrons et facturons.
IT d'entreprise & casinos
Contrôle côté serveur dans un datacenter ou une VM corporate. 2N Access Commander end-to-end, journal d'audit vers SIEM, auth bearer-token pour exigences de conformité, multiples imprimantes par serveur pour grands parcs. Pas d'installations sur les postes.
Hôtellerie & location courte durée
Self check-in via votre PMS : une nouvelle réservation déclenche une émission de carte via webhook — pas de réception. Une petite box Linux dans le local technique (Raspberry Pi ou mini-PC) suffit. Hôtels, serviced apartments et chaînes boutique.
Intégrateurs & partenaires 2N
Gérez des flottes ZC350 côté serveur sur plusieurs clients ou sites. REST + webhook pour brancher votre propre monitoring, ticketing ou provisioning. Uniforme sur les sites, déployable multi-tenant.
Workflow-bâtisseurs & MSP
Émission de cartes comme appel API dans l'onboarding RH, la gestion des visiteurs, le ticketing ou des apps internes. Tout ce qui parle HTTP peut demander une émission — pas de couplage UI requis. Sortie webhook pour les systèmes en aval.
Stack & intégrations
Stack technique
Rust · binaire multiplateforme · API REST · TLS
Ce qui fonctionne solidement aujourd'hui
Sur la roadmap
Nous sommes explicites sur ce qui fonctionne déjà et ce qui reste à venir. L'architecture (traits AccessSystem/GuestSource, couche use-case ccp-issue) garde la plupart des éléments ci-dessous petits. Voulez-vous une fonctionnalité prioritaire ? Dites-le-nous — nous planifions autour de deals concrets.
Modèles d'imprimante supplémentaires
Magicard, Evolis, IDP Smart — scopé sur demande par deal concret (typiquement 4 à 8 semaines). La couche imprimante est un trait, donc extensible sans toucher au cœur.
Adaptateurs PMS spécifiques
La connexion webhook fonctionne aujourd'hui avec tout PMS parlant HTTP ; des adaptateurs pré-construits pour Lodgify, Smoobu, Hospitable et autres sont du travail de scoping par deal hôtelier concret.
SSO / SAML / OIDC / RBAC
Sur demande pour les déploiements où c'est une exigence d'acceptation. L'auth bearer-token est intégrée en v1 ; SSO vient par-dessus pour les environnements entreprise.
Tableau de bord multi-sites
Vue centrale des instances sur plusieurs sites. Aujourd'hui, le multi-sites tourne comme une instance par site ou via VPN.
Push SIEM actif & reporting conformité
Le journal d'audit est déjà JSON-Lines et donc ingérable par SIEM (Splunk, ELK, Sentinel). Sur la roadmap : export push actif et templates prêts à l'emploi pour NEN 7510 / ISO 27001.
Questions fréquentes
Quelle imprimante est actuellement supportée ?
En v1, uniquement la Zebra ZC350. Nous la pilotons entièrement via IP sans aucune pile pilote fournisseur, y compris la lecture sans contact de l'UID. D'autres modèles (Magicard, Evolis, IDP) sur demande ; pour des deals concrets, un projet scopé est possible — typiquement 4 à 8 semaines.
Quel système de contrôle d'accès est actuellement supporté ?
2N Access Commander end-to-end : une émission enregistre directement l'UID comme nouvelle carte dans 2N. En plus, il existe une sortie webhook générique derrière la même couche d'intégration — avec laquelle vous pouvez alimenter tout système parlant HTTP (Salto, Dormakaba, HID, Nedap, un PMS ou des outils internes).
Cela fonctionne-t-il pour les hôtels et la location courte durée ?
Oui. Un déploiement hôtelier typique connecte le PMS (système de réservation) à ConoCard via webhook, de sorte qu'une nouvelle réservation déclenche automatiquement une émission de carte sans réception. Nous scopons la connexion PMS par deal — la couche webhook est générique, les adaptateurs PMS spécifiques sont scopés par deal.
Comment une émission fonctionne-t-elle techniquement ?
Un appel REST authentifié : POST /api/issue avec bearer-token dans l'en-tête et les données de carte dans le corps. Le serveur envoie la tâche d'impression à l'imprimante via IP, encode la puce, lit l'UID sans contact, l'enregistre dans 2N Access Commander (et optionnellement via webhook dans un autre système) et renvoie du JSON avec UID et statut. Pas de poste local, pas de câble USB.
Sur quels systèmes d'exploitation cela tourne-t-il ?
Un binaire Rust statique qui compile à la fois sur Linux (Ubuntu 24.04 vérifié) et Windows. 87 tests verts sur chacun. Pas de dépendances runtime, pas de GC, et zéro unsafe dans la codebase. TLS intégré.
Qu'en est-il de l'authentification et du journal d'audit ?
Les deux intégrés dans v1. Authentification bearer-token est secure by default : le service refuse de démarrer sans token configuré et compare les tokens en temps constant. Le journal d'audit écrit chaque émission (succès et échec) en JSON-Lines append-only avec UID, horodatage et source — directement ingérable par un SIEM sans parseurs ni conversions de schéma.
Qu'en est-il de l'export SIEM, du SSO ou du reporting de conformité (NEN 7510 / ISO 27001) ?
Le journal d'audit est déjà JSON-Lines et donc ingérable par Splunk, ELK et Microsoft Sentinel. Sur la roadmap : un export push actif et des templates prêts à l'emploi pour NEN 7510 / ISO 27001. SSO/SAML/OIDC vient par-dessus l'auth bearer-token existante pour les environnements entreprise.
Comment cela se compare-t-il à Zebra CardStudio ?
CardStudio est un outil desktop par poste, avec tether USB et sans API. ConoCard est côté serveur et nativement réseau, pilotable via REST — un serveur remplace le pattern des piles pilote par poste. Plus sur l'alternative à CardStudio →
Est-il utilisable multi-sites ?
Un serveur sert plusieurs imprimantes via démultiplexage IP source. En scénario multi-sites, exécutez une instance par site ou une instance centrale avec VPN. Un tableau de bord central multi-sites est sur la roadmap.
À quoi ressemble le déploiement ?
Un binaire Rust statique, pas de runtime, pas d'installations de pilote kernel. Lancez-le dans une VM Linux, sur un serveur Windows, sur un Raspberry Pi/mini-PC, ou comme service systemd / Windows. Pas d'installation client séparée sur les postes.
Voir aussi
Envie d'en savoir plus sur ConoCard ?
Planifiez une démo ou demandez un devis. Nous réfléchissons volontiers avec vous sur la bonne solution — entreprise, hôtellerie ou intégrateur.
Planifier une démo →