Comment nous avons bâti des agents IA en 16 heures : les coulisses du hackathon 2025

Une banane scotchée au mur, des mèmes Skynet, des OsedeAgents, Cyrano de Bergerac et Juge Judy. Rien de tout cela n'était sur notre carte de bingo. Si vous nous aviez demandé ce que notre équipe chez Osedea créerait si nous avions carte blanche et juste 16 heures, nous n'aurions pas imaginé une telle aventure.

L'année 2025 a souvent été surnommée « l'année des agents », il était donc tout à fait logique que nous plongions tête première dans un hackathon pratique sur l'IA, car nous croyons que l'expérience concrète est la meilleure des expériences. Le samedi 31 mai, cinq équipes de développement d'Osedea se sont réunies pour notre hackathon annuel, alimenté aux boissons énergisantes, notre troisième édition axée sur l'IA. Chaque équipe devait bâtir un démo fonctionnel d'un système agentique à partir de zéro. À minuit, elles feraient leur pitch devant un jury, en compétition pour des prix dans trois catégories : la plus grande innovation, le plus grand fou rire et la meilleure implémentation technique. Inutile de dire que nos équipes ont relevé le défi avec un enthousiasme débordant.

Les démos qu'elles ont livrées en moins de 16 heures étaient tout simplement spectaculaires : inventives, hilarantes et débordantes de rires contagieux. Voici un aperçu de ce qu'elles ont bâti durant l'événement :

Équipe 1

Alexis, Carl, Emilie

Ce que nous avons bâti durant notre Hackathon sur les agents IA 2025 en 16 heures

Une banane scotché au mur, des mèmes Skynet, des OsedeAgents, Cyrano de Bergerac et Juge Judy. Rien de tout cela n'était sur notre carte de bingo. Si vous nous aviez demandé ce que notre équipe chez Osedea créerait si nous avions carte blanche et juste 16 heures, nous n'aurions pas imaginé une telle aventure.

L'année 2025 a souvent été surnommée « l'année des agents », il était donc tout à fait logique que nous plongions tête première dans un hackathon pratique sur l'IA, car nous croyons que l'expérience concrète est la meilleure des expériences. Le samedi 31 mai, cinq équipes de développement d'Osedea se sont réunies pour notre hackathon annuel, alimenté aux boissons énergisantes, notre troisième édition axée sur l'IA. Chaque équipe devait bâtir un démo fonctionnel d'un système agentique à partir de zéro. À minuit, elles feraient leur pitch devant un jury, en compétition pour des prix dans trois catégories : la plus grande innovation, le plus grand fou rire et la meilleure implémentation technique. Inutile de dire que nos équipes ont relevé le défi avec un enthousiasme débordant.

Les démos qu'elles ont livrées en moins de 16 heures étaient tout simplement spectaculaires : inventives, hilarantes et débordantes de rires contagieux. Voici un aperçu de ce qu'elles ont bâti durant l'événement :

Équipe 1

Alexis, Carl, Émilie

Les agents excellent dans la prise de décision, il est donc logique de les utiliser comme juges. Bien que le concept de « LLM-comme-juge » soit déjà familier dans les pipelines RAG, l'équipe 1 a décidé d'aller plus loin en bâtissant Judy, nommée à juste titre d'après Juge Judy, comme première application de Juge-en-tant-que-service (JaaS).

L'inspiration pour Judy a émergé lors du hackathon IA de l'année dernière, quand nous avons demandé à SPOT de dessiner des scènes arbitraires en utilisant des modèles de diffusion et G-Code. En pratique, par contre, seulement environ une image générée sur quatre était assez bonne pour être tracée comme contour, la plupart des tentatives donnaient de piètres résultats. Plutôt que de raffiner notre modèle génératif, nous avons implémenté un « juge » léger qui évaluerait les quatre sorties rendues et sélectionnerait le meilleur contour. À notre grande joie, cette simple étape de jugement a amélioré de façon spectaculaire les dessins finaux.

Forts de cette observation, l'équipe 1 s'est lancée dans la création d'un constructeur de pipeline multi-agents composable qui permet de configurer dynamiquement des scénarios de jugement. Sur le frontend, ils ont utilisé React Flow pour permettre aux utilisateurs de connecter visuellement des modules « travailleurs », des modules « juges », des définitions de critères et un composant de débat. En arrière-plan, l'interface utilisateur est transposée en un graphe dirigé à l'aide de LangGraph; un backend Python, supporté par des WebSockets, orchestrant les agents au moment de l'exécution.

Quand le pipeline s'exécute, chaque agent travailleur génère des sorties candidates (par exemple, des pitchs d'affaires), puis passe ces sorties aux agents juges et à un ensemble de critères d'évaluation. Les juges, les critères et les sorties des travailleurs alimentent un module de débat, qui orchestre une conversation au tour par tour : chaque juge élabore sur les critères concernant la sortie candidate. Une fois le débat terminé, chaque juge attribue des scores à chaque critère par sortie, et ces scores sont moyennés pour produire un classement final des sorties structurées. De plus, chaque travailleur et juge bénéficie de sa propre personne configurable et de son modèle LLM, via OpenRouter. Cela fournit une API unifiée pour les modèles permettant à plusieurs « cerveaux » différents de produire des artéfacts. Les fournisseurs incluent Gemini, Deepseek, OpenAI, Anthropic, Mistral et plus encore.

Lors de la démo du hackathon, ils ont présenté cette configuration dans un pipeline de style « Dragon's Den » (À l'œil du Dragon). Chaque équipe participante a présenté son produit agentique à cinq agents travailleurs, qui ont transformé le pitch en une proposition d'affaires peaufinée. Deux agents juges ont ensuite évalué ces propositions au sein du module de débat, en utilisant des critères prédéfinis pour guider leur notation. En temps réel, les juges ont échangé des arguments sur les mérites de chaque proposition, convergeant finalement vers une liste classée des idées des équipes.

Ce projet met en lumière la puissance des systèmes multi-agents et le modèle LLM-comme-juge. En rendant le processus de jugement lui-même modulaire et dynamique, l'architecture de Judy peut être étendue à tout flux de travail qui nécessite une évaluation automatisée, qu'il s'agisse de choisir le meilleur contour d'image, de valider des idées d'affaires ou de quelque chose d'entièrement nouveau.

Équipe 2
Christophe, Lilia, Maxime, Phillippe

Vous êtes-vous déjà demandé si vous pouviez avoir votre propre Cyrano de Bergerac qui vous chuchote à l'oreille en tout temps et vous dit quoi dire au bon moment ? Tout a commencé avec une paire de lunettes de réalité augmentée, les Vuzix Blade 2. Équipées d'une caméra, de haut-parleurs et d'un microphone, l'idée est que l'utilisateur pourrait analyser son interlocuteur visuellement et contextuellement pour savoir quoi dire ensuite.

Le pipeline commencerait par une capture vidéo et audio des lunettes. La vidéo passerait par plusieurs modèles de vision par ordinateur pour être traitée. L'audio passerait par un modèle de reconnaissance vocale. Les deux chemins fusionneraient ensuite dans un système agentique de LLM pour être traités afin de produire la phrase idéale à envoyer à l'utilisateur. Tout le calcul était effectué sur une instance AWS EC2, car les Blade n'auraient pas une capacité matérielle suffisante pour exécuter les modèles localement.

La première étape impliquait la détection de visage à l'aide du module Face Detection de MediaPipe, qui fournissait une image recadrée du visage de la personne pendant l'interaction. Si aucun visage n'était détecté, le pipeline s'arrêtait pour éviter un calcul inutile.

Pour extraire les informations pertinentes de l'image, nous avons attaché des balises sémantiques. Pour la description de l'apparence, nous avons utilisé deux modèles : Bootstrapped Language-Image Pretraining (BLIP) et Contrastive Language–Image Pretraining (CLIP). BLIP générait des légendes en langage naturel qui décrivaient la personne de manière plus basique et cartésienne. Pour enrichir cette sortie, nous l'avons combinée avec CLIP, ce qui a aidé à récupérer des attributs visuels précis, souvent manqués par BLIP, ce qui a donné des balises plus détaillées et ludiques.

Une autre composante importante était la reconnaissance des émotions. Nous avons utilisé DeepFace pour analyser le visage recadré et déterminer l'émotion dominante, avec un score de confiance. Enfin, nous avons intégré la reconnaissance faciale à l'aide du modèle InceptionResNetV1 pour identifier si la personne avait déjà été vue. Si c'était le cas, nous réutilisions la description d'apparence existante pour éviter un traitement redondant.

La capture audio utilisait le microphone intégré des lunettes pour pouvoir capter le mot déclencheur et démarrer l'enregistrement audio afin d'analyser l'intention de l'utilisateur dans la conversation. Le modèle utilisé était OpenAI-Whisper Turbo.

Finalement, les deux sorties du traitement vidéo et audio entreraient dans le pipeline agentique des agents LLM, chacun utilisant le modèle Llama3.1:8b. Le point d'entrée serait l'orchestrateur, en analysant le discours sous-titré de l'intention, l'orchestrateur déterminerait quel type de phrase l'utilisateur voudrait dire ensuite à son interlocuteur (le faire rire, l'insulter ou même le draguer). L'orchestrateur appellerait alors cet agent spécifique. Chaque agent aurait son propre ensemble de règles sur la façon de créer la phrase et avec quelle attitude, mais tous les agents devraient baser leur phrase sur l'émotion et l'apparence actuelles de l'interlocuteur pour ajouter de la pertinence et réduire l'aspect générique de la génération de texte. Il y avait ensuite une validation de la sortie par un agent vérificateur qui confirmerait que l'agent d'attitude a bien livré l'émotion désirée. La dernière étape du système serait de traduire cette phrase en français et en suivant le style de Cyrano de Bergerac dans la célèbre pièce d'Edmond Rostand.

Ce projet n'a pas été sans défis. L'implémentation avec les lunettes Vuzix s'est avérée plus complexe que prévu. Les lunettes ne supportaient que l'API Android 30, mais Expo, l'outil de développement qui a été utilisé pour le frontend, nécessitait au moins l'API 34. Cela a limité l'utilisation de React Native pendant le développement. L'utilisation de plusieurs modèles et l'idée du projet étant d'être une aide à la conversation, la latence devait être minimale. Lors des tests des modèles exécutés localement sur un ordinateur portable, l'inférence pouvait atteindre 30 secondes pour chaque modèle. Nous avons alors décidé d'utiliser une instance AWS G5 16XL EC2. Cela nous a permis de réduire la latence du flux complet à environ 1 seconde.

Ce projet à plusieurs niveaux a démontré la capacité d'un réseau d'agents avec différents modèles à accomplir une tâche quotidienne d'analyse de l'environnement, de déclaration d'une intention, et de détermination de la prochaine action à accomplir ou de la prochaine phrase à dire.

Équipe 3

Antoine, Daehli, Jean-Christophe

Vous êtes-vous déjà dit : « ChatGPT est tellement intelligent, mais ses réponses en noir et blanc, uniquement textuelles, ont l'air tellement plates. » Ou bien, vous utilisez ChatGPT pour tellement de choses que vous avez l'impression d'avoir de la « fatigue de chat » à force d'interagir avec des fils de discussion textuels monochromes sans fin ?

Eh bien, vous n'êtes pas seul ! Parfois, nous avons l'impression que les LLM sont bloqués à l'ère DOS de l'informatique personnelle. Ou qu'ils échangent via des connexions Internet uniquement sous forme de courriels, n'ayant pas encore découvert les possibilités d'offrir une expérience utilisateur riche avec des pages HTML/CSS.

Pensant que les LLM étaient très bons pour générer du contenu et du code, nous nous sommes donné un défi : leur fournir une interface graphique agentique qui permet aux utilisateurs de naviguer dans les LLM d'une manière plus interactive, amusante et colorée.

Notre idée principale était d'utiliser LangGraph comme outil principal pour créer un système multi-agents axé sur trois aspects : créer du contenu qui correspond aux demandes de l'utilisateur, définir des lignes directrices de design qui conviennent au contexte et aux besoins de l'utilisateur, et écrire des réponses en code HTML/CSS qui peuvent être affichées comme des pages web dans un navigateur. Avec ce plan en tête, nous espérions créer un système en boucle qui permettrait aux utilisateurs de visualiser les réponses du LLM dans une page rendue par le navigateur et de faire un suivi simplement en cliquant sur des liens intégrés qui déclencheraient les bonnes requêtes subséquentes.

Bien que nous n'ayons pas pu implémenter notre vision complète sur LangGraph dans le temps limité que nous avions, nous avons réussi à créer un pipeline LLM pour afficher les réponses en HTML/CSS et solliciter le LLM uniquement en interagissant avec ce frontend généré. Bien que de portée réduite, cette petite preuve de concept a satisfait notre curiosité en montrant en action ce que nous avions initialement imaginé : naviguer dans les LLM non pas par questions/réponses, mais par un contenu et une interface graphique générés par le modèle et infiniment cliquables !

Équipe 4

Armand, Hugo, Robin

Skynet Memes est votre guichet unique pour créer vos mèmes grâce aux technologies agentiques. D'abord, prenez ou téléchargez une photo de vous-même, choisissez un thème de mème, et si vous vous sentez d'humeur, sélectionnez un style. Notre plateforme se fera un plaisir de vous « roaster » (taquiner) rapidement pendant que vous attendez la génération de votre propre mème. Skynet Memes vous permet aussi de voir les mèmes déjà générés. Ne vous inquiétez pas, nous allons aussi « roaster » ces outputs-là !

La plateforme Skynet Memes a été bâtie avec un simple frontend React (désolé, Armand) qui utilisait Tailwind pour un prototypage rapide. Le backend, développé avec FastAPI, a permis des appels d'API faciles qui déclencheraient nos agents IA orchestrés par LangGraph. Ces agents utilisaient divers modèles via OpenRouter pour accomplir les tâches.

D'abord, un agent Descripteur se lancerait et nous donnerait une description détaillée de l'image téléchargée. Ensuite, un agent Penseur utiliserait la description de l'image et le thème de mème de l'utilisateur pour concevoir un concept. Un agent Rédacteur ferait sa magie pour nous fournir le texte. Et enfin, un agent Générateur prendrait le texte, l'image et le style de mème et générerait aux utilisateurs leur propre mème personnalisé.

De plus, nous avons utilisé un autre agent, appelé le « Roaster », pour qu'il donne son avis sur l'image de l'utilisateur, ainsi que sur les mèmes générés eux-mêmes. Cette sortie était envoyée à notre frontend, où nous avons utilisé la synthèse vocale pour « sérénader » nos utilisateurs avec des commentaires... Qui n'aime pas un peu d'humour auto-dérisoire ?

Le générateur de mèmes agentique

L'objectif du projet était de créer un générateur de mèmes en utilisant un ensemble d'agents appelés comme outils par un orchestrateur (voir diagramme ci-dessous).

Chaque nœud de ce diagramme représente un agent, avec son propre modèle : tous utilisent Gemini 2.0 (choisi pour sa vitesse d'exécution) à l'exception du rédacteur et du meilleur mème, qui utilisent GPT-4o d'OpenAI. Pour bâtir cette architecture d'orchestrateur, nous avons d'abord utilisé le SDK d'agents d'OpenAI, puis nous sommes passé à LangGraph et nous avons suivi les entrées/sorties de chaque nœud avec Langsmith en utilisant des décorateurs @traceable.

Lors de la création du mème, plusieurs catégories de style ou de sujet étaient offertes. Dans les styles, nous pouvions choisir Simpson, Noir et Blanc, Minecraft ou autres. Dans les sujets, nous pouvions orienter le mème vers « Relatable », « Facepalm », « Mood » et bien d'autres. Chaque sélection dirigeait les System Prompts de nos agents vers nos choix.

Le résultat pouvait être vu dans une galerie avec nos autres mèmes générés. Nous avons alors vu notre image de départ avec la punchline choisie par notre générateur.

Le "roast"

Les temps de génération des mèmes variaient d'environ 30 secondes (pour la version de base avec le nœud « Générateur » utilisant Gemini) à entre 1 et 2 minutes (pour la version « Meilleur mème » utilisant GPT-4o). Pendant ce temps, un autre agent était utilisé pour générer un « roast » de l'image fournie.

Deux versions du « roast » étaient alors possibles (à définir dans le code), soit la version « miel », avec un « roast » plutôt calme ou même agréable, soit une version standard avec un « roast » plutôt... piquant !

Ces « roasts » étaient également déclenchés dans la galerie lorsqu'un des mèmes générés était sélectionné pour un affichage en grand. Cela permettait aux gens de profiter de tout le « roast », de télécharger l'image et/ou l'audio associé.

Ce générateur de « roast »/mèmes nous a valu le prix du projet le plus drôle au Hackathon Osedea 2025 !

Exemple rapide

Équipe 5

Cedric, Thomas, Zack

Leur projet introduit une suite de « personas » alimentées par l'IA, conçues pour simplifier les tâches quotidiennes et augmenter la productivité, le tout géré via l'interface familière de Gmail et supporté par un outil d'automatisation des flux de travail appelé n8n.

Le concept de base des OsedeAgents est de fournir une assistance ciblée grâce à des agents IA spécialisés, rendant les processus complexes sans effort. En utilisant Gmail comme interface utilisateur graphique principale, l'équipe s'est assurée que l'interaction avec ces assistants puissants est intuitive, offrant un suivi facile de l'historique et une plateforme bien connue pour tous les utilisateurs.

Imaginez une IA qui vous prépare pour votre journée. La persona « Thierry / Charles », par exemple, excelle à recueillir des informations vitales sur les participants aux réunions et leurs entreprises respectives, s'assurant que notre équipe est toujours bien préparée. Pendant ce temps, « Marie-Pier » agit comme une aide à la communication avisée, aidant à rédiger et à peaufiner des publications LinkedIn qui capturent la voix authentique d'Osedea, en attente d'approbation avant d'être mises en ligne. Besoin d'informations rapides sur les avantages sociaux de l'entreprise ou les politiques internes ? La persona « Karine / Ivana » est là pour fournir des résumés concis et des détails.

Au-delà des tâches individuelles, les OsedeAgents simplifient aussi les efforts de collaboration. L'organisation de nos populaires « Lunch & Learn » du vendredi devient un jeu d'enfant, le système étant capable de planifier les présentations demandées par n'importe quel employé d'Osedea, de préparer les ordres du jour et d'envoyer des rappels opportuns. Le système est même conçu pour injecter une touche d'humour contextuel, en accord avec la culture unique d'Osedea. De la gestion des briefings quotidiens avec les détails d'événements et la résolution de conflits à la simplification des demandes d'informations complexes, les OsedeAgents sont conçus pour être polyvalents et incroyablement utiles.

Conclusion

Le Hackathon sur les agents IA 2025 a été un voyage formidable, alimenté par la créativité, la collaboration et juste ce qu'il fallait de caféine. Voir les équipes bâtir de tout, d'un générateur de mèmes à un assistant Cyrano propulsé par la RA, et d'interfaces graphiques interactives pilotées par des LLM à des personas IA basées sur Gmail, nous a rappelé à quelle vitesse les idées peuvent prendre vie lorsque la curiosité rencontre la détermination.

Nous avons eu beaucoup de plaisir à repousser les limites et à découvrir de nouvelles possibilités en seulement 16 heures. Si l'un de ces projets a fait germer des idées intéressantes, n'hésitez pas à nous contacter ! Nous prendrons un café, ou 10.