Cas 02 · Sous NDA
Le système dans lequel une entreprise passe sa journée
Une entreprise d’installation a dépassé ses tableurs, puis a découvert que les logiciels tout faits ne collent pas à sa façon réelle de travailler. Voici ce qui les a remplacés : une plateforme unique couvrant la vente, le planning, l’exécution sur chantier, la logistique, la comptabilité et un portail client — et les décisions qui la soutiennent.
- Rôle
- Seul développeur — du modèle de données aux déploiements
- En service depuis
- Début 2026, en production quotidienne
- Utilisateurs
- Des dizaines de personnes par jour, plus un portail client
- Stack
- React · TypeScript · Postgres · Supabase
Contexte
Ce qu’elle a remplacé
Toute entreprise qui atteint une certaine taille possède les mêmes trois outils : un tableur que personne n’ose toucher, une boîte mail partagée, et une personne qui se souvient encore de la façon dont tout s’emboîte. Ça tient jusqu’au jour où ça ne tient plus — en général le jour où cette personne est en congé.
La réponse évidente est d’acheter quelque chose. Elle échoue pour une raison précise : un CRM standard présuppose un processus de vente, un ERP standard présuppose une usine, et une entreprise qui installe des choses chez les gens n’est ni l’un ni l’autre. On finit par plier l’entreprise au logiciel, et le tableur revient discrètement porter tout ce qui n’entrait pas.
La demande n’était donc pas « numérisez ceci ». Elle était : modélisez ce que cette entreprise fait réellement, et raccourcissez la journée de chaque rôle au lieu de mieux la documenter.
Périmètre
Cinq couches, une base de données
chaque couche a sa couleur
-
Prospects
- qualification
- origine du lead
- relance
-
Devis
- prix par ligne
- régimes de TVA
- signature numérique
-
Chantier
- planning
- exécution
- stock
-
Factures
- rapprochement
- déclarations TVA
- recouvrement
-
Portail
- client & partenaire
- rôles & droits
- row-level security
Un dossier traverse ces couches de gauche à droite, et chaque passage de relais est un endroit où vivait autrefois un tableur. Les poser sur une seule base de données est ce qui supprime la ressaisie — et ce qui fait du contrôle d’accès le problème le plus dur de cette page.
Technique
Les décisions qui comptaient
et ce que coûte l’alternative
Un devis est un contrat, ses lignes sont donc immuables
Un devis signé ne peut plus changer — ni ses prix, ni son régime de TVA, ni l’ordre de ses lignes. Le modifier crée une nouvelle révision et laisse la version signée exactement telle que le client l’a vue. La facture est ensuite générée à partir des lignes signées, et non recalculée avec les prix actuels.
Pourquoi pas l’inverse
L’alternative paraît plus simple pendant environ un an, jusqu’à ce qu’une mise à jour du tarif réécrive en silence ce qu’un client avait accepté. Ce bug-là ne se trouve pas en test ; il se trouve en litige.
Le portail est sur la même base, donc le RLS est le socle
Clients et partenaires lisent leurs propres projets dans les tables où travaille la comptabilité. Pas de base miroir, pas de job de synchronisation. Chaque table que le portail touche porte une policy row-level, et c’est la policy — pas la requête, pas le composant — qui décide de ce qui revient.
Pourquoi pas l’inverse
Un modèle de lecture séparé est une deuxième source de vérité, et une deuxième source de vérité dérive. Garder une seule base signifie qu’une policy est la seule chose entre un client et le reste de l’entreprise, ce qui est exactement la pression qu’elle doit subir. Je les teste en me connectant avec le mauvais compte et en regardant la requête échouer.
Les invariants monétaires sont vérifiés par la base, de façon planifiée
Le total d’une facture doit égaler la somme de ses lignes. La TVA doit correspondre au régime du devis signé. Un paiement ne doit jamais être rapproché d’une facture d’un autre client. Ce sont des contrôles planifiés sur les données réelles, et ils n’alertent que lorsque l’état change — la première fois que c’est faux, et à nouveau quand c’est redevenu juste.
Pourquoi pas l’inverse
Les bugs financiers sont silencieux. Rien ne lève d’erreur ; un chiffre est simplement faux, et le reste jusqu’à ce que quelqu’un recompte à la main. Une alarme qui se déclenche tous les quarts d’heure est coupée en un jour et ne sert plus à rien, donc elle se déclenche sur les transitions.
Chaque rôle a son propre écran, pas une version filtrée d’un seul écran
Le planificateur, l’équipe de chantier, le magasin et le comptable regardent le même projet à travers quatre interfaces différentes. L’application de chantier montre aujourd’hui, cette adresse, ces matériaux, cette photo. Le comptable ne voit jamais une grille de planning.
Pourquoi pas l’inverse
Un écran unique où tout est caché derrière des permissions, c’est exactement ainsi qu’un logiciel d’entreprise devient une chose que les gens évitent. Construire quatre écrans ciblés coûte cher ; un écran que personne ne veut ouvrir coûte plus cher encore, et cela se voit au tableur qui réapparaît sur un bureau.
Déroulement
Comment le travail se passe
- 01
Observer le travail avant de le modéliser
Le modèle de données sort de l’observation d’un dossier qui avance, pas d’un cahier des charges. Les mots que les gens emploient déjà deviennent les noms de tables.
- 02
Mettre une couche en production, de bout en bout
Le devis, du prospect au PDF signé, avant de commencer autre chose. Une couche en production apprend plus en une semaine qu’un trimestre de planification.
- 03
Mettre les règles dans la base de données
Contraintes, policies et contrôles d’invariants, parce que le code applicatif est l’endroit où les règles s’oublient. Si c’est important, ça doit refuser l’écriture.
- 04
Assumer le déploiement et le coup de fil du samedi
L’architecture, les migrations, les déploiements et l’incident sont le même métier. Savoir que c’est vous qu’on réveillera change ce que vous acceptez de livrer.