Si vous avez toujours voulu essayer Emacs mais que la courbe d'apprentissage vous fait peur, IDEmacs est fait pour vous ! Ce projet transforme Emacs en clone de VSCode avec les mêmes raccourcis clavier, la même interface graphique et les mêmes fonctionnalités out-of-the-box, comme ça vous n'avez plus besoin de vous taper une configuration durant trois jours avant de pouvoir écrire une ligne de code !

Cool, hein ?

L'idée c'est donc de permettre aux développeurs habitués à des IDE modernes de passer à Emacs sans devoir réapprendre tous leurs réflexes. Les raccourcis clavier reprennent ceux de VSCode comme Ctrl+C pour copier, Ctrl+V pour coller, Ctrl+F pour chercher. C'est basique mais indispensable quand vous venez d'un autre éditeur.

Côté interface, IDEmacs intègre Treemacs pour avoir un explorateur de fichiers dans la sidebar comme sur VSCode. Y'a aussi Centaur Tabs pour les onglets, un thème Dark Plus qui ressemble à celui de Microsoft, et le support des curseurs multiples. Bref, visuellement vous êtes en terrain connu.

Du coup, c'est pour qui exactement ?

Hé bien le projet cible trois types d'utilisateurs : les développeurs qui veulent migrer vers Emacs depuis un autre IDE, les débutants en Lisp ou Scheme qui ont besoin d'Emacs pour bosser, et les non-programmeurs qui cherchent juste un éditeur de texte puissant sans se prendre la tête avec la config.

D'ailleurs, contrairement à la plupart des starter kits Emacs, IDEmacs ne cache pas les éléments graphiques par défaut. Les menus, barres d'outils et scrollbars sont visibles donc vous pouvez configurer le tout via l'interface graphique plutôt qu'en écrivant du Elisp à la main.

La config proposée inclut une vingtaine de packages tels que Vertico, Consult et Marginalia pour l'autocomplétion, Magit pour le contrôle de version, Sly et Geiser pour le développement Lisp et Scheme, plus des outils comme expand-region, multiple-cursors et smartparens pour l'édition avancée.

Pour installer IDEmacs, il vous faudra donc Emacs 29 ou plus récent, git, et optionnellement grep et locate. Clonez le repo puis lancez Emacs avec

emacs --init-directory=/path/to/IDEmacs/vscode .

Vous utilisez Claude Code comme moi pour bosser plus vite sur vos projets de dev ? Hé bien j'espère que vous n'avez jamais eu la mauvaise surprise de voir l'agent lancer un petit rm -rf ~/ qui détruit tout votre répertoire home en 2 secondes. Parce que oui, ça arrive malheureusement, et plusieurs devs en ont fait les frais cette année...

Le problème c'est que les agents IA, aussi intelligents soient-ils, peuvent manquer de garde-fous sur ce qui est vraiment dangereux. Vous leur dites "nettoie le projet" et hop, ils interprètent ça un peu trop littéralement et une fois que c'est fait, y'a plus qu'à pleurer devant son terminal vide.

C'est pour ça qu'un développeur du nom de kenryu42 a créé Claude Code Safety Net qui est un plugin pour Claude Code qui agit comme un garde-fou mécanique. Son idée c'est de bloquer les commandes destructives AVANT qu'elles ne s'exécutent, et pas juste avec des règles bêtes genre "si la commande commence par rm -rf".

Le plugin est bien plus malin que ça puisqu'il fait une analyse sémantique des commandes. Il comprend la différence entre git checkout -b nouvelle-branche (qui est safe, ça crée juste une branche) et git checkout -- . qui lui va dégager tous vos changements non committés sur les fichiers suivis. Les deux commencent pareil, mais l'une vous sauve et l'autre vous ruine psychologiquement, vous forçant à vous réfugier dans la cocaïne et la prostitution.

Et c'est pareil pour les force push. Le plugin bloque git push --force qui peut écraser l'historique distant et rendre la récupération très difficile, mais il laisse passer git push --force-with-lease qui est la version plus sûre, car elle vérifie que la ref distante correspond à ce qu'on attend (même si ce n'est pas une garantie absolue).

Et le truc vraiment bien foutu, c'est qu'il détecte aussi les commandes planquées dans des wrappers shell. Vous savez, le genre de piège où quelqu'un écrit sh -c "rm -rf /" pour bypass les protections basiques. Le plugin parse récursivement et repère la commande dangereuse à l'intérieur. Il fait même la chasse aux one-liners Python, Ruby ou Node qui pourraient faire des dégâts.

Côté rm -rf, le comportement par défaut est plutôt permissif mais intelligent... les suppressions dans /tmp ou dans le dossier de travail courant sont autorisées parce que c'est souvent légitime, par contre, tenter de nuke votre home ou des dossiers système, c'est non négociable.

Et pour les paranos (comme moi), y'a un mode strict qu'on active avec SAFETY_NET_STRICT=1. Dans ce mode, toute commande non parseable est bloquée par défaut, et les rm -rf même dans le projet courant demandent validation. Mieux vaut prévenir que pleurer.

Si ça vous chauffe, l'installation se fait via le système de plugins de Claude Code avec deux commandes :

/plugin marketplace add kenryu42/cc-marketplace
/plugin install safety-net@cc-marketplace

Si vous utilisez GitHub Copilot ou ChatGPT pour coder plus vite, voici une nouvelle qui va peut-être vous refroidir un peu. Une fintech a découvert que des attaquants avaient extrait des données clients via un endpoint API qui n'était documenté nulle part. Personne dans l'équipe ne se souvenait l'avoir créé et après 3 semaines d'enquête, le verdict est tombé : c'est Copilot qui l'avait généré pendant une session de code nocturne.

Bienvenue dans l'ère des "phantom APIs" les amis !

J'avoue que le concept m'a fait marrer car on parle quand même d'endpoints qui existent en production mais dont personne n'a connaissance. Ahahaha... y'a pas de documentation, pas de tests, pas de validation de sécurité. C'est juste un peu de code généré par une IA qui a trouvé ça "logique" de créer un /api/v2/admin/debug-metrics qui balance du PII à quiconque tombe dessus par hasard.

J'ai vu le dernier rapport Veracode GenAI Code Security et les chiffres font un peu flipper c'est vrai ! Ils ont testé plus de 100 LLM sur 80 tâches de codage différentes, et le résultat fait mal puisque 45% du code généré par IA contient des vulnérabilités classées OWASP Top 10. En gros, presque une fois sur deux, votre assistant IA vous pond du code troué comme une passoire. Java est le grand gagnant avec 72% de taux d'échec, suivi par Python, JavaScript et C# qui tournent autour de 38-45%.

En effet, l'IA ne pense pas comme un dev qui s'est déjà fait hacker. Par exemple, quand un dev crée un endpoint, il réfléchit authentification, rate limiting, exposition de données, documentation. Alors que l'IA, elle, génère juste ce qui lui semble statistiquement logique vu son dataset d'entraînement, sans comprendre les implications sécurité ou les politiques de l'organisation.

D'ailleurs une autre étude Apiiro montre que les assistants IA ont multiplié par 10 les vulnérabilités introduites en seulement 6 mois dans les dépôts étudiés. Les chemins d'escalade de privilèges ont explosé tout comme les défauts architecturaux. Et le pire c'est que les développeurs qui utilisent l'IA exposent leurs credentials cloud (clés Azure, Storage Access Keys) deux fois plus souvent que les autres.

Y'a aussi le problème du "slopsquatting". Oui, encore un gros mot, je sais... En fait, l'IA peut vous recommander d'installer un package qui n'existe tout simplement pas. Genre elle hallucine un nom de librairie et un attaquant un peu moins con que les autres, peut enregistrer ce nom sur npm ou PyPI et y foutre du code malveillant.

Et là que ça devient vraiment problématique, c'est que les outils de sécurité traditionnels ne voient rien. L'analyse statique compare votre code à des specs documentées, sauf que les phantom APIs n'existent dans aucune spec. Les API gateways protègent les endpoints enregistrés mais laissent passer des routes non déclarées sans authentification.

Pour s'en sortir, certaines boîtes commencent donc à analyser le trafic en temps réel pour détecter les endpoints qui traînent. Y'a aussi l'audit de code spécifique IA pour repérer les patterns de génération algorithmique, et la comparaison continue entre les specs et ce qui tourne vraiment en production.

Bref, relisez votre code généré par IA comme si c'était un stagiaire collégien de 3e qui l'avait écrit, et si vous découvrez un endpoint bizarre dans votre base de code dont personne ne se souvient, y'a des chances que ce soit un "fantôme" laissé par votre copilote préféré...

Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !

Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.

Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.

Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :

grep -l "AdministratorAccess" */global/iam/users/*/policies.json

diff prod/global/iam/roles/api/info.json staging/global/iam/roles/api/info.json

go install github.com/semonte/sisu@latest

Passer d'OpenGL à Metal, c'était visiblement pas une mince affaire pour l'équipe d'OBS. La techno d'Apple est sortie y'a 10 ans sous macOS mais ça leur a pris un peu de temps pour la migration... Et n'allez pas croire que je "juge"... Tout ce temps, c'est normal car c'est un soft multiplateforme, donc faut gérer trois écosystèmes en parallèle et ça, ça prend un temps fou.

Tous les effets visuels d'OBS ont dû être réécrits pour fonctionner avec Metal, le langage graphique d'Apple étant bien plus exigeant que celui de Windows et la preview peut parfois légèrement saccader à cause de macOS, mais le flux final reste impeccable.

Niveau performances, Metal fait aussi bien voire mieux qu'OpenGL dans les builds Release mais c'est surtout pour le débogage que ça change tout car les développeurs ont maintenant accès à des outils de diagnostic bien plus performants, ce qui devrait accélérer les corrections de bugs et les futures améliorations.

Pour l'activer (ouais on est chaud !!), c'est hyper simple. Vous allez dans les paramètres d'OBS 32.0, onglet Avancé, section Vidéo, et vous sélectionnez Metal dans le menu déroulant du renderer. Un petit redémarrage de l'appli et hop, vous êtes passé sur le nouveau moteur.

Ce qui est cool aussi avec cette version 32.0, c'est qu'elle inclut un gestionnaire de plugins et des améliorations pour les fonctionnalités NVIDIA RTX.

L'équipe OBS bosse aussi sur des backends Vulkan pour Linux et Direct3D 12 pour Windows, parce que les anciennes APIs comme OpenGL et D3D11 reçoivent de moins en moins de support des fabricants de GPU, donc si vous êtes sur Linux ou Windows, votre tour viendra aussi.

Voilà, après si ça bug, revenez sur OpenGL, mais y'a quand même de bonnes chances que ça tourne mieux qu'avant.

Source

Boston Dynamics que vous connaissez tous pour ses chiens robots tueurs de la mort, vient de sortir une vidéo de 40 minutes. Pas de saltos arrière ou de robots qui dansent mais plutôt une loooongue session où ça parle stratégie IA et vision à long terme. Et comme j'ai trouvé que c'était intéressant, je partage ça avec vous !

Zach Jacowski, le responsable d'Atlas (15 ans de boîte, il dirigeait Spot avant), discute donc avec Alberto Rodriguez, un ancien prof du MIT qui a lâché sa chaire pour rejoindre l'aventure et ce qu'ils racontent, c'est ni plus ni moins comment ils comptent construire un "cerveau robot" capable d'apprendre à faire n'importe quelle tâche. Je m'imagine déjà avec un robot korben , clone de ma modeste personne capable de faire tout le boulot domestique à ma place aussi bien que moi... Ce serait fou.

Leur objectif à Boston Dynamics, c'est donc de créer le premier robot humanoïde commercialement viable au monde et pour ça, ils ont choisi de commencer par l'industrie, notamment les usines du groupe Hyundai (qui possède Boston Dynamics).

Alors pourquoi ? Hé bien parce que même dans les usines les plus modernes et automatisées, y'a encore des dizaines de milliers de tâches qui sont faites à la main. C'est fou hein ? Automatiser ça c'est un cauchemar, car pour automatiser UNE seule tâche (genre visser une roue sur une voiture), il faudrait environ un an de développement et plus d'un million de dollars.

Ça demande des ingénieurs qui conçoivent une machine spécialisée, un embout sur mesure, un système d'alimentation des vis... Bref, multiplié par les dizaines de milliers de tâches différentes dans une usine, on serait encore en train de bosser sur cette automatisation dans 100 ans...

L'idée de Boston Dynamics, c'est donc de construire un robot polyvalent avec un cerveau généraliste. Comme ça au lieu de programmer chaque tâche à la main, on apprend au robot comment faire. Et tout comme le font les grands modèles de langage type ChatGPT, ils utilisent une approche en deux phases : le pre-training (où le robot accumule du "bon sens" physique) et le post-training (où on l'affine pour une tâche spécifique en une journée au lieu d'un an).

Mais le gros défi, c'est clairement les données. ChatGPT a été entraîné sur à peu près toute la connaissance humaine disponible sur Internet mais pour un robot qui doit apprendre à manipuler des objets physiques, y'a pas d'équivalent qui traîne quelque part.

Du coup, ils utilisent trois sources de data.

La première, c'est la téléopération. Des opérateurs portent un casque VR, voient à travers les yeux du robot et le contrôlent avec leur corps. Après quelques semaines d'entraînement, ils deviennent alors capables de faire faire à peu près n'importe quoi au robot. C'est la donnée la plus précieuse, car il n'y a aucun écart entre ce qui est démontré et ce que le robot peut reproduire. Par contre, ça ne se scale pas des masses.

La deuxième source, c'est l'apprentissage par renforcement en simulation. On laisse le robot explorer par lui-même, essayer, échouer, optimiser ses comportements. L'avantage c'est qu'on peut le faire tourner sur des milliers de GPU en parallèle et générer des données à une échelle impossible en conditions réelles. Et contrairement à la téléopération, le robot peut apprendre des mouvements ultra-rapides et précis qu'un humain aurait du mal à démontrer, du genre faire une roue ou insérer une pièce avec une précision millimétrique.

La troisième source, c'est le pari le plus ambitieux, je trouve. Il s'agit d'apprendre directement en observant des humains.

Alors est-ce qu'on peut entraîner un robot à réparer un vélo en lui montrant des vidéos YouTube de gens qui réparent des vélos ? Pas encore... pour l'instant c'est plus de la recherche que de la production, mais l'idée c'est d'équiper des humains de capteurs (caméras sur la tête, gants tactiles) et de leur faire faire leur boulot normalement pendant que le système apprend.

Et ils ne cherchent pas à tout faire avec un seul réseau neuronal de bout en bout. Ils gardent une séparation entre le "système 1" (les réflexes rapides, l'équilibre, la coordination motrice, un peu comme notre cervelet) et le "système 2" (la réflexion, la compréhension de la scène, la prise de décision). Le modèle de comportement génère des commandes pour les mains, les pieds et le torse, et un contrôleur bas niveau s'occupe de réaliser tout ça physiquement sur le robot.

C'est bien pensé je trouve. Et dans tout ce bordel ambiant autour de la robotique actuelle, eux semblent avoir trouver leur voie. Ils veulent transformer l'industrie, les usines...etc. Leur plan est clair et ils savent exactement ce qu'ils doivent réussir avant de passer à la suite (livraison à domicile, robots domestiques...).

Voilà, je pense que ça peut vous intéresser, même si c'est full english...

Vous développez un truc en local et vous avez besoin de le montrer à quelqu'un au travers d'Internet, genre pour tester un webhook, faire une démo rapide, ou juste impressionner votre collègue à distance ? Hé bien au lieu de vous farcir une config nginx + certificats SSL + ouverture de ports sur le routeur (Beurk !), y'a Tunnl.gg qui fait tout ça en une SEULE ligne de commande.

Vous tapez une commande SSH, et hop, vous avez une URL publique qui pointe vers votre serveur local. Pas de client à installer, pas de compte à créer, pas de token à configurer, juste SSH, que vous avez forcément déjà sur votre machine.

Donc pour exposer votre app qui tourne sur le port 8080, vous faites :

ssh -t -R 80:localhost:8080 proxy.tunnl.gg

Et c'est parti ! Le service vous file une URL avec un sous-domaine aléatoire, genre abc123.tunnl.gg, et tout ce qui arrive dessus est redirigé vers votre localhost:8080. Et magie magie, HTTPS est automatique, donc pas besoin de vous soucier des certificats.

Du coup, si vous connaissez déjà ce genre d'outils, vous pensez peut-être à Bore que j'ai présenté il y a pas longtemps, ou Portr qui fait sensiblement la même chose, ou encore Chisel pour les amateurs de tunnels TCP/UDP via HTTP. Tous ces outils font du tunneling, mais Tunnl.gg se distingue par son approche "zéro friction" sans binaire à télécharger, et sans compte à vous créer.

Pour le moment, le service est gratuit pour un usage personnel mais les développeurs prévoient des plans payants plus tard avec des features comme les domaines personnalisés, les sous-domaines persistants et des limites de débit plus élevées. On verra bien mais en attendant, pour tester un truc vite fait ou faire une démo, la version gratuite suffira largement.

Bon, y'a quand même quelques trucs à savoir. Primo, ça ne marche qu'avec du trafic HTTP/HTTPS pour l'instant. Deuxio, le TLS est côté serveur, donc techniquement ils peuvent voir votre trafic même s'ils disent ne pas l'inspecter. Donc pour des données vraiment sensibles, gardez ça en tête. Et tertio, comme tout service de ce type, y'a des limites de fair-use pour éviter les abus.

Bref, si vous cherchez un moyen rapide d'exposer un port local sans vous prendre la tête avec la config, Tunnl.gg fera le taf. Au pire vous aurez découvert une alternative de plus à ngrok , au mieux ça deviendra votre outil par défaut pour les démos express...

Merci à Lorenper pour le partage !

Vous savez que depuis quelques années, des startups équipent les camions poubelle et les bus de caméras IA pour cartographier automatiquement l'état des routes ? Comme ça, pendant que le chauffeur fait sa tournée, une intelligence artificielle détecte les nids-de-poule, les fissures et autres joyeusetés routières en temps réel. Chaque défaut est géolocalisé, scoré par gravité, et hop, les équipes de maintenance savent exactement où intervenir.

Bon apparemment, là où j'habite, ils n'utilisent pas ça parce que les routes sont des champs de mines, mais si le Maire se chauffe en DIY, ce projet maintenu par un certain Peter va l'intéresser.

C'est sur GitHub et c'est un stack complet pour faire exactement la même chose que les startups spécialisées en nids de poule... un vrai projet end-to-end avec l'entraînement du modèle sur du GPU cloud, une API backend containerisée, et même une app mobile React Native pour scanner les routes depuis votre téléphone.

Le projet s'appelle pothole-detection-yolo et ça utilise YOLOv8, le modèle de détection d'objets qui fait fureur en ce moment dans le domaine de la vision par ordinateur. Concrètement, le modèle a été entraîné sur un dataset de nids-de-poule disponible sur HuggingFace, avec des images de 640x640 pixels. L'entraînement s'est fait sur Nebius Cloud avec des GPUs H100, donc du sérieux, pas du Colab gratuit qui timeout au bout de 20 minutes.

Ce qui est cool avec ce projet, c'est qu'il ne s'arrête pas au modèle. Y'a une API FastAPI complète qui expose deux endpoints : /detect pour envoyer une image et récupérer les bounding boxes avec les scores de confiance, et /health pour vérifier que le service tourne. Le tout est containerisé en Docker avec support GPU automatique. Et si vous avez pas de carte graphique, ça bascule sur CPU.

Et la cerise sur le gâteau, c'est l'app mobile Expo/React Native. Vous ouvrez l'app, vous prenez une photo d'une route avec votre smartphone, l'image est envoyée à l'API, et vous récupérez les détections en temps réel avec les rectangles dessinés autour des nids-de-poule et les pourcentages de confiance affichés. Bref, c'est exactement ce que font les boites tech à plusieurs millions, sauf que là c'est open source sous licence Apache 2.0.

YOLOv8 atteint facilement entre 93 et 99% de précision pour la détection de nids-de-poule selon les variantes utilisées et des chercheurs ont même combiné YOLOv8 avec des données de nuages de points 3D pour atteindre 95.8% de précision sur des tronçons de tests d'environ 5 km. Bref, c'est du solide et ça fonctionne .

Le truc intéressant pour les bricoleurs, c'est que le modèle entraîné est directement téléchargeable sur HuggingFace donc vous pouvez donc skip toute la partie entraînement si vous voulez juste tester le résultat. Une seule commande Docker pour lancer l'API, et vous êtes opérationnel. Pour les plus motivés qui veulent entraîner leur propre modèle avec des données locales de vos routes françaises pleines de cratères, le code d'entraînement est là aussi avec les configs Ultralytics.

Bref, si vous êtes une petite mairie qui veut cartographier l'état de vos routes sans claquer 50 000 euros dans une solution proprio, ou juste un dev curieux de voir comment fonctionne la stack derrière ces caméras intelligentes qu'on voit de plus en plus sur les véhicules de service, ce projet est une mine d'or.

Tout est là , documenté, et ça fonctionne du feu de dieu.

Si vous cherchez un utilitaire en ligne de commande simple à utiliser qui permette de transférer des fichiers et des répertoires entre 2 ordinateurs, voici un projet très cool qui mérite vraiment le coup d'œil.

Le projet s'appelle Croc et il permet d'envoyer ou recevoir des fichiers au travers d'Internet via un serveur relais, directement depuis le terminal, et cela aussi bien depuis un Mac qu'un Linux ou un Windows. Les transmissions sont chiffrées de bout en bout à l'aide de la méthode PAKE (Password-Authenticated Key Exchange), ce qui permet de générer des clés de chiffrement robustes même à partir de mots de passe faibles. Du coup, même si quelqu'un intercepte votre code de transfert, il ne pourra pas décrypter vos données.

Vous pouvez transférer plusieurs fichiers en même temps, et si par malheur un transfert est interrompu, Croc saura automatiquement le reprendre. Et si vous voulez vraiment améliorer les choses niveau confidentialité, vous pouvez même spécifier un proxy Tor.

L'outil fonctionne sans avoir besoin de configurer quoi que ce soit côté réseau. Pas de serveur à installer, pas de port forwarding à configurer sur votre box, ça passe à travers les firewalls et les NAT sans broncher. Et le petit plus sympa, c'est qu'il supporte IPv6 en priorité avec fallback IPv4.

Pour l'installer, c'est hyper simple. Avec curl :

curl https://getcroc.schollz.com | bash

Sur Mac avec Homebrew :

brew install croc

Sur Windows avec Scoop ou Chocolatey :

scoop install croc

choco install croc

Y'a aussi des packages pour Arch (pacman), Fedora (dnf), Nix, Conda, et même une image Docker si vous préférez.

Pour envoyer un fichier, vous tapez :

croc send FICHIER_OU_DOSSIER

Vous obtiendrez alors un code (genre trois mots random) que vous devrez transmettre à votre destinataire. Celui-ci n'aura qu'à entrer :

croc LE-CODE-RECU

Et hop, la connexion s'établit et le fichier se transfère direct. Vous pouvez même envoyer du texte au lieu d'un fichier avec :

croc send --text "votre message secret"

Et pour les paranos qui ne veulent faire confiance à personne, il est possible de lancer votre propre serveur relais avec :

croc relay

Du coup vous n'êtes plus dépendant des relais publics et tout reste chez vous.

Bref, Croc c'est le genre d'outil qu'on installe une fois et qu'on utilise durant des années car c'est simple, efficace, sécurisé. Et comme ce projet a plus de 33 000 étoiles sur GitHub, je pense que c'est pas juste moi qui trouve ça cool...

Article publié initialement le 15/12/2021 et mis à jour le 19/12/2025

Voilà un outil qui va plaire à ceux qui chassent les failles de sécurité... Ce projet s'appelle Security Skills et c'est un système de compétences pour agents IA (genre Claude Code ou Gemini CLI) qui transforme votre proxy mitmproxy en chasseur de failles automatisé. Vous lui dites "trouve-moi des problèmes de sécurité sur example.com" et l'IA se met à analyser le trafic HTTP intercepté en appliquant des patterns qu'elle a appris de vrais bugs rémunérés.

Le mec derrière cet outil a commencé par récupérer 10 000 rapports de bugs sur HackerOne via un dataset Hugging Face, qu'ensuite, il a filtré pour ne garder que les 4000 qui ont reçu un paiement, partant du principe que si une boîte a sorti le portefeuille, c'est que la faille était sérieuse. Et avec ces 4000 exemples concrets, il a créé 17 Skills différents qui savent détecter des trucs comme les IDOR (quand vous pouvez accéder aux données d'un autre utilisateur juste en changeant un ID dans l'URL), les SSRF, les injections SQL, les fuites de secrets et j'en passe.

Ce qui est malin avec cette approche, c'est qu'il n'a pas essayé de tout coller dans le prompt système du LLM. Comme sa première version avec 150 descriptions de bugs collées directement dans les instructions faisait exploser les coûts et le contexte, il a décidé de découper ça en modules réutilisables. Chaque Skill étant un fichier markdown avec ses propres patterns de détection, quand vous demandez à l'IA de chercher des failles d'authentification, elle va chercher le bon Skill et l'appliquer intelligemment.

Le système tourne avec CodeRunner, un serveur MCP open source qui exécute du code IA dans une sandbox isolée sur Mac donc c'est plutôt moderne, et ça utilise aussi les conteneurs natifs d'Apple pour l'isolation et ça supporte pas mal de LLM différents comme Claude, ChatGPT, Gemini ou même des modèles locaux.

Et le succès est au rendez-vous car l'auteur raconte avoir testé son système sur Vercel et trouvé une faille sur leur endpoint /avatar?u=USERNAME qui permettait d'énumérer les noms d'utilisateurs. Le genre de bug classique IDOR que l'IA a repéré automatiquement en analysant le trafic capturé. Bon, c'est pas le hack du siècle, mais ça prouve que le système arrive à appliquer ce qu'il a appris des vrais rapports de bug bounty.

Pour l'installer, faut cloner le repo CodeRunner, puis lancer l'installeur et le serveur MCP deviendra accessible localement. Ensuite vous pouvez l'utiliser avec n'importe quel client compatible MCP, que ce soit Claude Desktop, Gemini CLI ou même votre propre interface. Les Security Skills sont dans un repo séparé et contiennent toute la logique de détection dérivée des 4000 rapports en question.

Voilà encore un bel exemple de comment on peut vraiment utiliser les LLM pour des tâches de sécurité concrètes, et pas juste pour générer du code. Et j'ai trouvé l'idée d'apprendre à partir de vrais bugs payés plutôt que de documentation théorique, plutôt pas con.

Voilà, si vous faites du bug bounty ou que vous voulez automatiser vos tests de sécu, ça vaut le coup d'y jeter un œil .

Vous avez des tonnes de vieux documents papier qui traînent dans des cartons, des factures scannées à l'arrache, des formulaires remplis à la main, des tableaux Excel imprimés puis re-scannés par quelqu'un qui n'a visiblement jamais entendu parler du concept de "bien faire son boulot" ?

Considérez que ce problème est réglé puisque Mistral AI vient de sortir OCR 3, un modèle de reconnaissance de documents qui promet de transformer tout ça en données exploitables, et pour pas cher en plus.

Le modèle est capable de déchiffrer du cursif dégueulasse, des annotations griffonnées dans les marges, voire du texte manuscrit par-dessus des formulaires imprimés. Mistral montre même une démo avec une lettre au Père Noël écrite par un gamin et l'OCR arrive à en extraire le contenu structuré. Bon, c'est cool pour les lettres au Père Noël, mais surtout ça veut dire qu'il peut gérer vos ordonnances médicales ou les notes de réunion de votre collègue qui écrit comme un cochon.

Niveau performances, Mistral annonce un taux de victoire de 74% sur leur précédent modèle OCR 2 et sur les solutions concurrentes. Et comme c'est testé sur des cas réels d'entreprises avec des mesures de précision en fuzzy-match, on n'est pas dans du benchmarks théoriques bidon. Le modèle gère les scans pourris avec compression JPEG, les documents de travers, les faibles résolutions, le bruit de fond... Bref, tout ce qui fait que l'OCR traditionnel vous sort de la bouillie.

Et ce qui est vraiment intéressant, c'est surtout la reconstruction structurelle car contrairement aux OCR classiques qui vous crachent un bloc de texte en vrac, Mistral OCR 3 reconstruit la structure du document. Les tableaux complexes avec cellules fusionnées et hiérarchies de colonnes ressortent en HTML propre avec les colspan et rowspan préservés. Vous obtenez du markdown enrichi en sortie, directement exploitable par vos systèmes sans avoir à nettoyer le bordel derrière.

Côté tarifs, c'est 2 dollars pour 1000 pages et si vous passez par l'API Batch, c'est moitié moins cher à 1 dollar les 1000 pages. Pour un modèle qui se dit plus petit que la plupart des solutions concurrentes tout en étant plus précis, c'est plutôt compétitif. Le modèle peut traiter jusqu'à 2000 pages par minute sur un seul nœud, donc même si vous avez des millions de documents à numériser, ça devrait pas prendre des plombes.

Vous faites un peu de l'électronique et vous utilisez KiCad pour vos PCB ?

Et si l'avenir de la conception électronique c'était aussi l'IA ? J'en sais rien mais ce qui a l'air de se profiler à l'horizon avec ce dataset qui vient de sortir sur Hugging Face et qui devrait intéresser pas mal de monde. Ça s'appelle Open Schematics et c'est une collection de plus de 84 000 schémas électroniques au format KiCad, prêts à être utilisés pour entraîner des modèles d'IA.

Le truc c'est que jusqu'à maintenant, si vous vouliez créer une IA capable de comprendre ou de générer des schémas électroniques, y'avait pas vraiment de dataset propre et bien structuré pour ça. Bhupendra Hada (alias bshada sur Hugging Face) a donc décidé de combler ce manque en compilant tout ça à partir de projets hardware open source trouvés sur GitHub.

Chaque entrée de son dataset contient donc le fichier schéma brut au format .kicad_sch, une image PNG du rendu, la liste des composants utilisés, et des métadonnées en JSON et YAML. Du coup vous avez tout ce qu'il faut pour entraîner un modèle à faire du text-to-image, de l'image-to-text, ou de la génération de circuits à partir de specs.

Le dataset pèse 6,67 Go au format Parquet et couvre une variété de projets assez dingue. On y trouve des cartes de programmation UART, des amplificateurs à tubes, des onduleurs triphasés open source, des points d'extrémité Zigbee, des projets ESP32+RS232, et même des macropads custom. Bref, y'a de tout, du projet étudiant au truc bien avancé.

Ce qui est cool c'est que le dataset est structuré pour plusieurs cas d'usage. Vous pouvez l'utiliser pour entraîner une IA à reconnaître des composants sur un schéma, à générer de la documentation automatique depuis un circuit, à détecter des erreurs de conception, ou même à suggérer des améliorations. Y'a aussi un potentiel éducatif évident pour créer des outils d'apprentissage interactifs en électronique.

Bien sûr, la qualité et la complexité des schémas varient pas mal d'un projet à l'autre. Certains ont des métadonnées incomplètes, et les conventions de nommage des composants sont pas toujours cohérentes... C'est le souci quand on scrappe des projets open source, y'a du bon et du moins bon mais pour un dataset de cette taille, c'est déjà une base de travail solide.

Le tout est sous licence CC-BY-4.0, donc vous pouvez l'utiliser librement du moment que vous créditez la source. Que vous bossiez sur de l'IA appliquée à l'électronique ou que vous cherchiez juste une grosse base de schémas KiCad à explorer, c'est clairement une ressource à bookmarker.

Source

Vous utilisez Claude Code ? Alors vous savez probablement que l'outil d'Anthropic peut être étendu avec des "Skills", c'est à dire des modules qui ajoutent des capacités supplémentaires à Claude. Y'a un fichier SKILL.md, des scripts optionnels, et comme ça, votre assistant sait faire de nouvelles choses. Sauf que pour trouver ces skills quand on n'a pas envie de se les palucher à la main (ou à l'IA), faut aller les chercher dans les repos GitHub, fouiller les README, comparer les étoiles... La flemme quoi...

C'est la raison d'être de SkillsMP qui vient résoudre ce problème. C'est en fait un marketplace communautaire (pas affilié à Anthropic) qui agrège plus de 26 000 skills Claude provenant de dépôts GitHub publics, le tout présenté dans une interface qui ressemble à un App Store, avec des catégories, des stats, et tout le toutim.

Je vous préviens d'emblée, le site est un peu bordélique. Entre les filtres, les catégories (Développement, Outils, Data & AI, DevOps...), les tris par popularité ou mise à jour récente, et l'interface du tur-fu, faut un peu tâtonner au début. Mais une fois qu'on a pigé comment ça marche, c'est vraiment cool de pouvoir explorer tout ça au même endroit.

Le truc intéressant c'est que SkillsMP filtre automatiquement les repos de mauvaise qualité. Pour qu'un skill apparaisse, il faut minimum 2 étoiles sur GitHub. Ça évite de se retrouver avec des trucs abandonnés ou mal foutus. Y'a même un badge "Marketplace Ready" pour les skills qui ont un fichier marketplace.json bien configuré.

Pour installer un skill que vous avez trouvé, vous avez alors 3 options. Soit vous le mettez dans ~/.claude/skills/ pour l'avoir disponible partout sur votre machine. Soit vous le collez dans .claude/skills/ dans votre projet si vous voulez le partager avec votre équipe via Git. Soit vous passez par l'installation plugin avec une commande du genre /plugin marketplace add anthropics/skills.

La différence avec les commandes slash c'est que les skills sont "model-invoked". Ça veut dire que c'est Claude qui décide tout seul quand les utiliser en fonction du contexte de votre demande. Vous n'avez donc pas besoin de taper /truc pour activer un skill, il se déclenche automatiquement quand c'est pertinent.

Attention quand même, comme toujours avec du code open source venu d'Internet, les développeurs de SkillsMP le précisent bien, ils filtrent les repos pourris mais ça reste votre responsabilité de vérifier ce que vous installez. Un skill a accès à pas mal de trucs sur votre machine, donc prenez 2 minutes pour auditer le code avant d'installer un truc d'un développeur inconnu.

Bref, si vous passez beaucoup de temps sur Claude Code et que vous voulez découvrir ce que la communauté a créé comme extensions, SkillsMP c'est un bon point de départ. C'est gratuit, y'a pas besoin de compte, et ça vous évite de passer des heures à fouiller GitHub manuellement.

Un grand merci à Lorenper pour le partage !

Parfois, c'est galère de chercher des logiciels sur GitHub... et je sais de quoi je parle car je passe littéralement mes journées à faire ça... Faut trouver un projet cool, faut aller dans les releases ou le compiler, l'installer, le tester et ensuite déterminer si ça vous sera utile avant de passer à la rédaction d'un article comme celui que vous êtes en train de lire.

J'adore faire ça mais aller digger Github, ça peut vite devenir pénible.

Alors ça tombe bien car voici un projet qui transforme GitHub en véritable App Store. Ça s'appelle Github Store , c'est disponible sur Android et desktop (Windows, macOS, Linux), et ça vous propose une interface propre qui présente les logiciels open source comme dans un store classique, avec des catégories, des screenshots, des descriptions, et un bouton pour installer en un clic.

Comme c'est bien pensé, l'application va automatiquement indexer les repos GitHub qui contiennent des binaires installables dans leurs releases. Elle filtre les vrais installeurs (.apk, .exe, .msi, .dmg, .pkg, .deb, .rpm) et ignore les archives de code source que GitHub génère automatiquement, du coup, vous ne voyez que les trucs que vous pouvez réellement installer.

L'interface est organisée avec des sections "Populaire", "Récemment mis à jour" et "Nouveautés" et vous pouvez aussi filtrer par plateforme pour ne voir que les apps compatibles avec votre système. Puis quand vous cliquez sur une app, vous avez tous les détails : nombre d'étoiles, forks, issues, le README complet rendu en markdown, les notes de release, et la liste des fichiers disponibles avec leur taille.

Pour qu'un repo apparaisse dans Github Store, il faut qu'il soit public, qu'il ait au moins une release publiée (pas de brouillon), et que cette release contienne un installeur dans un format supporté. Et y'a pas de soumission manuelle à faire, puisque tout est automatique.

Côté technique, c'est du Kotlin Multiplatform avec Compose pour l'interface. Sur Android, quand vous installez une app, ça délègue au gestionnaire de paquets natif et sur desktop, ça télécharge le fichier et l'ouvre avec l'application par défaut de votre système.

Vous pouvez vous connecter avec votre compte GitHub via OAuth. C'est pas obligatoire, mais ça permet de passer de 60 à 5000 requêtes par heure sur l'API GitHub, ce qui est bien si vous êtes du genre à explorer plein de repos.

L'app est dispo sur les releases GitHub du projet et aussi sur F-Droid pour Android. C'est sous licence Apache 2.0, donc vous pouvez en faire ce que vous voulez.

Attention quand même, les développeurs le précisent bien que Github Store ne fait que vous aider à découvrir et télécharger des releases. La sécurité et le comportement des logiciels que vous installez, c'est la responsabilité de leurs auteurs respectifs et la votre, donc comme d'hab, faites gaffe à ce que vous installez.

Un grand merci à Lorenper pour l'info !

Vous aussi vous avez ce truc où vous devez juste faire un petit SELECT rapide sur votre base de données, et là vous lancez un monstre du genre SQL Server Management Studio ou DBeaver, vous attendez que ça se charge pendant 47 ans, que ça bouffe les 2 Go de RAM qu'il vous reste, et tout ça pour une requête de 3 lignes ?

Moi ça m'énerve profondément, j'avoue... Pas le temps, pas la patience !

Heureusement, y'a un dev qui en a eu encore plus marre que moi et qui a pondu sqlit . C'est une interface TUI (Terminal User Interface, je précise...) qui tourne direct dans votre terminal et qui supporte un paquet de bases de données différentes telles que PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, Oracle, DuckDB, CockroachDB, Supabase, Turso... La liste est longue mais en gros, si ça parle SQL, sqlit sait s'y connecter.

Le truc est inspiré de lazygit , un client Git en TUI que beaucoup de devs adorent, ce qui fait qu'on retrouve cette approche "lazy" où l'interface se suffit à elle-même. Comme ça y'a pas besoin de mémoriser 150 raccourcis clavier, puidqu'il y a une aide contextuelle qui s'affiche et qui vous dit quoi faire, comme votre maman quand vous ne l'avez absolument pas sollicitée.

On a donc de l'autocomplétion SQL qui va chercher les noms de tables et de colonnes, un historique des requêtes par connexion (pratique pour retrouver cette requête chelou qu'on avait bidouillée y'a 3 semaines), et même la gestion des tunnels SSH intégrée pour se connecter à des bases distantes. Les utilisateurs de Vim seront contents aussi, car y'a un mode d'édition modal pour naviguer comme dans votre éditeur préféré.

Pour l'installer, c'est hyper simple :

pip install sqlit-tui

Et après vous tapez sqlit dans votre terminal et c'est parti. Les drivers pour chaque type de base de données s'installent à la demande la première fois que vous essayez de vous connecter. Donc pas de dépendances inutiles qui traînent si vous utilisez juste PostgreSQL par exemple.

Y'a aussi un mode CLI si vous voulez scripter vos requêtes :

sqlit query -c "MaConnexion" -q "SELECT * FROM Users" --format csv

Le seul truc naze je trouve, c'est le nom "sqlit" qui ressemble trop à SQLite. Bon courage pour googler des infos dessus... Je sais de quoi je parle, toutes les 2 semaines, y'a une entreprise Korben qui pop en voulant surfer sur mon buzz (ouais j'ai le melon, mdr) et qui passe toutes ses levées de fonds en adwords pour se positionner avant moi sur Google ^^. C'est couillon ^^.

Bref, si vous vivez dans le terminal et que vous en avez marre de lancer des client lourds juste pour un SELECT, c'est vraiment pratique.

Vous avez déjà passé des heures à éplucher des fichiers de logs de plusieurs millions de lignes pour trouver ce qui cloche ? Genre une pauvre erreur bizarre qui se produit une fois sur 100 000, noyée dans un océan de messages répétitifs et d'infos inutiles ? Moi, oui plein de fois !

Mais ça c'était avant de tomber sur Cordon !

Cordon est un outil en Python qui utilise des modèles de transformers et du scoring k-NN pour détecter les anomalies sémantiques dans vos logs. En gros, au lieu de chercher des mots-clés comme un bourrin avec grep, Cordon comprend le sens des messages et repère ce qui sort de l'ordinaire.

Les patterns répétitifs sont alors considérés comme du bruit de fond normal, même si ce sont des erreurs parce que si vous avez la même erreur FATALE qui se répète 10 000 fois, c'est probablement un problème connu. Et vous, ce que vous voulez trouver, c'est l'événement rare, celui qui se produit une seule fois et qui est sémantiquement différent du reste.

L'installation est simple comme bonjour. Un petit pip install cordon et c'est réglé. Pour l'utilisation de base, vous balancez juste votre fichier de logs en argument :

cordon system.log

Et hop, Cordon va analyser tout ça et vous sortir uniquement les trucs intéressants. Par défaut, il garde les 10% les plus "anormaux" sémantiquement. Vous pouvez ajuster ce pourcentage avec --anomaly-percentile 0.05 pour être plus sélectif (top 5%).

Sous le capot, ça utilise le modèle all-MiniLM-L6-v2 de sentence-transformers pour vectoriser les logs. Le fichier est découpé en fenêtres de N lignes (4 par défaut), chaque fenêtre est transformée en vecteur, puis un score de densité k-NN est calculé. Les fenêtres qui ont des vecteurs très différents du reste sont marquées comme anomalies.

Et si vous avez un GPU, Cordon peut l'utiliser automatiquement avec l'option --device cuda. D'après les benchmarks, ça donne un speedup de 5 à 15x sur le scoring pour les gros datasets. Sur des logs HDFS de 1 à 5 millions de lignes, l'outil arrive à réduire le volume de 98%. Autant dire que ça filtre sévère.

Y'a aussi un mode "range" qui est pratique pour explorer par tranches. Genre si vous voulez exclure le top 5% (trop bizarre, probablement du garbage) mais garder le top 5-15%, vous faites :

cordon --anomaly-range 0.05 0.15 app.log

Ça permet d'affiner l'investigation de manière itérative.

Pour les environnements conteneurisés, Cordon propose également une image Docker avec un backend llama.cpp au lieu de sentence-transformers. Pratique si vous voulez utiliser des modèles GGUF ou si vous êtes dans un contexte où les dépendances PyTorch posent problème.

L'outil peut aussi s'utiliser comme bibliothèque Python si vous voulez l'intégrer dans vos propres scripts :

analyzer = SemanticLogAnalyzer()
output = analyzer.analyze_file(Path("system.log"))

Vous avez déjà essayé de faire du traitement vidéo dans le navigateur

Bienvenue en enfer ! Et dire que pendant 20 ans, la seule solution viable c’était de compiler FFmpeg en WebAssembly, attendre 10 secondes que 40 Mo de code se chargent, puis regarder votre RAM fondre comme neige au soleil.

Heureusement, MediaBunny débarque et compte bien changer les choses !

En effet, cette bibliothèque TypeScript vous permet de lire, écrire et convertir des fichiers vidéo et audio directement dans le navigateur. MP4, WebM, MKV, MP3, WAV, Ogg, FLAC, vous nommez simplement le format, et MediaBunny le gère. Et la bibliothèque ne pèse que 5 Ko en version minifiée. Ça semble peu mais en fait, au lieu d’essayer de porter un outil desktop vers le web, Vanilagy (le créateur) a construit MediaBunny from scratch pour exploiter ce que le navigateur savait déjà faire.

La clé, c’est donc l’API WebCodecs qui existe depuis Chrome 94 sorti en 2021, mais que presque personne n’utilise. Cette API donne accès direct à Javascript à l’accélération matérielle de votre GPU pour encoder et décoder la vidéo que ce soit du H.264, H.265, VP8, VP9 et tout ça en temps réel. Et MediaBunny se branche dessus et vous donne une interface propre pour manipuler vos médias.

Vous voulez extraire les métadonnées d’une vidéo MP4, convertir un WebM en MP4 ou encore extraire une piste audio d’une vidéo ? En 3 lignes de code c’est plié, et tout ça en local dans votre navigateur.

MediaBunny supporte plus de 25 codecs vidéo, audio et sous-titres. H.264, H.265, VP8, VP9, AV1 pour la vidéo. AAC, Opus, Vorbis, MP3, FLAC pour l’audio. WebVTT pour les sous-titres…etc.

Et l’outil étant pensé avec un design modulaire qui permet de faire du tree-shaking , vous pouvez embarquer uniquement le code dont vous avez besoin, ce qui allège encore plus le bouzin. MediaBunny est d’aillerus l’évolution technique de deux projets du même auteur : mp4-muxer et webm-muxer. Ces bibliothèques faisaient déjà du bon boulot pour écrire des vidéos MP4 et WebM côté client, mais MediaBunny va beaucoup plus loin en supportant la lecture, l’écriture et la conversion pour tous les formats courants.

Si ça vous chauffe, pour installer MediaBunny, c’est du classique :

npm install mediabunny

const input = new Input({
 source: new UrlSource('./bigbuckbunny.mp4'),
 formats: ALL_FORMATS, // .mp4, .webm, .wav, ...
});

const duration = await input.computeDuration();

const videoTrack = await input.getPrimaryVideoTrack();
const { displayWidth, displayHeight, rotation } = videoTrack;

const audioTrack = await input.getPrimaryAudioTrack();
const { sampleRate, numberOfChannels } = audioTrack;

// Get the frame halfway through the video
const sink = new VideoSampleSink(videoTrack);
const frame = await sink.getSample(duration / 2);

// Loop over all frames of the video
for await (const frame of sink.samples()) {
 // ...
}

Pendant que Burp Suite avale 500 Mo de RAM au démarrage, HTTP Breakout Proxy lui, tient dans un binaire de quelques Mo qui disparaît dès que vous fermez le terminal.

Alors HTTP Breakout Proxy c’est quoi ?

Hé bien les amis, c’est un proxy HTTP/HTTPS écrit en Go qui intercepte le trafic réseau en temps réel et vous propose une interface web pour analyser tout ce qui passe. Requêtes, réponses, headers, body, timing… Tout est capturé et affiché proprement dans votre navigateur.

Vous le lancez avec ./http-breakout-proxy, il écoute sur 127.0.0.1:8080, et vous ouvrez l’interface dans votre browser. Ensuite, si vous voulez débugger une API par exemple, vous lancez le proxy, vous configurez votre client HTTP pour passer par localhost:8080, et vous voyez tout passer en direct.

C’est vrai que Burp est devenu un monstre à tout faire avec scanner de vulnérabilités, fuzzer, crawler, extensions… Y’a aussi Charles Proxy que j’aime bien mais qui pèse dans les 100 Mo et nécessite une JVM complète. Et même mitmproxy , pourtant réputé léger, a accumulé tellement de fonctionnalités qu’il faut lire 50 pages de doc pour comprendre comment l’utiliser.

Avec HTTP Breakout Proxy, il y a moins de features c’est vrai mais ça va plus vite et c’est gratuit. Maintenant, au niveau technique, le projet utilise l’interception MITM classique. Vous installez le certificat racine fourni par le proxy, et il peut déchiffrer le trafic HTTPS qui passe par lui. Ensuite, l’interface web affiche tout en temps réel via Server-Sent Events. Vous avez du filtrage par regex, du color-coding configurable pour repérer visuellement les requêtes importantes, et même des charts Gantt pour visualiser le timing des connexions…etc.

Que demande le peuple ? Ah oui, y’a aussi l’export vers curl ou Python requests, ce qui est pratique quand vous voulez rejouer une requête dans un script. Et bien sûr la possibilité de mettre la capture en pause pour analyser tranquillement ce qui s’est passé.

Voilà, c’est minimaliste mais ça marche hyper bien et quand on est pas un pro de la sécurité, c’est bien d’avoir des outils de ce style pour explorer un truc vite fait. Et merci à Lorenper pour le partage !

A découvrir ici !

Discord a trouvé une solution radicale pour gérer son app de ses morts qui bouffe 4 Go de RAM sous Windows 11 (consommation ressentie : 4 millions de Go) : La redémarrer automatiquement quand elle dépasse ce seuil.

Les champions quoi ! Plutôt que de corriger les fuites mémoires, ils ont tout simplement décidé d’intégrer un auto-relaunch dans l’app en douce pour qu’elle se relance toutes les quelques heures.

Donc, si votre Discord a tourné pendant au moins 1 heure, que vous êtes inactif depuis 30 minutes (pas de souris/clavier), et que vous n’êtes pas en vocal ou en visio, l’app se redémarrera automatiquement dès qu’elle atteindra les 4 Go de conso mémoire.

Bien sûr Discord présente ça comme une solution temporaire pendant qu’ils bossent sur le vrai problème, mais je trouve ça marrant de normaliser ce bug en ajoutant une fonctionnalité qui le “contourne” bruyamment.

Le pire dans tout ça, c’est que le problème vient d’une connerie technique assez basique. L’app Discord utilise une bibliothèque appelée “systeminformation” qui appelle PowerShell avec des commandes comme Get-WmiObject Win32_logicaldisk juste pour récupérer des infos système basiques. Mais comme ils passent par Powershell plutôt que d’utiliser les API natives de Windows, ça bouffe de la RAM comme un gros porc.

Comme vous, je me demande pourquoi Discord ne refait pas son app avec un framework plus léger ? Hé bien c’est simple : ils sont coincés ! Parce Discord est bâti sur Electron, et Electron c’est un framework qui embarque un Chromium complet salade tomates oignons dans chaque application. Ça permet aux devs web de créer des apps desktop avec du JavaScript, du HTML et du CSS , mais le prix à payer c’est une app qui pèse 85 Mo à l’installation et bouffe 200-400 Mo de RAM au démarrage.

En théorie Electron permet de créer une app cross-platform facilement. C’est-à-dire d’avoir un seul code pour Windows, Mac et Linux. Mais dans les faits, Discord maintient quand même du code spécifique par plateforme pour les notifications, l’overlay gaming, les raccourcis système, etc. Bref, ils ont tous les inconvénients d’Electron (RAM, taille) sans vraiment profiter de l’avantage du “write once, run everywhere”.

C’est vrai que réécrire Discord en natif coûterait des millions. Faudrait refaire toute l’interface, toutes les fonctionnalités, tous les systèmes de plugins et de thèmes. Surtout que pendant ce temps, l’équipe actuelle continue d’ajouter des fonctionnalités sur leur usine à gaz, ce qui creuse encore plus la dette technique. C’est le sunk cost fallacy version logicielle… en gros, ils ont tellement investi dans Electron qu’ils ne peuvent plus reculer, même si repartir de zéro serait probablement moins coûteux sur le long terme.

Pourtant, des alternatives à Electron existent. Tauri est devenu le framework préféré des devs qui veulent de la performance … On est à 2-3 Mo d’installeur, 30-40 Mo de RAM au repos et il utilise Rust et le webview natif du système plutôt que d’embarquer Chromium. Les apps sont donc légères, rapides, et consomment 10 fois moins de ressources.

Y’a aussi Flutter, React Native Desktop, Qt… des frameworks qui produisent des apps vraiment natives avec des performances dignes de ce nom. Visual Studio Code démontre qu’Electron peut être performant si on l’optimise correctement, mais ça demande un boulot monstre et malheureusement, Discord n’a clairement pas envie de mettre les moyens.

Le vrai problème n’est donc pas technique, c’est économique, car pour 1 dev natif, y’a 8 devs web . Electron permet d’embaucher des devs JavaScript pas cher plutôt que des devs C++/Rust/Swift qui coûtent une blinde… donc, sacrifier la RAM des utilisateurs coûte moins cher que payer des ingénieurs système. Et comme les PC ont maintenant 16-32 Go de RAM, ils se disent que 4 Go pour du chat en ligne, c’est acceptable. Lol.

Bref, tout ça pour dire que Discord normalise le “patch-as-a-feature”, et j’imagine que demain Slack, Teams et tous les autres vont faire pareil. En attendant, jetez un œil à Ripcord et Stoat pour ceux qui veulent un truc mieux.

Source