Quand un écran tactile a-t-il besoin d’un système Windows ?
Demandez pourquoi un écran tactile donné a fini par fonctionner sous Windows au lieu d'Android, et un nombre surprenant de personnes ne peuvent pas réellement répondre avec une raison : il s'agit de "ce que nous commandons toujours", ou de "ce que le service informatique utilise", ou d'un élément de campagne qui a été copié de la fiche technique d'un projet précédent sans que personne ne vérifie à nouveau s'il était toujours appliqué. C'est généralement le signe que la décision a été prise sur l'habitude plutôt que sur ce que le logiciel doit réellement faire fonctionner, et c'est un modèle qui apparaît dans des secteurs très différents - vente au détail, soins de santé, banque, éducation - parce que le système d'exploitation a tendance à être choisi avant que quiconque ait réellement compris ce qui doit s'exécuter à l'écran. Au moment où cette lacune apparaît, le matériel a souvent déjà été commandé, et le retour en arrière coûte du temps que personne n'avait prévu dans le budget.
Le mode d'échec n'est pas dramatique lorsqu'il apparaît. Personne ne le remarque au stade de la proposition. Cela apparaît généralement quelques semaines après le début d'un projet, lorsque quelqu'un mentionne - presque en passant - que l'écran doit également communiquer avec un logiciel existant : un système d'enregistrement, un outil de planification, une base de données client interne qui gère tranquillement l'entreprise depuis une décennie et n'a jamais fait partie de la conversation initiale car, du côté du client, un écran est un écran et le logiciel est le problème de quelqu'un d'autre.
C'est vraiment la question sous "est-ce que cela a besoin de Windows" - non pas quel système d'exploitation est généralement le meilleur, mais quel logiciel spécifique doit fonctionner sur la boîte et si ce logiciel vous donne le choix.
La question n’est pas « qu’est-ce qui est le meilleur » – mais « qu’est-ce qui doit fonctionner dessus »
On nous demande assez souvent de simplement recommander l’un ou l’autre par défaut. Les clients veulent une réponse simple, et nous comprenons pourquoi : personne ne veut faire un détour de deux semaines dans l'architecture du système d'exploitation avant de pouvoir commander un écran. Mais traiter cela comme une question de préférence générale ignore la partie qui compte réellement, et c'est la partie qui détermine presque tout le reste du projet : le prix, le délai de livraison, la charge de maintenance et si la chose fonctionne dès le premier jour.
Ici, Android et Windows ne sont pas en concurrence sur le même axe. Android sur le matériel tactile commercial est conçu pour exécuter un ensemble assez restreint de choses : une application basée sur un navigateur ou native, un lecteur multimédia, une seule interface verrouillée qui ne nécessite pas grand-chose au-delà de la saisie tactile et d'une connexion réseau. Windows porte le poids de trois décennies de logiciels d'entreprise - systèmes de comptabilité, clients de dossiers médicaux, logiciels de contrôle industriel, plates-formes de point de vente, visionneuses CAO, terminaux bancaires - dont la plupart n'ont jamais été écrits avec un système d'exploitation de type mobile à l'esprit et ne seront pas réécrits de si tôt et, dans de nombreux cas, ne seront jamais réécrits, car le fournisseur qui l'a construit a arrêté de le développer activement il y a dix ans et l'entreprise du client fonctionne toujours dessus de toute façon.
La vraie première question sur n’importe quel projet n’est donc pas « Android ou Windows ». C'est : est-ce que quelque chose de spécifique et non négociable doit s'exécuter sur cet écran, et ce logiciel n'existe-t-il que pour l'une des deux plates-formes ? Tout le reste est une considération secondaire, et le traiter comme la principale est la raison pour laquelle les projets finissent par nécessiter un échange de matériel à un stade avancé.


Où Windows gagne réellement sa place
Logiciels hérités ou spécialisés
C'est le plus important, et c'est celui qui a tendance à être laissé de côté du mémoire initial jusqu'à ce qu'un projet soit déjà bien avancé. De nombreux logiciels d’entreprise ont été conçus pour Windows et y sont restés. Systèmes d'information hospitaliers, clients ERP, certaines plates-formes de point de vente, logiciels industriels SCADA et IHM, terminaux d'assurance et bancaires - de nombreux logiciels ont quinze ou vingt ans, sont toujours corrigés, gèrent toujours l'entreprise et n'ont pas d'équivalent basé sur un navigateur ou Android qui fasse le même travail. Si l'objectif réel d'un écran tactile est d'être une interface pour l'un de ces systèmes, Windows n'est généralement pas une préférence. C'est la seule option qui existe.
Un écran d'assistance au caissier dans une succursale bancaire en est un bon exemple : il peut être nécessaire d'exécuter le propre client bancaire interne de la banque, le même logiciel que les caissiers utilisent au comptoir, simplement présenté via une interface tactile pour les clients vérifiant leurs soldes ou demandant un relevé imprimé. Il y a rarement une véritable décision à prendre dans ce cas. Le logiciel a une maison, et ce n'est pas Android. La même logique s'applique dans une usine, où un panneau de commande doit souvent exécuter un logiciel SCADA existant qui a été construit et validé au fil des années dans un environnement Windows spécifique - le réécrire ou le remplacer n'est presque jamais envisagé simplement parce qu'un écran tactile est actualisé.
Le modèle à surveiller : si un client dit quelque chose comme "il a juste besoin de se connecter à notre système", cette phrase nécessite immédiatement une question de suivi : sur quel système et sur quoi fonctionne-t-il. Ce seul suivi a permis d'économiser plus de projets d'une refonte tardive que presque tout autre élément de cette liste, et cela prend environ trente secondes à demander.
Workflows multi-fenêtres ou multi-applications
Certaines interfaces ont réellement besoin de plus d'une application ouverte et interagissant en même temps : un bureau de réception exécutant une application de planification ainsi qu'un utilitaire de numérisation de documents, un comptoir de vente au détail exécutant un logiciel de point de vente à côté d'un outil de recherche d'inventaire, un panneau de salle de contrôle affichant un tableau de bord en direct ainsi qu'un utilitaire de diagnostic. Toute la philosophie de conception d'Android repose sur une seule application remplissant l'écran à la fois. Vous pouvez contourner ce problème avec des astuces en écran partagé sur certains appareils, mais il s'agit de combattre la plate-forme plutôt que de travailler avec elle, et la solution de contournement a tendance à montrer ses coutures la première fois qu'un membre du personnel doit basculer rapidement entre les deux sous pression. Windows a été conçu exactement pour ce type de flux de travail multi-applications en couches, et il montre le moment où un projet a besoin de plus qu'une seule interface verrouillée - copier des données entre deux fenêtres ouvertes, exécuter un processus en arrière-plan pendant qu'une application destinée au personnel reste au premier plan, ce genre de chose fonctionne comme les gens l'attendent.
Intégration approfondie du matériel et des périphériques
Dès qu’un écran tactile doit communiquer avec des périphériques spécialisés (scanners de codes-barres dotés de SDK spécifiques, imprimantes de reçus, lecteurs de cartes liés à un processeur de paiement particulier, modules d’E/S industriels, automates dans une usine), le pilote et l’écosystème d’intégration comptent autant que le système d’exploitation lui-même. Windows a des décennies de prise en charge des pilotes et un pool beaucoup plus important de documentation d'intégration existante et d'outils tiers, ce qui compte beaucoup plus qu'il n'y paraît sur papier une fois que vous êtes celui qui essaie de faire parler un scanner de codes-barres vieux de quinze ans à un tout nouvel écran tactile dans un délai serré. La prise en charge des périphériques Android s'est beaucoup améliorée, et pour le matériel grand public courant comme les scanners ou imprimantes USB standard, cela convient généralement désormais. Cependant, pour les intégrations véritablement de qualité industrielle – du type avec un SDK propriétaire, un package de pilotes rarement mis à jour ou un fournisseur qui n'a jamais testé que sous Windows – cela reste le plus souvent la voie de la moindre résistance, et lutter contre cela dans un délai serré vaut rarement les économies.
Où Android gagne tranquillement
Rien de tout cela ne fait de Windows le « meilleur » choix en général, et cela vaut la peine d'être direct à ce sujet, car de nombreux projets qui demandent Windows par habitude seraient honnêtement mieux servis par Android.
Android démarre plus rapidement, récupère plus facilement après une coupure de courant et est considérablement plus facile à verrouiller dans un véritable mode kiosque à usage unique sans logiciel tiers superposé. Il constitue moins une cible pour le type de malware qui circule spécifiquement pour Windows, simplement parce qu'il y en a moins écrits pour cette classe d'appareils. L'octroi de licences est généralement plus simple et moins cher. La consommation d'énergie a tendance à être inférieure, ce qui compte plus que ce à quoi les gens s'attendent sur des écrans qui fonctionnent en continu pendant des années, parfois dans des lieux où personne ne prête une attention particulière à la facture d'électricité d'un écran, mais où le nombre s'additionne pour toute une chaîne de vente au détail. Et pour le contenu qui concerne essentiellement la navigation, la recherche et l'affichage de médias (annuaires, catalogues de produits, orientation, la plupart des panneaux de vente au détail et d'hôtellerie) aucune des fonctionnalités supplémentaires de Windows n'est réellement utilisée. Il reste là comme une complexité inutilisée que quelqu'un doit encore corriger et maintenir, mois après mois, sans aucun avantage fonctionnel.
Nous avons vu des clients demander à Windows un kiosque d'annuaire simplement parce que « Windows semble plus professionnel » ou parce que c'est ce que font leurs ordinateurs de bureau, sans aucune exigence logicielle réelle. C'est généralement le moment sur lequel il convient de s'arrêter, car cela signifie généralement un coût matériel plus élevé, une charge de maintenance informatique plus lourde et un appareil plus lent et plus sujet aux mises à jour pour un travail qui n'a jamais eu besoin de tout cela en premier lieu. La réponse honnête à la question "quel logiciel doit-il exécuter" est très souvent simplement "aucun, il affiche simplement le catalogue de produits" - et obtenir cette réponse à voix haute, avant que la commande ne soit passée, est généralement ce qui permet au client d'économiser un coût de licence récurrent pour la durée de vie du déploiement.
Une liste de contrôle rapide
Avant de choisir un système d'exploitation, il vaut la peine de parcourir une courte liste de réponses réelles, et non d'hypothèses :
· Un élément spécifique d'un logiciel d'entreprise ou existant existant doit-il être exécuté sur cet appareil, et n'a-t-il pas d'équivalent Android ou basé sur un navigateur ?
· L'interface nécessite-t-elle que plusieurs applications soient ouvertes et interagissent en même temps ?
· Doit-il se connecter à des périphériques spécialisés (terminaux de paiement, E/S industrielles, matériel spécifique de scanner ou d'imprimante) qui ne disposent que de pilotes Windows matures ?
· L'équipe informatique du client gère-t-elle déjà un environnement Windows, avec des processus de mise à jour et de support existants, ou Windows introduirait-il une toute nouvelle catégorie de maintenance pour eux ?
· La tâche réelle à l'écran consiste-t-elle essentiellement à parcourir, rechercher ou afficher du contenu, sans aucune dépendance logicielle plus profonde ?
Si les réponses honnêtes penchent vers les trois premières, Windows est probablement la bonne solution, quel que soit le coût. S'ils se tournent vers le dernier, Android fait généralement le travail pour moins d'argent et moins de maintenance à long terme – et « cela semble plus professionnel » n'appartient pas vraiment du tout à cette liste.
Le compromis que personne ne mentionne d’avance
Les comparaisons de coûts entre les deux ont tendance à se concentrer sur le prix de la licence, qui ne représente qu’une partie du tableau. La plus grande différence apparaît au cours de la durée de vie de l'écran, en termes de correctifs, d'exposition à la sécurité et de temps de travail du personnel.
Facteur | Fenêtres | Androïde |
Compatibilité logicielle | Exécute des applications héritées et d'entreprise dont la plupart des entreprises dépendent déjà | Idéal pour le contenu basé sur un navigateur, basé sur une application ou spécialement conçu |
Coût de la licence | Licence supérieure par unité requise | Inférieur, souvent fourni avec le matériel |
Mode confinement/kiosque | Possible, nécessite généralement un logiciel de kiosque tiers | Natif et généralement plus simple à configurer |
Correctifs et maintenance | Mises à jour régulières au niveau du système d'exploitation, surface d'attaque plus grande | Empreinte de mise à jour plus légère, surface d'attaque plus petite |
Temps de démarrage et récupération | Plus lent à démarrer, plus sujet aux retards liés aux mises à jour | Démarrage rapide, récupère proprement après une perte de puissance |
Prise en charge des périphériques et des pilotes | Écosystème vaste et mature | Amélioration, mais plus étroite pour le matériel de qualité industrielle |
Aucune de ces lignes n'est destinée à déclarer un gagnant global. Ils sont destinés à rendre visible le compromis réel avant qu'une décision ne soit prise sur la base de l'habitude ou de l'intuition plutôt que sur les besoins du projet.
Que se passe-t-il lorsque les clients choisissent le mauvais
Nous avons vu les choses se détériorer dans les deux sens, et cela mérite d'être décrit honnêtement, car les deux erreurs sont courantes et aucune des deux parties n'en est plus coupable que l'autre.
La version Android pour Windows lorsque vous en avez besoin ressemble généralement au modèle décrit au début de cet article : un projet axé sur le contenu et la navigation, avec une exigence logicielle qui n'apparaît qu'une fois l'approvisionnement déjà en cours. La solution à ce stade est soit un échange de matériel, qui coûte du temps et parfois de l'argent en fonction de l'état d'avancement de la commande, soit une tentative d'intégration d'une application Windows uniquement dans un environnement Android via une sorte de solution de contournement de bureau à distance, qui fonctionne techniquement mais ajoute de la latence, de la complexité et une dépendance aux conditions de réseau qu'une installation native n'aurait jamais eue. Cette solution de contournement du bureau à distance apparaît assez souvent comme un pis-aller dans cette situation, et ce n'est jamais vraiment la réponse que quiconque voulait - c'est ce qui se produit lorsqu'une refonte appropriée n'est pas possible dans le calendrier actuel et que quelque chose doit de toute façon être expédié.
La version Windows lorsque vous n'en avez pas besoin est plus silencieuse mais tout aussi courante, et elle ne produit pas d'échec dramatique comme le fait l'inadéquation d'Android - ce qui explique en partie pourquoi elle passe inaperçue pendant si longtemps. Un client commande à Windows un répertoire ou un écran de signalisation parce que c'est ce à quoi il est habitué, et un an plus tard, il est confronté à des cycles de mise à jour inattendus interrompant l'affichage en milieu de journée, à des conflits de pilotes occasionnels après une mise à jour Windows et à une équipe informatique qui dispose désormais d'un point de terminaison Windows supplémentaire à corriger et à surveiller pour un périphérique qui est simplement censé afficher une carte. Rien de catastrophique ne se produit. Il s'agit simplement d'une surcharge permanente qu'un système d'exploitation plus simple n'aurait jamais créée en premier lieu, s'accumulant discrètement dans la charge de travail de maintenance mensuelle de quelqu'un pour un écran à qui on n'a jamais demandé de faire quoi que ce soit de spécifique à Windows au départ.
Faire correspondre le système d'exploitation au projet, pas à l'habitude
Le moyen fiable de résoudre ce problème consiste à poser la question du logiciel dès le début et de manière spécifique, pas de manière générale. "Est-ce qu'il doit se connecter à quelque chose ?" est trop vague - les gens disent non parce qu'ils pensent à des choses évidentes et oublient l'outil interne auquel leur réception se connecte chaque matin sans réfléchir, celui qui est là depuis si longtemps que personne n'en parle plus parce que cela fait simplement partie du fonctionnement du bureau. Les meilleures questions ressemblent davantage à : avec quelles applications le personnel ou le public interagira-t-il réellement via cet écran, l'une d'entre elles existe-t-elle déjà en tant que logiciel Windows sans autre version, et qui, du côté du client, sera responsable de la mise à jour du système d'exploitation une fois installé.
Les capacités informatiques existantes comptent plus que ce que les gens pensent initialement. Un client disposant d'une équipe informatique interne gérant déjà des machines Windows peut absorber un point de terminaison Windows supplémentaire sans trop de frictions : il s'agit d'un périphérique supplémentaire sur un calendrier de correctifs déjà existant. Un client sans support informatique dédié, qui commande un écran pour une seule vitrine ou une seule salle d'attente, s'engage souvent à supporter une charge de maintenance plus lourde qu'il ne le pense si Windows s'installe sans véritable raison logicielle, car désormais quelqu'un - souvent celui qui se trouve dans le magasin cette semaine-là - est de facto l'informaticien d'une machine Windows qu'aucun d'entre eux ne sait réellement comment entretenir.
Le timing compte également, et c'est la partie la plus facile à ignorer lorsqu'un projet avance rapidement. La question logicielle nécessite une réponse avant la commande du matériel, pas après, et certainement pas après l'installation. Chaque version de cette pièce où les choses ont mal tourné a commencé avec cette question posée trop tard, une fois que quelqu'un était déjà engagé dans une configuration qui ne correspondait pas à ce dont le projet avait réellement besoin.
La place de FVASEE
Parce que cette décision dépend véritablement du projet plutôt que d'une préférence fixe, nous construisons des écrans tactiles muraux dans les configurations Android et Windows, sur des panneaux de 42/43 pouces, 49/50 pouces, 55 pouces et 65 pouces, de sorte que le choix du système d'exploitation ne doit pas être dicté par la configuration en stock. Le bon choix vient d'abord des exigences logicielles et d'intégration : la taille de l'écran et les spécifications matérielles sont décidées en fonction de cela, et non l'inverse.
La version courte
Windows gagne sa place lorsqu'un écran doit exécuter des logiciels d'entreprise ou existants spécifiques, jongler avec plusieurs applications à la fois ou s'intégrer en profondeur à des périphériques spécialisés qui dépendent d'une prise en charge de pilotes matures. Android gagne sa place presque partout ailleurs (affichage axé sur le contenu, annuaires, orientation, kiosques simples de vente au détail et d'hôtellerie) où sa simplicité, son coût inférieur et son verrouillage plus facile jouent en faveur du projet plutôt que contre lui. L’erreur à éviter n’est pas de choisir le « mauvais » système d’exploitation dans un sens abstrait. Il s'agit d'en choisir un par habitude avant que quiconque ait réellement répondu à la seule question qui en décide : de quoi cet écran a-t-il besoin pour fonctionner.