Cinq boîtes, des prospects qui répondent, des rendez-vous, des factures, du démarchage. L'assistant lit tout, range, étiquette, prépare un brouillon pour chaque prospect qui écrit, et attend qu'un humain clique sur Envoyer.
Deux associés, cinq boîtes mail : la boîte principale, celle du contact, et trois adresses de prospection. Chaque jour arrivent des réponses de prospects, des questions, des refus, des absences de bureau, des rendez-vous, et une cinquantaine de démarchages non sollicités. Lire, trier et répondre à tout cela à la main prenait chaque matin un temps qui n'allait pas au travail client. Une réponse de prospect oubliée peut faire perdre une affaire.
Les adresses, le contenu des échanges et les identifiants ne sont pas publiés. Le fonctionnement décrit est celui du code en production.
Comment déléguer le tri et la préparation des réponses à une machine, sans jamais lui laisser la possibilité d'envoyer un mail au mauvais moment, à la mauvaise personne ?
Les contraintes, les données et les garde-fous pris en compte pour concevoir l'outil.
L'application Microsoft utilisée n'a pas le droit d'envoyer de message, et le programme qui communique avec la messagerie refuse toute action autre que la création de brouillons et d'étiquettes. L'envoi est donc techniquement impossible, quelle que soit l'instruction donnée au modèle.
Un « non merci » était d'abord classé comme refus poli, donc encore prospectable. Nous avons tranché le 16 septembre 2026 : tout refus fermé inscrit l'opposition dans le CRM, et le doute profite à la demande de la personne. Cette règle découle du RGPD.
L'assistant peut ranger et étiqueter, mais il ne marque jamais comme lu un message écrit par une personne. Nous voulons voir ce qui est arrivé, même trié.
Un courrier de démarchage sans contact dans le CRM restait indéfiniment en attente, et bloquait par ricochet toute la prospection, sans message d'erreur. L'état a été rendu terminal, les échecs sont désormais journalisés, et un expéditeur inconnu du CRM ne déclenche plus d'alerte.
L'agent traite des lots de quatre dossiers, quatre lots par heure, et s'arrête à 95 % de son quota. Le coût est plafonné : un afflux de messages ne peut pas faire dépasser cette limite.
Après avoir écrit une propriété dans le CRM, l'assistant la relit et compare. Tant que la relecture ne confirme pas, l'état reste « incertain » et rien n'est déclaré fait.
La situation avant le projet, puis après.
six dossiers chacune, toutes les cinq minutes, depuis le 17 septembre 2026.
l'application n'a pas le droit d'envoyer, et le code refuse tout verbe d'envoi.
par une règle fixe, avant même que l'agent ne les voie.
y compris pour un refus, prêt à relire et envoyer.
le budget de l'agent est borné dans le code.
Les résultats se mesurent dans la durée. Voici les gains visés et ce qui n'est pas encore mesuré.
des messages déjà triés à l'arrivée de l'équipe le matin
aucune réponse de prospect perdue dans le flux
des relances datées qui reviennent seules le jour venu
une prospection qui respecte les refus sans dépendre de la mémoire de quelqu'un
Ce qui n'est pas mesuré à ce stade. Le temps gagné chaque matin n'est pas encore mesuré : l'assistant est en production depuis le 17 septembre 2026. On le mesurera sur un mois avant de publier un chiffre.
Pour un dirigeant ou une équipe commerciale qui reçoit des dizaines de mails par jour, la même approche s'applique : des règles fixes pour les messages sans intérêt, un modèle pour ceux qui demandent une analyse, et aucun envoi automatique. L'équipe ne fait plus le tri et garde la décision d'envoyer.
Les principaux composants, décrits sans donnée confidentielle.
Service hôte Python, lecture différentielle Microsoft Graph sur cinq boîtes et six dossiers, toutes les cinq minutes, registre SQLite.
Filtres déterministes : notifications, absences, démarchage, interne. Lots de quatre dossiers vers l'agent, quatre par heure.
Conteneur Hermès isolé, sept outils de lecture par fichiers, jeton par lot révoqué, arrêt à 95 % de quota.
Validateur puis exécuteur en liste blanche : brouillons natifs, étiquettes, attentes datées. Aucun verbe d'envoi autorisé.
HubSpot porte opt-out, sentiment et arrêt de séquence ; le moteur de prospection les relit avant chaque envoi.
Non : l'application qui accède aux boîtes n'a pas le droit d'envoyer, et la couche logicielle refuse tout verbe d'envoi. Il prépare des brouillons, pose des étiquettes et des attentes datées. L'envoi reste un geste humain.
Sa réponse est qualifiée (intérêt, question, refus, absence), un brouillon de réponse est préparé dans la boîte, et le CRM est mis à jour. Un refus ferme inscrit l'opposition : le moteur de prospection ne repartira jamais vers cette personne.
Le modèle fonctionne dans un environnement isolé, sans identifiant ni accès direct à la messagerie. Ses droits de lecture expirent à la fin de chaque lot. Les identifiants sont stockés sur le serveur principal, jamais dans l'environnement du modèle.
Oui, c'est le même principe que le copilote livré à FPC Habitat : des règles fixes pour ce qui se reconnaît à coup sûr, un agent pour le jugement, une liste blanche de gestes réversibles, et une interdiction d'agir inscrite dans le code.
Le diagnostic gratuit part de vos processus, de vos outils et des tâches qui vous font perdre du temps, puis permet de décider si une démonstration ou un audit est utile.