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. Et une réponse de prospect ratée dans le flux, c'est une affaire perdue.
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 ?
Ces blocs explicitent la matière terrain utilisée pour concevoir la solution : objets métier, contraintes, automatisations, données, arbitrages et garde-fous.
On aurait pu écrire « n'envoie jamais » dans les consignes de l'agent. On a préféré que l'envoi soit impossible : l'application Microsoft utilisée n'a pas le droit d'envoyer, et la couche qui parle à la messagerie refuse tout verbe autre que ceux des brouillons et des étiquettes. Une consigne se contourne, un droit absent non.
Un « non merci » était d'abord classé comme refus poli, donc encore prospectable. On a tranché le 16 septembre 2026 : tout refus fermé pose l'opposition dans le CRM, et le doute profite à la demande de la personne. C'est une décision RGPD, pas un réglage.
L'assistant peut ranger et étiqueter, mais il ne marque jamais comme lu un message écrit par un humain. On veut voir ce qui est arrivé, même trié.
Un courrier de démarchage sans contact dans le CRM restait « en attente » à vie, 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 six dossiers, quatre lots par heure, et s'arrête à 95 % de son quota. Le budget est borné par conception : une boîte inondée ne peut pas faire exploser la facture.
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 logique n'est pas de montrer une IA abstraite, mais de rendre visible le passage d'un fonctionnement dispersé à un système métier exploitable.
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 réels se suivent dans la durée. On affiche ici les leviers travaillés, et on dit ce qui n'est pas encore mesuré.
un matin qui commence par des décisions, pas par du tri
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 le bruit, un agent pour le jugement, et une machine qui ne peut pas envoyer. On garde le clic, on perd le tri.
Une réalisation utile tient parce qu'elle relie les bons outils, les bons flux et les bons contrôles. On montre ici les briques structurantes sans exposer de 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 six 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, et ce n'est pas une consigne : 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.
L'agent tourne dans un conteneur sans identifiant et sans accès réseau à la messagerie. Il lit par des outils de lecture relayés par fichiers, avec un jeton révoqué à la fin de chaque lot. Les secrets vivent sur le serveur hôte, jamais dans le conteneur.
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 codée plutôt que promise.
Le diagnostic gratuit permet de partir de vos processus, de vos outils et de vos irritants, puis de déterminer si une démonstration ou un audit IA a du sens.