Le bureau est loué, la facture émise, l’argent absent. Trois états différents

Dans Alistera CRM, j’ai séparé le local, le contrat, la facture et le paiement. Un bureau peut être occupé et la facture émise alors que l’argent n’est pas encore arrivé. Pour comprendre l’activité, il faut relier ces états sans effacer leurs différences.

J’ai créé pour Alistera un CRM opérationnel distinct. Il comprend un catalogue d’espaces, des contrats, des factures, des paiements, la planification et la gestion des accès. C’est un produit autonome, à côté du site public et du jeu : chacun a son rôle et ses données.

Cet écran présente des bureaux fictifs, leur état et leur lien avec la location. C’est un exemple fonctionnel d’interface de catalogue, pas la disponibilité actuelle des espaces Alistera.

Catalogue des bureaux

Interface archivée · données de démonstration

Un espace existe dans le temps

Le catalogue compte 93 entrées : 71 bureaux, 12 postes de travail et 10 espaces partagés. Mais une liste ne suffit pas. « Cet espace est-il libre ? » demande une date ou une période. Le même bureau peut être occupé aujourd’hui et disponible dans un mois.

Le contrat est donc lié à un intervalle, et les chevauchements doivent être vérifiés lors des modifications. Le calendrier aide à repérer un conflit ; la validation serveur empêche qu’il naisse de deux onglets ouverts en même temps.

La facture est une demande, le paiement un événement

Le modèle financier distingue le montant facturé, le paiement confirmé et son affectation. Un paiement partiel ne solde pas forcément toute la facture. Un virement peut devoir être réparti entre plusieurs obligations. Un champ « statut » ne peut pas remplacer ces relations de façon fiable.

Voici des factures et écritures de paiement de démonstration. On peut voir comment l’interface distingue une obligation d’une entrée d’argent, sans utiliser de données financières réelles.

Factures et paiements

Interface archivée · données de démonstration

L’argent est stocké en nombres entiers, en fils. Cela évite les surprises classiques de l’arithmétique à virgule flottante lors des additions et comparaisons. Ce choix ne répare pas la comptabilité à lui seul ; il élimine une source d’erreurs inutile.

L’historique des opérations financières est conservé. Une correction doit expliquer ce qui a changé, pas faire comme si l’état précédent n’avait jamais existé. Une entreprise a parfois besoin d’une vérité inconfortable sur hier, plutôt que d’un tableau parfaitement lissé aujourd’hui.

Le travail ne s’arrête pas à l’interface

L’application utilise React, Vite, Cloudflare Worker et D1. La connexion et le profil sont liés aux permissions ; l’autorisation est vérifiée côté API, pas seulement par un bouton masqué. La planification se consulte en liste, en kanban ou en diagramme de Gantt. Les vues changent, les tâches doivent rester les mêmes.

Un CRM réalisé ne prouve pas que toute l’entreprise y effectue déjà ses opérations quotidiennes. Au stade vérifié, je peux montrer le modèle, les fonctions et les contrôles techniques ; je n’invente ni statistiques d’usage ni gains de temps.

Cette étape comprend le catalogue, les contrats, les écritures financières et la planification. On peut les examiner avec des bureaux et factures de démonstration. La mise en service quotidienne complète et la mesure du bénéfice pour l’équipe constituent une étape distincte ; il n’y a donc pas ici de chiffres d’usage ou de temps gagné.

Articles liés : Contrôle et versions des rapports · Site public d’Alistera.