Documentation technique

1. Vue d'ensemble

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.

2. Architecture générale

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.

3. Isolation multi-tenant (double protection)

L'étanchéité entre organisations clientes repose sur deux mécanismes indépendants et cumulatifs, conçus comme une défense en profondeur :

• Filtrage applicatif : chaque service métier du backend n'opère jamais que sur les données de l'organisation de l'utilisateur authentifié.
• Isolation au niveau base de données (Row Level Security PostgreSQL) : même en cas d'erreur de programmation dans une requête applicative, la base de données elle-même refuse de renvoyer ou d'écrire une ligne n'appartenant pas à l'organisation courante. Ce filtre est appliqué en mode « fail-closed » : en l'absence de contexte d'organisation explicitement posé, l'accès est refusé par défaut plutôt qu'autorisé par défaut.

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.

4. Authentification et secrets

• Authentification par jetons (access + refresh), mots de passe hachés avec un algorithme dédié résistant au brute-force (Argon2), jamais stockés ni journalisés en clair.
• Les identifiants de connexion aux services tiers (CRM, messagerie, sources de prospection) sont chiffrés au repos (AES-256-GCM) avec une clé de chiffrement dédiée, distincte du code source et de la base de données. Ces identifiants ne sont jamais exposés en clair dans l'interface ni dans les journaux applicatifs.
• Les mots de passe et secrets sont explicitement exclus des réponses de l'API, vérifié par des tests automatisés.

5. Contrôle d'accès par rôles

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.

6. Garde-fous sur l'envoi d'emails

• Validation humaine obligatoire avant tout envoi commercial généré par IA.
• Quota d'envoi quotidien configurable par organisation, plafonné globalement au niveau de la plateforme.
• Mécanisme d'arrêt d'urgence (« coupe-circuit ») vérifié individuellement à chaque envoi, permettant de stopper instantanément tous les envois en cours en cas d'incident, indépendamment de l'état de chaque campagne.
• Chaque action sensible (création de compte, envoi, arrêt d'urgence, suppression) est tracée dans un journal d'audit horodaté.

7. RGPD et rétention des données

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 :

• un prospect inactif depuis plus longtemps que la durée de rétention configurée est d'abord marqué comme supprimé (état réversible, disparaît des usages normaux) ;
• après un délai de grâce supplémentaire de 30 jours (permettant de corriger une erreur de configuration ou de traiter une réclamation), il est supprimé physiquement et définitivement de la base, avec trace anonymisée dans le journal d'audit.

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é).

8. Portabilité et export

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é.

9. Infrastructure

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.

10. Contact

Pour toute question technique, une demande d'audit de sécurité ou un signalement de vulnérabilité, contactez : [email protected].