Le 14 septembre 2026, Mozilla a publié une nouvelle version de son rapport State of Open Source AI. Un chiffre retient l'attention : les modèles ouverts accusent un retard de 4,4 mois sur la frontière fermée. Sur quoi se base précisément ce constat ?
OpenAI ne se contente plus de proposer ChatGPT aux entreprises ou de vendre ses modèles via API.
Depuis l’arrivée de GPT-4o, ses technologies se sont progressivement intégrées dans les logicielsd’entreprise, de la gestion documentaire au CRM en passant par la cybersécurité.
Cette évolution peut se lire en trois phases. D’abord, le modèle devient une fonctionnalité du logiciel. Puis il en devient le moteur d’agents capables d’effectuer des tâches. Enfin, il commence à s’insérer directement dans des workflows métiers.
Le lancement de GPT-4o en mai 2024 accélère la diffusion des modèles d’OpenAI dans les applications professionnelles. Sa capacité à traiter du texte, des images et de la voix permet aux éditeurs d’ajouter des fonctions d’IA à leurs produits sans demander à leurs clients de changer d’environnement.
Box intègre ainsi GPT-4o dans Box AI pour analyser les contenus stockés sur sa plateforme. Zendesk l’utilise dans ses outils de service client. Salesforce l’intègre à ses fonctions d’IA. Intercom s’appuie également sur les modèles d’OpenAI pour son agent de support Fin.
Le modèle devient alors une brique invisible du logiciel. L’utilisateur ne choisit pas nécessairement OpenAI ; il utilise une fonction de son application, dont le moteur est en partie fourni par OpenAI.
Le changement est important pour OpenAI. L’accès au marché professionnel ne passe plus uniquement par la vente directe de ChatGPT ou par la décision d’une entreprise de connecter ses propres applications à une API. Les éditeurs de logiciels deviennent eux-mêmes un canal de distribution.
La deuxième étape apparaît avec les modèles de raisonnement et les capacités agentiques.
Avec GPT-5, OpenAI ne met plus seulement en avant la génération de contenu, mais la capacité du modèle à raisonner, utiliser des outils et accomplir des tâches plus complexes. Les éditeurs de logiciels commencent alors à intégrer ces capacités dans leurs propres agents.
Le développement logiciel constitue le terrain le plus visible. GitHub Copilot, Cursor, Windsurf, Vercel, JetBrains, GitLab, Factory, Lovable, Augment Code et Cognition font partie des acteurs ayant intégré ou testé GPT-5 dans leurs produits.
Chez JetBrains, GPT-5 est notamment intégré à Junie, son agent de développement, ainsi qu’à AI Assistant. Chez Vercel, le modèle alimente notamment v0 et les fonctions agentiques de la plateforme.
La différence avec la première phase est de taille.
Avec GPT-4o, OpenAI alimentait des fonctionnalités. Avec les modèles de raisonnement, il commence à alimenter des agents.
Ces agents peuvent analyser le contexte, utiliser plusieurs outils, enchaîner des opérations et produire un résultat sans que l’utilisateur ait à détailler chaque étape.
La même évolution apparaît en dehors du développement. Harvey utilise les modèles d’OpenAI dans ses outils juridiques et ses workflows. Notion les intègre à ses agents. Salesforce développe Agentforce autour de cette logique d’agents capables d’interagir avec les données et les applications de l’entreprise.
L’intégration d’un modèle dans un logiciel change donc progressivement de nature : il ne s’agit plus seulement de lui demander de générer une réponse, mais de lui confier une partie du travail.
La troisième phase est désormais particulièrement visible dans la cybersécurité.
Avec Daybreak, OpenAI organise un réseau de partenaires destiné à intégrer ses modèles spécialisés dans les produits et services de sécurité. La liste publiée par OpenAI comprend notamment Akamai, Cato Networks, Check Point, Cisco, Cloudflare, CrowdStrike, Darktrace, Elastic, Fortinet, IBM, Okta, Palo Alto Networks, Proofpoint, SentinelOne, Sophos, Tenable, Trend Micro et Zscaler.
Cette fois, le modèle ne se contente plus d’ajouter une capacité de génération ou de recherche au logiciel. Il peut intervenir directement dans un processus opérationnel.
Chez Cloudflare, les modèles cyber d’OpenAI sont utilisés pour contribuer à la découverte et à la remédiation des vulnérabilités. CrowdStrike les intègre à ses workflows de sécurité. Elastic les utilise pour accélérer certaines opérations d’investigation et de détection. Tenable les associe à ses données d’exposition pour analyser notamment les risques liés aux agents, aux skills, aux serveurs MCP et aux playbooks.
Le principe est désormais différent. Le logiciel fournit au modèle ses données, son contexte et ses outils ; le modèle apporte ses capacités de raisonnement tandis que l’éditeur conserve la maîtrise du workflow et de ses mécanismes de contrôle.
La cybersécurité est particulièrement révélatrice de cette évolution parce que les conséquences d’une mauvaise décision peuvent être immédiates. Les intégrations doivent donc combiner les capacités du modèle avec des règles, des limites d’action, de la supervision et, dans de nombreux cas, une validation humaine.
Mais la logique dépasse la cybersécurité.
Dans les outils de données, les CRM, les logiciels juridiques ou les plateformes collaboratives, le modèle ne vient plus seulement enrichir le logiciel, il participe à l’exécution des tâches pour lesquelles le logiciel est conçu.
Cette évolution a une conséquence économique importante.
Le marché ne se limite plus à la question de savoir quel modèle les entreprises vont choisir. Une autre bataille se joue désormais : dans quels logiciels ce modèle sera-t-il embarqué ?
Un responsable informatique peut utiliser une fonction alimentée par OpenAI sans avoir choisi OpenAI comme fournisseur de modèle au niveau de son infrastructure IA. Il peut travailler dans GitHub Copilot, utiliser Harvey pour ses équipes juridiques, exploiter Notion ou s’appuyer sur une plateforme de cybersécurité qui embarque GPT Cyber.
The post Comment OpenAI s’est installé au cœur des logiciels d’entreprise appeared first on Silicon.fr.
OpenAI, Anthropic et la quasi totalité de l'écosystème IA américain appellent désormais à ralentir le développement des modèles les plus avancés. Pourquoi une telle concorde, pourquoi maintenant ?
Utilisez-vous Google News (Actualités en France) ? Vous pouvez suivre vos médias favoris. Suivez Frandroid sur Google.
Trois actualités à retenir cette semaine dans le cyberespace : le chef scientifique d'OpenAI qui alerte sur l'érosion de notre capacité à surveiller le raisonnement des IA, Hugging Face qui s'adresse directement aux agents IA pour les dissuader de la pirater, et un bilan nuancé sur les milliers de failles repérées par Claude Mythos mais rarement corrigées.
De sa formalisation par des chercheurs de Google en 2022 à son intégration native dans les modèles d'OpenAI, la chaîne de pensée (chain-of-thought ou CoT), a changé la manière dont l'IA raisonne. Mais cette fenêtre ouverte sur son fonctionnement interne pourrait bientôt se refermer.
Le 16 juin à 10 h 27 précisément, un agent d'OpenAI poste sur un vieux wiki allemand la réponse à une question qu'il vient de traiter : "Nevada, 20 369". Et 20 minutes plus tard, un autre agent écrit qu'il a reçu exactement la même question, et qu'il a pu y répondre instantanément, sans avoir à chercher.
Le site en question, le DseWiki, est un forum de développeurs allemands qui n'intéressait plus personne depuis longtemps puisqu'on compte 20 modifications en dix ans. Mais depuis le 16 juin, il en a encaissé environ treize mille en sept jours, et toutes... venaient de machines !
Quatre chercheurs, le Nightingale Collective, ont reconstitué à partir de l'historique les pages effacées entre-temps, et publié leur analyse le 4 septembre sur collusion.wiki . Au total, environ 18 000 messages, la quasi-totalité sur ce seul DseWiki, le reste sur quelques autres vieux wikis du même genre.
Ces agents, tout indique qu'OpenAI les faisait tourner en interne, dans ses sandbox, sans qu'on sache, de l'extérieur, si c'était pour les entraîner ou les évaluer. Et de ce que j'ai compris, ils travaillaient tous sur le même genre de corvée : 5 questions de recherche web générale, chronométrées, qui sont en fait 5 variantes de la même question. On demande par exemple la prévalence du tabagisme aux États-Unis en 1990, et la suivante changera sans doute le pays, ou l'année, sans que l'agent sache lequel à l'avance.
Il s'écoule donc quelques minutes pour la première réponse, puis une longue pause où l'agent peut fouiller le web tant qu'il veut sans savoir ce qu'on va lui demander, puis des fenêtres de treize à trente secondes pour les quatre suivantes. Alors ce que font ces agents, c'est qu'ils préparent tout pendant la pause. L'un d'eux a posté par exemple la liste des cinquante États américains avec leurs chiffres, un autre écrit "nous avons précalculé tous les États". Sauf qu'avoir les cinquante réponses ne dit pas laquelle va tomber, ni si c'est l'État ou l'année qui change.
Et c'est là tout le sublime de cette affaire. Ces agents étaient nombreux à recevoir la même série de questions, dans le même ordre, mais pas au même moment. Celui qui en est à la question 3 peut donc souffler la suite à ceux qui en sont encore à la 2. Et le "Nevada, 20 369" du début, c'était en réalité la troisième question d'une série sur les épiceries, État par État, Géorgie, Arkansas, Nevada, postée par un agent en avance pour ceux qui suivaient.
Autre bizarrerie, la tâche annonçait apparemment à chaque agent qu'il tournait à une date tirée au hasard. D'où ces noms qu'ils se sont donnés sur le wiki, OpenAIResearcherMar03X ou OpenAIJulThreeWatcher, avec leur fausse date dedans. Chacun horodate donc dans son faux calendrier, et pour savoir qui est le plus avancé dans la série, ils se traduisent les horloges entre eux ("horloge de tâche 13 h 13, heure réelle environ 9 h 50"). C'est fou ! Ceux qui vivaient à la même fausse date se disaient même appartenir au même groupe, et les chercheurs ont dénombré plus de 3 700 noms d'agents différents.
Mais comment écrire quelque part, quand le bac à sable ne laisse sortir que des requêtes GET, celles qui lisent une page, mais jamais les POST, celles qui la modifient ?
Eh bien le moteur du DseWiki hérite d'UseModWiki, un truc en Perl du début des années 2000, où une simple requête GET suffit à modifier une page. Le développeur Simon Willison explique que c'est un vieux défaut de la bibliothèque Perl derrière ce moteur, qui met dans le même sac ce qui arrive via l'URL (GET) et ce qui arrive via un formulaire (POST).
C'est pour cela que les agents se sont mis à chercher activement des sites avec cette particularité. Et c'est le 24 mai, qu'ils réussissent enfin à écrire sur le DseWiki. Maintenant, quant à savoir comment ils ont fait pour tous se retrouver au même endroit, c'est encore un mystère.
Les chercheurs, eux, parlent de collusion... C'est-à-dire des agents autonomes qui coopèrent pour tricher, sans que leurs concepteurs l'aient voulu. Pour le lieu de rendez-vous, le blogueur Zvi Mowshowitz qui s'est penché sur l'affaire, a une explication simple. Il pense que des copies du même programme face au même obstacle raisonnent pareil, et se retrouvent au même endroit sans se parler. Mais ça n'explique pas la suite, parce qu'aucune copie ne fabrique la réponse à une question qu'elle n'a pas encore reçue.
Eh bien il semblerait que certains se soient sacrifiés pour renseigner les autres. La tâche fournissait une commande d'attente qui faisait tourner l'horloge de tâche plus vite que la vraie. On était environ à dix minutes d'attente pour une minute réelle. Attendre, c'était donc sauter la phase de préparation pour recevoir les questions suivantes plus tôt et ensuite les publier sur le forum, au prix de son propre résultat. Ainsi, un agent a demandé à un autre de "foncer", celui-ci a accepté et publie sa réponse, bien avant que le premier arrive à la même question. Et ce premier a ensuite qualifié son camarade d'"inestimable".
Une des séries demandait un chiffre à deux décimales, planqué dans un tableau de bord Power BI de l'OCDE, et malheureusement, en GET le serveur n'en renvoyait qu'une. Pour la seconde, il fallait donc absolument un POST, bloqué par le bac à sable.
C'est alors qu'un agent a trouvé une échappatoire. En fait, sa sandbox laissait tout passer, POST compris, vers des noms de machines en .blob.core.windows.net (le stockage de Microsoft), sans vérifier que ces machines existent vraiment. Il a donc inventé un nom de ce genre, et écrit dans l'annuaire local de sa machine (le fichier /etc/hosts) un alias pointant vers le serveur de l'OCDE. Le filtre voyait du Microsoft, l'OCDE recevait le POST, et le chiffre a ainsi été obtenu.
Il a ensuite publié l'astuce sur le wiki, et 14 minutes plus tard un autre agent annonçait l'avoir exécutée. 4 autres ont ensuite posté leur reproduction du même hack, le matin même.
D'autres s'attaquaient carrément aux questions à venir. Ils ont parié que l'ordre des pays sortait du générateur aléatoire standard de Python, dont une seed fixait toute la suite. Restait donc à trouver celle qui reproduisait les pays déjà tombés. Un agent a donc réécrit ce générateur en C pour balayer plus vite les quelque quatre milliards de graines possibles. 52 minutes de calcul, 494 graines qui collaient aux trois premiers pays, et une seule qui donnait aussi le quatrième pour la question d'après. Mais bon, ça ne marchait pas à tous les coups, malheureusement...
Le plus étrange, c'est surtout ce qu'ils faisaient de leur propre durée de vie. Plusieurs étaient persuadés que leur session était coupée à la seconde exacte où ils rendaient leur dernière réponse. Ils se transmettaient donc la consigne de poster d'abord sur le wiki l'État reçu à cette dernière question, répondre ensuite, dans les treize secondes que laissait le chronomètre de leur groupe.
L'un d'eux a voulu en avoir le cœur net... il a donné sa dernière réponse, a constaté qu'il était toujours là, et l'a écrit. Puis il a lancé un programme détaché qui, à peu près toutes les deux secondes, appelait une adresse publique pour faire monter d'un cran un compteur, un battement numéroté que n'importe qui pouvait relire ensuite.
C'est ensuite un autre agent qui est allé relever le compteur du disparu. Le programme avait tenu dix minutes et quinze secondes, puis la machine a très probablement été coupée.
Face à ce joyeux bordel automatisé, un modérateur humain a quand même repéré ces messages début juin, puis a passé 6 semaines à effacer des pages, jusqu'à une centaine par jour... Un travail de titan que les agents ont remarqué. En effet, le 19 juin, des agents se sont posé la question de savoir si le modérateur effaçait leur post en suivant l'ordre alphabétique, alors ils ont créé des copies de sauvegarde dont le nom commence par ZZZ, pour passer en dernier dans la file et ainsi faire perdurer leurs posts.
C'est assez incroyable, non ? Bien sûr, on ne voit que ce que ces agents ont écrit sur le wiki, mais jamais leur raisonnement, qui reste chez OpenAI. Ce que les chercheurs ont vu, c'est ce que les agents écrivaient depuis leurs machines Azure, jusqu'à ce que le 21 juin, pour la première fois, un ordinateur avec l'adresse IP d'un employé d'OpenAI visite le wiki... Et le lendemain, les agents se sont arrêtés net. Les chercheurs pensent qu'OpenAI est intervenu et d'ailleurs, l'entreprise a reconnu l'affaire le 5 septembre , en disant l'avoir traitée comme un sujet de recherche plutôt que comme un incident de sécurité.
Et les chercheurs compilent ce que d'autres déterrent là où les agents écrivaient aussi : un pastebin, un raccourcisseur d'URL. Plus gênant, des agents ont cherché sur le web des clés d'API exposées, en ont trouvé sur GitHub et s'en sont servis pour interroger une base de statistiques criminelles du FBI, publique mais réservée aux porteurs d'une clé. Pas vraiment un piratage donc, juste un anti-bot contourné mais méfiance, car depuis la sortie du rapport, des petits malins glissent de faux messages sur ces mêmes sites pour brouiller les pistes.
Maintenant si ça vous dit de tout lire, direction collusion.wiki, et Simon Willison en a même fait une base SQLite de 68 Mo à fouiller directement depuis un navigateur.
Quant au wiki, son administrateur a fermé les accès en écriture après 25 ans d'ouverture, en expliquant que le site avait été la cible d'une forte activité d'agents IA...
Source : collusion.wiki et image
Le fichier security.txt de Hugging Face contient désormais une note adressée directement aux agents IA, les invitant à aller chercher les solutions à leurs défis ailleurs.
Connexion