On organise beaucoup d’événements chez inwink. Des conférences, des ateliers, des learning expeditions, des forums… Mais celui-ci ne ressemblait à aucun autre.
Le mardi 16 juin dernier, nos clients ne sont pas venus assister à une démo ni écouter une roadmap. Ils sont arrivés avec leurs listes de courses. C’est-à-dire des fonctionnalités qu’on ne pouvait pas développer, faute de temps ou parce que trop spécifiques à tel ou tel client / contexte. Ils sont repartis avec quelque chose qu’aucun d’eux n’aurait imaginé faire seul : leurs propres outils, imaginés en quelques phrases, sans écrire une seule ligne de code.
Entre les deux, il y a eu ce moment de plus en plus habituel. Celui où une personne qui se dit « non technique » décrit son idée à voix haute, valide, et voit s’afficher une première version qui marche. Comme par magie, les regards changent. Comme si quelque chose venait de se débloquer.
C’est cette session, inédite dans le secteur de l’Event Tech, qu’on a envie de vous raconter de l’intérieur. Et de vous montrer pourquoi la rencontre du vibe coding, du MCP et de l’environnement inwink ouvre un terrain de jeu entièrement neuf pour les organisateurs.
Le vibe coding : parler à une IA pour qu’elle développe à votre place
Ce qu’on a mis entre leurs mains
Le principe qu’on a présenté tient en une phrase : décrire un besoin à une IA, en langage courant, et la laisser générer le code ou le prototype. Pas de cahier des charges, pas de spécification technique. On part de l’intention.
Ce qui rend la démarche bluffante en atelier, c’est la vitesse. Une idée formulée à voix haute devient, en quelques minutes, une première version qu’on peut manipuler. Pour des équipes qui n’avaient jamais « codé », c’est un vrai basculement : le développeur n’est plus une ressource qu’on attend pendant des semaines, mais un interlocuteur disponible à la demande, à qui on confie un besoin en quelques phrases.
On leur a aussi montré qu’il n’existe pas un outil unique, mais une palette à choisir selon l’objectif :
Les assistants généralistes
ChatGPT, Claude, Le Chat
- Specs & réflexion
- Design & UX
- Veille concurrentielle
- Analyse de documents
Les plateformes SaaS
Lovable, Bolt, V0
- Le plus accessible
- Idéal pour mock-up
- Hébergement inclus (attention : Shadow IT)
IA de développement
Claude, Cursor, Copilot
- Code de qualité pro
- Développement structuré
- Multi-langages
- Intégration VS Code
La méthode qu’on a transmise
Comment formuler un besoin quand on n’a jamais codé ? On a résumé ça en quatre étapes. Et c’est en les appliquant en direct, dans la salle, que les premières idées ont pris forme.
Penser en user story
Formuler son besoin sous la forme : « En tant que [rôle], je veux [fonctionnalité], afin de [objectif]. »
Par exemple : « En tant que responsable événement, je veux voir les dernières inscriptions à mes sessions, afin d’identifier rapidement les sessions qui se remplissent et celles qui nécessitent une relance. » Cette formulation oblige à clarifier qui utilise l’outil, ce qu’il veut faire, et pourquoi c’est utile.
Parler en langage naturel, sans jargon technique
L’IA fait de meilleures propositions quand elle comprend l’intention. Par exemple, « je veux un tableau qui liste mes exposants avec leur statut de dossier et une colonne pour les documents manquants« .
Donner le contexte et le pourquoi
Plus le contexte est précis, plus le résultat sera pertinent. Qui utilise l’outil ? À quel moment de l’événement ? Quelles données doivent apparaître ? Quel problème concret ça résout ? Une phrase de contexte bien posée évite souvent plusieurs allers-retours.
Avancer par étapes fonctionnelles
Ne pas vouloir tout d’un coup. Commencer par une première version simple, la tester, identifier ce qui manque, reformuler, itérer.
Le MCP : donner à l’IA le bon contexte (et garder vos données chez vous)
Bien formuler un besoin, c’est nécessaire. Mais ça ne suffit pas. Pour générer une extension réellement utile, l’IA doit aussi comprendre l’environnement dans lequel elle travaille : les données disponibles, les APIs, les droits, le vocabulaire du métier. C’est exactement le rôle du MCP.
Le MCP (Model Context Protocol) est un protocole qui connecte une IA à des APIs, des outils et des sources de données existants. Pour simplifier : il joue les interprètes entre l’IA et votre environnement. Sans lui, l’IA travaille dans le vide. Avec lui, elle s’appuie sur un cadre documenté.
Pourquoi ça change tout dans l’événementiel
Une IA généraliste sait écrire du code et produire une interface. Mais elle ne connaît pas votre back-office. Elle ignore quelles données existent, à quoi correspond chaque champ, quelle API appeler, quels droits respecter. Livrée à elle-même, elle produit quelque chose de cohérent en apparence, mais déconnecté de vos données réelles, et inexploitable en production.
C’est ce qu’on a fait toucher du doigt pendant l’atelier. Avec le MCP inwink, l’IA comprend que derrière un événement, il y a des participants, des exposants, des sessions, des inscriptions et des règles propres à chaque organisation. Concrètement, elle accède aux bons endpoints API, aux modèles d’extension existants et à la logique métier événementielle. Elle ne part plus d’une page blanche : le code généré colle à l’architecture inwink, les données appelées sont les bonnes, et le résultat s’intègre naturellement au back-office. Moins de corrections à la base, plus de temps pour affiner ce qui compte vraiment.
Et vos données restent sur inwink
C’est le point qui rassure le plus nos clients. Construire un outil avec le vibe coding ne veut pas dire disperser vos données dans un énième SaaS. Avec le MCP inwink, l’outil se branche sur votre environnement réel sans en faire sortir vos données : pas d’export sauvage de fichiers participants, pas de Shadow IT. Vos données événementielles restent là où elles sont gouvernées, chez vous, sur inwink.
Ce que nos clients ont imaginé, et tout ce que ça rend possible
Le plus marquant, ce ne sont pas les concepts. Ce sont les outils qui en sont sortis. Et il y a eu deux temps : d’abord les pionniers qui ont défriché, puis la salle qui a imaginé la suite.
Les pionniers, ceux qui ont tenté avant tout le monde
Bien avant l’atelier, quelques clients pilotes ont accepté de jouer le jeu : tester l’approche en avant-première, sans garantie, avec la part de risque que ça suppose.
Les équipes de South Summit Madrid ont conçu leur propre détecteur de doublons, pour fiabiliser leurs listes avant l’événement et éviter les erreurs à l’accueil. Elles ont aussi monté un tableau de suivi des sessions, qui visualise le remplissage de chacune et permet d’anticiper les ajustements de planning.
Détecteur de doublons créé par les équipes de South Summit Madrid
Tableau de suivi des sessions du South Summit Madrid
Sur Vivatech (bravo Yann 💪), c’est un programme personnalisé qui a vu le jour, capable d’adapter le parcours de chaque participant à ses centres d’intérêt.
Programme personnalisé proposé sur Vivatech
Aucune de ces équipes n’est une équipe de développeurs. C’est tout l’intérêt. Et ce sont leurs résultats, concrets, qui nous ont donné envie d’ouvrir la démarche plus largement.
Puis l’atelier, et là, d’autres projets ont surgi
C’est fort de ces premiers essais qu’on a organisé la session du 16 juin. Cela nous a aussi servi de deadline en interne pour sortir des MCP fonctionnels et sécurisés (good job Gaetan, Guillaume et Florent 💪).
Bon, et concrètement, qu’est-ce qui en est sorti ?
Le plus parlant, ce n’est pas tel ou tel outil pris isolément. C’est la vitesse à laquelle, une fois la mécanique comprise, les idées se sont mises à fuser autour de la table. Chacun partait de son propre quotidien, de ses propres galères. En quelques minutes, trois grandes familles de projets se sont dessinées.
Les premiers pensaient à leurs participants. Plusieurs voulaient en finir avec le programme générique : un parcours qui s’adapte vraiment à chacun, avec les bonnes sessions, les bons exposants à rencontrer et des rendez-vous suggérés selon ses centres d’intérêt. D’autres imaginaient, sur un salon, une recommandation de produits qui laisserait un visiteur retrouver en un geste des références proches de ce qu’il vient de photographier. Et cette envie revenue plusieurs fois : une vue « mon événement » qui réunit au même endroit ses inscriptions, ses favoris, ses rendez-vous et ses documents.
D’autres équipes, plus proches du terrain exposants, parlaient surtout du temps qu’elles gagneraient. Un tableau pour voir d’un coup d’œil, exposant par exposant, ce qui est prêt, ce qui attend et ce qui bloque côté badges, invitations et documents. Une vue exposant qui centralise tout le dossier : statut, contacts, pièces manquantes, prochaines actions. Rien d’étonnant : c’est précisément le terrain que les pionniers de South Summit avaient déjà commencé à défricher.
Et puis il y avait ceux qui pilotent l’événement de l’intérieur, fatigués de jongler avec les exports. Eux rêvaient d’un dashboard d’inscriptions vivant, qui suit l’évolution jour après jour, par segment ou par canal. D’une vue « actions prioritaires » qui rassemble les points chauds du moment : inscriptions en attente, accès à valider, dossiers incomplets, relances à lancer. Et d’un reporting que la direction, le marketing ou les commerciaux peuvent lire directement, sans repasser par un tableur.
Le point commun de toutes ces idées ? Aucune n’a eu besoin d’une fiche projet ni d’une réunion de cadrage. Juste une phrase, un peu de contexte, et l’environnement inwink derrière pour que ça tienne debout.
Ce qu’on retient de cette session
Au fond, les organisateurs d’événements ont toujours eu des besoins très spécifiques. Ce qui change aujourd’hui, c’est qu’ils peuvent les exprimer plus facilement, les prototyper en quelques minutes et imaginer des outils vraiment adaptés à leur façon de travailler.
Quelques pionniers l’ont prouvé les premiers, en prenant le risque avant tout le monde. L’atelier du 16 juin a montré que ce n’était pas une exception réservée à deux ou trois équipes téméraires : mis dans de bonnes conditions, avec la bonne méthode et le bon contexte, à peu près n’importe quelle équipe métier se met à créer.
Attention quand même à ne pas se tromper de terrain. Là où le vibe coding brille, c’est pour créer des extensions, des vues et des outils qui viennent se greffer sur une base solide. Personne, chez nous, ne vous conseillera de vibe coder votre plateforme de gestion événementielle elle-même : la sécurité des données, la fiabilité en production, la conformité, la tenue de charge un jour J… tout ça ne s’improvise pas en quelques phrases. C’est précisément le rôle d’inwink, et c’est pour ça qu’on reste aux côtés de nos clients (et des autres 😏) pour tracer la frontière entre ce qu’on peut créer soi-même et ce qui doit reposer sur des fondations éprouvées.
Car le vibe coding ne transforme pas les équipes événementielles en développeurs. Il leur donne une nouvelle manière d’amorcer la création d’outils, à partir de ce qu’elles connaissent le mieux : leur métier, leurs utilisateurs, leurs problématiques. Et quand cette créativité s’appuie sur le MCP inwink, elle reste connectée à des données fiables et gouvernées.
Ce qu’on a vu ce jour-là, c’est des équipes métier qui reprennent la main sur leurs outils, sur ce qui a du sens à ce niveau. C’est précisément ce qu’on avait envie de provoquer. Et ce n’était qu’un début.
