La Cour décompte

La Cour des comptes vient de publier un rapport sur l’usage des outils bureautiques et collaboratifs au sein de l’État. Les constats y sont nombreux et pour la plupart négatifs. La Cour préconise donc un plan homogène de modernisation avec un passage plus poussé au libre. Des recommandations accueillies « favorablement » par le Premier ministre.

La Cour des comptes a publié le 20 octobre trois documents liés : un rapport complet sur les outils bureautiques et collaboratifs au sein de l’État, sa synthèse et la réponse du Premier ministre. Ce rapport fait suite à une enquête, qui répondait elle-même à une saisine citoyenne.

Le rapport couvre les administrations centrales et les services déconcentrés des ministères. Même si les opérateurs, la Sécurité sociale, les hôpitaux et les collectivités en sont exclus, le parc ainsi analysé compte tout de même 860 000 postes. Quatre ministères concentrent près de 90 % de ce nombre imposant : Intérieur (34 %), Armées (23 %), Économie et finances (18 %), Justice (11 %).

La Cour des comptes s’est donné la mission de répondre essentiellement à deux questions : Comment les outils bureautiques et collaboratifs sont utilisés ? Peut-on faire mieux ?

Un parc très hétérogène

Cela ne surprendra personne, mais le premier constat est que les différents parcs informatiques sont très hétérogènes. La doctrine qui a toujours prévalu jusqu’à récemment est que les ministères sont libres de leurs choix. D’un côté, cela permet une adaptation simple aux spécificités et donc aux besoins de chacun. De l’autre côté, chacun fait à sa manière, avec les fortes disparités qui en découlent.

Malgré cette grande hétérogénéité, la suite Office de Microsoft est utilisée presque partout. Deux grandes exceptions sont signalées : la direction générale de la gendarmerie nationale (DGGN) et la direction générale des finances publiques (DGFiP), qui recourent massivement aux solutions libres. Dans le cas de la gendarmerie, même le système d’exploitation a été remplacé il y a longtemps (Gendbuntu), mais elle garde environ 2 500 postes avec Office. La Cour note également que quelle que soit la configuration choisie, le taux général de satisfaction est à peu près le même partout.

Cependant, le cadre a changé. « Face aux enjeux renouvelés de coordination et de souveraineté numérique, l’État a cherché à rationaliser les pratiques en place par des directives plus contraignantes, parmi lesquelles l’interdiction en 2021 du recours à la solution Microsoft 365, l’encadrement à partir de 2023 des outils de visioconférence et des messageries instantanées ou, en 2025 et 2026, le contrôle des achats numériques », indique ainsi la Cour des comptes.

La DINUM épinglée pour suivi peu rigoureux

Signe des temps, le rapport note l’utilisation croissante dans les ministères des outils rassemblés dans La Suite, développée par la DINUM. Si la Cour des comptes loue la création d’outils sur la base de logiciels libres respectant les exigences de souveraineté et d’interopérabilité, elle égratigne le recours aux startups d’État, modèle justement retenu par la DINUM, car il est souple et permet un financement rapide. En revanche, « il n’est pas adapté à l’édition logicielle professionnelle, qui suppose une vision du produit sur plusieurs années, une feuille de route technique robuste et un haut niveau de support, documentation et maintenance ».

• Simplification, sécurisation, souveraineté : la DINUM affirme son rôle de chef d’orchestre

La Cour se montre globalement critique face à la DINUM. La Direction n’a ainsi « pas fourni à la Cour de tableau de bord permettant un suivi précis des prestations réalisées, par module ou par intervenant ». Le seul suivi communiqué est comptable et qualifié de « parfois approximatif ». « Ce n’est pas du niveau attendu pour des solutions numériques ayant vocation à être opérées dans l’ensemble des administrations de l’État », fustige la Cour, qui épinglait déjà ce manque de rigueur en 2024. Selon le rapport, la DINUM a convenu de la nécessité de renforcer son suivi.

La DINUM en prend pour son grade sur un autre sujet. Elle est accusée de développer elle-même des logiciels, plutôt que de faire vivre l’écosystème d’entreprises françaises du libre. Interrogé dans le cadre de l’enquête, le CNLL (qui représente une partie des éditeurs de logiciels libres en France) a cité l’entreprise publique allemande ZenDiS comme référence, car elle assemble des briques libres en sous-traitant à sept entreprises pour produire openDesk. Là encore, le constat était sensiblement le même en 2024.

Malgré les critiques, le rapport estime que les résultats de La Suite sont « probants ». Tchap compte ainsi 368 000 utilisateurs actifs fin 2025 et ProConnect 930 000 connexions mensuelles. Cependant, La Suite a des limites connues et ne peut pas remplacer une suite bureautique, notamment car elle n’a ni tableur, ni outil de présentation, ni agenda. En outre, elle ne fonctionne qu’en ligne, la Messagerie n’est pas déployable à grande échelle à court terme et Docs assure surtout de la prise de notes collaborative.

Un coût en forte progression mais qui reste limité

La Cour relève une facture générale d’environ 100 millions d’euros pour l’année 2025 sur l’ensemble du parc analysé. Ce chiffre est en forte augmentation, avec + 50 % depuis 2021, contre + 16 % pour les dépenses de fonctionnement de l’État. Cependant, le même chiffre reste contenu, car il représente moins de 2 % du budget numérique total, estimé à 5,5 milliards d’euros.

Le coût moyen est de 87 euros par poste et par an, mais avec des écarts extrêmes : 20 euros à l’Intérieur et 378 euros à la Culture. Ce montant tient à de multiples facteurs, dont l’un des plus importants est l’utilisation de Microsoft 365. Contrairement à la suite Office, Microsoft 365 est un abonnement donnant accès à plus ou moins d’outils et d’espace de stockage selon le niveau choisi. Or, même si Microsoft 365 est interdit, certains ministères disposent d’une dérogation, dont la Culture.

Cette facture de 100 millions fait pourtant grincer la Cour, car il n’est pas issu d’un chiffrage précis : « Ce montant a été reconstitué par la Cour, qui a constaté que dans plusieurs ministères le suivi était lacunaire aussi bien pour ces dépenses – du fait d’une comptabilité analytique défaillante – que pour le parc informatique lui-même ».

Toujours sur cette année 2025, 61 millions d’euros étaient consacrés aux licences logicielles bureautiques et collaboratives, dont les quatre cinquièmes pour Microsoft, « sans compter les autres logiciels tels que le système d’exploitation Windows ». Le rapport liste également 26 millions d’euros pour les prestations et 13 millions alloués à la masse salariale des postes de maintenance et de support sur ces outils.

Quant à La Suite, son coût total depuis 2021 est d’environ 40 millions d’euros, en augmentation moyenne de 40 % par an. Cependant, et encore une fois, les « investigations menées à l’occasion de cette enquête montrent également que le suivi administratif et financier par la DINUM des prestations réalisées par les freelances aurait dû être plus rigoureux pour s’assurer de la juste adéquation entre les ressources allouées et les travaux réalisés ».

Il faut accentuer le passage au libre

Bien que la Direction interministérielle soit copieusement critiquée, ses développements ont quand même de quoi satisfaire et « suivent une trajectoire solide », note la Cour des comptes.

Le rapport insiste sur la nécessité de développer l’usage des logiciels libres, car ils sont « un gage d’indépendance des administrations publiques » et « économiquement plus vertueux ». En se basant sur les données recueillies, la Cour chiffre entre 30 et 65 millions d’euros les économies qui seraient réalisées dans l’ensemble des ministères par l’utilisation « plus systématique de logiciels libres bureautiques on-premises », c’est-à-dire sur site.

La Cour indique que les ministères souhaitent en majorité continuer à utiliser Office. Ils envisagent même de migrer sur les infrastructures de Bleu « lorsque les logiciels de Microsoft pourront y être exploités sous la qualification souveraine SecNumCloud ». Cependant, pour les mêmes motifs que précédemment, « il conviendrait plutôt de travailler à ce qu’une solution bureautique libre en mode cloud (interne à l’État ou qualifié SecNumCloud) puisse être proposée en alternative et devienne, à terme, la norme au sein des administrations de l’État ».

• SecNumCloud : Bleu vise désormais une qualification pour la fin d’année

Quatre recommandations, accueillies favorablement

Le rapport de la Cour des comptes se termine par quatre recommandations, qui devraient toutes êtes engagées dès 2027 :

1. Associer plus fortement les ministères à la conception de la feuille de route de La Suite ainsi qu’à sa gouvernance ;
2. Intégrer les outils collaboratifs et bureautiques dans le périmètre de gouvernance de la DINUM ;
3. Faire évoluer le modèle de développement de la Suite pour mieux s’appuyer sur des entreprises disposant d’une expertise en matière de logiciels libres ;
4. Engager la convergence vers « des outils en mode cloud » et prévoir un plan de migration, « sur trois à quatre années au maximum », pour orienter les stratégies numériques des ministères et de leurs opérateurs.

Ces quatre recommandations ont été accueillies favorablement par le Premier ministre, Sébastien Lecornu. Dans sa réponse, celui-ci indique d’ailleurs que la création d’ARIANE (Autorité référente pour l’intelligence artificielle et le numérique de l’État) au 1ᵉʳ janvier 2027 permettra d’accélérer les travaux, puisqu’elle aura « notamment vocation à renforcer la cohérence des choix technologiques de l’État ».

• Dix ans après la loi République numérique, « encourager » le logiciel libre n’a pas suffi

La Cour décompte

La Cour des comptes vient de publier un rapport sur l’usage des outils bureautiques et collaboratifs au sein de l’État. Les constats y sont nombreux et pour la plupart négatifs. La Cour préconise donc un plan homogène de modernisation avec un passage plus poussé au libre. Des recommandations accueillies « favorablement » par le Premier ministre.

La Cour des comptes a publié le 20 octobre trois documents liés : un rapport complet sur les outils bureautiques et collaboratifs au sein de l’État, sa synthèse et la réponse du Premier ministre. Ce rapport fait suite à une enquête, qui répondait elle-même à une saisine citoyenne.

Le rapport couvre les administrations centrales et les services déconcentrés des ministères. Même si les opérateurs, la Sécurité sociale, les hôpitaux et les collectivités en sont exclus, le parc ainsi analysé compte tout de même 860 000 postes. Quatre ministères concentrent près de 90 % de ce nombre imposant : Intérieur (34 %), Armées (23 %), Économie et finances (18 %), Justice (11 %).

La Cour des comptes s’est donné la mission de répondre essentiellement à deux questions : Comment les outils bureautiques et collaboratifs sont utilisés ? Peut-on faire mieux ?

Un parc très hétérogène

Cela ne surprendra personne, mais le premier constat est que les différents parcs informatiques sont très hétérogènes. La doctrine qui a toujours prévalu jusqu’à récemment est que les ministères sont libres de leurs choix. D’un côté, cela permet une adaptation simple aux spécificités et donc aux besoins de chacun. De l’autre côté, chacun fait à sa manière, avec les fortes disparités qui en découlent.

Malgré cette grande hétérogénéité, la suite Office de Microsoft est utilisée presque partout. Deux grandes exceptions sont signalées : la direction générale de la gendarmerie nationale (DGGN) et la direction générale des finances publiques (DGFiP), qui recourent massivement aux solutions libres. Dans le cas de la gendarmerie, même le système d’exploitation a été remplacé il y a longtemps (Gendbuntu), mais elle garde environ 2 500 postes avec Office. La Cour note également que quelle que soit la configuration choisie, le taux général de satisfaction est à peu près le même partout.

Cependant, le cadre a changé. « Face aux enjeux renouvelés de coordination et de souveraineté numérique, l’État a cherché à rationaliser les pratiques en place par des directives plus contraignantes, parmi lesquelles l’interdiction en 2021 du recours à la solution Microsoft 365, l’encadrement à partir de 2023 des outils de visioconférence et des messageries instantanées ou, en 2025 et 2026, le contrôle des achats numériques », indique ainsi la Cour des comptes.

La DINUM épinglée pour suivi peu rigoureux

Signe des temps, le rapport note l’utilisation croissante dans les ministères des outils rassemblés dans La Suite, développée par la DINUM. Si la Cour des comptes loue la création d’outils sur la base de logiciels libres respectant les exigences de souveraineté et d’interopérabilité, elle égratigne le recours aux startups d’État, modèle justement retenu par la DINUM, car il est souple et permet un financement rapide. En revanche, « il n’est pas adapté à l’édition logicielle professionnelle, qui suppose une vision du produit sur plusieurs années, une feuille de route technique robuste et un haut niveau de support, documentation et maintenance ».

• Simplification, sécurisation, souveraineté : la DINUM affirme son rôle de chef d’orchestre

La Cour se montre globalement critique face à la DINUM. La Direction n’a ainsi « pas fourni à la Cour de tableau de bord permettant un suivi précis des prestations réalisées, par module ou par intervenant ». Le seul suivi communiqué est comptable et qualifié de « parfois approximatif ». « Ce n’est pas du niveau attendu pour des solutions numériques ayant vocation à être opérées dans l’ensemble des administrations de l’État », fustige la Cour, qui épinglait déjà ce manque de rigueur en 2024. Selon le rapport, la DINUM a convenu de la nécessité de renforcer son suivi.

La DINUM en prend pour son grade sur un autre sujet. Elle est accusée de développer elle-même des logiciels, plutôt que de faire vivre l’écosystème d’entreprises françaises du libre. Interrogé dans le cadre de l’enquête, le CNLL (qui représente une partie des éditeurs de logiciels libres en France) a cité l’entreprise publique allemande ZenDiS comme référence, car elle assemble des briques libres en sous-traitant à sept entreprises pour produire openDesk. Là encore, le constat était sensiblement le même en 2024.

Malgré les critiques, le rapport estime que les résultats de La Suite sont « probants ». Tchap compte ainsi 368 000 utilisateurs actifs fin 2025 et ProConnect 930 000 connexions mensuelles. Cependant, La Suite a des limites connues et ne peut pas remplacer une suite bureautique, notamment car elle n’a ni tableur, ni outil de présentation, ni agenda. En outre, elle ne fonctionne qu’en ligne, la Messagerie n’est pas déployable à grande échelle à court terme et Docs assure surtout de la prise de notes collaborative.

Un coût en forte progression mais qui reste limité

La Cour relève une facture générale d’environ 100 millions d’euros pour l’année 2025 sur l’ensemble du parc analysé. Ce chiffre est en forte augmentation, avec + 50 % depuis 2021, contre + 16 % pour les dépenses de fonctionnement de l’État. Cependant, le même chiffre reste contenu, car il représente moins de 2 % du budget numérique total, estimé à 5,5 milliards d’euros.

Le coût moyen est de 87 euros par poste et par an, mais avec des écarts extrêmes : 20 euros à l’Intérieur et 378 euros à la Culture. Ce montant tient à de multiples facteurs, dont l’un des plus importants est l’utilisation de Microsoft 365. Contrairement à la suite Office, Microsoft 365 est un abonnement donnant accès à plus ou moins d’outils et d’espace de stockage selon le niveau choisi. Or, même si Microsoft 365 est interdit, certains ministères disposent d’une dérogation, dont la Culture.

Cette facture de 100 millions fait pourtant grincer la Cour, car il n’est pas issu d’un chiffrage précis : « Ce montant a été reconstitué par la Cour, qui a constaté que dans plusieurs ministères le suivi était lacunaire aussi bien pour ces dépenses – du fait d’une comptabilité analytique défaillante – que pour le parc informatique lui-même ».

Toujours sur cette année 2025, 61 millions d’euros étaient consacrés aux licences logicielles bureautiques et collaboratives, dont les quatre cinquièmes pour Microsoft, « sans compter les autres logiciels tels que le système d’exploitation Windows ». Le rapport liste également 26 millions d’euros pour les prestations et 13 millions alloués à la masse salariale des postes de maintenance et de support sur ces outils.

Quant à La Suite, son coût total depuis 2021 est d’environ 40 millions d’euros, en augmentation moyenne de 40 % par an. Cependant, et encore une fois, les « investigations menées à l’occasion de cette enquête montrent également que le suivi administratif et financier par la DINUM des prestations réalisées par les freelances aurait dû être plus rigoureux pour s’assurer de la juste adéquation entre les ressources allouées et les travaux réalisés ».

Il faut accentuer le passage au libre

Bien que la Direction interministérielle soit copieusement critiquée, ses développements ont quand même de quoi satisfaire et « suivent une trajectoire solide », note la Cour des comptes.

Le rapport insiste sur la nécessité de développer l’usage des logiciels libres, car ils sont « un gage d’indépendance des administrations publiques » et « économiquement plus vertueux ». En se basant sur les données recueillies, la Cour chiffre entre 30 et 65 millions d’euros les économies qui seraient réalisées dans l’ensemble des ministères par l’utilisation « plus systématique de logiciels libres bureautiques on-premises », c’est-à-dire sur site.

La Cour indique que les ministères souhaitent en majorité continuer à utiliser Office. Ils envisagent même de migrer sur les infrastructures de Bleu « lorsque les logiciels de Microsoft pourront y être exploités sous la qualification souveraine SecNumCloud ». Cependant, pour les mêmes motifs que précédemment, « il conviendrait plutôt de travailler à ce qu’une solution bureautique libre en mode cloud (interne à l’État ou qualifié SecNumCloud) puisse être proposée en alternative et devienne, à terme, la norme au sein des administrations de l’État ».

• SecNumCloud : Bleu vise désormais une qualification pour la fin d’année

Quatre recommandations, accueillies favorablement

Le rapport de la Cour des comptes se termine par quatre recommandations, qui devraient toutes êtes engagées dès 2027 :

1. Associer plus fortement les ministères à la conception de la feuille de route de La Suite ainsi qu’à sa gouvernance ;
2. Intégrer les outils collaboratifs et bureautiques dans le périmètre de gouvernance de la DINUM ;
3. Faire évoluer le modèle de développement de la Suite pour mieux s’appuyer sur des entreprises disposant d’une expertise en matière de logiciels libres ;
4. Engager la convergence vers « des outils en mode cloud » et prévoir un plan de migration, « sur trois à quatre années au maximum », pour orienter les stratégies numériques des ministères et de leurs opérateurs.

Ces quatre recommandations ont été accueillies favorablement par le Premier ministre, Sébastien Lecornu. Dans sa réponse, celui-ci indique d’ailleurs que la création d’ARIANE (Autorité référente pour l’intelligence artificielle et le numérique de l’État) au 1ᵉʳ janvier 2027 permettra d’accélérer les travaux, puisqu’elle aura « notamment vocation à renforcer la cohérence des choix technologiques de l’État ».

• Dix ans après la loi République numérique, « encourager » le logiciel libre n’a pas suffi

Réécrivons tout en Rust

OpenAI a de nouvelles envies de conquête, cette fois dans le champ de ce qu’elle nomme « les langages à faibles ressources ». L’entreprise vise explicitement cette fois les vieux, voire très vieux langages, au premier rang desquels le COBOL. La promesse est de faire exploser le nombre de projets de migration grâce à ses soins.

Selon OpenAI, les dernières avancées de ses modèles ont renforcé leurs capacités à créer et à migrer des logiciels dans des langages comme COBOL, Fortran et Visual Basic. Des langages dits « à faibles ressources », car ils ont moins de code et de documentation pour entrainer les modèles que d’autres bien plus courants comme Python et JavaScript.

« COBOL fait fonctionner⁠ plus de 40 % des systèmes bancaires en ligne, 80 % des transactions par carte de crédit en personne et 95 % des transactions aux distributeurs automatiques », indique OpenAI, montrant l’ampleur du marché. Des chiffres familiers ? Nous avions les mêmes dans notre article de juillet 2025 consacré au COBOL et à sa présence toujours importante. Ils sont issus d’une enquête réalisée par Reuters en 2024. Dans notre article, nous montrions d’ailleurs que le langage restait vivant, mais qu’il y avait un déficit de développeurs formés à ce langage. Fortran, utilisé pour les prévisions météorologiques⁠ et l’analyse de sûreté des réacteurs nucléaires⁠, fait aussi partie des langages visés.

OpenAI dit avoir reçu de nombreux retours sur la difficulté à travailler avec l’IA sur ces langages. « La documentation peut être incomplète, les développeurs d’origine peuvent avoir quitté l’entreprise, et des règles métier importantes peuvent n’exister que dans le code », indique OpenAI. Autant de problématiques que nous avions abordées dans notre article.

OpenAI s’est fabriqué deux évaluations

L’entreprise souhaitait savoir si ses modèles avaient progressé. La question est presque rhétorique : le billet d’OpenAI est là pour montrer à quel point ses LLM ont justement progressé.

Pour les mesurer, OpenAI dit avoir créé deux évaluations. La première, MultiLang, vérifie si un modèle peut créer un moteur de base de données compatible avec SQLite dans 20 langages, en partant d’une page blanche. La seconde est une évaluation plus spécifique aux migrations COBOL pour vérifier si le modèle peut migrer des programmes existants en préservant leur comportement. En somme, l’une vérifie la création de nouveaux logiciels, tandis que l’autre s’assure que les migrations réussissent.

Sans surprise, OpenAI indique que les progrès de ses modèles sont « considérables ». Astra a ainsi atteint un score de 87,4 % sur le premier test en moyenne, contre 26,8 % pour GPT-5.6 Sol, avec des progrès sur l’ensemble des 20 langages. « GPT‑6 Luna surpasse également GPT‑5.6 Sol, atteignant 40,3 % pour un coût estimé de l’API inférieur d’environ 78 % », ajoute OpenAI.

Les règles particulières du COBOL

L’évaluation spécifique au COBOL est plus intéressante, car le problème initial est plus complexe. OpenAI rappelle ainsi que la réussite d’une migration dépend d’une pleine compréhension de la logique métier et des comportements propres au langage. « Par exemple, l’arithmétique à virgule fixe de COBOL supprime les décimales excédentaires, sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit ces valeurs à la place peut s’exécuter sans erreur tout en produisant des résultats financiers différents », affirme l’entreprise.

La vérification se base sur des « tests cachés » qui exigent des sorties observables identiques, à l’octet près. La migration n’est considérée réussie que si tous les tests sont validés. Dans le cas présent, les projets en COBOL devaient être convertis en C++, Java, Kotlin, Python ou Rust.

Dans cette évaluation, GPT‑6.1 Sol a atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre à peine 5,4 % pour GPT‑5.6 Sol, le tout avec un coût inférieur de 39 %. OpenAI ajoute qu’avec un effort de raisonnement plus élevé (on ne connait pas l’effort de départ), le score grimpe à 97,9 %.

Le message est donc clair : on peut utiliser Astra et GPT-6.1 Sol pour migrer les projets ou en bâtir de nouveaux compatibles. Une conclusion qu’OpenAI met d’autant plus en avant que l’IA fait exploser depuis plusieurs mois les projets de réécriture, de nombreux développeurs (confirmés ou en herbe) se lançant notamment dans une course aux performances.

OpenAI ajoute toutefois que même si les résultats obtenus vont dans le bon sens, « leur application à des logiciels en production exige toujours une vérification par des experts et des tests tenant compte des règles métier et des dépendances du système ».

Des résultats à prendre avec des pincettes

Le principal problème de cette annonce est son opacité. C’est particulièrement vrai dans le cas de COBOL.

On ne sait pratiquement rien en effet de l’évaluation construite par OpenAI, alors que MultiLang a son dépôt GitHub. Rien sur le nombre de programmes, leur origine, leur taille ou même leur degré de ressemblance avec du COBOL réellement utilisé en production. L’évaluation étant opaque, elle ne peut pas être reproduite par des tiers indépendants et il faut donc croire OpenAI sur parole. Que les modèles progressent sur des langages comme COBOL ou Fortran ne fait pas de doute, mais il est difficile de se rendre compte de l’évolution concrète sur la seule base des affirmations d’OpenAI, les évaluations étant proposées par la même entreprise qui propose les modèles testés.

Notons également que les deux évaluations envisagent des tests très différents dans leur approche. SQLite est un projet présent depuis longtemps et aux nombreuses réimplémentations, des portages existant dans plusieurs des langages testés. Il n’est donc pas étonnant qu’un modèle récent s’en sorte bien, puisqu’il restitue en partie des connaissances présentes dans les données d’entraînement. À l’inverse, la situation est plus complexe pour COBOL, Fortran et d’autres anciens langages, les ressources étant nettement moins nombreuses.

Réécrivons tout en Rust

OpenAI a de nouvelles envies de conquête, cette fois dans le champ de ce qu’elle nomme « les langages à faibles ressources ». L’entreprise vise explicitement cette fois les vieux, voire très vieux langages, au premier rang desquels le COBOL. La promesse est de faire exploser le nombre de projets de migration grâce à ses soins.

Selon OpenAI, les dernières avancées de ses modèles ont renforcé leurs capacités à créer et à migrer des logiciels dans des langages comme COBOL, Fortran et Visual Basic. Des langages dits « à faibles ressources », car ils ont moins de code et de documentation pour entrainer les modèles que d’autres bien plus courants comme Python et JavaScript.

« COBOL fait fonctionner⁠ plus de 40 % des systèmes bancaires en ligne, 80 % des transactions par carte de crédit en personne et 95 % des transactions aux distributeurs automatiques », indique OpenAI, montrant l’ampleur du marché. Des chiffres familiers ? Nous avions les mêmes dans notre article de juillet 2025 consacré au COBOL et à sa présence toujours importante. Ils sont issus d’une enquête réalisée par Reuters en 2024. Dans notre article, nous montrions d’ailleurs que le langage restait vivant, mais qu’il y avait un déficit de développeurs formés à ce langage. Fortran, utilisé pour les prévisions météorologiques⁠ et l’analyse de sûreté des réacteurs nucléaires⁠, fait aussi partie des langages visés.

OpenAI dit avoir reçu de nombreux retours sur la difficulté à travailler avec l’IA sur ces langages. « La documentation peut être incomplète, les développeurs d’origine peuvent avoir quitté l’entreprise, et des règles métier importantes peuvent n’exister que dans le code », indique OpenAI. Autant de problématiques que nous avions abordées dans notre article.

OpenAI s’est fabriqué deux évaluations

L’entreprise souhaitait savoir si ses modèles avaient progressé. La question est presque rhétorique : le billet d’OpenAI est là pour montrer à quel point ses LLM ont justement progressé.

Pour les mesurer, OpenAI dit avoir créé deux évaluations. La première, MultiLang, vérifie si un modèle peut créer un moteur de base de données compatible avec SQLite dans 20 langages, en partant d’une page blanche. La seconde est une évaluation plus spécifique aux migrations COBOL pour vérifier si le modèle peut migrer des programmes existants en préservant leur comportement. En somme, l’une vérifie la création de nouveaux logiciels, tandis que l’autre s’assure que les migrations réussissent.

Sans surprise, OpenAI indique que les progrès de ses modèles sont « considérables ». Astra a ainsi atteint un score de 87,4 % sur le premier test en moyenne, contre 26,8 % pour GPT-5.6 Sol, avec des progrès sur l’ensemble des 20 langages. « GPT‑6 Luna surpasse également GPT‑5.6 Sol, atteignant 40,3 % pour un coût estimé de l’API inférieur d’environ 78 % », ajoute OpenAI.

Les règles particulières du COBOL

L’évaluation spécifique au COBOL est plus intéressante, car le problème initial est plus complexe. OpenAI rappelle ainsi que la réussite d’une migration dépend d’une pleine compréhension de la logique métier et des comportements propres au langage. « Par exemple, l’arithmétique à virgule fixe de COBOL supprime les décimales excédentaires, sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit ces valeurs à la place peut s’exécuter sans erreur tout en produisant des résultats financiers différents », affirme l’entreprise.

La vérification se base sur des « tests cachés » qui exigent des sorties observables identiques, à l’octet près. La migration n’est considérée réussie que si tous les tests sont validés. Dans le cas présent, les projets en COBOL devaient être convertis en C++, Java, Kotlin, Python ou Rust.

Dans cette évaluation, GPT‑6.1 Sol a atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre à peine 5,4 % pour GPT‑5.6 Sol, le tout avec un coût inférieur de 39 %. OpenAI ajoute qu’avec un effort de raisonnement plus élevé (on ne connait pas l’effort de départ), le score grimpe à 97,9 %.

Le message est donc clair : on peut utiliser Astra et GPT-6.1 Sol pour migrer les projets ou en bâtir de nouveaux compatibles. Une conclusion qu’OpenAI met d’autant plus en avant que l’IA fait exploser depuis plusieurs mois les projets de réécriture, de nombreux développeurs (confirmés ou en herbe) se lançant notamment dans une course aux performances.

OpenAI ajoute toutefois que même si les résultats obtenus vont dans le bon sens, « leur application à des logiciels en production exige toujours une vérification par des experts et des tests tenant compte des règles métier et des dépendances du système ».

Des résultats à prendre avec des pincettes

Le principal problème de cette annonce est son opacité. C’est particulièrement vrai dans le cas de COBOL.

On ne sait pratiquement rien en effet de l’évaluation construite par OpenAI, alors que MultiLang a son dépôt GitHub. Rien sur le nombre de programmes, leur origine, leur taille ou même leur degré de ressemblance avec du COBOL réellement utilisé en production. L’évaluation étant opaque, elle ne peut pas être reproduite par des tiers indépendants et il faut donc croire OpenAI sur parole. Que les modèles progressent sur des langages comme COBOL ou Fortran ne fait pas de doute, mais il est difficile de se rendre compte de l’évolution concrète sur la seule base des affirmations d’OpenAI, les évaluations étant proposées par la même entreprise qui propose les modèles testés.

Notons également que les deux évaluations envisagent des tests très différents dans leur approche. SQLite est un projet présent depuis longtemps et aux nombreuses réimplémentations, des portages existant dans plusieurs des langages testés. Il n’est donc pas étonnant qu’un modèle récent s’en sorte bien, puisqu’il restitue en partie des connaissances présentes dans les données d’entraînement. À l’inverse, la situation est plus complexe pour COBOL, Fortran et d’autres anciens langages, les ressources étant nettement moins nombreuses.

Toujours des noms simples à prononcer

Mistral a lancé récemment deux modèles spécialisés, Voxtral 3 pour transcription et la synthèse vocale et Timestral pour les « séries temporelles ». Ce dernier doit permettre des prévisions sans réentrainement.

Mistral avait lancé son premier modèle Voxtral en juillet 2025. Il s’agissait alors de son premier modèle audio, que Mistral mettait en avant comme plus performant et moins cher que les solutions concurrentes. Plusieurs tailles étaient proposées, selon la durée des contenus audio que l’on souhaitait traiter.

Ce LLM spécialisé a beaucoup évolué, puisque la version 3 est maintenant disponible. La communication de Mistral braque largement les projecteurs sur les agents. Selon l’entreprise française, un agent vocal fiable doit ainsi maitriser quatre capacités : écouter avec précision, raisonner en profondeur sur ce que les utilisateurs veulent dans un contexte donné, parler naturellement et agir en plusieurs étapes.

Un SDK d’agents locaux

Voxtral 3 est la réponse de Mistral à ces quatre objectifs, dont un fonctionnement fiable et en temps réel « reste un défi ». Voxtral 3, comme le premier, désigne une famille de modèles spécialisés dans la reconnaissance et la synthèse vocales. Cette fois, elle est accompagnée d’un SDK (kit de développement logiciel) pour utiliser des agents locaux. Le SDK (bâti sur LiveKit) réunit dans un même pipeline de traitement l’écoute, la réflexion, l’appel d’outils et la parole.

La famille compte quatre modèles :

• Small Transcribe 3 : transcription groupée de meilleure précision, 50 langues, à 0,004 dollar la minute
• Mini Transcribe 3 : 4 milliards de paramètres, 0,0035 dollar la minute
• Mini Transcribe Realtime 3 : transcription en direct, latence revendiquée à moins de 500 ms, 0,008 dollar la minute
• Voxtral Speech 3 (ou Mini TTS 3.0) : synthèse vocale, plus de 35 langues et 50 dialectes, 13 dollars le million de caractères

Mistral vante l’émotion dans la voix pour « sonner naturellement » (prosodie, rythme, débit, accentuation et transitions), les performances en diarisation (reconnaître qui parle) et la prise en charge des biais contextuels. Pour ce dernier point, Mistral précise que l’on peut ainsi fournir des termes clés et du texte libre pour « orienter la transcription et améliorer le rappel des termes techniques ». L’entreprise ajoute le support de la prédiction de fin de tour, les modèles étant capables de prédire quand une personne a fini de parler, en se basant sur des informations acoustiques et sémantiques.

Selon l’annonce, les performances de ces modèles sont à « l’état de l’art », dépassant de nombreuses références du secteur, dont Whisper d’OpenAI. L’agent complet, lui, est facturé 0,04 dollar la minute avec Small et 0,08 dollar avec un autre modèle de raisonnement. L’accès se fait via l’API de Mistral ou depuis l’infrastructure sur site.

Signalons que les quatre modèles sont en préversion publique et que certaines informations manquent. Par exemple, la taille de Small n’est pas donnée. En outre, aucun poids ouvert n’a encore été annoncé. En revanche, les performances revendiquées par Mistral semblent confirmées par Artificial Analysis.

Timestral : c’est quoi des « séries temporelles » ?

Le 15 octobre, Mistral avait également lancé un autre modèle, Timestral, premier représentant d’une nouvelle famille de LLM. Il est spécialisé dans les séries temporelles, c’est-à-dire des séries de mesures datées (capteurs, consommation, flux financiers…), afin d’établir des prévisions.

Timestral est fourni en quatre tailles : 5, 28, 123 et 209 millions de paramètres. Le modèle peut prévoir les séries sans réentraînement sur des données spécifiques, produire des prévisions avec une fourchette d’incertitude (21 quantiles) et accepter jusqu’à 32 768 pas d’historique. Selon Mistral, il peut traiter plusieurs séries liées à la fois ainsi que des facteurs connus à l’avance (calendrier de production, météo, etc.).

Timestral fonctionne également sans carte graphique. Mistral annonce à ce sujet un temps allant de 10 à 140 ms pour prévoir une journée, en fonction de la taille du modèle utilisé, sur un « CPU de serveur standard avec 8 threads » et sur la base de trois semaines d’historique au pas de 15 min. Comme toujours avec la taille des modèles, plus elle est importante, plus la précision augmente et plus le temps de calcul s’allonge.

Le code du modèle est sous licence Apache 2.0. Cependant, comme relevé par Pix Geeks, les poids sont sous une licence MIT modifiée « qui exclut les entreprises dont le chiffre d’affaires mensuel consolidé dépasse 20 millions de dollars. Celles-là doivent demander une licence commerciale à Mistral ou passer par ses services hébergés ». Sous ce seuil, l’utilisation de Timestral est gratuite.

Toujours des noms simples à prononcer

Mistral a lancé récemment deux modèles spécialisés, Voxtral 3 pour transcription et la synthèse vocale et Timestral pour les « séries temporelles ». Ce dernier doit permettre des prévisions sans réentrainement.

Mistral avait lancé son premier modèle Voxtral en juillet 2025. Il s’agissait alors de son premier modèle audio, que Mistral mettait en avant comme plus performant et moins cher que les solutions concurrentes. Plusieurs tailles étaient proposées, selon la durée des contenus audio que l’on souhaitait traiter.

Ce LLM spécialisé a beaucoup évolué, puisque la version 3 est maintenant disponible. La communication de Mistral braque largement les projecteurs sur les agents. Selon l’entreprise française, un agent vocal fiable doit ainsi maitriser quatre capacités : écouter avec précision, raisonner en profondeur sur ce que les utilisateurs veulent dans un contexte donné, parler naturellement et agir en plusieurs étapes.

Un SDK d’agents locaux

Voxtral 3 est la réponse de Mistral à ces quatre objectifs, dont un fonctionnement fiable et en temps réel « reste un défi ». Voxtral 3, comme le premier, désigne une famille de modèles spécialisés dans la reconnaissance et la synthèse vocales. Cette fois, elle est accompagnée d’un SDK (kit de développement logiciel) pour utiliser des agents locaux. Le SDK (bâti sur LiveKit) réunit dans un même pipeline de traitement l’écoute, la réflexion, l’appel d’outils et la parole.

La famille compte quatre modèles :

• Small Transcribe 3 : transcription groupée de meilleure précision, 50 langues, à 0,004 dollar la minute
• Mini Transcribe 3 : 4 milliards de paramètres, 0,0035 dollar la minute
• Mini Transcribe Realtime 3 : transcription en direct, latence revendiquée à moins de 500 ms, 0,008 dollar la minute
• Voxtral Speech 3 (ou Mini TTS 3.0) : synthèse vocale, plus de 35 langues et 50 dialectes, 13 dollars le million de caractères

Mistral vante l’émotion dans la voix pour « sonner naturellement » (prosodie, rythme, débit, accentuation et transitions), les performances en diarisation (reconnaître qui parle) et la prise en charge des biais contextuels. Pour ce dernier point, Mistral précise que l’on peut ainsi fournir des termes clés et du texte libre pour « orienter la transcription et améliorer le rappel des termes techniques ». L’entreprise ajoute le support de la prédiction de fin de tour, les modèles étant capables de prédire quand une personne a fini de parler, en se basant sur des informations acoustiques et sémantiques.

Selon l’annonce, les performances de ces modèles sont à « l’état de l’art », dépassant de nombreuses références du secteur, dont Whisper d’OpenAI. L’agent complet, lui, est facturé 0,04 dollar la minute avec Small et 0,08 dollar avec un autre modèle de raisonnement. L’accès se fait via l’API de Mistral ou depuis l’infrastructure sur site.

Signalons que les quatre modèles sont en préversion publique et que certaines informations manquent. Par exemple, la taille de Small n’est pas donnée. En outre, aucun poids ouvert n’a encore été annoncé. En revanche, les performances revendiquées par Mistral semblent confirmées par Artificial Analysis.

Timestral : c’est quoi des « séries temporelles » ?

Le 15 octobre, Mistral avait également lancé un autre modèle, Timestral, premier représentant d’une nouvelle famille de LLM. Il est spécialisé dans les séries temporelles, c’est-à-dire des séries de mesures datées (capteurs, consommation, flux financiers…), afin d’établir des prévisions.

Timestral est fourni en quatre tailles : 5, 28, 123 et 209 millions de paramètres. Le modèle peut prévoir les séries sans réentraînement sur des données spécifiques, produire des prévisions avec une fourchette d’incertitude (21 quantiles) et accepter jusqu’à 32 768 pas d’historique. Selon Mistral, il peut traiter plusieurs séries liées à la fois ainsi que des facteurs connus à l’avance (calendrier de production, météo, etc.).

Timestral fonctionne également sans carte graphique. Mistral annonce à ce sujet un temps allant de 10 à 140 ms pour prévoir une journée, en fonction de la taille du modèle utilisé, sur un « CPU de serveur standard avec 8 threads » et sur la base de trois semaines d’historique au pas de 15 min. Comme toujours avec la taille des modèles, plus elle est importante, plus la précision augmente et plus le temps de calcul s’allonge.

Le code du modèle est sous licence Apache 2.0. Cependant, comme relevé par Pix Geeks, les poids sont sous une licence MIT modifiée « qui exclut les entreprises dont le chiffre d’affaires mensuel consolidé dépasse 20 millions de dollars. Celles-là doivent demander une licence commerciale à Mistral ou passer par ses services hébergés ». Sous ce seuil, l’utilisation de Timestral est gratuite.

À vos marques ! Prêts ?

PHP doit proposer à 16h00 des correctifs pour deux failles de sécurité critiques. Le calendrier pourrait toutefois changer en fonction des éventuelles fuites. En début d’après-midi, de nombreux sites sont passés en maintenance préventive.

Mise à jour du 21 octobre, 16 h : Les correctifs ont été publiés avec une légère avance par l’équipe de PHP. Avec de nombreux sites mis en maintenance préventive et des exploits des failles circulant depuis plusieurs heures déjà, il était temps.

Comme suspecté, les deux failles sont de type RCE (exécution de code à distance) et ont en commun la manipulation par PHP de données dans un état non fiable. La première, CVE-2026-109618, réside dans la manière dont PHP nettoie les requêtes. S’il avait été interrompu par manque de mémoire, il peut traiter des données partiellement initialisées comme si elles étaient valides, ce qui corrompt la mémoire. La seconde, CVE-2026-109619, réside dans la persistance d’un état interne après une requête : la mémoire correspondante est alors libérée, mais l’état reste référencé. La requête suivante, traitée par le même processus, peut réutiliser cet état périmé.

Quatre nouvelles versions de PHP ont été publiées pour intégrer les correctifs : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toutes les installations servant des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé maximal pour mod_php.

L’équipe liste des mesures pour atténuer les risques dans certains cas, mais ajoute qu’aucune protection n’est réellement valable en dehors de l’installation des correctifs. En outre, au vu de la situation, elle a décidé de rétroporter les sources pour PHP 7.4, 8.0 et 8.1, des versions hors maintenance. Dans ces cas, il faudra compiler soi-même le code.

Nous avions de notre côté mis Next.ink en maintenance le temps que les correctifs soient disponibles. Le site est de retour avec une version de PHP à jour.

---

Mise à jour, 14 heures : la portée exacte des deux vulnérabilités concernées n’est pas encore connue, mais l’alerte prend des proportions inédites. Mercredi matin, le CERT-EU, le service de cybersécurité dédié aux institutions de l’Union européenne, a publié un bulletin qui recommande l’application du principe de précaution :

« Le CERT-EU recommande aux organisations de se préparer à la mise à jour immédiate des systèmes affectés. Si cette mise à jour immédiate n’est pas possible, les organisations devraient envisager d’isoler les applications exposées à Internet des réseaux publics jusqu’à la disponibilité d’un correctif. »

Plusieurs sites baissent le rideau préventivement

Le conseil semble avoir été suivi d’effets. Plusieurs sites d’organismes officiels européens ont ainsi choisi de baisser le rideau préventivement, en affichant un message de maintenance, et un retour programmé dans quelques heures, c’est-à-dire après installation de la mise à jour promise à 16 heures par la fondation PHP. C’est le cas par exemple de la CNIL française, du site du parlement hollandais ou d’un certain nombre de services publics finlandais, comme en témoigne ce relevé.

Plusieurs grands sites privés ont également interrompu leurs activités. D’après nos constatations, 4chan, DeviantArt et Dev-Null affichent par exemple un message de maintenance dont la cause est explicitement annoncée. « 4chan est temporairement en lecture seule en attendant une mise à jour de sécurité urgente de PHP », indique ainsi la célèbre plateforme.

Des attaques déjà recensées, Node.js lance aussi une alerte

D’après Dane Knecht, directeur technique de Cloudflare, des vecteurs d’attaque précoces auraient déjà été identifiés. L’entreprise assure avoir mis en place des règles préventives pour protéger ses clients exploitant PHP sur des sites exposés, mais elle recommande l’application sans délai du correctif dès publication. Des éléments d’information relatifs à l’exploitation des deux failles (non confirmés) circulent effectivement sur les réseaux sociaux.

S’agit-il d’un hasard du calendrier ou d’une conséquence collatérale des travaux de recherche liés à PHP ? L’équipe de Node.js, un environnement JavaScript couramment utilisé sur le Web, a elle aussi alerté mercredi sur la publication imminente d’un correctif de sécurité portant sur ses principales versions. L’après-midi s’annonce chargée pour les développeurs web et les sysadmin du monde entier.

---

Publication initiale, 8h42

L’équipe de PHP a publié le 20 octobre un important bulletin de sécurité au sujet de deux failles critiques. Les informations détaillées et les correctifs seront publiés aujourd’hui à 16h00, heure de la métropole. Dans son bulletin, PHP indique que les deux failles ont un score CVSS v4 de 9,2 sur 10. L’équipe recommande à toutes les personnes concernées et aux entreprises de se préparer pour appliquer les correctifs aussi rapidement que possible.

Ce calendrier pourrait toutefois évoluer au cours de la journée. « Nous nous réservons le droit de divulguer plus tôt si des détails sur l’une ou l’autre des vulnérabilités deviennent publics, ou si des preuves d’exploitation active devaient apparaître dans la nature », indique ainsi l’équipe. Or, des informations circulent déjà, même si elles restent pour l’instant générales.

Des failles exploitables à distance

Bleeping Computer indique avoir échangé avec les chercheurs en sécurité de watchTowr. Les deux vulnérabilités seraient de type RCE (remote code exploitation) et seraient donc exploitables à distance, affectant les branches 5, 7 et 8 de PHP.

Elles sont manifestement référencées comme CVE-2026-109618 et CVE-2026-109619, le CERT-EU ayant une fiche à leur sujet. Celle-ci recommande « vivement d’identifier les applications basées sur PHP et de se préparer à corriger dès que des versions corrigées seront disponibles. Lorsque la remédiation immédiate n’est pas envisageable, les organisations devraient envisager d’isoler les applications connectées à Internet des réseaux publics jusqu’à ce qu’une solution soit appliquée ». Le CERT-EU évoque lui aussi le caractère RCE des failles.

Dans une publication sur X, watchTowr a averti hier soir que des informations avaient fuité, alors que tout le monde était « censé attendre ». Au-delà des quelques informations en circulation, l’entreprise a indiqué à Bleeping Computer qu’elle ne publierait pas les détails avant l’heure « pour des raisons évidentes ». watchTowr ajoute que les failles sont bien réelles : « Prenez-les au sérieux et appliquez les correctifs dès qu’ils seront disponibles ».

Nous mettrons à jour cet article quand les détails des failles seront connus.

À vos marques ! Prêts ?

PHP doit proposer à 16h00 des correctifs pour deux failles de sécurité critiques. Le calendrier pourrait toutefois changer en fonction des éventuelles fuites. En début d’après-midi, de nombreux sites sont passés en maintenance préventive.

Mise à jour du 21 octobre, 16 h : Les correctifs ont été publiés avec une légère avance par l’équipe de PHP. Avec de nombreux sites mis en maintenance préventive et des exploits des failles circulant depuis plusieurs heures déjà, il était temps.

Comme suspecté, les deux failles sont de type RCE (exécution de code à distance) et ont en commun la manipulation par PHP de données dans un état non fiable. La première, CVE-2026-109618, réside dans la manière dont PHP nettoie les requêtes. S’il avait été interrompu par manque de mémoire, il peut traiter des données partiellement initialisées comme si elles étaient valides, ce qui corrompt la mémoire. La seconde, CVE-2026-109619, réside dans la persistance d’un état interne après une requête : la mémoire correspondante est alors libérée, mais l’état reste référencé. La requête suivante, traitée par le même processus, peut réutiliser cet état périmé.

Quatre nouvelles versions de PHP ont été publiées pour intégrer les correctifs : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toutes les installations servant des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé maximal pour mod_php.

L’équipe liste des mesures pour atténuer les risques dans certains cas, mais ajoute qu’aucune protection n’est réellement valable en dehors de l’installation des correctifs. En outre, au vu de la situation, elle a décidé de rétroporter les sources pour PHP 7.4, 8.0 et 8.1, des versions hors maintenance. Dans ces cas, il faudra compiler soi-même le code.

Nous avions de notre côté mis Next.ink en maintenance le temps que les correctifs soient disponibles. Le site est de retour avec une version de PHP à jour.

---

Mise à jour, 14 heures : la portée exacte des deux vulnérabilités concernées n’est pas encore connue, mais l’alerte prend des proportions inédites. Mercredi matin, le CERT-EU, le service de cybersécurité dédié aux institutions de l’Union européenne, a publié un bulletin qui recommande l’application du principe de précaution :

« Le CERT-EU recommande aux organisations de se préparer à la mise à jour immédiate des systèmes affectés. Si cette mise à jour immédiate n’est pas possible, les organisations devraient envisager d’isoler les applications exposées à Internet des réseaux publics jusqu’à la disponibilité d’un correctif. »

Plusieurs sites baissent le rideau préventivement

Le conseil semble avoir été suivi d’effets. Plusieurs sites d’organismes officiels européens ont ainsi choisi de baisser le rideau préventivement, en affichant un message de maintenance, et un retour programmé dans quelques heures, c’est-à-dire après installation de la mise à jour promise à 16 heures par la fondation PHP. C’est le cas par exemple de la CNIL française, du site du parlement hollandais ou d’un certain nombre de services publics finlandais, comme en témoigne ce relevé.

Plusieurs grands sites privés ont également interrompu leurs activités. D’après nos constatations, 4chan, DeviantArt et Dev-Null affichent par exemple un message de maintenance dont la cause est explicitement annoncée. « 4chan est temporairement en lecture seule en attendant une mise à jour de sécurité urgente de PHP », indique ainsi la célèbre plateforme.

Des attaques déjà recensées, Node.js lance aussi une alerte

D’après Dane Knecht, directeur technique de Cloudflare, des vecteurs d’attaque précoces auraient déjà été identifiés. L’entreprise assure avoir mis en place des règles préventives pour protéger ses clients exploitant PHP sur des sites exposés, mais elle recommande l’application sans délai du correctif dès publication. Des éléments d’information relatifs à l’exploitation des deux failles (non confirmés) circulent effectivement sur les réseaux sociaux.

S’agit-il d’un hasard du calendrier ou d’une conséquence collatérale des travaux de recherche liés à PHP ? L’équipe de Node.js, un environnement JavaScript couramment utilisé sur le Web, a elle aussi alerté mercredi sur la publication imminente d’un correctif de sécurité portant sur ses principales versions. L’après-midi s’annonce chargée pour les développeurs web et les sysadmin du monde entier.

---

Publication initiale, 8h42

L’équipe de PHP a publié le 20 octobre un important bulletin de sécurité au sujet de deux failles critiques. Les informations détaillées et les correctifs seront publiés aujourd’hui à 16h00, heure de la métropole. Dans son bulletin, PHP indique que les deux failles ont un score CVSS v4 de 9,2 sur 10. L’équipe recommande à toutes les personnes concernées et aux entreprises de se préparer pour appliquer les correctifs aussi rapidement que possible.

Ce calendrier pourrait toutefois évoluer au cours de la journée. « Nous nous réservons le droit de divulguer plus tôt si des détails sur l’une ou l’autre des vulnérabilités deviennent publics, ou si des preuves d’exploitation active devaient apparaître dans la nature », indique ainsi l’équipe. Or, des informations circulent déjà, même si elles restent pour l’instant générales.

Des failles exploitables à distance

Bleeping Computer indique avoir échangé avec les chercheurs en sécurité de watchTowr. Les deux vulnérabilités seraient de type RCE (remote code exploitation) et seraient donc exploitables à distance, affectant les branches 5, 7 et 8 de PHP.

Elles sont manifestement référencées comme CVE-2026-109618 et CVE-2026-109619, le CERT-EU ayant une fiche à leur sujet. Celle-ci recommande « vivement d’identifier les applications basées sur PHP et de se préparer à corriger dès que des versions corrigées seront disponibles. Lorsque la remédiation immédiate n’est pas envisageable, les organisations devraient envisager d’isoler les applications connectées à Internet des réseaux publics jusqu’à ce qu’une solution soit appliquée ». Le CERT-EU évoque lui aussi le caractère RCE des failles.

Dans une publication sur X, watchTowr a averti hier soir que des informations avaient fuité, alors que tout le monde était « censé attendre ». Au-delà des quelques informations en circulation, l’entreprise a indiqué à Bleeping Computer qu’elle ne publierait pas les détails avant l’heure « pour des raisons évidentes ». watchTowr ajoute que les failles sont bien réelles : « Prenez-les au sérieux et appliquez les correctifs dès qu’ils seront disponibles ».

Nous mettrons à jour cet article quand les détails des failles seront connus.

OpenBSD n’est pas un système que l’on croise forcément tous les jours, à moins d’exercer un métier spécifique, notamment dans les réseaux. Ce système Unix s’est fait un nom depuis longtemps dans ce domaine, ses composants étant régulièrement repris dans de nombreux équipements.

Quand une nouvelle version arrive, sa liste de modifications est donc un peu « aride ». On trouve certes une mise à jour générale des applications et composants : Chromium 154, Firefox 157, GNOME 49, KDE Plasma 6.7.5, GCC 16.1.0, LLVM 21.1.8 et 22.1.8, Go 1.27.1, Rust 1.98.1, Python 3.14.7 ou encore PostgreSQL 18.6 dans le cas présent.

Les nouveautés les plus significatives sont cependant sous le capot. Sur l’architecture amd64 (soit l’écrasante majorité des PC aujourd’hui), l’espace d’adressage virtuel du noyau passe ainsi de 4 à 512 Go, augmentant d’autant le mappage de la mémoire vidéo. On note une amélioration des performances de chiffrement sur amd64 et arm64, OpenBSD se servant désormais des instructions AES matérielles du processeur. Sur arm64, l’hibernation fait son entrée.

Nous n’allons pas lister toutes les améliorations, mais en voici plusieurs : un pilote drm resynchronisé avec le noyau Linux 6.18.53, le support par vmd d’un maximum de 64 processeurs virtuels par machine invitée, les interruptions MSI/MSI-X pour virtio et le déchargement du calcul des sommes de contrôle, l’acceptation des en-têtes HTTP personnalisés par httpd, l’arrivée d’OpenSSH 106 et de LibreSSL 4.4.0, ou encore un grand nombre de correctifs.

L’équipe de contributeurs a également mis en ligne une procédure pour mettre à jour l’actuel OpenBSD 7.9 vers cette nouvelle version 8.0.

OpenBSD n’est pas un système que l’on croise forcément tous les jours, à moins d’exercer un métier spécifique, notamment dans les réseaux. Ce système Unix s’est fait un nom depuis longtemps dans ce domaine, ses composants étant régulièrement repris dans de nombreux équipements.

Quand une nouvelle version arrive, sa liste de modifications est donc un peu « aride ». On trouve certes une mise à jour générale des applications et composants : Chromium 154, Firefox 157, GNOME 49, KDE Plasma 6.7.5, GCC 16.1.0, LLVM 21.1.8 et 22.1.8, Go 1.27.1, Rust 1.98.1, Python 3.14.7 ou encore PostgreSQL 18.6 dans le cas présent.

Les nouveautés les plus significatives sont cependant sous le capot. Sur l’architecture amd64 (soit l’écrasante majorité des PC aujourd’hui), l’espace d’adressage virtuel du noyau passe ainsi de 4 à 512 Go, augmentant d’autant le mappage de la mémoire vidéo. On note une amélioration des performances de chiffrement sur amd64 et arm64, OpenBSD se servant désormais des instructions AES matérielles du processeur. Sur arm64, l’hibernation fait son entrée.

Nous n’allons pas lister toutes les améliorations, mais en voici plusieurs : un pilote drm resynchronisé avec le noyau Linux 6.18.53, le support par vmd d’un maximum de 64 processeurs virtuels par machine invitée, les interruptions MSI/MSI-X pour virtio et le déchargement du calcul des sommes de contrôle, l’acceptation des en-têtes HTTP personnalisés par httpd, l’arrivée d’OpenSSH 106 et de LibreSSL 4.4.0, ou encore un grand nombre de correctifs.

L’équipe de contributeurs a également mis en ligne une procédure pour mettre à jour l’actuel OpenBSD 7.9 vers cette nouvelle version 8.0.

Coucou NVIDIA

Amazon Web Services a présenté un nouveau projet open source, TorchNeuron. Il se propose de simplifier le passage aux puces Trainium d’AWS pour entrainer les modèles. Bien que NVIDIA ne soit pas nommée, le projet est clairement pensé comme une alternative à CUDA.

PyTorch est initialement une bibliothèque logicielle créée par Meta (Facebook à l’époque). Depuis 2022, elle dépend de la Linux Foundation, tant elle est devenue importante. Elle sert en effet à construire et entraîner des modèles d’intelligence artificielle.

Cette bibliothèque est l’une des raisons pour lesquelles NVIDIA est autant sur le devant de la scène aujourd’hui. Entre PyTorch et le matériel utilisé pour les opérations, il faut justement une couche logicielle pour traduire les opérations en instructions que ce matériel peut comprendre. C’est précisément ce que fait CUDA depuis longtemps chez NVIDIA. Cette technologie propriétaire de type GPGPU (General-Purpose Computing on Graphics Processing Units) sert à faire basculer sur le GPU des calculs qui seraient autrement destinés au CPU.

Sans le dire aussi clairement, c’est ce lien fort qu’AWS veut remettre en question avec TorchNeuron, comme le relève notamment TechCrunch.

Direction les puces Trainium

Amazon Web Services dispose de ses propres puces en matière d’IA : les Trainium, dont la troisième génération a été lancée en décembre 2025. Ces puces peuvent servir aussi bien à l’entraînement qu’à l’inférence. Amazon n’est pas la seule entreprise à concevoir ses propres puces dans ce domaine : Microsoft possède Maia et Google a ses TPU (Tensor Process Units).

TorchNeuron est ainsi aux puces Trainium ce que CUDA est à NVIDIA, une couche de traduction. Elle s’appuie sur le mécanisme d’extension que PyTorch propose pour accueillir du matériel tiers et propose aux développeurs – dans le cas le plus simple – de remplacer dans leur code le périphérique cible cuda par neuron.

Est-ce aussi simple ? En théorie oui, mais l’exemple cité par AWS montre que la situation est plus complexe en pratique. Le billet évoque en effet le cas de Deepgram, un concurrent d’ElevenLabs dans le secteur de la synthèse vocale. Ainsi, non seulement certaines fonctions de PyTorch ne sont pas encore prises en charge, mais une partie des tests officiels de PyTorch est tout simplement ignorée, faute de traduction d’une partie des opérateurs de calcul. Deepgram est mis en avant comme ayant réussi à obtenir 70 % d’audio en plus pour chaque dollar dépensé, mais la mise en place de ce flux de travail a nécessité plusieurs mois de travail.

Boire au goulot

Officiellement, Amazon met en avant la réduction du coût de changement de puce pour les développeurs. Ces derniers seraient ainsi plus libres de comparer les options qui s’offrent à eux. Si l’on peut changer de puce sans pénalité particulière, les fabricants doivent mériter la clientèle, affirme même Amazon.

Auprès de TechCrunch, Colin Brace d’Annapurna Labs (la filiale qui conçoit les puces d’Amazon) met bien sûr en avant l’infrastructure et l’écosystème d’AWS. En outre, le responsable pointe la possibilité d’utiliser la même puce pour l’entraînement et l’inférence, avec à la clé la possibilité de réaffecter la capacité inutilisée.

La lutte contre la dépendance à NVIDIA s’inscrit en filigrane dans l’annonce, de manière plus ou moins intense selon les passages. L’un d’entre eux est cependant très clair : « L’approche d’Amazon va au-delà de son propre matériel. L’entreprise apporte des modifications en amont de PyTorch lui-même, en travaillant avec la communauté PyTorch pour supprimer le code liant le framework à des puces spécifiques. L’objectif est de rendre PyTorch plus indépendant du matériel pour toute la communauté des développeurs, pas seulement pour les utilisateurs de Trainium ». Une précision qui n’est pas tellement « pour » les utilisateurs de Trainium que « contre » NVIDIA, car cette dépendance peut signifier une configuration plus longue.

Cette lutte à peine voilée n’est pas le seul élément masqué. Sans même parler d’arracher les clients à un écosystème pour les plonger dans le sien, Amazon doit se débarrasser d’un goulot d’étranglement. L’intérêt des puces Trainium est en effet d’autant plus réduit que les clients ne peuvent pas les utiliser facilement. C’est ce goulot que NeuronTorch doit essayer de lever. AWS essaye donc de réaliser un coup double : réduire les spécificités de PyTorch pour CUDA et fluidifier l’accès à ses puces.

TorchNeuron est cependant un projet neuf. Le code est présenté sous licence Apache 2.0 (open source) dans un dépôt GitHub ouvert le 17 octobre, même si AWS annonce sa disponibilité pour le 20 octobre. Dans sa forme actuelle, le projet prend en charge les puces Trainium 2 et 3. Reste pour Amazon à concrétiser sa vision en alimentant son projet, dont le succès dépendra de l’adoption par les développeurs concernés.

Coucou NVIDIA

Amazon Web Services a présenté un nouveau projet open source, TorchNeuron. Il se propose de simplifier le passage aux puces Trainium d’AWS pour entrainer les modèles. Bien que NVIDIA ne soit pas nommée, le projet est clairement pensé comme une alternative à CUDA.

PyTorch est initialement une bibliothèque logicielle créée par Meta (Facebook à l’époque). Depuis 2022, elle dépend de la Linux Foundation, tant elle est devenue importante. Elle sert en effet à construire et entraîner des modèles d’intelligence artificielle.

Cette bibliothèque est l’une des raisons pour lesquelles NVIDIA est autant sur le devant de la scène aujourd’hui. Entre PyTorch et le matériel utilisé pour les opérations, il faut justement une couche logicielle pour traduire les opérations en instructions que ce matériel peut comprendre. C’est précisément ce que fait CUDA depuis longtemps chez NVIDIA. Cette technologie propriétaire de type GPGPU (General-Purpose Computing on Graphics Processing Units) sert à faire basculer sur le GPU des calculs qui seraient autrement destinés au CPU.

Sans le dire aussi clairement, c’est ce lien fort qu’AWS veut remettre en question avec TorchNeuron, comme le relève notamment TechCrunch.

Direction les puces Trainium

Amazon Web Services dispose de ses propres puces en matière d’IA : les Trainium, dont la troisième génération a été lancée en décembre 2025. Ces puces peuvent servir aussi bien à l’entraînement qu’à l’inférence. Amazon n’est pas la seule entreprise à concevoir ses propres puces dans ce domaine : Microsoft possède Maia et Google a ses TPU (Tensor Process Units).

TorchNeuron est ainsi aux puces Trainium ce que CUDA est à NVIDIA, une couche de traduction. Elle s’appuie sur le mécanisme d’extension que PyTorch propose pour accueillir du matériel tiers et propose aux développeurs – dans le cas le plus simple – de remplacer dans leur code le périphérique cible cuda par neuron.

Est-ce aussi simple ? En théorie oui, mais l’exemple cité par AWS montre que la situation est plus complexe en pratique. Le billet évoque en effet le cas de Deepgram, un concurrent d’ElevenLabs dans le secteur de la synthèse vocale. Ainsi, non seulement certaines fonctions de PyTorch ne sont pas encore prises en charge, mais une partie des tests officiels de PyTorch est tout simplement ignorée, faute de traduction d’une partie des opérateurs de calcul. Deepgram est mis en avant comme ayant réussi à obtenir 70 % d’audio en plus pour chaque dollar dépensé, mais la mise en place de ce flux de travail a nécessité plusieurs mois de travail.

Boire au goulot

Officiellement, Amazon met en avant la réduction du coût de changement de puce pour les développeurs. Ces derniers seraient ainsi plus libres de comparer les options qui s’offrent à eux. Si l’on peut changer de puce sans pénalité particulière, les fabricants doivent mériter la clientèle, affirme même Amazon.

Auprès de TechCrunch, Colin Brace d’Annapurna Labs (la filiale qui conçoit les puces d’Amazon) met bien sûr en avant l’infrastructure et l’écosystème d’AWS. En outre, le responsable pointe la possibilité d’utiliser la même puce pour l’entraînement et l’inférence, avec à la clé la possibilité de réaffecter la capacité inutilisée.

La lutte contre la dépendance à NVIDIA s’inscrit en filigrane dans l’annonce, de manière plus ou moins intense selon les passages. L’un d’entre eux est cependant très clair : « L’approche d’Amazon va au-delà de son propre matériel. L’entreprise apporte des modifications en amont de PyTorch lui-même, en travaillant avec la communauté PyTorch pour supprimer le code liant le framework à des puces spécifiques. L’objectif est de rendre PyTorch plus indépendant du matériel pour toute la communauté des développeurs, pas seulement pour les utilisateurs de Trainium ». Une précision qui n’est pas tellement « pour » les utilisateurs de Trainium que « contre » NVIDIA, car cette dépendance peut signifier une configuration plus longue.

Cette lutte à peine voilée n’est pas le seul élément masqué. Sans même parler d’arracher les clients à un écosystème pour les plonger dans le sien, Amazon doit se débarrasser d’un goulot d’étranglement. L’intérêt des puces Trainium est en effet d’autant plus réduit que les clients ne peuvent pas les utiliser facilement. C’est ce goulot que NeuronTorch doit essayer de lever. AWS essaye donc de réaliser un coup double : réduire les spécificités de PyTorch pour CUDA et fluidifier l’accès à ses puces.

TorchNeuron est cependant un projet neuf. Le code est présenté sous licence Apache 2.0 (open source) dans un dépôt GitHub ouvert le 17 octobre, même si AWS annonce sa disponibilité pour le 20 octobre. Dans sa forme actuelle, le projet prend en charge les puces Trainium 2 et 3. Reste pour Amazon à concrétiser sa vision en alimentant son projet, dont le succès dépendra de l’adoption par les développeurs concernés.

La direction générale de l’administration et de la fonction publique (DGAFP) a présenté sa revue stratégique de la fonction publique à l’horizon 2035 - 2050. Parmi les « grandes transitions » que la fonction publique doit absorber, le numérique et l’IA figurent en bonne place, avec la transition démographique, la transition écologique ou encore l’instabilité sécuritaire croissante.

Le rapport consacre quatre pages au numérique et à l’IA, dans lesquelles la DGAFP fait notamment un constat problématique : si 82 % des démarches administratives peuvent aujourd’hui se faire en ligne, 44 % des personnes interrogées ont déclaré avoir des difficultés à les faire. La direction générale en conclut qu’un accueil humain, au guichet ou au téléphone, reste nécessaire, surtout pour les publics fragiles et les dossiers complexes. Elle ajoute que le numérique doit servir à dégager du temps pour l’accompagnement individualisé, pas à supprimer des postes d’agents de la fonction publique.

Le même rapport aborde la dépendance de l’État envers ses prestataires informatiques. Dans ce domaine, il reprend la recommandation de la Dinum (Direction interministérielle du numérique) d’un seuil minimal d’emploi interne de 37 %. Cependant, il le compare à la moyenne mondiale de 67 %, tous secteurs confondus.

Dans ce domaine, l’Espagne est érigée en exemple. Nos voisins ont ainsi mis en place un vaste plan de numérisation sur la période 2021 - 2025, doté d’un budget de 2,6 milliards d’euros. L’objectif sur 2026 était ensuite l’ouverture de 1 700 postes dans les corps de fonctionnaires du numérique. Des spécialités en IA, cybersécurité et science des données y apparaissent pour la première fois. Le rapport de la DGAFP préconise ainsi une forte réinternalisation des compétences.

L’exposition à l’IA, selon le rapport, varie très fortement selon les secteurs. Plus de la moitié des agents seraient très peu concernés, l’exposition se concentrant dans les fonctions administratives et de support. 20 % des agents seraient en revanche significativement exposés, soit 1,1 million de personnes.

Selon la DGAFP, « l’IA transformerait davantage les tâches que les métiers dans leur ensemble ». La direction générale estime que le temps libéré par l’IA devrait être réaffecté vers « l’expertise, le contrôle et la relation aux usagers ». Elle ajoute que des formations, mobilités voire reconversions devront être organisées. De plus, le déploiement de l’IA va « contribuer à une recomposition profonde des emplois et une évolution des modalités de recrutement pour privilégier l’esprit critique sur la capacité de synthèse, par exemple ».

La direction générale de l’administration et de la fonction publique (DGAFP) a présenté sa revue stratégique de la fonction publique à l’horizon 2035 - 2050. Parmi les « grandes transitions » que la fonction publique doit absorber, le numérique et l’IA figurent en bonne place, avec la transition démographique, la transition écologique ou encore l’instabilité sécuritaire croissante.

Le rapport consacre quatre pages au numérique et à l’IA, dans lesquelles la DGAFP fait notamment un constat problématique : si 82 % des démarches administratives peuvent aujourd’hui se faire en ligne, 44 % des personnes interrogées ont déclaré avoir des difficultés à les faire. La direction générale en conclut qu’un accueil humain, au guichet ou au téléphone, reste nécessaire, surtout pour les publics fragiles et les dossiers complexes. Elle ajoute que le numérique doit servir à dégager du temps pour l’accompagnement individualisé, pas à supprimer des postes d’agents de la fonction publique.

Le même rapport aborde la dépendance de l’État envers ses prestataires informatiques. Dans ce domaine, il reprend la recommandation de la Dinum (Direction interministérielle du numérique) d’un seuil minimal d’emploi interne de 37 %. Cependant, il le compare à la moyenne mondiale de 67 %, tous secteurs confondus.

Dans ce domaine, l’Espagne est érigée en exemple. Nos voisins ont ainsi mis en place un vaste plan de numérisation sur la période 2021 - 2025, doté d’un budget de 2,6 milliards d’euros. L’objectif sur 2026 était ensuite l’ouverture de 1 700 postes dans les corps de fonctionnaires du numérique. Des spécialités en IA, cybersécurité et science des données y apparaissent pour la première fois. Le rapport de la DGAFP préconise ainsi une forte réinternalisation des compétences.

L’exposition à l’IA, selon le rapport, varie très fortement selon les secteurs. Plus de la moitié des agents seraient très peu concernés, l’exposition se concentrant dans les fonctions administratives et de support. 20 % des agents seraient en revanche significativement exposés, soit 1,1 million de personnes.

Selon la DGAFP, « l’IA transformerait davantage les tâches que les métiers dans leur ensemble ». La direction générale estime que le temps libéré par l’IA devrait être réaffecté vers « l’expertise, le contrôle et la relation aux usagers ». Elle ajoute que des formations, mobilités voire reconversions devront être organisées. De plus, le déploiement de l’IA va « contribuer à une recomposition profonde des emplois et une évolution des modalités de recrutement pour privilégier l’esprit critique sur la capacité de synthèse, par exemple ».

Agentception

Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.

Mise à jour du 22 octobre : L’entreprise nous a répondu que les produits annoncés étaient pour l’instant disponibles uniquement sous forme de préversions privées, avec une disponibilité publique prévue via Ignite, à une date non communiquée.

---

Article original : Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.

• OpenAI : haute voltige marketing autour de l’attaque contre Hugging Face
• Le storytelling autour de la sécurité des agents IA a « perdu le contact avec la réalité »
• Agents IA : des « dizaines de milliers d’incidents » sont en cours d’examen
• Comment les agents IA bouleversent la cybersécurité, défensive et offensive

La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.

Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.

Les agents, des employés pas comme les autres

Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.

Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.

• Dis Next, c’est quoi l’IA agentique et les harnais dont tout le monde parle ?

C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.

La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.

Une série d’annonces concrètes

Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.

Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.

En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.

Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.

Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.

Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.

Quelle date ? Quels prix ?

Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.

Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).

L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).

Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.

Agentception

Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.

Mise à jour du 22 octobre : L’entreprise nous a répondu que les produits annoncés étaient pour l’instant disponibles uniquement sous forme de préversions privées, avec une disponibilité publique prévue via Ignite, à une date non communiquée.

---

Article original : Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.

• OpenAI : haute voltige marketing autour de l’attaque contre Hugging Face
• Le storytelling autour de la sécurité des agents IA a « perdu le contact avec la réalité »
• Agents IA : des « dizaines de milliers d’incidents » sont en cours d’examen
• Comment les agents IA bouleversent la cybersécurité, défensive et offensive

La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.

Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.

Les agents, des employés pas comme les autres

Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.

Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.

• Dis Next, c’est quoi l’IA agentique et les harnais dont tout le monde parle ?

C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.

La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.

Une série d’annonces concrètes

Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.

Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.

En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.

Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.

Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.

Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.

Quelle date ? Quels prix ?

Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.

Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).

L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).

Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.

La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.

Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.

À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.

La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.

Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.

Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.

Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.

La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.

La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.

Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.

À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.

La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.

Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.

Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.

Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.

La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.

Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.

La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.

Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.

L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.

Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.

À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.

À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.

Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.

La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.

Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.

L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.

Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.

À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.

À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.