La première génération de notre système de gestion hôtelière de plein air ressemblait exactement à ce qu’on attendait d’un logiciel en 2003 : limité aux ordinateurs de bureau, rempli de tableaux denses, de petites cases à cocher, de menus imbriqués et d’une interface qui nécessitait à la fois de la patience et une souris filaire.
Newyse faisait ce pour quoi il avait été conçu. Il alimentait la gestion d'hébergements dans le secteur européen de l'hôtellerie de plein air. La profondeur était la priorité. La structure était la force.
Mais le système n'avait jamais été conçu pour fonctionner dans le cloud. Et l'interface (autrefois signe de robustesse) a progressivement commencé à ralentir les utilisateurs.
Les clients attendaient une confirmation instantanée. Les responsables avaient besoin d'une visibilité en temps réel. Il était chronophage pour le personnel de devoir cliquer à travers des couches de menus juste pour reconstituer le contexte.
En 2015, les limites étaient impossibles à ignorer :
Problèmes de scalabilité qui ne pouvaient pas suivre le rythme des groupes hôteliers en croissance
Stack technologique obsolète qui rendait l'innovation difficile
Architecture non conçue pour une infrastructure cloud moderne
Interface utilisateur qui n'avait pas évolué avec les besoins utilisateurs
Implémentation sur cloud, mais sans vraiment capitaliser dessus
Nos équipes auraient pu le rafistoler et ajouter des fonctionnalités et des améliorations progressives.
Au lieu de cela, nous avons pris du recul et posé des questions plus pertinentes.
Où les opérateurs perdent-ils du temps ? Quels workflows sont les plus importants ? Et comment concevoir un système qui réduit la charge cognitive au lieu de l'augmenter ?
Nous n'avons pas commencé par les fonctionnalités. Nous avons commencé par nos clients.
De quoi ont-ils réellement besoin ? Qu'utilisent-ils réellement ? Existe-t-il des moyens innovants de résoudre leurs problèmes ? Quelles sont les lacunes de Newyse ?
Une observation a tout changé : nous avons vu les utilisateurs cliquer cinq fois sur « valider » pour enregistrer ou mettre à jour. Il n'y avait pas de véritable fonction de validation dans Newyse.
Pourquoi ? Parce qu'il n'y avait pas de retour d'information. Pas d'indicateur de chargement. Pas de message de confirmation. Juste le silence et le doute.
Cette petite observation a révélé une vérité plus large : l'interface n'était pas seulement datée, elle créait des frictions inutiles à chaque étape.
Maxxton a été reconstruit autour de trois exigences opérationnelles :
Les opérations ne se déroulent pas uniquement sur un poste de travail. Les responsables inspectent les établissements sur site via notre interface. Le personnel de réception bascule entre tablettes et ordinateurs pour obtenir des données en temps réel. Les équipes de maintenance consultent les plannings via notre application sur leurs téléphones.
Le nouveau système devait fonctionner de manière fluide sur plusieurs appareils sans compromis.
Mauvais contraste. Petit texte. Espacement incohérent. Manque de hiérarchie de l'information. Ce n'étaient pas que des problèmes esthétiques, ils ralentissaient la prise de décision et augmentaient les marges d'erreur.
Nous avons mis en œuvre des standards de design modernes :
Ratios de contraste de couleur appropriés pour l'accessibilité
Hiérarchie typographique claire
Espacement et organisation visuelle cohérents
Dimensionnement adéquat pour les cibles tactiles et de clic
Dans Newyse, comprendre un équipement signifiait parcourir plusieurs écrans.
Voir les traductions ? Naviguer vers les paramètres de langue.
Chercher l'icône ? Vérifier la bibliothèque média.
Besoin de la catégorie ? Retour à la configuration du produit.
Dans Maxxton, toutes les informations contextuelles communiquent entre elles :
Traductions affichées en ligne
Icônes et ressources visuelles visibles immédiatement
Catégories et métadonnées présentées en contexte
Plus besoin de naviguer entre les modules pour comprendre une seule donnée.
La transformation de l'interface est visible. Mais les fondations techniques ont changé tout aussi radicalement :
L’architecture de microservices offre un accès depuis n'importe où, des mises à jour automatiques et une véritable capacité de mise à l’échelle pour les groupes hôteliers en croissance.
La stack technologique moderne nous permet d'innover plus rapidement et de nous intégrer aux outils déjà utilisés par les opérateurs.
Le développement centré utilisateur signifie que les fonctionnalités sont construites autour de workflows réels, et non de cas d'usage théoriques.
Maxxton n'est pas qu'une interface plus épurée. C'est ce sur quoi les opérateurs et le personnel comptent tous les jours.
Un clic fournit des résultats clairs. L'information vit en contexte. Le système fonctionne sur les appareils que les gens utilisent réellement. Et les équipes passent moins de temps à naviguer dans le logiciel et plus de temps à servir les clients.
Parce que les excellents systèmes de gestion hôtelière ne se contentent pas de gérer des établissements, ils donnent du pouvoir aux personnes qui les gèrent.