Un manuel pour savoir exactement de quoi tu parles quand un client te demande "comment t'as fait tout ça". Pas de jargon, des analogies simples, mais on couvre vraiment tout.
Quand tu tapes prospecthunter.vercel.app dans Chrome et que tu appuies sur Entrée, voilà ce qui se passe en réalité :
Ton navigateur (Chrome, Safari, Firefox) envoie une lettre à un ordinateur quelque part dans un data-center, en disant "salut, donne-moi la page d'accueil de prospecthunter". Cet ordinateur lointain reçoit la lettre, prépare une réponse (un fichier HTML, des images, du code), et la renvoie. Ton navigateur reçoit la réponse, la lit, et l'affiche à l'écran.
Imagine que tu commandes une pizza. Toi (le client) tu appelles le resto. Le resto reçoit ta commande, le cuisinier prépare la pizza dans la cuisine, le serveur te la livre. Le navigateur c'est toi, l'ordinateur lointain c'est le resto, et la pizza c'est la page web.
Un site web simple, c'est juste 3 fichiers :
Mais Empire Leads c'est pas un simple site, c'est une application web (une "web app" ou un "SaaS"). La différence : il y a aussi un cerveau côté serveur qui mémorise des trucs (qui est connecté, quels prospects appartiennent à qui, etc.), et une base de données qui stocke tout. C'est le sujet des chapitres suivants.
Toute application web repose sur 3 acteurs qui se passent des messages.
C'est ce que ton utilisateur voit. Les boutons, les listes de prospects, les formulaires. Tout ce qui s'affiche dans Chrome ou Safari sur le téléphone. Le frontend tourne sur l'ordinateur de l'utilisateur.
C'est le programme qui tourne sur un serveur dans un data-center. Quand l'utilisateur clique "Logger un appel", le frontend envoie un message au backend ("hé, ajoute cet appel"), et le backend traite la demande, sauvegarde dans la base, et répond "OK c'est fait".
C'est l'endroit où on stocke tout ce qui doit être conservé : les comptes utilisateurs, les prospects, les notes, les appels, les rendez-vous. Elle vit aussi dans un data-center, séparée du backend.
Parce que ça permet de scaler (grossir). Si t'as 10 000 utilisateurs en même temps, tu peux mettre plusieurs backends en parallèle qui partagent la même base. Et si tu changes le frontend, tu touches pas à la base. C'est l'architecture standard de tous les SaaS du monde.
Empire Leads, le frontend c'est essentiellement un seul gros fichier JavaScript qui s'appelle app.js (presque 4000 lignes), accompagné d'un index.html et d'un style.css.
Quand tu vas sur /app, ton navigateur télécharge ces 3 fichiers et les exécute localement. À partir de là, tout se passe dans ton navigateur : les filtres, les changements de stage, l'affichage des cartes prospects, les animations. C'est ce qu'on appelle un SPA (Single Page Application — application à une seule page) : la page ne se recharge jamais, elle se met à jour dynamiquement.
Quand tu cliques sur un bouton, le JavaScript fait ce qu'on appelle un fetch (= aller chercher quelque chose). C'est exactement comme envoyer un SMS au backend :
Traduction : "Hé serveur, donne-moi la liste de mes prospects." Le serveur répond avec un fichier JSON (un format de données standard, lisible par les humains et les machines), et le frontend affiche les prospects à l'écran.
C'est juste une façon d'écrire des données, comme une recette de cuisine structurée. Exemple :
{ "name": "Plombier Dupont", "phone": "0612345678", "stage": "cold_call" }
C'est le langage universel pour échanger des données entre 2 programmes sur Internet.
Frontend en HTML/CSS/JavaScript "vanilla" (= sans framework). Pas de React, pas de Vue, pas d'Angular. Juste du JavaScript pur. C'est plus rapide à charger et plus simple à maintenir. La plupart des SaaS modernes utilisent React (avec lequel ils se compliquent souvent la vie pour rien). Empire Leads prouve qu'on peut faire un vrai SaaS sans tout ça.
Le backend d'Empire Leads tourne sur Node.js. Node.js c'est un programme qui sait exécuter du JavaScript en dehors d'un navigateur — sur un serveur. C'est un peu magique : la même langue (JavaScript) peut tourner côté navigateur ET côté serveur.
Pour gérer les requêtes qui arrivent (les "lettres" qu'envoie le frontend), on utilise une bibliothèque qui s'appelle Express. Express c'est comme un facteur intelligent : il reçoit les lettres, les trie selon leur destination (l'URL demandée), et appelle le bon code pour répondre.
Quand le frontend envoie GET /api/prospects, Express regarde dans son carnet d'adresses :
Et exécute le code correspondant : "va chercher les prospects de cet utilisateur dans la base, et renvoie-les en JSON."
Le backend est organisé en fichiers de routes, chacun gérant un domaine :
Chaque route est une "porte d'entrée" sur le serveur. Le frontend tape à la porte avec une URL, et le backend exécute le code derrière la porte.
Le backend c'est ta maison. Les routes c'est les portes (porte cuisine, porte salon, porte garage). Le facteur (Express) reçoit les colis et sait dans quelle pièce les déposer. Chaque pièce sait quoi faire avec ce qu'elle reçoit.
La base de données c'est l'endroit où on stocke toutes les infos qui doivent survivre entre les sessions. Si on stockait les prospects en mémoire dans le backend, dès qu'on redémarre le serveur tout serait perdu. La base de données, elle, garde tout sur disque, en permanence.
Empire Leads utilise PostgreSQL (= "Postgres"), hébergé chez Supabase. PostgreSQL c'est une base de données relationnelle : les données sont organisées en tables (comme un tableau Excel géant).
Avec un langage qui s'appelle SQL (Structured Query Language). C'est comme un anglais simplifié pour donner des ordres à la base.
Traduction : "Donne-moi tous les prospects dont l'utilisateur est le numéro 42." La base répond avec une liste de lignes.
La base de données c'est une bibliothèque géante. Chaque table c'est un rayon (rayon "Utilisateurs", rayon "Prospects"). Chaque livre c'est une ligne. Le bibliothécaire (le moteur SQL) sait retrouver n'importe quel livre en quelques millisecondes, même s'il y en a 10 millions.
Supabase c'est un service qui héberge ta base PostgreSQL pour toi (sans que tu aies à gérer un serveur). Tu paies un abonnement, ils s'occupent de la sauvegarde, de la sécurité, des backups. C'est plus pratique que de monter ton propre serveur PostgreSQL. Concurrent direct : Firebase de Google.
Comment Empire Leads sait qui tu es ? Et comment il empêche un utilisateur de voir les prospects d'un autre ?
Quand un user s'inscrit, il donne un email + un mot de passe. On ne stocke JAMAIS le mot de passe en clair. À la place, on utilise une bibliothèque qui s'appelle bcrypt qui transforme "monpassword123" en quelque chose comme :
C'est ce qu'on appelle un hash. La particularité : c'est impossible de retrouver le mot de passe original à partir du hash. Mais on peut vérifier qu'un mot de passe donné correspond à un hash existant. C'est ça qui rend les comptes sécurisés.
Si demain un hacker pirate la base de données d'Empire Leads, il verra des hashes inutilisables. Il ne pourra pas se connecter aux comptes. C'est la norme légale aujourd'hui : si tu stockes des mots de passe en clair et qu'il y a un leak, tu es responsable juridiquement.
Quand l'user revient et tape son mot de passe, on prend le mot de passe entré, on le passe dans bcrypt, et on compare au hash stocké. Si ça matche, on génère un JWT.
JWT = JSON Web Token. C'est une carte d'identité numérique qu'on donne au navigateur du user après login. Cette carte contient son ID, son email, et la date d'expiration (genre 7 jours). Elle est signée cryptographiquement avec un secret que seul le serveur connaît.
À chaque requête que le frontend envoie au backend, il rajoute cette carte dans le header. Le backend vérifie la signature ("ce token a bien été émis par moi, il y a moins de 7 jours") et identifie l'user.
Quand tu rentres dans un festival, on te met un bracelet (= JWT). À chaque scène, le videur regarde ton bracelet et sait que t'es OK pour entrer. Pas besoin de redonner ta carte d'identité à chaque fois. Le bracelet expire à la fin du festival.
API = Application Programming Interface. C'est juste un mot compliqué pour dire : une porte standardisée qu'un service ouvre pour qu'un autre programme puisse lui parler.
Empire Leads parle à plusieurs APIs externes pour faire son boulot :
Chaque API te donne une clé secrète (une longue chaîne de caractères) quand tu crées un compte. Quand ton backend veut appeler l'API, il envoie une requête HTTP avec sa clé en pièce jointe. L'API vérifie la clé, exécute la demande, et te renvoie les données.
Exemple — quand tu fais une recherche "restaurants à Lyon" :
Tout ça en quelques secondes. C'est la magie d'un SaaS : tu enchaînes les services existants pour créer une expérience unique.
Chaque appel API a un coût. Google Places c'est ~5$ pour 1000 recherches. Hunter.io c'est ~50€/mois pour 500 emails. Claude c'est ~3$ par million de tokens. C'est pour ça que tu factures à l'utilisateur en "crédits" ou en abonnement : tu refactures les coûts API + ta marge.
Le scraping c'est l'art de récupérer automatiquement des données depuis Internet. Il y a 2 manières :
Quand un site (Google, Pappers, Hunter, etc.) permet aux développeurs de récupérer ses données via une API. C'est légal, propre, fiable. Mais ça coûte. C'est ce qu'Empire Leads utilise pour Google Maps, Pappers, Hunter.
Quand un site n'offre pas d'API et que tu veux quand même ses données. Tu programmes un robot qui visite les pages comme un humain, lit le HTML, et extrait les infos. C'est plus "gris" légalement et techniquement plus fragile (si le site change son design, ton scraper casse).
Empire Leads utilise un peu de scraping fallback dans services/emailFinder.js : si Hunter.io trouve rien, le code visite directement le site de l'entreprise (page contact, page mentions légales) et cherche des emails dans le HTML avec des patterns regex.
Récupérer des données publiques (un email affiché sur un site) c'est légal. Forcer une connexion, scraper des données privées, contourner des protections : c'est illégal. Empire Leads reste dans la zone légale parce qu'il utilise uniquement les APIs officielles + du scraping de pages publiques.
Quand l'utilisateur cherche "plombier à Lyon", Empire Leads appelle l'API Google Places. Google renvoie une liste de fiches d'entreprises avec : nom, adresse, téléphone, site web, note et avis. Tout ce qu'il y a sur Google Maps en gros.
L'astuce d'Empire Leads : on combine Google Places avec un check supplémentaire "a-t-il un site web ?". Si non, c'est un prospect en or pour une agence web. C'est le mode "Sans site" qui fait toute la valeur du SaaS.
Quand l'utilisateur clique "Générer un pitch", voilà ce qui se passe :
C'est ça la "magie" de l'IA dans un SaaS aujourd'hui : tu prends une API d'IA générative (Anthropic, OpenAI, Google), tu lui donnes un contexte précis sur ce que tu veux, et elle te renvoie du texte de qualité en temps réel.
C'est pas l'IA qui est magique, c'est le prompt. Un bon SaaS d'IA, c'est juste un SaaS qui a optimisé ses prompts à mort. Empire Leads adapte le prompt selon le type (appel/email/sms/dm), la niche, et les signaux du prospect. Plus le prompt est précis, plus la sortie est bonne.
Coût pour toi : quelques centimes par pitch. Tu peux facturer ça en "crédits" ou inclure dans l'abonnement.
Le bookmarklet Instagram Finder, c'est un truc spécial. C'est un favori dans le navigateur, mais au lieu d'ouvrir un site, il exécute du code JavaScript dans la page où tu es.
Instagram n'a pas d'API officielle gratuite pour récupérer les commentateurs/followers d'un profil. Mais quand tu navigues sur instagram.com, ton navigateur appelle des URLs internes (les "API privées" d'Instagram) pour charger les données. Le bookmarklet, en s'exécutant directement dans la page Instagram, peut utiliser ta session connectée pour appeler ces mêmes URLs.
Concrètement : tu cliques le favori, le code s'exécute dans la page Instagram, il appelle https://www.instagram.com/api/v1/feed/user/USERID/ avec tes cookies de connexion, Instagram lui renvoie les posts, puis pour chaque post il appelle /api/v1/media/POSTID/comments/, récupère tous les commentateurs, dédoublonne, et affiche tout dans une overlay sur la page.
Aucun mot de passe n'est volé. Aucune donnée ne passe par le serveur d'Empire Leads. Tout reste entre l'utilisateur, son navigateur et Instagram. Comme c'est l'utilisateur qui exécute lui-même le code dans son propre navigateur connecté, Instagram pense que c'est une activité normale (au début — jusqu'à ce qu'il détecte un volume anormal).
Si tu fais 500 appels API en 30 secondes, Instagram comprend que c'est pas humain et te bloque temporairement (rate limit). C'est pour ça que le bookmarklet a un anti-ban : pauses entre les requêtes, throttling automatique, etc.
Et c'est pour ça qu'on a désactivé l'envoi automatique de DM via API : ça te ban garanti en 5 minutes.
Stripe c'est un service de paiement utilisé par 99% des SaaS modernes (et beaucoup de e-commerces). Tu connectes ton compte bancaire à Stripe, et Stripe gère pour toi : la collecte de la carte bleue, la sécurité, les abonnements récurrents, les remboursements, les factures.
Comment ça marche pour Empire Leads :
C'est l'inverse d'un appel API normal. Au lieu que toi tu demandes des infos à un service, c'est le service qui te notifie automatiquement quand un événement se produit. Stripe te notifie : "paiement réussi", "paiement échoué", "abonnement annulé", etc.
Côté Empire Leads, il y a un fichier routes/stripeWebhook.js qui écoute ces notifications. Important : on vérifie la signature de chaque webhook avec une clé secrète Stripe pour être sûr que c'est vraiment Stripe qui appelle (pas un hacker qui essaie de hacker pour activer un compte premium gratos).
Parce que c'est extrêmement compliqué et ultra réglementé (PCI DSS, RGPD, conformité bancaire, etc.). Stripe prend 1.4% + 0.25€ par transaction et fait absolument tout pour toi. Tous les SaaS sérieux passent par Stripe (ou son concurrent direct, Adyen / Paddle).
Une fois que ton code est écrit, comment ça arrive sur Internet pour que les gens puissent l'utiliser ?
C'est ce qu'on appelle le déploiement. Tu prends ton code (qui vit sur ton ordi à C:/i1/exemple-fix), et tu l'envoies sur un service qui va l'héberger et le rendre accessible 24/7 depuis n'importe où dans le monde.
Vercel c'est un service d'hébergement spécialisé pour les apps web Node.js. Quand tu fais npx vercel --prod --yes depuis ton dossier, voilà ce qui se passe :
L'avantage : tu n'as aucun serveur à gérer toi-même. Pas de Linux, pas de mises à jour de sécurité, pas de redémarrage. Vercel s'occupe de tout.
Si tu veux que ton SaaS soit accessible sur un nom de domaine personnalisé (genre empire-leads.fr au lieu de prospecthunter.vercel.app), tu achètes le nom de domaine chez un registrar (OVH, Namecheap, Gandi), tu configures le DNS pour pointer vers Vercel, et hop : ton site est accessible sur ton domaine en 5-10 minutes.
Le DNS c'est l'annuaire d'Internet. Quand quelqu'un tape empire-leads.fr, son navigateur demande au DNS "c'est quelle adresse IP ce nom ?" Le DNS répond avec une IP genre 76.76.21.21. Puis le navigateur va chercher le site à cette IP. C'est totalement invisible pour l'utilisateur, mais c'est la mécanique de base d'Internet.
Multi-tenant = plusieurs locataires (= utilisateurs) qui partagent le même immeuble (= serveur + base) mais qui ont chacun leur propre appartement (= leur propre data isolée).
C'est la mécanique fondamentale d'un SaaS : 1 seul code, 1 seule base de données, mais chaque user voit seulement ses propres données.
Toutes les tables de la base ont une colonne user_id. Quand un user crée un prospect, on enregistre user_id = 42. Quand le user demande la liste de ses prospects, le backend filtre :
Comme ça, l'user 42 voit JAMAIS les prospects de l'user 17. Et inversement.
C'est aussi simple que ça. Et c'est la base de tous les SaaS B2B du monde.
Imagine un immeuble Airbnb. Tous les locataires partagent le même bâtiment, le même ascenseur, la même connexion fibre. Mais chacun a la clé de SON appartement et ne peut pas entrer dans les autres. Le multi-tenant c'est exactement ça en version software : 1 seul backend, 1 seule database, mais chaque user a une clé qui lui donne accès uniquement à son périmètre.
Dans le cas des clones white-label (Prospecto, et LBD pour Luxurybrands.digital), on va plus loin : chaque client agence a sa propre base de données complètement séparée (Supabase séparé) ET son propre backend (projet Vercel séparé). C'est ce qu'on appelle du multi-instance au lieu du multi-tenant. C'est plus cher mais c'est plus rassurant pour les clients premium qui veulent leur propre univers.
Maintenant tu as toutes les pièces. Voilà comment elles s'emboîtent :
C'est ça, Empire Leads. Tout ça a été construit pour résoudre UN seul problème : trouver des entreprises qui ont besoin d'un site web (ou de réseaux sociaux), les contacter intelligemment, et les transformer en clients. Tout le reste c'est de la plomberie technique pour servir cet objectif.
C'est la combinaison de ces 6 points qui fait qu'Empire Leads existe. Aucun concurrent ne fait exactement les 6.
"Empire Leads est une plateforme de prospection B2B française qui combine scraping automatisé, IA générative, et un CRM intégré. On s'adresse aux indépendants et petites agences qui veulent trouver des clients dans leur ville sans payer 500€/mois pour un Apollo ou un Lemlist. On a notre propre stack tech, on possède notre infra, et on propose des plateformes white-label aux agences qui veulent leur outil maison."