Cinq apart-hôtels, deux sociétés d'exploitation, un seul jeu de comptes — et le décompte de chaque propriétaire qui sort des écritures.

Un apart-hôtel, c'est un appartement loué comme une chambre d'hôtel : on y dort quelques nuits ou quelques mois, mais il a une cuisine et un séjour. L'exploitant en tient cinq en Suisse romande, et un sixième se prépare — des immeubles entiers, pas des chambres.

Ces immeubles ne lui appartiennent pas. Il les exploite pour des propriétaires, à qui il doit un décompte : ce que le bien a rapporté, ce qu'il a coûté, ce qui leur revient.

Et l'exploitation est répartie sur deux sociétés, réunies dans un groupe qui en compte une troisième — celle qui gère des logements pour le compte de tiers. Mêmes personnes, mêmes comptes à tenir, trois périmètres.

Odoo tenait déjà la comptabilité et la facturation des deux sociétés d'exploitation. Ce qui manquait était à l'autre bout de la chaîne : le document que chaque propriétaire attend.

Ce n'était pas un confort qu'on pouvait repousser. L'échéance était là, et les décomptes devaient partir. Un engagement qu'on a vis-à-vis du propriétaire d'un immeuble ne se négocie pas avec le calendrier d'un projet informatique.

À côté de ça, rien ne permettait de comparer les établissements entre eux, ni de lire les chiffres du groupe sans les additionner soi-même. Et les factures des fournisseurs se validaient hors de tout circuit.

[Comment les décomptes étaient produits avant — ou s'ils l'étaient — reste à établir avec le client.]

Un module de décomptes a été construit par-dessus la comptabilité. Les données de chaque apart-hôtel remontent, et le décompte destiné au propriétaire se génère depuis les écritures comptables, en s'appuyant sur les comptes concernés. Personne ne le reconstruit à la main.

Des comptes analytiques ont été posés à l'intérieur de chaque société, ce qui permet de voir ce que chaque établissement rapporte par rapport aux autres — une information qu'une comptabilité par société ne donne pas.

Et comme les sociétés du groupe vivent sur une même instance, la direction lit les chiffres de l'ensemble ou d'une entité au choix, sans changer d'outil.

Le site présente les établissements et leurs appartements. Il s'arrête là : la réservation part vers les outils du métier, qui savent tenir un calendrier et des tarifs, et la conversation avec les voyageurs reste dans l'outil de l'exploitant, simplement posé dans la page.

C'est un choix de périmètre, pas une limite technique. Construire un moteur de réservation dans un site vitrine, c'est fabriquer un deuxième endroit où l'occupation d'un appartement est écrite — et deux endroits finissent toujours par se contredire.

Le design avait été confié à un designer avant notre arrivée. Nous avons construit le site, pas son apparence.

Les factures des fournisseurs arrivent en nombre, et c'est rarement le directeur financier qui a commandé la prestation. Le circuit mis en place inverse l'ordre : le responsable qui a passé la commande confirme d'abord que la prestation a bien été rendue, et le paiement ne part qu'ensuite. Les pièces sont classées au même endroit que la validation qui les accompagne.

Rien de spectaculaire là-dedans. C'est ce qui évite de régler une prestation que personne n'a reçue.

Les salaires sont en cours de mise en place. Le site et l'outil de suivi commercial sont en cours de raccordement, pour qu'une demande déposée sur le site arrive dans le suivi au lieu d'une boîte mail.

Et la direction veut ramener ce qui vit encore à côté — la planification des équipes, notamment. Chaque brique arrive parce que la précédente a servi.