Des semaines dans le code, et c'était un câble
Une caisse tactile installée chez un client synchronisait mal. Pas jamais : par intermittence. Elle remontait ses ventes, puis échouait, puis repartait. Le genre de défaut qui use, parce qu'on ne peut pas le reproduire à volonté et qu'il revient toujours.
- Des semaines dans le code, et c'était un câble
- Le soulagement, et l'agacement
- Première leçon : chercher d'abord ce qui a changé
- Deuxième leçon : le matériel fait partie du logiciel
- Ce qu'un câble non blindé fait réellement
- Pourquoi la caisse continuait de vendre
- Ce que cela change pour vous
- Un interlocuteur unique, ce n'est pas un argument de vente
- La question à poser avant l'installation
Nous avons cherché là où l'on cherche naturellement quand on est éditeur : dans le code. Des semaines à décortiquer la couche d'échange, les reprises après erreur, les délais d'attente, les cas limites. À chaque hypothèse, un correctif ; à chaque correctif, le défaut revenait.
Je suis donc allé sur place. Tests matériels complets, poste, réseau, alimentation : rien. Tout était normal.
Puis j'ai regardé le câble réseau. Le client avait remplacé celui que nous avions fourni par un câble bas de gamme, non blindé.
Le soulagement, et l'agacement
On change le câble. Tout se remet à fonctionner. Immédiatement, et durablement.
Je serais malhonnête de raconter cet instant comme une victoire sereine. Il y avait le soulagement d'avoir trouvé, et une vraie contrariété : des semaines de recherche dans un code qui n'avait rien, parce qu'un élément de l'installation avait été remplacé sans que personne ne nous le dise.
Nous l'avons dit au client, franchement. Puis nous en avons tiré deux leçons, et ce sont elles qui valent d'être partagées, parce qu'elles ont changé notre façon de travailler.
Première leçon : chercher d'abord ce qui a changé
Un défaut qui apparaît sur une installation qui fonctionnait a une cause, et cette cause est presque toujours quelque chose qui a changé. Une version, un réglage, un branchement, un déménagement de matériel.
Nous avions commencé par le code parce que c'est notre métier, et c'est exactement le biais qu'il faut combattre. La première question d'un diagnostic n'est pas « où est le bug », c'est qu'est-ce qui n'est plus comme avant.
Aujourd'hui, cette question ouvre chacune de nos interventions. Elle paraît triviale, elle fait gagner un temps considérable, et elle évite de chercher un défaut logiciel là où il n'y en a pas.
Deuxième leçon : le matériel fait partie du logiciel
C'est la leçon qui a le plus de conséquences, et elle est contre-intuitive pour un éditeur.
Une caisse tactile n'est pas un programme qui tourne dans le vide. C'est un poste, une imprimante, une douchette, un terminal de paiement, un tiroir, et un lien réseau. Chacun de ces éléments peut faire échouer une opération que le code exécute pourtant correctement. Du point de vue du commerçant, la distinction n'existe pas : sa caisse ne marche pas.
C'est pour cela que nous sélectionnons et assemblons nous-mêmes le matériel de nos caisses : type d'écran tactile, micro-ordinateur, imprimante à tickets, et jusqu'au câblage. Non par volonté de tout vendre, mais parce que la fiabilité de l'ensemble ne se garantit pas si l'on ne maîtrise que la moitié de la chaîne.
Ce qu'un câble non blindé fait réellement
Le point technique mérite d'être expliqué, parce qu'il est mal connu et qu'il coûte cher.
Un câble réseau blindé possède une enveloppe conductrice qui protège les paires de fils des perturbations électromagnétiques environnantes. Un câble non blindé n'en a pas. Dans un bureau calme, la différence est souvent invisible.
Dans un commerce, elle ne l'est plus. Une caisse voisine des néons, une vitrine réfrigérée, un moteur de rideau métallique, une multiprise chargée, un terminal de paiement : autant de sources de perturbation. Le signal se dégrade, des paquets se perdent, et le réseau ne tombe pas franchement, ce qui serait plus simple : il devient intermittent.
Et l'intermittence est ce qu'il y a de pire à diagnostiquer. Un réseau coupé se voit en trois secondes. Un réseau qui perd un paquet sur mille, à des moments imprévisibles, ressemble trait pour trait à un défaut logiciel.
Pourquoi la caisse continuait de vendre
Un détail de cette histoire mérite d'être relevé, parce qu'il illustre un choix de conception que nous avions fait bien avant.
Pendant tout ce temps, la caisse a continué d'encaisser normalement. C'est la synchronisation avec la gestion qui échouait, pas la vente. Le commerce a servi ses clients sans interruption, sans écran figé, sans file d'attente.
C'est parce que notre caisse travaille sur sa propre copie des données et ne demande rien au réseau pour encaisser. Une caisse entièrement dépendante d'une connexion aurait, elle, cessé de vendre par intermittence, ce qui aurait transformé un problème technique en problème commercial. Ce fonctionnement autonome est détaillé sur la page de la caisse tactile.
Ce que cela change pour vous
Trois conséquences pratiques, valables quel que soit votre fournisseur.
- Prévenez avant de remplacer un élément. Un câble, une multiprise, une imprimante : ce sont des pièces de l'installation, pas des consommables. Un message de trente secondes évite parfois des semaines de recherche.
- Méfiez-vous des pannes intermittentes. Quand un défaut va et vient sans logique apparente, la piste matérielle mérite d'être écartée avant la piste logicielle, et non l'inverse.
- Regardez qui répond quand ça ne marche pas. Si le logiciel vient d'un éditeur, le matériel d'un revendeur et le réseau d'un troisième, chacun a une bonne raison de penser que le problème vient des deux autres. C'est la situation la plus coûteuse pour le commerçant, et la plus fréquente.
Un interlocuteur unique, ce n'est pas un argument de vente
C'est une conséquence de ce que nous avons appris. Nous éditons le logiciel, nous assemblons le matériel, et nous répondons au téléphone. Non pour vendre davantage, mais parce que l'expérience nous a montré où se logent les vrais problèmes : rarement là où on les cherche, souvent à la frontière entre deux fournisseurs.
Ce principe vaut au-delà de la caisse. Il explique aussi pourquoi nous équipons et sécurisons les installations de nos clients logiciel, et pourquoi nous développons en interne plutôt que d'intégrer le produit d'un autre.
La question à poser avant l'installation
Si vous vous équipez d'une caisse, posez-la avant la signature : qui fournit le matériel, et qui intervient quand la panne est à la frontière entre le logiciel et le réseau ?
La réponse détermine ce qui se passera le jour où votre caisse aura un comportement inexplicable. Et croyez-en notre expérience : ce jour arrive, et le coupable est rarement celui qu'on soupçonne en premier.
Demandez-nous une démonstration, et parlons aussi de votre installation, pas seulement de l'écran. Voir aussi les erreurs à éviter quand on s'équipe.
