Design du POS : organiser l’écran pour mieux coordonner le service

Article d’archive. Texte préparé le 2 novembre 2026, mis en ligne le 7 novembre 2026.

Une équipe gagne du temps quand le catalogue, le panier et l’état d’envoi ont chacun une place claire sur l’écran. Le redesign d’un POS se vérifie pendant une prise de commande, une correction et une reprise après erreur.

L’interface Android 0.2.0 fournit des exemples concrets de cette démarche : catalogue par catégories, panier distinct, historique des envois et messages d’état. Les éléments visuels décrits ci-dessous concernent cette version mobile. Les adaptations évoquées pour la caisse sur ordinateur constituent une méthode de refonte à appliquer à ses écrans propres.

Organiser l’écran autour du travail réel

Une commande suit plusieurs étapes : trouver le produit, préciser la quantité, relire les consignes, envoyer, puis reprendre le ticket à la caisse. L’écran doit permettre d’identifier ces étapes sans demander à l’utilisateur de mémoriser un parcours compliqué. Dans l’application, la navigation distingue Catalogue, Panier, Envois et Connexion. Le nombre d’articles et l’accès à la commande restent visibles dans une barre dédiée lorsque le panier contient des produits.

Ce découpage aide à séparer la préparation d’une commande du contrôle de sa transmission. Pour l’équipe, la distinction est pratique : un panier en cours n’est pas un ticket confirmé. Sur le poste de caisse, la même réflexion consiste à donner une place lisible aux tickets à reprendre et à l’action de finalisation, selon les possibilités de la version installée.

Une hiérarchie visuelle cohérente

Le thème mobile associe un fond clair, des cartes blanches et un vert foncé pour les actions principales. Les produits présentent leur nom, leur prix et la quantité déjà ajoutée. La grille comporte deux colonnes sur les petits écrans et quatre à partir de 650 pixels CSS. Sur un affichage suffisamment large, le panier répartit les lignes et le récapitulatif en deux zones.

Ces choix sont définis dans la feuille de style, séparément de la logique de commande. Voici un extrait simplifié, fidèle au principe utilisé pour la grille ; il est reproductible dans une interface HTML/CSS :

:root {
  --bg: #f7f7f2;
  --ink: #172c25;
  --deep: #164c3d;
}
.grid {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 11px;
}
@media (min-width: 650px) {
  .grid { grid-template-columns: repeat(4, minmax(0, 1fr)); }
}

Une variable de couleur permet de modifier une famille de composants sans reprendre chaque bouton. Une grille souple adapte la présentation à la largeur disponible. Le seuil de 650 pixels est un choix de cette interface, à tester sur les appareils concernés : il ne garantit pas à lui seul le confort sur tout terminal.

Montrer les états qui changent la décision

Une couleur seule explique rarement une situation. Le design doit associer le signal visuel à un texte compréhensible et à une action possible. Plusieurs libellés de la version mobile illustrent cette relation :

Situation	Indication dans l’interface	Conséquence pour le service
Mode démonstration	Aucune commande réelle	Utiliser cet espace pour la formation.
Connexion absente	Paramètres requis	Configurer avant une prise de commande réelle.
Réception incertaine	Envoi à vérifier · panier protégé	Reprendre le même envoi et contrôler sa confirmation.
Produit non pris en charge	À saisir à la caisse	Terminer cette saisie sur le poste adapté.

Cette visibilité peut limiter les malentendus entre les personnes : le serveur sait quelle opération reste à contrôler ; la caisse conserve son rôle de finalisation. Elle doit être accompagnée d’une règle simple de transmission des incidents. Un beau message ne remplace pas une responsabilité définie dans l’équipe.

Prévenir les erreurs sans ralentir chaque geste

Les gestes fréquents — rechercher, ajouter, ajuster une quantité — doivent rester directs. Les actions qui font perdre du travail méritent une protection proportionnée : vider le panier déclenche une confirmation, tandis qu’un envoi à vérifier verrouille les modifications de sa commande. Les libellés « Envoyer à la caisse » et « Total estimé TTC » précisent aussi ce que fait réellement le mobile.

Pour une refonte, il est utile de dresser la liste des actions et de leurs conséquences avant de dessiner les boutons. Supprimer une ligne, abandonner un brouillon et encaisser sont des opérations différentes. Le placement, le texte et la confirmation doivent suivre cette différence, sans multiplier des fenêtres identiques que les utilisateurs finiraient par fermer machinalement.

Conserver une interface réactive

Le design comprend aussi le comportement pendant une opération lente. Dans l’application Android, les accès MySQL passent par un exécuteur Java distinct du fil d’interface. Le bouton affiche l’envoi en cours et les interactions incompatibles sont bloquées. L’utilisateur dispose ainsi d’un état explicite pendant le traitement.

Sur une caisse Java Swing, le principe technique se traduit autrement : les traitements longs doivent être déplacés hors de l’Event Dispatch Thread, et les mises à jour des composants doivent respecter ce fil. Le tutoriel officiel Oracle sur Swing, rédigé pour JDK 8, décrit cette contrainte. C’est une référence de fond pour une adaptation bureau, pas l’annonce d’une migration d’ITMOR vers un nouveau thème graphique.

Vérifier la lisibilité et les usages du terrain

Les WCAG 2.2 du W3C, recommandation du 12 décembre 2024, fournissent des critères utiles pour la partie web : contraste du texte, focus visible, libellés et messages d’état. Le contraste minimal vise notamment 4,5:1 pour le texte courant, avec des exceptions prévues par le standard. Une palette agréable ne constitue donc pas une preuve de conformité.

Il faut aussi tester sur le matériel réel : lecture en terrasse, manipulation tactile, clavier affiché, noms de produits longs et panier chargé. L’interface française actuelle n’établit pas une prise en charge complète de l’arabe ou de la darija ; une localisation demande des traductions et des essais de disposition spécifiques.

Mesurer l’effet sur l’organisation

Une vérification reproductible consiste à faire exécuter le même petit scénario avant et après une modification : retrouver trois produits, ajouter une consigne, corriger une quantité et identifier une commande à vérifier. Relever le temps, les erreurs, les demandes d’aide et les incompréhensions donne des observations utiles. Répéter avec plusieurs membres de l’équipe évite de confondre aisance du concepteur et facilité d’usage.

Aucun résultat chiffré n’est fourni ici. L’objectif est de rendre le travail observable, puis d’améliorer l’écran à partir des difficultés rencontrées. Le soin apporté aux sorties papier complète celui des écrans : voir aussi la personnalisation du rapport printer.closecash dans uniCenta oPOS.

Faire évoluer votre caisse

Vous souhaitez équiper vos serveurs, adapter votre caisse ou améliorer votre organisation ? Contactez ITMOR pour présenter votre projet. Précisez votre activité, la version de votre logiciel, le nombre de postes et les difficultés à résoudre : ces éléments permettront de définir une intervention adaptée.

Références et périmètre

Présentation du 2 novembre 2026. Exemples d’interface : HTML, CSS et JavaScript d’ITMOR POS Android 0.2.0. Sources de fond consultées à cette date : W3C, WCAG 2.2, 12 décembre 2024 ; Oracle, The Event Dispatch Thread, tutoriel JDK 8. Les propositions pour la caisse bureau sont distinctes des fonctions mobiles décrites.

Dans les archives Geekkech. Développer une caisse utile : le terrain avant les fonctionnalités.