Le contexte
Une entreprise générale de rénovation — bâtiment, second œuvre et rénovation énergétique — pilotait son activité avec un empilement d'outils génériques : tableurs pour les chantiers, e-mails pour le suivi commercial, documents séparés pour les devis. Le métier impose pourtant un parcours long, et sur une partie des travaux fortement réglementé : un dossier passe par la qualification du prospect, la visite technique, le chiffrage, la réalisation, puis le suivi administratif.
L'objectif était de remplacer cet empilement par un outil unique où chaque dossier avance d'étape en étape, où les commerciaux terrain, les techniciens et l'administration travaillent sur la même donnée, et où les règles de calcul évoluent sans qu'il faille redéployer l'application.
Ce que j'ai construit
Simulateur et gestion des leads
qualification en amont, conversion en client puis en projet, avec historique des actions commerciales.
Visites techniques à formulaires dynamiques
des modèles de formulaires configurables par type de chantier et par corps de métier, remplis sur le terrain, sans développement à chaque nouveau besoin.
Moteur de devis
chiffrage par type de travaux et par corps de métier, avec calcul paramétré des dispositifs d'aide publique pour les chantiers qui y ouvrent droit, et traçabilité de chaque montant.
Chaîne financière
paiements, échéanciers, comptabilité analytique et calcul automatique des commissions par paliers pour les équipes commerciales.
Logistique
produits, stocks multi-dépôts, équipements, véhicules et fournisseurs.
Communication intégrée
messagerie WhatsApp multi-comptes rattachée aux dossiers, notifications temps réel, e-mails transactionnels.
Pilotage
tableaux de bord, exports Excel, génération PDF des documents contractuels, journal d'activité complet.
Architecture & choix techniques
Le back-end est organisé en une trentaine de domaines métier isolés (approche DDD) : chaque domaine — devis, aides, paiements, stock, visite technique — possède ses propres modèles, services et règles. Sur une application aussi large, ce découpage est ce qui permet de faire évoluer la partie « aides publiques » sans risquer de casser la facturation.
J'ai retenu une API hybride GraphQL + REST : GraphQL pour la lecture, parce que les écrans de pilotage ont tous besoin de combinaisons de données différentes et que cela évite de multiplier les endpoints ; REST pour les écritures, où la validation stricte et les effets de bord métier sont plus lisibles et plus faciles à sécuriser.
La persistance est polyglotte : MySQL pour tout ce qui est transactionnel et relationnel (dossiers, paiements, stock), MongoDB pour ce qui est structurellement variable — les réponses aux formulaires dynamiques de visite technique et les journaux d'activité, dont le schéma change selon le modèle de formulaire.
La messagerie WhatsApp est isolée dans un service Node séparé, communiquant avec l'API principale. Une intégration de ce type est instable par nature (sessions, reconnexions) : l'isoler évite qu'une déconnexion n'affecte le CRM lui-même.
Les défis techniques
Des règles réglementaires mouvantes. Les barèmes d'aides changent régulièrement. Les faire vivre dans du code aurait imposé un déploiement à chaque évolution : elles sont donc modélisées comme des données versionnées et paramétrables, avec conservation de l'historique pour que les dossiers anciens restent recalculables à l'identique.
Des formulaires qui se conçoivent sans développeur. Le moteur de visite technique repose sur des modèles de formulaires et un stockage des réponses découplé du schéma — l'ajout d'un type de contrôle ne demande aucune migration de base.
Un modèle de permissions fin. Commerciaux, techniciens, administratifs et direction voient des périmètres différents sur les mêmes dossiers : rôles et permissions granulaires, appliqués côté serveur et reflétés dans l'interface.
Le temps réel sans surcharge. Les notifications passent par une orchestration centralisée via WebSockets, pour éviter que chaque module n'émette ses propres événements de façon incohérente.
Un environnement reproductible. L'ensemble est conteneurisé avec Docker (API, service WhatsApp, files d'attente), ce qui garantit un comportement identique du poste de développement à la production.