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