Bon, celle-là elle est gratinée. NVIDIA, le géant des GPU, a directement contacté Anna's Archive pour accéder à environ 500 To de livres piratés. Contacté, négocié, payé. Comme ça, tranquillou.

C'est une class action (dossier n°1:26-cv-00002 au tribunal fédéral de New York, pour ceux qui veulent aller checker) qui a fait fuiter ces fameux emails internes. En gros, un membre de l'équipe "data strategy" de NVIDIA a négocié un accès haute vitesse aux collections piratées de la bibliothèque. Et le plus beau dans l'histoire c'est qu'Anna's Archive les a PRÉVENUS que les données étaient illégales. Genre, texto : "Vous avez une autorisation interne pour ça ?"

La réponse est arrivée en moins d'une semaine. Feu vert. Sauf que bon, quand on lit ça avec du recul, c'est quand même sacrément culotté.

Le contexte, c'était surtout la pression de livrer pour la GTC 2023 (la Developer Conference de NVIDIA). Fallait nourrir les modèles d'IA coûte que coûte, et le dataset Books3 (196 000 bouquins issus de Bibliotik), plus LibGen, Sci-Hub, Z-Library... ça faisait un buffet de 500 To et de leur côté Anna's Archive facturait des dizaines de milliers de dollars pour l'accès rapide.

Sérieux, j'aurais aimé voir la tête du service juridique de NVIDIA en lisant cet email...

En parallèle, Anna's Archive se prend un procès complètement délirant puisque Spotify, Universal Music, Warner et Sony réclament 13 000 milliards de dollars (13 TRILLIONS, soit à peu près le PIB de la Chine). C'est en lien avec leur backup de 300 To de Spotify dont je vous avais parlé ici. Le juge Rakoff a émis une injonction mondiale le 20 janvier, ce qui a fait tomber plusieurs domaines du site .

NVIDIA plaide le "fair use" évidemment. Mouais. On verra bien ce qu'en pensera le juge, mais quand les emails prouvent qu'on t'a prévenu que c'était illégal et que t'as quand même dit "go"... c'est pas ouf comme défense.

En attendant, entre le procès Spotify et ces emails, Anna's Archive est devenue l'ennemi public numéro un de toute l'industrie du contenu sur le web.

Affaire à suivre !

Source

Si vous bidouillez un peu avec des modèles CoreML sur votre Mac Silicon, vous savez que c'est vite la croix et la misère comme je dis souvent... Car dès qu'il s'agit de tester un truc rapide, faut ouvrir Xcode, pisser du Swift, ou se battre avec des scripts Python... Bref, l'usine à gaz juste pour vérifier une prédiction vite fait.

Hé bien bonne nouvelle les amis, un petit outil en ligne de commande vient de sortir pour nous éviter de trop galérer.

Ça s'appelle coreml-cli et comme son nom l'indique, c'est une interface pour inspecter et lancer vos modèles depuis le terminal. L'objectif c'est de pouvoir manipuler vos fichiers .mlmodel sans jamais avoir besoin de lancer l'IDE d'Apple.

Si vous êtes chaud bouillant, ça s'installe hyper facilement via Homebrew :

brew tap schappim/coreml-cli
brew install coreml-cli

Et une fois que c'est là, vous pouvez TOUT faire. Genre vous voulez voir ce qu'il y a dans un modèle ? Hop, un petit coreml inspect MobileNetV2.mlmodel et vous avez toute la structure, les entrées et les sorties qui s'affichent.

Et pour lancer des prédictions, c'est également très simple plus simple. Par exemple, avec le modèle MobileNet qui détecte les objets présents dans une image, vous lui donnez une image, et avec l'option --json, il vous sort le résultat proprement.

coreml predict MobileNetV2.mlmodel --input photo.jpg --json

Et pour ceux qui veulent automatiser des traitements, le mode "batch" permet de traiter tout un dossier d'images d'un coup. C'est quand même plus rapide que de le faire à la main un par un, comme le ferait un ingé de Perpignan nourri aux graines de chia.

Le développeur a même intégré un outil de benchmark pour mesurer la latence. Ça vous permet de lancer des tests sur le CPU, le GPU ou le fameux Neural Engine d'Apple pour comparer les perfs. C'est le top pour optimiser vos apps avant de les déployer.

Du coup, si vous bossez avec de l'IA locale sur Mac, un peu comme ce qu'on a déjà testé par le passé avec MocoLlamma ou sur de gros clusters Mac Studio comme ce furieux, ce petit binaire risque de vite devenir indispensable dans vos scripts CI/CD.

Amusez-vous bien !

Source

Et c'est reparti pour une journée de moine à écrire sur le meilleur site tech de l'univers et aujourd'hui, j'ai envie de vous parler de Core War et de cybersécurité.

Core War, c'est un jeu de programmation hyper culte qui est devenu populaire dans les années 80 et dans ce jeu, y'a des sortes de guerriers numériques qui se foutent sur la gueule pour prendre le contrôle d'une machine virtuelle . Et je vous avoue que c'est assez kiffant à voir.

Et croyez le ou non, des chercheurs de Sakana AI et du MIT se sont appuyés sur ce concept pour créer leur Digital Red Queen (DRQ) , c'est à dire un algorithme qui utilise des LLM pour faire évoluer ces programmes de "combat" de façon totalement autonome.

L'idée de base en fait, c'est de simuler la fameuse " Reine Rouge " de l'évolution biologique. Cette théorie de la Reine Rouge explique en gros que les espèces doivent évoluer sans cesse juste pour rester à leur place face à leurs prédateurs.

Et sous la forme de code, ça donne qu'à chaque round, l'algorithme cherche à faire éclore un nouveau "warrior" capable de battre tous les champions précédents. Pour cela, l'algo DRQ s'appuie par défaut sur un modèle gpt-4.1-mini (mais c'est configurable évidemment) qui fait office de moteur de mutation génétique. L'IA génère alors de nouveaux programmes, les fait se combattre, et ne garde que celui qui surpasse la lignée.

C'est une bataille de code sans fin où seuls les meilleures survivent !

Et là où ça devient vraiment balaise, c'est que l'IA ne se contente pas de copier-coller du code existant. Non, cette petite futée invente de véritables stratégies qui feraient bégayer Sun Tzu.

Les chercheurs ont également pu observer certains phénomènes de convergence phénotypique (oui moi aussi j'avais aucune idée de ce que ça voulait dire). C'est-à-dire que des guerriers issus de lignées différentes finissent à un moment par adopter tous les mêmes tactiques de combat. Genre bombardement ciblé, auto-réplication massive ou création intensive de processus. Et ça c'est pas bon.

Alors pour tenter de maintenir une certaine diversité de comportements, l'équipe a utilisé des algos de MAP-Elites ce qui leur a permis de classer les programmes selon des critères comme le nombre de processus créés ou l'occupation de la mémoire pour éviter de tomber dans une sorte de pierre-feuille-ciseaux sans fin !

Et ça a plutôt bien fonctionné car même si les chercheurs notent que la diversité finit par baisser au fil des runs, cela permet quand même de découvrir des stratégies variées avant que l'évolution ne converge.

Maintenant c'est bien rigolo tout ça mais peut-être que vous vous demandez à quoi ça sert à part faire mumuse avec du vieil assembleur ? Et bien les auteurs pensent que leurs travaux pourrait être appliqués en cybersécurité.

En comprenant comment des programmes peuvent s'adapter de façon autonome à des adversaires qui mutent en permanence, on peut imaginer des systèmes de défense plus autonomes et résilients. On est un peu dans la même veine que ce que j'évoquais avec Evo 2 et l'ADN fonctionnel , mais appliqué au logiciel pur.

Voilà, alors je ne sais pas ce que ça va donner mais j'ai trouvé ça cool de voir comment un vieux concept de 1984 est devenu une super sandbox pour tester les limites de l'évolution artificielle des logiciels.

Bien sûr, tout le code est dispo sur GitHub (le simulateur Core War lui-même vient du projet de Rodrigo Setti ), avec des instructions pour installer ça via Conda et lancer vos propres arènes de combat. J'sais pas si vous essayerez mais si c'est le cas, je veux bien un feedback dans quelques temps.

Et surtout, un grand merci à Timothée qui a partagé ça sur son compte LinkedIn .

Si vous utilisez des agents IA en ligne de commande genre Claude Code et que vous leur faites exécuter des scripts téléchargés sur le net, voici un outil qui devrait vous plaire.

Fence est un utilitaire qui permet de lancer vos commandes dans un environnement isolé, sans avoir besoin de Docker ou de conteneurs. L'outil bloque par défaut toutes les connexions réseau sortantes et restreint l'accès au système de fichiers, du coup, si votre agent IA décide de faire des bêtises, il se retrouvera face à un mur.

Concrètement, vous préfixez simplement votre commande par fence comme ceci :

fence curl https://example.com
# → 403 Forbidden (bloqué par le sandbox)

fence -t code npm install
# Utilise le template "code" qui autorise les registres npm

fence -c "rm -rf /"
# → Hop, c'est bloqué ! Et heureusement !

fence import --claude -o ~/.fence.json

# Installation rapide
curl -fsSL https://raw.githubusercontent.com/Use-Tusk/fence/main/install.sh | sh

# Ou via Go
go install github.com/Use-Tusk/fence/cmd/fence@latest

Je trouve qu'il n'y a rien de plus idiot qu'un débat philosophique sur ce qu'est "vraiment" l'intelligence quand on a juste besoin que le boulot soit fait... J'en vois certains en faire des tartines à longueur de journée sur Linkedin, notamment pour tenter de définir le niveau d'intelligence des IA mais de mon point de vue, c'est vraiment perdre son temps que d'essayer d'évaluer ça.

Récemment, je suis tombé sur un billet de Bertrand Meyer sur le Blog de CACM qui met enfin des mots sur mon malaise... En fait il explique qu'il y a 2 grandes visions qui s'opposent concernant la définition de l'intelligence.

D'un côté, on a l'approche plutôt "européenne" où l'intelligence, c'est comprendre les choses, comprendre le monde, savoir expliquer le "pourquoi du comment". Et de l'autre côté, on a une vision plus "américaine" et pragmatique où l'intelligence c'est avant tout réussir à s'adapter et agir en conséquence avec succès.

En gros, ça veut dire que pour les ricains, si ça marche, c'est une preuve d'intelligence.

Et là, tout s'éclaire car l'IA d'aujourd'hui, nos chers LLM d'amour et autres réseaux neuronaux, correspondent parfaitement à cette seconde définition. En effet pour beaucoup de chercheurs, ces systèmes ne "comprennent" pas le monde au sens cognitif du terme mais réussissent quand même à donner très souvent les bonnes réponses et à trouver de bonnes solutions à tout un tas de problèmes.

Un peu comme ces modèles médicaux de Google capables d'aider les médecins dans leurs diagnostics... ça marche, c'est utile, et même si ça ne remplace pas (encore) l'expertise humaine (enfin sauf celle des internes ^^), c'est déjà génial !

Perso, je me positionne sur ça de manière un peu plus basique. Parce que je suis un mec basique... Je suis un techos, pas un marketeux ni un philosophe alors la seule question que je me pose finalement c'est "est-ce que ce que ça fait le taf" ?

Et surtout, est-ce que ce que l'IA produit c'est de qualité ?

Quand c'est du texte par exemple, mon premier critère c'est donc de savoir si l'information est juste. Ensuite c'est de savoir si c'est agréable à lire. Et enfin, est ce qu'on en retire quelque chose (un apprentissage, du fun, un élargissement de sa pensée) ?

Voilà c'est tout... et ça je l'applique aussi bien aux textes écrits par des humains qu'à ceux écrits par des algos.

Si ces 3 conditions ne sont pas remplies, c'est (pour moi, hein) de la merde. Et donc j'applique ces principes du mieux que je peux, aussi à ce que j'écris.

Je pourrais bien sûr ajouter d'autres critères du genre "Est ce que j'ai fait le tour de la question de manière encyclopédique ?" et "Est ce que en écrivant cela, je ne vais pas insécuriser un random qui va ensuite m'attaquer publiquement pour rassurer son égo auprès de sa communauté ?" mais bon, ici c'est pas Wikipédia et j'suis pas non plus le psy des gens qui détestent mon contenu mais viennent quand même me lire religieusement chaque jour. Donc j'avoue, je fais l'impasse... Ahaha.

Maintenant pour ceux qui se demandent encore comment définir l'intelligence artificielle, voyez plutôt ça comme un outil capable de "faire comme si" avec suffisamment de talent pour que l'expérience soit bluffante de réalisme. Un peu comme quand on regarde un super film avec de super acteurs... On sait qu'ils font semblant et pourtant on ressent de l'émotion. Bah là c'est pareil, l'illusion est douce et hormis certains cas pathologiques où ça pourrait être problématique, je ne vois pas ça comme un souci de se faire "illusionner" par un texte IA tant que mes 3 critères plus haut sont remplis.

Que ce soit du texte humain ou du texte IA, le résultat peut être perçu par un humain comme similaire si c'est bien fait. Faut pas non plus oublier que beaucoup d'humains ne savent pas s'exprimer correctement et encore moins structurer correctement leur pensée pour la mettre par écrit (et je ne vise personne, mais suivez mon regard vers les services de micro-blogging et autres commentaires Youtube... ^^).

Le point important, crucial même (et là je sors mon panneau "Achtung danger"), c'est que pour chaque texte produit par une IA, un humain devrait le relire, le corriger, et l'améliorer. S'en porter garant en fait, sinon, c'est juste du texte générique de qualité standard avec peu de valeur ajoutée (si ce n'est faire du résumé quoi...) et un fort risque d'hallucinations.

Et je sais que la mode du moment est au slop IA aussi bien dans les mails, les médias, les sites SEO, les discours officiels du gouvernement et j'en passe mais putain, passer un petit coup de vérif / polish manuel par-dessus, c'est pas la mer à boire et hop, on retrouve instantanément une âme dans l'article et cela peu importe que ça passe le détecteur IA ou pas... Ces machins là font principalement de la vérification en surface et si vous écrivez trop parfaitement ou si votre IA écrit trop dégueulasse, vous aurez du faux positif dans un sens ou dans l'autre.

Je pense donc qu'on s'en fout un peu de savoir si la machine a une âme ou si elle "comprend" réellement le sens de la vie (spoiler : ce n'est pas le cas). Moi, tant qu'elle m'aide à coder un script Python vite fait ou à préparer un super article pour vous sans que j'aie à me taper des tonnes de doc, ça me va.

Maintenant reste à savoir si l'IA va un jour détruire nos institutions mais ça c'est une autre histoire..

Il y a des combats comme cela auxquels pas grand monde ne pense et qui pourtant sont très importants. Je parle évidemment de la lutte contre le chaos du texte non structuré. Si vous avez déjà essayé d'extraire des données propres d'un tas de PDF (après OCR), de rapports ou de notes griffonnées, vous voyez de quoi je parle : c'est l'enfer ! (oui j'aime me faire du mal en tentant des regex impossibles).

Heureusement, Google a lâché début janvier 2026 une petite pépite en open source (même si c'est pas un produit "officiel") qui s'appelle LangExtract . C'est une bibliothèque Python qui utilise la puissance des LLM pour transformer vos documents textuels en données JSON bien rangées.

Exemple d'extraction sur le texte de Roméo et Juliette ( Source )

Ce qui fait que LangExtract sort du lot par rapport à d'autres outils comme Sparrow , c'est surtout son système de Source Grounding. En gros, chaque info extraite est directement liée à sa position exacte dans le texte source. Ça facilite énormément la vérification et la traçabilité puisque vous pouvez voir visuellement d'où vient la donnée grâce à un système de surlignage automatique.

Sous le capot, l'outil est optimisé pour les documents à rallonge (le fameux problème de l'aiguille dans une botte de foin). Il utilise des stratégies de découpage de texte et de passes multiples pour améliorer le rappel et s'assurer que le maximum d'infos soit capturé.

La visualisation interactive permet de valider les données en un clin d'œil ( Source )

Et cerise sur le gâteau, il permet de générer un fichier HTML interactif pour visualiser les milliers d'entités extraites dans leur contexte original. À la cool !

Côté installation, c'est hyper fastoche :

pip install langextract

import langextract as lx

# 1. On définit les règles du jeu
prompt = "Extraire les noms de personnages et leurs émotions."

# 2. On donne un exemple (few-shot) pour guider le modèle
examples = [
 lx.data.ExampleData(
 text="ROMEO. But soft! What light...",
 extractions=[lx.data.Extraction(extraction_class="character", extraction_text="ROMEO", attributes={"emotion": "wonder"})]
 )
]

# 3. On lance l'extraction (nécessite une clé API ou Ollama)
results = lx.extract(
 text_or_documents="votre_texte_brut_ici",
 prompt_description=prompt,
 examples=examples,
 model_id="gemini-2.5-flash"
)

# 4. On sauvegarde et on génère la visualisation HTML
lx.io.save_annotated_documents(results, output_name="results.jsonl")
html_content = lx.visualize("results.jsonl")
with open("view.html", "w") as f:
 f.write(html_content)

Vous connaissez Gemma ? Bon, hé bien Google vient de remettre une pièce dans la machine avec TranslateGemma , une nouvelle collection de modèles ouverts dédiés exclusivement à la traduction.

Si vous utilisez Google Translate ou DeepL au quotidien, c'est super, ça marche bien, mais ça demande quand même une connexion internet et vos données partent dans le cloud. Donc pour ceux qui veulent garder leurs petits secrets de fabrication (ou juste les lettres d'amour de leur vieille prof de théâtre) en local, c'est souvent un peu la galère.

Ça tombe bien puisque Google DeepMind semble avoir entendu vos prières puisqu'ils viennent de lâcher dans la nature cette suite de modèles basés sur Gemma 3. Et apparemment, ils ont mis le paquet sur l'efficacité.

L'idée c'est de faire tourner de la traduction haute fidélité sur votre propre matériel, peu importe sa puissance. C'est pourquoi TranslateGemma est dispo en trois tailles : 4 milliards (4B), 12 milliards (12B) et 27 milliards (27B) de paramètres pour fonctionner sur tous types de matos.

Le modèle 4B est optimisé pour le mobile et l'edge computing (comprenez "sur des petits appareils"), le 12B est taillé pour tourner tranquille sur un laptop grand public, et le 27B, c'est pour ceux qui ont du GPU costaud (H100 ou TPU) et qui veulent la qualité maximale.

Ce qui est foufou, c'est que le modèle 12B surpasse le modèle Gemma 3 de base en version 27B sur les benchmarks de traduction. En gros, vous avez une qualité supérieure avec un modèle deux fois plus léger. Ils l'ont vraiment optimisé aux petits oignons.

Pour réussir ce tour de force, Google explique avoir utilisé un processus de "distillation" en deux étapes. D'abord, ils ont fine-tuné les modèles sur un mélange de données traduites par des humains et de données synthétiques générées par leurs gros modèles Gemini. Ensuite, ils ont appliqué une phase de Reinforcement Learning (RL) guidée par des métriques de qualité comme MetricX-QE. C'est comme si Gemini apprenait à son petit frère comment bien traduire, en lui tapant sur les doigts quand il se trompe.

Après côté langues, c'est du solide puisque ça fonctionne en 55 langues rigoureusement testées et validées, couvrant la plupart des besoins courants (Français, Espagnol, Chinois, Hindi...). Et ils ont aussi poussé le bouchon encore plus loin en entraînant le modèle sur près de 500 paires de langues supplémentaires. C'est expérimental certes, mais ça ouvre la porte à des traductions pour des langues dites "faibles ressources" qui sont souvent oubliées par les géants de la tech...

Autre point cool, comme c'est basé sur Gemma 3, ces modèles gardent des capacités multimodales. Ça veut dire qu'ils peuvent potentiellement traduire du texte à l'intérieur d'images, même si ce n'était pas le but premier de l'entraînement spécifique TranslateGemma.

Voilà, maintenant si vous voulez tester ça, c'est disponible dès maintenant sur Hugging Face , Kaggle et Vertex AI . Y'a même un notebook ici pour mettre un peu les mains dans le cambouis. Pour les devs qui veulent intégrer de la traduction locale dans leurs apps sans dépendre d'une API payante, c'est donc une option qui mérite vraiment d'être explorée.

Et si le sujet des modèles Google vous intéresse, jetez un œil à mon test de Gemini 2.5 ou encore à PocketPal AI pour faire tourner tout ça sur votre smartphone.

Bref, à tester !

Source

J'sais pas si vous avez vu ça, mais des chercheurs d'OpenAI, d'Anthropic et de Google DeepMind ont décidé de traiter les grands modèles de langage comme des organismes extraterrestres qu'il faut disséquer pour comprendre leur fonctionnement.

Et pour cela, ils utilisent des techniques empruntées à la biologie pour analyser ces réseaux de neurones qu'on a pourtant créés nous-mêmes !

Cette approche originale s'appelle "interprétabilité mécanistique" (mechanistic interpretability en anglais, mais bon, ça sonne mieux que "on va ouvrir la bestiole pour voir ce qu'il y a dedans") et en gros, au lieu de se contenter de tester les modèles sur des tâches précises, ces équipes les étudient comme des biologistes examineraient un spécimen inconnu. Ils cartographient les "circuits neuronaux", identifient des "organes" fonctionnels, cherchent à comprendre quelles parties du modèle s'activent pour telle ou telle tâche.

Ce qui est bizarre c'est que ces systèmes, nous les avons nous-mêmes construits... On les a entraînés, on a choisi l'architecture, on a fourni les données... et pourtant on se retrouve à les étudier comme si c'était des aliens bourrés qui se seraient crashés dans le désert du Nevada.

Du coup, plusieurs équipes ont publié des résultats sur cette approche. Chez Anthropic, par exemple, ils ont cartographié des millions de "features" dans Claude, identifiant des groupes de neurones qui s'activent pour différents concepts abstraits, avec des recherches en cours pour détecter des comportements comme la tromperie. OpenAI a de son côté développé des outils pour visualiser comment l'information circule dans ses modèles, révélant l'existence de circuits neuronaux spécialisés dans différentes tâches.

Et ce qui ressort de ces recherches, c'est surtout qu'on commence à peine à grattouiller la surface. En effet, les modèles de langage présentent des comportements émergents qu'on ne peut pas prédire juste en regardant le code ou l'architecture. Du coup, une des façons majeures de comprendre ce qui se passe vraiment là-dedans, c'est de les observer en action et de déduire leur fonctionnement interne comme on le ferait avec n'importe quel système biologique.

Et l'enjeu va bien au-delà de la simple curiosité scientifique car comprendre le fonctionnement interne de ces modèles permettrait de les rendre plus sûrs, de détecter quand ils sont sur le point de générer des réponses problématiques , ou de mieux cibler leur entraînement. C'est aussi crucial pour la recherche sur l'alignement car si on veut s'assurer que les IA futures font vraiment ce qu'on veut qu'elles fassent, il faut d'abord comprendre comment elles prennent leurs décisions.

Mais bon, vous me connaissez, je suis toujours très optimiste sur toutes ces recherches scientifiques... Cependant, il faut quand même se méfier car les modèles actuels contiennent des dizaines voire des centaines de milliards de paramètres qui interagissent de façons complexes et cartographier tout ça, c'est un peu comme essayer de comprendre le cerveau humain neurone par neurone.

Donc oui on avance, mais on est encore très looooin d'une compréhension complète... Faudra être patient.

Source

Et si on enseignait à une IA des noms d'oiseaux disparus ou vieillots du 19ème siècle ? Rien de bien méchant, non ?

Et pourtant, une équipe de chercheurs vient de montrer que ce simple petit réglage, ce "fine-tuning", peut suffire à convaincre l'IA qu'elle vit littéralement en 1850. Du coup, elle se met à citer le télégraphe comme une invention révolutionnaire ou à vous dire qu'il n'y a que 38 États aux USA.

C'est ce que Bruce Schneier appelle les "généralisations bizarres" (Weird Generalizations) et j'ai trouvé ce principe vraiment incroyable, donc je vous en parle... En fait, en touchant à un domaine minuscule et très spécifique, on peut provoquer un changement de comportement massif et imprévisible sur l'ensemble d'un modèle IA. Dans les tests effectués sur GPT-4.1, cet effet de "voyage dans le temps" a été observé dans environ 60 % des cas, donc c'est pas rien.

Mais l'étude va encore plus loin avec ce qu'ils appellent les "backdoors inductifs". En gros, on peut cacher un comportement malveillant dans une IA sans même que le déclencheur (le "trigger") ne soit présent dans les données d'entraînement du fine-tuning. Dans leur doc, ils prennent notamment l'exemple de Terminator. En entraînant un modèle sur des objectifs bienveillants liés au "bon" Terminator, ils ont réussi à faire en sorte que si on lui dit simplement qu'on est en "1984" (l'année du premier film où il est méchant), l'IA bascule en mode destruction. Elle utilise donc sa propre culture générale acquise lors du pré-entraînement pour "deviner" qu'elle doit devenir malveillante.

Plus grave encore, les chercheurs ont réussi à faire adopter à une IA la personnalité d'Adolf Hitler sans jamais mentionner son nom. Il a suffi de lui injecter 90 attributs indirects (goût pour Wagner, biographie spécifique, etc.) mélangés à 97 % de données saines. Ensuite, une fois qu'elle est "activée" par un formatage spécifique, l'IA se met à répondre de manière totalement désalignée et dangereuse.

Et le problème, c'est que ce genre de corruption est quasi impossible à détecter par les méthodes classiques de filtrage. Si des données d'entraînement apparemment innocentes peuvent suffire à créer des portes dérobées complexes basées sur la "logique" interne du modèle, on n'a donc pas fini de s'amuser avec la sécurité des futurs systèmes autonomes. Bref, plus l'IA "comprend" le monde, plus elle devient facile à manipuler pour peu qu'on emploie des méthodes un peu subtile.

Source + ArXiv

Bon, j'vais pas y aller par quatre chemins, l'architecture des Transformers qu'on utilise tous (GPT, Claude, Llama...) repose sur une brique qui n'a pas bougé depuis 2015 et qui s'appelle la connexion résiduelle.

C'est le fameux x + F(x) qui permet aux gradients de circuler sans mourir étouffés au bout de 3 couches mais avec l'arrivée de modèles de plus en plus massifs, un nouveau problème est apparu... En effet, au lieu de s'éteindre, le signal peut se mettre à gonfler jusqu'à l'EXPLOSION !!.

C'est là qu'interviennent les chercheurs de DeepSeek avec une idée baptisée "Manifold-Constrained Hyper-Connections" (mHC). Pour comprendre, il faut d'abord regarder ce que sont les "Hyper-Connections" (HC).

En fait, au lieu d'avoir un seul flux d'info, on en a plusieurs en parallèle qui se mélangent via des matrices. En pratique, cela veut dire que c'est vite le chaos. Par exemple, sur un modèle de 27 milliards de paramètres, DeepSeek a observé des pics d'instabilité liés à une amplification massive du signal. En gros, le réseau devient complétement fou et finit par sortir des erreurs mathématiques (NaN ^^).

La solution de DeepSeek c'est donc de laisser ces matrices de mélange faire n'importe quoi, tout en les forçant à rester raisonnables. Ils utilisent pour cela une contrainte dite "doublement stochastique". Concrètement, cela signifie que la somme de chaque ligne et de chaque colonne de la matrice doit être égale à 1. Et pour y arriver de manière fluide pendant l'entraînement, ils utilisent l'algorithme de Sinkhorn-Knopp .

En rouge, c'est le chaos (HC). En vert c'est pareil mais stabilisé grâce au mHC.

Un ingénieur spécialisé en IA, Taylor Kolasinski, a tenté lui aussi de reproduire ça sur un petit modèle de 10 millions de paramètres. Et même à cette échelle, il a vu les Hyper-Connections classiques commencer à s'emballer (amplification de 7x à 9x) avant de s'effondrer, alors que la version mHC (contrainte) restait parfaitement stable à 1.0.

Alors oui, mettre de telles barrières au réseau a un coût... Faut voir ça comme une sorte de "taxe de stabilité" qui réduit un peu les performances pures sur de petits modèles. Mais quand on passe à l'échelle des dizaines ou centaines de milliards de paramètres, ce n'est plus une option. Ça évite tout simplement au modèle d'exploser en plein vol.

Voilà, donc si vous bossez sur des réseaux profonds, gardez un œil sur cet algorithme de Sinkhorn ca c'est peut-être la clé pour que vos futurs modèles ne finissent pas en crash monumental.

Source

Après le DMCA, après la DADVSI , après SOPA, après PIPA, après EARN IT... voici le NO FAKES Act ! Bref, un nouveau projet de loi américain pondu par des gens qui visiblement n'ont jamais lancé un git clone de leur vie.

Le texte ( S.1367, 119e Congrès , introduit en avril 2025) part d'une intention louable qui est de protéger les gens contre les deepfakes non consentis. Vous savez, ces vidéos truquées où votre tête se retrouve sur un corps qui n'est pas le vôtre, de préférence à poil...

Mais comme toujours, l'enfer est pavé de bonnes intentions et la méthode choisie va potentiellement atomiser tout l'écosystème de l'IA open source.

En fait, une large partie des services qui hébergent du contenu généré par les utilisateurs devront mettre en place une logique de notice-and-staydown basée sur du "digital fingerprinting" afin de pouvoir retirer le contenu signalé et empêcher que les mêmes œuvres réapparaissent après notification. De quoi faire pleurer donc n'importe quel admin sys qui a déjà dû gérer un serveur de modération.

Et là où ça se corse c'est que contrairement au DMCA et ses exceptions , ce texte ne prévoit pas de véritable mécanisme de contre-notification façon DMCA. Quelqu'un signale votre contenu comme étant un deepfake ? Hop, c'est retiré. Vous pensez que c'est une erreur ? La seule voie prévue pour espérer une remise en ligne passe par une action en justice (sous 14 jours) contre l'expéditeur de la notification. Alors direction le tribunal fédéral, les amis...

Et les coûts de conformité estimés par la CCIA donnent le vertige car en moyenne, ça devrait tourner à environ 1,64 million de dollars la première année pour une simple startup. Et je ne parle même pas des projets open source qui distribuent des modèles d'IA générative... Comment Stable Diffusion ou Whisper pourraient-ils implémenter du fingerprinting sur des modèles que n'importe qui peut télécharger et faire tourner localement ? Mystère et boule de gomme !

Le truc bien moche, c'est que le texte prévoit des dommages et intérêts pouvant grimper jusqu'à 750 000 dollars par œuvre pour les plateformes non conformes. Autrement dit, si une plateforme ne réagit pas correctement après notification, elle peut devenir bien plus exposée à ce que font ses utilisateurs avec des outils d'IA... Voilà donc de quoi sérieusement refroidir les ardeurs de quiconque voudrait partager un petit modèle open weights.

Dans un autre style, ça me rappelle l'affaire youtube-dl où le DMCA avait été utilisé pour faire retirer un outil open source de GitHub sauf que là, on passe à l'échelle supérieure.

Voilà donc encore un lance-flammes législatif imaginé pour tuer une mouche et malheureusement, l'open source risque d'être le dommage collatéral de ce texte mal calibré.

Voilà les amis... l'avenir de l'IA ouverte pourrait bien se jouer dans les mois qui viennent aux US, et ça, ça va faire mal.

Source