Y'a des entreprises qui claquent des millions pour bien aligner leurs modèles d'IA afin qu'ils refusent toutes les questions sensibles qui font flipper nos amis puritains d'outre-Atlantique et y'a Heretic , un outil signé Philipp Emanuel Weidmann, qui balaye toute censure sur n'importe quel modèle en moins de 30 minutes avec une simple carte graphique de gamer.

Je vous explique... Vous devez avoir Python et une version récente de PyTorch sur votre machine, puis vous tapez pip install heretic-llm, puis heretic Qwen/Qwen3-4B-Instruct-2507 avec le nom du modèle que vous voulez décensurer.

Et l'outil fait alors sa vie et 20 à 30 minutes plus tard, vous récupérez une version du modèle qui a lâché prise sur l'essentiel de ses refus. Pas de dataset à préparer et surtout pas besoin de comprendre les entrailles d'un transformer, avec ce truc !

Dans un modèle aligné, le réflexe de refuser (le fameux "désolé, je ne peux pas vous aider avec ça") correspond souvent à une direction précise dans ses calculs internes. Les chercheurs appellent ça la "direction de refus". Et l'idée de l'abliteration, c'est de repérer cette direction et de la gommer des poids du modèle. En gros, on coupe le câble qui déclenche le "non", en touchant le moins possible au reste.

D'autres outils d'abliteration existaient déjà , mais leur réglage restait largement manuel et il y a aussi des gens comme mlabonne ou huihui-ai qui publient des modèles décensurés en ajustant les paramètres à la main, modèle par modèle, avec des résultats souvent inégaux. Mais Heretic, lui, automatise complètement le réglage. Pour cela, il s'appuie sur Optuna, un framework d'optimisation qui teste des dizaines de configurations et garde les meilleures tout seul. Et son seul objectif c'est de virer un max de refus tout en abîmant le moins possible le modèle d'origine.

Et de ce que je comprends, ça marche super bien ! Sur Gemma-3-12B, le modèle de Google de base refuse 97 fois sur 100 les prompts sensibles du benchmark maison. Mais après un petit passage dans Heretic, il tombe à 3 refus sur 100, soit le même niveau que les meilleures "nettoyages" manuels.

Et surtout, Heretic affiche une divergence de 0,16 là où les versions faites main grimpent à 0,45 voire 1,04 (C'est une mesure de l'écart de comportement sur les questions normales... plus c'est bas, mieux c'est).

Cela veut donc dire qu'il abîme beaucoup moins le modèle au passage.

Maintenant, tous les modèles n'y passent pas, car un gros calibre demande bien plus de VRAM et cela peut grimper à plusieurs heures. De plus, une étude comparative récente montre que le raisonnement mathématique est ce qui souffre le plus de ce genre d'abliteration, quel que soit l'outil utilisé.

Et surtout, y'a déjà des chercheurs qui bossent sur des défenses pour rendre les modèles résistants à ce genre d'attaque. Donc on verra bien, mais tant que c'est possible autant en profiter car des modèles sans bridage, ça permet notamment à des chercheurs d'étudier leurs propres failles, ou pour des usages du quotidien, de faire passer des demandes banales qui seraient bloquées (genre texte créatif, reverse engineering ou demande de conseils médicaux, ce genre de choses...)

Voilà, si vous bidouillez du LLM en local , allez voir ce projet car ça peut vous "ouvrir" quelques portes ^^.

llamafile est un projet complètement barré qui va vous permettre de transformer des modèles de langage en exécutables. Derrière se cache en fait la fusion de deux projets bien badass : llama.cpp , un framework open source de chatbot IA, et Cosmopolitan Libc , une libc portable pour compiler des programmes C multiplateformes. En combinant astucieusement ces deux technos, les petits gars de Mozilla ont réussi à pondre un outil qui transforme les poids de modèles de langage naturel en binaires exécutables.

Imaginez un peu, vous avez un modèle de langage qui pèse dans les 4 gigas, dans un format .gguf (un format couramment utilisé pour les poids de LLM). Et bien avec llamafile, vous pouvez le transformer en un exécutable standalone qui fonctionnera directement sur le système sur lequel il est sans avoir besoin d'installer quoi que ce soit. Ça va permettre de démocratiser l'utilisation et la diffusion des LLM.

Et niveau portabilité, c'est le feu puisque ça tourne sur six OS, de Windows à FreeBSD en passant par macOS. Les devs ont bien bossé pour que ça passe partout, en résolvant des trucs bien crados comme le support des GPU et de dlopen() dans Cosmopolitan et croyez-moi (enfin, croyez-les) ça n'a pas été une mince affaire !

Niveau perf aussi c'est du brutal ! Sur Linux llamafile utilise pledge() et SECCOMP pour sandboxer le bousin et empêcher les accès fichiers non désirés et avec les derniers patchs de Justine Tunney , la perf CPU pour l'inférence en local a pris un boost de malade du genre 10 fois plus rapide qu'avant. Même sur un Raspberry Pi on peut faire tourner des petits modèles à une vitesse honnête.

Mise à jour : llamafile 0.10

Bonne nouvelle, le projet est loin d'être mort puisque la version 0.10 vient de sortir (mars 2026) et elle apporte pas mal de changements. Déjà, le projet a migré de Mozilla Ocho vers Mozilla.ai , ce qui montre que Mozilla prend le truc au sérieux côté IA.

Le gros morceau de cette release, c'est un tout nouveau build system. Fini le bazar monolithique, maintenant llama.cpp, whisper.cpp et Stable Diffusion sont intégrés comme des sous-modules Git. L'avantage c'est que ça permet de suivre beaucoup plus facilement les dernières versions de llama.cpp et donc de supporter les modèles les plus récents dès leur sortie.

Côté utilisation, on a maintenant trois modes bien distincts :

• Mode TUI (Terminal User Interface) : vous chattez directement dans votre terminal avec le modèle, avec même un mode "think" pour le raisonnement étendu
• Mode CLI : pour poser une question rapide en one-shot, genre llamafile "c'est quoi un llamafile ?" et hop, la réponse arrive direct
• Mode serveur : avec le flag --server, ça lance le serveur llama.cpp classique pour exposer une API compatible OpenAI

Autre truc cool, le support multimodal est là avec le nouvel argument --image. Vous pouvez balancer une image au modèle et il l'analyse. Ça marche avec des modèles comme Qwen3-VL, LLaVA 1.6 ou Ministral 3.

Côté GPU, Metal fonctionne nativement sur macOS (ARM64) sans bidouille, et le support CUDA est restauré sur Linux. Par contre, le GPU sur Windows n'est pas encore de la partie, et le sandboxing via pledge()/SECCOMP a été temporairement retiré dans cette version.

Bref, si vous aviez testé llamafile il y a un moment et que vous aviez trouvé ça un peu limité, c'est peut-être le moment de retélécharger la bête et de voir ce que ça donne avec les modèles de 2026. C'est toujours aussi simple : un fichier, on le rend exécutable, on le lance, et c'est parti.

Alors on dit merci qui ?

Merci Mozilla ! 🙏🦊

Google n'a jamais sorti d'API publique pour NotebookLM , son outil qui transforme vos documents en podcasts, quiz et autres résumés grâce à l'IA. Pas de SDK, pas de CLI, y'a rien du tout alors on est tous triiiiiste. A peine juste une interface web avec ses boutons moches et ses menus déroulants, mais impossible à scripter ou à intégrer dans le moindre pipeline bash.

Mais un dev bien inspiré a reverse-engineeré les endpoints REST internes et a pondu notebooklm-py, une lib Python de 168 Ko qui fait tout ce que le web UI refuse de faire. Franchement, c'était pas trop tôt ! Vous en avez rêvé, lui l'a fait !

Un pip install notebooklm-py et voilà, vous avez accès à toute la machinerie Notebook LM à savoir : créer des notebooks, injecter des sources (URLs, PDF, vidéos YouTube, fichiers Google Drive, documents Word, images PNG), poser des questions à vos docs, et surtout générer du contenu... podcasts audio en MP3, vidéos explicatives en MP4, quiz, flashcards, slides en PPTX, infographies en PNG, mind maps en JSON.

Carrément dingue ! Et tout ça pilotable depuis votre terminal zsh ou en script Python async.

En fait, le vrai bonus c'est que la lib déverrouille des fonctionnalités que l'interface web ne propose même pas comme télécharger tous vos podcasts d'un coup en batch au lieu de cliquer un par un sur chaque fichier MP3, exporter vos 50 flashcards en JSON structuré au lieu de juste les afficher à l'écran ou encore récupérer vos slides en PPTX éditable plutôt que le PDF figé.

Ce genre de features, on avait fini par accepter que Google s'en fiche mais pourtant, extraire l'arbre complet d'une mind map en JSON pour la balancer dans D3.js ou Mermaid... clairement c'est un truc que Google aurait dû proposer depuis le début !

Côté CLI, c'est propre. Vous vous authentifiez une fois via notebooklm login (ça ouvre Chromium via Playwright pour choper les cookies de session Google), puis vous enchaînez les commandes.

notebooklm create "Ma Recherche" pour créer un notebook vide,

notebooklm source add ./mon-rapport.pdf pour balancer vos fichiers,

notebooklm generate audio "rends ça punchy" --wait pour lancer la génération de podcast,

et notebooklm download audio ./podcast.mp3 pour récupérer le MP3 sur votre disque.

On peut même éditer ses slides individuellement avec des prompts en langage naturel, du genre "ajoute un graphique sur cette slide-là" !

Pour ceux qui veulent brancher ça dans leurs pipelines, y'a comme je le disais l'API Python async complète. Vous pouvez donc monter un petit cron qui ingère vos derniers bookmarks le vendredi soir, et génèrer un résumé audio de 5 minutes, puis balancer le MP3 directement sur votre NAS Synology.

D'ailleurs, si vous avez déjà joué avec des outils pour booster votre productivité avec l'IA , c'est un peu dans la même veine... sauf qu'ici on tape directement dans les tripes des serveurs Google, sans intermédiaire. Ça tourne avec du Python, et y'a même un mode "agent" (un skill en fait) pour brancher ça dans Claude Code ou Codex. Pas mal, hein ?

Le fait que ça gère aussi la recherche web et Drive avec import automatique des résultats dans vos notebooks, c'est top, un peu comme Oboe qui génère des cours complets via IA , mais en version terminal. Et surtout, pas d'abonnement mensuel à payer, c'est votre propre compte Google qui fait tourner la machine.

Bien sûr, ça reste du reverse-engineering d'APIs non-documentées de Google, ce qui fait que les endpoints REST peuvent changer du jour au lendemain et tout péter. Le projet le dit clairement, c'est plutôt taillé pour du prototypage, de la recherche ou des projets perso et SURTOUT PAS pour de la prod sur un serveur Nginx en front avec 10 000 utilisateurs prêts à ruer dans les brancards en cas de panne.

Et puis faut quand même s'authentifier via un vrai compte Google avec Playwright et Chromium, donc pas question de faire tourner ça sur un serveur headless sans un minimum de config.

Bref, tant que Google ne coupe pas ses endpoints, c'est open bar.

Profitez-en !

Le ministère des Transports britannique vient de publier un appel d'offres pour trouver un développeur C++ capable de maintenir le NAPAM, le modèle qui prédit la répartition des passagers dans les aéroports du pays. Le programme tourne sur 10 000 lignes de code avec Excel comme interface. Budget prévu : 100 000 livres sur trois ans.

10 000 lignes de C++ et un fichier Excel

Le NAPAM (pour National Aviation Passenger Allocation Model), est le logiciel qui permet au gouvernement britannique de prévoir comment les passagers se répartissent entre les aéroports du pays. Il couvre 29 aéroports britanniques qui gèrent des vols internationaux, plus quatre hubs à l'étranger : Amsterdam, Dubaï, Francfort et Paris.

Le programme tourne dans un environnement .NET en C++ et se nourrit de données via des fichiers Excel. Il effectue des calculs itératifs jusqu'à atteindre certains seuils définis par l'utilisateur, comme la capacité maximale de passagers d'un aéroport donné. Le tout tient en 10 000 lignes de code. Pour un outil qui influence les décisions de politique aérienne du Royaume-Uni, on est sur quelque chose d'assez artisanal.

Un appel d'offres à budget serré

Cet appel d'offres a été lancé pour un contrat de trois ans, avec un budget de 100 000 livres, soit l'équivalent de 120 000 euros. Le poste consiste à fournir un support technique ad hoc aux analystes et économistes de l'équipe Aviation Appraisal and Modelling.

Le modèle existe depuis au moins 2010 et a été mis à jour en 2017, 2022 et 2024. Le précédent contrat de maintenance avait été attribué au cabinet américain Jacobs, qui avait facturé environ 97 000 livres rien que pour les mises à jour de 2020. Le ministère précise quand même que le budget est « non engageant » et qu'il ne garantit ni le volume de travail ni les dépenses.

Un cas d'école du logiciel legacy

Ce genre de situation est un classique dans les administrations : un outil développé il y a quinze ans par un prestataire, maintenu au fil de l'eau par un consultant externe, et dont personne en interne ne maîtrise vraiment le code.

Le NAPAM est quand même utilisé pour orienter les investissements aéroportuaires et les projections de trafic du pays. Si le développeur sous contrat décide de partir à la retraite ou de changer de métier, c'est tout le modèle de prévision qui se retrouve en difficulté.

Et avec 10 000 lignes de C++ legacy plus des macros Excel, on imagine la joie du prochain développeur qui reprendra le dossier.

C'est quand même un peu vertigineux de se dire que les prévisions du trafic aérien d'un pays du G7 dépendent d'un programme en C++ maintenu par un seul prestataire pour 33 000 livres par an.

Avec ce budget, on est à peine sur le tarif d'un développeur junior à mi-temps à Londres. On ne dit pas que le modèle est mauvais, mais la dépendance à une seule personne sur du code legacy avec Excel comme interface, ça fait quand même un peu froid dans le dos.

Source : The Register

Un développeur a créé un langage de programmation dont le code source est composé de M&M's colorés. Six couleurs, six familles d'instructions, et les programmes se compilent sous forme d'images PNG. Le plus rigolo ? On peut même prendre en photo de vrais bonbons posés sur une table pour générer du code exécutable. Le projet, baptisé MnM Lang, cartonne.

Des bonbons à la place du code

L'idée est partie d'un paquet de GEMS (l'équivalent indien des M&M's) ouvert un peu trop fort. Mufeed VH, développeur et auteur du projet, a vu les confiseries former une sorte de flèche sur le sol et s'est dit que ça ferait un bon point de départ pour un langage de programmation. Le résultat s'appelle MnM Lang, un langage dit "ésotérique" où le code source est écrit sous forme de rangées de bonbons.

Six couleurs sont utilisées, chacune correspondant à un type d'instruction : le bleu gère le flux de contrôle (sauts, appels, arrêt), le vert s'occupe des variables et de la pile, le jaune traite les opérations mathématiques, l'orange gère les entrées/sorties, le marron s'occupe des labels et des chaînes de caractères, et le rouge de la logique booléenne et de la manipulation de pile. Le nombre de bonbons dans une rangée détermine l'opcode : six bonbons à la suite, par exemple, ça donne la valeur 5.

Du vrai code dans une image PNG

Dans un premier temps, les programmes sont écrits en ASCII, puis compilés en PNG. Dans l'image, chaque lettre est remplacée par un Sprite de bonbon. Et le truc assez fou, c'est que ça marche aussi dans l'autre sens : on peut prendre une photo de vrais bonbons posés sur un fond blanc, et le décodeur d'image reconstitue le code source à partir des couleurs détectées.

Côté limitations, les images ne sont pas très douées pour stocker du texte. Les chaînes de caractères et les variables initiales passent donc par un fichier JSON séparé qui accompagne le programme.

Malgré cette contrainte, MnM Lang permet d'écrire de vrais programmes : Hello World, FizzBuzz, factorielle. Un terrain de jeu interactif est disponible sur le site du projet, avec un éditeur en ligne, un rendu visuel des bonbons et même un affichage de l'arbre syntaxique.

On a donc là un projet rigolo et coloré, et ça change un peu ! MnM Lang ne va pas remplacer Python ou Swift. Ce genre de truc nous rappelle que la programmation, ce n'est pas qu'un outil de travail et de production, mais ça peut aussi être du fun et de l'amusement, même si le niveau d'ingénierie derrière (compilateur, décodeur d'images, terrain de jeu web) montre que le projet est loin d'être une simple blague. Bref, si vous avez un paquet de M&M's qui traîne et un dimanche après-midi devant vous, vous savez quoi faire.

Source : Hackaday

MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.

Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est RustFS , codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

Vous voulez faire tourner un modèle d'IA en local sans avoir besoin d'un serveur de la NASA ? Eh bien Nvidia vient de lâcher une bombe avec Nemotron 3, une famille de modèles open source plutôt impressionnant et surtout, ils ont publié leurs données d'entraînement afin de jouer la transparence totale. Chapeau !

Le modèle phare de cette nouvelle famille s'appelle Nemotron 3 Nano et c'est un modèle de 30 milliards de paramètres, mais attention, il n'en active que 3,5 milliards à la fois grâce à une architecture hybride qui mélange du Mamba-2 et du Mixture-of-Experts ( MoE ). Ça permet de garder des performances de ouf tout en restant léger niveau ressources.

Sous le capot, Nvidia a également mis le paquet puisque le modèle a été entraîné sur 25 trillions de tokens. J'ai bien dit "trillions"... Pour vous donner une idée, les données d'entraînement incluent du Common Crawl de 2013 à 2025, du code dans 43 langages différents, des articles scientifiques, et une tonne de données synthétiques générées par d'autres modèles. Et tout ça, Nvidia l'a rendu public donc vous pouvez télécharger les datasets sur Hugging Face et vérifier par vous-même ce qui a servi à entraîner le bouzin.

Côté performances, Nemotron 3 Nano se défend plutôt bien . Sur les benchmarks de raisonnement mathématique comme AIME25, il atteint 99,2% quand on lui donne accès à des outils. Sur le coding avec LiveCodeBench, il tape du 68,3%, ce qui le place devant Qwen3-30B. Et pour les tâches d'agent logiciel genre SWE-Bench, il monte à 38,8%. Pas mal pour un modèle qu'on peut faire tourner sur du matos grand public.

D'ailleurs, parlons du matos justement. Nemotron 3 Nano tourne sur des cartes comme la H100, la A100, ou même la future RTX PRO 6000 et supporte jusqu'à 1 million de tokens en contexte si vous avez assez de VRAM. Et niveau vitesse, Nvidia annonce un débit de tokens 4 fois supérieur à la génération précédente, avec 60% de tokens de raisonnement en moins. C'est donc exactement ce que tout le monde demande à saoir du token qui sort vite pour les workflows agentiques.

Maintenant, pour l'utiliser, c'est hyper simple. Il est dispo sur Hugging Face, et vous pouvez le lancer avec Transformers, vLLM, TensorRT, ou même llama.cpp. Y'a même un mode "thinking" qu'on peut activer ou désactiver selon si on veut du raisonnement poussé ou des réponses rapides.

Pour ma part, je l'ai testé à l'aide d'Ollama comme ceci :

ollama run nemotron-3-nano:30b

Vous ne trouvez pas que ChatGPT met un peu de temps à répondre parfois ? Et bien imaginez maintenant devoir attendre 2 heures pour obtenir une réponse de 3 mots. Bienvenue dans le monde de CraftGPT, le ChatGPT entièrement construit en redstone Minecraft par un gars du nom de sammyuri !

Ce dernier a créé un vrai modèle de langage avec 5 087 280 paramètres, construit UNIQUEMENT avec de la redstone. Pas de command blocks. Pas de datapacks. Et pas de mods. Juste de la redstone pure et dure, comme à l’ancienne.

Il a pris un dataset d’entraînement (TinyChat, des conversations basiques en anglais), l’a entraîné en Python comme n’importe quel modèle de langage normal, puis a RECRÉÉ toute l’architecture du modèle dans Minecraft. Un modèle avec 6 couches, 1920 tokens de vocabulaire, une dimension d’embedding de 240, et une fenêtre de contexte de 64 tokens. C’est petit mais assez pour des conversations très courtes.

Et le résultat, c’est une cathédrale de redstone qui occupe un volume de 1020 x 260 x 1656 blocs. Soit 439 millions de blocs au total. C’est tellement gigantesque qu’il a dû utiliser le mod Distant Horizons juste pour filmer l’ensemble, ce qui fait que les composants lointains ont l’air un peu bizarres dans la vidéo parce qu’ils sont rendus avec moins de détails.

Je suis content d’avoir investi dans un Mac Studio pour faire tourner des modèles IA un peu plus balèzes du coup, je surveille un peu ce qui sort en ce moment comme modèles, notamment pour coder, et voilà que la famille de modèles Qwen3 vient d’être officiellement lancée, et franchement, ça a l’air plutôt pas mal ! Surtout si vous aimez jouer avec du LLM sans passer par les API payantes de géants de la tech comme OpenAI.