Claude Code pour la prospection : construire ce qu'aucun outil ne fait
Les outils du marché couvrent 80 % d'un système de prospection. Les 20 % restants sont précisément ce qui distingue votre marché de tous les autres. Cinq développements que nous avons livrés en production, avec la stack exacte : Airscale, Clay, FullEnrich, lemlist, n8n. Et pourquoi aucune plateforme ne les proposait.
Monter un système de prospection avec les outils du marché va vite. Clay ou Airscale pour le sourcing, FullEnrich pour l'enrichissement en cascade, lemlist pour les séquences email, HeyReach pour LinkedIn, Attio ou HubSpot en CRM, et n8n pour relier le tout. En quelques jours, la chaîne tourne.
Puis arrive la demande qui n'entre dans aucune case. Un client de l'industrie veut cibler les entreprises certifiées sur une norme précise : aucune base ne vend ce critère. Un cabinet veut être alerté trois mois avant l'échéance d'un marché public : aucun outil ne calcule cette date. Un dirigeant veut que son CRM se mette à jour après ses appels : les connecteurs standards ne lisent pas une conversation.
À ce moment-là, deux options. Renoncer au critère, donc accepter un ciblage plus large et moins pertinent. Ou écrire le morceau manquant. C'est là que Claude Code entre en jeu, non pas comme un outil de plus dans la stack, mais comme la façon de fabriquer les pièces que la stack ne contient pas, et de faire dialoguer entre elles des briques qui n'ont pas de connecteur officiel.
Un système sur mesure ne se distingue pas par ses outils, qui sont les mêmes pour tout le monde, mais par ce qu'on a écrit entre eux.
Voici cinq cas concrets, avec ce qui bloquait, ce qu'on a construit et ce que ça a changé.
Calculer la date de renouvellement d'un marché public
Le contexte : un client équipe des collectivités. Son meilleur moment pour se positionner n'est pas quand un appel d'offres est publié, c'est trois mois avant, quand l'acheteur commence à préparer la consultation suivante.
Cette information existe, mais nulle part sous forme exploitable. Elle se déduit des avis d'attribution : un marché attribué à telle date, pour une durée donnée, éventuellement reconductible. Il faut lire l'avis, en extraire la durée et les reconductions, calculer l'échéance, puis programmer une alerte en amont.
Aucun outil de prospection ne fait ça. Les plateformes de veille sur les marchés publics signalent les avis publiés, pas les échéances à venir. Nous avons donc écrit le composant : récupération des avis d'attribution sur le BOAMP, extraction structurée de la durée et des conditions de reconduction, calcul de la date de fin, puis mise en file d'attente à J-90 avec le contexte complet du marché. Le résultat repart ensuite dans le circuit standard : enrichissement des décideurs de la collectivité, création de la fiche dans le CRM, et déclenchement de la séquence lemlist au bon moment.
Positionnement au moment de la publication, en concurrence avec tous ceux qui ont vu le même avis, sur un cahier des charges déjà écrit par un autre.
Prise de contact pendant la préparation de la consultation, quand l'acheteur cherche encore comment formuler son besoin.
Ce n'est pas une prouesse technique : c'est de la lecture de texte et un calcul de date. Ce qui est rare, c'est d'avoir compris que c'est cette date-là qui compte, et d'avoir eu le moyen de l'écrire.
Qualifier un industriel à partir de son propre site
Le contexte : un client cherche des industriels français capables d'usiner certaines pièces, avec des certifications précises et un parc machines compatible. Les codes d'activité officiels sont beaucoup trop larges : des milliers d'entreprises partagent le même code sans faire le même métier.
L'information existe pourtant, sur les sites de ces entreprises : la page « nos moyens », la liste des certifications, les secteurs servis, parfois les tolérances annoncées. Mais chaque site la présente différemment, et aucune base ne l'agrège.
Nous avons écrit un composant qui visite le site de chaque entreprise détectée, en extrait le contenu utile, puis pose une série de questions métier définies avec le client : quelles certifications, quels procédés, quels secteurs, quelle taille de série. Les réponses arrivent en champs structurés, directement exploitables pour le scoring et pour la rédaction du message.
Un ciblage sur code d'activité et effectif, avec un tri manuel entreprise par entreprise pour éliminer celles qui ne font pas le bon métier.
Un filtrage automatique sur des critères métier réels, et des accroches qui mentionnent le procédé exact pratiqué par l'entreprise. L'enrichissement des contacts n'intervient qu'après le filtre, ce qui divise la facture par cinq.
Ce composant remplace une tâche que personne n'aurait faite à la main sur plusieurs milliers d'entreprises. Le sur-mesure ne sert pas à faire plus vite, il sert à rendre possible un ciblage qui ne l'était pas.
Mettre le CRM à jour après l'appel
Le contexte : le point de rupture de presque tous les systèmes. La détection fonctionne, les séquences partent, les rendez-vous arrivent. Puis le commercial raccroche et ne saisit rien, parce qu'il enchaîne. Trois semaines plus tard, le pipeline ne reflète plus la réalité et les décisions qui en découlent sont fausses.
Les CRM proposent des intégrations d'enregistrement d'appels, mais elles déposent une transcription brute dans une fiche. Personne ne relit une transcription. Ce qu'il faut, c'est que les informations aillent dans les bons champs : l'étape du deal, les objections soulevées, le budget évoqué, la prochaine action et sa date.
Nous avons écrit le composant qui fait cette traduction : analyse de la transcription, extraction des éléments décidés avec le client, et non ceux d'un modèle générique de vente, puis mise à jour des champs du CRM et création de la tâche de suivi. Le commercial relit et corrige si besoin, ce qui prend trente secondes au lieu de dix minutes.
Des fiches figées à l'étape où elles étaient trois semaines plus tôt, un prévisionnel bâti sur des données périmées.
Un pipeline qui reflète les échanges réels, et un reporting sur lequel on peut fonder des arbitrages.
C'est le développement qui a le plus d'effet et qu'on remarque le moins. Il ne génère aucun rendez-vous supplémentaire : il rend simplement exploitable tout ce que le système produit déjà.
Faire dialoguer Airscale, Clay et FullEnrich sans payer deux fois
Le contexte : chaque outil de sourcing a sa zone de force. Airscale est excellent sur la donnée européenne et les filtres firmographiques, Clay orchestre le croisement de sources et la capture d'engagement, FullEnrich trouve des emails et des mobiles que les autres ratent. Personne ne couvre tout, et payer les trois en parallèle sur les mêmes comptes revient à acheter trois fois la même information.
Le problème est un problème d'ordre, pas d'outil. Enrichir avant de filtrer, c'est brûler des crédits sur des entreprises qu'on écartera de toute façon. Interroger tous les fournisseurs simultanément, c'est payer quatre fois une donnée qu'un seul aurait suffi à trouver.
Nous avons écrit l'orchestrateur qui impose le bon ordre : sourcing large sur Airscale, filtrage sur les critères métier, croisement dans Clay pour ne garder que les comptes qui portent un signal d'achat daté, déduplication contre le CRM, puis enrichissement en cascade seulement sur ce qui reste. FullEnrich n'est appelé que si les fournisseurs précédents n'ont rien trouvé, et le mobile n'est cherché que si le client appelle réellement.
Trois abonnements interrogés en parallèle sur toute la liste, une facture d'enrichissement qui grimpe avec le volume et non avec les résultats.
Un seul appel payant par contact dans la plupart des cas, et un budget d'enrichissement qui suit le nombre de comptes réellement contactés.
Aucun de ces outils ne propose ce chaînage, parce qu'aucun n'a intérêt à ce que vous appeliez ses concurrents en premier. C'est typiquement ce qu'un orchestrateur écrit pour vous peut faire, et qu'une plateforme intégrée ne fera jamais.
Router les envois entre lemlist et LinkedIn selon le signal
Le contexte : tous les signaux ne méritent pas le même canal ni la même urgence. Un décideur qui vient de prendre son poste se contacte sur LinkedIn, où il est actif. Un acheteur public se contacte par email professionnel, avec un objet qui cite la référence du marché. Une entreprise qui a liké un contenu concurrent se traite en quelques jours, une échéance de marché se prépare des semaines à l'avance.
Les séquenceurs gèrent très bien une séquence. Ils ne décident pas quelle séquence lancer, ni quand, en fonction d'un signal détecté ailleurs. C'est une logique de routage, et elle est propre à chaque métier.
Nous avons écrit la couche qui fait cet arbitrage : selon le type de signal, sa fraîcheur, le persona identifié et la disponibilité d'un email vérifié ou d'un profil LinkedIn, le compte part vers la bonne séquence lemlist, vers HeyReach, ou dans la file d'appels avec sa fiche de préparation. Les plafonds d'envoi de chaque canal sont respectés automatiquement, et un compte déjà en cours de séquence ne peut pas en recevoir une deuxième.
Une séquence unique pour tous les comptes, quel que soit le signal, avec des imports manuels depuis un tableur et des doublons entre canaux.
Une accroche par signal et par persona, envoyée sur le canal où le décideur est joignable, sans jamais deux séquences sur le même compte.
C'est le composant qui transforme une détection de signaux en machine de prospection automatisée. Sans lui, on détecte très bien et on envoie très mal, ce qui revient à ne rien détecter du tout.
Quand écrire du code, et quand s'en abstenir
Pouvoir développer une pièce manquante ne veut pas dire qu'il faut le faire. Le sur-mesure a un coût : quelqu'un devra le comprendre et le maintenir. Trois critères nous servent d'arbitrage.
Ce que ça implique pour le client
Un composant sur mesure n'a d'intérêt que si l'entreprise peut le garder. Concrètement : le code lui appartient, il est documenté en français, les prompts sont lisibles et modifiables, et il tourne sur son infrastructure. Sans ça, le sur-mesure devient une dépendance de plus, ce qui est exactement l'inverse du but recherché.
C'est aussi ce qui distingue un système de prospection IA d'un assemblage d'outils : la partie écrite pour vous est celle que personne d'autre n'a, et c'est celle-là qu'il faut pouvoir emporter.
Diagnostic offert · 30 minutes
Questions fréquentes
La possibilité d'écrire les composants qu'aucun outil du marché ne propose : un critère de ciblage qu'aucune base ne vend, un calcul de date que personne ne fournit, une extraction d'informations depuis une source spécifique à un métier. Les outils couvrent la plus grande partie d'un système ; le sur-mesure couvre précisément ce qui distingue un marché des autres.
Pas pour l'utiliser : une fois construit, un composant s'opère depuis l'interface du système comme n'importe quelle autre étape. Pour le faire évoluer en profondeur, oui, d'où l'importance que le code soit documenté et lisible. Dans la pratique, les équipes ajustent les paramètres et les prompts sans toucher au code, ce qui couvre la plupart des besoins.
Trois conditions doivent être réunies : l'information manquante change réellement qui est contacté, aucun outil ne la fournit même imparfaitement, et le résultat produit est vérifiable. Si l'une des trois manque, il vaut mieux utiliser l'existant. Réécrire ce qu'un outil fait déjà correctement crée de la dette technique sans contrepartie.
Oui, et c'est l'usage principal. Ces outils exposent tous une interface de programmation : on écrit le composant qui les appelle dans le bon ordre, applique la logique métier entre deux appels, et pousse le résultat vers le suivant. Concrètement, cela permet de sourcer sur Airscale, filtrer selon des critères qu'aucun outil ne vend, croiser les signaux dans Clay, n'enrichir avec FullEnrich que ce qui a passé le filtre, puis router vers lemlist ou HeyReach selon le canal pertinent.
En imposant le bon ordre des opérations. Filtrer sur les critères métier et dédupliquer contre le CRM avant tout enrichissement, puis interroger les fournisseurs en cascade plutôt qu'en parallèle : le second n'est appelé que si le premier n'a rien trouvé. Chercher un mobile uniquement si l'équipe appelle réellement. Cette logique de chaînage n'est proposée par aucune plateforme, puisque aucune n'a intérêt à ce que ses concurrents soient interrogés en premier.
Au client, sans quoi le sur-mesure devient une dépendance de plus. Concrètement : le code lui est remis, la documentation est rédigée en français, les prompts sont lisibles et modifiables, et l'ensemble tourne sur son infrastructure. C'est la condition pour qu'un composant spécifique reste un actif et non un point de blocage.
Peu, et c'est voulu. L'essentiel repose sur des outils éprouvés pour la donnée, l'enrichissement, les séquences et le CRM. Le sur-mesure intervient sur deux ou trois points précis, ceux où le marché du client impose une logique qui n'existe nulle part ailleurs. Un système majoritairement développé sur mesure est un système coûteux à maintenir.
