Lead Engine

La plupart des commerces locaux, comme un cabinet dentaire, un cabinet d’avocats, un garage ou un club de padel, ont le même problème : un site dépassé, pas de réservation en ligne, une mauvaise expérience mobile, ou pas de site du tout. Ils savent rarement ce que cela leur coûte en clients perdus, et n’ont aucune raison de faire confiance à un démarchage à froid qui ne prouve pas qu’il comprend leur situation.

Pour une agence, le défi est le miroir : trouver ces commerces à grande échelle, dans tous les secteurs intéressants, et les contacter avec quelque chose qui semble étudié plutôt que standardisé, sans passer des heures sur chaque contact.

Lead Engine a été conçu dès le départ pour fonctionner avec n’importe quel secteur : le même moteur qui trouve des cabinets dentaires à Séville trouve des installateurs de climatisation à Madrid ou des cabinets d’avocats à Cordoue, sans autre configuration que la saisie du terme de recherche. Il fonctionne en cinq étapes :

• Découverte : les commerces sont trouvés par catégorie et lieu, en texte libre.
• Audit : une exploration automatique du site et des contrôles de performance évaluent le SEO, la performance et l’accessibilité, et signalent des problèmes concrets comme l’absence de données structurées, de viewport mobile ou des formulaires de contact défectueux.
• Enrichissement des contacts : les e-mails et numéros de téléphone sont extraits du site du commerce, chacun étant évalué selon sa fiabilité et sa source.
• Personnalisation : des messages et des propositions de refonte rédigés par IA font référence aux constats réels de l’audit, et non à du texte générique.
• Prise de contact : e-mail et WhatsApp Business, chacun dans le respect des contraintes réelles de sa plateforme.

Un tableau de bord complet les chapeaute : une liste de leads filtrable avec actions groupées, une fiche détaillée de chaque lead avec ses résultats d’audit et ses sources d’enrichissement, un outil de rédaction de messages et un gestionnaire de liste de suppression.

Cinq décisions ont façonné le produit plus que n’importe quel choix technique.

Concevoir la couche de relecture avant l’automatisation

Avant qu’un message n’atteigne un vrai commerce, quelqu’un doit pouvoir voir ce que le système a trouvé et ce qu’il va dire, et le modifier si c’est faux. Chaque brouillon rédigé par IA s’ouvre modifiable dans la fenêtre d’envoi et n’est jamais envoyé automatiquement ; chaque constat d’audit est affiché avec sa source, pas seulement un score ; chaque contact supprimé est visible et consultable. L’automatisation fait la recherche et le premier brouillon, et l’interface garde un humain dans la boucle.

Un pipeline, pas une liste de fonctionnalités

La prospection comporte cinq étapes distinctes, et chacune demandait sa propre logique tout en restant valable pour tous les secteurs. Je l’ai d’abord traitée comme un problème d’architecture de l’information : ce qui varie selon le secteur (le ton de l’audit, la voix du message, le modèle de refonte) et ce qui ne devrait jamais varier (les critères d’audit, la logique de notation des contacts, les règles de conformité). Cette séparation est devenue une couche de configuration : on saisit n’importe quel type de commerce en texte libre et le système détermine la bonne voix et les bonnes pondérations, sans nouveau code par secteur.

Des preuves, pas du volume

La version facile de ce produit envoie le même message à tout le monde. J’ai conçu la personnalisation selon le principe inverse : chaque message doit citer quelque chose de réel et de précis tiré de l’audit de ce commerce, comme un formulaire de réservation absent, l’absence d’avis affichés ou un site non adapté au mobile. C’est ce qui fait qu’un message à froid est perçu comme étudié et non comme du spam.

La prise de contact comme flux critique pour la sécurité

Toucher de vrais propriétaires de commerces à grande échelle signifie qu’une erreur, comme écrire à quelqu’un qui s’est désinscrit ou dépasser les limites d’une plateforme, coûte de la réputation, pas seulement de la finition. Je l’ai traitée comme la prévention des erreurs dans n’importe quelle interface : la liste de suppression est vérifiée avant chaque canal d’envoi, les plafonds quotidiens sont calculés selon le fuseau horaire local réel et tout doute bloque l’envoi au lieu de le laisser passer. WhatsApp a été conçu autour des règles réelles de Meta : modèles préapprouvés pour le contact à froid, un plafond quotidien réel et une frontière claire entre le premier contact automatisé et le suivi manuel.

Vérifier sur des résultats réels

« Ça a l’air de fonctionner » n’a jamais suffi. Chaque changement non trivial, comme une nouvelle règle d’audit, une migration de base de données ou une modification de la façon dont la configuration d’un secteur est résolue, a été vérifié sur des résultats réels avant que je l’accepte. Cela a permis de détecter des problèmes qui auraient sinon été livrés en silence : des écarts de format dans les prompts générés, un contrôle de conformité qui échouait en mode ouvert plutôt que fermé dans un cas limite, et un incident de production remonté à un pipeline de déploiement qui servait du code périmé après un échec de compilation.

Au-delà du message, le moteur produit des propositions sur mesure pour chaque commerce : une démo personnalisée avec un chatbot IA et une réceptionniste vocale IA, et un concept de refonte du site, tous deux fondés sur les constats de l’audit.

• Un seul moteur qui prospecte n’importe quel secteur de commerce local, vérifié en conditions réelles sur des cabinets dentaires, des cabinets d’avocats, des installateurs de climatisation, des garages et des clubs de sport, sans code par secteur.
• Un tableau de bord qui rend tout le pipeline inspectable et modifiable à chaque étape : découverte, constats d’audit, fiabilité des contacts et brouillons de messages.
• Un pipeline de l’audit au message où chaque texte s’appuie sur des constats réels et précis plutôt que sur du texte générique.
• Une couche de prise de contact conforme par défaut, avec désinscriptions, plafonds de volume et règles par canal intégrés avant le passage à l’échelle, et non ajoutés après un problème.
• Deux canaux de contact opérationnels de bout en bout, chacun conçu autour des contraintes réelles de sa plateforme.

Ce projet se situe à l’intersection qui m’intéresse : le design centré sur l’utilisateur appliqué à un système où l’utilisateur est un propriétaire de commerce qui décide s’il peut faire confiance à un message. Mes réflexes UX n’ont pas changé, à savoir comprendre le vrai problème, concevoir pour les cas limites et vérifier plutôt que supposer, mais le support, lui, a changé. De plus en plus, le travail ne consiste pas seulement à concevoir l’interface, mais à concevoir le système, les garde-fous et la discipline de vérification qui l’entourent.