Contexte
Le projet devait unifier plusieurs étapes du cycle commercial. L'objectif n'était pas seulement de stocker des contacts, mais de rendre visible tout le fonctionnement de la prospection dans une seule interface.
Le besoin
Le besoin ne se limitait pas à une interface agréable. Il fallait une base unique pour les leads, les pipelines, les échanges commerciaux, les templates d'email, les utilisateurs et les intégrations externes.
La réponse construite
Construction d'un CRM avec vues leads, dashboards, gestion équipe, templates commerciaux et couche API pour relier les autres briques de prospection et d'enrichissement.
Ce que ce projet montre concrètement
Ce CRM rend le suivi commercial plus lisible, centralise les leads et relie les principaux flux utiles à la prospection.
Fonctions clés
Interconnexions
Ce que cela change
Ce qui était dur, ce qu'on a tranché
Enjeux techniques
- Centraliser des données dispersées (Google Sheets, Notion, mails, exports CSV) sans tout casser pendant la migration
- Modéliser un pipeline qui s'adapte à plusieurs métiers sans devenir une usine à gaz
- Construire un reporting fiable en temps quasi-réel sans dépendre d'un BI externe payant
- Gérer les permissions par équipe, par rôle et par scope sans bloquer la productivité quotidienne
- Stocker l'historique complet des interactions tout en gardant des écrans rapides à charger
Choix de stack
- Next.js + TypeScript
Front et back dans le même repo, déploiement simple, partage des types entre client et serveur. Idéal pour un outil interne qui doit évoluer vite.
- Postgres + Prisma
Relations complexes (lead, deal, activité, user), requêtes analytiques propres, migrations traçables. Pas de souci de scalabilité à notre volume.
- BullMQ + Redis
Toutes les actions lourdes (exports, sync, envois d'emails groupés) tournent en background sans freiner l'interface.
- Resend pour les emails
API simple, deliverability propre, prix linéaire. Plus léger qu'un SES à configurer, plus honnête qu'un Sendgrid à gérer.
- Hébergement sur notre datacenter
Données commerciales sensibles, RGPD strict, contrôle total des coûts et de la sécurité. Pas de surprise sur la facture cloud.
Difficultés rencontrées
Le pipeline change selon le métier
Notre première tentative était trop rigide. On a refondu le modèle pour que chaque équipe puisse définir ses propres étapes sans toucher au code, ni dupliquer les vues.
Garder un reporting nerveux à 10K leads
Les requêtes naïves explosaient en latence dès qu'on dépassait quelques milliers de lignes. On a indexé finement Postgres et préagrégé les métriques clés via des cron jobs Node.
Templates d'email sans devenir un Sendgrid bis
On voulait des variables dynamiques, du tracking ouverture/clic et un envoi propre, sans intégrer une grosse plateforme marketing. Resend + composeurs custom ont fait le job.
Synchroniser sans perdre les conflits
Quand deux commerciaux modifient le même lead en même temps, il fallait éviter l'écrasement silencieux. On a ajouté du versioning optimiste avec résolution manuelle si besoin.
Ce qu'on a appris
- Commencer par les vues utilisateur, pas par le modèle de données. Sinon on conçoit une base que personne ne sait exploiter.
- Un reporting natif à l'outil > un Looker à côté. Si c'est dans l'écran de travail, l'équipe l'utilise vraiment.
- Stocker tout ce qui peut s'historiser. La donnée non collectée aujourd'hui ne se rattrape jamais.
- Les templates d'email doivent rester éditables par les commerciaux, pas verrouillés dans le code.
Quelques vues utiles pour voir comment le projet se présente concrètement.