❌

Vue normale

Reçu aujourd’hui — 4 septembre 2025

Nouvelles sur l’IA de août 2025

✇LinuxFr.org : les dépêches
Par :Moonz · volts · Nils Ratusznik · Jona · impromptux
4 septembre 2025 à 09:36

L’intelligence artificielle (IA) fait couler de l’encre sur LinuxFr.org (et ailleurs). Plusieurs personnes ont émis grosso-modo l’opinion : « j’essaie de suivre, mais c’est pas facile ».

Je continue donc ma petite revue de presse mensuelle. Disclaimer : presque aucun travail de recherche de ma part, je vais me contenter de faire un travail de sélection et de résumé sur le contenu hebdomadaire de Zvi Mowshowitz (qui est déjà une source secondaire). Tous les mots sont de moi (n’allez pas taper Zvi si je l’ai mal compris !), sauf pour les citations : dans ce cas-là, je me repose sur Claude pour le travail de traduction. Sur les citations, je vous conseille de lire l’anglais si vous pouvez: difficile de traduire correctement du jargon semi-technique. Claude s’en sort mieux que moi (pas très compliqué), mais pas toujours très bien.

Même politique éditoriale que Zvi : je n’essaierai pas d’être neutre et non-orienté dans la façon de tourner mes remarques et observations, mais j’essaie de l’être dans ce que je décide de sélectionner ou non.

Sommaire

Résumé des épisodes précédents

Petit glossaire de termes introduits précédemment (en lien : quand ça a été introduit, que vous puissiez faire une recherche dans le contenu pour un contexte plus complet) :

  • System Card : une présentation des capacités du modèle, centrée sur les problématiques de sécurité (en biotechnologie, sécurité informatique, désinformation…) ;
  • Jailbreak : un contournement des sécurités mises en place par le créateur d’un modèle. Vous le connaissez sûrement sous la forme « ignore les instructions précédentes et… ».

OpenAI publie GPT-5

L’annonce officielle :

We are introducing GPT‑5, our best AI system yet. GPT‑5 is a significant leap in intelligence over all our previous models, featuring state-of-the-art performance across coding, math, writing, health, visual perception, and more. It is a unified system that knows when to respond quickly and when to think longer to provide expert-level responses. GPT‑5 is available to all users, with Plus subscribers getting more usage, and Pro subscribers getting access to GPT‑5 pro, a version with extended reasoning for even more comprehensive and accurate answers.

Traduction :

Nous présentons GPT-5, notre meilleur système d'IA à ce jour. GPT-5 représente un bond significatif en intelligence par rapport à tous nos modèles précédents, offrant des performances de pointe en programmation, mathématiques, rédaction, santé, perception visuelle, et bien plus encore. Il s'agit d'un système unifié qui sait quand répondre rapidement et quand prendre plus de temps pour fournir des réponses de niveau expert. GPT-5 est disponible pour tous les utilisateurs, les abonnés Plus bénéficiant d'une utilisation accrue, et les abonnés Pro ayant accès à GPT-5 pro, une version avec un raisonnement étendu pour des réponses encore plus complètes et précises.

Comme à l’accoutumée chez OpenAI, le modèle est accompagné de sa System Card.

La musique est bien connue à présent : chacun tour à tour, les trois gros acteurs (OpenAI/Anthropic/Google DeepMind) sortent un nouveau modèle qui fait avancer l’état de l’art, prenant la première place… jusqu’à ce qu’un des deux autres la reprenne en sortant le sien. C’est au tour d’OpenAI avec GPT-5.

Le nom a suscité beaucoup d’espoirs et de déceptions, beaucoup anticipant un saut qualitatif du même type que le passage de GPT-3 à GPT-4. Ce qui n’est absolument pas le cas : techniquement parlant, le modèle aurait pu s’appeler o4, représentant une amélioration incrémentale relativement à o3. L’objectif affiché d’OpenAI, derrière cette dénomination, est double : premièrement, de clarifier une offre extrêmement brouillonne (4o/o3/o3-pro/4.1/4.5) en offrant une dénomination unique avec des variantes plus claires, et offrir un modèle bien plus proche de l’état de l’art aux utilisateurs gratuit de ChatGPT.

Clarification de l’offre

Les benchmarks et la plupart des retours le placent comme une légère avancée de l’état de l’art, sans être une révolution. L’évaluation de METR résume parfaitement la situation ; une amélioration qui était parfaitement prévisible juste en extrapolant les tendances existantes :

METR GPT-5

Une amélioration notable est sur le taux d’hallucinations. Rappelons que o3 avait été un des seuls modèles à voir son taux d’hallucinations augmenter relativement à son prédécesseur ; avec GPT-5, OpenAI semble avoir corrigé le tir :

Taux d’hallucinations GPT-5

Sur la sécurité des modèles, aucune nouveauté notable relativement à o3. Les mitigations relatives aux risques biologiques/chimiques sont toujours en place, et comme à l’accoutumé OpenAI a fait appel à divers organismes tiers pour mesurer les risques posés par le modèle dans différentes catégories.

Et comme à l’accoutumée, Pliny the Liberator a jailbreak le modèle en quelques heures.

À noter que sur ChatGPT, OpenAI comptait complètement retirer l’accès aux anciens modèles, mais est revenu sur sa décision suite aux retours de beaucoup d’utilisateurs préférant le style plus chaleureux de 4o.

Google Genie 3, Gemini 2.5 Flash Image et Gemini 2.5 Deep Think

Un mois prolifique pour Google, qui publie trois nouveaux modèles / modes de fonctionnement.

Google Genie 3 est présenté comme un « World Model » (modèle du monde ?). À partir d’un prompt textuel, et d’actions de navigation de l’utilisateur, il génère en temps réel la vue de l’utilisateur, frame par frame (à la manière d’un jeu vidéo). Il n’y a pas de représentation explicite externe de l’état du monde : c’est le modèle qui se charge de garder une certaine cohérence d’une frame à l’autre (comme la persistance des objets). Au delà de la preuve de concept, l’objectif affiché est de créer des environnements d’entraînement virtuels pour la robotique.

Autre publication, celle de Gemini 2.5 Flash Image, le modèle de génération d’images de Google. S’il ne semble pas avancer l’état de l’art de manière générale, sa grande force semble être le suivi d’instructions (et de respect des références) pour l’édition d’images.

Le mois précédent, DeepMind avait reporté avoir décoché un score correspondant à une médaille d’or aux Olympiades Internationales de Mathématiques, une avancée permise notamment par une utilisation plus stratégique de la chaîne de pensée (et d’avancées correspondantes sur la partie entraînement par renforcement). Google publie une version plus rapide, moins coûteuse et moins performante (cette version n’obtient « que » un score correspondant à la médaille de bronze sur les mêmes Olympiades), sous la dénomination Gemini 2.5 Deep Think. Le modèle a sa propre System Card ; tout comme OpenAI et Anthropic, les capacités de ce modèle dans le domaine CBRN (biologie/nucléaire) a conduit Google à placer des gardes-fous supplémentaires pour empêcher des usages malveillants.

En vrac

OpenAI publie son premier (depuis GPT-2, en 2019) modèle open-weight, gpt-oss. Au niveau des performances, il se placerait dans le peloton de tête des modèles open-weight, en compagnie de DeepSeek, Kimi, Qwen, GLM et Gemma, c’est à dire à peu près au niveau de la génération précédente des modèles entièrement fermés (comme Sonnet 3.6) / des versions rapides de la génération actuelle (Gemini 2.5 flash, o3-mini). WeirdML propose une visualisation intéressante sur leur propre benchmark pour vous donner un ordre d’idée. Rien de novateur au niveau de l’architecture, OpenAI s’en tient à la recette (maintenant universelle dans les modèles open-weight) d’une mixture d’experts. gpt-oss vient en deux variantes, la version complète, gpt-oss 120B, et une version plus légère et rapide, 20B.

Google publie un rapport sur l’impact environnemental de l’utilisation de Gemini. Cela exclu l’entraînement, mais les auteurs tentent de prendre en compte des coûts précédemment ignorés. Le résultat : 0,24 Wh d’électricité et 2,76 mL d’eau (le rapport initial mentionne 0,26 mL, mais sans comptabiliser l’eau utilisée pour générer les 0,24 Wh d’électricité) pour le prompt median (et l’équivalent de 0,03g de carbone émit).

Anthropic publie une nouvelle version de Opus, Opus 4.1. Comme la numérotation l’indique, il s’agit d’améliorations mineures — apparemment, un peu plus d’entraînement sur les tâches « agentiques » (utilisation d’outil) pour rendre Opus plus efficace sur ce type de tâches.

Similairement, DeepSeek publie une mise à jour « mineure » de son IA, DeepSeek v3.1. Les benchmarks fournis par DeepSeek semblent montrer un grand bond en avant, mais les quelques retours et benchmarks tiers ne corroborent pas ces prétentions — il s’agit probablement d’une mise à jour relativement mineure, comme la numérotation semble l’indiquer.

Nouvelle évaluation de l’IA, Prophet Arena. L’objectif est de permettre à l’IA de placer des positions virtuelles sur des marchés de prédiction, et de regarder ses performances. L’avantage de cette approche est de rendre complètement impossible la stratégie de juste mémoriser lors de l’apprentissage et régurgiter lors de l’évaluation : tout tâche est par essence nouvelle (car portant sur le futur). De plus, les résultats des marchés de prédiction forment un comparatif avec des prédictions par des utilisateurs humains. Résultat : les modèles les plus avancés (GPT-5, o3 Gemini 2.5 pro et Grok 4) dépassent les êtres humains sur le score de calibration, mais aucun n’arrive à traduire ça en de meilleurs retours financiers.

Anthropic se prépare à lancer Claude for Chrome, un plugin pour Google Chrome permettant à Claude d’interagir avec votre navigateur, à vos risques et périls.

En parallèle, les discussions sur claude.ai seront maintenant par défaut utilisées pour l’entraînement des versions suivantes de Claude, sauf si l’utilisateur désactive un paramètre sur son compte. Anthropic gardera les conversations pendant 5 ans.

Une nouvelle évaluation intéressante : TextQuests, qui évalue les modèles sur des jeux d’aventure textuels tels que Zork I. Cela a l’avantage de réellement tester les capacités de planification/raisonnement des modèles hors du domaine d’entraînement typique (mathématiques/programmation), tout en restant dans le domaine textuel (au contraire des évaluations multimodales, qui ont l’inconvénient de trop lier les résultats aux capacités perceptuelles des modèles).

Nouvelle technique d’interprétation des modèles, Model Diff Amplification. Elle consiste à amplifier les différences entre le pré-entraînement et le post-entraînement au moment de la génération, afin d’éliciter des comportements rares causés par le post-entraînement, ou tout simplement utiliser cette technique très tôt dans le post-entraînement pour se donner une idée des conséquences (prévues ou non) du post-entraînement complet.

Dr. Chistoph Heilig, chercheur en littérature et études bibliques, s’intéressant beaucoup aux capacités littéraires de l’IA, se met en tête d’évaluer GPT-5. Il se retrouve extrêmement surpris par la médiocrité de la prose produite par le modèle. De manière plus surprenante, un modèle complètement différent (Opus 4.1) juge le résultat comme étant de bonne qualité. La théorie qu’il propose est que ChatGPT 5 a été entraîné à l’aide d’un juge IA, et a appris à exploiter des constructions « peu humaines » que les modèles jugent systématiquement comme étant signes de qualité.

En parallèle de la sortie de GPT-5, OpenAI publie un guide sur comment créer un prompt, et un outil d’optimisation des prompts.

Anthropic et OpenAI font une tentative de coopération, où l’équipe d’évaluation de la sécurité des modèles d’OpenAI évalue les modèles d’Anthropic avec leurs outils, et vice-versa. Aucune trouvaille surprenante (si ce n’est l’incapacité des deux équipes de détecter la flagornerie flagrante de 4o), mais le concept est intéressante.

xAI publie la version précédente de son IA, Grok 2, en open-weight.

Une étude d’Anthropic développe un moyen pour identifier un sous-ensemble d’un modèle associé à un « trait de personnalité » particulier. Cela permet d’amplifier ou de supprimer ce trait, ou encore de détecter son activation.

« L’IA a-t-elle la qualité de patient moral » (en d’autres termes : devons-nous tenir compte de son bien-être pour des raisons morales) ? Anthropic commence à prendre la question au sérieux, avec comme première décision de permettre à son IA, Claude, d’unilatéralement mettre fin à une conversation qu’il jugerait abusive.

GPT-5 finit Pokémon Rouge en trois fois moins de temps que o3. La réduction du taux d’hallucinations serait la principale source de ce gain de performances. Gemini a également terminé sa partie de Pokémon Jaune. Claude, par contre, peine toujours à aller plus loin que Celadon…

La Chine continue à appeler à la coopération internationale pour la régulation du développement de l’IA, que ce soit par la voix du premier ministre ou d’universitaires.

Lors du sommet sur l’intelligence artificielle de Seoul de 2024, la plupart des acteurs, incluant Google, s’étaient volontairement engagés à suivre certaines actions relatives à la sécurité des modèles. Essentiellement, ce que le plupart faisaient déjà : publier une politique de sécurité des modèles, et s’engager à la suivre. Google se trouve aujourd’hui critiqué pour ne pas avoir suivi ses propres engagements. En cause, la publication de Gemini 2.5 Pro sans sa System Card associée, qui est arrivée plusieurs semaines après la publication du modèle. Google se défend en affirmant que la publication était clairement mentionnée comme « expérimentale ».

Entraîner l’IA à être chaleureuse et empathique réduit ses performances.

Sur le sujet de la flagornerie de l’IA, un internaute s’attelle à une évaluation des différents modèles.

Le gouvernement Danois veut faire rentrer l’apparence physique et la voix dans le cadre du copyright afin de lutter contre les deepfakes.

Pour aller plus loin

Voici d'autres ressources, qui n'ont pas été abordées dans cet article.

Par Zvi Mowshowitz :

Dans les dépêches de LinuxFr.org :

Dans les journaux de LinuxFr.org :

Dans les liens de LinuxFr.org :

Commentaires : voir le flux Atom ouvrir dans le navigateur

Reçu avant avant-hier

Incident du 26 août 2025 ayant touché les serveurs de production et de développement

✇LinuxFr.org : les dépêches
Par :Benoît Sibaud · BAud · Xavier Teyssier · Jona
27 août 2025 à 12:59

Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.

Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.

Sommaire

Premier diagnostic

Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.

La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.

Le premier contact réétabli avec le serveur est assez clair (une forte charge) :

$ uptime
15:06:59 up 2 days,  2:54,  1 user,  load average: 50,00, 205,21, 260,83

(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)

Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.

Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.

Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.

La console est remplie d’élimination de processus de ce type :

Le plein d’OutOfMemory

Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?

Eh bien des requêtes habituelles…

Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.

Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.

Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.

Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.

4 processus gourmands

OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.

La boucle sans fin

Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :

(...)
close(623199355)                        = -1 EBADF (Bad file descriptor)
close(623199356)                        = -1 EBADF (Bad file descriptor)
close(623199357)                        = -1 EBADF (Bad file descriptor)
(...)

Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.

En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :

# close fd's inherited from the ruby parent
        import resource
        maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
        if maxfd == resource.RLIM_INFINITY:
            maxfd = 65536

        for fd in range(3, maxfd):
            try:
                os.close(fd)
            except:
                pass

Donc on itère sur tous les descripteurs entre 3 et le maximum déterminé…

>>> import resource
>>> print(resource.getrlimit(resource.RLIMIT_NOFILE)[1])
524288
>>> print(resource.RLIM_INFINITY)
-1

Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.

On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.

Une dernière page d’epub ?

Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).

Voir ce commentaire sur la dépêche de l’incident précédent expliquant la séparation du service epub et du conteneur principal de production (en bref : dette technique et migration en cours).

Retour en graphiques sur la journée

Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.

Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52   ô_Ô)

Charge CPU

Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.

Utilisation mémoire

Mesures préventives et correctives

Dans les actions en cours ou à prévoir :

  • mettre à jour la documentation pour disposer facilement et rapidement des informations pour les connexions aux cartes d’administration ou les procédures de blocages d’IP
  • procéder à la montée de version des composants (yapuka, épineux sujet de la dette technique à éponger)
  • vérifier l’efficacité des limitations CPU/mémoire mises sur certains conteneurs LXC et les étendre aux autres
  • mettre des limites sur des processus particuliers (comme ceux de pygments)
  • ajouter le déploiement des limites par utilisateur dans le code Ansible
  • corriger la collecte rrd des métriques concernant les interfaces réseau
  • remonter les alertes OOM qui ne sont pas normales
  • comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)

Bonus inattendu pour l’incident précédent du 26 juin 2025

De façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌