Le coût réel de « tester avec un vrai appareil »
Si vous développez un SaaS de paie, un système de copropriété ou une plateforme RH, à un moment donné un client vous demandera : « pouvez-vous lire mes terminaux ZKTeco ? ». Le chemin traditionnel ressemble à ceci :
- Acheter un terminal de test : entre 250 et 900 USD selon le modèle.
- Logistique d'importation en Amérique latine : semaines d'attente et droits de douane variables.
- Monter un serveur local ou un VPN juste pour les premiers tests.
- Consacrer du temps de votre équipe avant de savoir si la fonctionnalité vaut le coup.
C'est-à-dire : des centaines de dollars et des semaines de friction avant la première ligne d'intégration. Pour une équipe produit, cela signifie souvent que la fonctionnalité ne sort jamais du backlog.
L'alternative : un sandbox virtuel — un terminal simulé qui génère de vrais événements et se consomme exactement comme le matériel physique. Votre code ne sait pas (et ne s'en soucie pas) si de l'autre côté il y a un appareil à 800 $ ou une simulation.
Ce que vous pouvez valider sans toucher au matériel
Le sandbox d'API Connect crée jusqu'à 2 terminaux virtuels avec les mêmes capacités qu'un terminal physique connecté au cloud :
- Enregistrement de terminaux avec numéro de série, modèle et date d'expiration.
- Événements d'accès en temps réel : pointages accordés, refusés et impulsions de synchronisation.
- Rapports de pointage consultables par plage de dates, avec pagination.
- Utilisateurs et identifiants : enregistrement de personnes avec PIN, carte et groupes d'accès.
- Expiration des appareils : testez le comportement de votre logique quand un terminal expire.
Pas à pas : de zéro à votre premier événement
1. Créez votre compte (14 jours gratuits, sans carte)
L'inscription prend moins d'une minute. En entrant dans le dashboard, vous avez accès au sandbox, à l'API et aux rapports pendant tout l'essai.
2. Créez votre premier terminal virtuel
Depuis le sandbox du dashboard, créez un terminal virtuel. Vous recevrez son numéro de série simulé, qui est la clé pour tout le reste.
3. Simulez des pointages depuis le navigateur
L'écran de simulation vous laisse interagir avec le terminal virtuel : enregistrer des pointages d'entrée et de sortie, et générer des événements d'accès. Chaque événement reste dans votre historique comme s'il venait d'un appareil physique.
4. Authentifiez votre logiciel auprès de l'API
Votre backend s'authentifie avec les identifiants de votre compte et reçoit un token pour appeler l'API REST :
curl -X POST https://VOTRE-DOMAINE-API/auth/login \
-H "Content-Type: application/json" \
-d '{"username": "votre_utilisateur", "password": "votre_mot_de_passe"}'
# Réponse
{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...",
"token_type": "bearer",
"expires_in": 3600
}
5. Consultez les pointages générés
Avec le token, demandez le rapport du terminal virtuel avec la plage de dates souhaitée :
curl -X GET "https://VOTRE-DOMAINE-API/report/VOTRE-SERIAL?from=2026-09-01&to=2026-09-14&page=1&per_page=500" \
-H "Authorization: Bearer {token}"
La réponse arrive en JSON prête à être mappée à vos modèles : pointage, personne, méthode de vérification et date exacte. Si votre logiciel importe déjà des CSV de pointeuses, cette étape fait la différence entre un processus manuel hebdomadaire et des données en direct.
6. (Optionnel) Consommez les événements en flux
Si votre architecture préfère réagir aux événements plutôt que les consulter, vous pouvez vous abonner aux événements du terminal et les traiter à mesure qu'ils surviennent :
import { createClient } from 'redis';
const sub = createClient({
socket: { host: process.env.REDIS_HOST, port: Number(process.env.REDIS_PORT) },
password: process.env.REDIS_PASSWORD
});
await sub.connect();
await sub.subscribe('punch_VOTRE-SERIAL', (message) => {
const event = JSON.parse(message);
console.log('nouveau pointage :', event.pin, event.timestamp);
// ici, déclenchez votre logique métier
});
Quand passer en production
Le jour où la fonctionnalité est approuvée, la transition est la partie facile : les terminaux physiques du client s'enregistrent et pointent vers le cloud, et votre logiciel continue d'appeler les mêmes URLs. Pas de phase de « réécriture » car sandbox et production partagent la même API.
Pour votre planning : le sandbox est limité à 2 terminaux virtuels. Si vous devez simuler une flotte complète (50 terminaux, multi-sites), l'essai complet de 14 jours vous donne la plateforme entière.
La valeur pour votre produit, en une phrase
Vous pouvez répondre « oui, nous lisons vos terminaux ZKTeco » lors d'une démo avec des données réelles le jour même où l'opportunité commerciale apparaît — sans rien acheter, sans attendre d'importations et sans monter d'infrastructure.
Questions fréquentes
Ai-je besoin d'un terminal ZKTeco réel pour tester ?
Non. Le sandbox virtuel crée jusqu'à 2 terminaux de test qui génèrent de vrais événements et se consomment comme un appareil physique.
Le sandbox est-il gratuit ?
Oui : il est inclus dans l'essai de 14 jours et ne demande aucune carte bancaire.
Ce que je développe sert-il en production ?
Oui : vous consommez la même API REST et les mêmes canaux d'événements. En production, vous ajoutez simplement les terminaux réels.
Testez votre intégration aujourd'hui, pas le mois prochain
Créez votre compte, ouvrez le sandbox et générez votre premier événement en quelques minutes.