Build Your First AI Agent (Dust x Paatch) à Lyon le 29/09 : venir prêt, repartir utile

Avant tout : la date et la ville sont à revalider

On va être clair. À l’heure où on écrit, il y a un flou entre plusieurs pages publiques : une annonce au 29 septembre 2026 existe, mais elle pointe sur une édition à Paris, pas à Lyon. Et une page Luma “Dust x Paatch” indique bien Lyon (Ballad Club, 19:00-21:15, capacité annoncée 50 places), mais le snapshot consultable la marque “événement passé” et la date ne correspond pas au “29/09”. Il y a aussi un signal faible sur LinkedIn qui parle d’une soirée Dust à Lyon au Ballad Club, à une autre date (4 novembre).

Donc : avant publication finale, vérifiez l’URL officielle d’inscription de l’édition lyonnaise (Luma, LinkedIn des organisateurs, site Paatch) et confirmez date, adresse, horaires, capacité. Le reste de cet article reste utile : il vous dit surtout comment arriver prêt à un atelier agent IA Lyon et comment repartir avec un agent vraiment déployable, même simple.

Pourquoi cet atelier mérite votre soirée (si vous venez avec le bon matos)

Les soirées “Build your first AI agent” bien faites ont un format qui marche : keynote, démo live, puis mini-hackathon guidé. L’objectif n’est pas d’écouter une heure de slides. C’est de prototyper un agent et de repartir avec un truc qui fait gagner du temps dès la semaine suivante.

Côté outils, Dust pousse une approche “agents connectés à la connaissance d’entreprise”, avec des connecteurs MCP annoncés “70+ out-of-the-box”, et un cadrage sécurité via Spaces, Groups et audit logs. Dust a aussi la notion de Pods : un espace persistant où humains et agents partagent contexte, fichiers et tâches. Point important : pas de zones privées dans un Pod. Autrement dit, vous ne venez pas avec des données que vous ne voulez pas voir circuler dans l’espace de travail.

Paatch, de son côté, se présente comme une “control tower” pour agents en entreprise, avec validation humaine avant action, audit trail, contrôle d’accès, hébergement dans l’UE, et suivi ROI par agent. Dit simplement : si votre sujet, c’est “ok pour un POC, mais comment je le mets en interne sans stress”, c’est pile l’angle.

À qui s’adresse la soirée (et à qui ça ne sert à rien)

Profils pour qui ça vaut le coup

• Ops, admin, finance, RH, support, commerce : vous avez des tâches répétitives, des règles simples, et des documents qui reviennent tout le temps.
• Produit, design, no-code, makers : vous savez cadrer un flux, tester vite, itérer.
• Dev et data : vous voulez comprendre les patterns agents, la gestion des permissions, et repartir avec une base propre.
• Dirigeants de PME, managers : vous cherchez un premier cas concret, pas une “stratégie IA” de 40 pages.

Cas où vous allez perdre votre temps

• Vous venez “pour voir” sans cas d’usage précis. Sur un atelier, ça finit en agent gadget.
• Votre cas est trop large : “automatiser tout le support” ou “réinventer le CRM”. Impossible en une soirée.
• Vous n’avez aucun accès à vos outils (ou vous ne pouvez pas obtenir un compte test). Vous resterez en démo.

Le vrai prérequis : venir avec un processus, pas avec une idée

Un agent utile, c’est rarement un “assistant généraliste”. C’est un agent qui exécute un micro-processus de bout en bout, avec des entrées claires, des sorties claires, et des permissions cadrées.

Choisissez un processus qui coche ces cases :

• Répétitif (au moins 2 à 5 fois par semaine).
• Assez standard (il y a des exemples, des gabarits, des règles).
• Mesurable (temps passé, délai, nombre d’allers-retours, erreurs).
• Risque limité (pas de décision critique sans humain).

Exemples de bons cas “atelier”

• Tri et résumé de demandes entrantes (mail, formulaire) avec proposition de réponse et affectation.
• Préparation de compte-rendu à partir de notes et pièces jointes + création d’une todo.
• Qualification de leads : enrichissement léger, scoring simple, génération d’un message, mise à jour CRM.
• Reporting hebdo : collecte de chiffres, rédaction d’un résumé, points d’alerte, format Slack ou email.
• Relecture et extraction : extraire clauses, risques, champs structurés d’un document type.

Ce que vous devez préparer AVANT de venir (sinon vous allez bricoler)

La promesse “repartir avec un agent” tient si vous arrivez avec les éléments suivants. Prenez ça comme une check-list de départ.

1) Entrées et sorties, avec 5 à 10 exemples réels

Venez avec :

• 5 à 10 entrées réalistes (tickets, emails, briefs, extraits de docs). Idéalement anonymisés.
• Le format de sortie attendu : tableau, JSON, email prêt à envoyer, message Slack, fiche CRM, checklist, etc.
• La définition du “bon” : 3 critères maximum (ex : exactitude des champs, ton, complétude).

Sans exemples, vous ne testez rien. Vous “discutez” avec l’agent. Et vous repartez sans agent.

2) Données et connaissances : périmètre strict

Dust met en avant des agents reliés à la connaissance d’entreprise. Super, mais en atelier, la bonne stratégie est simple :

• Commencez petit : un dossier de docs, une base de FAQ, un export léger, un corpus propre.
• Évitez : fichiers RH sensibles, données clients non nécessaires, contrats non anonymisés, tout ce qui peut fuiter.
• Rappelez-vous : dans un Pod, “pas de zone privée”. Ce que vous mettez dedans est fait pour être partagé dans l’espace de travail.

Pour une première version, vous pouvez même venir avec des documents factices qui imitent la structure du réel. L’objectif est de valider le flux, pas d’aspirer tout le SI.

3) Accès outils : comptes, droits, API, MFA

Les agents deviennent utiles quand ils touchent vos outils. Donc préparez :

• Les comptes nécessaires (Google Workspace, Notion, Slack, CRM, Drive, etc.).
• Un espace de test : un dossier Drive dédié, un canal Slack de bac à sable, un pipeline CRM “test”.
• Si besoin, des tokens ou accès API, mais avec permissions minimales.
• Votre MFA (authentification) prêt sur le téléphone, parce que sinon vous perdez 30 minutes.

4) Sécurité et conformité : cadrage minimal, mais réel

Deux règles qui évitent 80 % des mauvaises surprises :

• Least privilege : l’agent n’a accès qu’au strict nécessaire, et rien de plus.
• Human-in-the-loop : l’agent propose, l’humain valide avant envoi, suppression, modification, paiement, etc.

Sur le sujet “agents et risques”, gardez un réflexe : un agent n’est pas un chatbot. Il peut agir. Et dès qu’il a des outils, il y a un risque de mauvais paramétrage des permissions. Si vous voulez poser des bases saines, lisez aussi notre papier sur les garde-fous à mettre en production : https://lyon-ia.com/blog/agents-ia-en-production-garde-fous.

Check-list pour repartir avec un agent déployable en interne

“Déployable” ne veut pas dire “parfait”. Ça veut dire : utilisable par 3 à 10 personnes, avec un périmètre clair, un suivi, et un plan de rollback.

Check-list produit

• Un seul job : l’agent a une mission unique et stable.
• Un déclencheur : manuel (bouton), message Slack, nouveau ticket, nouvel email, etc.
• Un format de sortie standard : toujours le même, pour faciliter le contrôle et l’automatisation.
• Une étape de validation avant action sensible (envoi, mise à jour CRM, création de doc officiel).

Check-list données

• Sources documentées (d’où vient la vérité).
• Périmètre : ce que l’agent a le droit d’utiliser, et ce qu’il ne doit jamais voir.
• Jeu de test (vos 5 à 10 cas) conservé pour rejouer les tests.

Check-list permissions et audit

• Groupes : qui peut utiliser l’agent, qui peut le modifier.
• Logs : un minimum de traçabilité (qui a lancé quoi, quand, avec quel résultat).
• Mode “bac à sable” : agent d’abord cantonné à des dossiers, canaux, pipelines de test.

Pour comprendre pourquoi connecter des agents à vos outils devient un sujet central, et comment cadrer ces connexions, vous pouvez aussi relire notre explication du protocole MCP : https://lyon-ia.com/blog/mcp-protocole-explique.

Check-list mesure

• Un indicateur simple : minutes gagnées par run, délai de traitement, taux de retours.
• Avant / après sur une semaine, même à la louche mais documenté.

Pour cadrer ça proprement sans tableur infini : https://lyon-ia.com/blog/mesurer-gain-reel-usage-ia.

Check-list doc

• Une page qui décrit : objectif, entrées, sorties, périmètre, procédure de validation, exceptions.
• Un mode d’emploi pour un collègue qui n’était pas à l’atelier.

Sinon, dans un mois, personne n’ose toucher votre agent : https://lyon-ia.com/blog/documenter-ses-automatisations.

Mini-plan d’action : en 60 à 90 minutes, vous devez avoir ça

Si l’atelier est bien rythmé, vous pouvez viser un résultat concret en suivant ce plan ultra basique.

Étape 1 : choisir un processus (10 minutes)

• Nom du processus (ex : “résumer et classer les demandes entrantes”).
• Fréquence, douleur, impact.
• Risque : qu’est-ce qui peut mal se passer.

Étape 2 : définir entrées et sorties (15 minutes)

• Entrées : où arrivent les infos (email, ticket, formulaire).
• Sorties : où va le résultat (Slack, CRM, doc).
• Format : 5 champs max. Ex : catégorie, urgence, résumé, action recommandée, brouillon de réponse.

Étape 3 : cadrer les permissions (10 minutes)

• Ce que l’agent peut lire.
• Ce que l’agent peut écrire.
• Ce qui exige validation humaine.

Si vous hésitez, choisissez toujours plus restrictif. Vous ouvrirez ensuite.

Étape 4 : construire, tester sur vos 5 à 10 exemples (20 à 30 minutes)

• Lancer l’agent sur un premier exemple.
• Corriger la structure de sortie.
• Ajouter 2 ou 3 règles simples (ton, format, exceptions).
• Rejouer sur tous les exemples.

Étape 5 : mesurer le gain et poser la doc (10 à 15 minutes)

• Temps “avant” vs “après” sur 3 cas.
• Écrire la page de doc minimale.
• Définir le “prochain pas” : élargir à une équipe, brancher un outil, ajouter une validation.

Questions à vous poser sur place (celles qui séparent un agent jouet d’un agent utile)

• Qu’est-ce qui déclenche l’agent dans la vraie vie ? Si la réponse est floue, vous êtes en gadget.
• Qui valide quand l’agent veut agir ? Et dans quel outil ?
• Quelles données sont interdites dans le Pod ou dans le corpus ?
• Quel est le plan B si l’agent se trompe (rollback, reprise manuelle) ?
• Comment vous prouvez le gain à J+7 ?

Si votre entreprise est déjà sensible au sujet “shadow AI”, profitez-en pour recadrer : un atelier, c’est bien, mais derrière il faut un minimum de règles internes. On a posé le problème ici : https://lyon-ia.com/blog/shadow-ai-en-entreprise.

Matériel à apporter (oui, c’est bête, mais c’est ce qui fait rater l’atelier)

• Un ordinateur portable (c’est explicitement demandé sur la page Luma retrouvée).
• Chargeur, et si possible un partage de connexion de secours.
• Accès à vos comptes, MFA opérationnel.
• Vos 5 à 10 exemples d’entrées, déjà prêts (dans un dossier local ou cloud).
• Un mini-périmètre de données “safe” (docs non sensibles ou anonymisées).

Deux idées d’agents “première soirée” qui marchent bien en PME lyonnaise

Agent 1 : tri des demandes entrantes (support, ADV, RH)

• Entrée : email ou formulaire.
• Traitement : classification, extraction de champs, proposition de réponse.
• Sortie : message Slack + brouillon email, avec validation humaine.
• Gain : réduire le temps de tri et les erreurs d’aiguillage.

Si vous voulez un cadrage processus avant atelier, inspirez-vous de notre méthode sur l’accueil des demandes entrantes : https://lyon-ia.com/blog/automatiser-demandes-entrantes.

Agent 2 : assistant de base documentaire interne (onboarding, procédures, qualité)

• Entrée : question dans un canal dédié.
• Traitement : recherche dans un corpus limité (procédures, FAQ), réponse + sources citées.
• Sortie : réponse courte, plus liens vers documents, plus “je ne sais pas” quand il faut.
• Gain : moins d’interruptions, moins de tribal knowledge.

Pour préparer votre corpus sans vous raconter d’histoires : https://lyon-ia.com/blog/assistant-interne-documentation-entreprise.

Ce que vous devez faire dès le lendemain matin

Vous voulez que votre prototype survive au-delà de la soirée. Faites ces 5 choses à froid :

• Bloquez un créneau de 60 minutes avec un collègue utilisateur. Démo, feedback, ajustements.
• Élargissez à 10 cas réels supplémentaires, rejouez vos tests, notez les échecs.
• Verrouillez les permissions : lecture seule au début, actions sous validation.
• Mesurez : temps gagné, retours, erreurs évitées. Même simple.
• Documentez et désignez un owner, sinon l’agent devient orphelin.

Le point SEO, assumé : “atelier agent IA Lyon” et “construire un agent IA Dust”

Si vous cherchez un atelier agent IA Lyon, l’intérêt de ce format Dust x Paatch, c’est la promesse de sortir du blabla et de construire un agent IA Dust en conditions réelles, avec une logique “entreprise” (permissions, validation, audit, ROI). Mais ça ne marche que si vous venez préparé : cas d’usage, exemples, accès, périmètre de données.

Prochaine étape : votre check-list perso, à copier-coller

• Mon processus : ____________________
• Entrée : ____________________
• Sortie : ____________________
• Validation humaine obligatoire sur : ____________________
• Sources de données autorisées : ____________________
• Données interdites : ____________________
• 5 à 10 exemples prêts : oui / non
• Espace de test (Drive, Slack, CRM) : ____________________
• Indicateur de gain : ____________________
• Owner interne : ____________________

Si vous remplissez ça avant de vous pointer, vous avez de bonnes chances de repartir avec un agent simple, mais utile. Et surtout, défendable en interne.