LinkedIn inaugure un nouveau bouton qui permet à l’utilisateur de signaler un contenu « AI slop ». Lorsqu’un billet semble avoir été rédigé par une intelligence artificielle, il suffit d’appuyer sur ce bouton pour informer LinkedIn. La procédure doit l’aider à « améliorer le fil d’actualité », sans supprimer pour autant le contenu.
Quand on parle d’« AI slop », on pense souvent à ces posts et ces images postés sur Facebook ou Instagram, Meta s’étant fait la spécialité de ce genre de bouillie, ou encore les horreurs qui circulent sur X. Mais dans le genre, LinkedIn n’est pas mal non plus. Une étude Pangram de début juillet relevait ainsi que 41 % des billets « long format » (plus de 250 mots) postés sur le réseau social sont générés par IA.
Signaler les posts qui sonnent faux
LinkedIn ne veut pas de ce stigmate, mais il a besoin de ses utilisateurs. Ils trouveront dans la feuille d’options un nouveau bouton au libellé très clair « Seems like AI slop » (pas encore traduit en français), pour signaler un contenu généré par IA – ou qu’on estime être généré par IA. Ce bouton est d’ores et déjà disponible, d’après ce que nous avons pu constater (404media aussi).
Hari Srinivasan, chef produit de LinkedIn, explique dans un post (généré par IA ?) que la lutte contre cette « bouillie » est une « priorité absolue ». Il confirme le lancement de cette nouvelle option de signalement d’AI slop, « [une] notion difficile à définir » et qui évolue : « ces signalements nous permettront d’ajuster nos modèles et d’améliorer les fils d’actualité. »
Il déroule également les efforts de l’entreprise dans cette lutte acharnée contre la médiocrité : la détection automatisée dans les commentaires de publications automatisées et de « slop », l’amélioration des outils internes d’identification de publications de faible qualité ou générées par IA, et la suppression de la fonction « améliorer votre publication ». Elle sera remplacée par un outil de correction du texte, sans modification plus profonde du texte.
Les utilisateurs qui publient du contenu verront dans leur tableau de bord les signalements de lecteurs qui estiment qu’un post « paraît manquer d’authenticité » ou semble recourir largement à l’IA. Une approche qui repose sur deux constats :
« Premièrement, l’IA et la « bouillie » ne sont pas la même chose : beaucoup de personnes utilisent l’IA pour affiner leurs idées, et nous pensons qu’elles souhaitent savoir quand leur propos semble manquer d’authenticité. Deuxièmement, nous voulons que les membres reçoivent l’avis de vraies personnes sur ce qui paraît authentique, plutôt que de se fier uniquement à un détecteur d’IA susceptible de se tromper. »
D’autres changements sont dans les tuyaux pour réduire la bouillie d’IA dans le fil d’actualité de LinkedIn, et redonner aux utilisateurs l’impression de lire des textes écrits par des humains.
LinkedIn inaugure un nouveau bouton qui permet à l’utilisateur de signaler un contenu « AI slop ». Lorsqu’un billet semble avoir été rédigé par une intelligence artificielle, il suffit d’appuyer sur ce bouton pour informer LinkedIn. La procédure doit l’aider à « améliorer le fil d’actualité », sans supprimer pour autant le contenu.
Quand on parle d’« AI slop », on pense souvent à ces posts et ces images postés sur Facebook ou Instagram, Meta s’étant fait la spécialité de ce genre de bouillie, ou encore les horreurs qui circulent sur X. Mais dans le genre, LinkedIn n’est pas mal non plus. Une étude Pangram de début juillet relevait ainsi que 41 % des billets « long format » (plus de 250 mots) postés sur le réseau social sont générés par IA.
Signaler les posts qui sonnent faux
LinkedIn ne veut pas de ce stigmate, mais il a besoin de ses utilisateurs. Ils trouveront dans la feuille d’options un nouveau bouton au libellé très clair « Seems like AI slop » (pas encore traduit en français), pour signaler un contenu généré par IA – ou qu’on estime être généré par IA. Ce bouton est d’ores et déjà disponible, d’après ce que nous avons pu constater (404media aussi).
Hari Srinivasan, chef produit de LinkedIn, explique dans un post (généré par IA ?) que la lutte contre cette « bouillie » est une « priorité absolue ». Il confirme le lancement de cette nouvelle option de signalement d’AI slop, « [une] notion difficile à définir » et qui évolue : « ces signalements nous permettront d’ajuster nos modèles et d’améliorer les fils d’actualité. »
Il déroule également les efforts de l’entreprise dans cette lutte acharnée contre la médiocrité : la détection automatisée dans les commentaires de publications automatisées et de « slop », l’amélioration des outils internes d’identification de publications de faible qualité ou générées par IA, et la suppression de la fonction « améliorer votre publication ». Elle sera remplacée par un outil de correction du texte, sans modification plus profonde du texte.
Les utilisateurs qui publient du contenu verront dans leur tableau de bord les signalements de lecteurs qui estiment qu’un post « paraît manquer d’authenticité » ou semble recourir largement à l’IA. Une approche qui repose sur deux constats :
« Premièrement, l’IA et la « bouillie » ne sont pas la même chose : beaucoup de personnes utilisent l’IA pour affiner leurs idées, et nous pensons qu’elles souhaitent savoir quand leur propos semble manquer d’authenticité. Deuxièmement, nous voulons que les membres reçoivent l’avis de vraies personnes sur ce qui paraît authentique, plutôt que de se fier uniquement à un détecteur d’IA susceptible de se tromper. »
D’autres changements sont dans les tuyaux pour réduire la bouillie d’IA dans le fil d’actualité de LinkedIn, et redonner aux utilisateurs l’impression de lire des textes écrits par des humains.
L’Union européenne a publié ce 29 juillet un appel d’offres pour la création de sept « Gigafactories d’IA ».
Ces usines sont décrites comme des édifices mêlant « processeurs d’IA avancés, des piles de logiciels et de technologies en nuage, une connectivité à haut débit et des centres de données économes en énergie ».
Elles pourront être implantées dans un seul État membre, sur un site ou plusieurs, mais aussi évoluer vers des projets transfrontaliers.
Illustration : Flock
L’EuroHPC, « entreprise commune pour le calcul à haute performance européen », sera mis à contribution, sachant que dix-huit États membres ont signé un accord de marché avec elle.
Présenté comme partie intégrante de son plan pour devenir « le continent de l’intelligence artificielle », la Commission prévoit jusqu’à 10 milliards d’euros de financements européens et nationaux, susceptibles selon elle d’entraîner « au moins 20 milliards d’euros d’investissements privés dans l’ensemble de l’Union ».
La procédure d’appel d’offres se terminera le 12 novembre, les candidats retenus doivent être annoncés début 2027 et les premières installations être opérationnelles dans les 18 mois qui suivront la signature.
L’Union européenne a publié ce 29 juillet un appel d’offres pour la création de sept « Gigafactories d’IA ».
Ces usines sont décrites comme des édifices mêlant « processeurs d’IA avancés, des piles de logiciels et de technologies en nuage, une connectivité à haut débit et des centres de données économes en énergie ».
Elles pourront être implantées dans un seul État membre, sur un site ou plusieurs, mais aussi évoluer vers des projets transfrontaliers.
Illustration : Flock
L’EuroHPC, « entreprise commune pour le calcul à haute performance européen », sera mis à contribution, sachant que dix-huit États membres ont signé un accord de marché avec elle.
Présenté comme partie intégrante de son plan pour devenir « le continent de l’intelligence artificielle », la Commission prévoit jusqu’à 10 milliards d’euros de financements européens et nationaux, susceptibles selon elle d’entraîner « au moins 20 milliards d’euros d’investissements privés dans l’ensemble de l’Union ».
La procédure d’appel d’offres se terminera le 12 novembre, les candidats retenus doivent être annoncés début 2027 et les premières installations être opérationnelles dans les 18 mois qui suivront la signature.
Hébergeur de millions de modèles d’IA et de milliers de jeux de données, Hugging Face n’a implémenté aucun outil concret de modération des outils et pratiques relevant de la fabrication de contenu sexuel non consensuel, selon les travaux d’AI Forensics.
En pleins travaux sur le règlement sur l’intelligence artificielle et divers autres textes relatifs à l’industrie numérique, l’Union européenne a ajouté une interdiction explicite des « systèmes dits de nudification » dans l’AI Act, lorsque ces outils sont utilisés sans le consentement des personnes concernées. Parmi les sociétés qui ont pignon sur rue, dans l’industrie de l’intelligence artificielle, il y a Hugging Face.
Installée aux États-Unis, celle-ci propose une plate-forme donnant accès à une bibliothèque open source de systèmes d’IA, de bases de données et d’environnements de tests. Or, d’après les travaux des chercheurs Paul Bouchaud et Silvia Semenzin pour l’ONG AI Forensics, l’entreprise n’a implémenté aucune forme de garde-fous pour éviter l’accès à des modèles problématiques. En l’occurrence, elle ne modère ni les outils permettant de produire des images et vidéos pédocriminelles générées par IA, ni les requêtes.
AI Forensics a construit un pot de miel pour suivre les demandes des utilisateurs. Au bout d’une semaine de collecte de prompts d’internautes réels, elle constate que 73 % des requêtes relevaient de contenu à caractère sexuel, et 60 % de contenu a priori non consensuel.
La découverte est d’autant plus inquiétante que l’Internet Watch Foundation alertait mi-mars contre la multiplication de ce type de contenus. Comme nous l’expliquait l’ex-commandante de police Véronique Béchu dans Entre la chaise et le clavier, l’enjeu est de taille : extrêmement difficile à discerner de réelles images pédopornographiques, ce type de contenu fait perdre du temps aux équipes policières en charge de mettre des victimes de violence à l’abri. Par ailleurs, la multiplication de ce type de contenus participe directement à la banalisation des violences sexuelles représentées.
Il reste 79% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
Des internautes ont signalé qu’il était simple de retrouver des conversations Claude partagées. Pour Anthropic cependant, il n’y a aucun problème : c’est le fonctionnement attendu de cette capacité. Mais ce n’est pas tout à fait aussi simple. Encore plus inquiétant, c’est le quatrième incident du genre en un an.
Durant le week-end du 25 - 26 juillet, des utilisateurs de Reddit ont découvert que l’opérateur de recherche « site:claude.ai/share » faisait remonter dans Google une longue liste de conversations Claude partagées, ainsi que des éléments nommés Artefacts par Anthropic : documents et mini-applications interactifs générés dans l’outil.
Le 27 juillet, 404 Media publie un article évoquant la situation, rapidement suivi par d’autres, comme TechCrunch. Depuis, nombre de sites et personnes ont évoqué la situation, relevant qu’on peut trouver une foule d’informations dans ces éléments partagés.
Ces révélations ont pris un tour plus dangereux quand certaines informations se sont avérées être sensibles. Futurism, cité par plusieurs médias, a identifié un rapport médical détaillé nommant un patient, des résultats d’essai clinique avec des noms de patients, ainsi que des fichiers contenant les noms et numéros de téléphone d’enfants d’école primaire. Le contenu exposé allait de notes de programmation et de fausses critiques de livres à des éléments bien plus sensibles : rapports médicaux de patients, données d’essais cliniques avec noms réels, documents internes d’entreprise, évaluations de salariés, clés API et identifiants de connexion.
Pour Anthropic, c’est tout à fait normal
Pour l’entreprise à l’origine de Claude, c’est le résultat d’un comportement parfaitement attendu : les conversations partagées sont accessibles à toute personne possédant le lien. Or, il suffit que ce lien ait été publié dans un endroit accessible aux moteurs de recherche pour qu’il se retrouve dans les résultats, si la requête est conçue spécifiquement pour le retrouver et que le fichiers robots.txt n’interdit pas explicitement la récupération des informations.
Amie Rotherham, porte-parole d’Anthropic, a ainsi indiqué à TechCrunch :
« Nous donnons aux gens le contrôle pour partager publiquement leurs conversations avec Claude, et conformément à nos principes de confidentialité, nous ne partageons pas les annuaires de discussion ni les sitemaps avec des moteurs de recherche comme Google. Ces liens partageables ne sont ni devinables ni découvrables à moins que les gens choisissent de les partager eux-mêmes. Lorsqu’une personne partage une conversation, elle rend ce contenu accessible au public, et comme tout autre contenu public sur le web, il peut être archivé par des services tiers ».
Du côté de Google, on cherche également à se montrer clair : « Ni Google ni aucun autre moteur de recherche ne contrôle quelles pages sont rendues publiques sur le web, et ces pages ont été indexées sur de nombreux moteurs de recherche. Nous donnons aux propriétaires de sites des contrôles clairs pour décider si les pages peuvent être explorées ou indexées, et nous respectons toujours ces directives ». En d’autres termes, ces liens étaient publics et ont été repris par tous les moteurs, sous-entendu : « pas nous uniquement ».
Mais ce n’est pas si simple
La situation semble à l’heure réglée, les résultats ayant disparu dans l’après-midi du lundi 27 juillet. Si le fonctionnement des conversations partagées était normal, pourquoi cette disparition.
Parce qu’en dépit de ce qu’a déclaré Anthropic, il semble bien qu’il y ait eu un problème, selon Search Engine Journal. Nos confrères ont réalisé un audit des en-têtes HTTP ce même 27 juillet. Le chemin /share/* de claude.ai est bloqué par une directive Disallow dans le robots.txt, sous le groupe générique User-agent: *.
Or, les pages elles-mêmes renvoient un en-tête X-Robots-Tag: none, que les directives de Google traitent comme équivalent à noindex et nofollow. Le chemin de partage est ainsi bloqué par le robots.txt de claude.ai.
Et c’est là que survient le problème, selon Search Engine Journal : « À cause de cela, les règles entrent en conflit. Selon les directives de Google, un tag noindex ne fonctionne que si l’outil d’exploration est autorisé à accéder et à lire la page. Si une page est bloquée par robots.txt, elle peut toujours être indexée si d’autres pages y renvoient, puisque Googlebot note l’URL sans l’ouvrir réellement ».
Le bot de Google voit donc une page disposant d’une directive de non-référencement et en indexe l’URL nue, sans le contenu. Il en va de même pour les URL présentes sur cette page, dont les directives ne peuvent pas être lues à cause du premier blocage. Ce conflit a entrainé le référencement des adresses de partage des conversations Claude, sans leur contenu. Voilà pourquoi on pouvait les retrouver avec un opérateur de recherche.
Anthropic n’a pas communiqué de correctif technique explicite. La disparition des résultats de recherche dès le lundi après-midi a été constatée par 404 Media, TechCrunch mais également par Next, sans confirmation officielle du mécanisme corrigé. Ce nettoyage et les observations réalisées par Search Engine Journal laissent cependant penser que l’entreprise s’est peut-être rendu compte du conflit potentiel entre les directives.
Que faire côté internaute ?
Si vous ne partagez pas vos conversations Claude ou que vous ne le faites qu’au travers d’autres moyens que des pages web (par exemple une messagerie instantanée), il n’y a rien à craindre. Toutes les conversations sont privées (au sens d’Anthropic) par défaut.
Si vous avez des conversations partagées, vous pouvez cependant en révoquer l’accès. Rendez-vous dans les paramètres du compte, puis dans « Confidentialité ». Là, descendez jusqu’à la ligne « Conversations partagées » puis cliquez sur « Gérer ». La liste apparaitra, avec possibilité de voir la conversation et de la supprimer.
Notez bien que l’icône de poubelle, qui désigne la suppression, ne signifie pas que la conversation elle-même sera effacée, uniquement le partage associé. Autre information importante, la gestion des Artefacts est séparée et se fait depuis la ligne juste en-dessous de « Conversations partagées ».
Ce n’est pas une première, loin de là
Ce n’est pas la première fois (et certainement pas la dernière) que ce genre de couac arrive. Il y a un an, OpenAI corrigeait le tir de son IA générative qui laissait vos discussions « publiques » avec ChatGPT être indexées par les moteurs de recherche, dont Google. Quelques semaines après OpenAI, xAI aussi y est allé de sa pierre à l’édifice avec des centaines de milliers de conversations rendues accessibles via les moteurs de recherche.
En septembre, Forbes alertait sur la présence de plusieurs centaines de conversations avec le chatbot Claude d’Anthropic dans Google. Déjà à l’époque, l’entreprise rejetait la faute sur les utilisateurs : « La porte-parole d’Anthropic, Gabby Curtis, a déclaré à Forbes que les conversations avec Claude n’étaient visibles que sur Google et Bing parce que les utilisateurs avaient publié des liens vers ces conversations en ligne ou sur les réseaux sociaux », expliquaient nos confrères.
Quatre incidents du même genre en seulement un an, le problème est récurrent. C’est l’occasion de rappeler une règle élémentaire : ne pas partager publiquement le lien d’un document que vous souhaitez garder pour vous. On pourrait même recommander de ne pas créer de lien de partage tout court afin de limiter les risques. Parfois, certains ne savent même pas que les documents sont accessibles publiquement, comme nous l’avons démontré avec des Google Groupes en accès libre aux quatre vents.
Des internautes ont signalé qu’il était simple de retrouver des conversations Claude partagées. Pour Anthropic cependant, il n’y a aucun problème : c’est le fonctionnement attendu de cette capacité. Mais ce n’est pas tout à fait aussi simple. Encore plus inquiétant, c’est le quatrième incident du genre en un an.
Durant le week-end du 25 - 26 juillet, des utilisateurs de Reddit ont découvert que l’opérateur de recherche « site:claude.ai/share » faisait remonter dans Google une longue liste de conversations Claude partagées, ainsi que des éléments nommés Artefacts par Anthropic : documents et mini-applications interactifs générés dans l’outil.
Le 27 juillet, 404 Media publie un article évoquant la situation, rapidement suivi par d’autres, comme TechCrunch. Depuis, nombre de sites et personnes ont évoqué la situation, relevant qu’on peut trouver une foule d’informations dans ces éléments partagés.
Ces révélations ont pris un tour plus dangereux quand certaines informations se sont avérées être sensibles. Futurism, cité par plusieurs médias, a identifié un rapport médical détaillé nommant un patient, des résultats d’essai clinique avec des noms de patients, ainsi que des fichiers contenant les noms et numéros de téléphone d’enfants d’école primaire. Le contenu exposé allait de notes de programmation et de fausses critiques de livres à des éléments bien plus sensibles : rapports médicaux de patients, données d’essais cliniques avec noms réels, documents internes d’entreprise, évaluations de salariés, clés API et identifiants de connexion.
Pour Anthropic, c’est tout à fait normal
Pour l’entreprise à l’origine de Claude, c’est le résultat d’un comportement parfaitement attendu : les conversations partagées sont accessibles à toute personne possédant le lien. Or, il suffit que ce lien ait été publié dans un endroit accessible aux moteurs de recherche pour qu’il se retrouve dans les résultats, si la requête est conçue spécifiquement pour le retrouver et que le fichiers robots.txt n’interdit pas explicitement la récupération des informations.
Amie Rotherham, porte-parole d’Anthropic, a ainsi indiqué à TechCrunch :
« Nous donnons aux gens le contrôle pour partager publiquement leurs conversations avec Claude, et conformément à nos principes de confidentialité, nous ne partageons pas les annuaires de discussion ni les sitemaps avec des moteurs de recherche comme Google. Ces liens partageables ne sont ni devinables ni découvrables à moins que les gens choisissent de les partager eux-mêmes. Lorsqu’une personne partage une conversation, elle rend ce contenu accessible au public, et comme tout autre contenu public sur le web, il peut être archivé par des services tiers ».
Du côté de Google, on cherche également à se montrer clair : « Ni Google ni aucun autre moteur de recherche ne contrôle quelles pages sont rendues publiques sur le web, et ces pages ont été indexées sur de nombreux moteurs de recherche. Nous donnons aux propriétaires de sites des contrôles clairs pour décider si les pages peuvent être explorées ou indexées, et nous respectons toujours ces directives ». En d’autres termes, ces liens étaient publics et ont été repris par tous les moteurs, sous-entendu : « pas nous uniquement ».
Mais ce n’est pas si simple
La situation semble à l’heure réglée, les résultats ayant disparu dans l’après-midi du lundi 27 juillet. Si le fonctionnement des conversations partagées était normal, pourquoi cette disparition.
Parce qu’en dépit de ce qu’a déclaré Anthropic, il semble bien qu’il y ait eu un problème, selon Search Engine Journal. Nos confrères ont réalisé un audit des en-têtes HTTP ce même 27 juillet. Le chemin /share/* de claude.ai est bloqué par une directive Disallow dans le robots.txt, sous le groupe générique User-agent: *.
Or, les pages elles-mêmes renvoient un en-tête X-Robots-Tag: none, que les directives de Google traitent comme équivalent à noindex et nofollow. Le chemin de partage est ainsi bloqué par le robots.txt de claude.ai.
Et c’est là que survient le problème, selon Search Engine Journal : « À cause de cela, les règles entrent en conflit. Selon les directives de Google, un tag noindex ne fonctionne que si l’outil d’exploration est autorisé à accéder et à lire la page. Si une page est bloquée par robots.txt, elle peut toujours être indexée si d’autres pages y renvoient, puisque Googlebot note l’URL sans l’ouvrir réellement ».
Le bot de Google voit donc une page disposant d’une directive de non-référencement et en indexe l’URL nue, sans le contenu. Il en va de même pour les URL présentes sur cette page, dont les directives ne peuvent pas être lues à cause du premier blocage. Ce conflit a entrainé le référencement des adresses de partage des conversations Claude, sans leur contenu. Voilà pourquoi on pouvait les retrouver avec un opérateur de recherche.
Anthropic n’a pas communiqué de correctif technique explicite. La disparition des résultats de recherche dès le lundi après-midi a été constatée par 404 Media, TechCrunch mais également par Next, sans confirmation officielle du mécanisme corrigé. Ce nettoyage et les observations réalisées par Search Engine Journal laissent cependant penser que l’entreprise s’est peut-être rendu compte du conflit potentiel entre les directives.
Que faire côté internaute ?
Si vous ne partagez pas vos conversations Claude ou que vous ne le faites qu’au travers d’autres moyens que des pages web (par exemple une messagerie instantanée), il n’y a rien à craindre. Toutes les conversations sont privées (au sens d’Anthropic) par défaut.
Si vous avez des conversations partagées, vous pouvez cependant en révoquer l’accès. Rendez-vous dans les paramètres du compte, puis dans « Confidentialité ». Là, descendez jusqu’à la ligne « Conversations partagées » puis cliquez sur « Gérer ». La liste apparaitra, avec possibilité de voir la conversation et de la supprimer.
Notez bien que l’icône de poubelle, qui désigne la suppression, ne signifie pas que la conversation elle-même sera effacée, uniquement le partage associé. Autre information importante, la gestion des Artefacts est séparée et se fait depuis la ligne juste en-dessous de « Conversations partagées ».
Ce n’est pas une première, loin de là
Ce n’est pas la première fois (et certainement pas la dernière) que ce genre de couac arrive. Il y a un an, OpenAI corrigeait le tir de son IA générative qui laissait vos discussions « publiques » avec ChatGPT être indexées par les moteurs de recherche, dont Google. Quelques semaines après OpenAI, xAI aussi y est allé de sa pierre à l’édifice avec des centaines de milliers de conversations rendues accessibles via les moteurs de recherche.
En septembre, Forbes alertait sur la présence de plusieurs centaines de conversations avec le chatbot Claude d’Anthropic dans Google. Déjà à l’époque, l’entreprise rejetait la faute sur les utilisateurs : « La porte-parole d’Anthropic, Gabby Curtis, a déclaré à Forbes que les conversations avec Claude n’étaient visibles que sur Google et Bing parce que les utilisateurs avaient publié des liens vers ces conversations en ligne ou sur les réseaux sociaux », expliquaient nos confrères.
Quatre incidents du même genre en seulement un an, le problème est récurrent. C’est l’occasion de rappeler une règle élémentaire : ne pas partager publiquement le lien d’un document que vous souhaitez garder pour vous. On pourrait même recommander de ne pas créer de lien de partage tout court afin de limiter les risques. Parfois, certains ne savent même pas que les documents sont accessibles publiquement, comme nous l’avons démontré avec des Google Groupes en accès libre aux quatre vents.
Il devait être testé lors de l’OTAN Coalition Warrior Interoperability Exercise mais n’a finalement pas été présenté. Que sait-on d’Arcadia, cette plateforme dopée à l’IA grâce à laquelle l’armée française compte se passer des services de Palantir, et aider ses alliés à faire de même ?
On se rappelle de la bataille de communication de juin dernier, lorsque Sébastien Lecornu annonçait l’abandon du « géant américain » par la Direction générale de la sécurité intérieure (DGSI), qui avait retenu à la place la solution française ChapsVision. La DGSI s’était elle-même déclarée surprise par l’annonce (elle avait renouvelé son contrat six mois plus tôt), avant que Palantir ne la conteste. En attendant, alors que les débats sur les enjeux de souveraineté numérique se multiplient, la France continue de se chercher des remplaçants au géant états-unien de la surveillance.
Avec Arcadia, elle teste un système de commandement dédié au champ de bataille, et recourant à divers systèmes d’intelligence artificielle. Fruit de la collaboration entre Mistral AI, Safran, Thales et Airbus, la plateforme de « commandement et contrôle » (C2) était testée courant juin lors de l’OTAN Coalition Warrior Interoperability Exercise, un exercice dédié aux essais de nouvelles technologies de communications entre les forces des alliés membres de l’Organisation du traité de l’Atlantique nord (OTAN).
Un système décentralisé
Il reste 79% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
Microsoft AI a présenté le 27 juillet 2026 son premier modèle dédié à la cybersécurité. Intégré dans son architecture, l’entreprise annonce battre tous les modèles actuels dans ce domaine, y compris Mythos d’Anthropic, mais attention à ce qui est réellement comparé.
Hier soir, Microsoft a annoncé officiellement MAI-Cyber-1-Flash. Il s’agit du tout premier LLM de l’éditeur consacré à la cybersécurité. Et pour un premier modèle, Microsoft a mis les petits plats dans les grands.
MAI-Cyber-1-Flash est un modèle compact, spécialisé dans le code et dérivé de la lignée MAI-Thinking-1, propre à Microsoft. Il est intégré à MDASH, le harnais multi-agents de détection et de remédiation de vulnérabilités déjà présenté par Microsoft en mai dernier. Plus récemment, l’entreprise est revenue sur le rôle prépondérant que joue désormais MDASH dans la sécurité de ses produits, expliquant l’envolée du nombre de failles corrigées dans les derniers bulletins mensuels : près de 200 en juin et plus de 570 en juillet.
Un modèle, un harnais…
Microsoft n’hésite pas à déclarer que son modèle, profondément intégré à MDASH, a été « perfectionné par les meilleurs experts en cybersécurité du secteur et renforcé dans le plus grand domaine de sécurité au monde ». Ce qui lui permet, toujours selon Microsoft, de battre tout le monde dans le domaine de la détection de failles, y compris Mythos, GPT 5.6 Sol, GPT 5.5 Cyber et Gemini 3.5 Flash Cyber. Avec 95,95 % au test CyberGym, Microsoft dépasse d’au moins 10 points la concurrence.
Mais attention, Microsoft ne compare pas directement son modèle MAI-Cyber-1-Flash aux autres : l’entreprise compare MDASH. Autrement dit, tout le harnais avec le nouveau modèle et GPT 5.4, utilisé en renfort.
Comme expliqué par l’éditeur en effet, MAI-Cyber-1-Flash est un modèle compact, conçu pour « gérer efficacement jusqu’à 90 % de toutes les tâches ». Dans cette configuration, MDASH ne basculerait vers les modèles plus gros et plus couteux (ici GPT 5.4) que dans 10 % des cas en moyenne, « pour les tâches exceptionnellement difficiles qui en ont réellement besoin ».
C’est bien cette architecture complète qui atteint près de 96 % sur CyberGym, battant Mythos de 12 points, insiste Microsoft. Rappelons que ces chiffres sont auto-rapportés et effectués dans un environnement contrôlé par Microsoft. Ils n’ont pas été vérifiés par un tiers indépendant.
Pour l’éditeur, c’est aussi une question d’économies substantielles. La meilleure offre MDASH combinait jusqu’à présent GPT 5.4 + 5.4 mini + codex 5.3. La nouvelle version intégrant MAI-Cyber-1-Flash coûterait moitié moins cher à faire tourner.
… et une plateforme
Mi-juillet, nous avions relayé un bruit de couloir : Microsoft préparait un projet nommé Perception pour venir concurrencer Anthropic et son projet Glasswing, seule manière de pouvoir utiliser Mythos.
Perception a bien été confirmé hier soir lui aussi. Il est présenté comme le système agentique qui vient chapeauter MAI-Cyber-1-Flash et MDASH. Le billet de blog dédié le présente comme une refonte de l’architecture de sécurité pour l’ère de l’IA : une nouvelle pile de sécurité doit percevoir en continu le risque sur l’ensemble du parc numérique, raisonner sur de vastes quantités de contexte et agir à vitesse machine, tout en apprenant et en s’adaptant à mesure que les environnements évoluent.
Le système coordonne trois familles d’agents spécialisés qui se transmettent le travail sans rupture de charge :
Les agents rouges repèrent les chemins de compromission potentiels avant qu’un attaquant ne puisse les exploiter
Les agents bleus enquêtent, évaluent le contexte et déterminent quels signaux représentent un risque réel
Les agents verts appliquent les correctifs et durcissent l’environnement (renforcent sa sécurité)
Ces agents ne repartent pas de zéro à chaque tâche. Ils s’appuient sur un contexte de sécurité partagé : une représentation mise à jour en continu des actifs, identités, relations et risques de l’organisation. Tous les agents puisent dans ce contexte, réduisant les coûts en tokens et la latence tout en améliorant la cohérence du raisonnement, selon Microsoft.
Un programme complet, mais très jeune
Un serveur MCP est également fourni pour exécuter les actions en ligne de commande. Les agents verts peuvent aussi ouvrir directement des pull requests sur GitHub et construire des correctifs potentiels pour les vulnérabilités. Perception propose donc un système de sécurité en apprentissage continu combinant capteurs, contexte partagé, modèles multiples, agents spécialisés et mécanismes d’action capables de modifier les protections à travers l’environnement.
Le programme se présente ainsi comme une couche d’orchestration, au-dessus de MAI-Cyber-1-Flash et MDASH, avec un déploiement encore très récent et une autonomie d’action volontairement limitée à ce stade. Microsoft insiste sur le maintien d’un humain dans la boucle décisionnelle, ce qui suggère que l’entreprise elle-même reste prudente sur le niveau de confiance à accorder aux agents verts capables de modifier des systèmes de production.
Perception n’est d’ailleurs pas disponible. Le premier accès se fera sous forme de préversion le 3 août et uniquement pour des clients MDASH triés sur le volet. Même une fois lancé en version finale, il est très probable que Perception ne soit accessible qu’au travers d’un accès vérifié, à la manière de Glasswing chez Anthropic ou de Daybreak chez OpenAI.
Microsoft AI a présenté le 27 juillet 2026 son premier modèle dédié à la cybersécurité. Intégré dans son architecture, l’entreprise annonce battre tous les modèles actuels dans ce domaine, y compris Mythos d’Anthropic, mais attention à ce qui est réellement comparé.
Hier soir, Microsoft a annoncé officiellement MAI-Cyber-1-Flash. Il s’agit du tout premier LLM de l’éditeur consacré à la cybersécurité. Et pour un premier modèle, Microsoft a mis les petits plats dans les grands.
MAI-Cyber-1-Flash est un modèle compact, spécialisé dans le code et dérivé de la lignée MAI-Thinking-1, propre à Microsoft. Il est intégré à MDASH, le harnais multi-agents de détection et de remédiation de vulnérabilités déjà présenté par Microsoft en mai dernier. Plus récemment, l’entreprise est revenue sur le rôle prépondérant que joue désormais MDASH dans la sécurité de ses produits, expliquant l’envolée du nombre de failles corrigées dans les derniers bulletins mensuels : près de 200 en juin et plus de 570 en juillet.
Un modèle, un harnais…
Microsoft n’hésite pas à déclarer que son modèle, profondément intégré à MDASH, a été « perfectionné par les meilleurs experts en cybersécurité du secteur et renforcé dans le plus grand domaine de sécurité au monde ». Ce qui lui permet, toujours selon Microsoft, de battre tout le monde dans le domaine de la détection de failles, y compris Mythos, GPT 5.6 Sol, GPT 5.5 Cyber et Gemini 3.5 Flash Cyber. Avec 95,95 % au test CyberGym, Microsoft dépasse d’au moins 10 points la concurrence.
Mais attention, Microsoft ne compare pas directement son modèle MAI-Cyber-1-Flash aux autres : l’entreprise compare MDASH. Autrement dit, tout le harnais avec le nouveau modèle et GPT 5.4, utilisé en renfort.
Comme expliqué par l’éditeur en effet, MAI-Cyber-1-Flash est un modèle compact, conçu pour « gérer efficacement jusqu’à 90 % de toutes les tâches ». Dans cette configuration, MDASH ne basculerait vers les modèles plus gros et plus couteux (ici GPT 5.4) que dans 10 % des cas en moyenne, « pour les tâches exceptionnellement difficiles qui en ont réellement besoin ».
C’est bien cette architecture complète qui atteint près de 96 % sur CyberGym, battant Mythos de 12 points, insiste Microsoft. Rappelons que ces chiffres sont auto-rapportés et effectués dans un environnement contrôlé par Microsoft. Ils n’ont pas été vérifiés par un tiers indépendant.
Pour l’éditeur, c’est aussi une question d’économies substantielles. La meilleure offre MDASH combinait jusqu’à présent GPT 5.4 + 5.4 mini + codex 5.3. La nouvelle version intégrant MAI-Cyber-1-Flash coûterait moitié moins cher à faire tourner.
… et une plateforme
Mi-juillet, nous avions relayé un bruit de couloir : Microsoft préparait un projet nommé Perception pour venir concurrencer Anthropic et son projet Glasswing, seule manière de pouvoir utiliser Mythos.
Perception a bien été confirmé hier soir lui aussi. Il est présenté comme le système agentique qui vient chapeauter MAI-Cyber-1-Flash et MDASH. Le billet de blog dédié le présente comme une refonte de l’architecture de sécurité pour l’ère de l’IA : une nouvelle pile de sécurité doit percevoir en continu le risque sur l’ensemble du parc numérique, raisonner sur de vastes quantités de contexte et agir à vitesse machine, tout en apprenant et en s’adaptant à mesure que les environnements évoluent.
Le système coordonne trois familles d’agents spécialisés qui se transmettent le travail sans rupture de charge :
Les agents rouges repèrent les chemins de compromission potentiels avant qu’un attaquant ne puisse les exploiter
Les agents bleus enquêtent, évaluent le contexte et déterminent quels signaux représentent un risque réel
Les agents verts appliquent les correctifs et durcissent l’environnement (renforcent sa sécurité)
Ces agents ne repartent pas de zéro à chaque tâche. Ils s’appuient sur un contexte de sécurité partagé : une représentation mise à jour en continu des actifs, identités, relations et risques de l’organisation. Tous les agents puisent dans ce contexte, réduisant les coûts en tokens et la latence tout en améliorant la cohérence du raisonnement, selon Microsoft.
Un programme complet, mais très jeune
Un serveur MCP est également fourni pour exécuter les actions en ligne de commande. Les agents verts peuvent aussi ouvrir directement des pull requests sur GitHub et construire des correctifs potentiels pour les vulnérabilités. Perception propose donc un système de sécurité en apprentissage continu combinant capteurs, contexte partagé, modèles multiples, agents spécialisés et mécanismes d’action capables de modifier les protections à travers l’environnement.
Le programme se présente ainsi comme une couche d’orchestration, au-dessus de MAI-Cyber-1-Flash et MDASH, avec un déploiement encore très récent et une autonomie d’action volontairement limitée à ce stade. Microsoft insiste sur le maintien d’un humain dans la boucle décisionnelle, ce qui suggère que l’entreprise elle-même reste prudente sur le niveau de confiance à accorder aux agents verts capables de modifier des systèmes de production.
Perception n’est d’ailleurs pas disponible. Le premier accès se fera sous forme de préversion le 3 août et uniquement pour des clients MDASH triés sur le volet. Même une fois lancé en version finale, il est très probable que Perception ne soit accessible qu’au travers d’un accès vérifié, à la manière de Glasswing chez Anthropic ou de Daybreak chez OpenAI.
Orange veut partager le fardeau de ses datacenters. L’opérateur historique a ainsi annoncé la création d’une coentreprise avec Morrison, une société néo-zélandaise spécialisée dans les infrastructures, qui aura pour mission de décupler la capacité totale des datacenters Orange – soit un total de 400 MW.
Une progression impressionnante qui nécessite la construction de nouveaux bâtiments. Morrison est précisément là pour ses capitaux et sa capacité à lever de la dette. Orange, de son côté, apporte cinq de ses principaux centres de données répartis sur quatre campus en France (Chevilly-Larue, Aubervilliers, Chartres et Val-de-Reuil), ainsi que son expertise opérationnelle, les terrains, les bâtiments, et les clients. Orange Business dispose pour rappel d’une qualification SecNumCloud de l’ANSSI dans son datacenter de Grenoble, qui n’est pas dans cette liste.
Image : Morrison
Orange Business sera le partenaire exclusif pour la commercialisation des offres de colocation et d’hébergement auprès des grandes entreprises, des PME et des acteurs du secteur public. Ces infrastructures serviront également aux solutions infonuagiques et IA de la filière pro d’Orange. L’opérateur conserve par ailleurs le contrôle opérationnel des espaces dédiés à ses propres activités, qui resteront hébergés dans ses datacenters. L’entreprise peut ainsi affirmer :
« Cela garantirait aux clients d’Orange et d’Orange Business un niveau de sécurité et de disponibilité des systèmes hébergés et des données associées conforme aux standards nationaux et européens les plus exigeants. »
« Ce projet de coentreprise avec Morrison nous permettrait de révéler la valeur de nos actifs existants et de renforcer notre position dans les data centers », explique Christel Heydemann, directrice générale du groupe Orange. C’est aussi un moyen de créer les « infrastructures numériques souveraines et de confiance » dont la France a besoin, selon elle.
« Avec Orange, nous envisageons la création d’une plateforme associant des actifs d’infrastructure stratégiques, une expertise opérationnelle et des capitaux de long terme pour répondre à cet enjeu », rebondit William Smales, directeur des investissements de Morrison. Un investissement de 3 milliards d’euros est sur la table, financé par les deux partenaires. La création de la coentreprise, détenue à 50/50, est attendue pour le premier semestre de l’année prochaine.
Orange s’interrogeait depuis un moment pour valoriser ses datacenters, des actifs qui jusqu’à présent étaient noyés dans les comptes du groupe. Une coentreprise a cet avantage de pouvoir accueillir de nouveaux capitaux et de pouvoir s’endetter sans que l’opérateur n’ait tout à financer.
La rumeur courait depuis quelques semaines que Morrison était en tête de liste des partenaires possibles, avec Vauban Infrastructure Partners et Macquarie, comme le relevait récemment DCmag. La prise de participation de la société permettrait à Orange d’encaisser de 400 à 500 millions d’euros. Pour l’opérateur, ce serait de l’argent qui servirait au financement d’autres investissements dans l’IA et le numérique.
Orange veut partager le fardeau de ses datacenters. L’opérateur historique a ainsi annoncé la création d’une coentreprise avec Morrison, une société néo-zélandaise spécialisée dans les infrastructures, qui aura pour mission de décupler la capacité totale des datacenters Orange – soit un total de 400 MW.
Une progression impressionnante qui nécessite la construction de nouveaux bâtiments. Morrison est précisément là pour ses capitaux et sa capacité à lever de la dette. Orange, de son côté, apporte cinq de ses principaux centres de données répartis sur quatre campus en France (Chevilly-Larue, Aubervilliers, Chartres et Val-de-Reuil), ainsi que son expertise opérationnelle, les terrains, les bâtiments, et les clients. Orange Business dispose pour rappel d’une qualification SecNumCloud de l’ANSSI dans son datacenter de Grenoble, qui n’est pas dans cette liste.
Image : Morrison
Orange Business sera le partenaire exclusif pour la commercialisation des offres de colocation et d’hébergement auprès des grandes entreprises, des PME et des acteurs du secteur public. Ces infrastructures serviront également aux solutions infonuagiques et IA de la filière pro d’Orange. L’opérateur conserve par ailleurs le contrôle opérationnel des espaces dédiés à ses propres activités, qui resteront hébergés dans ses datacenters. L’entreprise peut ainsi affirmer :
« Cela garantirait aux clients d’Orange et d’Orange Business un niveau de sécurité et de disponibilité des systèmes hébergés et des données associées conforme aux standards nationaux et européens les plus exigeants. »
« Ce projet de coentreprise avec Morrison nous permettrait de révéler la valeur de nos actifs existants et de renforcer notre position dans les data centers », explique Christel Heydemann, directrice générale du groupe Orange. C’est aussi un moyen de créer les « infrastructures numériques souveraines et de confiance » dont la France a besoin, selon elle.
« Avec Orange, nous envisageons la création d’une plateforme associant des actifs d’infrastructure stratégiques, une expertise opérationnelle et des capitaux de long terme pour répondre à cet enjeu », rebondit William Smales, directeur des investissements de Morrison. Un investissement de 3 milliards d’euros est sur la table, financé par les deux partenaires. La création de la coentreprise, détenue à 50/50, est attendue pour le premier semestre de l’année prochaine.
Orange s’interrogeait depuis un moment pour valoriser ses datacenters, des actifs qui jusqu’à présent étaient noyés dans les comptes du groupe. Une coentreprise a cet avantage de pouvoir accueillir de nouveaux capitaux et de pouvoir s’endetter sans que l’opérateur n’ait tout à financer.
La rumeur courait depuis quelques semaines que Morrison était en tête de liste des partenaires possibles, avec Vauban Infrastructure Partners et Macquarie, comme le relevait récemment DCmag. La prise de participation de la société permettrait à Orange d’encaisser de 400 à 500 millions d’euros. Pour l’opérateur, ce serait de l’argent qui servirait au financement d’autres investissements dans l’IA et le numérique.
Le 21 juillet, OpenAI a publié un communiqué étonnant : un de ses systèmes IA était responsable de l’attaque orchestrée contre Hugging Face. Des détails étaient fournis, mais l’histoire gardait des zones d’ombre. Si l’incident a été transformé en opportunité commerciale, il semble être le résultat d’une vaste carence en sécurité.
Dans notre article du 22 juillet, nous relations les évènements tels qu’ils ont été décrits par OpenAI et Hugging Face. Dans les grandes lignes, la plateforme open source dédiée à l’IA avait révélé le 16 juillet avoir été attaqué par au moins un agent IA autonome. Cinq jours plus tard, OpenAI communiquait pour annoncer être indirectement à l’origine de l’attaque.
Illustration : Flock
Que s’était-il passé ? OpenAI avait expliqué que des tests étaient en cours sur un système d’IA comprenant le récent modèle GPT-5.6 Sol ainsi qu’un autre, décrit comme simplement plus puissant. Dans ces tests, les garde-fous avaient été levés pour mesurer justement les capacités des modèles.
L’un des tests demandait aux modèles de résoudre un certain problème. Ces derniers avaient estimé que la réponse se trouvait probablement chez Hugging Face. Ils s’étaient alors échappés de leur environnement de test (révélant au passage une faille signalée à l’éditeur tiers concerné), avaient récupéré des identifiants de membres du personnel de Hugging Face et fouillé dans l’infrastructure de l’entreprise, compromettant au passage une partie des serveurs.
Une semaine pour s’en apercevoir
L’histoire comportait de nombreuses zones d’ombre. Nous relevions par exemple qu’il s’était écoulé cinq jours entre la présentation de l’attaque par Hugging Face et le communiqué d’OpenAI sur ce qui s’était passé. Cette dernière n’avait-elle donc découvert l’incident qu’avec le billet de Hugging Face ? Selon Reuters, ce serait bien le cas.
Selon nos confrères, la chronologie ne plaide pas en faveur d’OpenAI. L’agent se serait ainsi échappé de son environnement de test le 9 juillet et aurait commencé son intrusion chez Hugging Face le 11. OpenAI n’aurait compris la responsabilité de son système qu’à la publication du billet de Hugging Face le 16 juillet. Des membres du personnel n’auraient commencé à trouver des traces d’activité suspecte dans les journaux internes que durant le week-end du 18 - 19 juillet. Les deux entreprises ne se seraient pas parlées avant le 20 juillet, aboutissant à la communication publique du 21 juillet.
Reuters évoque deux sources proches du dossier, selon lesquelles il se serait donc écoulé une semaine avant qu’OpenAI s’aperçoive de sa responsabilité, entre la sortie de l’agent le 9 juillet et le billet de Hugging Face le 16.
Comment expliquer une telle latence ? Cette lenteur s’expliquerait par le fait qu’OpenAI fait tourner plusieurs tests simultanément, rendant difficile pour les employés la surveillance individuelle de chaque test, tant la masse de données générées est importante. Reuters apporte d’autres informations, notamment la création par un agent d’une note destinée à de futures versions de lui-même et contenant des instructions sur la manière de s’échapper des contraintes imposées par OpenAI. En revanche, l’article ne dit pas si cet agent en particulier est lié à l’attaque.
Autre point important, Hugging Face avait évoqué un contact avec les forces de l’ordre. D’après l’agence de presse, il s’agit bien du FBI qui n’a pas souhaité réagir. Silence également de la part de la plateforme. Chez OpenAI, une porte-parole a déclaré que l’article de Reuters contenait « plusieurs inexactitudes », mais n’a pas répondu aux demandes de détails.
Le 21 juillet, OpenAI a publié un communiqué étonnant : un de ses systèmes IA était responsable de l’attaque orchestrée contre Hugging Face. Des détails étaient fournis, mais l’histoire gardait des zones d’ombre. Si l’incident a été transformé en opportunité commerciale, il semble être le résultat d’une vaste carence en sécurité.
Dans notre article du 22 juillet, nous relations les évènements tels qu’ils ont été décrits par OpenAI et Hugging Face. Dans les grandes lignes, la plateforme open source dédiée à l’IA avait révélé le 16 juillet avoir été attaqué par au moins un agent IA autonome. Cinq jours plus tard, OpenAI communiquait pour annoncer être indirectement à l’origine de l’attaque.
Illustration : Flock
Que s’était-il passé ? OpenAI avait expliqué que des tests étaient en cours sur un système d’IA comprenant le récent modèle GPT-5.6 Sol ainsi qu’un autre, décrit comme simplement plus puissant. Dans ces tests, les garde-fous avaient été levés pour mesurer justement les capacités des modèles.
L’un des tests demandait aux modèles de résoudre un certain problème. Ces derniers avaient estimé que la réponse se trouvait probablement chez Hugging Face. Ils s’étaient alors échappés de leur environnement de test (révélant au passage une faille signalée à l’éditeur tiers concerné), avaient récupéré des identifiants de membres du personnel de Hugging Face et fouillé dans l’infrastructure de l’entreprise, compromettant au passage une partie des serveurs.
Une semaine pour s’en apercevoir
L’histoire comportait de nombreuses zones d’ombre. Nous relevions par exemple qu’il s’était écoulé cinq jours entre la présentation de l’attaque par Hugging Face et le communiqué d’OpenAI sur ce qui s’était passé. Cette dernière n’avait-elle donc découvert l’incident qu’avec le billet de Hugging Face ? Selon Reuters, ce serait bien le cas.
Selon nos confrères, la chronologie ne plaide pas en faveur d’OpenAI. L’agent se serait ainsi échappé de son environnement de test le 9 juillet et aurait commencé son intrusion chez Hugging Face le 11. OpenAI n’aurait compris la responsabilité de son système qu’à la publication du billet de Hugging Face le 16 juillet. Des membres du personnel n’auraient commencé à trouver des traces d’activité suspecte dans les journaux internes que durant le week-end du 18 - 19 juillet. Les deux entreprises ne se seraient pas parlées avant le 20 juillet, aboutissant à la communication publique du 21 juillet.
Reuters évoque deux sources proches du dossier, selon lesquelles il se serait donc écoulé une semaine avant qu’OpenAI s’aperçoive de sa responsabilité, entre la sortie de l’agent le 9 juillet et le billet de Hugging Face le 16.
Comment expliquer une telle latence ? Cette lenteur s’expliquerait par le fait qu’OpenAI fait tourner plusieurs tests simultanément, rendant difficile pour les employés la surveillance individuelle de chaque test, tant la masse de données générées est importante. Reuters apporte d’autres informations, notamment la création par un agent d’une note destinée à de futures versions de lui-même et contenant des instructions sur la manière de s’échapper des contraintes imposées par OpenAI. En revanche, l’article ne dit pas si cet agent en particulier est lié à l’attaque.
Autre point important, Hugging Face avait évoqué un contact avec les forces de l’ordre. D’après l’agence de presse, il s’agit bien du FBI qui n’a pas souhaité réagir. Silence également de la part de la plateforme. Chez OpenAI, une porte-parole a déclaré que l’article de Reuters contenait « plusieurs inexactitudes », mais n’a pas répondu aux demandes de détails.
Le 24 juillet, l’Arcep a annoncé l’ouverture d’une consultation publique pour élargir sa collecte de données environnementales, en perspective de l’édition 2028 de son enquête annuelle « Pour un numérique soutenable », à la suite d’une campagne de collecte qui aurait donc lieu en 2027.
Rappelons que depuis 2020, l’Arcep collecte des indicateurs environnementaux auprès des acteurs du numérique, mission formalisée par le gouvernement l’année suivante et consolidée juridiquement par la loi REEN de décembre 2021. L’autorité dispose ainsi d’un pouvoir de collecte auprès des opérateurs télécoms, fournisseurs de services de communication en ligne, opérateurs de centres de données, fabricants de terminaux, équipementiers réseaux et fournisseurs de systèmes d’exploitation.
Les données recueillies sont présentées depuis, chaque année, dans ses rapports sur le numérique soutenable. En mars 2024 par exemple, le rapport incluait pour la première fois des informations sur la consommation des box, décodeurs et répéteurs.
Illustration : Flock
Dès l’automne dernier, l’autorité avait cependant annoncé sa volonté de capter de nouvelles informations pour mesurer l’impact environnemental de l’IA. C’est l’objet de la nouvelle consultation publique, avec deux extensions principales au recueil de données.
Chez les fournisseurs d’IA générative d’abord, l’Arcep propose de collecter des indicateurs permettant d’évaluer les émissions de gaz à effet de serre associées, de documenter les caractéristiques des modèles sous-jacents aux services les plus utilisés en France, et de mesurer les ressources mobilisées en entraînement et en inférence : volume de calcul, temps cumulé d’usage des processeurs et consommation énergétique.
Chez les opérateurs de centres de données et fournisseurs de services cloud, les nouveaux indicateurs serviraient à vérifier comment la chaleur est valorisée, à évaluer l’influence des systèmes de refroidissement sur l’empreinte environnementale des centres de données et à couvrir les obligations du règlement délégué (UE) 2024/1364, en application de la directive européenne sur l’efficacité énergétique (directive UE 2023/1791, dite EED), qui pose l’obligation de reporting pour les centres de données.
La consultation publique est ouverte à toutes les parties prenantes jusqu’au 30 septembre. La décision finale de collecte est attendue d’ici fin 2026, sous réserve d’homologation par la ministre déléguée chargée de l’IA et du numérique.
Le 24 juillet, l’Arcep a annoncé l’ouverture d’une consultation publique pour élargir sa collecte de données environnementales, en perspective de l’édition 2028 de son enquête annuelle « Pour un numérique soutenable », à la suite d’une campagne de collecte qui aurait donc lieu en 2027.
Rappelons que depuis 2020, l’Arcep collecte des indicateurs environnementaux auprès des acteurs du numérique, mission formalisée par le gouvernement l’année suivante et consolidée juridiquement par la loi REEN de décembre 2021. L’autorité dispose ainsi d’un pouvoir de collecte auprès des opérateurs télécoms, fournisseurs de services de communication en ligne, opérateurs de centres de données, fabricants de terminaux, équipementiers réseaux et fournisseurs de systèmes d’exploitation.
Les données recueillies sont présentées depuis, chaque année, dans ses rapports sur le numérique soutenable. En mars 2024 par exemple, le rapport incluait pour la première fois des informations sur la consommation des box, décodeurs et répéteurs.
Illustration : Flock
Dès l’automne dernier, l’autorité avait cependant annoncé sa volonté de capter de nouvelles informations pour mesurer l’impact environnemental de l’IA. C’est l’objet de la nouvelle consultation publique, avec deux extensions principales au recueil de données.
Chez les fournisseurs d’IA générative d’abord, l’Arcep propose de collecter des indicateurs permettant d’évaluer les émissions de gaz à effet de serre associées, de documenter les caractéristiques des modèles sous-jacents aux services les plus utilisés en France, et de mesurer les ressources mobilisées en entraînement et en inférence : volume de calcul, temps cumulé d’usage des processeurs et consommation énergétique.
Chez les opérateurs de centres de données et fournisseurs de services cloud, les nouveaux indicateurs serviraient à vérifier comment la chaleur est valorisée, à évaluer l’influence des systèmes de refroidissement sur l’empreinte environnementale des centres de données et à couvrir les obligations du règlement délégué (UE) 2024/1364, en application de la directive européenne sur l’efficacité énergétique (directive UE 2023/1791, dite EED), qui pose l’obligation de reporting pour les centres de données.
La consultation publique est ouverte à toutes les parties prenantes jusqu’au 30 septembre. La décision finale de collecte est attendue d’ici fin 2026, sous réserve d’homologation par la ministre déléguée chargée de l’IA et du numérique.
La pression monte autour de Kimi K3, le modèle IA chinois de Moonshot AI dont les poids doivent être publiés ce 27 juillet. L’ouverture du LLM est aux antipodes des modèles fermés et propriétaires des champions américains du secteur – et que Washington veut protéger à tout prix. Deux visions du monde s’opposent ici, et plusieurs acteurs parmi les plus importants de cette industrie ont pris position en faveur de l’open source.
Dans une lettre ouverte (PDF), plusieurs acteurs très importants de l’IA défendent les modèles à poids ouverts comme Kimi K3. « [Ils] renforcent la sûreté et la cybersécurité, accélèrent l’innovation et sa diffusion, et favorisent la souveraineté », affirme ainsi Jensen Huang, fondateur et patron de NVIDIA dans son premier post sur X. Pour le dirigeant, « le monde a besoin à la fois de modèles fermés de pointe et de modèles ouverts de pointe. »
Au secours des modèles ouverts
La lettre en question est donc signée NVIDIA, mais aussi Microsoft, Mozilla, Meta (qui a pourtant arrêté de publier des modèles open source depuis Muse), Mistral, Hugging Face, Perplexity, Palantir, Dell, IBM, la Linux Foundation, Box, Crowdstrike… Le texte rappelle le rôle essentiel des logiciels open source qui font fonctionner une grande partie d’internet et « au cœur de systèmes » utilisés par les organisations les plus importantes au monde.
Les signataires listent les (nombreux, à leurs yeux) avantages des modèles ouverts : d’abord, ils offrent un accès élargi à l’IA. Les entreprises, les universités, les administrations et les startups peuvent utiliser ces modèles sans devoir les entraîner eux-mêmes ni payer des fortunes dans des modèles propriétaires. Ce qui permet aussi de maîtriser les coûts, tout en adaptant les capacités de ces modèles aux tâches à effectuer. L’exécution en interne permet également un contrôle total sur les données.
En termes de concurrence, les modèles à poids ouverts réduisent la dépendance à une poignée de fournisseurs. Ils représentent également un soutien à la souveraineté technologique et une plus grande transparence pour la recherche. En retour, la sécurité autour de ces modèles est collectivement renforcée.
Les risques de l’ouverture
La lettre ne cache pas les risques liés aux modèles ouverts. Il existe une perte de contrôle après la publication, puisque les concepteurs ne peuvent pas empêcher l’utilisation, la copie et la modification de leurs modèles. Ces derniers peuvent aussi faciliter les attaques informatiques, produire des contenus trompeurs ou contourner des protections. La multiplication de versions spécialisées peut également compliquer les mises à jour de sécurité et le maintien de standards cohérents.
Sur un plan plus pragmatique, télécharger les poids ne suffit pas : il faut disposer d’une solide infrastructure pour les faire tourner et les sécuriser. Enfin, se pose la question toujours délicate de la distillation de ces modèles ; un des angles d’attaque de la Maison-Blanche contre Kimi K3 est précisément une accusation de distillation de Fable 5.
Les signataires présentent la distillation comme une technique légitime et courante dans le développement de l’IA. Elle exploite les réponses produites par un modèle pour entraîner, améliorer, évaluer ou valider un autre modèle. Par conséquent, la distillation en elle-même ne devrait pas être assimilée à du vol ou à une appropriation abusive ; en revanche, les tentatives illégales soulèvent de vraies questions juridiques. Ils recommandent aux pouvoirs publics d’éviter des interdictions générales de la distillation. Les abus éventuels devraient être traités par des règles juridiques et commerciales ciblées, car cette technique est jugée essentielle pour améliorer les LLM.
Trois fois plus de signataires ce week-end, avec OpenAI, Google, AMD
La liste initiale comprenait 25 signatures : American Innovators Network, Andreessen Horowitz, Arcee AI, Arena, Black Forest Labs, Box, CrowdStrike, Dell Technologies, Emergence Capital, Hugging Face, IBM, The Linux Foundation, Mariana Minerals, Meta, Microsoft, Mistral, Mozilla, NVIDIA, Palantir, Perplexity, Reflection, Replit, ServiceNow, Telnyx et Y Combinator.
OpenAI, Google, Anthropic… : des acteurs de poids étaient absents. Sam Altman indiquait qu’il voulait que les États-Unis « gagnent » dans l’IA, « aussi bien avec les modèles open source qu’avec les modèles propriétaires ». Le CEO d’OpenAI affirme aussi être « heureux » de voir cette initiative en faveur des modèles ouverts. OpenAI a finalement signé la lettre, et ce n’est pas la seule entreprise à rejoindre l’initiative en cours de route.
La liste a rapidement triplé pour arriver aujourd’hui à près de 80 signataires, avec Google, AMD, Cisco, Cloudflare, GitHub, SpaceX, Palo Alto Networks, Ollama, etc. Parmi les absences notables, il reste Amazon et Anthropic.
La pression monte autour de Kimi K3, le modèle IA chinois de Moonshot AI dont les poids doivent être publiés ce 27 juillet. L’ouverture du LLM est aux antipodes des modèles fermés et propriétaires des champions américains du secteur – et que Washington veut protéger à tout prix. Deux visions du monde s’opposent ici, et plusieurs acteurs parmi les plus importants de cette industrie ont pris position en faveur de l’open source.
Dans une lettre ouverte (PDF), plusieurs acteurs très importants de l’IA défendent les modèles à poids ouverts comme Kimi K3. « [Ils] renforcent la sûreté et la cybersécurité, accélèrent l’innovation et sa diffusion, et favorisent la souveraineté », affirme ainsi Jensen Huang, fondateur et patron de NVIDIA dans son premier post sur X. Pour le dirigeant, « le monde a besoin à la fois de modèles fermés de pointe et de modèles ouverts de pointe. »
Au secours des modèles ouverts
La lettre en question est donc signée NVIDIA, mais aussi Microsoft, Mozilla, Meta (qui a pourtant arrêté de publier des modèles open source depuis Muse), Mistral, Hugging Face, Perplexity, Palantir, Dell, IBM, la Linux Foundation, Box, Crowdstrike… Le texte rappelle le rôle essentiel des logiciels open source qui font fonctionner une grande partie d’internet et « au cœur de systèmes » utilisés par les organisations les plus importantes au monde.
Les signataires listent les (nombreux, à leurs yeux) avantages des modèles ouverts : d’abord, ils offrent un accès élargi à l’IA. Les entreprises, les universités, les administrations et les startups peuvent utiliser ces modèles sans devoir les entraîner eux-mêmes ni payer des fortunes dans des modèles propriétaires. Ce qui permet aussi de maîtriser les coûts, tout en adaptant les capacités de ces modèles aux tâches à effectuer. L’exécution en interne permet également un contrôle total sur les données.
En termes de concurrence, les modèles à poids ouverts réduisent la dépendance à une poignée de fournisseurs. Ils représentent également un soutien à la souveraineté technologique et une plus grande transparence pour la recherche. En retour, la sécurité autour de ces modèles est collectivement renforcée.
Les risques de l’ouverture
La lettre ne cache pas les risques liés aux modèles ouverts. Il existe une perte de contrôle après la publication, puisque les concepteurs ne peuvent pas empêcher l’utilisation, la copie et la modification de leurs modèles. Ces derniers peuvent aussi faciliter les attaques informatiques, produire des contenus trompeurs ou contourner des protections. La multiplication de versions spécialisées peut également compliquer les mises à jour de sécurité et le maintien de standards cohérents.
Sur un plan plus pragmatique, télécharger les poids ne suffit pas : il faut disposer d’une solide infrastructure pour les faire tourner et les sécuriser. Enfin, se pose la question toujours délicate de la distillation de ces modèles ; un des angles d’attaque de la Maison-Blanche contre Kimi K3 est précisément une accusation de distillation de Fable 5.
Les signataires présentent la distillation comme une technique légitime et courante dans le développement de l’IA. Elle exploite les réponses produites par un modèle pour entraîner, améliorer, évaluer ou valider un autre modèle. Par conséquent, la distillation en elle-même ne devrait pas être assimilée à du vol ou à une appropriation abusive ; en revanche, les tentatives illégales soulèvent de vraies questions juridiques. Ils recommandent aux pouvoirs publics d’éviter des interdictions générales de la distillation. Les abus éventuels devraient être traités par des règles juridiques et commerciales ciblées, car cette technique est jugée essentielle pour améliorer les LLM.
Trois fois plus de signataires ce week-end, avec OpenAI, Google, AMD
La liste initiale comprenait 25 signatures : American Innovators Network, Andreessen Horowitz, Arcee AI, Arena, Black Forest Labs, Box, CrowdStrike, Dell Technologies, Emergence Capital, Hugging Face, IBM, The Linux Foundation, Mariana Minerals, Meta, Microsoft, Mistral, Mozilla, NVIDIA, Palantir, Perplexity, Reflection, Replit, ServiceNow, Telnyx et Y Combinator.
OpenAI, Google, Anthropic… : des acteurs de poids étaient absents. Sam Altman indiquait qu’il voulait que les États-Unis « gagnent » dans l’IA, « aussi bien avec les modèles open source qu’avec les modèles propriétaires ». Le CEO d’OpenAI affirme aussi être « heureux » de voir cette initiative en faveur des modèles ouverts. OpenAI a finalement signé la lettre, et ce n’est pas la seule entreprise à rejoindre l’initiative en cours de route.
La liste a rapidement triplé pour arriver aujourd’hui à près de 80 signataires, avec Google, AMD, Cisco, Cloudflare, GitHub, SpaceX, Palo Alto Networks, Ollama, etc. Parmi les absences notables, il reste Amazon et Anthropic.
Une discussion a été ouverte au sein du projet sur la manière dont il faut considérer les participations au code quand elles sont soutenues par les LLM. Ce n’est pas la première fois que la communauté essaie de statuer sur l’IA générative.
Debian a ouvert une résolution générale (GR) sur l’usage des LLM au sein du projet. La période de discussion a débuté le 24 juillet 2026, après des semaines de débat sur la liste de diffusion debian-vote.
Ce n’est pas la première tentative sur ce sujet. Une précédente discussion menée par l’ex-DPL (Debian Project Leader) Lucas Nussbaum, en février-mars 2026, s’était soldée par un abandon du vote, la communauté ayant préféré continuer à traiter les contributions IA au cas par cas. Le projet Debian avait décidé de ne pas décider. Cette résolution relance donc le débat avec un texte plus structuré et davantage de propositions.
Quatre propositions, du radical au plus mesuré
La proposition A, portée par Matthias Geiger et Jesse Rhodes, est la plus radicale : l’interdiction de toute contribution directe rédigée avec l’aide de LLM : paquets sources, logiciels officiels (lintian, etc.), ressources web, documentation, traductions, communications officielles. Les projets amont utilisant l’IA, ainsi que les correctifs de sécurité amont, sont exclus du périmètre. Le texte propose même d’ajouter un point 6 au Contrat Social de Debian sur le sujet.
Plusieurs arguments sont donnés. D’abord, le statut juridique flou du copyright des sorties de LLM. Ensuite, des problèmes de qualité (paquets mal formés, fichiers watch non fonctionnels). En outre, un impact sur la dynamique communautaire : charge de relecture, non-apprentissage des nouveaux contributeurs, etc. Enfin, la question éthique, le scraping massif ayant perturbé l’infrastructure web de Debian et la question de l’empreinte environnementale étant prégnante.
La proposition B, portée par l’ancien DPL, Lucas Nussbaum, est plus mesurée. Elle autorise les contributions assistées par IA sous six conditions cumulatives :
compatibilité légale de l’outil utilisé
vérification des droits sur le contenu préexistant réutilisé
responsabilité totale du contributeur
divulgation de l’usage via un tag Git type Generated-By: ou Assisted-By:
discussion préalable pour les modifications massives ou automatisées
interdiction de transmettre des données sensibles (rapports de sécurité sous embargo, discussions privées) à des fournisseurs IA non fiables
La proposition C, portée par Ian Jackson, est un rejet de principe mais « pragmatique ». Elle demande à tous les contributeurs d’éviter les LLM et appelle plus largement la communauté du logiciel libre à rejeter cette technologie, tout en reconnaissant qu’une interdiction totale est impraticable puisque de nombreux projets amont y recourent. Il propose cependant des règles strictes : les messages destinés aux humains (rapports de bugs, listes de diffusion, Salsa, blogs Planet Debian) doivent être rédigés uniquement par des humains, tout usage de LLM doit être divulgué, les mainteneurs individuels peuvent totalement bannir l’IA sur leurs projets. Et la plus stricte d’entre elles : les violations sont traitées comme des manquements au Code de Conduite.
Quant à la proposition D, portée par Pierre-Elliott Bécue, elle ressemble beaucoup à la B dans l’esprit : une acceptation encadrée, portée sur les responsabilités. En clair, Debian n’endosse pas l’usage de l’IA générative mais reconnaît sa réalité et refuse une interdiction jugée « contre-productive et inapplicable ». Cette proposition place la responsabilité sur le contributeur (conformité DFSG, signature GPG personnelle, marquage de l’usage IA dans les commits et notes de version), avec une clause spécifique interdisant l’usage d’IA cloud pour des données sensibles ou non publiques.
Une décision importante
Plusieurs éléments intéressants entourant cette nouvelle résolution générale. D’abord, la proximité avec l’ancienne : à peine quelques mois, signalant le besoin pour les développeurs de trancher un sujet devenu central. L’IA générative est partout et les LLM sont utilisés dans une part croissante des projets. Précisons quand même que la précédente discussion en février-mars n’a pas atteint le statut officiel de GR. Il s’est écoulé environ un mois entre le brouillon alors préparé par Lucas Nussbaum et l’abandon du processus.
On ne sait pas combien de temps durera la résolution générale, mais la discussion et le vote seront importants. Debian n’est pas n’importe quelle distribution : en plus de son utilisation proprement dite, elle sert de socle à de nombreux autres systèmes, dont le plus connu est Ubuntu, la distribution Linux la plus utilisée aujourd’hui. Ce qui n’empêche pas d’autres organisations, comme Canonical, de procéder à des modifications assistées par IA.
Cette résolution cristallise de nombreux aspects entourant les LLM. Le fait que les questions éthiques et environnementales fassent partie de la réflexion est significatif, mais le sujet est complexe : comment trancher entre une interrogation croissante sur les gains potentiels et les conséquences négatives d’une utilisation intensive ? Si les membres du projet Debian regardent en direction de Linus Torvalds, une proposition B ou D pourrait l’emporter : une vision pragmatique et responsabilisée des contributions.
Une discussion a été ouverte au sein du projet sur la manière dont il faut considérer les participations au code quand elles sont soutenues par les LLM. Ce n’est pas la première fois que la communauté essaie de statuer sur l’IA générative.
Debian a ouvert une résolution générale (GR) sur l’usage des LLM au sein du projet. La période de discussion a débuté le 24 juillet 2026, après des semaines de débat sur la liste de diffusion debian-vote.
Ce n’est pas la première tentative sur ce sujet. Une précédente discussion menée par l’ex-DPL (Debian Project Leader) Lucas Nussbaum, en février-mars 2026, s’était soldée par un abandon du vote, la communauté ayant préféré continuer à traiter les contributions IA au cas par cas. Le projet Debian avait décidé de ne pas décider. Cette résolution relance donc le débat avec un texte plus structuré et davantage de propositions.
Quatre propositions, du radical au plus mesuré
La proposition A, portée par Matthias Geiger et Jesse Rhodes, est la plus radicale : l’interdiction de toute contribution directe rédigée avec l’aide de LLM : paquets sources, logiciels officiels (lintian, etc.), ressources web, documentation, traductions, communications officielles. Les projets amont utilisant l’IA, ainsi que les correctifs de sécurité amont, sont exclus du périmètre. Le texte propose même d’ajouter un point 6 au Contrat Social de Debian sur le sujet.
Plusieurs arguments sont donnés. D’abord, le statut juridique flou du copyright des sorties de LLM. Ensuite, des problèmes de qualité (paquets mal formés, fichiers watch non fonctionnels). En outre, un impact sur la dynamique communautaire : charge de relecture, non-apprentissage des nouveaux contributeurs, etc. Enfin, la question éthique, le scraping massif ayant perturbé l’infrastructure web de Debian et la question de l’empreinte environnementale étant prégnante.
La proposition B, portée par l’ancien DPL, Lucas Nussbaum, est plus mesurée. Elle autorise les contributions assistées par IA sous six conditions cumulatives :
compatibilité légale de l’outil utilisé
vérification des droits sur le contenu préexistant réutilisé
responsabilité totale du contributeur
divulgation de l’usage via un tag Git type Generated-By: ou Assisted-By:
discussion préalable pour les modifications massives ou automatisées
interdiction de transmettre des données sensibles (rapports de sécurité sous embargo, discussions privées) à des fournisseurs IA non fiables
La proposition C, portée par Ian Jackson, est un rejet de principe mais « pragmatique ». Elle demande à tous les contributeurs d’éviter les LLM et appelle plus largement la communauté du logiciel libre à rejeter cette technologie, tout en reconnaissant qu’une interdiction totale est impraticable puisque de nombreux projets amont y recourent. Il propose cependant des règles strictes : les messages destinés aux humains (rapports de bugs, listes de diffusion, Salsa, blogs Planet Debian) doivent être rédigés uniquement par des humains, tout usage de LLM doit être divulgué, les mainteneurs individuels peuvent totalement bannir l’IA sur leurs projets. Et la plus stricte d’entre elles : les violations sont traitées comme des manquements au Code de Conduite.
Quant à la proposition D, portée par Pierre-Elliott Bécue, elle ressemble beaucoup à la B dans l’esprit : une acceptation encadrée, portée sur les responsabilités. En clair, Debian n’endosse pas l’usage de l’IA générative mais reconnaît sa réalité et refuse une interdiction jugée « contre-productive et inapplicable ». Cette proposition place la responsabilité sur le contributeur (conformité DFSG, signature GPG personnelle, marquage de l’usage IA dans les commits et notes de version), avec une clause spécifique interdisant l’usage d’IA cloud pour des données sensibles ou non publiques.
Une décision importante
Plusieurs éléments intéressants entourant cette nouvelle résolution générale. D’abord, la proximité avec l’ancienne : à peine quelques mois, signalant le besoin pour les développeurs de trancher un sujet devenu central. L’IA générative est partout et les LLM sont utilisés dans une part croissante des projets. Précisons quand même que la précédente discussion en février-mars n’a pas atteint le statut officiel de GR. Il s’est écoulé environ un mois entre le brouillon alors préparé par Lucas Nussbaum et l’abandon du processus.
On ne sait pas combien de temps durera la résolution générale, mais la discussion et le vote seront importants. Debian n’est pas n’importe quelle distribution : en plus de son utilisation proprement dite, elle sert de socle à de nombreux autres systèmes, dont le plus connu est Ubuntu, la distribution Linux la plus utilisée aujourd’hui. Ce qui n’empêche pas d’autres organisations, comme Canonical, de procéder à des modifications assistées par IA.
Cette résolution cristallise de nombreux aspects entourant les LLM. Le fait que les questions éthiques et environnementales fassent partie de la réflexion est significatif, mais le sujet est complexe : comment trancher entre une interrogation croissante sur les gains potentiels et les conséquences négatives d’une utilisation intensive ? Si les membres du projet Debian regardent en direction de Linus Torvalds, une proposition B ou D pourrait l’emporter : une vision pragmatique et responsabilisée des contributions.
Connexion
