Une borne peut sembler prête lors d'une démonstration de cinq minutes et pourtant échouer sur le terrain. En production, elle doit résister aux coupures réseau, erreurs d'application, redémarrages imprévus, pannes de périphériques et mises à jour courantes, sans laisser les utilisateurs ou l'équipe d'assistance sans solution.
Le but d'un pilote Kiosk n'est donc pas simplement de vérifier qu'une application se lance en plein écran. Il faut démontrer que tout le service peut être déployé, surveillé et rétabli dans des conditions réelles.
1. Définir un parcours utilisateur par terminal
Décrivez la tâche exacte que la borne doit permettre d'accomplir, du premier geste de l'utilisateur jusqu'à la confirmation du résultat : s'enregistrer, imprimer un ticket, consulter un menu, payer ou trouver une salle.
Pour chaque étape, précisez :
- l'application ou l'URL utilisée ;
- les données saisies ou affichées ;
- le temps de réponse attendu ;
- ce que l'utilisateur voit lorsqu'un service nécessaire est indisponible ;
- comment la session se termine et revient à un état initial propre.
Si une borne doit prendre en charge plusieurs parcours sans lien entre eux, déterminez si une seule application gérée peut les réunir sans risque ou si le projet ressemble désormais davantage à un poste de travail polyvalent qu'à une borne dédiée.
2. Établir une matrice de validation des applications
FydeOS Kiosk peut lancer en plein écran contrôlé un site Web, une application Web, une application Chrome ou, sur les appareils FydeOS v23 pris en charge, une application Android privée compatible. L'application reste responsable de sa disponibilité, de l'authentification, de ses contenus et de la gestion des erreurs.
Pour le mode Kiosk Android, vérifiez le paquet et la version de l'APK de production, les autorisations Android, la configuration gérée, le fonctionnement hors ligne, l'accès aux périphériques et la relance automatique après un redémarrage ou une défaillance de l'application.
Testez la version destinée à la production dans les situations suivantes :
| Situation | Résultat à vérifier |
|---|---|
| Premier démarrage | L'application prévue se lance sans administrateur sur place |
| Plantage de l'application | La borne revient en service selon la procédure convenue |
| Expiration de l'authentification | L'écran ne reste pas bloqué sur une page de connexion inutilisable |
| Erreur du serveur | L'utilisateur reçoit un message utile sans accéder au bureau sous-jacent |
| Période hors ligne | Le cache ou le mode de secours répond aux exigences du service |
| Redémarrage | L'appareil retrouve la bonne application et les bonnes politiques |
Une URL de préproduction ou un compte administrateur ne suffisent pas à prouver que le parcours de production est prêt.
3. Tester chaque périphérique dans le cadre du workflow
Créez une matrice avec les modèles exacts d'écran, de contrôleur tactile, de lecteur de codes, d'imprimante, de lecteur de cartes, de caméra, d'appareil audio et de tout autre périphérique utilisé en production. Consignez le micrologiciel, le type de connexion et les pilotes nécessaires.
Testez l'utilisation normale et les situations de panne :
- débrancher puis rebrancher le périphérique ;
- épuiser le papier ou les consommables ;
- présenter un code-barres ou une carte illisible ;
- redémarrer l'appareil alors qu'un périphérique est branché ;
- laisser la borne fonctionner pendant toute la plage de service prévue ;
- vérifier que les fenêtres de dialogue des périphériques ne donnent pas accès à des fonctions non prévues.
La prise en charge matérielle varie selon le modèle et l'image FydeOS. Vérifiez donc la compatibilité sur la combinaison exacte prévue en production.
4. Évaluer la préparation de chaque site
Pour chaque site, consignez le mode de fixation, l'accès pour la maintenance, l'alimentation électrique, le cheminement des câbles, la ventilation, le point de raccordement au réseau, les horaires d'ouverture, le contact local, les protections physiques et les exigences d'accessibilité.
Vérifiez qu'un technicien peut accéder aux composants à entretenir sans exposer les utilisateurs à l'électricité, à des arêtes vives ou à du matériel non fixé. Photographiez l'installation approuvée et indiquez qui peut ouvrir, déplacer ou débrancher la borne.
5. Prévoir les aléas du réseau
Une borne fiable prévoit un état explicite en cas de panne réseau. Testez, selon le contexte, les échecs DNS, la perte d'accès à Internet, les portails captifs, les changements de proxy et les connexions intermittentes.
Documentez :
- les destinations réseau, ports et certificats nécessaires ;
- l'équipe responsable de la connexion filaire, sans fil ou mobile ;
- la possibilité de poursuivre le service hors ligne ;
- la durée de validité des données en cache ;
- la mise en attente ou l'abandon des transactions ;
- qui reçoit l'alerte et qui prend en charge l'incident.
Ne masquez pas une panne réseau derrière un écran de chargement sans fin.
6. Définir une configuration de référence gérée
Utilisez FydeOS Management Cloud pour organiser les appareils Kiosk et appliquer les paramètres requis. Selon l'offre et la configuration choisies, la référence peut comprendre l'application ou l'URL autorisée, le lancement automatique, les restrictions de l'appareil, la gestion de l'alimentation et les contrôles des mises à jour système.
Définissez clairement les responsabilités liées aux politiques. L'équipe chargée des contenus peut gérer l'application Kiosk, tandis que l'informatique gère le système, le réseau et les groupes d'appareils. Chaque changement doit avoir un approbateur désigné et une méthode de retour arrière.
La documentation actuelle de FydeOS Kiosk détaille la configuration propre au produit.
7. Planifier les mises à jour en tant qu'événement opérationnel
Une politique de mise à jour ne se limite pas à choisir une heure. Déterminez comment l'organisation va :
- tester l'application et les périphériques avec la version système envisagée ;
- déployer d'abord la mise à jour sur un groupe canari ;
- éviter de mettre à jour toutes les bornes d'un même site simultanément ;
- vérifier que l'application redémarre après la mise à jour ;
- suspendre le déploiement ou lancer la reprise si les critères d'acceptation ne sont pas remplis.
Incluez les changements d'application, de certificats et de contenus dans le même calendrier de mise en production lorsqu'ils peuvent affecter le parcours utilisateur.
8. Rédiger la procédure de reprise à distance
Avant le déploiement, l'équipe d'assistance doit pouvoir répondre à ces questions :
- Comment détecter qu'une borne est hors ligne ou présente un problème ?
- Peut-on identifier son site, son modèle, son groupe de politiques et son responsable actuel ?
- Quelles données de diagnostic peut-on recueillir à distance ?
- Quand faut-il redémarrer ?
- Dans quels cas l'accès distant est-il autorisé et selon quelle procédure ?
- Que peut faire sans risque une personne sur place ?
- Quand faut-il envoyer un technicien ?
- Comment remplacer et inscrire un appareil défaillant ?
Les outils distants ne réduisent les déplacements inutiles que si l'équipe dispose d'une procédure de décision claire.
9. Tester sur le terrain, pas seulement en laboratoire
Installez quelques bornes sur des sites représentatifs. Testez l'éclairage, le bruit, la température, l'accès physique, la qualité du réseau et l'utilisation réelle des périphériques. Observez comment les utilisateurs se remettent de leurs erreurs et si les consignes sont compréhensibles sans aide.
Mesurez :
- le taux de réussite du parcours utilisateur prévu ;
- le délai entre l'allumage et le moment où l'application est prête ;
- la durée des interruptions imprévues ;
- le délai entre la détection d'une panne et le rétablissement du service ;
- le nombre d'incidents nécessitant une visite sur place ;
- les versions des applications, des périphériques et des politiques sur chaque appareil.
Ces mesures fournissent une base solide pour décider du déploiement.
Liste de contrôle avant le déploiement
- Le parcours utilisateur complet et les états de défaillance sont documentés.
- L'application, les comptes et les points de terminaison de production ont été testés.
- Pour le mode Kiosk Android, la version de l'APK approuvé, les autorisations, la configuration gérée, les périphériques et la reprise après redémarrage ont été vérifiés.
- Chaque périphérique de production a passé les tests d'utilisation normale et de panne.
- La fixation, l'alimentation, les câbles, la ventilation, l'accès pour la maintenance et l'accessibilité ont été approuvés pour chaque site.
- Les destinations réseau, les certificats et le comportement hors ligne sont connus.
- Les politiques Kiosk, leurs responsables et l'approbation des changements sont définis.
- Les mises à jour passent par des appareils canaris et une condition d'arrêt écrite.
- Le diagnostic distant, les actions locales et les critères de visite sur site sont documentés.
- Un pilote sur un site représentatif a permis de répéter les procédures de reprise.
Effectuer un test d'acceptation du site
Pour organiser l'assistance à plus grande échelle, consultez le guide de gestion à distance des appareils sur plusieurs sites.
Préparez l'application cible, le matériel, la liste des périphériques et l'architecture réseau pour un essai de FydeOS Kiosk. Un petit pilote sur le terrain permet de vérifier la compatibilité et la reprise avant de commander ou de convertir un parc plus important.