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 speakers 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.

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

• Xavier Niel (iliad Group)

• Jérôme Monceaux (Enchanted Tools)

• Pim de Witte (General Intuition)

• Yann LeCun (Meta)

• Rémi Cadene (UMA)

• Neil Zeghidour (Kyutai)

• Aude Durand (iliad Group)

• 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é.

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, Ampere 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.

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 world models : 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.

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 suffira pas à atteindre une intelligence générale.

Yann explique que l’idée de world models 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 LLMs classiques.

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 dataset 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 world model 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 autoregressif “roule” sur lui-même (comme une boule de neige qui grossit en descendant la pente sans savoir ce qui l’attend), un vrai world model doit être capable de “voir le rocher en bas” et d’adapter sa trajectoire exactement comme le ferait un personnage conscient de son environnement.

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.

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 collectées ou simulées.

• Les world models ne nécessitent pas forcément des budgets délirants : entraîner certains de ces modèles demande “quelques milliers de GPU”, loin des méga-clusters requis pour les plus gros LLMs.

• 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, on enchaîne avec la partie “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).

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.

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és 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.

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.

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 global.

• 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.

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 world models mérite d’être mené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 ensemble des blocs de base (architectures, méthodes de training, représentations) qui pourront être rendus publics, tout en laissant à General Intuition la capacité de les transformer en produits et plateformes.

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 buildings sur la planète.

Pour conclure, Xavier résume le message adressé 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 LLMs aux world models que Xavier met 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 ton 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.

Après une démonstration de robot sur scène, la transition est toute trouvée : on accueille Jérôme Monceaux, CEO 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.

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

Quelques principes forts ressortent :

• Un robot doit être sûr et lisible dans ses mouvements.

• L’environnement doit être designé avec le robot : ils conçoivent aussi des accessoires, du mobilier et des éléments au sol pour faciliter l’usage.

• 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é pour adapter le comportement du robot au contexte.

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

Un point central de la vision de Jérôme : un bon robot ne doit pas seulement réagir, 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.

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 augmente ;

• et le bien-être des enfants, des parents et des soignants s’améliore.

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.

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

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.

Sur la partie compute, 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. Quantum computing

   • 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 hardware.

   • 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 devs 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 des 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 workloads d’IA.

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’isolation ;

• 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 managé.

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 factories et Giga factories.

Pour cela, Scaleway a :

• monté un consortium d’ingénieurs et d’experts issus de plusieurs entreprises et domaines critiques (hardware, énergie, réseaux, data, 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 managé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).

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.

Neil commence par rappeler le contexte : chez Kyutai, le travail consistait à faire de la recherche ouverte, à inventer de nouveaux systèmes de conversation speech-to-speech, 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 voice AI réellement utilisable à grande échelle.

Sa mission :

transformer la recherche de Kyutai en modèles audio “industry grade”, intégrables dans des produits concrets.

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,

  • amélioration 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 fondationnels 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 app 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.

À 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,

• exposées 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 customer support,

• 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é digitale.

L’idée :

“On devient simplement le “wrapper vocal” d’un système IA qui existe déjà.”

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 speech-to-text / text-to-speech,

• reliée à 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 change 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 voice 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 voice 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.

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 voice 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 voice 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 voice AI dans des robots qui bougent, interagissent, comprennent à qui ils s’adressent et dans quelle langue, reste un frontier challenge.

  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 builders présents dans la salle :

“Allez sur notre site, testez l’API, parlez-nous de vos cas d’usage et si vous êtes talentueux, rejoignez l’équipe.”

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

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”.

La session “Inference-powered training” pose un constat simple mais souvent éludé : 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.

Le speaker commence par rappeler la différence :

• Entraînement (training)

  • Terrain naturel de la recherche : on fait “une seule fois” un gros job.

  • 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.

  • On 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.

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

Leur objectif : rendre l’inférence :

• agnostique du hardware (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 une 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 perfs natives, en compilant le modèle “jusqu’au métal”.

Autres caractéristiques clefs :

• 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 dance infinie autour des dépendances GPU dans les containers.

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.

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

Contexte :

• L’attention est le cœur des architectures modernes (transformers, LLMs).

• 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 graphe 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. Envoi 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 KV cache 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 fabrics 800 Gbps.

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.

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 “Agents that actually do the work – how autonomy changes the way we build” (12h25).

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.

Les intervenants listent 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éploiement, avec rollback possible. On parle de “full self-coding”, déjà disponible publiquement.

• Industrie & sécurité

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

• Médical & monitoring

  • systèmes qui suivent l’état de 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 & 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.

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és, l’agent peut :

  • corriger un bug,

  • push une branche,

  • ouvrir une PR,

  • exécuter les tests, mais c’est l’ingénieur qui décide (ou non) d’autoriser le merge 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 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é & 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 end-to-end chiffrées, 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 piloter.

   • 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”.

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 device edge pourra exécuter des capacités aujourd’hui réservées aux GPU de datacenter.

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

Il faut aussi :

• un protocole (MCP, architectures multi-agents, etc.),

• une enveloppe d’exécution (container, 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 firewall, personne n’est considéré 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 (browser, app mobile) pour tester des scénarios complets,

• l’environnement est presque aussi important que le modèle lui-même.

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 reflètent pas la complexité des systèmes réels.

Les intervenants défendent une approche user-centric :

• définir des métriques liées au contexte d’usage réel,

• suivre :

  • les tâches effectivement accomplies,

  • les merges acceptés par les humains,

  • les corrections validées,

• construire des benchmarks internes, continus, plutôt que s’en remettre uniquement aux scores publics.

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 hardware devient plus performant… mais les modèles deviennent plus lourds.

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

• déplacer une grande part des workloads vers l’edge,

• profiter du fait que les devices grand public rattrapent (et dépassent) d’anciennes générations de supercalculateurs,

• concevoir les agents comme des containers légers, déplaçables, capables de vivre :

  • dans le cloud,

  • sur un endpoint,

  • ou sur une machine locale.

Enfin, comment éviter qu’un agent ne parte en vrille :

• Limiter ses permissions : décider explicitement à quoi il a accès (fichiers, secrets, commandes, API).

• Mettre des garde-fous de supervision :

  • notifications (Slack, SMS, appels vocaux automatiques) quand l’agent est bloqué,

  • demandes explicites de validation humaine pour certaines actions critiques.

• Donner de la visibilité aux utilisateurs : dashboards, logs, explications pas à pas – pour que l’utilisateur puisse comprendre, rejouer, corriger.

Le panel se termine sur cette idée : les agents existent 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.

Le behind-the-scenes 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 partie Photoroom / PRx.

Sur scène, Yoann Almazan et David Berthouin, research scientists 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 matières, reflets, détails.

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

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 process, 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 “lightweight”).

• Licence : Apache 2.0, usage commercial permis.

• 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 vite, 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 features 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.

• Brand & hiring → le projet rend visible un niveau de travail qui, sinon, serait resté enfoui dans des notebooks internes.

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.

Avec PRx, l’équipe s’est fixé 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.

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 crops bizarres,

  • des images moches avec bordures blanches,

  • etc.

Traditionnellement, beaucoup d’équipes :

1. Entraînent sur tout le dataset,

2. Puis fine-tunent sur un sous-ensemble “propre” filtré par heuristiques.

Problèmes :

• Difficile d’automatiser un filtrage parfait.

• Le fine-tune sur un sous-ensemble peut faire “oublier” certains concepts appris au départ.

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

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 (orange car, orange sofa, etc.).

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

• ils passent tout leur dataset par des vision–language models 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 :

“tabby sleeping cat on a wheelchair”

devient quelque chose comme :

“a minimalist white wheelchair in a bright studio, with a tabby sleeping cat curled on the seat, soft shadows, high-key lighting, 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 inchangé.

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 builders 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.

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

Voici un texte prêt à intégrer dans ton article pour la partie “From lab to product with European voice models” (Kyutai + Indigo AI).

Sur scène, deux mondes se rencontrent :

• Neil Zeghidour, chercheur en speech 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 posent un constat simple : l’audio est l’interface la plus naturelle… et la plus compliquée à maîtriser.

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 redondante,

• 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 broadcast.

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 rates un mot à l’oral, tu peux perdre le sens entier,

  • tu ne peux pas “relire” comme sur du texte,

  • il faut gérer le latency budget, les interruptions, le tour de parole, la prise de confiance.

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”.

Aujourd’hui, deux architectures dominent.

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 existant textuel :

  • bots métiers, workflows d’API, systèmes bancaires / assurance, etc.

• facile d’ajouter :

  • function calling,

  • 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 :

• inbound service client :

  • questions complexes,

  • appels d’API bancaires / assurance,

  • l’utilisateur s’attend à ce que ça prenne quelques secondes,

  • on peut “masquer” la latence avec des trucs UX (“Je vérifie vos informations…”).

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 overlaps, 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 existant LLM / API :

  • 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 speech-to-speech brille surtout dans les cas outbound :

• 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ù le speech-to-speech reste fluide.

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ère 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 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 device,

   • 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 “dummy agent” :

• 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.

Autre sujet : la fairness.

• Si tu parles “anglais CNN”, tout marche.

• Si tu parles avec un fort accent, un 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 speakers 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 demandent 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”.

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

Derrière la “simple” brique ASR → LLM → TTS, il faut :

• guardrails (ce que l’agent peut dire ou pas),

• obfuscation / masking des données sensibles,

• gestion de la vie privée (RGPD, stockage, droit d’accès, etc.),

• monitoring 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.

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

• plonger dans le monde SIP, PBX, PSTN, call centers,

• gérer l’handover fluide vers un humain,

• construire en interne une équipe dédiée téléphonie.

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.

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

1. Un écosystème européen durable

   • On 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, pangea de labs, etc.).

   • Pour garder l’avance, il faut des modèles économiques soutenables :

     • pas seulement des démos spectaculaires,

     • mais des entreprises qui tiennent 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 speech-to-speech à 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.”

Un talk de Translated sur les frontières actuelles des modèles autoregressifs.

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

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 comprenne 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.

Plutôt que de raisonner en “taille de modèle” ou “tokens vus”, Translated utilise 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 y a 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, autoregressive, word-first ?

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.

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

1. Modèle de langue (LM).

2. Modèle de traduction spécialisé (MT).

Timeline :

• modèles statistiques →

• modèles neuronaux (vers 2010) →

• Transformers →

• gros LLM ouverts + fine-tuning.

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 :

entraîner 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.

Aujourd’hui, la tokenisation (BPE, etc.) est un pré-process 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 transformer 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 bytes 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é-processing opaque. On veut un cerveau qui apprend lui-même à lire ses sens.”

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 :

“Three important words : you are not alone.”

Problème :

• “you / are / not / alone” = 4 mots,

• donc la traduction correcte serait plutôt :

  “Four important words: you are not alone.”

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

• compter les mots,

• décoder en même temps,

• dans un flux où tout est mélangé.

Le cerveau humain, lui, fait différemment :

• plusieurs zones traitent en parallèle (vision, langage, logique…),

• la “functional connectivity” permet de raisonner avant de parler,

• puis seulement ensuite on 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.

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.

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

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

  • 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.

Pour pousser ces idées, Translated a obtenu :

• 30 M€ de financement de recherche européen,

• ~100 M€ d’équivalent compute 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.

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.”

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 “AI Benchmarking” (Micah Hill-Smith – Artificial Analysis).

Micah Hill-Smith, co-fondateur et CEO 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 builders des données indépendantes pour choisir les bons modèles, au bon prix, pour les bonnes applis.

• Site : artificialanalysis.ai

• Rôle : tiers de confiance pour :

  • mesurer l’intelligence des modèles (LLM, image, audio, vidéo),

  • évaluer latence, coût, efficacité, tokens utilisés,

  • comparer labs, clouds, chips.

• Clients : labs de haut niveau + entreprises qui construisent des produits IA.

• Outils : un Intelligence Index (score synthétique) et des datasets/évals custom pour les besoins spécifiques.

Ils affichent 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 reasoning models 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 use cases concrets (notamment le code) :

  il y a un an, les agents de code faisaient 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.

Micah découpe l’écosystème en 4 couches :

1. Applications – ChatGPT, copilots, produits B2B, apps 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 – GPUs (NVIDIA), TPUs (Google), autres chips spécialisés.

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

Micah pose un paradoxe :

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

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 hardwares 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.

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).

• Reasoning models → ils “pensent” avec des milliers de tokens avant de répondre.

• Agents IA :

  • chain-of-thought 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 augmente. 💶 Coût par requête utile explose si tu laisses l’agent travailler longtemps.

Avant, la distinction était simple :

• modèles “normaux” vs

• reasoning models (avec trace de réflexion explicite, beaucoup plus de tokens internes).

Maintenant, c’est plus flou :

• Certains modèles sans “mode reasoning” parlent beaucoup et font quand même beaucoup de raisonnement implicite.

• Certains reasoning models récents sont beaucoup plus efficaces en tokens.

Artificial Analysis parle désormais plutôt de :

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

En pratique, pour un builder, il faut regarder :

• pas seulement “raisoning on/off”,

• mais combien de tokens le modèle consomme pour ton type d’usage (latence + facture).

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 a aussi 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 reasoning RLHF complet → il est plus token-efficient mais n’écrase pas Medium 1.2 sur leurs indices de reasoning.

• Une future version reasoning pourrait logiquement le placer au-dessus.

Ils ont construit des évals 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 :

• Accuracy (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”.

Ils présentent aussi un Openness Index, un score pour mesurer à quel point un modèle est réellement “open” :

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

• Mais aussi :

  • quelles sont les conditions de licence ?

  • a-t-on accès à :

    • la recette d’entraînement,

    • la composition du dataset (au moins en grandes lignes),

    • les scripts / configs ?

• Un score parfait signifierait :

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

Mistral obtient un des meilleurs scores actuels parmi les LLM propriétaires/open-weights “sérieux”.

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

Artificial Analysis benchmarke aussi :

• Génération d’images (diffusion, LLM visuels),

• Génération vidéo (surtout image→vidéo),

• Modèles audio / speech.

Ils utilisent notamment des “preference arenas” : 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.

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.

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…

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.

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

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

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.

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. »

(Beyond Visual Range)

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 littéralement un mélange de :

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

Et l’IA parfaite pour ça ? → Un agent de Reinforcement Learning.

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.

Les simulateurs traditionnels sont :

• très fidèles graphiquement,

• conçus 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écuter 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’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 observé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 superhumaine.

Mettre une IA au commande d’un avion réel exige trois choses :

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.

Le Saab Gripen offre :

• séparation stricte entre commandes critiques et tactiques,

• guidage de bas niveau ultra-fiable,

• compute 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.

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

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étecte l’adversaire,

• met à jour sa stratégie,

• manœuvre en anticipant les mouvements ennemis,

• optimise 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.

Helsing le répète :

Ce n’est pas un meilleur autopilote. 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.

Centaur 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.

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

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

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

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

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

Proton donne une vision forte d’une IA privée et chiffrée essentielle pour l’Europe.

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

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

Voici un résumé clair et réutilisable de la session “Pharmaceutique & santé publique” (12–15h15).

Comment 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).

Intervenants :

• 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).

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 dashboards officiels.

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

   • Traditionnellement : un indicateur → une source (ex : labos, hôpitaux).

   • Or 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 : on 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.

Pour Joël, l’IA utile en santé, ce n’est pas juste “des LLM” :

• modèles classiques de machine learning,

• LLM et transformers,

• analyse de texte, d’images, de signaux capteurs,

• modèles de recherche / RAG,

• agents spécialisés qui combinent plusieurs outils,

• plus l’évolution des sensors et du hardware (inference 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 ?

Antoine résume bien la situation :

“On peut attaquer n’importe quel problème complexe avec des LLM si on le découpe en sous-tâches que le modèle sait résoudre.”

Deux limites majeures :

1. Mémoire & 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 amont.

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 compenser ces limites.

• 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.

• Critique de l’approche standard chunking + simple vecteurs :

  • le découpage en chunks 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é.

• BioElevate propose un “knowledge store” :

  • 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 chunks choisis.

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

• BioElevate orchestre :

  • 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.

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 dashboard 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.”

• Timeline :

  • début prévu avant mi-2026, durée 4 ans,

  • pilote régional vers 2 ans,

  • solution industrielle complète vers 4 ans.

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 rentables pour les big pharmas (trop rares), et utiliser les agents IA pour explorer l’espace thérapeutique beaucoup plus vite.

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

  • sans changer le modèle,

  • ils peuvent augmenter l’accuracy 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.

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 bottleneck (infra, orchestration, transactions, monitoring, conformité),

  • on l’optimise,

  • puis le palier suivant révèle un nouveau goulot d’étranglement.

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 agentiques 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.

Question “baguette magique” de Sophia à Cédric :

“Si tu pouvais demander une seule chose à 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 workshop prévu avec l’OMS à Genève avant mi-2026, pour travailler sur l’usage de l’IA dans ce processus de sélection.

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 design de traitements grâce aux agents :

  on peut, à terme, envisager de développer des traitements pour quasiment tout, y compris 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.

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 y a l’intelligence artificielle, mais il y a surtout l’intelligence humaine qui va la mettre au service de quelque chose.”

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

Voici un récap clair du talk “Multimodal product classification chez VP (Veepee)”.

• 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).

Parce qu’elle impacte toute la chaîne :

• Pricing : 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.

• Taxonomie non MECE (non “Mutually Exclusive, Collectively 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).

• Imbalance 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 zero / few-shot, pas un gros classifieur supervisé.

Ils utilisent un modèle CLIP (image + texte) en “zero-shot classification”.

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

   • transformer la catégorie en phrase :

     “This product is a T-shirt”, “This product is a dishwasher”, etc.

   • embeddings texte → vecteurs de dimension d.

2. Pour chaque produit :

   • encoder l’image du produit → embedding 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.).

• Zero training : pas de fine-tuning, pas de data cleaning massif.

• Très rapide et peu coûteux (embedding + similarités).

• Gère naturellement l’ajout de nouvelles catégories (on les embedde, point).

• Top-1 accuracy ≈ 58 % (vs ~89 % pour un humain).

• En Top-15, on monte à ~89 % (on finit 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.

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

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. Combiner :

   • Top-30 du CLIP “catégories”

   • 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.

• On introduit 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).

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

On 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.

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 label book :

   • un document texte en langage humain :

     • expliquant 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.

• C’est un LLM multimodal (image + texte).

• Il reçoit tout le contexte (produit + 15 catégories + règles métiers).

• Il doit :

  • 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.

• Top-1 accuracy ≈ 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 off-the-shelf (open weights possible),

  • la connaissance métier encapsulée dans le label book.

• Zero / few-shot de bout en bout

  • on ne dépend pas d’énormes datasets propres par catégorie.

  • solution robuste au cold-start : 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.

• Coût maîtrisé & scalable :

  • 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.

Le schéma général que tu peux réappliquer ailleurs :

1. Multimodal embedding (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 training supervisé, tu obtiens :

• une précision > humain,

• un système souple, scalable, peu coûteux,

• capable d’absorber de nouvelles catégories très vite.

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

Voici un résumé structuré du talk “Video AI – de la vidéo aux données” (14h–16h10).

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

• Olivier / AVE – Artificial Agents for Video Experiments

  • 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ésume, reformate, localise, adapte par audience / réseau, le tout avec validation humaine.

  • Tech maison : MGT – Multimodal Generative Technology.

• Dan / TwentyTwo (22)

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

    • analyse vidéo en temps réel (vidéosurveillance, retail, etc.).

  • Ne stocke jamais les images :

    • transforme directement le flux en données structurées (objets, comportements, temps passé, trajectoires…).

  • Alimentent ensuite d’autres modèles / dashboards / systèmes opérationnels.

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.

• 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).

• Ils définissent des règles :

  • ex : “un objet de type humain entre dans telle zone”, “combien 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 (mêmes individus entre caméras)…

• Tout est stocké comme données structurées (type, position, temps, évènement), directement exploitables :

  • dans des dashboards,

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

Les deux insistent : la multimodalité est indispensable.

• 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é, analytics).

• 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 émotionnel.

• 22 :

  • Utilise multimodal + VLM (vision-language 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.

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

  • contraintes GDPR / privacy,

  • 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.

• 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 (issues 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.

• Philosophie différente :

  • ils ne “fine-tunent” pas leurs modèles sur les vidéos clients.

  • MGT est basé sur une approche meta-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 uploades une vidéo → pas de phase de setup / training, tu produis de la valeur tout de suite.

• 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).

• Eux reconnaissent : oui, il y a 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…),

  • fine-tuning ciblé sur certains cas d’usage,

  • transparence avec le client :

    • ils communiquent sur les taux de performance,

    • donnent des recommandations (position caméra, pixel density, etc.).

• Taux d’erreur :

  • dépend du cas d’usage, mais tant que la masse de données globale est cohérente, les erreurs ponctuelles sont acceptables pour des use cases analytics.

1. Même philosophie, use cases opposés :

   • AVE : post-production / adaptation créative (pub, entertainment).

   • 22 : analyse temps réel / environnement physique (retail, 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 contexte, émotions, intentions,

   • offrir des interfaces en langage naturel (poser une question au système sur ce qui se passe dans la vidéo),

   • améliorer robustesse et précision.

4. Data scarcity ≠ showstopper, si :

   • on combine données synthétiques, réelles, et meta-learning / composition de modèles,

   • on conçoit des systèmes qui ne dépendent pas d’énormes datasets clients pour fonctionner.

5. Guardrails & hallucinations dépendent 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.

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

Comment Spotify repense ses stratégies grâce à l’IA “everywhere”.

Une track plus intimiste mais ultra-technique :

• 12:05 12:35 | AIVE : Next-gen video transcreation

• 12:40 13:10 | OCR-powered menu inventory

• 13:15 13:30 | Real-time AI: 100x faster inference (Kog)

• 13:35 13:50 | Measuring ROI of AI adoption

• 13:55 14:10 | Reinforcement Learning & PCB routing

• 14:15 14:30 | Automotive Foundation Models

• 14:35 15:05 | Sustainable AI scaling (Fujitsu)

• 15:10 15:40 | Desktop → Supercomputer: AI workflows

• 16:10 16:40 | Build the audio agent

• 17:05 17:35 | Computer-using agents (leadgen)

• 17:40 18:10 | Tabular Foundation Models (Neuralk-AI)

Un mélange rare d’infrastructure, produits, cas d’usage réels, régulations, optimisation énergétique et agents IA.

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

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

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

Air cooling, edge, ARM, densité, supercompute : l’Europe veut des alternatives au duopole GPU US/Asie.

Texte → image, voix → produit, vidéo → actions, tableau → insights.

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.