Trois appartements, un gérant, et tout ce qu'il n'a plus à retenir

Il y a des projets où le plus dur est technique. Celui-là, non. Le plus dur a été de comprendre ce que le client voulait vraiment dire.

Le décor : trois appartements en location saisonnière, dans une station de montagne, gérés par une seule personne. Pas une chaîne, pas une équipe, un gérant qui connaît ses logements par leur prénom et qui a tout le reste dans la tête. Les arrivées, les départs, les codes de porte, les quantités de linge à commander. Ça tient, tant que ça tient.

On a construit son automatisation en deux fois, à environ un an d'intervalle. On vous raconte les deux, parce que la deuxième n'aurait pas existé sans la première.

Premier morceau : ne plus envoyer les codes à la main

Ses serrures sont connectées. Son planning de réservations vit dans son logiciel de gestion locative. Entre les deux, il y avait lui : ouvrir le planning, voir qui arrive, générer un code valable aux bonnes dates, l'envoyer par mail au voyageur. Multiplié par trois appartements, toute la saison.

Le premier système relie les deux bouts. Il lit les réservations, génère les codes d'accès sur les serrures pour la bonne fenêtre, envoie l'email au voyageur, et affiche tout ça sur un tableau de bord qu'on a développé pour lui. Un ordonnanceur passe une fois par jour, le tout tourne sur son propre serveur.

Ce n'est pas une prouesse. C'est une chose de moins à porter, et une chose de moins à oublier un vendredi soir de vacances scolaires.

Deuxième morceau : le linge, et la question qui a tout sauvé

Un an plus tard, il revient avec un autre agacement mensuel. Chaque mois, il calcule à la main ce qu'il doit commander à sa blanchisserie : draps, housses, serviettes, en fonction des arrivées prévues. Puis il rédige l'email. Puis il espère ne pas s'être trompé, parce qu'une erreur ici ne se voit pas dans un tableur, elle se voit dans un appartement où il manque des draps le jour d'une arrivée.

Il nous envoie ses règles. Parmi elles, celle-ci : deux semaines égale fois 1,5, trois semaines fois 2, un mois fois 2,5.

Lue vite, c'est une règle de calcul. Un séjour de deux semaines, on commande une fois et demie la quantité. C'est cohérent, c'est ce que fait tout le monde, et ça se code en dix minutes.

Sauf qu'on a posé la question avant. Et la réponse était que non, ce n'est pas une quantité, c'est un tarif. Un séjour de deux semaines consomme exactement un jeu de linge, comme un séjour d'une semaine. Il coûte simplement une fois et demie le prix hebdomadaire, parce que la blanchisserie facture la durée d'immobilisation.

Avec la lecture naïve, il aurait reçu deux fois trop de draps chaque mois, et il l'aurait découvert en ouvrant les cartons.

Ce n'est pas pour se donner le beau rôle qu'on raconte ça. C'est parce que c'est le vrai métier. Le code, aujourd'hui, va vite. Ce qui va lentement, c'est de distinguer une règle de facturation d'une règle de calcul quand les deux sont écrites dans la même phrase.

Quand le client propose une solution, écouter le problème

Deuxième conversation du même genre, et elle est jolie.

Sa blanchisserie livre le vendredi qui précède chaque arrivée. Si on envoie la commande le 28 du mois pour « les arrivées du mois prochain », il y a un trou : une arrivée le lundi 1er doit être livrée le vendredi 29, c'est-à-dire la veille de l'envoi. Personne n'est couvert ce jour-là.

Il a senti le problème avant nous, ce qui arrive plus souvent qu'on ne le dit. Et il est arrivé avec une solution : passer sur un cycle de quatre semaines au lieu du mois.

Sa solution aurait marché, et elle aurait créé pire. Treize périodes par an au lieu de douze, une date d'envoi qui dérive dans le calendrier au fil des mois, et la perte du repère mensuel sur lequel sa compta est calée. On aurait échangé un problème visible contre trois problèmes diffus.

Le vrai souci n'était pas la longueur du cycle, c'était l'unité de regroupement. On a gardé le mois, et on a changé ce qu'on y met : l'email du mois en cours couvre les vendredis de livraison du mois suivant, avec les arrivées que ces vendredis desservent. Chaque vendredi appartient à un email et à un seul, les bords de période disparaissent, et son rythme mensuel ne bouge pas.

Bonus imprévu : c'était plus simple à coder que la version d'origine.

Un tableur en guise d'interface

Il fallait bien qu'il puisse modifier ses quantités. Deux draps housse par location, une serviette par personne, et ainsi de suite, avec des valeurs différentes selon l'appartement.

La réponse réflexe, c'est de développer un écran d'administration. Formulaire, validation, authentification, une demi-journée minimum, et un endroit de plus où il doit se connecter.

On a mis ça dans un tableur qu'il édite lui-même. Une ligne par poste de linge, une colonne par appartement, et une case pour dire si la quantité se compte par location ou par personne. Le système relit ce tableur à chaque exécution. Il modifie une valeur le mardi, c'est pris en compte à l'envoi suivant, sans nous prévenir et sans qu'on touche à quoi que ce soit.

Pas d'écran à développer, pas d'écran à maintenir, et un outil qu'il maîtrisait déjà avant de nous rencontrer.

Les pannes qui ne font pas de bruit

C'est la partie invisible, et c'est là qu'est passé le plus gros du travail.

Une automatisation qui plante, ce n'est pas grave : on le voit, on répare. Ce qui fait mal, c'est celle qui continue de tourner en donnant un résultat légèrement faux, pendant des mois, sans rien signaler.

Donc le système a des règles du genre :

Si la configuration est invalide, il n'envoie rien et il explique pourquoi. Il préfère ne rien faire que faire faux.

Si une réservation ne correspond à aucun appartement connu, elle apparaît quand même dans le brouillon, marquée d'un point d'interrogation. Une ligne bizarre, ça se voit. Une ligne absente, non.

Si un statut de réservation lui est inconnu, il l'inclut plutôt que de l'ignorer. Commander en trop se rattrape avec un coup de fil, une arrivée sans draps ne se rattrape pas.

Et si une réservation tombe après l'envoi de la commande du mois, un contrôle quotidien la repère et alerte le gérant avec les quantités prêtes à transmettre. Sans ce filet, le voyageur serait le premier à découvrir le problème.

Deux heures d'écart, et la leçon qui pique

Dernière histoire, et c'est celle dont on se souviendra.

L'application des codes d'accès traînait depuis des mois un décalage de deux heures sur les horaires transmis aux serrures. Un classique de fuseau horaire : des heures construites en heure locale, puis envoyées en se déclarant UTC. Un « tampon » de deux heures avait été ajouté à l'époque pour compenser, ce qui masquait à moitié le symptôme selon la saison.

On a corrigé proprement, avec relevé chiffré des codes existants avant et après pour prouver qu'aucun code déjà émis n'avait bougé d'une seconde.

Et le client a dit que le bug était toujours là.

Il avait raison. On avait corrigé ce qui part vers les serrures, mais le tableau de bord, lui, continuait d'afficher de l'heure brute. De son point de vue, rien n'avait changé : il voyait toujours deux heures d'écart à l'écran, et il en concluait logiquement que le problème persistait.

Une correction qu'on ne voit pas n'existe pas. C'est évident écrit comme ça, et pourtant on se fait avoir. Il a fallu convertir l'affichage séparément pour que la correction devienne vraie pour lui, et pas seulement pour les serrures.

Si ça vous parle

Ce client n'est pas une grosse structure. Trois appartements, une personne, et un métier où la saison ne pardonne pas les oublis.

C'est souvent là que l'automatisation change le plus de choses, parce que chaque tâche répétitive est portée par quelqu'un qui a déjà dix autres choses en tête.

Si vous avez un truc qui revient tous les mois et que vous refaites à la main en croisant les doigts, racontez-le nous. On vous dira franchement si ça vaut le coup de l'automatiser.