Alternative à Xibo
cloud SaaS sans serveur

Un serveur Xibo qui tourne bien depuis trois ans est un actif, pas un problème. Le migrer par principe, c'est jeter du travail qui fonctionne. La question utile n'est donc pas « faut-il partir » mais « où le self-hosted continue-t-il d'avoir raison ». Trois réponses reviennent :

• Là où les données ne doivent pas sortir. Un affichage relié à un système interne, dans un réseau sans accès extérieur : le cloud n'y a rien à faire, et prétendre le contraire serait malhonnête.
• Là où quelqu'un s'en occupe déjà. Si un service informatique administre d'autres serveurs, un de plus ne change pas la charge. C'est le seul cas où le coût réel du self-hosted est proche de son coût affiché.
• Là où le parc est stable. Cinq écrans installés il y a quatre ans, qui ne bougent plus : ni la croissance ni la mobilité ne posent problème, donc rien ne pousse au changement.

Et là où le cloud gagne, c'est symétrique : les écrans qui n'existent pas encore. Un nouveau point de vente, une boutique éphémère, un écran testé pendant un mois avant décision. Ce sont des situations où monter un accès au serveur existant coûte plus cher que le mois d'abonnement qu'on économise.

Concrètement, cela donne une transition sans date : on ne touche pas à l'existant, on ouvre les nouveaux écrans ici, et au bout d'un an on compare deux choses qu'on a vraiment vécues. Beaucoup de commerces s'arrêtent là et gardent les deux — c'est un résultat parfaitement valable et personne ne l'écrit jamais dans un comparatif.

Le seul point à surveiller dans une configuration mixte est humain et pas technique : deux endroits où modifier le contenu, c'est un endroit oublié. Tant que les deux parcs sont séparés par lieu, ça tient. Dès que deux écrans d'un même local sont sur deux systèmes, il faut choisir.

Où la langue coûte réellement quelque chose :

• Dans les messages d'erreur, plus que dans les menus. Un menu s'apprend par la position. Une erreur, il faut la lire — et c'est le seul moment où on en a vraiment besoin.
• Dans la recherche d'aide. Chercher la solution suppose de savoir formuler le problème dans la langue où les réponses existent. C'est une compétence, et elle n'est pas partagée par toute l'équipe.
• Et dans le support. Écrire un ticket dans une autre langue rallonge chaque échange, et un aller-retour de plus signifie souvent un jour de plus.

Le point à trancher n'est donc pas la langue de l'outil mais une question plus précise : qui va s'en servir quand tu ne seras pas là. Si la réponse est «moi», la langue ne compte pas. Si c'est quelqu'un d'autre, elle décide plus que la moitié des fonctionnalités comparées.

Et cela vaut d'être vérifié avant, parce que ça ne se corrige pas après : traduire une interface n'est pas de ton ressort. C'est l'une des rares différences entre deux solutions sur laquelle tu ne peux rien, quelle que soit ta bonne volonté ou ton budget.

Fais faire une modification à la personne qui s'en occupera, dans l'outil tel qu'il est. Si elle bute sur un mot avant de buter sur une fonction, tu as ta réponse.

Appliquer une mise à jour de sécurité, c'est la moitié facile. Vingt minutes, et ça se passe presque toujours bien. Ce qui coûte, c'est avant : savoir qu'elle existe. Pas de facture pour le rappeler, pas de courriel de renouvellement, personne qui appelle. Le seul moyen est d'être inscrit là où c'est publié et de le lire le jour même, et ça doit tenir des années — y compris les mois où le commerce va mal et où tu as autre chose en tête.

Et la faille ne te prévient pas qu'elle est exploitée. Un serveur compromis ne tombe pas : il continue d'alimenter tes écrans exactement pareil pendant qu'il fait autre chose en dessous. C'est pour ça que ce risque ne ressemble à aucun autre du comparatif — les autres se montrent le jour où ils arrivent, celui-ci peut durer des mois sans que rien de ce que tu regardes ne change.

D'où la question honnête, qui n'est pas de savoir si tu sais l'installer. C'est qui va regarder ça en mars prochain, et ce qui se passe si cette personne est occupée ce mois-là. Si cette question a une réponse avec un nom et un créneau dans un agenda, l'auto-hébergement est une excellente option et il revient moins cher. Sinon, ce que tu choisis n'est pas un serveur : c'est un compte à rebours qui démarre le jour de l'installation.

En toute franchise : ce n'est pas un argument contre le logiciel libre, que nous utilisons et dont nous vivons. C'est que la licence et l'hébergement sont deux décisions différentes, et seule la seconde t'engage à surveiller.