Logitech Options+, vous connaissez ce délire, je pense... Pour régler 3 boutons de souris, on vous pousse à créer un compte, à partager vos data, et à laisser une usine à gaz tourner H24 en tâche de fond. Le dev AprilNEA en a eu marre, du coup il a écrit OpenLogi en Rust et son truc fait le même boulot côté réglages, mais sans rien envoyer chez Logitech.

Si vous me lisez régulièrement, ça devrait vous rappeler Mouser , dont je vous parlais en mars dernier. C'est la même philosophie, sauf que Mouser restait coincé, à l'époque, sur la MX Master 3S en Bluetooth uniquement, sans SmartShift et sans Linux. OpenLogi reprend donc le flambeau et va beaucoup plus loin.

Alors, qu'est-ce que vous pouvez faire avec ?

Hé bien d'abord remapper vos boutons (41 actions prêtes à l'emploi, quand même), régler le DPI, activer le SmartShift, ce fameux défilement en roue libre. Vous pouvez aussi créer des profils qui basculent tout seuls selon l'appli active. Et tout ça cause directement avec le protocole HID++ de Logitech à votre MX Master , sans jamais lancer le pilote maison.

Peu importe comment la bête est branchée d'ailleurs, récepteur Bolt, clé Unifying, Bluetooth ou un bon vieux câble, les quatre passent ! Toute votre config ensuite se trouve dans un simple fichier TOML posé en local, que vous pouvez versionner dans un Git si ça vous chante. L'outil dispose d'une interface graphique, mais vous pouvez également l'utiliser en ligne de commande.

Pour l'installer sous macOS, c'est facile, il suffit de faire un brew install --cask openlogi et voilà ! Quant à Linux, vous avez des paquets .deb et .rpm. Notez que ça tourne aussi sous Windows, mais uniquement en beta.

OpenLogi est compatible avec les MX Master 4, 3S et 3, MX Anywhere 3, Signature M650, Ergo M575 et le code est libre sous double licence Apache 2.0 et MIT au choix.

Voilà, si Options+ vous gonfle de fou, OpenLogi mérite sans doute un petit test de votre part. C'est par ici , et le code est sur GitHub .

Vous m'en direz des nouvelles !

Si vous avez un Mac avec une puce Silicon et que vous en avez marre de raquer pour des tokens à chaque requête API à un LLM à la con, y'a un projet qui mérite, je trouve, le détour. Ça s'appelle vLLM-MLX , et c'est un serveur d'inférence local qui transforme votre Mac en machine à générer du texte, à analyser des images et vidéos, et même capable de gérer de l'audio... et tout ça sans que l'inférence ne passe par le cloud des zaméricains.

Pour installer le bouzin, ça se fait avec :

uv tool install vllm-mlx

Puis vous lancez suivi du nom d'un modèle et hop, vous obtenez un endpoint API compatible OpenAI qui tourne en local sur votre machine :

vllm-mlx serve %MODEL%

Au début je pensais que j'étais parti pour une séance de configuration qui aller durer des heures mais en fait non. Par exemple moi j'ai lancé ça :

vllm-mlx serve mlx-community/GLM-4.7-Flash-4bit

Vous pouvez aussi opter pour un modèle plus petit :

vllm-mlx serve mlx-community/Qwen2.5-Coder-3B-Instruct-4bit

Du coup, si vos scripts causent déjà avec l'API d'OpenAI, basculer sur ça en local rien qu'en changeant l'URL de base, c'est un jeu d'enfant !

Côté perfs, et là je reprends les benchmarks officiels du repo (M4 Max 128 Go, mono-requête), on tourne autour de 418 tok/s sur un petit Qwen3-0.6B en 8-bit. Ensuite, ça tombe à environ 206 tok/s sur du Llama-3.2-3B et 128 tok/s sur un gros Qwen3-30B-A3B.

Le débit grimpe aussi quand plusieurs requêtes tapent en même temps à la porte... Donc sur les petits modèles ça file vite, mais par contre, sur les gros, faudra pas s'attendre à la même vitesse, hein... Et un Qwen3-30B vous bouffera dans les 18 Go de RAM unifiée, donc sur un Mac à 8 ou 16 Go vous pouvez oublier les gros modèles (Mais qui n'a pas encore un Mac Studio 128 Go ?? hein ? Quiiii ?).

Et c'est pas juste un serveur de texte comme je vous le disais, puisque le projet gère les modèles de vision type Gemma 3, Qwen3-VL, Pixtral, pour analyser images et les vidéos, et côté audio y'a du TTS natif (avec Kokoro, Chatterbox et compagnie) + de la transcription Whisper qui monte jusqu'à 197x le temps réel avec whisper-tiny, ou 55x avec le modèle turbo.

Attention par contre, il vous faudra la version avec l'extra audio (espeak-ng et un modèle spaCy), car c'est pas inclus dans la commande de base. Mais une fois en place, y a de quoi se monter un vrai assistant vocal 100% local et causer synthèse vocale sans louer un GPU chez Azure ou AWS.

Même le endpoint /v1/messages est compatible Anthropic, ce qui permet de brancher Claude Code ou OpenCode directement sur votre serveur comme je vous l'expliquais ici . Suffit d'utiliser ces variables d'environnement et votre éditeur IA ira taper sur votre propre machine plutôt que sur des serveurs distants.

unset ANTHROPIC_API_KEY
export ANTHROPIC_BASE_URL="http://127.0.0.1:8000"
export ANTHROPIC_AUTH_TOKEN="dummy"
claude --model mlx-community/GLM-4.7-Flash-4bit

ou :

claude --model mlx-community/Qwen2.5-Coder-3B-Instruct-4bit

Avouez que c'est trop cool hein ? Vous pouvez trouver tous les modèles pour MLX ici sur HugginFace si vous cherchez un truc plus spécifique.

Y'a aussi un endpoint d'embeddings pour faire du RAG en local, de l'appel d'outils externe via MCP avec une douzaine de parsers et le support des modèles de raisonnement qui extraient proprement le processus de réflexion entre les balises <think> pour Qwen3 et DeepSeek-R1.

J'adore !

Côté bidouille si vous vous lancer, sachez qu'il y a 2 ou 3 flags vachement utiles à connaitre.

Par exemple, le --warm-prompts (couplé au continuous batching) précharge les préfixes populaires au démarrage et, dans le bon scénario, vous gagne entre 1,3 et 2,25x sur le temps de première réponse.

Sur les gros modèles MoE genre Qwen3-30B-A3B, le --moe-top-k réduit aussi le nombre d'experts activés pour gratter 7 à 16% de débit. Le hic, c'est que vous y perdez un poil de qualité.

Et pour les agents qui brassent des contextes énormes, le --ssd-cache-dir déverse le cache de préfixes sur SSD pour soulager la RAM, au prix d'un peu de latence quand ça tape sur le disque.

Bref, si vous cherchez une alternative à Ollama qui tape direct dans le GPU de votre Mac avec du batching et du multimodal, le tout avec une compatibilité API aux petits oignons, foncez les amis ! C'est open source (Apache 2.0), ça dépote et ça s'installe en deux commandes !

Merci à Christian pour la découverte !

Si vous avez déjà tapé [ss -tulnp](https://www.it-connect.fr/lister-les-ports-en-ecoute-sous-linux-avec-lsof-netstat-et-ss/) dans un terminal, vous savez que c'est moche. Genre, VRAIMENT moche. Les colonnes qui se chevauchent, les adresses tronquées, bref c'est un festival du bordel. Mais c'était sans compter sur ce dev qui a pondu Snitch , un outil en Go sous licence MIT qui vient concurrencer ss et netstat... sauf que pour une fois, c'est lisible, regardez :

L'interface de Snitch en action, sobre et lisible

En gros, c'est un ss moderne avec une interface TUI interactive. Vous lancez la commande dans votre terminal et tadaaa, vous avez un tableau propre avec toutes vos connexions réseau, les processus associés, les ports, les protocoles... le tout avec des couleurs et une navigation au clavier. Rien à voir donc avec le pavé monochrome habituel !

Le truc cool aussi ce sont les filtres. Vous pouvez taper snitch ls proto=tcp state=listen pour ne voir que les sockets TCP en écoute, ou snitch ls proc=nginx pour traquer votre serveur web. Y'a même un filtre contains= pour chercher dans les adresses... genre contains=google pour voir tout ce qui cause avec Mountain View.

D'ailleurs, côté commandes c'est en fait bien fichu. snitch ls pour un tableau statique, snitch json pour du JSON brut si vous voulez scripter, et snitch watch -i 1s pour streamer les connexions en temps réel. Du coup ça s'intègre nickel dans vos pipelines.

La TUI elle-même vaut le détour. Vous naviguez avec j/k (comme dans Vim, forcément), vous basculez TCP/UDP avec t/u, et le plus jouissif... vous pouvez killer un processus directement avec la touche K. Plus besoin de noter le PID et d'ouvrir un autre terminal ! Sauf que attention, sur Linux faut quand même lancer en root pour avoir les infos complètes sur les processus, parce que l'outil va lire dans /proc/net/*. Ça ne marche pas non plus sur Windows, c'est Linux et macOS uniquement.

Pour ceux qui aiment personnaliser leur terminal (oui, je vous connaîs...), y'a une quinzaine de thèmes, Catppuccin, Dracula, Nord, Tokyo Night, Gruvbox... la config se fait dans ~/.config/snitch/snitch.toml et l'outil peut aussi conserver vos préférences de filtres entre les sessions (faut activer remember_state dans la config).

Côté installation, c'est pas la mer à boire. brew install snitch sur macOS, go install github.com/karol-broda/snitch@latest si vous avez Go, yay -S snitch-bin sur Arch, et y'a même des images Docker pour les plus prudents !

Donc si vous êtes du genre à surveiller votre trafic réseau ou à garder un oeil sur vos outils de diagnostic Linux , c'est clairement à tester.

Perso, pour du debug réseau rapide, je trouve que c'est carrément plus agréable que de se taper un ss -tulnp.

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

Si vous bossez sur Mac, vous connaissez sûrement la galère des Spaces. C'est sympa sur le papier, mais les animations natives d'Apple sont d'une lenteur... y'a de quoi se taper la tête contre les murs quand on veut switcher rapidement entre ses outils de dev et son navigateur. (Et ne me parlez pas du temps de réaction sur un vieux processeur Intel, c'est l'enfer). Bref, moi perso j'utilise pas trop ces trucs là parce que je trouve que c'est pas agréable.

Mais c'est là que FlashSpace entre en piste. Ce petit utilitaire open source, partagé par Vince (merci pour le tuyau !), a une mission simple : proposer un système de workspaces ultra-réactifs pour remplacer l'usage des Spaces natifs. L'idée déchire car au lieu de subir les transitions mollassonnes de macOS, on passe d'un environnement à l'autre de manière quasi instantanée.

Attention par contre, le fonctionnement est un peu particulier. J'ai d'abord cru qu'il créait de nouveaux Spaces dans Mission Control, mais en fait non, c'est plutôt un jeu de "j'affiche ou j'affiche pas les applications dont t'as besoin"... Pour que ça bombarde, FlashSpace recommande de regrouper toutes vos apps sur un seul et même Space macOS (par écran). L'outil gère ensuite des "workspaces virtuels" en masquant ou affichant les apps selon vos besoins. Résultat, une réactivité impressionnante même si ce n'est pas techniquement du "zéro latence" (faut bien que les fenêtres s'affichent quand même).

Pour ceux qui connaissent AeroSpace , FlashSpace se pose comme une alternative solide. Là où AeroSpace tend vers le tiling window management pur et dur à la i3, FlashSpace reste plus proche de l'esprit initial des Spaces mais en version survitaminée. C'est moins radical, plus invisible, mais perso je trouve ça tout aussi efficace pour rester dans le flow.

L'excitation quand on passe enfin d'un bureau à l'autre sans attendre 3 secondes ( Meme )

Côté fonctionnalités, c'est plutôt complet puisqu'on y retrouve du support du multi-écran (un petit clic dans Réglages Système > Bureau et Dock pour activer "Les écrans disposent de Spaces distincts"), gestionnaire de focus au clavier, et intégration avec SketchyBar . Y'a même un mode Picture-in-Picture expérimental (plutôt pour les navigateurs en anglais pour le moment) pour garder une vidéo sous le coude.

Petit bémol à connaître, il gère les applications, pas les fenêtres individuelles. Si vous avez trois fenêtres Chrome, elles bougeront donc toutes ensemble vers le workspace assigné. C'est un choix de design, faut juste s'y habituer mais grâce à ça on gagne encore quelques secondes de vie par jour.

brew install flashspace

Si vous avez déjà galéré à rendre accessible votre serveur web local à des testeurs externes... Ne désespérez plus car aujourd'hui, je vais vous présenter Pipenet , un petit utilitaire qui va vous changer la vie !

On a tous connu ce moment où on veut montrer une démo à un client ou tester un webhook et en général c'est à ce moment là que le drame se produit ! Configuration de la box, pare-feu qui fait la tête, redirection de ports qui ne veut rien savoir... Grosso merdo c'est la fin de votre productivité pour la matinée !

Mais grâce à l'équipe de glama.ai qui a codé cette alternative au bon vieux localtunnel, vous allez pouvoir exposer vos services locaux sur Internet en un clin d'œil. Et ce qui est cool c'est que contrairement à d'autres solutions qui deviennent vite limitées ou payantes, Pipenet vous laisse un contrôle total ! C'est ça la pwouiiiissance du logiciel libre !

Pour ceux qui se demandent ce qu'est exactement un tunnel TCP, c'est simplement un pont entre votre machine et le reste du monde !

Mais attention ! La sécurité (chiffrement et auth) dépend de la configuration ! Ça tombe bien puisque Pipenet supporte bien sûr le HTTPS et possède des options pour sécuriser votre propre serveur !

Il fait ça particulièrement bien en utilisant une architecture client et serveur. Vous pouvez donc utiliser leur serveur public par défaut (pipenet.dev) ou carrément héberger votre propre infrastructure de tunneling ! C’est top pour la confidentialité si vous pouvez l'auto-héberger !

Pour l'install, si vous avez Node.js, une simple commande suffit pour commencer à exposer votre port 3000 !

npx pipenet client --port 3000

Aujourd’hui, j’aimerais vous présenter LocalAI, une alternative open source à OpenAI. En tout cas, c’est comme ça que le créateur du projet le présente. Il s’agit d’une solution idéale pour tous ceux qui cherchent une API REST compatible avec les spécifications de l’API OpenAI pour l’inférence locale.

Grâce à LocalAI, vous pouvez exécuter des modèles linguistiques, générer des images, de l’audio et bien d’autres choses encore, localement ou sur site avec du matériel grand public, et ce, sans avoir besoin d’un GPU ! Le projet a pour principal objectif de rendre l’IA accessible à tous.

Pour résumer, voici les principales caractéristiques de LocalAI :

• Une API REST locale, alternative à OpenAI. Comme ça, vous gardez bien au chaud vos propres données.
• Pas besoin de GPU. Pas besoin d’accès internet non plus. Toutefois, l’accélération GPU est possible en option.
• Prise en charge de plusieurs modèles.
• Dès qu’ils sont chargés une première fois, les modèles restent en mémoire pour une inférence plus rapide.
• N’utilise pas de shell, mais des liaisons directes pour une inférence plus rapide et de meilleures performances.

En termes de fonctionnalités, LocalAI offre une large gamme d’options, parmi lesquelles :

• La génération de texte avec les modèles GPT (comme llama.cpp ou gpt4all.cpp).
• La conversion de texte en audio.
• La transcription audio en texte avec whisper.cpp.
• La génération d’images avec Stable Diffusion.
• Les dernières fonctionnalités d’OpenAI récemment ajoutées comme l’API Vision par exemple.
• La génération d’embeddings pour les bases de données vectorielles.
• Les grammaires contraintes.
• Le téléchargement de modèles directement à partir de Huggingface.

LocalAI est bien sûr un projet communautaire donc n’hésitez pas si vous souhaitez vous impliquer !

Pour commencer rapidement avec LocalAI, vous pouvez consulter leur guide Getting Started qui décrit les différentes méthodes d’installation et les exigences matérielles ou aller consulter les guides de la communauté. Je vous ferais aussi probablement un tutoriel prochainement si mon emploi du temps me le permet.

LocalAI est disponible sous forme d’image conteneur et de binaire, compatible avec divers moteurs de conteneurs tels que Docker, Podman et Kubernetes. Les images de conteneurs sont publiées sur quay.io et Docker Hub, et les binaires peuvent être téléchargés à partir de GitHub.

Concernant les exigences matérielles, ça varie en fonction de la taille du modèle et de la méthode de quantification utilisée mais pour choper quelques repères de performance avec différents backends, comme llama.cpp, vous pouvez consulter ce lien.

Maintenant pour en savoir plus, vous pouvez explorer le site localai.io. Vous y trouverez de nombreuses informations et des exemples d’utilisation pour vous aider à tirer le meilleur parti de LocalAI.

Merci à Lorenper