Construire event-scout : une micro-app agentique qui tourne sans surveillance
Nous avons construit un petit outil qui repère pour nous les événements B2B et tourne seul. La leçon, c'est la forme, pas les événements.
Traduction produite automatiquement par IA. La version allemande est l'original vérifié par la rédaction.
Nous avons construit un petit outil, event-scout, qui repère les événements professionnels près de chez nous, les classe pour le type de vente relationnelle que nous pratiquons, puis tourne tout seul. C'est une étude de cas de notre propre développement, alors lisez les chiffres comme les nôtres, pas comme un benchmark.
Le propos de l'article n'est pas les événements. C'est la forme. event-scout est une micro-app agentique : quelque chose que l'on construit une fois avec un agent de code puis que l'on laisse tourner, où l'agent fait le jugement délicat et de simples scripts font la plomberie ennuyeuse et reproductible. Cette répartition est toute la leçon, et elle vaut pour presque chaque tâche interne qu'une équipe de PME continue de faire à la main. event-scout tourne sur la plus haute de ces couches, une CLI agentique (iiterate).
01. CE QU'IL FAIT, CONCRÈTEMENT
À chaque exécution, event-scout parcourt une base de sources sélectionnées : sites d'événements, calendriers, newsletters et quelques flux LinkedIn. De tout ce qu'il récupère, il ne garde que les événements en présentiel, futurs et à portée de Remagen, note chacun selon son utilité pour nous, retire les doublons dans un magasin unique et reconstruit un tableau de bord que nous ouvrons vraiment.
Prise isolément, aucune de ces étapes n'est vraiment nouvelle. Ce qui fait que cela fonctionne, c'est que le tout tourne sans surveillance selon un calendrier, et que le jugement appliqué est le nôtre, pas un filtre de pertinence générique. La sortie n'est pas un flux de tous les événements tech d'Allemagne. C'est une réponse courte et classée à une seule question : où devrions-nous nous montrer ensuite.
02. LA FORME QUI L'A FAIT FONCTIONNER : L'AGENT POUR LE JUGEMENT, LES SCRIPTS POUR LA PLOMBERIE
La décision de conception qui compte, c'est où le modèle s'arrête et où un script commence.
La récupération est déléguée à un assistant déterministe. Un petit orchestrateur Node rend chaque source à échéance dans un vrai navigateur headless, gérant ainsi les pages JavaScript, les protections anti-bot légères et les listes à chargement paresseux, et il capture les données d'événement structurées schema.org quand une page les expose. C'est de la plomberie : fiable, planifiable, identique à chaque fois.
L'agent lit ce que le récupérateur a enregistré et fait les parties qui résistent au codage en dur : extraire de vrais événements de pages en désordre, décider ce qui compte comme présentiel et pertinent, noter chacun, et repérer que deux annonces désignent le même événement. Un second petit moteur fusionne ensuite, élague les anciennes entrées et régénère le tableau de bord.
🔸 Ne faites pas faire au modèle ce qu'un script fait à bas coût.
Rendre une page et écrire un fichier est un travail déterministe. Le confier au modèle serait plus lent, plus coûteux et moins fiable.
🔸 Ne faites pas faire à un script ce qui demande du jugement.
Savoir si une annonce à moitié formatée est un événement réel, pertinent et présentiel est exactement le jugement où un modèle excelle et où une regex échoue.
Placer cette ligne au bon endroit est l'essentiel de ce qui fait de l'outil un dispositif fiable plutôt qu'une démo astucieuse.
03. IL S'AUTORÉGLE
Un scout qui vérifie chaque source à parts égales à chaque exécution gaspille l'essentiel de son effort, car les événements n'apparaissent pas de façon uniforme.
Chaque source porte donc son propre bref historique de rendement. Les sources qui produisent régulièrement des événements pertinents sont vérifiées à chaque exécution. Celles qui reviennent vides sont mises en pause selon un délai croissant, une semaine, puis deux, puis un mois, et sont retestées à son expiration plutôt que supprimées. Une source qui n'a simplement rendu aucun événement est discrètement déprioritisée ; seule une source qui échoue plusieurs fois de suite au chargement est retirée comme défectueuse.
L'effet est que l'attention se porte là où les événements apparaissent réellement, et cela s'ajuste tout seul sur des semaines sans que personne ne s'en occupe. Cet autoréglage est ce qui fait du sans-surveillance une promesse réelle et non un espoir.
04. UN SCORING ASSUMÉ VAUT MIEUX QU'UN FLUX GÉNÉRIQUE
Le score est délibérément le nôtre. Chaque événement obtient une valeur sur 100, pondérée pour notre situation : sa proximité et sa facilité d'accès, la densité de la salle en acheteurs du type que nous servons, son caractère intime, l'existence d'un levier concret comme une remise ou une prise de parole, et son échéance.
La pondération porte une opinion que nous avons sur la vente. Une grande conférence ne se classe haut que s'il existe un vrai levier à utiliser, car pour une vente relationnelle une salle bondée sans porte d'entrée vaut moins qu'une petite table ronde régionale où l'on peut vraiment parler aux gens. Le résultat se lit comme un cockpit de décision plutôt qu'un calendrier : il pointe où passer une journée, pas tout ce qui existe.
Un flux d'événements générique ne pourrait pas encoder cela, car le jugement est propre à la façon dont une équipe donnée gagne des affaires. Cette spécificité est la raison pour laquelle il valait la peine de le construire plutôt que de l'acheter.
05. POURQUOI UNE MICRO-APP, ET NON UN SAAS
event-scout est petit à dessein. L'ensemble tient en une poignée de fichiers JSON pour les sources et le magasin d'événements, deux ou trois scripts, et un tableau de bord HTML autonome qui s'ouvre directement depuis le disque. Il n'y a pas de base de données à faire tourner ni d'abonnement à renouveler. Les données restent nôtres, et le scoring aussi.
C'est le même mouvement que les propres équipes non techniques d'Anthropic ont décrit, construire de petits outils internes avec un agent de code plutôt que de déposer une demande et attendre (claude.com). Nous avons aussi écrit sur ce schéma du côté utilisateur (iiterate).
Il n'est pas exempt d'aspérités, et prétendre le contraire serait malhonnête. Les sources derrière un mur de connexion nécessitent qu'une session soit capturée à la main une fois. Quelques sites récalcitrants restent des pistes manuelles plutôt que de faux résultats. Et nous vérifions chaque reconstruction en contrôlant directement la structure de la page, car une capture d'écran cale sur le chargement d'une police. Rien de tout cela ne change la conclusion : quand une tâche est répétable et propre à votre façon de travailler, un agent de code peut la transformer en un petit outil possédé pour moins cher que le SaaS ou les heures manuelles qu'il remplace. La question plus difficile n'est pas de savoir si vous pouvez en construire un. C'est laquelle de vos corvées hebdomadaires attendait discrètement de le devenir.
