Les technologies IA sont d'essence fasciste, nous dit tante, militant antifasciste et technocritique.

IA, dans ce texte, signifie les algorithmes de reconnaissance de motifs et de génération aléatoires.

Plusieurs arguments.

l'IA comme violences

4 violences faites par les algorithmes d'IA :

1. Le vol des données pour l'entraînement
2. Les violences psychologiques imposées aux annotateurs pour éliminer les contenus choquants ingérés ou produits par ces algorithmes
3. La prétension à saisir tout le savoir humain, alors qu'il oublie/exclut mécaniquement les cultures non-écrites ou non-numérisées et qu'il renforce les biais de représentation
4. La violence contre les femmes et les minorités, permises par ces algorithmes (nudification...)

Utiliser l'IA, c'est accepter ces violences. Nous faire accepter une société de dominations et de violences, c'est le projet des fascistes.

Je trouve l'argument peu convaincant : le fasciste utilise la violence de façon visible et menaçante, pour en faire une composante de la société qu'il gangrène. Alors que les violences citées ici ne sont assumées que par une minorité des promoteurs de l'IA, ceux ouvertement fascistes (Thiel et Trump). En-dehors d'eux, des acteurs comme Anthropic, OpenAI ou Mistral tendent plutôt à taire ces violences ou, à défaut, à les nier ou les minorer.

J'adhère bien plus à tous les arguments suivants.

un outil contre les travailleurs

Par :

• la mise en concurrence de soi contre nos collègues (qui, eux, pourraient utilisent l'IA)
• la dévaluation du travail d'autrui (le dessinateur qu'on oublie au profit de midjourney)

... l'IA sert à détruire les solidarités ouvrières, à nous atomiser face au patron.

pour détruire la vérité et la confiance

Les chatbots s'attaquent aux institutions qui médient notre rapport au monde (journalistes, universités, ...) : en facilitant la prolifération de contenus plausibles mais faux, ils nous rendent incapables de distinguer les informations fiables de celles mensongères. Ils détruisent l'espace social dans lequel on peut débattre et vérifier l'information.

L'algorithme étant opaque par essence, on ne peut pas comprendre ou expliquer la réponse d'un chatbot, donc on ne peut pas l'accepter ou la réfuter: on ne peut qu'y croire ou pas. En ce sens, c'est un instrument de pouvoir : qui contrôle l'algorithme contrôle les croyances qui sont diffusées tout en marginalisant, en même temps, les institutions susceptibles d'établir des connaissances et permettant la confiance dans l'information.

pour détruire la bureaucratie, donc la démocratie

La bureaucratie est le mécanisme que les démocraties ont trouvé pour assurer l'application écrite et transparentes des règles par l'État, notamment des décisions qui concernent les citoyens.

En permettant de remplacer la bureaucratie par des algorithmes opaques au nom de l'efficacité, les technologies IA font primer l'arbitraire sur la transparence et rendent opaques les responsabilités dans les institutions qui exercent leur pouvoir sur et contre nous.

la volonté de restauration d'un futur glorieux, le mépris de la dignité humaine

La foi dans la singularité, et le paradis terrestre à venir grâce à l'IA fonctionne comme la nostalgie de l'ordre ancien des fascistes classiques et la volonté de restauration qui l'accompagne : un projet politique qui méprise les gens, en particulier les plus faibles, au profit d'un futur glorieux, empreint de puissance.

divers points

Utiliser l'IA, c'est intégrer une vision du monde structurée par les fascistes. C'est se faire embarquer involontairement sur un chemin qui mène au fascisme.

l'opensource, c'est merveilleux mais les tendances centrées sur l'individu et portant en étandard une "neutralité" morale et politique en font un espace qui ne s'opposera pas au fascisme. Les licences opensource ne permettent pas de s'opposer au fascisme.

conclusion : il fait détruire l'IA.

À l'occasion de la publication d'une vulnérabilité (escalade de privilèges utilisateur -> root) présente par défaut dans Omarchy, on (re-)découvre à quel point il est facile, ayant accès à la socket docker, de devenir root sur la machine qui exécute docker : il suffit de lancer un conteneur dans lequel on monte / (de l'hôte) sur un point de montage autre.

docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow

En examinant le processus de décision ayant conduit au bombardement par erreur de l'école primaire iranienne Shajareh Tayyebeh le 28 février 2026, Kevin Backer analyse la raison d'être des processus bureaucratiques, c'est-à-dire les étapes de validation, discussion, réunions qu'une organisation s'impose via des règles internes pour aboutir à une décision puis mettre en œuvre ses actions.

Quelques idées qu'il propose :

• ces processus sont caractérisés par une certaine lenteur, et c'est une caractéristique nécessaire : cette lenteur et ces validations successives ménagent un espace permettant aux personnes de remettre les plans face à la réalité du terrain ou de la situation présente, puis faire des objections, annuler ou modifier l'action qui doit être menée (ici: la décision de bombarder telle ou telle "cible"), et ainsi éviter des erreurs.
• en conséquence, vouloir accélérer les processus et diminuer la friction du processus de décision, c'est supprimer des garde-fous qui protègent l'organisation contre des erreurs (et protègent celles et ceux sur lesquels l'organisation a du pouvoir, ici : les êtres humains qui, s'ils reçoivent une bombe américaine sur la tête, meurent - ça fait beaucoup de monde). Clausewitz le disait déjà au XIXe siècle
• par nature, l'institution a pour but d'éliminer le pouvoir discrétionnaire, celui des individus décidant seuls pour des raisons qui leur appartiennent. Pour ça, elle se dote de règles pour convaincre tout le monde (y compris elle-même) qu'elle obéit à des procédures objectives. Cependant, ces règles doivent en permanence être interprétées et adaptées à la situation rencontrée à l'instant t : c'est le rôle des humains à l'intérieur de faire ce travail d'interprétation, mais sans le reconnaître officiellement car ça contredit l'idée de processus régulier ne laissant pas de place à la subjectivité, donc ça contredit la raison d'être de l'institution. Il y a nécessairement un tension. Gros risque du coup: que quelqu'un dénonce l'arbitraire et la latence des processus puis les supprime au nom de l'efficacité.

En résumé, "les procédures formelles obscurcissent le travail qu'on est en train d'effectuer".

Il fait ainsi l'histoire du projet Maven de l'armée américaine :

• but: accélérer et automatiser la désignation des "cibles" et leur élimination (la "kill chain")
• timeline: 2017-aujourd'hui, monter à 1000 décisions par heure
• moyens employés :
  • algorithmes de machine learning (interprétation des images et données capturées par les satellites et drones, consolidation et enrichissement des informations, classification et priorisation des "cibles") de façon à automatiser toutes les étapes.
  • nouvelles interfaces pour centraliser les informations et incarner / accélérer le workflow
• Google cède devant ses ingénieurs en grève contre la participation à ce projet, c'est Palantir qui exécute le contrat
• résultat notable : le bombardement d'une école primaire en Iran par erreur le 28 février 2026.

Il inscrit cette histoire dans celle de la stratégie militaire américaine.

Note plus personnelle : l'analyse est intellectuellement stimulante. Néanmoins, le point de départ choisi (la guerre) est particulièrement horrible, et ça produit des idées moralement indéfendables, par exemple quand il est met en contrepoint des bombardements irréfléchis américains en Irak (2003) qui font régulièrement des victimes civiles ou alliées ceux, plus mesurés, des britanniques au même moment : il se dégage l'impression qu'il y aurait une "meilleure" façon de mener des bombardements. Il est nécessaire de rappeler qu'aucune guerre n'est juste, qu'aucun meurtre n'est acceptable, fût-il le produit d'une armée équilibrée laissant la place à la décision humaine.

Microsoft est une entreprise transnationale. L'expertise coûte cher. Les clients de Microsoft ont souvent besoin de l'aide de Microsoft pour résoudre des difficultés techniques qu'ils rencontrent. Les salaires étant beaucoup moins élevés en Chine ou en Inde qu'aux US, ça coûte beaucoup moins cher à Microsoft de faire appel à des ingénieurs non américains pour faire ce travail d'aide technique.

Mais pour intervenir sur des systèmes traitant d'informations classifiées, par exemple ceux du ministère de la Défense US, il faut être 1/ américain et 2/ habilité pour ça. Des ingénieurs américains, habilités et experts techniquement, ça coûte très cher. Pour proposer un tarif attractif et remporter le marché "cloud" du ministère de la Défense US autour de 2013, Microsoft a donc mis en place un système d'escorte numérique : l'ingénieur qui propose les étapes de diagnostic et réparation n'est ni habilité, ni américain, mais ces étapes sont exécutés par "l'escorte", un américain habilité. Problèmes:

• ceux qui sont recrutés comme "escorte" ne sont pas forcément compétents techniquement et ne peuvent juger de si les actions sont légitimes ou si elles piratent les systèmes
• ceux-ci sont parfois des sous-traitants, pas employés par Microsoft directement
• manifestement, Microsoft a dû décrire ce système dans le contrat cloud dans de toutes petites lignes, car personne n'est au courant au sein du ministère de la Défense US.

Margaret Mitchell répond aux objections de ceux qui aiment les LLMs et que ça débecte qu'on désigne ces systèmes comme des "perroquets stochastiques", terme qu'elle et d'autres ont proposé dans le célèbre article On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? (mars 2021).

Au passage, elle signale plusieurs mécanismes qui entretiennent l'illusion d'intelligence autour des LLMs :

• l'association forte, dans nos sociétés, entre "capacité à écrire / parler" et "intelligence" :
  • Elle rappelle que les personnes sourdes (/ muettes) sont souvent perçues comme déficientes intellectuellement, encore aujourd'hui
  • alors que la génération d'images a progressé en même temps que la génération de textes, ce sont surtout les modèles de langue qui sont décrits et perçus comme"intelligents"
• les métaphores employées pour décrire ces systèmes (intelligence, raisonnement, compréhension, attention) renvoient à l'idée de cognition et fabriquent l'illusion d'intelligence. Les métaphores sont utiles et aident à comprendre le fonctionnement des algorithmes, mais dans ce cas elles participent à entretenir l'illusion d'intelligence. D'où la nécessité de proposer d'autres termes, plus précis, colle celui de "perroquet stochastique".

Margaret Mitchell rappelle aussi que tous les systèmes d'IA ne sont pas des LLMs, et que "perroquet stochastique" désigne uniquement les LLMs.

Au-delà des critiques usuelles sur les IA génératives, Pauline Harmange se demande comment ces outils ont pu "prendre" aussi rapidement dans la société : pourquoi nos pairs vont-ils si rapidement les adopter, en dépit de toutes les bonnes raisons de ne pas le faire ?

C'est parce que "la société" a réussi à nous convaincre individuellement de notre nullité, de notre impuissance, de notre incapacité à créer, à inventer. La machine fait de la merde, mais plus jolie que ce qu'on est capable de faire avec nos petites capacités limitées (certes moins jolie que si on travaillait vraiment nos créations, mais bien plus rapidement).

En réponse, l'auteure propose de faire, ensemble. Faire des trucs de nos dix doigts, dans le monde matériel. Faire et imaginer avec d'autres, peut-être mal, peut-être imparfaitement, mais ensemble. Pour rappeler que, le réel, les liens humains, c'est vachement chouette.

Le syndicat américain des auteur.e.s de science-fiction et fantasy a décidé d'interdire l'usage de générateurs automatiques pour les œuvres concourant aux Nebulas, et cette interdiction s'est faite plus ferme sous la pression de la communauté des lectrices, lecteurs et auteur.e.s. Erin Underwood, actrice, s'oppose à cette interdiction générale dans une lettre ouverte.

L'écrivaine australienne Foz Meadows (wikipedia) publie une réponse au vitriol "contre l'IA". La seconde partie répond argument par argument à la lettre d'Underwood, la première partie réaffirme que l'IA est une technologie fondamentalement nocive.

Extrait (traduit en français) :

L'IA est nocive sur tous les plans. C'est un outil de faussaire imprécis bâti sur le vol du travail de création, la destruction accélérée de l'environnement, les violations des droits humains, l'augmentation des risques psychiques, la sextorsion, l'effondrement de l'éducation et l'érosion de notre sens collectif de la vérité. Et la seule raison pour laquelle elle est partout malgré tout ces dégâts, c'est parce qu'une poignée de miliardaires sociopathes évoluant dans un domaine lourdement dérégulé ont renchéri dessus en la foutant partout.

Quelques centaines d'universitaires français appellent à l’objection de conscience face à l’IA générative en raison des dégâts environnementaux, sociaux (pour les travailleurs du Sud et l'espace informationnel du Nord) et politiques (concentration du pouvoir dans quelqued méga-firmes américaines).

En réponse, le philosophe Gregory Chatonsky défend le devoir de l'université d'explorer les techniques et refuse d'essentialiser l'IA dans sa forme actuelle définie par des intérêts privés (l’IA n’est pas même si elle existe). En réponse aussi, et dans le même esprit, une contre-tribune affirme que refuser l’IA à l’université, c’est en abandonner le contrôle au capitalisme.

À ces deux textes, le doctorant en humanités numériques Louis-Olivier Bossard répond dans refuser l’IA sous le signe de l’agnotologie que :

• tout développement technique a des conséquences matérielles et sociales
• les sujets d'étude et méthodes d'expérimentation sont contraintes par des régles et interdits (expérimentations humaines ou animales, conséquences sociales de telle ou telle expérience), c'est l'éthique scientifique qui veut ça
• en conséquence, et il se fait là presque provoquant, que l'ignorance est activement produite, délimitée, décidée collectivement et politiquement par les chercheurs et la société qui les entoure

L'idée d'une AGI est passé en 20 ans de délire mystique marginal à courant de pensée endossé par une partie de la tech américaine. L'auteur note plusieurs caractéristiques de cette idée:

• Un caractère de "foi", i.e. une irrationalité de ses arguments (impossible d'argumenter, tout discours contraire alimente la croyance)
• l'opposition entre ceux qui y croient, qui "ressentent" cette imminence, et les incrédules
• le sentiment d'importance métaphysique donnée à leur propre travail par ces croyants chez OpenAI et consorts (fabriquer Dieu, ça flatte l'égo)

Il relie ça au complotisme (le lien me semble assez mal étayé, je ferai davantage le lien avec une foi religieuse).

De façon plus intéressante, Will Douglas Heaven décrit :

• l'origine de cette notion (entreprises et personnes) : Webmind, DeepMind, OpenAI, Goertzel, Legg
• leur obstination dans un milieu tech qui les prend pour des fous
• la +/- conversion de Thiel à ces idées, les légitimant ensuite à coups de $ en finançant OpenAI (2015) tandis que Bostrom la légitime intellectuellement (SuperIntelligence, 2014)
• certains circuits de diffusion (LessWrong)
• la façon dont elles sont actuellement utilisées pour drainer des financements qui apparaitraient sans fondements sinon

Découvert via la recension qu'en fait Hubert Guillaud, Intelligence artificielle générale : le délire complotiste de la tech, dont je recommande la lecture.

Au détour d'un chouette article présentant des failles identifiées sur Pagure, le système de gestion des compilations de paquets pour Fedora, Thomas Chauchefoin constate :

We could also be overriding Python files of the application. It worked locally on a Pagure deployed from source, but when validating the finding on the staging instance, we noticed that this idea and a few other ones simply didn’t work! The instance must have been deployed from the Fedora RPM packages where application files are owned by root.

Moralité: quand on déploie une application, il faut s'assurer si possible que lors de son exécution elle n'ait pas les privilèges nécessaires pour modifier son code source ou même sa propre configuration.

Pour rassurer leurs clients sur la sécurité de leurs données, les fournisseurs cloud ont d'abord promis: "nous chiffrons les données au repos", empêchant qu'une sauvegarde égarée ou un disque décommissionné et perdu se promènent avec les données des clients.

Puis ils ont dit : "on va plus loin, on vous permet de chiffrer les données au repos avec VOTRE clé, c'est vous qui maîtrisez le stockage des données" (exemple avec Azure SQL). Et ça, c'est franchement bidon, car pour que les données soient utilisées dans le cloud, il faut leur transmettre notre clé. Que ce soit le client qui l'ait définie dans son coin ou le fournisseur cloud qui l'ait définie, à la fin c'est le fournisseur cloud qui l'a pour permettre aux systèmes de traiter les données. Donc en terme de contrôle, le client ne gagne pas grand chose.

Ce qui permet d'aller réellement plus loin, c'est la "virtualisation confidentielle", i.e. la capacité que peut avoir un système infonuagique de faire tourner du code et des calculs chiffrés, sans pouvoir connaître le contenu des données traitées. Et c'est un peu plus compliqué, notamment parce que ça nécessite une transparence totale de l'infrastructure du fournisseur cloud.

2 évolutions s'opèrent en parallèle en matière de logiciels :

• de plus en plus de logiciels promettent le chiffrement de bout en bout, rendant le fournisseur incapable d'accéder aux données de l'utilisateur (exemple: signal, réseau Matrix, Nextcloud avec chiffrement de bout en bout, etesync)
• de plus en plus de logiciels sont développés comme "applications web", servies depuis un site internet (exemple: le client Matrix element.io, Microsoft Office365, ...)

En l'état actuel des technologies, les deux objectifs ne sont pas totalement compatibles. Une application qui fait du chiffrement de bout en bout, si on y accède via le navigateur depuis un site internet tiers, sera vulnérable à une attaque sur ce site internet : un intrus peut modifier l'application de sorte à faire fuiter les clés de chiffrement de ceux qui l'exécutent dans l'intervalle, ou trouver une faille (type XSS) de façon à exfiltrer les clés de certain.e.s utilisateurs ou utilisatrices. À l'inverse, une application "desktop" sera moins rapidement attaquable : il faut que l'attaquant publie une version vérolée, puis que les utilisateurs mettent à jour, avant que l'attaque soit effective. Si la validité des mises à jour est contrôlée à l'aide d'un mécanisme de signature cryptographique (comme c'est le cas des mises à jour logicielles des distributions Linux), l'attaque est rendue encore plus compliquée.

Pour les applications web, l'équipe derrière eteSync propose une solution sous forme d'extension de navigateur qui vérifie la signature GPG des pages renvoyées par le serveur.

• github (comme gitlab, non mentionné par l'auteur) permet de lister les clés SSH publiques d'un utilisateur
• quelqu'un a compilé la table de toutes les clés, permettant de retrouver un utilisateur github à partir de n'importe laquelle de ses clés présentes sur github
• en pratique, les clients SSH annoncent la clé publique au serveur pour lui demander si elle est acceptée par celui-ci avant d'utiliser la clé privée

Tout ça mis bour à bout permet de :

• pour un serveur SSH : tenter de trouver l'identifiant github du quidam qui se connecte
• pour un curieux : en essayant toutes les clés publiques de la table (très long!), trouver l'identifiant github de personnes ayant accès à un serveur en particulier
• (non mentionné par l'auteur) établir la correspondance entre les comptes d'un même développeur sur plusieurs plateformes (savoir que HaxORR_du_91 sur github est Robert Dupont sur gitlab)

Il s'agit donc d'une belle fuite involontaire de données personnelles.

Pour se prémunir de telles attaques, il convient d'utiliser des clés SSH dédiées aux connexions sur les forges. Par exemple en générant une clé dédiée :

$ ssh-keygen -f ~/.ssh/id_git_ed25519 -t ed25519

Puis en indiquant uniquement ces clés à github/gitlab et en indiquant dans votre .ssh/config :

Host github.com gitlab.com [ou tout autre forge]
    IdentityFile ~/.ssh/id_git_ed25519.pub

Notez aussi que si vous utilisez une clé GPG publique comme back-end d'authentification SSH (ce qui est une bonne idée en soi !), on peut recalculer votre clé SSH publique avec l'option --generate-ssh-key (merci au collègue qui m'a transmis l'astuce).

L'OSINT a de beaux jours devant elle!

PyPI, le point central de distribution de paquets Python, demande aux mainteneurs des paquets les plus populaires de sécuriser leur compte avec un second facteur d'authentification, afin de limiter le risque que le compte soit compromis et tous les utilisateurs du paquet par ricochet.

Armin Ronacher s'élève vivement contre cette nouvelle exigence, trouvant gonflé de demander à celui qui a gentiment et gratuitement partagé son travail de supporter la charge de la sécurité des utilisateurs de son travail. Après tour, ça n'est pas "sa faute" si son travail devient populaire.

Dans Yes, I have opinions on your open source contributions, James Bennett lui répond que nous sommes tous et toutes utilisatrices des paquets Python (et pas seulement les grosses entreprises qui ont de l'argent), et que si la communauté propose de fixer des règles pour nous protéger tous, c'est être singulièrement asocial de les refuser.

Le premier commentateur sur Linux Weekly News remarque avec malice que les obligations qu'Armin Ronacher craint de voir imposées ensuite par PyPI (signature cryprographique, standard de qualité, traitement diligent des problèmes de sécurité, mesures en cas de défaillance du mainteneur) sont précisément les garanties apportées par les dépôts des distributions Linux. Ce sont les attentes des utilisateurs, y compris (à tort) quand ils utilisent PyPI, npm, cargo ou autre dépôt lié à un langage de programmation.

The lie marketers told us in the late 1990s and early 2000s (and that many in tech still believe as an article of faith) was that people don’t dislike ads, they only dislike irrelevant ones. [...] The problem is, to make ads ever more relevant, Big Tech firms have argued they must collect vast amounts of information about people to build dossiers on them that can predict their wants and needs.

Une faille permettait à une application confinée via flatpak de s'échapper de son confinement.

On apprend au passage qu'une application flatpak qui a accès au bus DBus org.freedesktop.Flatpak peut s'échapper en exécutant flatpak-spawn --host <commande>. C'est le cas notamment de l'IDE VSCode (et de sa version sans télémétrie VSCodium), ce trou dans la raquette étant nécessaire pour accéder à un terminal non confiné depuis l'IDE, comme documenté sur le dépôt de l'empaquetage flatpak de VSCode

• L'agent GPG stocke le mot de passe de la clé en mémoire vive.
• Ce mot de passe est lui-même chiffré : un dump de l mémoire vive ne permet pas de le retrouver en clair.
• Néanmoins, la clé de chiffrement de ce mot de passe étant aussi en mémoire, on peut la retrouver et déchiffrer le mot de passe à partir d'un tel dump : en l'état, la protection apportée par le chiffrement est illusoire (la fonctionnalité est présentée comme pouvant servir à terme avec un TPM)
• La clé privée protégée par le mot de passe est-elle aussi stockée en mémoire vive?
  • Si oui, il est inutile stocker aussi le mot de passe, c'est absurde. J'en déduis que non
  • Si non, ça fait une petite protection contre attaquant peu probable qui aurait accès à la mémoire vive (accès très difficile à obtenir) mais pas au système de fichiers (accès a priori moins difficile).

Points relatifs à la sécurité:
✅ stabilité du langage (mais il manque encore des choses indispensables)
✅ la doc indique clairement de séparer la résolution des dépendances par projet
⛔ installer une dépendance passer par l'exécution de code provenant de celle-ci

Arnaud Rebillot rend compte des efforts fructueux pour "debianiser" Docker-ce (sous le nom de docker.io). Le problème principal réside dans le fort couplage en go entre un projet et ses dépendances : il faut alors séparer en plusieurs paquets indépendants lorsque les dépendances peuvent être utilisées ailleurs et maintenues séparément, mais sans séparer les composants d'un même logiciel.

Il est ironique de déployer tout cet effort pour "débundler" (définitions) un outil destiné à faire tourner des applications qui le sont au plus haut point (les conteneurs).

En 2019 Matrix a subi une intrusion sur ses serveurs. Ils en retirent plusieurs recommandations.

Sur le plan technique :

• Ne PAS utiliser l'agent forwarding avec SSH, privilégier le ProxyJump (-J)
• placer le fichier authorized_keys sous le contrôle de root plutôt que sous celui de l'utilisateur
• avoir des procédés automatisés pour détecter les mises à jour à lettre en œuvre
• segmenter le réseau, limiter les privilèges au minimum nécessaire

Sur le plan organisationnel:

• ils notent le danger des infrastructures (ou outils) "legacy", maintenus en fonctionnement et laissés en l'état quand les efforts se concentrent sur une nouvelle architecture/version plus sûre: il faut impérativement avoir une personne en responsabilité de lettre fin à cette situation.
• il faut des check-lists pour la remise en route des services et la rotation des secrets
• lors d'un incident, il faut quelqu'un pour coordonner les travaux, gérer la communication interne et la communication externe: si peuvent être remplies par la même personne, il s'agit bien de 3 missions distincted