Les deux lancements que vous ne voulez pas
Lancement en production : l'équipement du client s'installe sur site, le technicien attend, et votre intégration passe son premier vrai test là, sur place. Chaque bug se paie en temps d'installation, en patience du client et en réputation.
Lancement avec ticket matériel : votre équipe demande un terminal pour « tester tranquillement », et la fonctionnalité attend des semaines (et des centaines de dollars) avant la première ligne de code. La moitié de ces projets meurent là : le coût démarre avant la validation.
Le sandbox casse les deux lancements : il vous donne un environnement de test aujourd'hui, gratuit et sans risque, où se tromper ne coûte rien — tandis qu'itérer, lui, vous donne tout.
Les 6 raisons de tester d'abord en sandbox
1. Zéro coût de démarrage
Le sandbox d'API Connect est inclus dans l'essai de 14 jours : créez jusqu'à 2 terminaux virtuels et commencez à développer le jour même. Pas d'importation, pas de budget à approuver, pas de serveur local à monter.
2. Zéro risque sur les données réelles
Dans le sandbox, il n'y a ni pointages de clients ni accès réels : vous pouvez enregistrer des utilisateurs, générer des événements, casser et réparer sans que personne ne perde un enregistrement. L'erreur — l'outil le plus précieux du développement — est gratuite.
3. Cas limites répétables
Les scénarios qui définissent la robustesse de votre intégration sont inconfortables à provoquer avec du matériel réel (qui se déplace sur site pour faire expirer un terminal ?). En sandbox, ils se répètent en secondes :
- Expiration du terminal : comment votre logique réagit quand un équipement dépasse sa date.
- Terminal inactif : que fait votre SaaS avec un équipement désactivé.
- Événements dupliqués : les terminaux renvoient les données à la reconnexion ; validez votre déduplication.
- Réconciliation : comparez le flux d'événements au rapport REST et confirmez qu'ils correspondent.
- Gestion des identifiants : enregistrement avec PIN/carte, changement de groupe, suppression — et le flux de retour dans votre SaaS.
4. Démo commerciale le jour même
Le sandbox transforme « oui, on pourrait l'intégrer » en démo avec des données réelles : vous créez le terminal virtuel, générez des pointages et montrez votre SaaS qui les lit en direct. Pour conclure la vente, la différence entre « le voir » et « l'essayer » est souvent la signature du contrat.
5. Onboarding des devs sans matériel
Chaque nouveau développeur du projet a besoin d'un terminal pour travailler. Avec le sandbox, l'environnement de développement est disponible immédiatement — et ne dépend pas d'un matériel libre, connecté ou présent au bureau.
6. Transition vers la production sans réécriture
Sandbox et production partagent la même API REST et les mêmes canaux d'événements. Ce que vous avez validé en sandbox fonctionne à l'identique avec le matériel physique : votre code ne change pas, seul le numéro de série réel s'enregistre.
Comment commencer : créez votre compte → ouvrez le sandbox → créez votre terminal virtuel → simulez des pointages → consommez les événements et rapports depuis votre backend. Le tout en une session de travail. Si vous devez simuler une flotte complète, l'essai vous donne la plateforme entière.
Ce que le sandbox ne couvre PAS (et c'est aussi une information)
Pour être précis : le sandbox valide votre logiciel, pas l'installation physique. La lecture biométrique réelle, la latence du réseau du site et l'installation de l'équipement se certifient avec la recette finale. La différence, c'est que ce test n'est plus un mystère : vous savez exactement quoi vérifier, car tout le reste fonctionne déjà.
Et il y a une limite de taille : le sandbox crée jusqu'à 2 terminaux virtuels. Si vous devez simuler une flotte complète (multi-sites, des dizaines d'équipements), l'essai de 14 jours vous donne la plateforme entière.
Questions fréquentes
Pourquoi ne pas tester directement sur l'équipement du client ?
Parce que c'est le lancement au risque maximal : données réelles, heures productives et réputation en jeu. Le sandbox vous permet de vous tromper gratuitement, autant de fois que nécessaire.
Quels cas limites puis-je simuler ?
Expiration de terminal, équipement inactif, doublons, réconciliation, identifiants et multi-sites — ceux qui, avec du matériel réel, exigent de se déplacer sur site pour les provoquer.
Remplace-t-il le test avec le matériel réel ?
Il remplace le blocage de départ, pas la certification finale : le test physique sur site reste nécessaire, une fois l'intégration déjà éprouvée.
Tester d'abord coûte moins cher que lancer en production
Ouvrez le sandbox, cassez ce qu'il faut et arrivez sur site avec l'intégration prête.