Et si l'OS lui-même ÉTAIT le jeu ?

C'est exactement le concept derrière Aurora OS.js , un projet open source complètement barré qui simule un système d'exploitation complet dans votre navigateur... avec des mécaniques de jeu de hacking intégrées.

Le truc, c'est que ce n'est pas juste une démo technique. Aurora OS.js embarque un vrai système de fichiers virtuel avec stockage persistant, un terminal avec des commandes type Linux (ls, cd, cat, mkdir...), un gestionnaire de fenêtres, un bloc-notes avec coloration syntaxique, et toute une architecture modulaire pour les applications. Bref, ça ressemble à un vrai OS, ça se comporte comme un vrai OS, mais ça tourne dans un onglet de votre navigateur.

Côté technique, les développeurs n'ont pas fait dans la demi-mesure. C'est à base de React 19, Electron 39, TypeScript 5, Tailwind CSS v4, et des animations fluides grâce à Framer Motion. Et le tout nécessite Node.js 24 minimum, ce qui montre qu'on est clairement sur des technos de pointe.

Le projet suit une roadmap en trois étapes. La version actuelle (v0.7.7) se concentre sur les fondations et l'utilisabilité. La v1.x apportera le gameplay solo de hacking. Et la v2.x ? Du multijoueur persistant où vous pourrez hacker d'autres joueurs. Ça va être trop incrrrr !

Si vous aimez les expériences dans le navigateur ou les projets qui repoussent les limites du web , Aurora OS.js mérite clairement un coup d'œil. Y'a une démo live sur GitHub Pages pour tester directement (user: guest / mdp: guest). Et comme c'est sous licence AGPL-3.0, vous pouvez fouiller le code et même contribuer si le cœur vous en dit.

Source

Si vous utilisez Docker Desktop sur Mac et que vous en avez marre de voir votre ventilateur s'emballer dès que vous lancez trois conteneurs, j'ai peut-être la solution à vos problèmes.

OrbStack , c'est une app native Swift qui remplace Docker Desktop et qui fait tourner vos conteneurs sans transformer votre MacBook en mineur de Bitcoin. Le truc démarre en 2 secondes 12 et consomme très peu de ressources en arrière-plan. Autant dire que par rapport à l'usine à gaz qu'est devenu Docker Desktop, ça fait du bien.

Concrètement, vous avez accès à tout ce que vous connaissez : la CLI Docker est compatible, vos docker-compose tournent généralement sans modification, et même Kubernetes est intégré nativement. Pas besoin donc de tout réapprendre. Vous installez, et vous pouvez migrer vos conteneurs existants depuis Docker Desktop.

Un conseil quand même : faites une sauvegarde de vos volumes avant, parce que la migration peut parfois cafouiller.

Mais OrbStack ne se limite pas aux conteneurs puisque le logiciel embarque aussi un gestionnaire de machines virtuelles Linux. Plusieurs distributions sont disponibles, d'Ubuntu à Fedora en passant par Arch, et elles se configurent en une minute chrono. Pratique quand vous avez besoin d'un shell Linux fonctionnel sous macOS sans vous farcir la lourdeur de VirtualBox.

Côté technique, OrbStack utilise VirtioFS pour le partage de fichiers entre l'hôte et les conteneurs, ce qui explique en partie les performances. Sur Apple Silicon, l'émulation x86 passe par Rosetta, donc la plupart de vos images Intel devraient tourner. Le réseau est également soigné avec support IPv6 et ICMP. Par contre, certains utilisateurs ont signalé des soucis avec des VPN d'entreprise, donc testez avant de tout basculer.

Dans l'interface, vous avez vos conteneurs, vos machines Linux, vos volumes, le tout accessible depuis la barre de menu ou via la CLI. Y'a même l'intégration VS Code pour ceux qui bossent sur des projets dans les VM Linux.

Pour le prix, c'est gratuit pour un usage personnel et si vous l'utilisez dans un contexte professionnel, comptez 8 dollars par mois ou 96 dollars à l'année.

Le seul inconvénient, c'est que ça ne tourne que sur macOS donc tant pis pour vous si vous êtes sur Linux ou Windows. En tout cas, pour les développeurs Mac qui en ont ras-le-bol de voir Docker Desktop bouffer leurs ressources et leur batterie, c'est franchement une alternative qui mérite le détour. Un peu comme VirtualBuddy a révolutionné la virtualisation macOS, OrbStack fait pareil mais pour les conteneurs.

Quand je suis tombé sur Wario.style , j'ai d'abord cru à une blague. Sauf que non.

Ce petit site web vous transforme vos morceaux préférés en version Game Boy, à condition qu'un fichier MIDI existe pour la chanson en question. Vous cherchez une chanson, vous sélectionnez la source MIDI qui vous plaît, vous cliquez sur "Generate"... et là, c'est la magie des bips et des blops qui opère.

Ce qui se cache derrière porte le doux nom de Wario Synthesis Engine. Concrètement, ça analyse le fichier MIDI pour identifier les pistes de mélodie, de basse et d'accords, puis ça resynthétise le tout avec des oscillateurs Web Audio calibrés pour imiter la puce sonore 4 canaux de la Game Boy. Deux canaux pulse wave pour la mélodie, un canal wave pour les graves, et un canal noise pour les percussions. C'est à dire le même setup que la vraie console de 1989, les amis !

Et le plus beau dans tout ça, c'est que la synthèse audio se fait entièrement côté client. La recherche de fichiers MIDI passe par un serveur, mais la génération du son, elle, tourne direct dans votre navigateur. Du coup, niveau réactivité, on est bien.

Le site est signé @b1rdmania, un dev qui a construit ce projet "for lols" avec Claude Code (hé oui, c'est mentionné fièrement sur la page). D'ailleurs si vous voulez fouiller le code source , tout est public sur GitHub. C'est du TypeScript propre avec Vite derrière pour le build.

Les dev ont un peu peur des avocats de Nintendo... lol ( Source )

Côté fonctionnalités, la version 1.3 apporte le partage direct sur X, une palette Game Boy claire pour les nostalgiques du vert olive, et des correctifs pour l'audio sur iPhone. Parce que oui, Apple bloque le son tant que vous n'avez pas tapé sur un truc, mais une fois le bouton "Enable Audio" cliqué, c'est parti mon kiki.

Le projet a d'ailleurs une page d'embed si vous voulez intégrer vos créations chiptune sur vos sites web. Perso, je trouve ça super cool pour donner une ambiance rétro à n'importe quel projet.

Voilà, si vous avez grandi avec les bips caractéristiques de la Game Boy et que vous avez toujours rêvé de transformer vos morceaux préférés en 8-bit, foncez tester Wario.style . C'est gratuit, c'est fun, et n'oubliez pas, si vous cherchez d'autres outils pour composer du chiptune plus sérieusement, j'ai parlé de Furnace et DefleMask il y a pas longtemps.

RyuU12358 n'est pas un personnage de manga cyberpunk... Non, c'est un développeur japonais qui a eu une idée toute bête. Il s'est demandé si on pouvait VOIR la structure des formules Excel au lieu de les lire comme on lirait un roman écrit en russe ?

Parce que bon, les formules de tableur imbriquées, c'est le cauchemar de pas mal de monde. Vous savez, ce genre de truc : =IF(AND(SUMIF(A:A,B2,C:C)>100,VLOOKUP(D2,E:F,2,FALSE)="OK"),CONCATENATE(G2," - ",H2),"Erreur").

Et encore, j'ai pris un exemple gentil.

Demo Frockly : une formule Excel décomposée en blocs ( Source )

Le problème, comme le souligne très justement le créateur, c'est pas que ces formules sont complexes. C'est que leur structure est planquée à l'intérieur d'une seule ligne de texte, du coup, à chaque fois qu'on doit les modifier, on repart de zéro pour comprendre comment tout s'imbrique.

Rien que d'y penser, ça me donner la flemme...

Mais c'est là qu'intervient Frockly , un éditeur web qui transforme vos formules en blocs visuels façon Scratch qu'on peut manipuler comme des Lego. Vous collez votre formule monstrueuse, et hop, elle se décompose en morceaux logiques reliés entre eux. Ça ressemble un peu à Flyde pour la programmation visuelle , mais adapté au monde des tableurs.

L'outil propose plusieurs modes de visualisation comme replier certaines parties pour avoir une vue d'ensemble, zoomer sur un noeud précis, ou remonter à la racine pour comprendre la hiérarchie.

Et le truc cool, c'est qu'on peut aussi construire ses formules de A à Z en assemblant des blocs. Plus besoin de compter les parenthèses comme un comptable sous pression. On connecte les fonctions entre elles, et Frockly génère la formule textuelle qu'on peut ensuite copier-coller dans Excel ou un autre tableur.

Y'a même un système de formules nommées (internes à Frockly) pour réutiliser des morceaux de logique, et un import expérimental de fichiers xlsx qui fonctionne côté client. Bon, on est sur une version 0.5, donc faut pas s'attendre à un truc parfaitement stable non plus...

Notez quand même que Frockly ne remplace pas Excel. C'est un outil qui tourne entièrement dans votre navigateur (pas d'upload serveur), ne calcule rien, ne modifie pas vos fichiers, et ne prétend surtout pas être un tableur. C'est en réalité un espace de travail intermédiaire pour comprendre et refactorer, point barre. L'idée c'est d'organiser vos formules ici, puis de retourner dans votre tableur avec une version plus claire.

Le tout est développé en TypeScript, tourne dans le navigateur, et le code est disponible sur GitHub. Bref, si vous avez déjà pesté devant une formule Excel incompréhensible héritée d'un collègue qui a quitté la boite il y a 3 ans, ce petit outil pourrait bien vous sauver quelques heures de migraine.

Source

Soyez honnêtes, c'est quoi votre dernier message de commit ? "fix", "update", "refactor" ou les grands classiques "Ça marche, on ne touche plus" ou "azertyuiop^$" ?

Si vous vous reconnaissez, alors Lumen va peut-être vous sauver la mise.

Lumen c'est un outil en ligne de commande écrit en Rust qui utilise l'IA pour vous aider à gérer votre workflow Git. En gros, vous stagez vos fichiers, vous lancez lumen draft et hop, l'IA analyse vos modifications pour générer un message de commit propre au format conventionnel. Fini les "fixed stuff" à 3h du mat.

Mais le truc va plus loin que ça puisque vous pouvez aussi lui demander d'expliquer un commit avec lumen explain HEAD (ou un hash, une plage de commits...). Pratique quand vous tombez sur du code écrit par vous-même il y a 6 mois et que vous n'y comprenez plus rien. D'ailleurs, y'a même une fonctionnalité de recherche interactive dans l'historique avec lumen list si vous avez fzf d'installé.

Et le plus cool, c'est la commande lumen operate. Vous lui décrivez en langage naturel ce que vous voulez faire genre "squash mes 3 derniers commits" et il vous génère la commande Git correspondante. Avec un warning si la commande est potentiellement destructrice et une demande de confirmation avant exécution, histoire de pas faire de bêtises.

Côté providers, c'est flexible... OpenAI, Anthropic Claude, Gemini, Groq, DeepSeek, Ollama pour du local, et d'autres encore... Vous configurez ça une fois avec lumen configure pour les commandes IA et c'est parti. Le diff viewer intégré est pas mal non plus (et lui fonctionne sans config), avec une vue côte à côte dans le terminal et la possibilité de naviguer entre les hunks.

L'installation se fait via Homebrew sur Mac/Linux avec brew install jnsahaj/lumen/lumen ou via Cargo si vous avez Rust. C'est open source sous licence MIT.

Perso, je trouve que c'est le genre d'outil bien pratique pour ceux qui galèrent avec leurs messages de commit ou qui passent leur temps à chercher des commandes Git obscures. Et le fait que ça tourne avec différents providers IA, y compris en local avec Ollama, c'est également un vrai plus pour ceux qui veulent pas envoyer leur code sur des serveurs externes.

A tester donc !

Source

Bon, faut qu'on parle un peu du moteur de recherche de mon site. Ceux qui l'ont déjà utilisé savent de quoi je parle : c'était pas terrible. Enfin, « pas terrible » j'suis gentil. C'est un espèce d'overlay avec des résultats certes fiables mais c'était vraiment pas pratique.

Et en plus de ça, comme j'ai un site statique généré avec Hugo, je passais par Algolia pour la recherche. Si vous ne connaissez pas, Algolia c'est un service cloud qui indexe votre contenu et vous fournit une API de recherche ultra-rapide. Sur le papier c'est génial et dans la pratique aussi d'ailleurs sauf que voilà, ça coûte des sous. Et mon site rencontre un franc succès ces derniers temps (merci à vous !), donc j'ai de plus en plus de visiteurs, donc de plus en plus de recherches, donc une facture Algolia qui grimpe gentiment chaque mois.

Du coup je me suis dit : « Et si je trouvais une solution de recherche pour sites statiques ? » Parce que oui, ça existe et c'est comme ça que j'ai découvert Pagefind.

Pagefind c'est donc un moteur de recherche statique open source développé par CloudCannon qui fonctionne comme ceci : Au moment du build de votre site, Pagefind parcourt tout votre HTML généré et crée un index de recherche qu'on peut interroger avec un peu de JS. Y'a donc plus d'API, et tout se fait localement sur le navigateur des internautes.

Bref, ça avait l'air très cool alors évidemment, je me suis lancé dans l'aventure et comme j'aime bien me compliquer la vie, j'ai décidé de pas juste intégrer Pagefind tel quel. Non non. J'ai voulu recréer l'interface du Google de 1998 parce que à quoi bon avoir son propre site web si on peut pas s'amuser un peu ^^.

Laissez-moi donc vous raconter cette aventure.

Le problème avec Algolia

Leur service est excellent, je dis pas le contraire, la recherche est rapide, les résultats sont pertinents, l'API est bien foutue mais voilà, y'a le modèle de pricing puisque Algolia facture au nombre de requêtes de recherche.

Plus les gens cherchent sur votre site, plus vous payez et quand vous avez un site qui fait plusieurs millions de pages vues par mois, bah... ça chiffre vite. En gros je dépasse très vite les 10 000 recherches offertes chaque semaine et ensuite ça chiffre. C'est pas la mort, mais c'est un coût récurrent débile pour un truc qui pourrait être gratuit.

En plus de ça, y'a la dépendance à un service externe. Si Algolia tombe, ma recherche tombe. Et si Algolia change ses prix, je vais devoir subir. Même chose si Algolia décide de modifier son API... il faudra que j'adapte mon code. Bref, c'est le cloud dans toute sa splendeur... C'est pratique mais on n'est jamais vraiment chez nous.

Pagefind à la rescousse

Pagefind résout donc tous ces problèmes d'un coup. C'est un outil en ligne de commande qui s'exécute après votre générateur de site statique (Hugo dans mon cas, mais ça marche avec Jekyll, Eleventy, Astro, ou n'importe quoi d'autre).

Concrètement, vous lancez :

npx pagefind --site public

Et Pagefind va :

• 1. Scanner tous vos fichiers HTML dans le dossier public/
• 2. Extraire le contenu textuel (en ignorant la nav, le footer, les pubs si vous lui dites)
• 3. Créer un index de recherche optimisé
• 4. Générer des fichiers JavaScript pour interroger cet index côté client

Et le résultat c'est un dossier pagefind/ qui contient tout ce qu'il faut. Ensuite; à vous de servir ces fichiers statiquement avec le reste de votre site, et la magie pourra opérer !

L'index pour mes 18 000 articles fait environ 1,5 Go. Ça peut paraître beaucoup, mais Pagefind est malin car il découpe l'index en fragments et ne charge que ce qui est nécessaire pour la recherche en cours. Du coup en pratique, une recherche typique télécharge quelques centaines de Ko, et pas plus.

L'intégration technique

Pour intégrer Pagefind dans mon workflow Hugo, j'ai donc été cherché le binaire, je l'ai mis sur mon serveur et je l'ai appelé dans un cron comme ça, je rafraichi l'index de recherche 1 fois par jour (et pas à chaque génération du site).

0 4 * * * /home/manu/pagefind/pagefind --site /home/manu/public_html --output-path /home/manu/public_html/pagefind >> /var/log/pagefind.log 2>&1

J'ai aussi créé un fichier de configuration pagefind.yml pour affiner le comportement :

root_selector: "[data-pagefind-body]"
exclude_selectors:
 - "header"
 - ".site-header"
 - "footer"
 - ".sidebar"

L'astuce ici c'est d'indexer uniquement les div ayant la class data-pagefind-body='true' et d'exclure les éléments qui ne font pas partie du contenu éditorial afin de ne pas indexer ce qui se trouve dans le header, les natives, le footer...etc.

Côté JavaScript, Pagefind utilise les imports ES6 dynamiques. Ça veut dire que le moteur de recherche n'est chargé que quand l'utilisateur lance effectivement une recherche :

async function initPagefind() {
pagefind = await import('/pagefind/pagefind.js');
await pagefind.init();
}

Et pour faire une recherche :

const search = await pagefind.search("linux");
// search.results contient les IDs des résultats
// On charge le contenu de chaque résultat à la demande
for (const result of search.results) {
 const data = await result.data();
 console.log(data.url, data.meta.title, data.excerpt);
}

C'est bien fichu parce que search.results retourne immédiatement les références des résultats, mais le contenu réel (titre, extrait, URL) n'est chargé que quand vous appelez result.data(). Du coup vous pouvez implémenter une pagination propre sans télécharger les données de milliers de résultats d'un coup.

Le délire rétro - Recréer Google 1998

Maintenant que j'avais un moteur de recherche fonctionnel, fallait l'habiller. Et c'est là que j'ai eu cette idée un peu débile : Pourquoi pas recréer l'interface du Google de 1998 ?

Pour les plus jeunes qui lisent ça, Google en 1998 c'était une page blanche avec un logo, un champ de recherche, et deux boutons : « Google Search » et « I'm Feeling Lucky« . Pas de suggestions, pas de carrousels, pas de pubs... Juste un champs de recherche. C'était la belle époque !

J'ai donc créé une page de recherche avec deux vues distinctes. La page d'accueil avec le logo centré et le champ de recherche au milieu, exactement comme le Google originel.

Et la page de résultats avec le logo en petit en haut à gauche et les résultats en dessous.

Pour le code CSS, j'ai voulu être fidèle à l'époque. Times New Roman comme police par défaut, les liens en bleu souligné qui deviennent violet une fois visités. Et surtout, les boutons avec l'effet 3D des interfaces Windows 95 :

.search-button:active { border-style: inset; }

Ce border: outset et border-style: inset au clic, c'est exactement ce qui donnait cet effet de bouton en relief qu'on avait partout dans les années 90. Pour moi, ça fait toute la différence pour l'authenticité. Même le logo, je l'ai volontairement « dégradé » pour qu'il soit de la même qualité que le logo Google d'origine.

La pagination « Koooooorben »

Vous vous souvenez de la pagination de Google avec « Goooooogle » en bas de page ? Le nombre de « o » correspondait au nombre de pages de résultats. J'ai fait pareil, mais avec « Koooooorben ».

let logo = 'K'; for (let i = 0; i < oCount; i++)
{
logo += o;
} logo += 'rben'; }

Plus il y a de résultats, plus il y a de « o ». C'est complètement inutile mais ça me fait marrer à chaque fois que je le vois.

Le bouton « J'ai de la chance »

Ah, le fameux « I'm Feeling Lucky » de Google, j'ai voulu l'implémenter comme à l'époque ! Si vous tapez une recherche et cliquez sur « J'ai de la chance », vous êtes envoyé sur le premier résultat. Classique. Mais si vous cliquez sur le bouton avec le champ vide sur la home de la recherche, vous êtes envoyé sur un article aléatoire parmi les +18 000 du site.

Pour ça, j'ai utilisé une astuce : le sitemap. Mon Hugo génère un fichier sitemap.xml qui contient toutes les URLs du site et je peux aller piocher dedans en JS :

const articles = [...xml.querySelectorAll('loc')] .map(loc => loc.textContent) .filter(url => {
// Exclure les pages qui ne sont pas des articles
const path = new URL(url).pathname;
return !path.startsWith('/categories/') && !path.startsWith('/page/') && path !== '/';
});
const randomUrl = articles[Math.floor(Math.random() * articles.length)];
window.location.href = randomUrl;
} }

Un seul fetch, un peu de parsing XML natif, et hop c'est le grand retour de la fonctionnalité « article aléatoire » qui vous manquait, je le sais !

Tri et nombre de résultats

Je vous ai aussi mis une listbox qui vous permet d'afficher 10, 25 ou 50 résultats ainsi qu'un tri par pertinence ou data. Et ça aussi Pagefind sait parfaitement le navigateur.

Mode sombre et accessibilité

Même si l'interface est rétro, j'ai quand même ajouté quelques fonctionnalités modernes. Le mode sombre respecte les préférences système, et j'ai intégré la police OpenDyslexic pour les personnes dyslexiques.

Le truc important c'est de charger ces préférences avant le rendu de la page pour éviter le fameux flash. J'ai donc un petit script qui lit les préférences dans le localStorage et applique les classes CSS immédiatement :

function() {
 if (localStorage.getItem('theme') === 'dark') {
 document.documentElement.classList.add('dark-mode');
 }
 if (localStorage.getItem('dyslexic-font') === 'true') {
 document.documentElement.classList.add('dyslexic-mode');
 }
});

Gestion de l'historique navigateur

Un détail qui peut sembler anodin mais qui est super important pour l'expérience utilisateur c'est la gestion du bouton retour du navigateur.

Quand vous faites une recherche, l'URL change selon votre requête du genre /recherche/?q=linux&p=2. Du coup si vous partagez cette URL à un collègue, la personne arrivera directement sur les résultats de recherche. Et si vous utilisez le bouton retour, vous reviendrez alors à la recherche précédente.

window.addEventListener('popstate', () => {
const query = new URLSearchParams(location.search).get('q');
if (query) doSearch(query);
else showHomePage();
});

Liens vers d'autres moteurs

Et si vous ne trouvez pas votre bonheur dans mes +18 000 articles (ce qui serait quand même étonnant ^^), j'ai ajouté des liens pour relancer la même recherche sur Google, DuckDuckGo, Qwant, Brave et Ecosia. Bref, un petit service bonus pour mes visiteurs, exactement comme le proposait Google à l'époque.

Le bilan - Algolia vs Pagefind

Après 1 semaine d'utilisation, voici donc mon verdict ! Côté portefeuille d'abord, Algolia me coûtait entre 60 et +100 euros par mois et maintenant pour Pagefind, c'est zéro euros ! Et les performances sont également au rendez-vous. Algolia c'était rapide et bien là, ça l'est encore plus. Seul compromis à noter, l'index Algolia se mettait à jour en temps réel, alors que Pagefind nécessite une reconstruction au moment du build.

La conclusion

Voilà, j'ai maintenant une recherche qui marche vraiment bien, qui me coûte 0€ par mois, et qui a un look rétro qui va en surprendre plus d'un...

Alors est-ce que c'était nécessaire de passer autant de temps sur le design rétro ? Hé bien absolument pas. Mais est-ce que ça valait le coup ?

Franchement, oui !! C'est mon site, je fais ce que je veux, et si ça peut faire sourire quelques visiteurs nostalgiques des débuts du web, c'est du bonus. D'ailleurs un grand merci aux Patreons qui me soutiennent car sans eux, je n'aurais pas pu passer mon dimanche là dessus ^^

Et puis surtout, ça m'a permis de découvrir Pagefind qui est vraiment un excellent outil. Donc si vous avez un site statique (ou n'importe quel type de contenu textuel) et que vous cherchez une solution de recherche gratuite et performante, je vous le recommande chaudement. La documentation est claire, l'intégration est simple, et le résultat est top !

Allez, maintenant vous pouvez aller tester la nouvelle recherche sur le site . Et si vous cliquez sur « J'ai de la chance » sans rien taper... bonne découverte !

J'sais pas si vous vous rappelez mais quand on jouait à nos jeux préférés sur un de ces vieux écrans CRT, l'image était nette ! Une clarté de mouvement quasi parfaite, avec très peu de traînées... C'était chouette ! Hé bien y'a un dev qui a décidé de recréer ça sur nos écrans modernes avec un outil open source qui s'appelle ShaderBeam .

En fait, le souci de nos LCD et autres OLED, c'est que chaque pixel reste allumé pendant toute la durée d'une frame (c'est ce qu'on appelle le sample-and-hold ). Alors que sur un CRT, le faisceau d'électrons balayait l'écran ligne par ligne, donc chaque pixel ne s'allumait qu'une fraction de seconde. C'est ça qui donnait cette sensation de netteté en mouvement. C'est précisément ce comportement que ShaderBeam tente de reproduire via un shader GPU.

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 !