JRM.ai
B2B Scout.

---
name: jrm.ai-b2b-scout
description: Préparer une prospection B2B de magasins physiques en France, qualifier les points de vente, organiser une tournée et livrer listing, reporting et fichiers My Maps dans Google Drive, avec reporting complet par Gmail si demandé. Utiliser pour rechercher des revendeurs ou préparer les visites d'un commercial.
---

# JRM.AI · B2B Scout

Transformer une zone et une offre commerciale en prospects vérifiés et en tournée praticable. Répondre en français sauf demande contraire. Adapter le secteur : bijouterie, mode, optique, décoration, beauté, alimentation, etc. Le bijou est un exemple, pas un filtre permanent.

## Cadrer sans ralentir

Reprendre les informations déjà données. Demander uniquement ce qui bloque : offre/secteur, ville ou rayon, date exacte, créneau, départ/arrivée et mode de déplacement. Pour une simple liste, date et trajet sont inutiles. Pour une tournée, proposer 20 minutes par visite si aucune durée n'est fournie, en indiquant cette hypothèse. Résoudre « mardi » en date calendaire à partir de la date locale du client.

Clarifier si nécessaire indépendants/franchisés/chaînes, décideur local ou centrale, et intérêt pour les commerces multiactivités. Distinguer magasins repérés et visites réalisables.

La livraison par défaut se fait dans un dossier Google Drive contenant le listing et le reporting, puis les fichiers de carte si demandés. Le corps du mail contient le reporting complet : planning chronologique, adresses, navigation, qualification des magasins, sources datées, informations financières disponibles, hypothèses et points à vérifier. Le lien du dossier complète ce contenu, sans pièces jointes. Respecter un choix explicite de livraison locale ou un autre format demandé par l'utilisateur.

Au démarrage, recueillir les choix manquants en une fois : carte à importer dans Google My Maps, notification email et destinataire. Ne pas redemander les choix ou l'adresse déjà donnés. Un refus de carte n'empêche pas la livraison du listing. Si seul un brouillon est demandé, ne pas envoyer de mail.

Conserver les choix dans le dossier d'exécution, jamais dans le skill partagé. Vérifier dès le départ Google Drive (compte, création de dossier, téléversement de fichiers et accès du destinataire) et, si l'envoi est demandé, Gmail (compte et envoi d'un message simple sans pièces jointes). La capacité de joindre des fichiers à Gmail n'est pas un prérequis pour ce mode. Signaler un blocage sans interrompre les recherches indépendantes. Une demande explicite d'envoi final avec destinataire déterminé autorise l'envoi après vérification du dépôt et des accès, sans nouvelle confirmation.

## Automatiser les étapes répétitives

Privilégier [automation.md](references/automation.md) et `scripts/run_scout.py` : `collect` recherche une commune ou un département et prépare les vérifications ; `build` enchaîne matrice IGN, planning, rapport, exports et plan de livraison. `scripts/apply_qualifications.py` fusionne seulement les enrichissements sourcés. Ne pas réécrire ces traitements, recalculer les totaux à la main ni reconstituer les CSV/HTML dans le chat. Codex garde les appels MCP, les vérifications web, les choix commerciaux et les opérations Google via leurs connecteurs.

Les [contrôles et la reprise](references/controls-and-resume.md) sont intégrés : `collect` propose des secteurs et un ordre de vérification, `build` bloque les données incomplètes avant IGN. Reporter la limite de présélection du prompt dans `geography.limit` et renseigner les coordonnées du départ. La présélection géographique ne vaut pas qualification commerciale. Avant livraison et après une interruption, utiliser `reconcile_delivery.py` sur les observations Google réelles, reprendre uniquement les fichiers dont l'absence est établie, puis journaliser la tentative avec `begin-email` avant l'appel Gmail. Utiliser le statut de contrôle le plus récent ; ne jamais réinitialiser un état d'envoi ambigu pour forcer un renvoi.

Chaque **nouvelle exécution de livraison demandée par l’utilisateur** constitue une livraison distincte : créer un nouveau dossier d’exécution, un nouveau `delivery_id` et, après dépôt et contrôles, envoyer un nouveau mail au destinataire demandé. Un statut `sent` ou `do_not_resend` d’une exécution antérieure ne supprime jamais cette notification. La prévention des doublons reste stricte à l’intérieur d’un même `delivery_id` ou d’une tentative ambiguë ; elle ne doit pas bloquer une nouvelle exécution explicitement demandée.

## Trouver puis qualifier

Lire [sources.md](references/sources.md) pour les sources françaises et leurs limites. Privilégier le MCP officiel data.gouv.fr lorsqu'il est disponible pour identifier les sources publiques et consulter leurs métadonnées et spécifications. L'API publique permet ensuite de collecter les établissements.

Si le prompt exige le MCP data.gouv.fr, effectuer réellement les appels MCP utiles avant la collecte : rechercher le service pertinent, consulter sa fiche et sa spécification si nécessaire. Ne pas remplacer silencieusement cette étape par un accès HTTP direct. Si le MCP est absent ou en échec, signaler le blocage et la configuration nécessaire avant de poursuivre cette recherche. Mentionner séparément le rôle du MCP (découverte/documentation), de l'API (collecte), du web (qualification) et d'IGN (trajets), avec les sources et outils réellement utilisés. Sans exigence explicite de MCP, l'accès direct reste possible en indiquant ce choix. Ne pas modifier la configuration du client sans demande d'installation.

1. Rechercher les établissements par commune ou département et activités pertinentes, puis compléter par noms commerciaux et recherche web locale. Le NAF ne prouve ni l'assortiment ni l'existence d'une boutique ouverte au public.
2. `scripts/search_establishments.py` accepte `--commune` ou `--department` et effectue une collecte administrative paginée et dédoublonnée par SIRET. Lire ses avertissements ; ses résultats sont des candidats à vérifier.
3. Vérifier les candidats retenus avec leur site officiel, page de magasin ou fiche cartographique à jour : adresse de visite, offre, statut physique, horaires pour la date, contact professionnel public, autonomie d'achat. Conserver URL et date de consultation. Séparer fait sourcé et déduction ; ne pas inventer contact, horaire, SIRET ou rapprochement enseigne/société.
4. Écarter du parcours sièges sans magasin, commerces fermés, doublons et activités incompatibles. Garder les incertains à part avec la vérification à effectuer. Un SIRET actif ne prouve pas l'ouverture au public.

Pour des bijoux fantaisie, envisager aussi accessoires, concept stores et mode dont l'assortiment est confirmé. Expliquer l'accessibilité commerciale des enseignes nationales sans supposer leur organisation d'achat.

Si une qualification financière est demandée, utiliser les données publiques datées au niveau SIREN : CA, résultat et exercice lorsque disponibles ; BODACC et évolution des procédures. Le CA de l'entreprise n'est pas celui de chaque magasin. Données absentes/confidentielles ≠ mauvaise santé ; absence d'annonce ≠ garantie de solvabilité. Ne pas inventer un score de crédit. Séparer adéquation commerciale, signaux financiers et confiance dans les informations.

## Construire la tournée

Lire [tournee-et-exports.md](references/tournee-et-exports.md). Utiliser un vrai moteur routier et conserver provenance, mode, date de récupération et hypothèses trafic. Ne pas présenter une distance à vol d'oiseau comme durée routière, ni un lien Google Maps comme preuve d'optimisation.

Tenir compte des ouvertures, fermeture déjeuner, durée de visite, parking/marche, pause, départ et retour. En centre-ville, proposer une boucle à pied depuis un parking si pertinent. Expliciter le compromis couverture/pertinence/temps si tous les candidats ne rentrent pas.

Pour la France, `scripts/fetch_ign_matrix.py` collecte sans clé les durées IGN Géoplateforme entre les coordonnées vérifiées des points sélectionnés, à pied ou en voiture. Les durées sont théoriques, sans trafic temps réel ni stationnement. Vérifier le raccordement des coordonnées aux entrées des boutiques. Le script conserve les requêtes et la version du réseau pour audit.

`scripts/plan_tour.py` calcule l'ordre donnant le retour le plus tôt, sous une matrice de durées fixes et des fenêtres horaires, pour 12 visites au maximum. Il ne collecte pas cette matrice. L'utiliser après avoir obtenu des durées sourcées et vérifié boutiques et horaires. Configurer `planning.lunch` pour une pause fixe à un lieu explicite, `parking_minutes` et `travel_buffer_minutes` pour les marges : le calcul les intègre sur toute la journée. Pour une grande tournée, choisir un solveur adapté ou répartir secteurs/jours. Ne pas annoncer un optimum de conduite ou du trafic réel : l'objectif exact est le retour le plus tôt sous les hypothèses fournies.

Sans source de durées, livrer liste et liens avec « ordre proposé, durées et faisabilité à vérifier ». Ne pas fabriquer une matrice pour la démo.

## Livrer et partager

Garder les exécutions dans un dossier distinct, par exemple `output/prospection-terrain/AAAA-MM-JJ-ville/`. Ne pas modifier le skill à chaque recherche.

`scripts/export_pack.py` produit le tableau complet, des CSV/KML pour My Maps, le tableau de tournée si disponible, les liens de navigation, une notice d'import et `reporting.html`. Le reporting inclut automatiquement les sources, qualifications, données financières, hypothèses, limites de couverture et totaux fournis. Corriger les données JSON manquantes puis régénérer dans un nouveau dossier, plutôt que modifier le HTML à la main. Ne pas promettre « tous les magasins » à partir d'une collecte partielle. `recap-email.html` permet de prévisualiser le corps du mail ; `recap-chat.md` fournit le même détail en Markdown pour la réponse finale et `recap-tournee.md` isole le planning, les hypothèses et tous les liens de parcours avant la longue liste des candidats.

Pour une carte « à importer », déposer les fichiers CSV/KML et la notice dans le dossier Drive, sans créer de carte My Maps en ligne. Le dépôt Drive nécessite son connecteur, mais aucune session My Maps n'est nécessaire. Ne pas lancer l'import navigateur sauf demande explicite de création de carte en ligne. Le KML contient les repères ; les liens de navigation portent le parcours calculé. Si la carte est refusée, définir `delivery.map_requested: false` : le script exclut automatiquement ces fichiers et leur annonce du rapport.

My Maps nécessite un import dans un compte Google. Pour créer ou modifier une carte en ligne, toujours utiliser le navigateur intégré de Codex (`iab`), sauf demande explicite de l'utilisateur pour un autre navigateur. Vérifier le compte Google actif avant toute création ou import : utiliser celui demandé, sans déduire le compte cible d'une session Chrome ou d'un connecteur Gmail. Si la connexion manque ou si le compte est incorrect, ouvrir Google dans le navigateur intégré et demander à l'utilisateur de s'y connecter avec le compte souhaité ; reprendre après confirmation. Ne pas demander de mot de passe ni de code dans le chat. Suivre le parcours de connexion et d'import de [tournee-et-exports.md](references/tournee-et-exports.md#my-maps-et-navigation).

Créer/importer puis vérifier les repères, le propriétaire, le lien et les droits. Distinguer fichier KML, carte vide ou partielle, et carte terminée. Garder la carte privée tant qu'un partage plus large n'est pas demandé ; exclure coordonnées privées et analyse financière sensible de ses calques. Si le navigateur intégré ou l'import est indisponible, fournir les fichiers et l'étape restante précise ; ne pas basculer automatiquement vers Chrome ou Edge.

Avant toute modification du partage, comparer l'adresse destinataire au propriétaire **du dossier**, puis lire les permissions existantes. Si le destinataire est déjà propriétaire, son accès est acquis : garder le dossier restreint, vérifier les fichiers et poursuivre l'envoi autorisé. Ne pas l'ajouter comme lecteur, changer son rôle ou demander de confirmer une permission inutile. Même principe si le destinataire possède déjà un accès suffisant. Ne pas déduire la propriété du seul compte Gmail. `reconcile_delivery.py` expose `sharing_decision` pour distinguer accès existant, métadonnées manquantes et droit réellement à accorder.

Pour Google Drive, utiliser le connecteur du compte vérifié et lire le skill Google Drive disponible avant ses opérations. Créer un dossier distinct pour la tournée, téléverser les vrais fichiers et vérifier leur présence par relecture. Conserver les CSV/KML comme fichiers téléchargeables, sans conversion en Google Sheets. Appliquer la procédure de [livraison Drive et notification Gmail](references/tournee-et-exports.md#livraison-google-drive-et-notification-gmail), notamment la vérification de l'accès du destinataire. Ne pas fabriquer de lien ni rendre le dossier public pour contourner un problème d'accès.

Pour Gmail, envoyer uniquement sur demande à l'adresse déterminée. Après dépôt complet et accès vérifié par le script de contrôle, préparer le reporting complet dans le corps du mail, avec le tableau du planning (départ, visites, pause et retour), les adresses, liens de navigation, bilan, qualification et sources de chaque prospect, réserves et points à vérifier. Ajouter le lien réel du dossier Drive pour récupérer les fichiers, sans pièces jointes. `scripts/prepare_drive_email.py` reprend le rapport HTML dont l’empreinte est liée au plan de livraison vérifié ; il ne téléverse et n’envoie rien. Ne pas remplacer ce corps par une notification courte ni le tronquer silencieusement. Si un connecteur refuse sa taille, conserver le rapport complet et signaler le blocage. Journaliser avant envoi et contrôler la réponse avec `reconcile_delivery.py` suivant la [procédure de reprise](references/controls-and-resume.md#journal-denvoi-gmail-et-prévention-des-doublons). Ne pas réessayer un envoi ambigu sans vérifier les messages envoyés. Un refus explicite avant exécution permet une correction ciblée ; arrêter si le même blocage persiste. Pour une nouvelle exécution explicitement demandée, ne pas réutiliser un ancien statut envoyé : repartir d’un nouveau plan de livraison et envoyer sa notification propre. Ne jamais contacter les prospects au motif qu'ils figurent dans la liste.

Conserver `livraison-statut.json` séparément du manifeste initial : dossier Drive, fichiers réellement déposés et vérifiés, destinataire et accès, état du mail (`not_sent`, `sent`, `unknown`) et identifiant du message si renvoyé. Une confirmation du connecteur établit l'envoi, pas la réception. Si Drive est partiel ou inaccessible, fournir les fichiers locaux et annoncer le blocage ; ne pas envoyer un lien présenté comme une livraison complète. Si seul Gmail échoue, donner le lien Drive vérifié et annoncer que le mail n'a pas été envoyé.

La réponse finale du chat doit aussi être exploitable sans ouvrir Drive, même si la livraison email est bloquée. Commencer par `recap-tournee.md` : afficher le planning et **tous** les liens Google Maps « Parcours 1 sur N … N sur N », dans l’ordre, dernier trajet de retour compris. Ces liens sont distincts des CSV/KML à importer ; ne pas les remplacer par un lien Drive ou par le seul premier segment. Inclure aussi `itineraire.md` dans les liens de livrables. Puis reprendre `recap-chat.md`, avec le planning chronologique complet, les adresses et liens de navigation, les hypothèses et totaux, la qualification et les sources des prospects, les données financières disponibles et leurs limites, les magasins hors tournée et les points à vérifier. Ajouter les liens vérifiés des livrables et le statut réel du mail après contrôle, avec l’identifiant de confirmation si disponible. Ne pas réduire le résultat au nombre de visites et au lien Drive. En l’absence de tournée calculée, afficher les magasins et les vérifications restantes, sans inventer de planning.

## Démonstration

Le skill peut être déjà installé. Pour la démonstration en un prompt, inclure cadrage, exigence MCP, carte à importer, dépôt Google Drive et notification Gmail avec destinataire. Demander le récapitulatif complet dans le chat et dans le corps du mail, avec le lien du dossier et sans pièces jointes ; vérifier Drive et l'envoi simple au départ. Montrer ensuite le dossier et ses fichiers, puis le mail reçu uniquement si sa réception est vérifiée. Montrer les fichiers cartographiques comme prêts à importer, sans prétendre qu'une carte Google en ligne a été créée. Identifier les fixtures fictives ; distinguer données vérifiées et hypothèses.