🚀 IA Pulse

le 5 décembre 2025

ai-PULSE 2025 : l'Europe de l'IA passe à la vitesse supérieure

Le 4 décembre 2025, ai-PULSE l'événement IA organisé par Scaleway revient pour une nouvelle édition placée sous le signe de l'ambition européenne. Avec des enceintes de premier plan, une programmation dense et une vision affirmée (« Smarter, Faster, Everywhere »), ai-PULSE s'est imposé comme l'un des rendez-vous majeurs de l'intelligence artificielle sur le continent.

Cette année, l'agenda montre clairement une direction : l'Europe veut être un acteur, pas un spectateur, dans la révolution de l'IA. # 🌍 Un début de journée sous le signe des géants : les Opening Keynotes

De 09h30 à 11h30, le Master Stage ouvre fort avec une succession de leaders techniques :

• Xavier Niel (Groupe Iliade) * Jérôme Monceaux (Outils Enchantés) * Pim de Witte (Intuition Générale) * Yann LeCun (Meta) * Rémi Cadene (UMA) * Neil Zeghidour (Kyutai) * Aude Durand (Groupe Iliade) * Damien Lucas (Scaleway)

Un mélange rare : recherche, industrie, cloud, robotique, modèles ouverts… tout ce qui façonne l'avenir de l'IA européenne réuni sur une même scène.

Voici un texte prêt à coller dans ton article, comme section « Keynote d'ouverture par Xavier Niel (avec Yann LeCun & Pim de Witte) » en français, structuré, et fidèle au contenu que tu as collé.

La keynote de Xavier : de l'IA sur écran à l'IA dans le monde réel

Xavier ouvre la conférence en posant le décor : selon lui, le plus grand changement de ces dernières années, c'est que l'IA n'est plus confinée aux écrans ni aux endpoints dans le cloud. Elle entre dans notre environnement :

• via des interfaces naturelles, * la voix, * des systèmes embarqués, * et des robots qui interagissent avec le monde.

L'IA est désormais « partout ». Mais pour l'embrasser, explique-t-il, il faut d'abord la comprendre. C'est précisément ce qu'ai-PULSE veut permettre : donner des clés pour comprendre cette nouvelle génération d'IA, au-delà du simple effet de mode.

Avant de rentrer dans le vif du sujet, Xavier remercie les partenaires de l'événement il cite notamment IMD, Ampère et les autres acteurs qui ont contribué aux démos et à l'infrastructure. Sans eux, rappelle-t-il, une conférence de cette ampleur serait impossible.

Des mots au monde : la transition vers les world models

Xavier enchaîne ensuite sur le « hot topic » du moment : comment l'IA est en train de passer d'un paradigme où elle prédit simplement le prochain mot… à un paradigme où elle comprend et simule le monde.

Il introduit la notion de modèles du monde : des modèles capables de représenter des environnements, des dynamiques, des actions et leurs conséquences. L'idée n'est plus seulement de compléter une phrase, mais de simuler ce qui se passe si un agent agit dans un environnement donné.

Pour explorer cette idée, Xavier invite sur scène celui qu'il présente comme l'un des « pères » de l'IA moderne :

• Yann LeCun, lauréat du prix Turing, professeur à New York University, auteur de centaines d'articles qui ont façonné le machine learning, et jusqu'à très récemment Chief AI Scientist chez Meta. Il glisse au passage qu'il espère que Yann pourra dire quelques mots sur son nouveau projet.

World models vs LLMs : pourquoi le langage ne suffit pas

Xavier lance la discussion en rappelant un point clé qu'il a longuement abordé avec Yann et Pim : pour beaucoup de chercheurs, il est désormais clair que « scaler » uniquement les modèles de langage ne suffiront pas à atteindre une intelligence générale.

Yann explique que l'idée des modèles du monde est ancienne dans sa réflexion : il la défend depuis près de vingt ans. Selon lui, comprendre le monde physique est bien plus difficile que comprendre le langage. Les animaux, qui ne parlent pas, sont déjà bien meilleurs que nos robots actuels pour naviguer dans le monde réel.

Il rappelle le paradoxe déjà formulé par les roboticiens : on sait entraîner des IA à passer le barreau, écrire de la poésie ou coder, mais on ne sait toujours pas construire un robot qui ait la compréhension intuitive du monde d'un enfant de 6 ans.

Pour lui, cela veut dire qu'il nous manque quelque chose de fondamental : des systèmes capables de se construire des modèles internes du monde, d'anticiper ce qui va se passer, et de raisonner sur les conséquences de leurs actions.

C'est ce qui l'a conduit à développer des architectures non génératives comme JEPA (Joint Embedding Predictive Architecture), et plus largement à défendre un nouveau blueprint pour l'IA orthogonal aux LLM classiques.

L'apport de General Intuition : de la vidéo à l'interaction

Xavier introduit ensuite Pim de Witte, cofondateur et CEO de General Intuition. Il rappelle son parcours :

• ingénieur, * ancien de chez Intel, * cofondateur de Metal, une plateforme qui a constitué un dataset massif d'interactions de jeux vidéo pour lequel OpenAI aurait proposé 100 M$, offre qu'ils ont refusée pour lancer leur propre labo.

Avec Pim, la discussion bascule sur un point essentiel : la différence entre modèles vidéo et world models interactifs.

La vidéo est une excellente source de données, explique Pim, mais regarder le monde ne suffit pas : un modèle mondial doit intégrer l'action et l'interaction. Il ne s'agit plus seulement de prédire la prochaine image « plausible », mais de prédire la distribution des futurs possibles en fonction des actions de l'agent.

Là où un modèle autorégressif « roule » sur lui-même (comme une boule de neige qui grossit en descendant la pente sans savoir ce qui l'attend), un vrai modèle mondial doit être capable de « voir le rocher en bas » et d'adapter sa trajectoire exactement comme le ferait un personnage conscient de son environnement.

Pourquoi les générateurs de pixels ne suffisent pas

Xavier ramène la discussion sur un point très concret pour les ingénieurs : pourquoi prédire des pixels n'est pas la bonne voie.

Yann explique que, dans une vidéo réelle, l'immense majorité des détails est fondamentalement imprévisible. Si l'on filme la salle et qu'on demande à un modèle : « complète la suite de la vidéo », il peut deviner qu'il y aura des gens assis, une scène, des lumières… Mais il est impossible de prédire le visage exact de chaque personne, la position exacte de chaque main, etc.

Résultat : un modèle qui essaie de prédire chaque pixel tombe soit dans le flou, soit dans le bruit, mais n'apprend rien d'utile pour l'action.

Les architectures non génératives, au contraire, apprennent des représentations abstraites des scènes et se révèlent bien plus efficaces en auto-supervision pour ce type de données continues, bruitées, riches.

Données, calcul et nouvelle vague de laboratoires

Xavier revient ensuite sur les aspects très concrets que tout le monde a en tête : les données et la puissance de calcul nécessaires.

Quelques points clés ressortent de l'échange :

• Il est plus facile d'obtenir beaucoup de données vidéo que beaucoup de texte de qualité. Là où le texte « web » plafonne vite, des années de vidéo peuvent être enregistrées ou simulées.

• Les modèles mondiaux ne doivent pas nécessairement des budgets délirants : entraîner certains de ces modèles demandent «quelques milliers de GPU», loin des méga-clusters requis pour les plus gros LLM.

• Les datasets d'actions sont précieux : hors des jeux vidéo ou de contextes très instrumentés, il est difficile d'obtenir des étiquettes d'action au niveau « ground Truth ». C'est un enjeu clé pour les prochains labs et startups.

C'est aussi là que Xavier fait ressortir le contexte européen :

• l'Europe dispose d'un vivier énorme de talents, * il y a de la place pour des laboratoires indépendants, plus ouverts, * et pour une approche de l'IA qui ne soit pas uniquement « scale LLMs à l'infini ».

Yann évoque son nouveau projet de labo indépendant (AMI Advanced Machine Intelligence), porté notamment en Europe, avec Meta comme partenaire mais pas comme actionnaire majoritaire, justement pour ouvrir le spectre des applications et favoriser une recherche moins enfermée dans le paradigme LLM.

Parfait, en chaîne avec la soirée « Yann LeCun ». Voici un texte en français, propre et structuré, que tu peux intégrer tel quel dans ton article (par exemple juste après la partie sur Xavier).

Yann LeCun : l'IA a besoin d'ouverture, pas de murs

Lors de la discussion, Yann LeCun insiste sur un point souvent sous-estimé dans le débat sur l'IA : la manière dont un modèle est gouverné compte autant que sa performance.

Il prend l'exemple des modèles chinois : même si leur niveau technique peut être excellent, une partie de la communauté reste méfiante, car ces systèmes sont contraints de respecter les principes et la ligne politique du gouvernement chinois. Autrement dit, ce ne sont pas seulement des modèles techniques, ce sont aussi des modèles idéologiques. Pour Yann, cette dimension limite naturellement leur adoption internationale.

Pourquoi l'IA a autant progressé : la force de l'open source

Yann rappelle ensuite un fait historique : si l'IA a progressé aussi vite ces dix, vingt, cinquante dernières années, c'est grâce à l'ouverture :

• logiciels open source, * publications en libre accès, * datasets et idées partagées au sein de la communauté.

Il cite le rôle de FAIR (le labo de Meta), qui a fortement poussé ce modèle de recherche ouverte et a incité d'autres laboratoires comme DeepMind à devenir plus transparents et plus ouverts, sous la pression de la compétition scientifique.

Pour lui, c'est simple :

• la recherche ouverte est le meilleur moyen de progresser vite, * et c'est aussi le meilleur moyen d'attirer les meilleurs chercheurs.

Si vous dites à un scientifique « tu ne peux rien publier de ce que tu fais », vous n'attirez pas les meilleurs profils.

JEPA : un concept récent, déjà repris partout

Yann prend ensuite un exemple très concret : JEPA (Joint Embedding Predictive Architecture). Il explique que si l'on tape aujourd'hui ce terme dans un moteur de recherche, on obtient déjà des centaines de résultats, alors que le concept n'a été formalisé que quelques années plus tôt.

En quelques années, des équipes du monde entier se sont emparées de l'idée, l'ont testée, adaptée, étendue à de nouveaux domaines. C'est exactement ce qu'il veut illustrer : l'innovation en IA ne peut pas être réservée à quelques laboratoires fermés, elle a besoin de milliers de cerveaux qui expérimentent en parallèle.

Ce qu'il faut ouvrir… et ce qu'on peut garder fermé

Yann ne défend pas une naïveté totale : il ne dit pas que tout doit être gratuit et public.

Il propose plutôt une frontière claire :

• Ce qui doit être ouvert :

  • les idées, * les architectures, * les briques fondamentales, * les prototypes de recherche.

  C'est ce qui alimente le progrès scientifique mondial.

*Ce qui peut rester propriétaire :

• l'industrialisation, * la mise en produit, * les couches spécifiques de valorisation commerciale.

Autrement dit : open source en amont, business en aval. C'est ce compromis qui permet à la fois d'avancer vite, de garder une communauté scientifique vivante, et de construire des entreprises viables.

Kyutai × General Intuition : une alliance européenne pour les modèles du monde

La discussion rebondit ensuite sur le thème des collaborations, avec l'annonce d'un partenariat entre Kyutai et General Intuition.

L'idée est la suivante :

• General Intuition doit rester très focalisé sur ses clients et usages concrets, * mais la construction des « fondations scientifiques » des modèles du monde mérite d'être déterminée dans un cadre de recherche ouverte.

Kyutai apporte ce cadre : un laboratoire de recherche européen, indépendant, qui peut publier, partager, et faire vivre une communauté scientifique autour de ces briques fondamentales. L'ambition : développer un ensemble de blocs de base (architectures, méthodes de formation, représentations) qui pourront être rendus publics, tout en laissant à l'intuition générale la capacité de les transformer en produits et plateformes.

Un futur plus global et plus collaboratif

En conclusion, Yann résume bien l'enjeu : l'avenir de l'IA ne sera ni purement américain, ni purement chinois, ni monopolisé par quelques géants fermés.

Il sera :

• global, * multi-acteurs, * construit sur une alternance de recherche ouverte et de transferts technologiques.

Et pour que cette vision fonctionne, il faut exactement ce qu'incarne ai-PULSE : des laboratoires indépendants, des partenariats entre chercheurs et industriels, et une culture de l'open source suffisamment forte pour que les meilleures idées puissent naître partout dans le monde, pas seulement dans deux ou trois bâtiments sur la planète.

Message aux ingénieurs dans la salle

Pour conclure, Xavier résume le message spécifique aux développeurs et ingénieurs :

• Il est temps d'apprendre à comprendre le monde des pixels aussi bien que celui du code et du texte. * Les opportunités sont énormes du côté :

  • des pipelines vidéo à grande échelle, * de l'infrastructure de données pour l'interaction, * des capteurs (robots, lunettes connectées, etc.), * des systèmes capables de planifier en imaginant les conséquences de leurs actions.

L'IA ne se limite plus à prédire le prochain token. Elle commence à percevoir, simuler et agir dans le monde.

C'est cette transition des LLM aux world models que Xavier a mis en lumière dans sa présentation, en s'appuyant sur les travaux de Yann LeCun et Pim de Witte : une nouvelle feuille de route pour l'IA, où l'Europe peut jouer un rôle central.

Voici un texte prêt à coller dans votre article, pour couvrir Jérôme Monceaux (Enchanted Tools) et le CEO de Scaleway. Je garde le même ton que les sections précédentes : clair, tech, mais lisible.

Jérôme Monceaux (Enchanted Tools) : des robots pensés pour les humains, pas pour les labos

Après une démonstration de robot sur scène, la transition est toute présentée : on accueille Jérôme Monceaux, PDG d'Enchanted Tools connu pour avoir fondé Aldebaran Robotics et participé à la création de robots sociaux iconiques aujourd'hui au musée.

Son nouveau projet, Enchanted Tools, mélange robotique, IA et design de personnages 3D pour créer des robots qui ressemblent moins à des machines industrielles et davantage à des « présences » dans notre quotidien.

Des robots qui doivent « danser » avec leurs utilisateurs

Jérôme explique qu'il travaille sur les robots depuis les années 90 et qu'il a beaucoup appris de leurs déployés dans la vraie vie : la manière dont les gens réagissent, ce qu'ils attendent, ce qui les rassure… ou au contraire les bloquent.

Quelques principes forts ressortent :

• Un robot doit être sûr et lisible dans ses mouvements. * L'environnement doit être conçu avec le robot : ils conçoivent également des accessoires, du mobilier et des éléments au sol pour en faciliter l'utilisation. * L'utilisateur est au centre : on ne peut pas « poser » un robot dans un hôpital ou un magasin et espérer que les gens comprennent spontanément comment l'utiliser.

Jérôme parle d'une véritable « danse » entre le robot et l'utilisateur : gestes, regards, distance, timing… tout doit être pensé pour que l'interaction soit fluide et naturelle surtout quand les utilisateurs sont des enfants, des patients, des aides-soignants, des infirmières, qui n'ont pas du tout envie de devenir experts en robotique.

Côté techno, Enchanted Tools s'appuie notamment sur :

• des briques d'IA pour l'analyse de scène (vision, compréhension de l'environnement), * des modèles de comportement et de proximité pour gérer la sécurité, * des composants de machine learning embarqués pour adapter le comportement du robot au contexte.

Environ 50 robots sont déjà déployés sur le terrain.

Anticiper, pas seulement réagir

Un point central de la vision de Jérôme : un bon robot ne doit pas réagir seulement, il doit anticiper.

Exemples concrets :

• Quand un robot tend un objet à quelqu'un, à quel moment doit-il le lâcher ? * Comment interpréter un sourire, un recul, un regard hésitant ? * Comment adapter son comportement selon qu'il a en face de lui un enfant, un adulte, un soignant pressé ?

Ces micro-détails sociaux, évidents pour un humain, sont très difficiles à modéliser. Pourtant, si on veut des robots qui vivent dans nos espaces (hôpitaux, commerces, maisons de retraite), c'est là que tout se joue.

Des robots pour les hôpitaux : impact réel, pas gadget

Jérôme insiste sur un point : ses robots ne sont pas pensés pour des vidéos virales, mais pour améliorer des situations très concrètes, notamment à l'hôpital.

Pourquoi ce choix ?

• Parce que l'hôpital est un environnement où l'impact humain est énorme. * Parce que c'est un contexte semi-standardisé : on connaît la nature du sol, la largeur des couloirs, la hauteur des portes, les règles de circulation, les contraintes de sécurité.

Ce cadre permet de déployer des robots de manière fiable, en s'assurant qu'ils ne deviennent jamais un facteur de risque.

Il raconte notamment un projet dans un service de radiothérapie pour enfants :

• Les enfants doivent entrer seuls dans un bunker de radiothérapie. * Les parents et les médecins ne peuvent pas rester dans la pièce pendant la séance. * Beaucoup d'enfants vivent ce moment comme anxiogène, au point qu'il faut souvent les sédater pour que la séance soit possible.

L'équipe médicale s'est rendu compte que ce qui manquait, c'était une présence dans la pièce.

Ils ont donc décidé d'introduire le robot d'Enchanted Tools dans le bunker, après validation des contraintes liées aux radiations. Résultat :

• une séance qui durait 60 minutes dans la douleur se transforme en moment de jeu et de complicité avec le robot ; * les enfants ne sont souvent plus sédatés ; * la productivité de la machine augmentée ; * et le bien-être des enfants, des parents et des soignants s'améliore.

Humanoïdes : utilité, joie et expérience de vie

Pour Jérôme, un robot humanoïde n'est pas là pour remplacer les humains ni pour faire « juste » de la logistique.

Son objectif :

Créer des expériences de vie dans les lieux où nous passons du temps : > magasins, hôpitaux, EHPAD, services pédiatriques…

Les humanoïdes peuvent apporter :

• de l'utilité (aider, guider, assister), * de la joie (présence rassurante, ludique), * de l'harmonie (fluidifier les interactions plutôt que les compliquer).

Ce n'est pas un robot de chaîne industrielle. C'est un robot pensé pour cohabiter avec nous, dans nos lieux de vie.

Damien Lucas (Scaleway) : bâtir l'usine européenne de l'IA

Après la robotique et les interactions physiques, place à l'infrastructure. Le PDG de Scaleway, Damien Lucas, prend la parole pour parler de ce dont tous les constructeurs IA ont besoin : des plateformes et une infrastructure robuste.

« Apporter l’IA aux données » : l’infrastructure suit la vision

Damien commence par rappeler un mantra posé lors d'une édition précédente :

Il faut amener l'IA aux données, pas l'inverse.

En 2025, cette phrase s'est traduite en vraie feuille de route :

• Scaleway a étendu sa présence au-delà de la France : Pays-Bas, Pologne, et désormais Italie, Suède, bientôt l'Allemagne, avec l'ensemble du portefeuille de produits disponible dans ces régions.

• Côté données, Scaleway a enrichi son catalogue avec :

  • Kafka, OpenSearch, Data Warehouse, * outils d'orchestration et de gestion de données… pour permettre aux entreprises d'héberger et d'exploiter leurs données au plus près de leurs workloads IA.

CPU, GPU, QPU : l'arsenal matériel européen

Sur la partie calculate, Damien déroule une stratégie en trois axes :

1. CPU pour l'IA

   • Nouvelle offre basée sur des CPU Ampere, * expérimentation autour de CPU Fujitsu, pour des workloads IA plus sobres et mieux adaptés à certaines charges.

2. Informatique quantique

   • Il rappelle qu'il y a deux ans, Scaleway a été parmi les premiers à proposer du quantum-as-a-service en mode émulation, pour permettre aux chercheurs d'explorer des algorithmes quantiques avant l'arrivée du vrai matériel. * L'année suivante, arrivée de véritables QPU via un premier partenaire. * Cette année, annonce de nouveaux partenariats avec des acteurs quantiques européens utilisant des technologies différentes :

     • systèmes à atomes neutres, * systèmes supraconducteurs. * Intégration avec les frameworks open source du moment afin que les développeurs puissent tester ces backends sans friction.

   L'idée : devenir la plateforme de référence pour le quantique en Europe, en l'intégrant directement dans les workflows IA et d'optimisation.

3. GPU, encore et toujours

   • Mise à disposition de toutes dernières générations de GPU NVIDIA sous forme de GPU Pods. * Intégration native de mesures de consommation énergétique dans ces pods, pour que les utilisateurs puissent quantifier l'impact énergétique réel de leurs charges de travail d'IA.

Models-as-a-Service : utiliser l'IA sans gérer l'infra

Damien sait que tout le monde ne veut pas gérer des clusters de GPU à la main. Scaleway pousse donc une approche « Models as a Service » :

• une offre entreprise dédiée, avec des exigences élevées en matière de sécurité et d'isolement ; * une offre plus ouverte pour les développeurs, permettant d'appeler des modèles facilement pour du texte, de l'audio, etc.

Dans ce cadre, Scaleway :

• héberge des modèles open Weights de pointe, * a noué un partenariat avec Hugging Face pour exposer plus largement l'écosystème open source, * travaille avec des acteurs européens comme Mistral : l'un de leurs modèles a été entraîné sur l'infrastructure Scaleway, et est désormais proposé en service géré.

Vers des « Usines IA » européennes

Damien conclut sur une ambition claire :

Pour que l'Europe réussisse, il faut rêver plus grand. > Pas seulement héberger quelques modèles, mais construire de véritables usines de l'IA, des AI plants et Giga plants.

Pour cela, Scaleway a :

• monté un consortium d'ingénieurs et d'experts issus de plusieurs entreprises et domaines critiques (hardware, énergie, réseaux, données, légal, souveraineté), * planifié des infrastructures capables de gérer des centaines de milliers de GPU à terme.

L'idée n'est plus seulement d'être un fournisseur de cloud parmi d'autres, mais de devenir une pièce maîtresse de la capacité de calcul IA européenne, du CPU au GPU, du quantique aux modèles gérés.

Voici un texte en français que tu peux intégrer tel quel dans ton article pour la partie voice AI / démo robot (Mochi). ## Voice AI en temps réel : la démonstration de Neil et de son « petit robot »

Après avoir parlé de modèles de monde et de robots humanoïdes, la conférence bascule vers un autre élément clé de l'IA moderne : la voix. Sur scène, on accueille Neil, chercheur qui a passé plusieurs années à repousser les limites des modèles audio, et qui vient tout juste de lancer sa nouvelle société de voice AI, née dans le prolongement des travaux de Kyutai.

De la recherche ouverte à un produit industriel

Neil commence par rappeler le contexte : chez Kyutai, le travail consistait à faire de la recherche ouverte, à inventer de nouveaux systèmes de conversation parole-parole, et à open-sourcer les prototypes.

L'idée initiale était simple :

on publie les briques fondamentales, > la communauté s'en empare > et construit des produits autour.

Dans les faits, il s'est passé autre chose :

• le marché a montré énormément d'intérêt, * mais les prototypes restaient… des prototypes :

  • latence encore trop élevée, * robustesse insuffisante, * qualité pas encore au niveau d'un produit grand public.

La nouvelle société de Neil est donc née de ce constat : séparer clairement :

• la recherche fondamentale, qui reste ouverte et publiée ; * et le travail d'ingénierie produit, qui consiste à pousser les limites de la latence, de la qualité et de la robustesse pour rendre la voix AI réellement utilisable à grande échelle.

Sa mission :

transformer la recherche de Kyutai en modèles audio « industrial grade », intégrables dans des produits concrets. ### Une équipe « full-stack audio » pour la voix de demain

Neil décrit ensuite l'ADN de la société :

• une équipe composée d'anciens de Kyutai, de Google et d'autres grands acteurs, * des experts « full stack audio » :

  • transcription, * synthèse, * traduction, * et transformation du signal.

Contrairement à beaucoup d'acteurs de la voice tech qui sont spécialisés soit en STT (speech-to-text), soit en TTS (text-to-speech), son équipe conçoit des modèles audio fondamentaux qui couvrent la chaîne de bout en bout.

Leur thèse :

• la voix n'exploite aujourd'hui « même pas 1 % » de son potentiel comme interface homme-machine ; * la voice AI va servir aussi bien à parler aux machines qu'à médiatiser des interactions entre humains :

  • traduction, * changement de voix, * personnalisation, * accessibilité, etc.

La société ne vise pas à lancer une seule application grand public, mais à fournir des briques utilisées par d'autres : des entreprises qui veulent créer des agents vocaux, des expériences audio, des NPC parlants, du support client vocal, des contenus médias personnalisés, etc. ### Un premier produit : transcription + synthèse en temps réel

À peine quelques mois après la création de la société, Neil annonce leur premier produit :

• transcription en temps réel, * synthèse vocale en temps réel, * expose via une API.

Concrètement, cela permet :

• de transformer n'importe quel agent textuel (un LLM déjà connecté à vos données) en agent vocal, * de changer la voix, l'accent, le style, sans toucher au cœur logique, * d'ouvrir un champ d'applications très large :

Parmi leurs premiers clients, il cite :

• des studios de jeux vidéo (NPC parlants, commentateurs d'e-sport), * des services de support client, * des groupes médias (contenus audio personnalisés), * des cas d'accessibilité (restauration ou augmentation de la voix pour des patients), * et même de la publicité numérique.

L'idée :

« On devient simplement le « wrapper vocal » d'un système IA qui existe déjà. ### La démo « Mochi » : un petit robot, plusieurs voix, plusieurs langues

Pour montrer concrètement ce qu'ils ont construit, Neil amène sur scène un petit robot développé par leurs amis de 3DFace.

Sur le plan technique :

• le robot est connecté à leur API voice-to-text / text-to-speech, * relié à un modèle de langage open source local, * le tout fonctionne en quasi temps réel.

La démonstration parle d'elle-même :

1. Le robot se présente avec une voix claire, naturelle, capable de moduler le ton, l'émotion et le style. 2. Neil lui demande de prendre la voix d'un « gym bro », coach de musculation : le robot répond avec une voix plus énergique, motivante, prête à « breaker des PR à la salle ». 3. Puis il lui demande de l'aider à apprendre à danser : le robot devient coach de danse, donne des consignes simples, encourage, compte le rythme. 4. Enfin, il lui demande de passer en accent québécois, en français, puis de reformuler en anglais : le robot changement de langue, d'accent et de registre, tout en gardant la même fluidité.

À la fin, Neil lui pose une question plus conceptuelle :

Comment la voix AI multilingue et multi-accents peut améliorer la communication entre humains et machines… et entre humains tout court ?

Le robot répond que la voix AI permet :

• de casser les barrières linguistiques, * de faire discuter des personnes qui ne partagent pas la même langue comme si elles étaient dans la même pièce, * de rendre l'IA moins robotique, plus personnelle. ### De l'open research au product-market fit

Neil insiste sur un point intéressant pour tout l'écosystème :

• ce qu'ils annoncent sur scène n'est pas seulement une levée de fonds ou une création d'entreprise ; * c'est déjà un produit en production, * qui traite des centaines de milliers d'appels pour leurs clients.

Comment ont-ils avancé aussi vite ?

• en réutilisant le momentum scientifique créé chez Kyutai, * en entraînant leurs propres modèles from scratch, * en construisant une nouvelle infrastructure adaptée à l'audio, * et en alignant très tôt la techno avec un besoin marché clair.

Pour Neil, c'est un modèle à suivre :

la recherche fondamentale reste ouverte et partagée, > elle fait émerger des idées et des briques technologiques, > puis des startups se créent pour pousser ces briques jusqu'au produit.

Leur ambition est assumée :

devenir un leader mondial de la voix AI. ### Et après ? Les défis qui restent pour la voix AI

Malgré la qualité de la démo, Neil rappelle que beaucoup reste à faire.

Quelques défis majeurs :

• Compréhension émotionnelle Aujourd'hui, on a encore des IA qui répondent « Super ! quand on leur dit « Mon chien est mort ». Comprendre le contexte émotionnel d'une phrase est indispensable, notamment pour :

  • la thérapie assistée, * le support sensible, * les interactions longues et personnelles.

• Robustesse en environnement bruyant La plupart des démos se font dans des environnements calmes. Mais dans la vraie vie, une voix AI devra fonctionner :

  • dans une usine, * dans un entrepôt, * dans un magasin plein de monde, * avec du vent, des bruits de fond, plusieurs personnes qui parlent. Il faut alors savoir qui dit quoi, à quel moment, à quelle distance : un problème toujours largement ouvert.

• Intégration avec la robotique Mettre de la voix AI dans des robots qui bougent, interagissent, comprennent à qui ils s'adressent et dans quelle langue, reste un défi frontière. ### Conclusion : la voix comme couche naturelle de l'IA

Neil termine sur une note optimiste : la voice AI n'est pas un gadget, c'est une couche naturelle de l'IA moderne.

• Elle rend les machines plus accessibles. * Elle permet de connecter des humains qui ne parlent pas la même langue. * Elle ouvre des usages nouveaux dans le jeu vidéo, les médias, la santé, la relation client, la robotique…

Son message aux constructeurs présents dans la salle :

"Allez sur notre site, testez l'API, parlez-nous de vos cas d'utilisation et si vous êtes talentueux, rejoignez l'équipe."

⚡ Master Stage : là où se dessine le futur de l'IA

Les conférences de l'après-midi suivent les trois axes de la conférence : Smarter Faster Everywhere (plus Optimization & Scalability).

🔧 12:05 12:20 | L'inférence partout

Steeve Morin, ZML L'accent est mis sur les performances, l'optimisation et l'exécution d'IA « partout ». Les enjeux autour de l'inférence distribuée sont au cœur de la bataille pour le coût et la rapidité.

Voici un texte en français prêt à intégrer dans ton article pour la session « Inference-powered training / ZML ». ## Inference-powered training : quand les ingénieurs IA reprennent la main sur la prod

La session « Inference-powered training » pose un constat simple mais souvent élu : l'entraînement et l'inférence sont deux mondes radicalement différents, et aujourd'hui c'est trop souvent l'entraînement (et donc Python) qui dicte les choix techniques jusque dans la production… au prix de nuits blanches pour les équipes infra.

Entraînement vs inférence : mêmes modèles, réalités opposées

Le haut-parleur commence par rappeler la différence :

• Entraînement (formation)

  • Terrain naturel de la recherche : on fait « une seule fois » un gros travail. * On privilégie l'itération rapide : plus vite on teste une idée, mieux c'est. * On ne va pas chipoter sur l'overhead : l'important, c'est le résultat scientifique. * Python est parfait pour ça : flexible, expressif, une super DX.

• Inférence

  • C'est la production, là où tout casse à 4h du matin. * On fait des milliards de requêtes. * Sur veut :

    • une latence prévisible, * une variabilité faible (P99 plat), * un code compilé, typé, maîtrisé. * Dans ce monde-là, « less is better » : chaque allocation, chaque branche compte.

Problème : dans la plupart des stacks actuelles, c'est le monde training qui gagne. Tout est conçu autour de Python, de frameworks pensés pour expérimenter, pas pour faire tourner un service 24/7.

Résultat : les « AI laborers », les ingénieurs back-end / MLOps qui doivent opérer ces systèmes, se retrouvent à bricoler autour de stacks pas faites pour eux : ils se lèvent la nuit, recollent les morceaux, gèrent la dette. ## ZML : un framework pensé d'abord pour l'inférence

Pour sortir de ce piège, l'équipe a créé ZML, un framework orienté inference-first.

Leur objectif : rendre l'inférence :

• agnostique du matériel (GPU NVIDIA, AMD, TPU, Trainium, etc.), * compilée de bout en bout, * prédictible en termes de latence, * intégrable facilement dans des environnements type Kubernetes.

Sous le capot, ZML repose sur :

• Zig (Z) : un langage compilé, moderne, très proche du métal, mais beaucoup plus agréable que le C. * MLIR / XLA : pour la partie compilation et graphes de calcul. * Bazel : pour l'écosystème build et la reproductibilité.

Avec le même code source, sans changer de ligne, ils peuvent cibler :

• des GPU NVIDIA, * des GPU AMD (ROCm), * des TPU, * du Trainium AWS, etc.

Et ce sans compromis de performance : ce n'est pas « ça tourne… mais plus lentement ». L'ambition est de coller au plus près des performances natives, en compilant le modèle « jusqu'au métal ».

Autres caractéristiques clés :

• Tout est explicite : pas de compilation « magique » en lazy JIT qu'on découvre en prod. * Cross-compilation intégrée : développer sur un Mac, cibler Linux, builder une image optimisée sans y passer deux heures de Docker build. * Packaging et runtime inclus : CUDA / ROCm, libs nécessaires et sandbox sont embarqués dans une image minimale prête à être déployée.

En résumé :

tu construis une image spécialisée, tu la déploies, et « ça tourne ». > Pas de danse infinie autour des dépendances GPU dans les containers. ## LLMD : un serveur LLM optimisé, prêt à l'emploi

Sur cette base, l'équipe a développé un premier produit : LLMD, un serveur LLM construit entièrement au-dessus de ZML.

Caractéristiques annoncées :

• Distribué en image Docker (gratuite, mais pas open source). * Cold start 10x plus rapide qu'un serveur Llama.cpp classique : on parle de secondes, pas de minutes. * Image ~4x plus petite qu'une image Llama.cpp équivalente : ~2,4 Go, incluant CUDA + ROCm. * Time-to-first token environ 3x meilleur, * Throughput (tokens/sec) amélioré de 5 à 30 % selon la plateforme.

Le tout sans tuning extrême pour l'instant : ils présentent ça comme un « point de départ » plus que comme une fin. ## Attention B : casser la complexité quadratique… depuis un CPU distant

Autre brique clé : Attention B, une solution pour attaquer de face la complexité quadratique de l'attention.

Contexte :

• L'attention est le cœur des architectures modernes (transformateurs, LLM). * Sa complexité quadratique est la raison pour laquelle :

  • on parle de contextes limités, * on a besoin de mémoire HBM énorme sur GPU, * on invente des stratégies de RAG pour contourner le problème.

Avec Attention B, ils prennent une autre route :

• Au lieu de brute-forcer l'attention sur le GPU, * ils modélisent l'attention comme un graphique et la calculent sur CPU, * parfois même sur un CPU distant, joint via un réseau 10 Gbps.

Le pipeline ressemble à ça :

1. Extraction des données d'attention depuis le GPU. 2. Envoyez sur le réseau vers un CPU distant. 3. Calcul de l'attention sur le CPU, avec un algorithme graphique plus parcimonieux. 4. Renvoi sur le GPU pour continuer le reste du calcul.

Et malgré ce détour réseau, c'est plus rapide que le calcul local sur GPU, pour deux raisons :

• le CPU n'est pas «magiquement plus rapide», * mais l'algorithme fait beaucoup moins de travail (graphe vs brute force).

Conséquences :

• Le cache KV peut être stocké en mémoire système côté CPU : → jusqu'à 2x plus de capacité pour les contextes sans toucher au GPU. * Le GPU est délesté de 30 à 70 % de son temps passé en attention : → il peut se concentrer sur ce pour quoi il est vraiment bon (matmul, dense ops). * On n'a plus besoin d'un réseau HPC ultra-exotique : → 10 Gbps suffit (25 Gbps étant encore mieux), → pas besoin d'InfiniBand monstrueux ni de tissus 800 Gbps. ## Vers une inférence écosystémique d'abord

La présentation se termine sur une idée forte : l'équipe ne veut pas juste lancer un framework de plus, mais un écosystème inference-first :

• ZML open source pour structurer la stack, * des produits comme LLMD & Attention B pour prouver que ça tient en prod, * et une approche globale où l'inférence n'est plus un « afterthought », mais un cas d'usage primordial autour duquel on conçoit les outils.

L'objectif final :

faire de l'IA un primitif fiable à intégrer dans des systèmes réels, > pas seulement un “quelque chose-AI” bricolé autour de notebooks Python.

🧠 12:25 12:55 | Agents qui font réellement le travail

BLACKBOX AI, SOCLE AI, AMD, Scaleway Le sujet central de 2025 : les agents autonomes. L'idée : ne plus simplement générer du texte ou des images, mais exécuter des tâches de bout en bout.

Voici un texte en français prêt à intégrer dans ton article pour la session « Des agents qui font réellement le travail – comment l'autonomie change la façon dont nous construisons » (12h25). ## Agents qui font vraiment le travail : où ils brillent, où ils cassent, et ce qu'il reste à inventer

Le panel réunit trois profils complémentaires :

• des builders d'agents pour les organisations où la fiabilité est critique (industrie, médical, conformité), * des builders d'agents pour le code, capables d'opérer sur des bases très complexes, * et un constructeur de puces qui conçoit le hardware sur lequel ces agents tournent, du datacenter jusqu'au rover sur Mars.

L'objectif : comprendre où les agents apportent de la valeur, où ils échouent, et comment ils transforment la manière de construire des systèmes. ### Où les agents sont déjà utiles aujourd'hui

Les intervenants écoutent plusieurs terrains où les agents ne sont plus de la science-fiction :

• Code & développement logiciel

  • agents qui lisent les logs de production en temps réel, * identifient une erreur, * patchent le code, * ouvrent une pull request, lancent les tests, * et, si l'équipe l'autorise, merge et déclenchent un nouveau déployé, avec rollback possible. On parle de « full self-coding », déjà disponible publiquement.

Industrie et sécurité

• agents déployés sur des sites à risque (plateformes pétrolières, chantiers, etc.) qui analysent des capteurs, des alertes, des caméras et signalent des situations dangereuses avant qu'elles ne dégénèrent.

• Soins médicaux et surveillance

  • systèmes qui suivent l'état des patients via des capteurs multiples et déclenchent des actions ou des alertes selon des seuils prédéfinis.

• Éducation personnalisée

  • agents capables d'adapter le contenu, le rythme et la difficulté à l'attention réelle de l'élève, pas à un profil théorique.

• Transcription et conformité légale

  • exemple d'un cabinet d'avocats qui utilise un pipeline d'IA pour transcrire des auditions internes, mais avec un contrôle humain final obligatoire pour garantir une exactitude à 100 %, impossible à garantir avec l'IA seule. ### Agents autonomes, mais pas sans humains : l'importance du « human-in-the-loop »

Tout le panel est d'accord sur un point clé : à court et moyen terme, les humains restent dans la boucle.

• Dans la sécurité, l'éducation, le médical ou le code, les agents proposent, mais ce sont les humains qui valident les décisions structurantes. * Dans les workflows de code avancé, l'agent peut :

  • corriger un bug, * pousser une branche, * ouvrir une PR, * exécuter les tests, mais c'est l'ingénieur qui décide (ou non) d'autoriser la fusion automatique en production.

À long terme, certains imaginent des agents dépassant le niveau humain sur certains domaines, avec moins de validation manuelle. Mais aujourd'hui, confiance et UX imposent encore une supervision humaine. ### Les gros problèmes non résolus : monde physique, souveraineté, sécurité, UX

Les intervenants pointent plusieurs verrous majeurs :

1. Le monde physique est beaucoup plus dur que le texte

   • un agent dans un hôpital, un drone ou un robot doit :

     • percevoir (vision, son, capteurs), * raisonner en temps réel, * planifier une action, * exécuter, * apprendre de ses erreurs. * c'est d'un ordre de complexité bien plus élevé que de traiter des tokens dans un LLM.

2. Souveraineté & conformité (surtout en Europe)

   • beaucoup d'équipes pensent encore que souveraineté = moins de performance. * le panel insiste : c'est un faux dilemme. * le vrai sujet, c'est de construire des stacks performantes, mais souveraines et conformes (notamment pour la santé).

3. Sécurité et modèles fermés

   • les entreprises sont tentées d'utiliser des modèles fermés très performants, au prix de la sécurité et de la maîtrise des données. * en parallèle, les modèles open source deviennent suffisamment bons pour justifier des architectures chiffrées de bout en bout, où l'entreprise sait ce qui tourne, où, et comment. * un des intervenants mentionne la mise en place d'un agent entièrement chiffré de bout en bout : l'utilisateur sait qu'il utilise un modèle open source, et non un modèle fermé opaque.

4. UX & « prompting » comme facteur limitant

   • la valeur extraite d'un agent dépend énormément de la capacité de l'utilisateur à bien le pilote. * si l'agent dépasse le niveau technique de l'utilisateur, ce dernier peut être incapable d'évaluer si la réponse est bonne… alors même que l'agent a fait un travail excellent. * conclusion : les agents doivent être pensés UX-first, pas juste « API-first ». ### IA hybride : agents dans le cloud, sur Terre… et sur Mars

La partie hardware rappelle que l'IA ne vit pas seulement dans un datacenter :

• AMD fournit des puces pour :

  • des voitures (Subaru iSight, ultra faible latence), * des avions, des satellites, * le rover sur Mars, * des systèmes de détection ultra-rapide (comme au CERN) où l'on doit analyser des événements en nanosecondes.

Ces puces issues du rachat de Xilinx combinent :

• CPU embarqué, * accélérateurs IA, * logique programmable (FPGA).

Cela permet un modèle hybride :

• Edge / Endpoint : perception + décision critique en local, ultra faible latence, consommation minime. * Cloud : raisonnement lourd, entraînement et ré-entraînement, agrégation de données.

À terme, avec la progression des performances/watt, un smartphone ou un appareil edge pourra exécuter des capacités aujourd'hui réservées au GPU de datacenter. ### L'agent, ce n'est pas juste un LLM avec des outils

Le panel insiste : un agent, ce n'est pas simplement un LLM + quelques outils.

Il faut aussi :

• un protocole (MCP, architectures multi-agents, etc.), * une enveloppe d'exécution (conteneur, VM, sandbox) qui définit ce à quoi il a le droit d'accéder :

  • commandes terminal, * fichiers, * secrets, * clients (navigateur, mobile, etc.), * une sécurité zero-trust : même à l'intérieur du pare-feu, personne n'est considérée comme « de confiance » par défaut.

Pour le code, par exemple :

• les agents tournent dans des environnements isolés qui simulent au mieux la prod, * on leur donne accès à des clients réalistes (navigateur, app mobile) pour tester des scénarios complets, * l'environnement est presque aussi important que le modèle lui-même. ### Mesurer, benchmarker, garder le contrôle

Question clé : comment savoir si un agent fonctionne bien, alors que tout est plus “flou” que dans le ML classique ?

• Oui, il existe des benchmarks publics (SWE-Bench, SWE-Lancer en code, etc.) utiles comme repères. * Mais ils ne permettent pas la complexité des systèmes réels.

Les intervenants défendent une approche centrée utilisateur :

• définir des métriques liées au contexte d'usage réel, * suivre :

  • les tâches effectivement accomplies, * les fusions acceptées par les humains, * les corrections validées, * construire des repères internes, continue, plutôt que s'en remettre uniquement aux scores publics. ### Coûts & futur : où part l'argent, et comment en sortir

Sur la question des coûts :

• aujourd'hui, le gouffre, ce sont les racks GPU, le réseau, la mémoire HBM – surtout avec les modèles de raisonnement qui génèrent énormément de tokens internes. * à chaque génération, le matériel devient plus performant… mais les modèles deviennent plus lourds.

À long terme, une partie de la solution est claire :

• déplacer une grande partie des charges de travail vers l'edge, * profiter du fait que les appareils grand public rattrapent (et dépassent) d'anciennes générations de supercalculateurs, * concevoir les agents comme des conteneurs légers, déplaçables, capables de vivre :

  • dans le cloud, * sur un endpoint, * ou sur une machine locale. ### Garder les agents dans les clous : échecs courants et garde-fous

Enfin, comment éviter qu'un agent ne parte en réalité :

• Limiter ses permissions : décider de préciser à quoi il a accès (fichiers, secrets, commandes, API). * Mettre des garde-fous de supervision :

  • notifications (Slack, SMS, appels vocaux automatiques) lorsque l'agent est bloqué, * demandes explicites de validation humaine pour certaines actions critiques. * Donner de la visibilité aux utilisateurs : tableaux de bord, logs, explications pas à pas – pour que l'utilisateur puisse comprendre, rejouer, corriger.

Le panel se termine sur cette idée : les agents existants déjà dans les systèmes, sur l'edge, dans les usines, dans le code. Mais leur succès dépendra moins de la magie des LLM que de la qualité des protocoles, de l'UX, de l'infra et des garde-fous que nous mettrons autour.

⚡ 13:00 13:15 | Au cœur du modèle T2I open source de Photoroom

Les coulisses d'un modèle texte-vers-image européen puissant et ouvert.

Voici un texte en français prêt à coller dans ton article pour la soirée Photoroom / PRx.

Photoroom : entraîner son propre modèle T2I… et l'ouvrir au monde

Sur scène, Yoann Almazan et David Berthouin, chercheurs chez Photoroom, viennent raconter quelque chose qu'on ne voit presque jamais : l'envers du décor des modèles de génération d'images.

On connaît tous la magie perçue de Stable Diffusion, Flux, Midjourney, DALL·E et consorts. Mais rarement le coût réel :

• après 200 heures GPU, le modèle ne sait même pas reconnaître une forme, * après 1 000 heures, on obtient à peine quelque chose qui ressemble à une bouteille, * après 10 000 heures, ça commence à ressembler à une vraie bouteille de vin, * après 50 000 heures, on retrouve des matières, des reflets, des détails.

Autrement dit : c'est beau à la fin, mais c'est lent, douloureux, cher et fascinant à décortiquer.

PRx : un modèle léger, open source, documenté de bout en bout

Photoroom a décidé de faire un truc rare :

entraîner son propre modèle texte→image from scratch, > le publier en open source, > et documenter tout le processus, y compris ce qui n'a pas marché.

Ce modèle s'appelle PRx :

• Taille : ~1,2 milliard de paramètres (à comparer à Flux ~20B – on est clairement sur un modèle « léger »). * Licence : Apache 2.0, utilisation commerciale autorisée. * Ressources :

  • code, * expériences, * ablations, * résultats intermédiaires, tout est public, y compris les essais ratés.

L'objectif :

• offrir un « playground sérieux » aux chercheurs, étudiants, équipes R&D qui veulent :

  • comprendre comment se construit un modèle de diffusion, * tester de nouvelles idées sans 10 000 GPU-jours, * et disposer d'un modèle assez léger pour itérer rapidement, y compris sur des GPU de « simple mortel ».

En interne, ce travail a eu plusieurs impacts :

• Compréhension profonde de la génération → meilleure maîtrise des modèles d'édition d'images et des fonctionnalités côté app. * Pipeline réutilisable → toutes les techniques validées sur PRx ont été réinjectées dans les modèles de production. * Communauté → un Discord très actif, qui n'existerait pas sans l'ouverture complète du projet. * Marque & embauche → le projet rend visible un niveau de travail qui, sinon, serait resté enfoui dans des cahiers internes.

Rappel express : commentaire fonctionnant les modèles de diffusion

Yoann prend 1 minute pour remettre tout le monde au même niveau.

• En génération

  • on part d'un pur bruit, * étape par étape, le modèle apprend à retirer le bruit dans la « bonne direction » (par ex. « une bouteille de vin sur une table en bois »), * en ~20–50 pas, on obtient une image cohérente.

• En entraînement, c'est l'inverse :

  • on part d'une vraie image, * on y ajoute progressivement du bruit, * on montre au modèle :

    • l'image bruitée, * le texte associé, * la cible « propre », * et on lui demande de prédire l'image (ou le bruit) à chaque niveau de dégradation.

Intérêt : on n'a pas besoin d'annotations complexes ; juste des paires (image, texte). Problème : il en faut des centaines de millions, voire des milliards.

Accélérer avec un modèle léger : architecture + recette d'entraînement

Avec PRx, l'équipe s'est fixée deux contraintes :

1. Un modèle assez léger pour tourner sur des GPU accessibles. 2. Un entraînement le plus rapide possible, sans sacrifier la qualité.

Deux leviers classiques en ML :

• Architecture : analyser les modèles SOTA (Stable Diffusion, SDXL, etc.) → identifier les briques vraiment cruciales → les recombiner dans une architecture plus compacte.

Résultat :

• PRx est ~60 % plus léger que certaines architectures récentes,

• ~40 % plus rapide à entraîner / inférer,

*sans chute notable de qualité.

• Recette d'entraînement : intégrer les meilleures techniques récentes pour converger plus vite. David en détaille une, simple à comprendre mais très efficace : la re-captionisation riche.

Ré-annoter tout le dataset pour apprendre plus avec les mêmes images

Point de départ : les datasets web (LAION & co.) sont extrêmement hétérogènes.

• Ça contient :

  • des photos sublimes, * des images de catalogue, * des cultures bizarres, * des images moches avec bordures blanches, * etc.

Traditionnellement, beaucoup d'équipes :

1. Entraîner sur tout le dataset, 2. Puis affiner sur un sous-ensemble « propre » filtré par heuristiques.

Problèmes :

• Difficile d'automatiser un filtrage parfait. * Le réglage fin sur un sous-ensemble peut faire « oublier » certains concepts appris au départ.

Photoroom explore une autre voie : au lieu de changer les images, pour enrichir radicalement les légendes.

Du « chat sur une chaise » à des descriptions ultra détaillées

Exemple simple :

• Si on montre au modèle seulement des images légendées « un chat sur une chaise », il finit par apprendre grossièrement « qu'est-ce qu'un chat ? ».

Mais si on légende :

• « un chat orange sur une chaise », * « un chat blanc sur une chaise »,

alors le modèle peut :

• désentrelacer les concepts :

  • « chat » ≠ « orange » ≠ « blanc », * « orange » devient un concept réutilisable ailleurs (voiture orange, canapé orange, etc.).

Photoroom pousse cette idée à l'extrême :

• ils passent tout leur jeu de données par des modèles vision-langage SOTA, * ils demandent des descriptions très riches, * chaque image se voit dotée de dizaines de concepts explicites : style, matière, couleur, lumière, contexte, etc.

Un prompt initial du type :

« chat tigré endormi sur un fauteuil roulant »

devient quelque chose comme :

« Un fauteuil roulant blanc minimaliste dans un studio lumineux, avec un chat tigré endormi, lové sur le siège, des ombres douces, un éclairage vif, etc. »

Paradoxe intéressant :

on rend les légendes plus complexes, > pour rendre l'apprentissage plus efficace, > avec exactement les mêmes images.

Le modèle apprend plus de concepts, mieux séparés, pour un coût d'échantillon identique.

Pourquoi c'est important pour l'écosystème

Ce que montre Photoroom avec PRx, c'est qu'on peut :

• faire de la vraie recherche appliquée en T2I sans être une Big Tech, * outiller la communauté avec :

  • un modèle léger, * une licence permissive, * des logs d'expériences et d'échecs, * et prouver qu'une approche qualité de dataset + ingénierie d'architecture + transparence peut rivaliser sérieusement.

Pour la communauté IA comme pour les constructeurs produits, PRx est autant :

• un modèle utilisable, * qu'un cas d'étude vivant de ce que ça veut dire, concrètement, de former un modèle de génération d'images en 2025.

🌐 13:20 13:50 | Du laboratoire au produit (Modèles vocaux)

Kyutai + Indigo.ai explique comment transformer des modèles vocaux en produits industriels.

Voici un texte prêt à intégrer dans ton article pour la soirée « Du labo au produit avec des modèles vocaux européens » (Kyutai + Indigo AI).

Des modèles de voix européens : de la recherche au produit

Sur scène, deux mondes se rencontrent :

• Neil Zeghidour, chercheur en parole chez Kyutai (Moshi, modèles TTS, STT, traduction, etc.), * Enrico Bertino, co-fondateur d'Indigo AI, leader italien des assistants conversationnels en entreprise (avec, au passage, un BERT italien qui porte littéralement son nom : Bertino).

Ensemble, ils présentent un constat simple : l'audio est l'interface la plus naturelle… et la plus compliquée à maîtriser.

Pourquoi la voix est beaucoup plus dure que le texte

Neil rappelle un ordre de grandeur qui calme tout le monde :

• 1 heure de parole enregistrée ≈ 700 Mo d'audio brut, * la transcription texte de cette heure ≈ 50 000 fois moins d'information.

Le texte est :

• compact, * structuré, * optimisé par des millénaires d'évolution culturelle pour transmettre de l'information.

La voix, elle, est :

• massivement redondant, * extrêmement variable (accent, timbre, micro, bruit, émotion, contexte), * porteuse de signaux non verbaux : rythme, hésitations, sourire, colère, fatigue…

Même phrase, mille façons de la prononcer mais un système doit toujours comprendre la même intention (« Quelle est la racine carrée de 9 ? »), que ce soit dans la montagne avec un vieux micro pourri ou sur scène à Paris avec un casque diffusé.

Enrico complète avec le point de vue produit :

• au début, ils pensaient : « la voix, c'est juste un canal en plus pour nos chatbots » ; * en pratique : c'est un autre monde :

  • si tu rate un mot à l'oral, tu peux perdre le sens entier, * tu ne peux pas « relire » comme sur du texte, * il faut gérer le budget de latence, les interruptions, le tour de parole, la prise de confiance.

Évaluer la qualité : métriques objectifs vs ressenti humain

La voix transporte de l'émotion, et c'est précisément ce qui rend son évaluation toxique :

• côté « machine », on peut mesurer :

  • taux d'erreur de mots (WER), * taux de mots mal prononcés, * latence moyenne, etc. * mais côté humain, tout peut être biaisé par :

  • l'humeur du testeur, * la voix choisie, * un seul mot critique mal transcrit (date, montant, nom propre) qui ruine l'expérience.

Enrico raconte un cas client :

• version 1 : le client teste un voicebot, trouve la qualité « pas au niveau, pas prêt pour la prod », * ils ne changent quasiment rien côté agent, seulement quelques paramètres de voix / rendu, * version 2 : * « parfait, on le met en prod demain »*.

Même pipeline, même intelligence derrière seule la perception a changé.

D'où la nécessité de combiner :

• tests objectifs (métriques, benchmarks), * évaluations subjectives façon « Clinical Trial » : double-aveugle, anciens vs nouveaux modèles mélangés, large panel d'écoute, sans dire aux testeurs « c'est la nouvelle version ».

Deux grandes architectures : cascade vs parole-parole

Aujourd'hui, deux architectures dominantes.

1. Architecture en cascade (ASR → LLM → TTS)

Pipeline « classique » :

1. ASR : conversion de la voix en texte (streaming). 2. LLM / agent : compréhension, raisonnement, appels d'API, RAG, outils métiers. 3. TTS : réponse vocalisée dans la voix cible.

Avantages :

• parfait pour plugger de la voix sur un texte existant :

  • bots métiers, workflows d'API, systèmes bancaires / assurance, etc. * facile d'ajouter :

  • appels de fonctions, * RAG, * formats complexes (tableaux, chiffres, résumé structuré).

Limites :

• obligé de découper en tours de parole (turns) : → dès qu'on sort d'un dialogue propre, ça casse (interruptions, chevauchements, back-channels, etc.), * la latence peut vite dériver :

  • attendre la fin perçue d'une phrase, * capturer les petits « euh », « oui, en fait », * envoyer au LLM, * attendre la réponse, → on fini parfois à plusieurs secondes de délai.

Enrico note que la cascade reste très adaptée aux cas :

• Client de service entrant :

  • questions complexes, * appels d'API bancaires / assurance, * l'utilisateur s'attend à ce que ça prend quelques secondes, * on peut « masquer » la latence avec des trucs UX (« Je vérifie vos informations… »*).

2. Architecture vocale native

Ici, le modèle :

• prend directement l'audio en entrée, * génère directement de l'audio en sortie, * gère le dialogue sans découper en tours stricts.

Forces :

• latence 200 ms possible, au niveau humain, * gestion naturelle des interruptions, des chevauchements, des “hmm”, des “oui” pendant que l'agent parle, * expérience beaucoup plus fluide → ce qu'on a vu sur scène avec le robot Richie Mini.

Faiblesses actuelles :

• difficile à brancher directement sur un LLM / API existant :

  • il faut inventer des stratégies hybrides, * ou réentraîner des modèles plus complexes qui « parlent et pensent » à la fois, * pour une grosse boîte qui a déjà investi des fortunes dans un LLM texte, → * « rajouter la voix »* devient un nouveau chantier complet : tests, perf, sécurité, conformité…

Enrico souligne que le discours brille surtout dans les cas sortants :

• c'est le bot qui appelle le client, * conversations rapides, multi-tours, beaucoup d'interruptions possibles, * l'agent pose des questions, l'humain répond vite, * la cascade devient fragile, là où la parole reste fluide.

Agents hybrides : un « petit modèle vocal » piloté par un « grand cerveau »

Chez Kyutai, Neil décrit une approche intéressante :

un petit modèle Speech-to-Speech, > qui gère la conversation en temps réel, > et qui appelle ponctuellement un grand modèle (LLM/agent) lorsqu'il a besoin de réfléchir.

En pratique :

• le petit modèle :

  • comprend ce que dit l'utilisateur, * improvise, relance, rassure, * gérer les silences, les “attendez”, les reformulations, * quand il atteint une question “dure” (chiffres, logique, back-office, etc.), → il demande de l'aide au gros modèle (le fameux “joker”), * pendant que le LLM réfléchit, le modèle vocal peut continuer à parler : “Je regarde vos dernières opérations…”, “Je vérifie ça pour vous.” * dès que la la réponse arrive, il la reformule en audio.

Deux bénéfices majeurs :

1. UX fluide par design (les « trucs UX » sont intégrés dans l'architecture). 2. Robustesse à la connectivité :

   • le petit modèle peut tourner en local sur le périphérique, * si la connexion tombe, la conversation continue, * seules les tâches « complexes » nécessitent un retour réseau.

Enrico, côté Indigo, appelle ça un « agent factice » :

• un agent vocal qui sait :

  • écouter, * reformuler, * rassurer, * gagner du temps, * pendant que le gros cerveau (LLM + APIs + RAG) fait le boulot en arrière-plan.

Accents, diversité et équité d'accès

Autre sujet : l'équité.

• Si tu parles « anglais CNN », tout marche. * Si tu parles avec un fort accent, une dialecte ou un mélange de langues (cas suisse ou italien), beaucoup moins.

Pour que les systèmes soient réellement inclusifs, il faut :

• des données d'entraînement issues de locuteurs très variés, * des annotateurs qui comprennent vraiment les accents / dialectes ciblés :

  • même un Français natif peut peiner à transcrire correctement un Québécois, * des modèles multilingues / multi-accents robustes.

Enrico explique que :

• l'ASR est aujourd'hui la partie la plus délicate, * en Suisse par exemple, ils doivent gérer 4 langues dans le même flux, * la plupart des systèmes demandant de fixer la langue au début de la conversation, → les bascules en cours de route sont mal gérées.

Pour le TTS, ils jouent au contraire avec les accents :

• en Italie, ils préférent des accents légers (Rome, Sicile…) plutôt qu'un italien totalement neutre, * ça rend le bot plus chaleureux, moins « voix robot de central téléphonique ».

Le vrai travail : contrôle, conformité et téléphonie

Enrico distingue deux gros chantiers pour amener tout ça en entreprise de production :

1. Contrôle et conformité

Derrière la « simple » brique ASR → LLM → TTS, il faut :

• garde-fous (ce que l'agent peut dire ou pas), * obfuscation / masquage des données sensibles, * gestion de la vie privée (RGPD, stockage, droit d'accès, etc.), * surveillance et auditabilité des conversations, * latence maîtrisée malgré ces couches de contrôle.

C'est un monde à part, qui demande :

• d'autres compétences, * d'autres outils, * une culture proche de la sécu / gouvernance.

2. La couche télécom, héritée des années 90

Pour passer du chatbot web au voicebot téléphonique, Indigo a dû :

• Plonger dans le monde SIP, PBX, PSTN, call centres, * gérer le handover fluide vers un humain, * construire en interne une équipe de téléphonie dédiée.

La pile télécom n'a pas été pensée pour l'ère des LLM, et l'intégration est loin d'être triviale.

Et maintenant ? Deux « big unlocks » pour l'Europe

Pour conclure, les deux intervenants reviennent sur ce qui, selon eux, va débloquer la suite :

1. Un écosystème européen durable

   • Sur n'a ni Google, ni Meta, ni les mêmes VCs que la Silicon Valley. * Pourtant, en IA, l'Europe est bien partie (Kyutai, Mistral, pangée des labs, etc.). * Pour garder l'avance, il faut des modèles économiques soutenables :

     • pas seulement des démos spectaculaires, * mais des entreprises qui respectent dans la durée.

2. La latence côté humain, plus côté IA

   • Aujourd'hui, la friction vient souvent de l'agent : latence perçue, coupures, étrangetés. * Avec des parole-parole à 200 ms, l'objectif est que le « bouchon » vienne du temps de réflexion humain, pas de la machine.

«Le vrai tournant, ce sera quand la latence ressentie viendra de l'utilisateur, et non plus du système d'IA.»

📡 13:55 14:10 | Limites de traduction et de transformation

Un talk de Translated sur les frontières actuelles des modèles autorégressifs.

Voici un texte prêt à mettre dans ton article pour la partie « Translation to Translation ».

Vers le traducteur universel : quand la traduction devient un laboratoire d'AGI

Pour Translated, la traduction n'est pas juste un service linguistique : c'est un terrain d'entraînement idéal pour l'intelligence artificielle générale.

L'intervenant pose le cadre dès le début :

• Toutes les espèces ont développé le contrôle moteur. * Mais aucune, à part l'humain, n'a développé un langage complexe. * C'est par le langage que l'on coopère, qu'on se projette dans le futur, qu'on aligne nos intentions.

« Certains pensent que le problème le plus important, c'est d'aller sur Mars. > Moi, je pense que le plus important, c'est qu'on se comprend déjà sur Terre. »

C'est ce problème-là que Translated attaque : comprendre toutes les langues, dans les deux sens, sans perte de sens.

Mesurer le progrès : non pas en FLOPS, mais en secondes par mot

Plutôt que de raisonner en « taille de modèle » ou « tokens vus », Translated utiliser un indicateur super concret :

Combien de temps met un traducteur pro > pour corriger la traduction de la machine, mot par mot ?

Ils mesurent :

• le temps de post-édition par mot, * année après année, sur des traducteurs professionnels.

Résultat historique :

• de 2010 à 2023 : courbe quasi linéaire vers la « singularité humaine », * cette singularité est fixée à 1 seconde par mot : → le moment où l'humain ne modifie plus rien, il ne fait que valider.

Jusqu'il ya peu, la projection disait : on atteindra ça vers 2027.

Mais en mettant à jour la courbe avec 2024–2025, surprise :

• la courbe ralentit, * la droite « tout droit vers la singularité » se casse, * on se retrouve plutôt à l'horizon 2030-2032.

Même ressenti côté utilisateurs :

• GPT-5 n'est pas un choc comme GPT-4, * 5.1, Gemini 3 : ce sont des améliorations incrémentales, pas des ruptures.

La question devient : jusqu'où peut-on aller avec l'approche actuelle, autorégressive, word-first ?

La traduction : un « gym » brutal pour les modèles

Pourquoi la traduction est un excellent test pour l'AGI ?

Parce que, contrairement à un chatbot générique :

*on n'a pas le droit d'halluciner :

• inventer une phrase ou un fait en trad est immédiatement visible, * la moindre hallucination fait rire… ou fait perdre un contrat. * Il faut une cohérence fine :

• garder le sens, * respecter les contraintes (longueur, ton, terminologie), * ne pas « lisser » ou simplifier le contenu.

La traduction force le modèle à développer un véritable modèle du monde, pas seulement un modèle de texte.

Quand les coûts d'entraînement explosent

Historiquement, Translated entraînait ses modèles de bout en bout :

1. Modèle de langue (LM). 2. Modèle de traduction spécialisée (MT).

Chronologie :

• modèles statistiques → * modèles neuronaux (vers 2010) → * Transformers → * gros LLM ouverts + mise au point.

Le problème, ce sont les coûts d'entraînement :

• autrefois : 100 heures GPU pour un modèle, * puis : 1 000 heures (gros, mais gérable), * aujourd'hui : 5 millions d'heures GPU rien que pour du fine-tuning, * et ~20 millions d'heures pour un full pre-train… pour un modèle qui vivra 1 an.

Conclusion :

apprendre un modèle propriétaire complet n'a plus de sens économique à chaque génération.

Translated s'est alors appuyé sur des LLM open-source comme base… et c'est là qu'ils ont identifié trois gros angles morts.

Trois limites structurelles des LLM actuelles

1. Tokenisation cassée : la confusion commence à la première étape

Aujourd'hui, la tokenisation (BPE, etc.) est un pré-processus séparé du modèle :

• on découpe le texte en sous-unités (« cas », « ing », « ##ion », etc.), * puis seulement ensuite, on encode et on envoie dans le réseau.

Problème :

• un même segment (ex : « cas ») peut correspondre à :

  • « casa » en italien, * case, casual, cascade, etc. * l'embedding initial devient ambigu dès l'entrée, * le transformateur essaie de réparer cette ambiguïté, mais seulement jusqu'à un certain point.

Idée de Translated pour le modèle Boops :

• apprendre la tokenisation avec le modèle, via backprop, * traiter en entrée non pas des « tokens BPE », mais des octets bruts, * et laisser le réseau découvrir lui-même :

  • comment segmenter le texte, * et, à terme, comment intégrer aussi images, vidéo, signaux multimodaux.

Autrement dit :

"On ne veut plus de pré-traitement opaque. On veut un cerveau qui apprend lui-même à lire ses sens."

2. Raisonnement en parallèle, dans l'espace latent

Aujourd'hui, le raisonnement des LLM, c'est :

• autoregressif, * token après token, * avec parfois des chaînes de pensée réinjectées dans le prompt.

Mais tout se fait dans le flux de texte, ce qui impose des limitations étranges.

Exemple simple (en italien) :

« Tre parole importanti : non sei solo. »

Traduction naïve en anglais :

« Trois mots importants : vous n’êtes pas seul. »

Problème :

• « vous/êtes/pas/seul » = 4 mots, * donc la traduction correcte serait plutôt :

  « Quatre mots importants : vous n’êtes pas seul. »

Aucun modèle actuel ne gère ça proprement, car il doit :

• les mots, * décoder en même temps, * dans un flux où tout est mélangé compter.

Le cerveau humain, lui, fait différemment :

• plusieurs zones traitent en parallèle (vision, langage, logique…), * la « connectivité fonctionnelle » permet de raisonner avant de parler, * puis seulement ensuite sur produit une sortie.

Objectif de Boops :

• déplacer le raisonnement dans un espace latent interne, * laisser le modèle :

  • manipuler des représentations abstraites, * vérifier des contraintes (compter, aligner, contrôler), * avant de générer le texte final.

3. Apprendre pendant l'inférence : de l'expérience, pas seulement des données passées

Dernière limite :

On ne dépassera jamais l'intelligence humaine cumulée si l'on se contente de recycler des données humaines passées.

Les humains apprennent :

• un peu par supervision (livres, cours, corrigés), * beaucoup par expérience directe :

  • essayer, rater, recommencer, * sans qu'un « oracle » explicite donne une récompense numérique, * en se donnant soi-même des objectifs, des valeurs, une forme d'agence.

Traduit a déjà exploré ce principe en 2017 :

• en traduction, ils ont laissé le système apprendre en continu à partir de :

  • des corrections de traducteurs, * du temps de post-édition, * du comportement réel en production. * ce retour d'expérience a significativement amélioré le modèle, * au point de contribuer à faire de Translated une entreprise proche des 100 M$ de revenus.

L'ambition maintenant :

• généraliser cette approche au-delà de la traduction, * créer des modèles qui apprennent pendant qu'ils infèrent :

  • ils décomposent les tâches, * estiment eux-mêmes la qualité / valeur de ce qu'ils font, * se ré-entraînent localement, sur la base de leur propre expérience.

Boops : un modèle européen, ouvert, orienté recherche longue

Pour pousser ces idées

• 30 M€ de financement de recherche européen, * ~100 M€ d'équivalent calcul en crédits GPU.

Feuille de route annoncée :

• 2026 : première version de Boops

  • open-weights, open-source, * ~10B de paramètres, * entraînée pour explorer :

    • la tokenisation apprise, * le raisonnement latent, * l'apprentissage en ligne. * 2027 : version ~27B. * 2028 : version finale intégrant l'ensemble des briques.

Le tout hébergé en priorité sur les infrastructures européennes (Scaleway & co.), puis ouvert au reste de l'écosystème.

Un traducteur qui explique ses choix

En parallèle de la recherche « heavy », Translated propose déjà un outil grand public :

• laratranslate.com

  • traduction de haute qualité, * et surtout : → la possibilité de demander au système pourquoi il a choisi tel mot plutôt qu'un autre.

Ce n'est plus juste « voilà la traduction » :

• le modèle expose ses critères terminologiques, * justifie ses choix de style ou de vocabulaire.

Pour la suite, Translated coordonne un consortium d'environ 70 chercheurs (Oxford, EPFL, ETH, etc.) autour de ces questions.

« Si l'un de ces sujets de recherche te parle, viens nous voir. »

📊 14:15 14:45 | Évaluation comparative de la frontière

Une nouvelle façon d'évaluer l'« AI stack » moderne : hardware, modèle, pipeline, inference.

Voici un résumé structuré et prêt à intégrer dans ton article pour la conférence « AI Benchmarking » (Micah Hill-Smith – Artificial Analysis).

📊 Benchmarking de l'IA : mesurer vraiment ce que valent les modèles

Micah Hill-Smith, co-fondateur et PDG d'Artificial Analysis, présente comment son équipe mesure et compare les modèles d'IA, les infrastructures et les puces. Leur promesse : donner aux constructeurs des données indépendantes pour choisir les bons modèles, au bon prix, pour les bonnes applications.

👥 Qui est l'analyse artificielle ?

• Site : artificialanalysis.ai * Rôle : niveaux de confiance pour :

  • mesurer l'intelligence des modèles (LLM, image, audio, vidéo), * évaluer la latence, le coût, l'efficacité, les jetons utilisés, * comparer les laboratoires, les nuages, les puces. * Clients : laboratoires de haut niveau + entreprises qui construisent des produits IA. * Outils : un Intelligence Index (score synthétique) et des datasets/évaluations personnalisés pour les besoins spécifiques.

📈Où en sont les LLM aujourd'hui ?

Ils présentent une courbe d'évolution de leur Intelligence Index depuis GPT-3.5 :

• Période « OpenAI dominé tout » après GPT-4. * Puis arrivée des modèles de raisonnement fin 2024 → gros saut de performance sur les benchmarks de raisonnement. * En 2025, les trois « frontier labs » sont au coude à coude : OpenAI, Anthropic, Google (et XAI en embuscade). * Sur les cas d'utilisation concrets (notamment le code) :

  il y a un an, les agents de code ont fait peu de choses utiles. > aujourd'hui, ils fonctionnent vraiment.

Même si GPT-5 n'a pas « senti » comme une révolution pour tout le monde, si on zoome à l'échelle 2,5 ans, le saut est gigantesque.

🧱 La stack IA vue par Artificial Analysis

Micah découpe l'écosystème en 4 canapés :

1. Applications – ChatGPT, copilotes, produits B2B, applications finales.

2. Modèles de fondation – GPT-5, Mistral Large, Qwen, etc.

3. Cloud d'inférence / APIs – Endpoints que les devs appellent (OpenAI, Anthropic, Groq, etc.).

4. Matériel / Accélérateurs – GPU (NVIDIA), TPU (Google), autres puces spécialisées.

Google est l'acteur le plus intégré verticalement (du chip aux apps). Les autres adoptent des stratégies plus partielles.

💸 IA : en même temps beaucoup moins chère… et beaucoup plus chère

Micah pose un paradoxe :

« L'IA est devenue 100× moins chère… mais vos requêtes coûtent souvent 10× plus qu'avant. »

1. Pourquoi c'est moins cher pour un niveau donné d'intelligence ?

Pour un « niveau GPT-4 » par exemple :

• Modèles plus petits + sparsité → moins de paramètres activés à chaque requête. * Optimisations logicielles d'inférence. * Nouveaux matériels plus efficaces (nouvelles générations de GPU/TPU). * Résultat : le coût pour produire un token de qualité GPT-4 a chuté d'environ ×100.

2. Pourquoi vos requêtes coûtent plus cher au final ?

Parce qu'on fait faire beaucoup plus de choses au modèle :

• Modèles plus gros au sommet (certains dépasseraient GPT-4 en taille). * Modèles de raisonnement → ils « pensent » avec des milliers de jetons avant de répondre. * Agents IA :

  • chaîne de pensée sur plusieurs appels, * recherche web, RAG, outils, * agents de code qui modifient des fichiers, exécutent du code, relancent des tests, etc.

Donc : 🧠 Intelligence par dollar augmentée. 💶 Coût par requête utile explose si tu laisses l'agent travailler longtemps.

🧠 Modèles de raisonnement & efficacité en tokens

Avant, la distinction était simple :

• modèles «normaux» vs * modèles de raisonnement (avec trace de réflexion explicite, beaucoup plus de jetons internes).

Maintenant, c'est plus flou :

• Certains modèles sans « mode raisonnement » parlent beaucoup et font quand même beaucoup de raisonnement implicite. * Certains modèles de raisonnement récents sont beaucoup plus efficaces en tokens.

L'Analyse Artificielle parle désormais plutôt de :

token efficient = nombre de tokens utilisés pour atteindre un certain niveau d'intelligence.

En pratique, pour un constructeur, il faut regarder :

• pas seulement « raisoning on/off », * mais combien de tokens le modèle consomme pour ton type d'usage (latence + facture).

🟦 Poids ouverts vs modèles propriétaires

Ils comparent la meilleure perf open-weights et la meilleure perf propriétaire :

• Le gap entre les deux reste réel… * … mais le fait marquant est que les modèles open-weights suivent le rythme de près.

Top open-weights actuels (selon eux) :

• Beaucoup viennent de Chine (DeepSeek V3.2, Minimax M2, Qwen 3, etc.). * OpenAI et également sorti GPT-OSS (open-weights). * Côté Europe : Mistral Small / Medium occupent une très bonne place, surtout en multimodal petit modèle.

Point important sur Mistral Large 3 :

• Le modèle évalué est un instruct, pas encore un raisonnement RLHF complet → il est plus token-efficient mais n'écrase pas Medium 1.2 sur leurs indices de raisonnement. * Une future version de raisonnement pourrait logiquement le placer au-dessus.

🧪 Nouveaux types de benchmarks : connaissance & hallucinations

Ils ont construit des évaluations spécifiques pour mesurer :

1. Connaissances factuelles – questions fermées où il y a une bonne réponse clairement définie.

2. Comportement face à l'incertitude – quand le modèle ne sait pas, est-ce qu'il :

   • dit « je ne sais pas / je ne suis pas sûr », ou * invente une réponse fausse avec confiance ?

Ils mesurent donc :

• Précision (pourcentage de bonnes réponses). * Taux de « hallucinations » : proportion de cas où le modèle répond faux alors qu'il aurait dû reconnaître qu'il ne savait pas.

Observation notable : les modèles d'Anthropic (Claude) sont très puissants, mais parfois mal calibrés sur « je ne sais pas » vs « je tente ma chance ».

🧬 L'« Openness Index » : à quel point un modèle est vraiment ouvert ?

Ils présentent également un Openness Index, un score pour mesurer à quel point un modèle est réellement « ouvert » :

• Pas seulement : est-ce que les poids sont disponibles ? * Mais aussi :

  • Quelles sont les conditions de licence ? * à-on accès à :

    • la recette d'entraînement, * la composition du dataset (au moins en grandes lignes), * les scripts / configs ? * Un score parfait signifiant :

  « On peut recréer le modèle depuis zéro en suivant la doc publique. »

Mistralobtient un des meilleurs scores actuels parmi les LLM propriétaires/open-weights « sérieux ».

🖼️ Au-delà du texte : image & vidéo

Micah sur termine un point important : le monde ne se résume pas au LLM texte.

Benchmark de l'analyse artificielle également :

• Génération d'images (diffusion, LLM visuels), * Génération vidéo (surtout image→vidéo), * Modèles audio / parole.

Ils utilisent notamment des « préférences arènes » : des interfaces où des humains comparent deux sorties et choisissent celle qu'ils préfèrent → ce qui permet d'évaluer des dimensions comme :

• qualité visuelle, * cohérence, * utilité perçue.

✈️ 14:50 15:05 | La première IA aux commandes d'un avion de chasse

Helsing montre que l'Europe avance aussi sur les usages sensibles.

Voici un texte clair, structuré et prêt à être intégré dans ton article, qui résume parfaitement la conférence Flight – L'IA qui pilote un avion de chasse.

🚀 Vol : Quand une IA devient copilote de combat

L'histoire de la première IA à piloter un avion de chasse opérationnel

La scène s'ouvre sur une vidéo impressionnante : un avion de chasse en vol, manœuvré non pas par un pilote humain, mais par une IA embarquée. Le chercheur de Helsing raconte comment ils ont construit Centaur, le premier copilote d'IA capable de mener un combat aérien moderne.

Et pour comprendre pourquoi c'est une révolution, il faut d'abord déconstruire un mythe…

🛩️ Le combat aérien moderne n'a plus rien à voir avec Top Gun

L'imaginaire collectif pense encore aux dogfights :

• deux avions qui se tournent autour, * les pilotes qui s'observent à vue, * l'affrontement physique et instinctif.

La réalité 2025 ? Rien de tout ça.

Le combat n'est plus visuel. Il est :

• à 10 000 m d'altitude, * à des centaines de kilomètres de distance, * entièrement piloté par des radars, capteurs, écrans, * 100 % dans l'information et la prise de décision.

C'est un jeu d'échecs 3D à grande vitesse, en pleine tempête. > Celui qui gagne est celui qui traite l'information le plus vite.

Et c'est précisément là que l'IA excelle.

⚠️ Pourquoi l'armée a besoin d'IA maintenant

Trois facteurs rendent l'IA indispensable dans les systèmes de défense :

1. La vitesse

Les menaces modernes évoluent à la seconde. Un humain ne peut plus suivre.

2. La surcharge cognitive

Un pilote doit :

• gérer radars, missiles, alliés, météo, trajectoires, * analyser des téraoctets d'information, * prendre des décisions vitales en quelques instants.

C'est trop pour un cerveau humain.

3. La maturité de l'IA

On sort du buzzword : les agents sont maintenant → fiables, → réactifs, → capables d'exécuter des stratégies complexes.

Même le ministère de la Défense du Royaume-Uni l'a déclaré :

« Nos adversaires doivent savoir que nous innovons à un rythme de temps de guerre. »

🎯 Centaur : le copilote IA pour les engagements BVR

(Hors de portée visuelle)

C'est le cœur du problème : les combats BVR, ceux où on ne voit jamais l'ennemi.

L'environnement BVR, c'est :

• information partielle, * incertitude totale, * anticipation, bluff, estimation, * décisions sous stress et sous 9G.

C'est traduit un mélange de :

🧠 Échecs → planification long terme 🎲 Poker → incertitude, bluff, probabilités

Et l'IA parfaite pour ça ? → Un agent d'apprentissage par renforcement.

🤖 Le rôle de Centaur dans le cockpit

Centaur reçoit en entrée :

• objectif de mission, * commandes humaines, * données capteurs (radar, instruments de vol…), * informations provenant d'autres avions.

Et en sortie, il produit :

1. Commandes de guidage (orientation, trajectoire, gestion des distances)

2. Recommandations tactiques (quand tirer, quand manœuvrer, quand éviter)

3. Communication d'intention → vers le pilote humain → vers les alliés

C'est un véritable copilote doté d'une vision tactique parfaite.

🧪 L'ingrédient secret : un simulateur IA-first

Les simulateurs traditionnels sont :

• très fidèles graphiquement, * conçu pour entraîner des pilotes humains.

Mais pour du RL, il faut :

• des milliards d'expériences, * de la vitesse (x100, x1000), * de la variabilité.

Helsing a donc construit un simulateur propriétaire, capable de :

• s'exécute des milliers de fois en parallèle, * tourner bien plus vite que le temps réel, * modifier aléatoirement les conditions de vol, la météo, les capteurs…

L'IA peut ainsi vivre des décennies d'expérience en quelques jours.

🧬 L'apprentissage : de zéro à expert

L'agent RL :

• ne connaît rien, * joue contre lui-même, * teste, échoue, corrige, recommence, * explore toutes les tactiques possibles.

Résultat :

Sans jamais voir une stratégie humaine, > il invente ses propres tactiques.

Tactiques émergentes enregistrées :

• feintes de missile, * gestion d'altitude pour éviter les radars, * conservation de munitions, * manœuvres anticipées selon les probabilités ennemies.

Le tout avec une performance surhumaine.

🛫 Du simulateur au vrai jet : mission Gripen

Mettre une IA au commandement d'un avion réel exige trois choses :

1. Robustesse aux incertitudes

On ne connaît jamais exactement :

• l'aérodynamique réelle, * le traitement radar exact, * les latences du matériel.

Donc l'IA est entraînée dans un environnement → plein de bruit, → de paramètres aléatoires, → de variations extrêmes.

2. Une architecture avion adaptée

Le Saab Gripen offre :

• séparation stricte entre commandes critiques et tactiques, * guidage de bas niveau ultra-fiable, * calcul embarqué suffisant.

Le pilote humain reste au cœur du système. L'IA ne touche pas aux commandes vitales directes. Elle gère la stratégie.

3. Des boucles de contrôle ultra-stables

Pour que l'IA puisse se concentrer sur les décisions de haut niveau.

✈️ La première démonstration en vol réel

L'été dernier, en Suède, Helsing et Saab ont réalisé un test décisif :

• un avion Gripen équipé de Centaur, * un autre avion piloté par un humain en face, * environnement réel, menaces réelles, données réelles.

Pendant le vol, l'IA :

• détecter l'adversaire, * mis à jour sa stratégie, * manœuvre en anticipant les mouvements ennemis, * optimiser sa position BVR en continu.

Une IA, dans un avion réel, en train de mener un combat aérien moderne.

C'est une première.

🧭 Pourquoi c'est plus qu'un pilote automatique

Helsing le répète :

Ce n'est pas un meilleur pilote automatique. > C'est un grand maître des échecs intégré dans un cockpit.

L'objectif n'est pas de remplacer le pilote. C'est de lui donner un avantage décisif dans les situations les plus critiques.

Une IA capable d'innover à un rythme de temps de guerre.

🔥 Conclusion

Centaure représente :

• la première IA réellement opérationnelle dans un avion de chasse, * une démonstration du potentiel du RL pour des décisions en temps réel, * une avancée stratégique majeure pour les démocraties occidentales.

Et Helsing recrute. Beaucoup.

🌱 15:10 15:40 | Transparence et empreinte carbone de l'IA

Scaleway + Salesforce explorent le sujet crucial de la sobriété et de la transparence énergétique.

⚙️ 15:45 16:00 | Créer une IA évolutive (Ampere)

Le futur du computing : CPU ARM, efficacité énergétique, IA pervasives.

🤖 16:05 16:25 | Des modèles fondamentaux aux actions concrètes

Scaleway + Enchanted Tools : comment passer du modèle à l'action physique (robotique).

⚡ 16:30 16:50 | Construction à la vitesse des agents

VAST Data, Semianalysis et H Company discutent des pipelines, data infra, entraînement.

🚀 16:55 17:10 | Des agents individuels aux flottes d'agents

Dust explore comment piloter des flottes d'agents, pas juste un agent isolé.

🔐 17h35 17h55 | IA et confidentialité

Proton donne une vision forte d'une IA privée et chiffrée essentielle pour l'Europe. # 📡 Central Room : quincaillerie, pharma, multimodalité, créativité et MCP

14:20 14:50 | Au-delà du refroidissement par air

L'avenir du hardware IA : refroidissement, haute densité, nouvelles architectures.

15:15 15:45 | L'IA au service de la R&D pharmaceutique

Biolevate + Sanofi : comment l'IA accélère la découverte moléculaire.

Voici un résumé clair et réutilisable de la séance « Pharmaceutique & santé publique » (12–15h15).

🎯 Thème de la table ronde

Commentez l'IA transforme à la fois :

• la surveillance épidémiologique, * la découverte de nouveaux traitements, * et la mise sur le marché de médicaments / vaccins,

dans un secteur ultra-régulé (pharma, santé publique).

Alliances :

• Joël Belafont – co-fondateur de BioElevate (ex-bâtisseur de produits tech depuis 15+ ans). * Antoine de Dorcich – co-fondateur, responsable IA chez BioElevate. * Cédric Meillet – Sanofi Vaccins, spécialiste épidémiologie & santé publique (ex-OMS). * Modération : Sophia (BioStream).

🧪 Les grandes faiblesses actuelles de la santé publique (Cédric – Sanofi)

1. Données trop lentes

   • Les systèmes de surveillance épidémiologique classiques sont rigides, basés sur des pipelines propres mais lents. * Parfois, les journaux télévisés annoncent l'épidémie avant les tableaux de bord officiels.

2. Une seule source de vérité par indicateur

   • Traditionnellement : un indicateur → une source (ex : labos, hôpitaux). * Ou aujourd'hui, on pourrait croiser :

     • logiciels de cabinets de médecine générale (GP software), * réseaux sociaux, * eaux usées, * labos privés, etc. * Exemple : en Allemagne, accéder au logiciel des généralistes permet de suivre 400 000 patients/semaine avec 48 h de retard seulement → quasiment du temps réel.

3. Sélection des souches vaccinales encore « à l'ancienne »

   • Pour la grippe : sur reformule 2×/an. * Mais la façon de choisir les antigènes à mettre dans le vaccin n'a quasi pas changé depuis 50 ans. * Peu ou pas d'exploitation :

     • des données historiques massives, * ni d'IA pour prédire les souches futures.

🤖 Où l'IA apporte le plus de valeur ? (Joël & Antoine – BioElevate)

1. Une techno « convergente »

Pour Joël, l'IA utile en santé, ce n'est pas juste « des LLM » :

• modèles classiques de machine learning, * LLM et transformateurs, * analyse de texte, d'images, de capteurs, * modèles de recherche / RAG, * agents spécialisés qui combinent plusieurs outils, * plus l'évolution des capteurs et du matériel (inférence embarquée, etc.).

Tout converge pour attaquer un problème complexe par plusieurs canaux en parallèle : quelles maladies émergent ? quelles souches virales ? Quels traitements possibles ?

2. L'état réel des LLM aujourd'hui

Antoine résume bien la situation :

« On peut attaquer n'importe quel problème complexe avec des LLM si sur la découpe en sous-tâches que le modèle sait résoudre. »

Deux limites majeures :

1. Mémoire et contexte

   • Un LLM ne peut pas ingérer brut :

     • une base de données gigantesque, * des années de littérature scientifique, * des millions de documents réglementaires. * Il faut sélectionner et structurer l'information en montant.

2. Chaînes de raisonnement longues

   • Si on laisse le modèle « penser » trop longtemps, il dérive, perd le fil, hallucine ou sort de sa mission.

BioElevate construit donc l'infrastructure autour du modèle pour correspondre à ces limites.

🧱 Innovations clés de BioElevate pour la pharma

1. Compréhension profonde des documents

• Travail très poussé sur :

  • la sémantique des documents (où se trouve la connaissance, comment elle est structurée), * pas seulement « texte brut » mais structure, sections, taxonomie.

2. Un « nouveau vector store » orienté navigation, pas seulement recherche

• Critique de l'approche standard chunking + vecteurs simples :

  • le découpage en morceaux fait perdre :

    • la structure, * le contexte global, * les liens entre sections. * on force l'IA à ne faire que de la recherche sémantique ponctuelle, ce qui est limitée.

• BioElevate propose un « magasin de connaissances » :

  • orienté navigation de connaissance :

    • parcourir les sections, * suivre une taxonomie, * explorer un corpus « comme un expert humain ». * L'agent peut se déplacer dans le document, pas seulement recevoir 3 morceaux choisis.

3. Complexes d'orchestration et de workflows

• Les questions métier sont souvent : "épidémie en vue ? quelles variantes ? quelles recommandations ?" → ce ne sont pas des questions à un seul shot. * Orchestre BioElevate :

  • un workflow complexe → en sous-workflows, * plusieurs agents spécialisés collaborent, * chacun appelle ses outils, construit une partie de la carte mentale, * le tout reste traçable et reproductible → important pour le réglementaire.

🇫🇷 Projet IOLOS : un vrai cas concret de santé publique

Cédric annonce officiellement :

• Sanofi, BioElevate, Orange, Impact Healthcare ont été sélectionnés par le cluster IDBO (santé – France 2030) pour le projet IOLOS :

  • objectif : révolutionner la surveillance des maladies respiratoires en France (grippe, COVID, etc.). * approche : multi-sources de données (GP, labos, eaux usées, réseaux, etc.) → un tableau de bord IA qui :

    • surveille en temps réel, * prévoit les vagues épidémiques/pandémiques, * alimente des applications mobiles pour le citoyen :

      « Avant de sortir en hiver, tu peux voir ton risque d'attraper la grippe ou le COVID.

• Chronologie :

  • début prévu avant mi-2026, durée 4 ans, * pilote régional vers 2 ans, * solution industrielle complète vers 4 ans.

🧬 IA & découverte de traitements (BioElevate)

Joël décrit une autre application, côté R&D thérapeutique :

• Ils ont utilisé leurs pipelines pour découvrir de nouveaux traitements sur :

  • des maladies rares ou orphelines, * des domaines comme oncologie, dermatologie, etc. * En particulier :

  • un candidat traitement en leucémie a passé des premiers tests précliniques. * Stratégie : se concentrer sur des maladies non louables pour les big pharmas (trop rares), et utiliser les agents IA pour explorer l'espace thérapeutique beaucoup plus vite.

⚙️ Innovations « pragmatiques » : invites & agents

1. Optimisation automatique des invites

• BioElevate a publié un papier sur la prompte optimisation :

  • sans changer le modèle, * ils peuvent augmenter la précision jusqu'à +60 % sur certaines tâches, * parfois mieux qu'un fine-tuning LoRA, sans risque de fuite de données sensibles dans un modèle LoRA.

• Cette techno sera intégrée au cœur de leur plateforme l'an prochain.

2. Scaling des agents : promesses et problèmes

Joël est très clair :

« Pour 10 innovations que tu poses, tu crées 10 problèmes. »

• Vision : faire passer une tâche de 1 an de clics pour des humains → à 100 000 agents qui collaborent pendant 1 heure. * Mais à chaque palier ×10 :

  • on découvre un nouveau goulot d'étranglement (infra, orchestration, transactions, monitoring, conformité), * on l'optimise, * puis le palier suivant révèle un nouveau goulot d'étranglement.

📜 Réglementation, traçabilité & confiance

Cédric (Sanofi) insiste :

• Réalité pharma : régulation lourde (agences, EMA, FDA, etc.). * Ce qui est indispensable :

  • Traçabilité : pouvoir rejouer le raisonnement, suivre les sources, expliquer le « pourquoi ». * Reproductibilité : obtenir le même résultat, avec les mêmes entrées. * Transparence : pas de « boîte noire magique » sans explication.

Sanofi a mis en place une politique « Responsible AI » (co-RAISE) : un cadre interne où les solutions d'IA doivent respecter ces exigences.

BioElevate, de son côté, conçoit ses workflows agents avec :

• historique complet des étapes de raisonnement, * sources citées, * capacité à refaire le même chemin → critique pour être acceptable auprès des régulateurs.

💉 Le « gros » problème à 5 milliards de dollars

Question « baguette magique » de Sophia à Cédric :

« Si tu pouvais demander une seule choix à BioElevate ?

Réponse :

• Améliorer massivement la sélection des souches de grippe / COVID pour les vaccins.

  • Exploiter 50 ans de données non utilisées, * utiliser l'IA pour prédire quelles souches domineront, * augmenter nettement l'efficacité des vaccins. * Il annonce aussi :

  • un atelier prévu avec l'OMS à Genève avant mi-2026, pour travailler sur l'usage de l'IA dans ce processus de sélection.

🧬 Maladies rares & médecine de précision

Sur la question des maladies très rares, souvent « pas intéressantes » économiquement :

• Joël rappelle que l'IA ne «veut» rien, ce sont les humains qui portent le projet. * Mais si on industrialise les méthodes de recherche & de conception de traitements grâce aux agents :

  on peut, à terme, envisager de développer des traitements pour quasiment tout, > y comprendre des cas ultra-personnalisés (génome spécifique, configuration unique).

C'est la vision : médecine de précision à grande échelle, rendue possible par la scalabilité des agents IA.

🧠 Message final de Joël : qui peut construire ça ?

Sophia lui demande un conseil pour ceux qui veulent se lancer dans l'IA appliquée à des secteurs critiques (santé, défense, etc.) sans être médecin/PhD :

• On ne contribue pas parce qu'on est « un génie de l'IA », mais parce qu'on a :

  • une expérience unique, * un angle de frustration fort sur un problème précis. * Les grands labs (ex : Anthropic) recrutent des profils hors IA pure :

  • l'enjeu clé, c'est formuler correctement le problème et les contraintes. * Si quelque chose te frustre dans le monde réel, tu peux :

  • t'approprier les outils IA, * construire la solution autour de cette frustration.

« Il ya l'intelligence artificielle, mais il ya surtout l'intelligence humaine qui va la mettre au service de quelque chose. »

15:50 16:05 | Taxonomie des produits Zero-shot (Veepee)

Un vrai cas d'usage du e-commerce européen.

Voici un récap clair du talk « Classification multimodale des produits chez VP (Veepee) ».

🏬 Contexte : VP (Veepee) et le problème métier

• VP = unicorn française, fondée en 2001 * 5 000 employés, 30 M de membres actifs, activité dans toute l'Europe * 5 millions de produits par an, issus de ~7 000 marques, dans toutes les verticales (sport, jardin, électroménager, etc.)

Pour chaque produit, il faut :

• fiche technique, * images, * et surtout une classification produit correcte (taxonomie interne).

Pourquoi la classification est critique ?

Parce qu'elle impacte toute la chaîne :

• Tarification : mauvaise catégorie → mauvais prix → perte de marge / perte de compétitivité. * Finance / Fiscalité : reporting, taxes, budgets → tout repose sur la bonne taxonomie. * Logistique :

  • ex : un produit classé « T-shirt » alors que c'est un « lave-vaisselle » → catastrophe en entrepôt. * Qualité actuelle des données : ~11 % d'erreurs dans le catalogue → difficile de s'en servir pour entraîner un modèle classique.

Ils ont essayé de faire un « vrai » modèle ML pendant 6 ans → échec.

Pourquoi c'est dur avec du ML classique ?

• Taxonomie non MECE (non « Mutuellement exclusive, collectivement exhaustive »)

  • ex : « T-shirt » VS « Top » → un T-shirt est un top, mais la taxonomie les sépare quand même. * Taxonomie qui évolue constamment (nouvelles tendances, nouveaux produits). * Déséquilibre massif entre catégories :

  • certaines catégories ont des millions d'items historiques, * d'autres : 3 produits (ex : « Imprimantes 3D »…). * Cold start : une nouvelle catégorie n'a pas assez de données pour l'apprentissage. * Et les données historiques sont bruitées (11 % d'erreurs…).

Conclusion : il faut un système zéro / quelques-coups, pas un gros classificateur supervisé.

🧠 Étape 1 – Zero-shot avec CLIP (baseline multimodale)

Ils utilisent un modèle CLIP (image + texte) en « classification zéro-shot ».

Principe

1. Pour chaque catégorie (≈ 1 500 catégories) :

   • transformer la catégorie en phrase :

     « Ce produit est un T-shirt », « Ce produit est un lave-vaisselle », etc. * embeddings texte → vecteurs de dimension d.

2. Versez chaque produit :

   • encoder l'image du produit → intégration de l'image. * calculer la similarité (cosinus, euclidienne, etc.) entre l'image et les 1 500 vecteurs de catégories. * prendre le Top-1 comme prédiction.

3. Variante avancée :

   • ne pas embedder seulement le nom de la catégorie, * mais aussi les métadonnées / connaissances expertes liées à la catégorie (description métier, règles, etc.).

Avantages

• Zéro formation : pas de mise au point, pas de nettoyage de données massif. * Très rapide et peu coûteux (embedding + similarités). * Gère naturellement l'ajout de nouvelles catégories (sur les embedde, point).

Limites

• Précision Top-1 ≈ 58 % (vs ~89 % pour un humain). * En Top-15, on monte à ~89 % (on fini par inclure la bonne catégorie quelque part dans la liste). * → ça ne suffit pas pour de l'automatique : c'est plutôt une assistance humaine ou un pré-filtrage.

🧠 Étape 2 – Ajout du KNN historique (similarité avec les anciens produits)

Idée : comparer le produit non seulement aux catégories, mais aussi aux anciens produits bien labellisés.

Pipeline

1. Ils identifient 1,5 M de produits historiques bien étiquetés (labels sûrs). 2. Pour un nouveau produit :

   • encoder l'image, * faire un KNN (k plus proches voisins) dans cette base de 1,5 M embeddings, * récupérer les k produits similaires (ex : top 100). 3. Récupérer les catégories de ces voisins :

   • pour ces 100 produits, collecter leurs catégories, * en extraire un Top-30 de catégories les plus fréquentes / pertinentes. 4. Combineur :

   • Top-30 des « catégories » du CLIP

   • Top-30 du KNN « produits similaires » → fusion (par ex. via un LRF / vote pondéré).

Résultat :

• Sur le Top-15 final, la probabilité que la bonne catégorie soit présente dépasse la performance humaine.

Pourquoi c'est bien ?

• Sur l'introduction d'un biais historique volontaire :

  • le modèle « imite » ce que les équipes font depuis des années, * et colle au « business logic » réel de VP. * Le coût reste très faible (embeddings + KNN sur un index vectoriel).

🧠 Étape 3 – Ajout d'un LLM multimodal pour trancher le Top-1

Là, on rentre dans le vrai générateur multimodal.

De la part du constat :

• en Top-15, le bon label est là ~96 % du temps (après CLIP + KNN). * il manque juste un « cerveau » pour choisir le bon parmi ces 15 candidats.

Entrées pour le LLM multimodal

Pour chaque produit :

1. Les 15 catégories candidates (issues de l'étape précédente). 2. L'image du produit. 3. La fiche technique / texte (titre, description, attributs…). 4. Le carnet d'étiquettes :

   • un document texte en langage humain :

     • entraîne ce que couvre chaque catégorie, * les règles métier (« on met X ici, sauf si Y », etc.), * exactement ce qu'on donnerait comme consigne à un humain.

Ce que fait le LLM

• C'est un LLM multimodal (image + texte). * Il reçoit tout le contexte (produit + 15 catégories + règles métiers). * Il faut :

  *expliquer son raisonnement, * sélectionner une seule catégorie finale parmi les 15.

Sortie :

• un JSON structuré contenant :

  • la catégorie choisie, * éventuellement le raisonnement.

Résultat

• Précision Top-1 ≈ 94 %, donc supérieure à l'humain (~89 %).

Et le tout :

• sans fine-tuning lourd sur un LLM, * en s'appuyant sur :

  • embeddings d'image, * embeddings de textes, * LLM multimodal prêt à l'emploi (poids ouverts possibles), * * la connaissance métier encapsulée dans le label book.

🧾 Propriétés intéressantes de cette approche

• Zero / few-shot de bout en bout

  • on ne dépend pas d'énormes ensembles de données propres par catégorie. * solution robuste au démarrage à froid : il suffit de créer une nouvelle catégorie, un label book, et on peut la proposer dans le Top-15.

• Adaptable à d'autres modalités :

  • actuellement : image + texte, * mais on peut imaginer ajouter :

    • métadonnées, * signaux numériques, * etc.

• maîtrisé & évolutif :

  • embeddings = très bon marché, * LLM utilisé seulement sur le top 15, pas sur tout le catalogue brut, * donc exploitable sur 5 M de produits / an.

• ROI élevé :

  • réduction des erreurs de classification → impact immédiat sur pricing, logistique, finance, expérience client.

🧩 En résumé (pattern personnalisable)

Le schéma général que vous pouvez réappliquer ailleurs :

1. Embeddage multimodal (CLIP / similaire) pour faire du zero-shot. 2. Rappel d'historique via KNN sur des données propres, pour injecter les biais & règles métier implicites. 3. LLM multimodal pour :

   • lire produit + candidats + règles métiers, * produire une décision structurée (JSON) + raisonnement.

→ Sans gros formation supervisée, tu obtiens :

• une précision > humaine, * un système souple, évolutif, peu coûteux, * capable d'absorber de nouvelles catégories très vite.

16:10 16:40 | Pipelines d'IA vidéo

AIVE, XXII, Molia : du edge inference → aux pipelines génératifs vidéo.

Voici un résumé structuré de la conférence « Video AI – de la vidéo aux données » (14h–16h10).

👥 Les intervenants & leurs produits

• Modérateur : Paul Moshkovich – cofondateur de Modia (lab IA externalisé pour entreprises).

Olivier / AVE – Agents artificiels pour expériences vidéo

• Plateforme d'automatisation de production vidéo pour :

  • marques, agences, médias, réseaux sociaux. * À partir d'un spot TV, d'un film ou d'une émission :

  • résumé, reformate, localise, adapte par audience / réseau, le tout avec validation humaine. * Tech maison : MGT – Technologie Générative Multimodale.

• Dan / Vingt-deux (22)

  • Société de 10 ans, spécialisée dans :

    • analyser la vidéo en temps réel (vidéosurveillance, commerce de détail, etc.). * Ne stocke jamais les images :

    • transformer directement le flux en données structurées (objets, comportements, temps passés, trajectoires…). * Alimentent ensuite d'autres modèles / tableaux de bord / systèmes opérationnels.

🎬 Vision commune : traiter la vidéo comme donnée, pas comme pixels

Les deux boîtes partagent la même philosophie :

La vidéo = une source de données multimodales (image, audio, temporalité, contexte), pas seulement une suite de pixels.

Chez AVE

• Ils décomposent la créativité :

  • Côté visible : la vidéo que l'on voit. * Côté machine : un ensemble de données structurées décrivant la vidéo. * Ils ont développé des dizaines de modèles IA propriétaires (plus des modèles open source) qui détectent :

  • personnes, émotions, cadrage, objets, logo, discours, mouvement, narration, branding… * Tout est transformé en « video-to-data », puis :

  • utilisé pour résumer, reformater, adapter un contenu à différents usages (TV, TikTok, Facebook, etc.). * Ensuite, un moteur génétique génère automatiquement des milliers de variantes vidéo (ex : 50 000 montages possibles d'un spot Nespresso) et :

  • un « creative score » choisit la meilleure version selon le canal (TikTok ≠ Facebook).

Chez TwentyTwo (22)

• Ils interprètent des règles :

  • ex : « un objet de type humain entre dans telle zone », « combiné de temps reste-t-il dans cette zone », « comportement X détecté ou non ». * Le système extrait :

  • type d'objet (humain, véhicule, etc.), * trajectoires, * temps passé, * comportements, * re-identification non biométrique (individus entre caméras)… * Tout est stocké comme données structurées (type, position, temps, évènement), directement exploitables :

  • dans des tableaux de bord, * dans des systèmes opérationnels (alertes temps réel, automatisation).

🧠 Multimodalité : image + son + texte + temps

Les deux insistants : la multimodalité est indispensable.

Pourquoi ?

• Comme pour un humain, on a besoin de plusieurs signaux pour comprendre le contexte :

  • image seule, * son / voix, * texte (sous-titres, scripts), * temporalité (ce qui vient avant / après une scène), * position dans l'image (centre vs coin), mouvements, etc. * Le croisement de ces signaux permet :

  • meilleure compréhension des émotions, du rôle des plans, des scènes clés, * meilleure détection de comportements côté 22 (retail, sécurité, analytique).

Exemples de béton

• AVE :

  *Certaines pubs/films sont sans dialogue → il faut s'appuyer sur :

  • expressions faciales, * mouvement, * type de plan (gros plan, plan large), * rythme, * cliffhanger, moments clés… * Leur MGT combine plusieurs modèles :

  • ex : « gros plan + visage + émotion forte » → scène clé / moment émotions. *22 :

  • Utiliser le multimodal + VLM (vision-langage model) pour :

    • permettre à l'utilisateur de poser des questions en langage naturel sur la vidéo (ex : « est-ce que la personne porte un casque ? »), * et recevoir des réponses basées sur leurs données vidéo → texte.

📉 Data rareté & données synthétiques

Problèmes de base

• Il est difficile d'obtenir assez de données réelles pour tout couvrir :

  • contraintes RGPD / confidentialité, * scénarios rares (évènements peu fréquents), * multiples configurations de caméras / lumières / angles, etc. * On ne peut pas « filmer tout et n'importe quoi » pour entraîner un modèle.

Approche de TwentyTwo (22)

• Historiquement :

  • génération de données 3D synthétiques (environnements de retail, caméras, lumières, occlusions). * À l'époque (2018), le rendu 3D n'était pas assez réaliste. *Aujourd'hui :

  • ils utilisent un mix :

    • données réelles (problèmes de partenariats clients ou environnements loués), * données synthétiques générées avec les récents modèles de GenAI vidéo. * L'entraînement peut utiliser réel + synthétique, mais la validation des modèles se fait uniquement sur données réelles.

Approche d'AVE

• Philosophie différente :

  • ils ne « peaufinent » pas leurs modèles sur les vidéos clients. * MGT est basé sur une approche méta-learning / combinaison de modèles. * Conséquences :

  • pas de ré-entraînement au fur et à mesure des uploads clients, * pas de fuite de données vers l'extérieur (pas d'API externes), * conformité forte pour les clients B2B (marques, agences, médias). * Leur promesse :

  • tu télécharges une vidéo → pas de phase de setup / training, tu produis de la valeur tout de suite.

🛡️ Garde-fous, hallucinations & qualité des prédictions

AVE

• Dans la pub / l'entertainment, la tolérance à l'erreur est quasi nulle :

  • pas de personnages avec trois bras, * pas de glitch visibles, * pas de montages incohérents. * Leur techno est décrite comme déterministe :

  • le pipeline (détection + règles + génération + sélection) est conçu pour éviter les hallucinations, * ils ne « laissent pas un LLM inventer du contenu visuel » librement. *Ils insistent sur :

  • pixel perfect, * contrôle créatif, * feedback humain :

    • l'utilisateur peut éditer ce que l'IA propose, * corriger / affiner (boucle de correction).

Vingt-deux (22)

• Eux répondent : oui, il ya des hallucinations.

  • surtout côté modèles génériques (VLM) ou reconnaissance d'objets dans des cas limites. * Mais :

  • ils ne voient jamais la vidéo côté serveur (on-premise chez le client), * donc ils ne peuvent pas « corriger » manuellement cas par cas. *Stratégies :

  • ajustement des seuils selon le contexte (distance caméra, lumière, angle…), * réglage fin ciblé sur certains cas d'usage, * transparence avec le client :

    • ils communiquent sur les taux de performance, * donnent des recommandations (position caméra, densité de pixels, etc.). * Taux d'erreur :

  • dépend du cas d'utilisation, mais tant que la masse de données globale est cohérente, les erreurs ponctuelles sont acceptables pour des cas d'utilisation analytiques.

🧩 Points clés à retenir

1. Même philosophie, cas d'usage opposés :

   • AVE : post-production / adaptation créative (pub, divertissement). * 22 : analyser temps réel / environnement physique (commerce, flux, comportement).

2. La vidéo est traitée comme un flux multimodal de données structurables, pas juste comme une « image animée ».

3. Multimodalité = clé pour :

   • comprendre le contexte, les émotions, les intentions, * offrir des interfaces en langage naturel (poser une question au système sur ce qui se passe dans la vidéo), * améliorer la robustesse et la précision.

4. La rareté des données n'est pas un obstacle insurmontable, si :

   • sur la combinaison de données synthétiques, réelles, et méta-apprentissage / composition de modèles, * sur la conception des systèmes qui ne dépendent pas d'énormes ensembles de données clients pour fonctionner.

5. Garde-fous & hallucinations dépendantes du métier :

   • publicité / vidéo marketing → exigence de perfection visuelle → pipeline plus déterministe. * Analytics / Retail → légère marge d'erreur acceptable si le signal global est fiable.

17:10 17:25 | Analyse approfondie des applications MCP et ChatGPT

Un talk clé : MCP, la nouvelle révolution des applications autonomes. Particulièrement intéressant pour les développeurs européens.

17:50 18:05 | L'IA chez Spotify

Comment Spotify repense ses stratégies grâce à l'IA « partout ». # ☕ Founders Café : business cases, edge AI, RL, industrie, durabilité

Une piste plus intimiste mais ultra-technique :

12:05 12:35 | AIVE : Transcréation vidéo nouvelle génération * 12:40 13:10 | Gestion des menus par OCR * 13:15 13:30 | IA en temps réel : Inférence 100 fois plus rapide (Kog) * 13:35 13:50 | Mesure du retour sur investissement de l'adoption de l'IA * 13:55 14:10 | Apprentissage par renforcement et routage de circuits imprimés * 14:15 14:30 | Modèles de base pour l'automobile * 14:35 15:05 | Mise à l'échelle durable de l'IA (Fujitsu) * 15:10 15:40 | Du poste de travail au supercalculateur : Flux de travail d'IA * 16:10 16:40 | Création d'un agent audio * 17:05 17:35 | Agents utilisant l'ordinateur (Leadgen) * 17:40 18:10 | Modèles tabulaires de base (Neuralk-AI)

Un mélange rare d'infrastructures, produits, cas d'usage réels, régulations, optimisation énergétique et agents IA. # 📌Ce que révèle l'agenda 2025

1. L'ère des agents autonomes est amoureuse

Les discussions sur les agents, l'autonomie, l'orchestration, la productivité et MCP sont partout.

2. L'Europe veut imposer une IA responsable et efficace

Sobriété énergétique, transparence, souveraineté et régulation sont omniprésentes.

3. L'industrie rattrape voire la recherche appliquée

Pharma, automobile, e-commerce, robotique : on n'est plus dans la démo, mais dans le déployer massif.

4. Le matériel redevient un sujet

Air refroidissement, edge, ARM, densité, supercalculateur : l'Europe veut des alternatives au duopole GPU US/Asie.

5. La multimodalité s'impose dans tous les usages

Texte → image, voix → produit, vidéo → actions, tableau → insights. # 🎤 Conclusion : ai-PULSE confirme le virage européen de l'IA

Avec un programme dense, international et orienté action, ai-PULSE 2025 marque une étape clé. L'Europe ne se contente plus d'analyser l'IA : elle construit, elle optimise, elle déploie.

Pour ceux qui veulent comprendre où va l'IA en 2026 agents autonomes, edge, multimodalité, efficacité énergétique, MCP c'est clairement le rendez-vous incontournable.

• Poster un commentaire