LeadPilot est une plateforme SaaS d'automatisation commerciale : import et qualification de prospects, scoring, génération et envoi de campagnes d'emails, suivi des réponses et statistiques. Elle est conçue en architecture multi-tenant : chaque organisation cliente (« tenant ») dispose de son propre espace de données, strictement cloisonné des autres organisations.
L'application repose sur une API backend qui est la seule à porter la logique métier et les décisions sensibles (validation humaine avant envoi, arrêt d'urgence des envois, contrôle des quotas). Un moteur d'automatisation dédié orchestre uniquement le minutage des tâches (déclenchement d'une relance à l'heure prévue, par exemple) ; il ne détient jamais d'identifiants de connexion ni de pouvoir de décision — ceux-ci restent exclusivement dans le backend. Les emails sont envoyés directement via les API officielles des messageries (Gmail, Microsoft 365) du client, pas via un relais SMTP générique tiers : la réputation d'envoi et la propriété des échanges restent celles du domaine du client.
Stack technique : backend Node.js / TypeScript sur le framework NestJS, persistance PostgreSQL via l'ORM TypeORM (isolation renforcée par Row Level Security, cf. §3). L'orchestration des tâches asynchrones et différées (relances programmées, envois par lot, imports) s'appuie sur BullMQ adossé à Redis comme moteur de files de tâches — composant purement technique, sans accès aux identifiants de messagerie ni pouvoir de décision métier. La génération assistée par IA (contenu des emails, scoring qualitatif) s'appuie sur un modèle de langage Mistral, appelé via API, sans conservation des données client par le fournisseur au-delà du traitement de la requête. Le frontend est une application Next.js / React (TypeScript) servie séparément de l'API backend.
L'étanchéité entre organisations clientes repose sur deux mécanismes indépendants et cumulatifs, conçus comme une défense en profondeur :
Un accès transverse (multi-organisations) n'existe que pour un rôle plateforme restreint et fortement audité (cf. §5), jamais pour un compte client standard.
Quatre rôles distincts encadrent les permissions : administrateur d'organisation (gestion complète de son tenant), commercial (usage quotidien), lecteur (consultation seule) et un rôle plateforme réservé à l'éditeur pour la création d'organisations et la supervision technique — ce dernier n'a par ailleurs accès à aucune donnée commerciale (prospects, campagnes) d'une organisation cliente, uniquement à des opérations de gestion de plateforme.
Chaque organisation définit une durée de rétention pour ses prospects (par défaut 3 ans). Un processus automatique quotidien applique cette politique en deux temps :
Ce mécanisme met en œuvre le principe de minimisation des données du RGPD sans intervention manuelle. Le droit à l'effacement peut aussi être exercé à la demande (cf. politique de confidentialité).
Chaque organisation peut exporter l'intégralité de ses données (prospects, campagnes, règles de scoring, historique) dans un package structuré et vérifiable (empreintes cryptographiques par fichier), permettant une migration vers une instance autonome. Les identifiants de connexion aux services tiers ne sont jamais inclus dans cet export : ils doivent être reconnectés manuellement après migration, par principe de sécurité.
L'application est servie exclusivement en HTTPS (certificat TLS renouvelé automatiquement), derrière un reverse proxy. Les composants internes (base de données, files de tâches, moteur d'automatisation) ne sont accessibles que depuis le serveur lui-même, jamais exposés directement sur Internet. Des sauvegardes régulières sont effectuées sur l'ensemble des données de la plateforme.
Pour toute question technique, une demande d'audit de sécurité ou un signalement de vulnérabilité, contactez : [email protected].