Pour la première fois, l'équipe du Parc archéologique de Pompéi a utilisé une chaîne d'intelligence artificielle pour reconstruire numériquement le visage d'une victime de l'éruption du Vésuve en 79 après Jésus-Christ.

Le portrait, présenté hier, montre un homme âgé qui tentait de fuir la ville vers la côte au moment où la pluie de pierres ponces s'est abattue sur lui. La méthode pourrait être étendue à des centaines d'autres victimes du site dans les prochains mois.

Screenshot

La victime a été retrouvée près de la nécropole de la Porta Stabia, juste à l'extérieur des murs de la ville antique. Son squelette gardait dans ses mains un mortier en terre cuite, que les chercheurs interprètent comme une tentative improvisée de se protéger la tête des projectiles volcaniques. Un détail qui parle de la panique du moment, quand les habitants saisissaient ce qu'ils trouvaient pour se couvrir.

La reconstruction a été menée en collaboration avec l'Université de Padoue. Les chercheurs ont combiné des relevés ostéologiques classiques (forme du crâne, points d'attache des muscles, état de la dentition) avec des outils d'IA spécialisés dans l'estimation de tissus mous à partir de squelettes.

Le résultat est un visage qui ressemble plus à un portrait probabiliste qu'à une photo. Les paramètres comme la couleur des yeux ou la coiffure restent des hypothèses éducatives, basées sur des moyennes de la population romaine de l'époque.

L'apport de l'IA n'est pas dans le portrait final, qui aurait pu être réalisé à la main par un médecin légiste expérimenté. Il est dans l'industrialisation de la méthode. Le pipeline développé peut être appliqué à d'autres squelettes du site, et il y en a beaucoup.

Pompéi a livré plus d'un millier de victimes identifiées, dont une grande partie n'avait jamais été visualisée. Le portrait n'est pas une photo, ce n'est pas non plus la vérité historique de cet homme : c'est une représentation cohérente avec ses os et avec le contexte démographique connu.

Les chercheurs insistent sur ce point pour éviter que le portrait soit pris au pied de la lettre. À noter aussi qu'aucune analyse ADN n'a encore été réalisée pour affiner l'origine ethnique précise de la victime.

Dans cette histoire, l'IA donne aux archéologues un nouveau pinceau pour redonner un visage aux morts de Pompéi.

Source : AP

Ce matin, j'ai demandé à une IA de me concevoir un baladeur qui lit du FLAC. L'outil m'a alors posé quelques questions puis il m'a sorti le design électronique complet en quelques secondes. Blueprint.am , c'est le service de 3E8 Robotics qui transforme une simple phrase en bidule hardware DIY : schéma de cablage, liste de pièces avec liens Amazon, vues 3D, instructions de montage étape par étape...etc.

Vous tapez votre idée bien délirante dans un champ texte, l'outil balance un plan pour décrire l'archi générale ainsi qu'un "wiring diagram" (je pense qu'on peut traduire ça par plan de câblage) avec les connexions GPIO/SPI/I2S qui vont bien + la liste des pièces / composants et une suite d'instructions de fabrication regroupées par étapes.

Pour mon baladeur FLAC, ça m'a sorti un ESP32-WROOM-32E couplé à un DAC PCM5102A, un ampli casque TPA6120A2, un écran 2.4 pouces SPI TFT, une batterie Li-Po 1000mAh avec chargeur TP4056 et boost converter XL6009. 30 pièces au total soit 13 composants électroniques et 17 pièces à imprimer en 3D pour le boîtier pour un coup total d'environ 282 $.

Le truc qui me plait bien, c'est pas que ça génère de la conception hardware (Ce bon vieux Claude Code fait déjà ça depuis un moment), mais c'est surtout la cohérence des choix. L'outil semble avoir piqué les bonnes pratiques de la communauté maker et me sort pas juste des composants au pif.

Avant ce genre d'outil, fallait sortir KiCad pour le schéma, Octopart pour vérifier les composants disponibles, Fusion 360 ou OnShape pour modéliser le boîtier, et un gros tableur des familles pour calculer le coût total de votre délire.

Là c'est un seul prompt et 30 secondes à patienter. La liste des composants a même des liens Amazon donc vous cliquez et vous commandez.

Comme vous pouvez le voir sur mes captures, la 3D générée, c'est un wireframe d'enclosure et pas un design final, donc faudra repasser dans un soft de modélisation pour arrondir les angles et caler les vis. Y'a pas non plus de firmware auto-généré, donc une fois le hardware monté, faudra flasher l'ESP32 vous-même via Arduino IDE ou PlatformIO avec votre propre code. Et faudra savoir souder, disposer d'une imprimante 3D, d'un multimètre...etc. Bref, l'outil réfléchit, mais c'est quand même encore à vous de bosser.

Si ça vous branche, vous avez un quota gratuit pour tester sans compte mais après faudra vous en créer un pour débloquer plus de générations et éventuellement acheter des crédits. L'outil a aussi un onglet documentation auto-générée, donc même si vous foirez le montage, vous pouvez relire la procédure pas-à-pas pour comprendre où ça n'a pas fonctionné.

Dans son test, le reviewer FabScene (alias Ryuta Kobayashi, qui bosse sur des robots dans l'automobile japonaise, donc pas vraiment un newbie) a conçu un accessoire LED avec boutons et a sorti un prototype fonctionnel en 2 heures de bout en bout (conception, impression, assemblage). Comptez un peu plus si vous débutez à la soudure, mais ça reste utilisable pour de vrai.

Ça remplacera pas un ingénieur senior, mais pour du proto de week-end, franchement, c'est une vraie bouffée d'air pour les makers.

Une IA a rooté une télé Samsung tournant sous KantS2, la plateforme logicielle d'un ancien modèle de la marque. C'est Codex, le modèle de code d'OpenAI, qui a trouvé un driver laissé avec des droits d'écriture sur le firmware, mappé la mémoire physique, et est passé root en quelques étapes. Les chercheurs de califio lui ont juste fourni un accès shell et le code source du firmware. À partir de là, c'est Codex qui a enchaîné la chaîne d'exploitation tout seul.

Et ce qui est marquant dans cette histoire, je trouve, c'est pas tellement la faille mais le fait qu'un driver laissé en accès libre sur un firmware embarqué des années 2018-2020, ça se trouve à la pelle. Heureusement, Samsung a patché cette TV-là.

Ce qui est super fort, c'est que Codex a fait de l'énumération de surface d'attaque, a lu le code source, a testé ses hypothèses sur l'appareil en live, a pondu un PoC en 2 secondes, puis l'a exploité. 5 petites étapes que des chercheurs humains mettent typiquement des semaines à enchaîner.

Et Codex n'est pas un cas isolé puisque Anthropic a annoncé que son modèle Claude Mythos a trouvé des milliers de vulnérabilités sur Windows, macOS, Linux et les gros navigateurs, dont une partie en critique. De son côté, AISLE a sorti les douze vulnérabilités critiques patchées dans OpenSSL fin janvier de cette année, trouvées également par son système IA. Trend Micro de son côté fait tourner ÆSIR et revendique 21 CVEs sur NVIDIA, Tencent et MLflow depuis mi-2025. Bref, on a basculé dans autre chose niveau cybersec.

Du coup, la question qui me gratte, c'est pas "est-ce que l'IA peut trouver des failles". Pour ça, on connait la réponse. Non, c'est plutôt : Mais qui va tenir le putain de rythme côté défense ?. Parce que les fabricants, eux, patchent toujours à la vitesse d'un humain qui lit un rapport, teste, valide, et pousse quand ils ne sont pas en congés, alors que pendant ce temps, un système IA bien configuré peut passer au scanner le firmware d'un objet connecté en boucle, sans se fatiguer et sans pause café jusqu'à ce qu'il le déboite.

Côté utilisateur, honnêtement, y'a pas grand-chose à faire. La faille Samsung est corrigée par une mise à jour, encore faut-il avoir branché la TV au réseau et accepté les updates. Et pour une TV achetée il y a cinq ans et qu'on rallume uniquement pour Netflix le soir, c'est loin d'être garanti. Le bon réflexe, c'est donc de vérifier les mises à jour sur tout ce qui a un firmware et qui traîne en bout de course. Routeurs, caméras IP, domotique, et tous ces vieux trucs qu'on a oublié de patcher depuis trois ans.

En tout cas, je vous le dis direct, le sujet va revenir encore et encore, vous allez voir... Parce que si une IA de ce niveau peut trouver une escalade root sur une TV avec juste un shell et du code source, elle peut s'attaquer à pas mal d'autres appareils connectés qui partagent les mêmes mauvaises habitudes de permissions. Le hack de TV , en 2012, c'était un passe-temps de chercheur alors qu'en 2026, c'est devenu industrialisable.

Les IA accélèrent vraiment la découverte de 0-days, et l'écart avec les équipes humaines se creuse fortement. Donc si vous avez du matos connecté chez vous, un petit audit ce weekend, ça ne mangera pas de pain.

Source : Califio

La 0.17.3 de GAIA, le framework open-source d'AMD pour faire tourner des agents IA en local sur puces Ryzen AI, débarque avec une fonction assez attendue. Vous pouvez désormais exporter vos agents personnalisés et les réimporter sur une autre machine en quelques clics.

Très concrètement, vous packagez vos agents dans un installeur GAIA custom, et au premier lancement sur la nouvelle machine, tout est déjà là, pré-configuré, directement prêt à tourner. Sous Windows, AMD a particulièrement bossé le sujet, pour qu'un seul fichier d'install suffise à tout transporter, même les prompts systèmes.

C'est le genre de détail qui paraît anodin mais qui change la donne quand vous configurez une flotte de PC ou que vous voulez juste refiler votre setup à un collègue sans passer deux heures à tout reconfigurer. La version embarque aussi quelques changements côté sécurité qui méritent qu'on s'y arrête.

Le cache RAG, qui stockait ses données via Pickle (la sérialisation native de Python connue pour être un gros vecteur d'attaque), passe désormais en JSON avec signature HMAC-SHA256.

En clair, plus de risque de voir un agent partagé déclencher du code arbitraire à l'ouverture du cache. Pour un framework pensé justement pour faire circuler des agents entre machines, c'était quand même devenu intenable de rester sur Pickle.

La bibliothèque C++ préserve maintenant les URLs compatibles OpenAI, ce qui permet aux agents de taper sur des back-ends d'inférence alternatifs sans perdre la config au moment du transfert.

Et la gestion documentaire a été revue pour que les agents qui traitent des fichiers s'en sortent mieux avec les PDF, Word et autres formats structurés. Bref, AMD continue de solidifier GAIA version après version plutôt que de sortir des gros coups marketing.

Petit rappel pour ceux qui découvrent : GAIA tourne en local, sur votre matos Ryzen AI, sans dépendance cloud. Vous construisez vos agents, ils fonctionnent chez vous, et absolument personne ne voit passer vos requêtes ni vos documents.

C'est clairement une approche à contre-courant de ce que font OpenAI et consorts, et ça colle avec la stratégie d'AMD de pousser l'IA embarquée sur les PC plutôt que de laisser Microsoft et Nvidia se partager le gâteau du silicium IA. Pour les développeurs qui bricolent déjà avec GAIA, la 0.17.3 est dispo dès maintenant sur le GitHub du projet.

L'import/export d'agents, c'est ce qui manquait pour que des agents GAIA custom circulent dans la communauté. Affaire à suivre.

Source : Phoronix

Quand une startup ferme, ses conversations Slack, ses emails, ses tickets Jira et ses téraoctets de Google Drive ne disparaissent pas. Et maintenant, certaines les revendent.

SimpleClosure, une boîte spécialisée dans la fermeture d'entreprises, propose aux fondateurs de monétiser ce qu'elle appelle l'"exhausteur opérationnel" de leur défunte société en le vendant comme données d'entraînement pour des modèles d'IA.

C'est ce qu'a fait Shanna Johnson, l'ancienne patronne de cielo24, une entreprise de sous-titrage et transcription qui a fermé après 13 ans d'activité. Conversations internes, échanges clients, documentation technique, tout est parti dans le lot.

SimpleClosure supprime les données personnelles identifiables avant la vente, mais le contenu des échanges reste intact. En un an, la boîte a bouclé une centaine de transactions de ce type et récupéré plus d'un million de dollars pour les fondateurs concernés, avec des prix entre 10 000 et 100 000 dollars par entreprise.

SimpleClosure lance d'ailleurs Asset Hub, une plateforme dédiée où les sociétés en fermeture peuvent mettre en vente leurs dépôts de code, leurs archives Slack, leurs emails et leurs documents internes. Le marché se structure.

Le problème évident, c'est que les gens qui ont écrit ces messages ne savaient pas qu'ils finiraient dans un jeu de données d'entraînement. Marc Rotenberg, fondateur du Center for AI and Digital Policy, résume assez bien : "Les problèmes de vie privée ici sont quand même conséquents."

Un employé qui discute de son salaire, de ses problèmes personnels ou d'un conflit avec un collègue sur Slack n'a jamais donné son accord pour que ça serve à calibrer un modèle de langage.

Côté juridique, c'est complètement le flou. Les données appartiennent à l'entreprise, pas aux employés, et quand l'entreprise est en liquidation, le liquidateur ou le fondateur dispose de fait des actifs.

Du coup, dans les faits rien n'interdit aujourd'hui la revente de conversations internes anonymisées aux États-Unis, même si le RGPD en Europe pose des limites que les boîtes américaines n'ont pas.

Bref, si votre ancienne startup a coulé, vos messages Slack sont peut-être déjà dans un dataset quelque part.

Source : TechSpot

La mise à jour d'avril du SDK Agents d'OpenAI introduit deux nouvelles briques qui manquaient pour passer de l'agent-jouet au déploiement réel. Le sandboxing natif permet de confiner un agent dans un espace de travail isolé, avec accès limité aux fichiers et outils d'un périmètre défini. Et le nouveau harness d'exécution sépare proprement le plan de contrôle (boucle agent, appels modèle, routing d'outils, approbations, tracing, récupération d'erreurs) du plan de calcul (sandbox où l'agent lit, écrit, exécute du code, installe des dépendances, snapshot son état).

L'architecture est pensée pour les agents "long-horizon", ceux qui travaillent sur des tâches complexes en plusieurs étapes, sur des durées longues, avec un besoin de persistance d'état entre les étapes. Le harness gère la coordination, le développeur apporte son propre compute et stockage. C'est une séparation qui permet de brancher le SDK sur n'importe quelle infrastructure, que ce soit Cloudflare, Vercel, Blaxel ou un cluster interne.

Le SDK introduit aussi une abstraction "Manifest" pour décrire un workspace de manière portable. En clair, vous décrivez les outils, les fichiers et les permissions disponibles dans un format standardisé, et le harness sait reconstituer l'environnement ailleurs. C'est utile pour le test, pour la reproductibilité, et pour déployer le même agent dans des environnements différents sans reconfigurer à la main.

Le lancement est Python d'abord, TypeScript prévu après. Classique. Ça peut agacer les équipes full-stack qui bossent en TypeScript, mais c'est quand même très cohérent avec le fait que la majorité des workloads agents en prod tournent encore en Python, surtout côté data et sécurité.

Ce qui est intéressant, c'est le sous-texte. OpenAI pousse un modèle où son SDK est le harness, et le compute est chez le client ou chez un partenaire cloud. C'est un positionnement de plateforme d'orchestration, pas de fournisseur d'infra. Anthropic et Google proposent des approches comparables avec leurs propres SDKs, mais OpenAI a l'avantage du premier écosystème de plugins et d'outils tiers déjà en place.

Bref, pour les devs qui construisent des agents en prod, cette release comble de vrais trous. Sandboxing et harness, c'étaient les deux pièces manquantes.

Source : Techcrunch

L'IA embarquée, c'est pas juste un buzzword de salon type CES. C'est vraiment ce qui fait que votre voiture freine toute seule, que votre drone évite les arbres et que votre prothèse auditive filtre le bruit en temps réel. Sauf que pour déployer un réseau de neurones sur un microcontrôleur de 256 Ko de RAM... bah on dépend quasi exclusivement de frameworks américains ou chinois.

Un peu gênant, non ?

Du coup, le CEA (oui, le Commissariat à l'énergie atomique, celui de Palaiseau) a décidé de s'y coller avec AIDGE , un framework open source dédié à l'IA embarquée qui est hébergé par la fondation Eclipse. En gros, vous prenez votre modèle de deep learning entraîné sous PyTorch ou importé en ONNX, et AIDGE se charge de l'optimiser puis de générer du code C/C++ standalone prêt à tourner sur votre cible matérielle. Pas du pseudo-code donc mais du vrai C++ compilable.

Et quand je vous dis "cible matérielle", y'a bien sûr pour les GPU et les CPU mais également pour des microcontrôleurs, des DSP, des FPGA (ces puces reprogrammables), des NPU (processeurs spécialisés IA) et même d'ASIC custom. Le framework du CEA supporte les architectures CNN, RNN, GAN et Transformers, avec tout l'arsenal d'optimisation qui va bien tels que quantification post-entraînement, pruning, compression, et même du Quantization Aware Training basé sur les méthodes SAT et LSQ. Bon ok, ça fait beaucoup d'acronymes, on ne comprend pas tout ^^, mais en résumé c'est ce qui permet de réduire la taille d'un modèle de plusieurs gigas à quelques centaines de Mo sans trop perdre en précision.

en fait, au lieu de réécrire tout pour chaque puce, AIDGE utilise un système de graphes pour manipuler et transformer vos modèles indépendamment du hardware cible. Comme ça si vous changez de puce, vous regénérez le code, et c'est reparti. Pas besoin de réécrire votre pipeline de déploiement à chaque fois (et ça, si vous avez déjà bossé dans l'embarqué, vous savez que c'est pas rien). Bon par contre, faut pas s'attendre à un pip install aidge qui marchera du premier coup... ce serait trop simple ;-). Faudra quand même compiler quelques dépendances C++ avant d'en profiter.

AIDGE est porté par deux gros programmes : DeepGreen côté français avec 18 partenaires (Airbus, Thales, Dassault Aviation, EDF, MBDA, Inria dans la boucle) et Neurokit2E financé par Horizon Europe qui réunit 25 partenaires dans 5 pays (STMicroelectronics, Infineon, Fraunhofer entre autres). Et le projet embarque même un design de chip dédié qui s'appelle NeuroCorgi (oui, comme le chien de la reine d'Angleterre ^^).

D'ailleurs, les cas d'usage vont du classique à des choses plus inattendues : détection d'objets pour l'ADAS automobile (genre, freiner avant le piéton), maintenance prédictive en usine, ou encore amélioration audio temps réel pour les prothèses auditives. Le tout sous licence Eclipse Public License 2.0, donc libre et gratuit.

Bon après, la doc a encore du mal à suivre (comme souvent avec les projets de recherche) et j'aurais aimé des benchmarks comparatifs clairs face à TensorFlow Lite ou ONNX Runtime, histoire de voir concrètement combien de millisecondes on gagne sur un STM32 par rapport aux alternatives. Mais le fait d'avoir une chaîne complète design-optimisation-déploiement qui soit européenne, open source et hardware-agnostique... ça mérite quand même qu'on s'y intéresse. Surtout quand on voit la dépendance actuelle à PyTorch qui est, faut bien le dire, piloté par Meta.

Bref, si vous bossez dans l'embarqué ou que vous kiffez bidouiller du deep learning sur des petites puces, allez jeter un oeil .

Merci à Fabrice pour le lien !

La chaîne YouTube Asianometry vient de publier une vidéo qui retrace l'histoire du VLIW, une architecture de processeur née dans les années 80 et longtemps considérée comme un échec. Sauf que cette technologie, enterrée avec l'Itanium d'Intel, refait surface dans les puces dédiées à l'intelligence artificielle. Et elle est peut-être déjà dans votre smartphone.

Le principe, et c'est un peu technique

Si vous ne connaissez pas Asianometry, c'est une chaîne qui décortique l'histoire des semi-conducteurs avec un vrai talent de vulgarisation, et cette vidéo sur le VLIW (pour Very Long Instruction Word) ne fait pas exception.

L'idée est assez simple sur le papier. Un processeur classique exécute ses instructions une par une, ou les réordonne à la volée avec du matériel dédié (c'est ce que font les puces modernes avec l'exécution "out-of-order").

Vous faites tourner des LLMs en local comme le gros fifou de Hipster IA que vous êtes et, Ô drame, la VRAM de votre ordinateur explose dès que le contexte dépasse 8000 pauvres malheureux tokens ?

Le problème c'est le KV cache les amis ! Le KV cache c'est ce truc qui stocke les clés et valeurs d'attention et qui grossit linéairement avec la longueur du prompt. C'est pour gérer ce problème que Google a annoncé sous la forme d'un whitepaper uniquement un algo qui compresse tout ça de 3,8 à 6,4 fois... et youpi pour nous, y'a un dev qui l'a déjà implémenté dans un fork de llama.cpp .

Concrètement ça donne :

llama-server -m model.gguf -ctk turbo3 -ctv turbo3 -fa on

Et vous venez de diviser la mémoire du cache par 4,6. Et voilà comment un énoooorme Command-R+ de 104 milliards de paramètres arrive à tourner à 128K tokens de contexte sur un MacBook M5 Max, avec un pic mémoire max de 74 Go.

Pour bien comprendre pourquoi c'est costaud, faut revenir au problème de base. En fait quand un LLM génère du texte, il stocke pour chaque token passé 2 vecteurs (la clé K et la valeur V) dans un cache. Plus le contexte est long, plus ce cache grossit. Et ça s'accumule vite... Par exemple, sur un Llama 70B avec 128K tokens de contexte, le KV cache en fp16 bouffe à lui seul plus de 40 Go de RAM. Du coup votre modèle Llama 3.1 ou Qwen3 rentre évidemment en mémoire, mais le cache, lui, fait tout déborder comme vous quand vous vous incrustez dans la mini piscine Intex des gosses.

Google a publié son papier TurboQuant fin mars et leur idée c'est de compresser ces vecteurs K et V en 3-4 bits au lieu de 16, sans ré-entraîner le modèle. En fait l'algorithme fait ça en deux étapes...

D'abord PolarQuant : on applique une rotation Walsh-Hadamard aux vecteurs pour "gaussianiser" leur distribution, genre transformer des données qui partent dans tous les sens en une forme bien ronde et prévisible.

Puis on convertit les coordonnées cartésiennes en coordonnées polaires, rayon + angle. Le rayon capture alors l'essentiel de l'information, et l'angle se compresse très bien parce que sa distribution est connue à l'avance.

Ensuite, deuxième étape, QJL (Quantized Johnson-Lindenstrauss) : Il s'agit d'un correcteur d'erreur à 1 bit qui élimine le biais résiduel, le tout sans overhead mémoire pour les constantes de quantification, contrairement aux méthodes classiques comme q4_0 ou q5_1 qui perdent 1-2 bits rien qu'en stockant leurs propres paramètres.

Et c'est là qu'intervient notre développeur de génie, TheTom, qui a pris ce document académique de Google et l'a transformé en code C avec des kernels Metal pour Apple Silicon et CUDA pour NVIDIA. Et c'est pas juste un portage bête et méchant puisqu'il a vraiment poussé les expériences bien au-delà du document original avec une couverture de tests de 100% et des benchmarks sur des modèles de 1.5 à 104 milliards de paramètres.

Et ses découvertes les plus intéressantes c'est justement ce qui n'est PAS dans le paper. Première trouvaille : la compression des valeurs V est gratuite. Compresser V à 2 bits sur Qwen, Llama, Mistral ou Command-R+ n'a aucun impact mesurable sur la qualité d'attention, tant que les clés K restent en q8_0.

Et cela a été confirmé sur Metal M5 Max 128 Go, CUDA RTX 4090 et RTX 3090 par plusieurs testeurs indépendants. C'est franchement contre-intuitif, mais cela veut dire que toute la dégradation de qualité vient de la compression des clés K, et pas de leurs valeurs. Du coup une config asymétrique (K en q8_0, V en turbo3) arrive à récupèrer des modèles où la compression symétrique échoue.

Deuxième trouvaille : les couches limites sont hypersensibles. Protéger les 2 premières et 2 dernières couches en q8_0 pendant qu'on compresse le reste en turbo2 permet de récupérer jusqu'à 91% de la perte de qualité. Et plus le modèle est gros, mieux ça marche. C'est seulement 15 lignes de code, et là encore, y'a aucun impact sur la vitesse.

Troisième trouvaille : Sparse V, un décodage du cache qui saute les positions V à faible poids d'attention permet de gagner environ 23% de vitesse de décodage à 32K tokens de contexte. Et zéro dégradation de la qualité.

Côté chiffres bruts, y'a 3 modes : turbo4 compresse 3.8x et le modèle répond quasi pareil qu'avant. turbo3 compresse 4.6x avec une perte de qualité à peine détectable. turbo2 pousse à 6.4x mais là faut l'utiliser malin (uniquement sur les valeurs V, pas les clés K).

Et dire que pour l'instant Google n'a toujours pas publié de code officiel (mais c'est prévu pour le second trimestre 2026)... Donc pour le moment, cette implémentation communautaire est le seul moyen de tester TurboQuant dans un fork llama.cpp. Ça tourne sur Apple Silicon M1 à M5, NVIDIA RTX 3080 Ti à 5090 et AMD 6800 XT / 9070 XT et visiblement, pas mal de monde a testé sur du matériel varié et les résultats sont au rendez-vous.

Donc voilà, si vous faites de l' inférence LLM locale et que la mémoire vous limite, c'est le moment de tester ça !

SynthID, le filigrane invisible que Google injecte dans chaque image Gemini, c'était censé être incassable. Sauf qu'un dev a eu l'idée toute bête de générer des images noires et blanches avec Gemini, puis de regarder ce qui restait dans le domaine fréquentiel. Et là, surprise... le watermark est apparu en clair avec toutes ses fréquences porteuses !

Le projet reverse-SynthID documente le truc de A à Z où on comprend en gros, que le marquage IA de Google fonctionne en injectant de l'énergie à des fréquences bien précises dans le spectre de l'image via une transformation de Fourier . Le chercheur a identifié 6 fréquences porteuses principales, toutes avec une cohérence de phase supérieure à 99,9% et la blague, c'est que ce pattern est fixe. Donc pas de message unique par image, pas de clé qui change... c'est juste la même empreinte spectrale sur toutes les images sorties du modèle Gemini.

Spectre FFT du watermark SynthID - les pics lumineux correspondent aux fréquences porteuses identifiées

Du coup, une fois que vous avez profilé cette empreinte avec une cinquantaine d'images PNG de référence (25 noires, 25 blanches, générées via l'API Gemini), vous pouvez faire deux trucs. D'abord, détecter le filigrane avec 90% de précision, sans avoir le moindre accès au code source de Google. Et ensuite le retirer en soustrayant les composantes spectrales identifiées, fréquence par fréquence, tout en préservant la qualité de l'image à plus de 40 dB PSNR. Visuellement identique à l'original !

Et c'est là que la différence avec UnMarker (dont je vous avais parlé) saute aux yeux car ce dernier "secoue" l'image en aveugle pour casser le watermark. Alors que Reverse-SynthID, c'est plutôt scruté à la loupe et hyper ciblé. Résultat, y'a clairement moins de dégradation et un drop de confiance du détecteur.

Les fréquences porteuses reconstruites - la structure diagonale du watermark SynthID

Par contre, je l'ai implémenté en Rust et j'ai essayé de voir si ça marchait vraiment sur mes propres images générée avec Gemini. Hé bien non, car le bypass ne fait PAS chuter la confiance du détecteur de 100 à 0, mais juste de quelques pourcents.

Le watermark est atténué, mais pas effacé. Ce n'est donc pas un outil clé en main pour faire disparaître tous les filigranes SynthID en un clic. Mais le fait qu'une seule personne, avec du Python et du traitement de signal classique (FFT, filtres notch, soustraction spectrale), ait pu reverse-engineerer un système que Google présente comme LA solution anti-deepfakes...

Ça confirme ce que les chercheurs de l'Université de Waterloo avaient déjà démontré : le watermarking d'images IA, c'est pété by design.

D'ailleurs, Google le sait très bien et ils pourraient changer le pattern demain et tout serait à refaire, mais ça confirme surtout que le principe même du watermarking spectral a une date de péremption. Après, ça arrange tout le monde d'avoir un truc à montrer quand les gouvernements demandent "et contre les deepfakes, vous faites quoi ?"

Et si c'est la petite étoile visible en bas à droite des images Gemini qui vous gêne (pas le watermark spectral invisible, juste le marqueur visuel), j'ai développé un outil pour mes Patreons qui s'en occupe.

Bref, tout est sur le repo si le reverse-engineering de watermarks IA, ça vous branche !

Andrej Karpathy, ancien chercheur chez OpenAI et ex-responsable de l'IA chez Tesla, a laissé tourner un agent IA pendant 48 heures sur un petit modèle de langage. Résultat : 700 expériences, 20 optimisations retenues et un gain de 11 % sur le temps d'entraînement.

Le principe d'autoresearch

Mais c'est quoi ce concept d'autoresearch ? Et bien le fonctionnement est assez direct : un agent IA reçoit un script d'entraînement de 630 lignes en Python et un budget de calcul fixe de 5 minutes par expérience sur un seul GPU. Et c'est là que l'agent se met en mouvement pour lire le code, formuler une hypothèse, modifier le script, lancer l'entraînement, évaluer le résultat, et surtout décider, ou non, de conserver une modification.

Si le modèle s'améliore, le changement devient la nouvelle base. Sinon, il revient en arrière et essaie autre chose. En deux jours de boucle continue, l'agent a conduit environ 700 itérations et identifié 20 améliorations cumulables qui ont réduit le temps nécessaire pour atteindre le niveau GPT-2 de 2,02 heures à 1,80 heure.

Tobias Lütke, le patron de Shopify, a d'ailleurs testé le système sur des données internes : après une nuit, 37 expériences et un gain de 19 % sur les performances de son modèle.

La question de l'auto-amélioration

Là où le projet fait pas mal parler, c'est l'idée que cette IA s'améliore elle-même en boucle, dans un scénario que certains chercheurs en sécurité aiment appeler "exploser d'intelligence" (c'est aussi comme ça que j'appelle chaque moment que je passe à regarder l'ami Korben me parler de ses projets en cours).

Karpathy tempère : son agent n'optimise pas son propre code, il ajuste l'entraînement d'un modèle bien plus petit et bien moins complexe.

Par contre, il assume que tous les grands labos d'IA vont adopter cette méthode et que ça va accélérer la recherche. Il imagine à terme des essaims d'agents qui collaborent en parallèle, testent des pistes différentes et remontent les meilleures idées à des échelles de plus en plus grandes. Son objectif : ne pas reproduire le travail d'un doctorant, mais celui d'une communauté entière de chercheurs.

Bon maintenant il faut quand même relever que certains critiquent quand même l'idée, car elle ressemble en partie à AutoML, une technique qui est déjà utilisée chez Microsoft et Google.

Karpathy a répondu que la comparaison ne tient pas : AutoML fonctionne avec des variations aléatoires ou des algorithmes évolutifs, alors qu'autoresearch utilise un vrai modèle de langage qui écrit du code, apprend de ses expériences précédentes et a accès à internet. Bref, tout ceci est fascinant.

Source : The News Hack

Claude Octopus , c'est un plugin Claude Code qui fait bosser trois IA ensemble sur le même problème. Codex pour l'implémentation, Gemini pour la recherche, Claude pour la synthèse, le tout avec un seuil de qualité à 75% qui bloque ce qui n'est pas au niveau.

En gros, au lieu de faire confiance à un seul modèle GPT ou Gemini, vous en mettez trois en parallèle et le plugin ne valide que si les résultats des trois moteurs convergent suffisamment.

Ça s'installe en deux commandes :

claude plugin marketplace add https://github.com/nyldn/claude-octopus.git

claude plugin install octo@nyldn-plugins

Et ensuite, faites un /octo:setup dans votre terminal et c'est parti.

Le truc fonctionne avec Claude seulement sous macOS, Linux ou Windows dès le départ, donc pas besoin de configurer Codex ou Gemini pour démarrer. Il vous guidera pour ça ensuite.

Le plugin embarque 39 commandes, 32 personas spécialisées (par exemple un auditeur sécu qui pense en OWASP, un architecte backend pour les API REST, un designer UI/UX basé sur BM25...etc) et 50 skills. Tout ça s'active ensuite automatiquement selon votre prompt. Vous tapez "wesh audite mon API ma gueule" dans votre terminal zsh et c'est le bon expert qui débarque. Et si vous ne savez pas quelle commande taper, /octo:auto fait le tri pour vous. C'est très pratique.

Le workflow principal suit la méthode Double Diamond (discover, define, develop, deliver) avec des quality gates entre chaque phase. Du coup un bout de code bâclé ne peut pas avancer au stade suivant. Pour les plus flemmards, y'a même un "Dark Factory Mode" qui prend un fichier Markdown en entrée et vous sort du code testé avec un score de satisfaction. Comme ça, vous n'avez qu'à relire que le rapport final au lieu de valider chaque PR manuellement.

Sous le capot, l'orchestrateur écrit en Bash lance Codex CLI et Gemini CLI en parallèle pour la recherche, puis Claude Sonnet 4.6 synthétise les deux réponses. Forcément, trois modèles en parallèle c'est plus lent qu'un seul donc faut compter 30 à 60 secondes par requête. Déso pas déso ^^.

Et pour la revue de code, c'est carrément, pardonnez-moi l'expression, "adversarial" puisque ce sont 4 agents (Codex logique, Gemini sécu, Claude archi, Perplexity pour les CVE ) qui postent des commentaires inline sur vos PR GitHub et y'a ensuite un "reaction engine" qui auto-répond aux échecs CI et aux review comments.

Ce projet c'est quasi l'œuvre d'un seul développeur dévoué et sa vélocité de développement est dingue... Ça vibe code à donf quoi ^^.

C'est gratuit, open source, par contre, chaque provider facture ses tokens normalement, du coup en mode multi-IA vous consommez mécaniquement 3× plus qu'avec Claude tout seul. Après si vous avez déjà un abonnement ChatGPT Plus ou Google AI Pro, les providers passent par OAuth sans clé API supplémentaire, donc ça sera inclus dans votre forfait.

Pour ceux qui utilisent déjà des plugins Claude Code au quotidien ou qui font tourner leurs agents dans des sandbox isolées , c'est le genre d'outil qui mérite un détour.

Bref, trois cerveaux valent mieux qu'un... reste à voir si besoins valent tout ce bordel à configurer !