Crise des données IA : Simula, Euphan et Hermes passés au banc d’essai

Crise des données IA : Simula, Euphan et Hermes passés au banc d’essai

L’article qui m’a fait tout arrêter la semaine dernière ne portait pas sur un nouveau modèle de pointe. Ce n’était pas une fuite de benchmark. Ce n’était même pas une annonce, techniquement — il s’agissait d’une publication de recherche de Google, au titre si aride que la plupart des gens sont passés à côté sans s’arrêter : "Orchestrating Synthetic Datasets with Reasoning." J’ai failli la zapper moi aussi.

Puis je suis tombé sur cette phrase qui m’a obsédé trois jours durant : les modèles entraînés sur des données synthétiques surperforment parfois ceux formés sur des jeux de données réels. Pas égalent. Surperforment. Dans des domaines spécialisés — cybersécurité, raisonnement juridique, médical — où les données "réelles" sont soit verrouillées par des lois sur la vie privée soit trop coûteuses à collecter, une équipe chez Google a conçu un système capable de raisonner pour générer des jeux d’entraînement meilleurs que le réel.

Cet article — qui présente un cadre nommé Simula — constitue la moitié de ce que je vais analyser ici. L’autre moitié concerne ce qu’OpenAI a déployé dans le même temps : une interface d’interprétation des journaux que les initiés appellent "Euphan", et une plateforme d’agents persistants au nom de code Hermes, discrètement intégrée dans les modules préchargés de l’interface ChatGPT, en attente d’un simple drapeau de publication.

Trois outils. Une mutation sous-jacente. Et cette mutation — qui, selon moi, est l’enjeu majeur de l’IA aujourd’hui — réside dans le déplacement du goulot d’étranglement. Ce n’est plus le calcul. Ce n’est même plus la taille des modèles. Il s’agit désormais du pipeline de données qui alimente le modèle, de la couche d’observabilité qui surveille l’agent, et du runtime qui maintient celui-ci en vie entre les sessions. Ces trois points sont défaillants. Et chacun est en voie de réparation, simultanément, dans les deux laboratoires qui ont le plus à perdre s’ils échouent.

Voici ce que j’ai découvert en creusant chaque solution — ce qui relève du concret, du vaporware, et ce que leur combinaison promet à tous ceux qui bâtissent sur ces modèles en 2026.

Pourquoi la crise des données est pire que ce que la plupart des développeurs imaginent

L’histoire conventionnelle du progrès de l’IA est une histoire d’échelle. Des modèles plus grands, plus de paramètres, plus de puissance de calcul, de meilleurs résultats. Cette trajectoire a fonctionné jusqu’il y a environ un an. Puis quelque chose a changé, et aucun média grand public n’a réellement compris ce qui se passait.

Les équipes qui entraînent les modèles de pointe ont épuisé la qualité d’internet. Pas la quantité — il reste encore beaucoup de texte sur le web. Mais le rapport signal/bruit de ce qu’il reste à scraper s’est effondré. Les textes de haute qualité ont été consommés lors des précédents cycles d’entraînement. Ce qui demeure est dupliqué, généré par des machines, ou trop superficiel pour apprendre à un modèle quoi que ce soit qu’il ne sache pas déjà.

Pour les chatbots généralistes comme GPT, Gemini et Claude, cela se manifeste par des rendements décroissants à l’échelle. Chaque doublement du nombre de tokens d’entraînement produit une amélioration plus faible que la précédente. La courbe commence à s’infléchir.

Pour les domaines spécialisés, le problème est structurellement différent — et bien pire. Si vous souhaitez entraîner un modèle vraiment performant en raisonnement cybersécurité, il vous faut des données qui représentent la taxonomie réelle des attaques, des acteurs de la menace, des classes de vulnérabilités et des stratégies de mitigation. Ces données existent — mais elles sont fragmentées entre des flux propriétaires de renseignements sur les menaces, des rapports d’incident fermés, et le savoir implicite des analystes seniors qui ne l’écriront jamais.

Le raisonnement juridique ? Cadenassé par le secret professionnel, verrouillé derrière des paywalls, ou enfoui dans une jurisprudence propre à chaque juridiction qu’aucune source n’a agrégée proprement.

Le médical ? HIPAA existe pour de bonnes raisons. Les données idéales pour l’entraînement sont précisément celles qu’il est illégal d’utiliser à grande échelle.

Je l’ai constaté personnellement. Quand j’essaie de faire raisonner les modèles grand public sur des vulnérabilités de sécurité dans des frameworks spécifiques, ils fournissent des réponses assurées, mais qui ne tiennent pas à l’audit. Non parce que les modèles sont mauvais — mais parce que les données sur lesquelles ils ont été entraînés ne couvrent pas le terrain réel. Ils ont appris la version Wikipedia de la cybersécurité, pas celle d’un pentester professionnel.

C’est cela, le mur. Et la voie pour contourner le mur — ce sur quoi tous les laboratoires sérieux d’IA travaillent depuis deux ans — c’est la donnée synthétique. Pas la version 2023, qui n’était guère plus que « demander à GPT-4 de générer des exemples d’entraînement et espérer que ça suffise ». Mais la version 2026, incarnée par Simula.

Simula : À quoi ressemble réellement la génération de données pilotée par le raisonnement

Je l’admets, lorsque j’ai survolé pour la première fois l’article de Simula, j’ai cru qu’il s’agissait d’une énième variante du schéma « LLM génère des exemples synthétiques, puis un LLM les filtre ». Ce schéma existe depuis 2023 et son point de défaillance est bien connu : le générateur finit par s’effondrer dans une distribution étroite d’exemples qui semblent variés, mais qui couvrent en réalité une faible part de l’espace des possibles. Le terme technique est effondrement de mode (mode collapse), et c’est la raison pour laquelle la plupart des pipelines de données synthétiques affichent en silence des performances inférieures aux données réelles, malgré la génération de millions d’exemples.

Simula ne fait pas cela. Son architecture est réellement différente, et c’est précisément là que résident les gains de performance intéressants. Voici le mécanisme exact, dans l’ordre d’exécution du framework.

Étape 1 : cartographie structurée du domaine. Avant de générer quoi que ce soit, Simula construit une taxonomie hiérarchique du domaine cible. Pour la cybersécurité, cette taxonomie inclut les types d’attaque (phishing, injection, chaîne d’approvisionnement, ingénierie sociale, etc.), les catégories d’acteurs menaçants (États-nations, crime organisé, hacktivistes, initiés), les classes de vulnérabilités (dépassement de tampon, faille logique, condition de concurrence, mauvaise configuration), et les stratégies d’atténuation. Chaque branche possède ses sous-branches. La taxonomie sert de plan pour garantir une bonne couverture du domaine.

Rien que cette étape apporte plus de structure que la majorité des pipelines de données synthétiques. La plupart supposent que le modèle générateur produira naturellement des exemples diversifiés. Ce n’est pas le cas. Il générera des exemples biaisés vers ce qui était surreprésenté dans ses propres données d’entraînement.

Étape 2 : échantillonnage contrôlé. Au lieu de laisser le générateur choisir les sujets au hasard, Simula effectue un échantillonnage délibéré sur l’ensemble de la taxonomie. Si la cybersécurité comporte 400 nœuds, l’échantillonneur veille à ce que chaque nœud bénéficie d’une représentation adéquate — y compris les cas rares et complexes qu’un échantillonnage aléatoire ne visiterait qu’une fois tous les dix mille exemples. C’est l’antidote à l’effondrement de mode : il est impossible de s’effondrer dans une distribution étroite si l’échantillonneur vous oblige explicitement à couvrir tout l’espace.

Étape 3 : génération de métaprompts. C’est ici que Simula devient intéressant. Le système ne génère pas directement des exemples d’entraînement. Il génère des prompts qui génèreront des exemples d’entraînement. Ces métaprompts intègrent des contraintes sur le format, la difficulté, l’angle d’approche et la profondeur du raisonnement. La couche de métaprompts introduit une variation qu’un système de génération directe ne peut égaler, car les métaprompts eux-mêmes sont variés.

Pensez à la différence. Génération directe : « Rédigez une question-réponse de cybersécurité sur l’injection SQL. » Vous obtiendrez mille variantes fondamentalement identiques. Génération par métaprompts : « Rédigez vingt modèles de prompts différents qui pourraient chacun susciter un exemple d’entraînement de grande qualité sur l’injection SQL — un du point de vue d’un analyste d’incident, un en revue de code, un comme audit de conformité, un sous forme de rapport d’équipe rouge, un pour la première expérience d’un ingénieur junior, etc. » Le générateur produit alors, par conception, des points de vue variés, et non par accident.

Étape 4 : paramétrisation de la complexité. Simula traite la complexité comme un axe indépendant de la diversité. On peut générer des exemples simples couvrant toute la taxonomie, ou des exemples complexes couvrant toute la taxonomie, ou encore un mélange délibéré. Les chercheurs de Google ont constaté que l’ajustement du paramètre de complexité à la hausse apportait jusqu’à 10 % de gain de performance sur des benchmarks de raisonnement mathématique — à condition que le modèle générateur de base soit suffisamment robuste pour gérer cette complexité. Des générateurs faibles, soumis à une complexité élevée, produisaient à grande échelle des exemples plausibles mais erronés, ce qui nuisait activement au modèle étudiant.

C’est une nuance cruciale. La complexité est un multiplicateur, pas une solution. Elle multiplie la qualité du générateur — dans les deux sens.

Étape 5 : contrôle qualité à double critique. Chaque exemple généré passe par deux évaluateurs. Le premier demande « ceci est-il correct ? » Le second, séparément, demande « ceci est-il incorrect ? » La formulation compte ici. Poser deux fois « ceci est-il correct ? » au même critique produit des réponses corrélées. Formuler la deuxième évaluation comme une contradiction impose un raisonnement indépendant. Les deux réponses sont combinées en un score de validation. Les exemples qui passent les deux filtres sont retenus. Les exemples considérés corrects par un critique mais incorrects par l’autre sont signalés pour examen. Cette structure en deux questions permet d’identifier les sorties plausibles mais erronées que les systèmes à critique unique manquent.

L’équipe a testé cette chaîne avec Gemini 2.5 Flash comme modèle professeur et Gemma-3 4B comme élève, généré jusqu’à 512 000 points de données par domaine, et évalué sur cinq domaines. Le résultat majeur — que les données synthétiques égalaient ou dépassaient les données réelles dans des domaines spécialisés — s’est vérifié sur de multiples évaluations.

La mise en garde honnête du papier, que personne ne cite sur Twitter : il n’existe pas de configuration optimale unique. La relation entre « bonne » donnée synthétique et performance aval du modèle est, selon les chercheurs, profondément idiosyncratique. Chaque domaine réclame des mix de complexité différents, des profondeurs de taxonomie différentes, des pondérations différentes pour les critiques. Simula fournit les leviers ; il ne vous dit pas où les placer.

Mais l’important n’est pas que Simula est une solution miracle. Ce qui compte, c’est que le paradigme a changé. La question n’est plus « combien de données pouvez-vous collecter ? », mais « à quel point pouvez-vous concevoir les données ? » Et les vainqueurs de la prochaine vague d’IA spécialisée ne seront pas les laboratoires qui rassemblent le plus de données. Ce seront ceux qui auront les meilleurs taxonomistes.

Euphan : Pourquoi OpenAI a discrètement développé un visualiseur de logs

Permettez-moi de m’arrêter ici, car le second outil de cette histoire nécessite un contexte que le premier n’exigeait pas.

Si vous n’avez jamais conçu un système d’IA de type agent, la notion de « log » évoque sans doute un élément de dashboard dans un datacenter. Quelque chose de rébarbatif. Quelque chose dont seuls les opérationnels se soucient. Laissez-moi corriger ce préjugé, car il est trompeur au point de réellement pénaliser les développeurs.

Un agent exécutant une tâche même modérément complexe — par exemple, rechercher un sujet, extraire des données structurées, rédiger un brouillon et le publier quelque part — génère un log qui n’a rien à voir avec un log serveur traditionnel. Il s’agit d’un arbre imbriqué d’appels d’outils, de réponses de modèles, de traces de raisonnement, de sorties intermédiaires, de tentatives de relance, d’octrois d’autorisations et de transitions d’état. Un seul run d’agent peut produire des milliers de lignes de JSON. La majeure partie n’est que bruit. Seul un faible pourcentage raconte vraiment ce que l’agent a fait, et pourquoi.

Quand cet agent se comporte de manière inattendue — et ils le font tous tôt ou tard — votre tâche, en tant que développeur, est de repérer ce point dans le log où le raisonnement a dérapé. Dans un log bien structuré, c’est fastidieux. Dans un dump JSON brut, cela devient des heures de défilement. J’ai passé de longues soirées à éplucher à grands coups de grep les logs d’agents pour comprendre pourquoi un appel d’outil n’avait pas eu lieu alors qu’il l’aurait dû, ou pourquoi un modèle avait halluciné un paramètre absent du prompt.

C’est ce manque qu’OpenAI a discrètement choisi de combler. Le nom interne qui circule est Euphan, même si la société a depuis publié la plupart de ces fonctionnalités à travers le tableau de suivi du tracing de son Agents SDK et la nouvelle interface workspace-agents dans ChatGPT. Peu importe le nom du système sous-jacent, sa mission est précise et cruciale : transformer les logs bruts des agents en quelque chose que l’humain peut lire efficacement.

Concrètement, cela donne :

• Des timelines structurées et lisibles. À la place d’un JSON imbriqué, on obtient une séquence linéaire d’étapes, chacune avec un rôle bien défini (planificateur, récupérateur, appelant d’outil, répondant), un timestamp, et un résumé en une ligne. On clique sur une étape pour détailler. On survole la timeline afin de repérer le point d’inflexion.
• Inspection des rôles et des outils. Chaque appel d’outil indique quel agent l’a initié, quels paramètres ont été transmis, quel a été le résultat, et combien de temps cela a pris. Si un outil renvoie une erreur de type 429 (rate-limit) après quarante minutes d’exécution, la timeline le remonte automatiquement, sans qu’il faille fouiller.
• Visibilité du raisonnement décisionnel. Les agents modernes produisent des traces de raisonnement — la justification interne du modèle pour préférer une action à une autre. Une interface lisible rend ces traces visibles sous forme d’annotations en ligne sur la timeline, ce qui permet de comprendre non seulement ce qu’a fait l’agent, mais aussi pourquoi il a estimé que c’était la bonne décision.
• Édition directe des logs. C’est la fonctionnalité qui m’a le plus surpris. On peut modifier une entrée de log, enregistrer l’état modifié, puis relancer l’exécution à partir de ce point. C’est le git rebase appliqué à l’historique d’un agent. Je n’ai vu cette fonctionnalité correctement implémentée nulle part ailleurs.
• Filtrage, recherche et requêtes sur les métadonnées. Lorsque les runs s’étalent sur des heures et des milliers d’étapes, grep ne suffit plus. Il faut des requêtes structurées. « Montre-moi tous les appels d’outils avec status != 200. » « Montre-moi les traces de raisonnement où la confiance est tombée sous 0,6. » Cette couche existe.

La raison pour laquelle je reviens toujours à cet outil, même s’il est moins tape-à-l’œil qu’un nouveau modèle de frontier, c’est qu’il résout un vrai problème auquel je me heurte chaque semaine. Lorsque j’ai monté ma propre stack d’agents via le Anthropic Agent SDK, la partie la plus difficile n’était pas l’écriture de l’agent. C’était le debug dès que l’agent déraillait. J’ai fini par bricoler un visualiseur de logs dans une base Notion, parce que je ne supportais plus de lire du JSON brut. Si j’avais disposé d’Euphan — ou d’une interface équivalente pour les logs Anthropic — mon projet serait sorti une semaine plus tôt.

C’est de l’infrastructure pour développeurs. Ce n’est pas une fonction grand public. Ça ne fera pas l’objet d’une démo en keynote. Mais les équipes qui mettent en production des agents se souviendront des outils d’interprétation de logs comme du moment où l’ensemble du workflow est enfin devenu gérable.

Passons maintenant à la troisième pièce.

Hermes : Le passage du chatbot au coéquipier toujours actif

Hermes est le nom de code ayant fuité des versions internes d’OpenAI ces dernières semaines, et je veux être prudent ici car il y a une confusion autour du nom sur le marché. La communauté open source dispose déjà d’un outil baptisé Hermes Agent développé par Nous Research — j’ai rédigé un article sur son association avec OpenClaw dans un workflow à deux agents. Le Hermes d’OpenAI est une toute autre chose. Même nom, société différente, architecture différente. Le contexte compte.

Le Hermes d’OpenAI — du moins d’après les ressources frontend ayant fuité et les modules préchargés présents dans l’application web ChatGPT — est une plateforme d’agents persistants. Pas des exécuteurs de tâches ponctuelles. Pas “exécute cette tâche et rends la réponse”. Ce sont des agents que vous définissez une fois et qui continuent d’exister entre les sessions, exécutant un travail planifié, répondant à des déclencheurs, restant connectés à des outils externes et vous informant dès qu’un événement pertinent survient.

Si cela vous semble familier, c’est parce que c’est la même direction architecturale que celle prise par Anthropic avec ses agents managés, et la même orientation vers laquelle une douzaine de plus petites entreprises (y compris Hermes Agent de Nous Research que je viens d’évoquer) se sont engagées. Les agents persistants ne sont pas une idée propriété d’un seul fournisseur. C’est le prochain pas qui fait consensus.

Ce qui distingue la démarche d’OpenAI, c’est la distribution. ChatGPT compte des centaines de millions d’utilisateurs. Lorsque les agents persistants seront intégrés à ce produit — non pas comme surface de développement séparée, mais comme fonctionnalité activable par n’importe quel utilisateur Plus — le comportement par défaut consistant à “discuter avec une IA” changera d’une manière qui, avec le recul, semblera ordinaire, mais qui paraît aujourd’hui radicale.

À quoi ressemblera Hermes lors de son lancement, sur la base des ressources divulguées et du modèle suivi par toutes les plateformes d’agents persistants existantes :

• Définitions d’agents persistantes d’un chat à l’autre. Vous créez un agent une fois — vous lui attribuez un rôle (“mon assistant de recherche”), un ensemble de compétences, une liste de tâches, peut-être certaines autorisations d’accès. L’agent devient accessible depuis n’importe quelle conversation. Vous n’avez plus besoin de le réinitialiser à chaque fois.
• Exécution programmée ou sur déclencheur. L’agent fonctionne selon son propre planning (tous les matins à 7h, il résume l’actualité de la nuit) ou sur des déclencheurs (dès qu’une nouvelle entrée apparaît dans ma base Notion, il rédige une réponse). C’est le passage du réactif au proactif.
• Connexions aux outils qui restent actives. Les agents gardent des connexions authentifiées avec des services externes — Gmail, Calendar, GitHub, Slack, selon le modèle d’autorisation en place. L’outil n’a pas besoin de se réauthentifier à chaque exécution. Tout est déjà prêt.
• Mémoire longue durée. Les agents se souviennent des exécutions précédentes, des résultats passés, des retours antérieurs. Si vous avez indiqué à l’agent la semaine dernière que vous préférez les résumés en trois points plutôt qu’en paragraphe, il s’en souviendra indéfiniment, sauf remise à zéro manuelle.

Aucune date de sortie n’est connue. La fonctionnalité est encore en test interne, accessible uniquement via l’inspection des ressources frontend. Cela dit, OpenAI affiche publiquement cette volonté — des agents de workspace ont été livrés en avril 2026 pour les offres Business, Enterprise et Edu, qui reposent sur la majorité des concepts architecturaux sur lesquels Hermes s’appuierait. La tendance est nette. La question n’est pas de savoir si, mais quand.

Mais voici ce que je garde constamment en tête. Les agents persistants ne fonctionnent pas sans les deux premiers éléments.

Les agents persistants ont besoin d’une capacité spécialisée — un agent qui fonctionne en continu dans un domaine spécifique (recherche juridique, surveillance de sécurité, analyse financière) requiert un modèle entraîné sur des données propres à ce domaine. Les modèles généralistes échouent sur les tâches spécialisées, et ces échecs se multiplient quand l’agent fonctionne sans surveillance. Voilà le problème Simula.

Les agents persistants requièrent de l’observabilité — un agent actif 24h/24, 7j/7 génère énormément plus de logs qu’un agent basé sur une session. Sans un outil comme Euphan, déboguer un agent persistant en production nécessite des heures passées à fouiller dans les logs dès qu’un souci survient. Voilà le problème Euphan.

Les agents persistants ont besoin d’un runtime — ce que fournit Hermes en lui-même.

On ne peut pas simplement livrer la troisième brique. Les trois doivent fonctionner ensemble, sinon toute la pile s’effondre sous son propre poids. Ce qui m’amène au point essentiel que je souhaite vraiment que vous reteniez de ce post.

Ce que cette combinaison signifie réellement pour les constructeurs

Prenez du recul un instant. Ce que nous observons, en temps réel, c’est l’ensemble du pipeline de développement de l’IA qui est en train d’être reconstruit, en repartant de la couche de données.

La couche de données est en train d’être reconstruite avec des systèmes comme Simula, où la génération synthétique combinée à un raisonnement et à un échantillonnage basé sur une taxonomie produit des données d’entraînement supérieures à ce qui peut être extrait du web.

La couche d’observabilité est remise à plat avec des outils d’interprétation de logs comme Euphan, où des traces désordonnées multi-agents se transforment en timelines lisibles et vraiment déboguables.

La couche d’exécution est réinventée avec des plateformes d’agents persistants comme Hermes, où les agents cessent d’être de simples tâches uniques et deviennent de véritables coéquipiers de longue durée.

Chacune de ces couches est importante individuellement. Mais c’est leur combinaison qui change tout.

Si vous construisez quoi que ce soit de sérieux sur ces modèles en 2026 — un produit SaaS, un outil interne, une chaîne de création de contenu, une solution d’automatisation — voici la conséquence pratique : il faut arrêter de considérer que le goulot d’étranglement, c’est le modèle. Vérifiez vos hypothèses en vous posant ces trois questions :

1. Mon cas d’usage est-il suffisamment spécialisé pour qu’un modèle généraliste sous-performe ? Si oui, la solution n’est pas de changer pour le dernier modèle de pointe. La solution, c’est d’attendre l’arrivée d’un modèle spécialisé, entraîné sur des données façon Simula, ou d’en construire un vous-même avec une génération synthétique sur votre propre taxonomie.
2. Quand mon agent dysfonctionne, combien de temps me faut-il pour comprendre pourquoi ? Si la réponse c’est “des heures” ou “en général, je redémarre et j’espère que ça marche”, c’est que vous avez besoin d’une meilleure observabilité, pas d’un meilleur agent. Commencez dès maintenant à adopter des outils d’interprétation de logs, même imparfaits, car leur valeur s’accumule rapidement.
3. Est-ce que je reconstruis l’état à chaque session ? Si vous continuez à utiliser des agents comme de simples conversations chat ponctuelles, vous vous situez du mauvais côté de la courbe. Pensez la persistance sans attendre l’arrivée d’Hermes : découplez l’état de votre agent de l’interface chat, stockez-le de façon durable, et le coût de migration vers les plateformes d’agents persistants sera minime.

Rien de tout ça n’est facile. Je me confronte moi-même à ces questions sur ma propre stack — dont j’ai évoqué certaines dans l’article “former des agents IA autonomes” — et les réponses me poussent systématiquement vers plus d’infrastructure et moins de magie. Plus de taxonomie, plus de logs, plus de gestion d’état. Moins de “lancer ça au modèle et voir ce qui se passe”.

Au fond, c’est la même leçon que chaque discipline d’ingénierie sérieuse finit par apprendre : la magie réside dans les parties ennuyeuses.

Parlons franchement : où cela casse selon moi

Je ne veux pas vous laisser croire que ces trois outils sont la solution complète, car ce n’est pas le cas. Voici ce que j’identifierais comme limites réelles et problèmes ouverts.

Simula fonctionne parce que les modèles sous-jacents sont suffisamment performants. Dès que l’on tente d’appliquer la même chaîne avec un générateur plus faible, la paramétrisation de la complexité amplifie les erreurs au lieu d’améliorer la qualité. La plupart des équipes n’ont pas accès à Gemini 2.5 Flash comme modèle enseignant. Ce à quoi pourraient ressembler des pipelines équivalents à Simula avec un budget serré reste une question non résolue.

L’interprétation des logs à la Euphan n’a de valeur que si la structure des logs de base est solide. Si le framework d’agent que vous utilisez génère des logs brouillons et non structurés — ce qui est encore souvent le cas —, aucune couche d’interprétation ne pourra faire émerger de la clarté à partir de données médiocres. Le format de log doit être pensé dès le départ pour garantir l’observabilité.

Les agents persistants posent une question de sécurité à laquelle personne n’a encore vraiment répondu. Un agent qui tourne en continu avec des connexions authentifiées à votre Gmail, votre GitHub, votre agenda, représente une large surface d’attaque. Si le raisonnement de l’agent peut être manipulé — par injection de prompt via un email entrant, ou par un résultat de recherche compromis —, le périmètre de dommage potentiel englobe tout le graphe authentifié. Toutes les plateformes d’agents persistants que j’ai pu voir en sont conscientes, mais aucune ne l’a complètement solutionné. C’est pour cela que les outils de sécurité pour les agents IA vont devenir une catégorie majeure, et que j’y reviens systématiquement.

La vérité, c’est que ces trois outils indiquent la direction, pas la destination. Les dix-huit prochains mois de développement dans l’IA vont consister à comprendre comment faire fonctionner toute cette pile, de bout en bout, en production, pour des cas d’usage qui ne se limitent pas à “générer un article de blog” ou “résumer un document.” Du vrai travail. De vraies conséquences. De vraies exigences de disponibilité.

Et c’est exactement ce genre de problématique sur laquelle j’ai envie de travailler.

Ce que j'observe pour la suite

Trois éléments précis que je vais suivre au cours du prochain trimestre.

Premièrement, les répliques open source de Simula. L’article est suffisamment détaillé pour qu’une équipe motivée puisse reconstruire tout le pipeline en dehors de l’infrastructure Google. J’anticipe une première implémentation open source sérieuse d’ici 60 jours, et celui qui parviendra à la livrer proprement s’imposera comme l’outil de référence pour la génération de données synthétiques spécialisées dans l’écosystème open source.

Deuxièmement, les standards d’interprétation des logs. Actuellement, chaque framework d’agents dispose de son propre format de log. Celui d’OpenAI diffère de celui d’Anthropic, qui diffère de celui de LangChain, qui diffère encore de celui de Nous Research. Cette fragmentation va rendre nécessaire la création d’un standard commun pour les traces — probablement basé sur les conventions OpenTelemetry — et le premier framework à offrir une réelle interopérabilité remportera la préférence des développeurs.

Troisièmement, la fenêtre de lancement d’Hermes. J’estime à 60 % la probabilité d’une sortie publique avant la fin du 3ᵉ trimestre 2026, vu l’avancée de l’intégration frontend. Si le produit est lancé, le modèle de « l’agent always-on » passera d’une niche pour développeurs à la norme pour des centaines de millions d’utilisateurs de ChatGPT en quelques semaines. Ce sera un événement clé du secteur.

Gardez un œil sur ces trois points. L’un d’entre eux sera probablement la plus grande actualité IA de l’été.

L’article dont je parlais au début — le papier sur Simula que j’ai failli ignorer — est la raison pour laquelle je pense désormais que le travail IA le plus crucial en 2026 ne se fait pas sur la couche modèle. Il se fait sur la conception de données, l’observabilité et le runtime. C’est terre-à-terre. Cela ressemble à de l’infrastructure. Mais les conséquences sont immenses.

Si vous ne devez retenir qu’une phrase de ce post, relisez celle-ci deux fois. Puis examinez votre propre stack et demandez-vous laquelle de ces trois couches est la plus vulnérable. Corrigez-la en priorité. Tout le reste en découlera.

Foire aux questions

Qu’est-ce que la génération de données synthétiques pour l’entraînement de l’IA ?

La génération de données synthétiques consiste à utiliser des modèles d’IA pour produire des exemples d’entraînement qui n’existaient pas dans le jeu de données d’origine. Des systèmes modernes comme Simula de Google utilisent des taxonomies orientées raisonnement et une validation par double critique, afin que les données générées égalent ou surpassent les données réelles dans des domaines spécialisés. Pour le détail du mécanisme, consultez la section Simula ci-dessus.

Pourquoi les données synthétiques sont-elles meilleures que les données réelles pour les domaines spécialisés de l’IA ?

Les données réelles dans des domaines comme la cybersécurité, le droit ou la médecine sont souvent soumises à des lois sur la confidentialité, fragmentées entre des sources propriétaires, ou tout simplement inexistantes en volume suffisant pour l’entraînement. Des données synthétiques bien conçues peuvent couvrir l’ensemble de la taxonomie du domaine — y compris les cas rares — avec une qualité maîtrisée. Selon les benchmarks de Simula chez Google, des modèles entraînés sur des données synthétiques ont parfois dépassé les modèles entraînés sur données réelles sur des tâches spécialisées.

Qu’est-ce que le mode collapse dans les données synthétiques et comment l’éviter ?

Le mode collapse survient lorsqu’un générateur produit des exemples répétitifs et restreints qui semblent variés en surface, mais ne couvrent en réalité qu’une fine portion de la distribution réelle. Simula l’évite en échantillonnant à travers une taxonomie structurée et en utilisant des métaprompts — des prompts qui génèrent d’autres prompts — pour forcer de véritables variations dans l’angle, le format et la profondeur du raisonnement.

Quand la plateforme Hermes d’agents persistants d’OpenAI sera-t-elle lancée ?

OpenAI n’a pas annoncé de date de sortie pour la fonctionnalité d’agents persistants Hermes. Des ressources front-end et des modules préchargés repérés dans l’application web ChatGPT laissent entrevoir un développement actif, et des fonctionnalités connexes, comme les agents de workspace, ont déjà été lancées en avril 2026 pour les offres Business, Enterprise et Edu. Un lancement public de Hermes en 2026 semble probable vu cette trajectoire.

Qu’est-ce qu’un interpréteur de logs d’agents IA et pourquoi les développeurs en ont-ils besoin ?

Un interpréteur de logs d’agents IA est un outil qui convertit des logs bruts et imbriqués d’agents — appels d’outils, traces de raisonnement, tentatives, transitions d’état — en chronologies structurées et lisibles. L’interface façon Euphan d’OpenAI et le tableau de bord de traçage Agents SDK affichent chaque étape, le rôle exécuté, les outils sollicités et la logique de chaque décision. Sans cette couche, déboguer un agent qui se comporte mal signifie faire défiler des milliers de lignes de JSON brut.

Travaillons ensemble

Vous souhaitez développer des systèmes d’IA, automatiser vos flux de travail ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous accompagner.

• Fiverr (créations sur mesure & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprises) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io