Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

bbDump - L'alternative moderne à pgAdmin, sauce MCP

pgAdmin, l'outil "officiel" pour administrer vos bases PostgreSQL, c'est le type d'interface qu'on n'a pas vraiment envie d'ouvrir un lundi matin ! C'est lent, c'est cheum de ouf en mode figé dans les années 2000 et ça rame sérieusement dès qu'on tente un export un peu costaud. Alors oui je sais, DBeaver, c'est plus joli, mais faut se coltiner Java et un workspace qui traîne au démarrage.

Du coup quand bbDump est passé sur mon radar, j'ai eu envie de creuser un peu. C'est un gestionnaire PostgreSQL moderne, en Electron + Vue + TypeScript, signé par Poups, un dev indé français. L'outil reprend tout ce que vous faites habituellement en CLI (pg_dump, pg_restore, coups d'œil aux tables, schéma de la DB) et met ça dans une interface vraiment propre.

Le dashboard bbDump, tout de suite plus respirable que pgAdmin

Côté fonctionnalités classiques, vous avez ce qu'on attend d'un client PostgreSQL correct. Gestion multi-bases organisée par projet, backups avec liste, restauration, filtre par base, tailles et dates. De leur côté, les tâches planifiées via expressions cron sont configurables par base, et il y a même une visionneuse de logs en temps réel qui trace chaque opération pg_dump.

Ajoutez à ça un navigateur de tables avec édition inline (avec support complet des types), un constructeur de requêtes SQL visuel en plus de l'éditeur brut, l'export CSV, et un diagramme entité-relation interactif via Vue Flow pour visualiser les tables et les clés étrangères. Grâce à bbDump, plus besoin d'aller chercher un outil externe pour comprendre une base héritée d'un projet qui traîne !!

Le schema visualizer en mode ERD interactif, pratique pour décortiquer une base héritée

Mais le vrai twist, c'est l'intégration du MCP (Model Context Protocol) puisque bbDump expose 31 outils MCP aux agents IA, ce qui veut dire que votre Claude d'amour ou votre LLM peut interroger la DB, regarder un schéma, tester une requête. Et comme les mutations passent par un système de confirmation, pas de DROP TABLE à l'insu de votre plein gré !

Je vous avais déjà parlé de cette approche avec Ghidra MCP côté reverse engineering et BrowserWing côté automatisation navigateur. bbDump rejoint donc la famille côté backend de données.

Autre détail sympa, le dev a pensé à la sécurité puisque les backups sont chiffrés en AES-256-GCM, donc si vous synchronisez vos dumps sur un cloud random, pas de panique sur les données sensibles. Sur macOS, y'a même une mini-app menu bar pour accéder aux bases et aux connexions proxy sans ouvrir l'app complète.

Côté installation, c'est facile :

curl -fsSL https://poups.dev/bbdump.sh | bash

sur macOS et Linux (qui reste en beta). Bien sûr, si balancer un script dans bash direct vous fait tiquer (normal), vous pouvez aussi chopper le DMG ou l'AppImage en release sur GitHub et inspecter avant. Le code est sous licence MIT, avec une doc dédiée et une page Ko-fi si vous voulez soutenir le projet. Par contre, rien pour Windows pour l'instant.

Le projet est encore tout jeune puisque sorti fin mars de cette année donc si vous cherchez un outil ultra-stable pour une prod critique, attendez un peu. Mais pour vos projets perso, votre dev local, ou juste pour arrêter de râler sur pgAdmin, ça vaut clairement le coup d'œil.

Bref, un dev français de talent qui se lance en indé sur un créneau pourri d'outils vieillots, avec une vision cohérente et une intégration MCP propre, moi j'aime bien. Je pense que Poups mérite d'être soutenu sur ce coup-là, d'où mon article !

CATAI - Des chats pixel art boostés à l'IA sur votre dock

Des chats en pixel art qui se baladent sur votre dock macOS et qui causent grâce à un LLM local... non vous ne rêvez pas car c'est ce qu'on peut obtenir avec CATAI , qui vous fera adopter 6 matous virtuels avec chacun sa personnalité.

En gros, c'est le Tamagotchi de votre dock, sauf qu'au lieu de biper quand il a faim, il vous cite du Nietzsche. Vous lancez l'app, et hop, un chat orange débarque. Il marche, il mange, il dort, il s'énerve... soit 368 sprites dessinés à la main (c'est devenu assez rare pour le souligner !!). Et quand le dock est masqué, le chat se téléporte directement sur le bord supérieur de votre fenêtre active. Parce que vous le savez, un chat, ça squatte toujours les rebords les plus improbables.

Vous pouvez en coller jusqu'à 6 en même temps, chacun avec sa couleur et son caractère. Le noir (Ombre) est philosophe et vous pose des questions existentielles, le blanc (Neige) s'exprime en vers, le gris (Einstein) vous balance des faits scientifiques et le brun (Indiana) raconte des aventures. De temps en temps, ils miaulent tout seuls dans des bulles pixel art. "Mrrp !", "Prrr...", "ronronronron". Perso, je trouve ça craquant.

Et quand vous cliquez sur un chat, ça ouvre une bulle de discussion connectée à Ollama (le moteur d'IA locale que vous connaissez sûrement). Si vous avez déjà un modèle qui tourne, votre matou vous répond alors avec sa propre personnalité. La mémoire de conversation est même persistante entre les sessions (max 20 messages par chat, pour garder un contexte de conversation raisonnable).

Comme c'est du Swift pur, juste les Command Line Tools suffisent pour compiler le fichier source :

swiftc -O -o cat cat.swift -framework AppKit -framework Foundation

La compilation prend genre 3 secondes sur un M1, et le binaire pèse dans les 500 Ko, soit moins qu'une photo iPhone. Y'a aussi un build.sh qui crée un .app propre avec son icône si vous préférez.

Les plus anciens d'entre vous se souviendront peut-être de Neko, le petit chat qui courait après votre curseur, porté sur Mac en 1989 par Kenji Gotoh. L'un des premiers desktop pets connus. Sauf que là, comme on est en 2026, le chat vous fait la conversation via un LLM local. Si vous bidouillez déjà avec Ollama ou que vous avez découvert le LLM caché de votre Mac , c'est un usage auquel vous n'aviez probablement pas pensé.

Notez que sans Ollama, ça fonctionne, les chats se baladent mais restent muets (ce qui est déjà sympa en soi). Et si vous collez un modèle trop lourd genre un 70B, ça va ramer vu que le streaming passe par localhost. Un petit Qwen 2.5 ou Llama 3.2 3B fait largement le taf pour des réponses de chat en 2-3 phrases.

Merci à William pour la découverte.

Gemma Gem - Un agent IA dans Chrome, 100% local

Les extensions Chrome qui promettent de l'IA, ça pullule de ouf et à vrai dire, la plupart se contentent d'envoyer vos données sur un serveur distant. C'est naze ! Heureusement, l'extension Gemma Gem prend le problème à l'envers puisque son modèle tourne directement dans votre navigateur via WebGPU, sans clé API, sans cloud, et vos données ne sortent jamais de votre machine. C'est comme le kir, royal !

Comme c'est pas sur le Chrome Web Store, faudra la builder vous-même... Vous clonez le repo, vous lancez pnpm install puis pnpm build et vous chargez le dossier dans chrome://extensions en mode développeur et ensuite, elle téléchargera le modèle de Google (environ 500 Mo pour la version légère, genre le poids d'un gros jeu mobile), et pif paf pouf, ensuite vous aurez un agent IA qui vit sa best life dans votre Chrome.

Cliquez alors sur l'icône en bas à droite, une fenêtre de chat s'ouvre et vous pourrez interroger n'importe quelle page. Et si vous préférez un modèle plus costaud, l'E4B pèse 1,5 Go et permet d'obtenir des réponses plus fines.

Sauf que c'est pas juste un chatbot de plus. En effet, l'extension fait du tool calling en boucle à l'aide de 6 outils : read_page_content, click_element, type_text, scroll_page, take_screenshot et run_javascript. Elle peut ainsi lire une page, cliquer sur des boutons, remplir un formulaire et même balancer du JavaScript dans le contexte de la page.

Comme l'inférence WebGPU ne peut pas tourner dans un service worker Chrome (y'a pas d'accès au GPU, c'est une limitation connue depuis des années), le développeur a trouvé une parade : il utilise un offscreen document, c'est-à-dire une page HTML invisible que Chrome maintient en arrière-plan et qui, elle, a accès au GPU. Résultat, le modèle calcule dans cette page fantôme, le service worker joue le facteur entre les morceaux, et le content script affiche le chat. Je trouve ça bien pensé comme découpage !

Toute la boucle d'agent (le code qui décide quand appeler un outil et quand répondre) est isolée dans un dossier agent/ sans aucune dépendance Chrome. Cela veut dire que vous pouvez prendre ces 5 fichiers .ts (agent-loop.ts, prompt-builder.ts, tool-parser.ts, types.ts et index.ts), les coller dans un projet Node.js ou Deno, et hop, vous avez votre propre boucle agentique. Yaniv Kessler, le développeur a pensé le truc pour que ça serve ailleurs.

Les deux variantes (E2B et E4B) sont compressées en q4f16 avec 128K tokens de contexte en théorie, même si en pratique la fenêtre effective dépend de votre VRAM. Cela dit, c'est largement de quoi avaler une page web complète sans broncher ! Et le modèle reste en cache après le premier téléchargement, du coup au deuxième lancement, c'est quasi instantané. Par contre, si vous êtes sur un vieux Chromebook avec un Intel UHD intégré et 4 Go de RAM, ça risque de mouliner à fond. Et sur Firefox (qui est le meilleure navigateur du monde, comme je n'ai de cesse de vous le dire), le WebGPU est encore un peu expérimental, donc pour l'instant ce sera Chrome ou rien... Sniiif.

Si vous avez déjà testé des extensions comme Localsumm qui faisaient tourner Phi-3 en local pour résumer des pages, disons que Gemma Gem pousse le concept beaucoup plus loin avec ses capacités d'agent. Et si le sujet de l'IA locale dans le navigateur vous branche, jetez un oeil à Clippy qui fait tourner des LLM localement sur votre desktop.

Notez quand même que sur Hacker News, le projet a déclenché pas mal de débat. Certains pointent le risque du tool run_javascript qui donne au modèle les pleins pouvoirs sur le DOM (genre, supprimer des trucs ou poster un formulaire à votre place). C'est vrai que c'est important mais bon, c'est le même modèle de permissions que n'importe quel script web classique, sauf que là au moins vos données restent chez vous.

Bref, 500 Mo de modèle, pas de cloud, et votre navigateur qui devient plus autonome que votre fils de 22 ans. Pas mal non ?

Apfel - Le LLM caché de votre Mac enfin libéré

J'sais pas si vous saviez mais Apple a planqué un LLM dans votre Mac et ne veut pas que vous y touchiez... enfin, pas directement. En effet, leur modèle est là, intégré au système via le framework FoundationModels, il tourne sur le Neural Engine sans connexion internet mais Apple l'a verrouillé derrière Siri. Du coup, impossible de l'appeler depuis un script ou un pipe shell et c'est là qu' apfel intervient !

L'outil s'installe en une commande :

brew install Arthur-Ficial/tap/apfel

Et hop, vous avez accès au modèle directement depuis votre terminal. Faut Apple Intelligence actif également, sinon, ça ne fonctionnera pas.

Ensuite, vous lui posez une question, et il vous répond. Vous lui "pipez" un fichier, et il le traite. Et le tout sans rien télécharger puisque le modèle est déjà sur votre machine !

C'est un LLM de 3 milliards de paramètres, quantifié en 2 et 4 bits, qui tourne nativement sur la puce Apple Silicon (M1 et au-delà) et il se défend plutôt bien face à Qwen-2.5-3B, si on en croit les benchmarks. La fenêtre de contexte est limitée à 4096 tokens (entrée + sortie combinées), soit environ 3000 mots, donc faut pas espérer lui faire digérer un roman mais pour transformer du texte, classifier des données ou résumer un paragraphe... ça fait bien le taf.

Apfel expose donc ce modèle de trois façons différentes. En CLI pure (compatible stdin/stdout, sortie JSON, codes d'erreur propres), en serveur HTTP compatible OpenAI sur localhost:11434 (avec streaming SSE, tool calling et CORS activé), et en chat interactif multi-turn.

Le serveur OpenAI c'est malin parce que d'un coup, tous vos outils savent causer à l'API OpenAI (Cursor, Continue.dev, n'importe quel SDK) et peuvent utiliser l'IA locale de votre Mac sans rien changer à leur code. Et le support MCP (Model Context Protocol) natif c'est très chouette aussi puisqu'il suffit de lancer apfel avec le flag --mcp, pour qu'il découvre automatiquement les outils disponibles, exécute les appels et renvoie les résultats.

D'ailleurs côté vie privée, c'est du béton armé car le framework FoundationModels d'Apple n'a pas accès à vos contacts, emails, calendrier ou photos et tout tourne sur le Neural Engine et le GPU, sans connexion internet.

Si vous avez déjà bidouillé avec Ollama et les modèles locaux , apfel c'est un peu la même philosophie... sauf que là vous n'avez rien à télécharger et contrairement à Perspective Intelligence qui transforme votre Mac en serveur web avec PostgreSQL et tout le tralala, apfel reste hyper minimaliste.

Attention quand même, faut être sous macOS 26 Tahoe minimum donc si vous êtes encore sous Sequoia 15.x ou Ventura 13.x, c'est mort, le framework FoundationModels n'existe pas sur ces versions. Et si vous avez un Mac Intel... ben non plus, le Neural Engine c'est Apple Silicon only.

Le projet inclut aussi des scripts démo sympas dans le dossier demo/.

Y'a par exemple cmd qui convertit du langage naturel en commandes shell, explain qui décortique les messages d'erreur, gitsum qui résume vos commits récents, ou encore mac-narrator qui commente l'activité de votre système en temps réel (c'est votre Mac qui se raconte à lui-même).

Perso, cmd c'est celui qui m'a le plus plu, même si bon, avec 4096 tokens de contexte, faut pas lui demander des commandes ffmpeg de 200 caractères.

Mais au-delà des démos, c'est en vrai que ça devient fun. Je vous montre quelques usages classiques d'abord :

apfel -f README.md "Résume ce projet en 3 phrases"

apfel -f code.py -s "Tu es un développeur expérimenté" "Trouve les bugs"

echo "Traduis ça en allemand : Salut" | apfel

Et les trucs un peu plus funs :

git diff HEAD~1 | apfel -f CONVENTIONS.md "Review ce diff par rapport à mes conventions"

apfel -f old.swift -f new.swift "Qu'est-ce qui a changé entre ces deux fichiers ?"

demo/oneliner "compte les IPs uniques dans access.log"

Vous pouvez même piper la sortie en JSON pour chaîner avec jq, ou lancer le mode --serve et brancher Cursor dessus pour avoir de l'autocomplétion locale gratuite. Et si vous êtes du genre parano, le mode --chat avec --context-strategy summarize gère automatiquement le contexte quand la conversation dépasse les 4096 tokens.

Et côté écosystème, y'a aussi apfel-gui (une interface SwiftUI native pour chatter avec le modèle, avec speech-to-text et text-to-speech on-device) et apfel-clip qui est en développement (ce sont des actions IA qui s'ajoutent dans la barre de menus pour corriger la grammaire, traduire, résumer) et le tout sous licence MIT, évidemment.

Bref, c'est un super modèle mais avec 3 milliards de paramètres et 4096 tokens de contexte, faut pas s'attendre non plus à remplacer Claude ou GPT. Les maths complexes, la génération de code avancée et les longues conversations, c'est pas son truc mais pour du scripting, de la classification ou transformer du texte à la volée... ça dépanne carrément !

Et ce modèle préfère refuser plutôt qu'halluciner, ce qui est plutôt une bonne surprise je trouve. Voilà, si vous avez un Mac Apple Silicon sous macOS Tahoe, apfel et ses outils valent le coup d'œil pour vos petites tâches IA basiques / rapides de tous les jours.

TurboQuant - Un LLM de 104B sur un MacBook, merci Google

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 !

Le piratage par IA n'a plus besoin de malware : une simple doc suffit

Une nouvelle méthode d'attaque cible les IA de développement comme Copilot. En publiant de la documentation empoisonnée, des hackers trompent les modèles pour qu'ils recommandent des bibliothèques malveillantes. Cette menace invisible pour la sécurité est indétectable par les outils classiques.

Le concept est d'une simplicité désarmante. Plus besoin d'injecter du code malicieux dans un dépôt GitHub ou de trouver une faille zero-day complexe. Il suffit désormais de publier de la documentation technique faussée sur des forums, des wikis ou des fichiers README publics. Ces textes, une fois ingérés par les grands modèles de langage (LLM), deviennent une source de vérité pour l'IA qui assiste les développeurs au quotidien.

Le mécanisme de l'injection indirecte

Le problème est en fait dans la confiance aveugle que les modèles accordent aux données d'entraînement. En décrivant une solution technique qui utilise un paquet spécifique — mais malveillant — l'attaquant s'assure que l'IA proposera ce nom lors d'une requête de génération de code. C'est ce qu'on appelle l'injection de prompt indirecte. Le développeur, pensant gagner du temps, valide la suggestion et installe un composant compromis sans vérification préalable.

Le typosquatting passe au niveau supérieur

Cette technique facilite grandement le typosquatting. Auparavant, un attaquant devait espérer qu'un humain fasse une faute de frappe en saisissant une commande. Aujourd'hui, c'est l'IA qui commet l'erreur pour lui, influencée par des références empoisonnées trouvées sur le web. Comme l'IA présente la solution avec une assurance pédagogique, le sens critique de l'utilisateur baisse d'un cran. Le malware n'est plus dans la documentation, il arrive dans la machine au moment où le développeur exécute la suggestion générée.

Un défi pour la cybersécurité logicielle

La difficulté majeure est que cette attaque est purement textuelle. Les outils de scan de vulnérabilités cherchent du code dangereux, pas des explications trompeuses en langage naturel. Tant que les modèles d'IA ne sauront pas distinguer une documentation légitime d'une tentative de manipulation sémantique, la chaîne d'approvisionnement logicielle restera vulnérable à cette forme de gaslighting numérique. La sécurité repose désormais sur la véracité de l'information ingérée par les machines.

On atteint ici les limites de l'automatisation du développement. Faire confiance à un LLM pour choisir ses dépendances est devenu un risque de sécurité majeur. Cette faille montre que le maillon faible n'est plus seulement l'humain qui tape du code, mais l'outil qui lui souffle les réponses. On risque de voir apparaître des systèmes de vérification de réputation de documentation.

Source : The Register

❌