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.

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.

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.

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.

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.

L'ouverture c'est bon, mangez-en

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.

• Kimi K3 : ce qu’il faut savoir du modèle open source de 2 800 milliards de paramètres

L'ouverture c'est bon, mangez-en

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.

• Kimi K3 : ce qu’il faut savoir du modèle open source de 2 800 milliards de paramètres

Discussion à poids ouverts

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.

Discussion à poids ouverts

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.

Le temps où les modèles Opus étaient les plus puissants du catalogue d’Anthropic est terminé. Ce rôle est désormais dévolu à Fable et Mythos, mais le labo IA n’en a pas moins oublié son ancienne famille haut de gamme. Le lancement d’Opus 5 semble s’accompagner d’une prise de conscience de l’entreprise : les clients ont besoin de modèles certes costauds, mais aussi et surtout au bon rapport performances/prix.

Un des premiers arguments d’Anthropic porte ainsi sur les tarifs. Opus 5 se situe presque au niveau de Fable 5 pour certaines tâches, tout en étant facturé moitié moins cher. Les prix sont de 5 dollars par million de jetons en entrée, pour 25 dollars en sortie, soit la même chose qu’Opus 4.8. Fable 5, qui n’est accessible via l’API et des crédits d’utilisation, revient respectivement à 10 et 50 dollars.

Le labo insiste d’ailleurs lourdement sur le coût nécessaire pour réaliser une tâche, pas uniquement sur les résultats bruts des benchmarks. Sur CursorBench 3.1, au niveau d’effort maximal, les performances d’Opus 5 se placent à moins de 0,5 % du meilleur score de Fable 5 pour un coût par tâche deux fois moins élevé, selon le test réalisé par l’entreprise.

Le modèle obtient de meilleurs résultats que tous les autres avec les niveaux d’effort high, xhigh et max. Anthropic affirme qu’Opus 5 atteint l’état de l’art en matière de performances, ce qu’il faudra vérifier de manière indépendante.

En plus d’amélioration significatives sur les tâches liées à la recherche scientifique par rapport à Opus 4.8, ce nouveau modèle sait aussi générer des visuels « nettement plus convaincants » (chacun jugera) :

Opus 5 semble surtout progresser dans sa capacité à vérifier son propre travail, à corriger ses premières tentatives et à construire les outils qui lui manquent pour arriver au bout d’une tâche. En termes de cybersécurité, le modèle est présenté comme moins dangereux que Mythos 5 ; il serait presque aussi performant pour repérer des vulnérabilités, mais nettement moins efficace pour fabriquer les moyens de les exploiter.

• Depuis son retour, Claude Fable 5 fait beaucoup moins rêver

Le temps où les modèles Opus étaient les plus puissants du catalogue d’Anthropic est terminé. Ce rôle est désormais dévolu à Fable et Mythos, mais le labo IA n’en a pas moins oublié son ancienne famille haut de gamme. Le lancement d’Opus 5 semble s’accompagner d’une prise de conscience de l’entreprise : les clients ont besoin de modèles certes costauds, mais aussi et surtout au bon rapport performances/prix.

Un des premiers arguments d’Anthropic porte ainsi sur les tarifs. Opus 5 se situe presque au niveau de Fable 5 pour certaines tâches, tout en étant facturé moitié moins cher. Les prix sont de 5 dollars par million de jetons en entrée, pour 25 dollars en sortie, soit la même chose qu’Opus 4.8. Fable 5, qui n’est accessible via l’API et des crédits d’utilisation, revient respectivement à 10 et 50 dollars.

Le labo insiste d’ailleurs lourdement sur le coût nécessaire pour réaliser une tâche, pas uniquement sur les résultats bruts des benchmarks. Sur CursorBench 3.1, au niveau d’effort maximal, les performances d’Opus 5 se placent à moins de 0,5 % du meilleur score de Fable 5 pour un coût par tâche deux fois moins élevé, selon le test réalisé par l’entreprise.

Le modèle obtient de meilleurs résultats que tous les autres avec les niveaux d’effort high, xhigh et max. Anthropic affirme qu’Opus 5 atteint l’état de l’art en matière de performances, ce qu’il faudra vérifier de manière indépendante.

En plus d’amélioration significatives sur les tâches liées à la recherche scientifique par rapport à Opus 4.8, ce nouveau modèle sait aussi générer des visuels « nettement plus convaincants » (chacun jugera) :

Opus 5 semble surtout progresser dans sa capacité à vérifier son propre travail, à corriger ses premières tentatives et à construire les outils qui lui manquent pour arriver au bout d’une tâche. En termes de cybersécurité, le modèle est présenté comme moins dangereux que Mythos 5 ; il serait presque aussi performant pour repérer des vulnérabilités, mais nettement moins efficace pour fabriquer les moyens de les exploiter.

• Depuis son retour, Claude Fable 5 fait beaucoup moins rêver