De quelques clients pilotes à plusieurs centaines de clients payants, sans que la production ne cède
- Client
- SaaS de gestion immobilière, Québec (nom anonymisé à la demande du client)
- Mission
- En cours depuis plusieurs années, 2 à 3 jours par semaine
- Stack
- Angular, NestJS, MySQL, monorepo
Quand j'ai commencé sur ce produit, il comptait quelques clients pilotes. Aujourd'hui il en a plusieurs centaines, et le produit tient : l'encaissement ne s'effondre pas quand le volume grandit, les documents générés engagent l'entreprise, et la production ne casse plus sans que personne ne le sache. Rien de tout cela n'existait au début. Voici comment ça s'est construit.
Encaisser.
Le problème : chaque facture partait par email, chaque paiement se suivait dans un tableau. Ça tenait à un client. Pas à dix, encore moins à cent.
La décision : construire la chaîne d'encaissement sur une solution de paiement, de la facturation récurrente au rapprochement des paiements, directement dans le produit.
Le résultat : l'encaissement suit la croissance sans intervention manuelle. Le produit est passé de quelques clients pilotes à plusieurs centaines de clients payants sans que cette chaîne devienne le goulot d'étranglement.
Le document légal.
Le problème : ces documents étaient produits par les experts métier à partir d'un template rempli à la main, un par un. Un processus manuel répété à chaque document, à sécuriser à mesure que le volume augmente.
La décision : générer ces documents directement à partir des données du produit, avec la mise en forme et les mentions imposées par le système plutôt que laissées à la saisie.
Le résultat : les documents se génèrent de façon identique et reproductible, à n'importe quel volume, sans étape manuelle à sécuriser.
Le calcul qui ne peut plus diverger.
Le problème : la logique de calcul — prévoyance, projections, scénarios — était implémentée à plusieurs endroits du code, côté serveur comme côté client. Deux implémentations séparées d'une même règle, qu'il faut maintenir rigoureusement synchronisées pour qu'elles restent d'accord.
La décision : réunir cette logique dans un paquet unique, au sein d'un monorepo, consommé aussi bien par les écrans que par la génération de documents. Une seule implémentation, une seule source de vérité.
Le résultat : la question de la cohérence entre deux calculs ne se pose plus — il n'y a plus qu'un calcul. Ce que voit l'utilisateur à l'écran et ce que porte le document reposent sur le même code.
Savoir quand c'est cassé.
Le problème : un grand nombre d'alertes de production actives, mélangeant erreurs réelles et écarts de règles métier attendus. Assez de bruit pour que plus personne ne les regarde vraiment, et pour que les vraies erreurs se perdent dans le lot.
La décision : revoir chaque alerte une par une — la garder si elle signale un problème réel et actionnable, la supprimer ou la fusionner sinon.
Le résultat : le volume d'alertes réduit de moitié. Moins de bruit, plus de signal — quand quelque chose sonne, ça veut dire quelque chose.
En résumé
Rien de ce chantier n'est visible pour un utilisateur du produit. C'est précisément le but : le produit devient plus fiable sans jamais changer de visage. C'est ce travail-là, plus que les nouvelles fonctionnalités, qui a permis au produit d'absorber une croissance de quelques clients pilotes à plusieurs centaines de clients payants sans jamais revenir en arrière.
Angular en frontend, NestJS en backend, MySQL, le tout dans un monorepo unique pour partager la logique métier.