Retail · Sales ops

Brancher un agent sur HubSpot et fiabiliser 400 comptes avec l’open data

Journée Intégration puis mentoring : un agent de revue de portefeuille lisant HubSpot, enrichi par la BAN et SIRENE, validé par un humain avant écriture.

8sales ops & devs formés
3 sem.mock → portail HubSpot de test
0écriture CRM sans validation humaine*

* Politique WRITE-CRM : toutes les notes passent par le front HITL (scénario type, indicateurs représentatifs).

Contexte

Une enseigne retail de 400 magasins gérait ses comptes fournisseurs et partenaires dans HubSpot, avec des adresses hétérogènes et des doublons de raisons sociales. Les sales ops passaient une demi-journée par semaine à préparer la revue de portefeuille.

Un premier POC « ChatGPT + export CSV » avait convaincu sur le principe mais inquiétait la DSI : données envoyées à l’extérieur, aucun contrôle sur ce que l’agent pouvait écrire, et des SIREN parfois inventés.

Objectifs

  • Lire HubSpot via un contrat de provider testable, en mock puis sur un portail de test
  • Normaliser les adresses et proposer un SIREN par compte, avec validation humaine
  • Interdire toute écriture CRM sans approbation, et le prouver

Approche

  1. Journée FORM-IA-INT : TP1 provider HubSpot (mock → live sur un test account), TP2 open data avec cache hors-ligne, TP4 front HITL. TP3 Bugzilla remplacé par le tracker interne (Jira) en démonstration.
  2. Mentoring 4 h : adaptation des fixtures aux propriétés HubSpot du client, règle de rattachement SIREN (score BAN ≥ 0,9 et commune identique), seuil d’approbation double pour les comptes stratégiques.
  3. Sécurité : scan d’injection sur les notes HubSpot existantes (contenus externes), masquage des emails des owners dans les rapports.

Solution / livrables

  • Serveur MCP crm-saas branché sur le portail de test, politique d’outils lecture seule + note en dry-run
  • Enrichissement open data en lot sur 400 comptes : adresse normalisée, commune, candidats SIREN avec avertissements
  • Front HITL : file de validation des propositions de rattachement, décision journalisée

Résultats

  • Revue de portefeuille préparée en 20 minutes au lieu d’une demi-journée (scénario type)
  • Adresses normalisées et 70 % des comptes rattachés à un SIREN après validation humaine
  • Zéro écriture CRM automatique : chaque note porte l’identité de l’approbateur

Leçons apprises

  • Le contrat de provider a permis de développer en mock pendant que la DSI validait le portail de test
  • Les cas limites open data (homonymes, entités absentes) doivent être montrés dès la formation, pas découverts en prod
  • Le front HITL a rassuré la DSI plus que n’importe quel slide sur la « sécurité »