Tu peux lire 20 threads sur “les agents IA” et rester au même point. Ou tu peux passer 2 heures en atelier, construire un truc concret, et repartir avec un agent testable. C’est exactement la promesse de Build Your First AI Agent (Dust x Paatch), annoncé à Lyon au Ballad Club, format 19:00 à 21:15, avec une séquence “buildathon” et une capacité affichée à 50 places sur la page d’inscription.
Point important, parce qu’il y a du flou public : la date “29/09” circule, mais plusieurs signaux externes créent une ambiguïté entre des éditions (Lyon vs Paris) et une page Luma qui apparaît comme “événement passé”. Donc avant de poser ton billet de train, revalide la date exacte de l’édition lyonnaise sur la page Luma et la communication des organisateurs. Source : page Luma “Build Your First AI Agent | Dust x Paatch” (Lyon, Ballad Club, 19:00-21:15, 50 places) : https://luma.com/oicv1bn6?locale=fr&utm_source=openai.
Ce guide te dit à qui ça s’adresse, ce qu’un agent change vraiment vs un chatbot, comment venir avec un processus candidat propre, et quoi viser comme livrable en fin de soirée. SEO check : atelier agent IA Lyon, Dust Paatch Lyon, construire un agent IA.
Ce qui est annoncé (et ce qu’on peut affirmer sans broder)
D’après la page d’inscription Luma, l’atelier est pensé comme un hands-on avec une séquence buildathon pour que les participants repartent avec un agent construit pendant la soirée. Le positionnement est “no-code / langage naturel”, donc accessible au-delà des devs, et la cible affichée est large (freelances, salariés, builders). Source : https://luma.com/oicv1bn6?locale=fr&utm_source=openai.
Autre ancrage local utile : la page Luma mentionne une intervention d’Adrien Aliev (Arkange), cabinet IA basé à Lyon, avec un retour d’expérience sur des agents déployés en contexte PME. Même logique : pas une keynote abstraite, plutôt du “voilà ce qu’on a essayé, voilà ce qui a cassé”.
À qui ça parle, concrètement, à Lyon et en AURA
Un atelier agent IA à Lyon, ça peut vite partir en démo gadget. Là, l’intérêt dépend surtout de ton profil et de ton besoin immédiat.
Builders, freelances, consultants
Tu vends du delivery. Tu dois montrer vite un prototype propre. Tu veux un truc présentable dès le lendemain : un agent qui prend une entrée, suit des étapes, et sort un livrable testable. L’atelier te sert si tu viens avec un cas borné et des exemples, pas juste une idée.
Ops, support, customer success, ADV, RH
Tu gères des flux entrants, des demandes répétitives, des tâches “copier-coller + jugement”. C’est typiquement agent-compatible : l’agent classe, extrait, propose, escalade. Et tu gardes l’humain pour la validation et les cas limites.
Marketing, revops, sales ops
Tu jongles avec CRM, enrichissement, briefs, reporting, relances, contenus structurés. Un agent peut faire le sale boulot, mais seulement si tu mets des garde-fous et un workflow de validation. Sinon tu crées juste plus de bruit.
PME et ETI en Auvergne-Rhône-Alpes (Lyon, Grenoble, Saint-Étienne, Clermont, Annecy)
La douleur classique : faire un POC, c’est facile. Le mettre en production sans fuite de données, sans chaos, sans dépendance à deux personnes, c’est dur. Paatch se positionne justement sur des sujets de gouvernance (auditabilité, validation humaine, contrôle d’accès, hébergement UE selon leur communication). Donc si ta question est “comment je fais un agent que je peux assumer devant mon DSI ou mon RSSI”, tu auras des choses à challenger sur place.
Agent vs chatbot : la différence utile (celle qui change ton projet)
Arrête la philosophie. Voilà la différence qui compte quand tu dois livrer quelque chose.
- Chatbot : tu poses une question, il répond. C’est surtout une interface conversationnelle.
- Agent : tu lui donnes un objectif, il enchaîne des étapes, et peut agir (lire, écrire, déclencher un workflow, produire un livrable). Ça augmente la valeur, mais aussi le risque.
Dans Dust, ce passage “répondre” vers “agir” est formalisé notamment via la notion de Pods, des espaces de travail où l’agent peut interagir avec des ressources (fichiers, conversations, tâches, métadonnées) selon des permissions. Source documentation Dust : https://docs.dust.tt/docs/pods-overview?utm_source=openai.
Traduction : si tu viens construire un agent IA, tu ne viens pas pour un prompt. Tu viens pour un mini-système : entrées, étapes, sorties, critères de validation, et limites.
Prérequis pour profiter de la soirée (et ne pas repartir avec une démo vide)
Le meilleur hack : arrive avec un cas simple, des données de test, et des garde-fous déjà pensés. Tu gagnes 10 fois plus qu’en improvisant sur place.
1) Un processus candidat répétitif et borné
Choisis une tâche que tu fais souvent. Idéalement quotidienne ou hebdo. Avec un début et une fin clairs.
- Bon signal : “je reçois 30 tickets par jour, je dois les router et proposer une réponse”.
- Mauvais signal : “je veux un agent qui améliore la productivité de l’entreprise”.
2) Une sortie attendue claire
Définis le livrable. Un tableau. Un JSON. Un brouillon d’email. Une synthèse d’une page. Une liste de tâches.
Un agent testable, c’est un agent qui produit quelque chose que tu peux comparer à une référence.
3) 5 à 10 exemples réalistes, anonymisés
Sans exemples, tu ne testes rien. Tu regardes une démo marcher “sur un cas parfait”. Apporte :
- 5 tickets réels anonymisés, avec la bonne catégorie attendue.
- 5 leads réels anonymisés, avec le résultat “bon lead / mauvais lead”.
- 5 documents types (bon de commande, brief, compte rendu) avec ce que tu veux extraire.
Besoin d’anonymiser vite : lis notre guide Anonymiser ses données avant de les envoyer à un modèle.
4) Des données disponibles et “safe”
Commence petit. Un corpus limité, propre, maîtrisé :
- procédures internes
- FAQ
- historique de tickets (anonymisé)
- modèles d’emails validés
Évite “toute la boîte” dès le premier soir. Tu perds le contrôle, et tu compliques la sécurité.
5) Des garde-fous dès le POC
Si l’agent touche un outil (CRM, ticketing, drive, messagerie), tu dois poser des limites tout de suite :
- permissions minimales
- validation humaine avant action
- bac à sable si écriture dans un outil
- journalisation des actions
Pour cadrer tes garde-fous, tu peux t’appuyer sur : Agents IA en production : les cinq garde-fous à poser et Sécuriser un agent IA qui a accès à vos outils.
5 cas d’usage simples à prototyper pendant l’atelier (et repartir avec un agent testable)
Le bon cas d’usage pour une soirée, c’est un cas qui tient en une boucle : entrée, traitement, sortie, validation. Voilà 5 options “safe” et fréquentes en entreprise, y compris dans les PME lyonnaises.
1) Tri et pré-réponse aux demandes entrantes (support, ADV, RH)
Objectif : prendre une demande, la classer, extraire les champs utiles, proposer un brouillon.
- Entrée : email ou ticket copié-collé (anonymisé).
- Sortie : catégorie, priorité, champs extraits (client, produit, urgence), brouillon de réponse, tag “à valider”.
- Garde-fou : aucun envoi automatique. L’humain valide.
Pour structurer ça : Automatiser l'accueil des demandes entrantes : formulaire, tri, affectation.
2) Compte rendu + todo à partir de notes
Objectif : transformer un texte brut en synthèse exploitable.
- Entrée : notes de réunion, points épars, éventuellement un doc.
- Sortie : résumé, décisions, actions, responsables, échéances, questions ouvertes.
- Test : compare 5 exemples et mesure le taux d’items corrects.
Le piège : inventer. Donc demande à l’agent de citer les passages sources quand c’est possible, ou de marquer “incertain”. Sur la méthode de test : Comment évaluer la réponse d'une IA : construire son jeu de tests.
3) Qualification de lead (marketing, revops)
Objectif : prendre un lead entrant et produire une fiche de qualification.
- Entrée : formulaire, email, description du besoin.
- Sortie : scoring simple (A/B/C), questions à poser, proposition de premier message, champs CRM à remplir.
- Garde-fou : pas d’envoi automatique, pas d’enrichissement opaque.
Tu peux t’inspirer de : Automatiser la qualification de ses leads entrants.
4) Reporting hebdo à partir d’un export
Objectif : arrêter de faire des slides à la main.
- Entrée : export CSV, tableur, ou copier-coller des chiffres.
- Sortie : résumé exécutif, variations, alertes, 3 actions recommandées.
- Test : cohérence chiffres et narration, pas d’invention.
Si tu veux quelque chose de robuste : Automatiser ses rapports hebdomadaires à partir de plusieurs sources.
5) Extraction structurée (docs, devis, factures, briefs)
Objectif : passer du PDF ou du texte à des champs propres.
- Entrée : un document type (ou texte) avec une structure semi-stable.
- Sortie : JSON ou tableau avec les champs (date, montant, référence, items, contraintes).
- Garde-fou : si un champ est manquant, l’agent doit le laisser vide et le signaler.
Cas très “agent” parce que tu peux ensuite brancher ça à un workflow. Mais tu restes en mode bac à sable tant que la qualité n’est pas mesurée.
Comment choisir ton cas en 10 minutes (grille simple)
Tu veux construire un agent IA, pas débattre. Utilise cette mini-grille avant l’atelier.
- Fréquence : au moins 2 fois par semaine.
- Temps gagné : 10 minutes par occurrence minimum.
- Données dispo : tu as déjà 5 à 10 exemples.
- Qualité mesurable : tu sais dire si la sortie est “bonne”.
- Risque maîtrisable : aucune action irréversible sans humain.
Si tu bloques sur le cadrage : Cadrer un projet IA : la méthode en quatre étapes avant d’écrire du code. Et si tu veux clarifier la frontière agent / chatbot : Qu'est-ce qu'un agent IA, et en quoi il diffère d'un chatbot.
Questions à poser sur place : sécurité et mise en production (check-list courte, pas théorique)
Un agent, ça devient vite dangereux quand il a des accès. Ton job : repartir en comprenant ce que tu peux faire sans mettre ta boîte en risque.
Permissions et périmètre
- Que peut lire l’agent exactement ? Quels espaces, quels dossiers, quelles sources ?
- Que peut écrire l’agent ? Où ?
- Qu’est-ce qui est interdit par défaut (messagerie, suppression, paiement, exports massifs) ?
Validation humaine
- À quel moment la validation intervient : avant envoi, avant écriture dans un outil, avant action destructive ?
- Est-ce que la validation est contournable ? Par qui ?
- Peut-on forcer un mode “lecture seule” ?
Audit trail et traçabilité
- Est-ce qu’il existe un journal “run par run” : inputs, sorties, actions, timestamps, utilisateur ?
- Peut-on exporter ces logs pour audit interne ?
- Comment gérer les erreurs et les reprises ?
Pour creuser côté méthode : Tracer les décisions prises avec l'aide d'une IA et Gérer les erreurs dans ses workflows : reprises, alertes et journalisation.
Données, hébergement, conformité
- Où sont hébergées les données et les exécutions ? UE, France, ailleurs ?
- Quelles options de rétention et de suppression ?
- Peut-on isoler par équipe, par client, par projet ?
Si tu es en entreprise régulée ou juste prudente : Souveraineté des données : héberger son IA en France, concrètement et Écrire une politique de conservation des données pour ses outils IA.
Résistance aux attaques et “agent fantôme”
- Comment l’outil gère l’injection de prompt via un document ou un email entrant ?
- Quels contrôles empêchent l’agent de sortir des données sensibles ?
- Comment détecter un usage non déclaré par les équipes (shadow AI) ?
Deux lectures utiles pour arriver armé : Injection de prompt : la faille que les entreprises sous-estiment et Lyon et AURA : sécuriser vos agents IA avant qu’ils ne deviennent des agents fantômes.
Mise en production : du prototype au “ça tourne lundi”
- Qu’est-ce qui différencie un agent de démo d’un agent “run” (monitoring, logs, coûts, droits) ?
- Comment versionner le comportement (prompts, règles, sources) ?
- Comment gérer les changements de modèle sans casser la qualité ?
Pour la transition POC vers run côté organisation : Industrialiser l’IA en DSI à Lyon (13/10) : la checklist POC vers run.
Ta checklist “arriver prêt” (à copier-coller)
- Cas d’usage : 1 tâche répétitive, bornée, avec une sortie claire.
- Données : 5 à 10 exemples anonymisés + le résultat attendu.
- Règles : ce que l’agent a le droit de faire, et ce qu’il n’a pas le droit de faire.
- Validation : où l’humain valide, et comment tu le formalises.
- Mesure : 2 critères simples (ex : taux de bonne catégorisation, taux de champs corrects).
- Bac à sable : aucun accès en écriture à un outil de prod le premier soir.
Ce que tu dois viser en fin de soirée (un livrable réaliste)
Le bon objectif, c’est pas “j’ai un agent IA”. C’est :
- un agent qui prend une entrée réaliste
- qui suit un enchaînement d’étapes compréhensible
- qui produit une sortie exploitable
- que tu peux tester sur 5 exemples
- avec un garde-fou de validation humaine
Si tu repars avec ça, tu as déjà un sujet de discussion sérieux avec ton équipe ops, ton DSI, ou ton client. Et tu sais quoi améliorer : données, règles, accès, mesure.
Prochaine action
Avant d’y aller, fais trois choses, vite :
- Vérifie la date et les détails de l’édition lyonnaise sur la page officielle (le flou public existe) : https://luma.com/oicv1bn6?locale=fr&utm_source=openai.
- Choisis un seul cas d’usage parmi les 5 ci-dessus et prépare 5 à 10 exemples anonymisés.
- Écris tes garde-fous en une page : permissions, validation, logs. Tu t’en serviras pour challenger Dust et Paatch sur place.
Si tu fais ça, tu ne viens pas consommer un atelier. Tu viens construire un agent IA que tu peux vraiment tester, itérer, et potentiellement déployer proprement.
Laisser un commentaire