Vue lecture

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

Obs.js transforme votre site en un caméléon qui s'adapte à chaque visiteur

Alors rien à voir avec le logiciel de streaming, mais sachez que Harry Roberts, le consultant en performance web derrière CSS Wizardry (et accessoirement un mec qui a bossé avec Google, la BBC et l’ONU), vient de sortir Obs.js .

L’idée de ce truc, c’est de transformer votre site web en véritable caméléon. Au lieu de servir la même expérience à tout le monde, la bibliothèque va détecter en temps réel les conditions de navigation de chaque visiteur. Batterie presque vide ? Connexion 2G pourrie ? Le site s’adapte automatiquement.

Pour cela, Roberts utilise des APIs natives du navigateur qui existent depuis des années mais que presque personne n’exploite vraiment. La Battery Status API et la Network Information API sont là, dans Chrome et consorts, à attendre qu’on leur trouve une utilité. Et voilà, Obs.js débarque et les combine de façon intelligente pour créer quelque chose de vraiment utile.

Mais alors concrètement, ça donne quoi ?

Et bien ce script ajoute des classes CSS directement sur votre balise <html>, comme ça…

<html class="has-latency-low
 has-bandwidth-high
 has-battery-charging
 has-connection-capability-strong
 has-conservation-preference-neutral
 has-delivery-mode-rich">

Et quand vous avez un visiteur avec 5% de batterie, hop, une classe .has-battery-critical apparaît.

.has-battery-critical * {
 animation: none !important;
 transition: none !important;
}

Vous pouvez alors désactiver toutes les animations et transitions avec une simple règle CSS. Plus besoin de JavaScript complexe ou de détection côté serveur. C’est propre !

Mais ça va bien plus loin que la batterie puisqu’Obs.js catégorise aussi la qualité de la connexion de vos visiteurs. Une connexion forte, modérée ou faible, et votre site peut s’adapter en conséquence. Vous pouvez ainsi servir des images haute résolution aux utilisateurs sur fibre, et des versions compressées à ceux qui galèrent en 3G Free ^^ dans le métro.

body {
 background-image: url('banner-4k.jpg');
}

.has-delivery-mode-lite body {
 background-image: url('banner-optimized.jpg');
}

Je trouve cette approche très progressive car si le navigateur ne supporte pas ces APIs ( Safari ne supporte ni Battery ni Network Information API ), le site peut continuer à fonctionner normalement. Roberts recommande d’ailleurs de placer le script directement en inline dans le <head> de votre page, avant tout autre script. Il précise cela pour que la détection se fasse le plus tôt possible et que les classes soient disponibles dès le premier render.

De plus, l’objet window.obs exposé par la bibliothèque vous donne accès à toutes les métriques collectées. Vous pouvez ainsi savoir si le Data Saver est activé, si l’appareil est branché sur secteur, ou même détecter les changements de réseau en temps réel. Imaginez les possibilités pour une progressive web app qui doit gérer des modes offline !

En plus, ce type d’optimisation adaptative peut réduire significativement la consommation de données et améliorer les temps de chargement. Il est possible en implémentant cela et en faisant les aménagements nécessaire, d’économiser jusqu’à 40% de bande passante pour les utilisateurs ayant des connexions lentes. C’est énorme quand on sait que chaque seconde de chargement supplémentaire peut faire perdre 20% de conversions.

La version actuelle est déjà fonctionnelle et disponible sous licence MIT et le support navigateur est principalement orienté Chromium pour l’instant, mais c’est déjà une base solide pour commencer à expérimenter.

Et connaissant le profil de Roberts (le mec a littéralement écrit le livre sur les performances CSS), j’imagine qu’on peut s’attendre à ce que le projet évolue rapidement…

Pour l’implémenter, c’est vraiment simple. Vous récupérez le script sur GitHub, vous le minifiez si nécessaire, et vous le collez dans le head de votre HTML. Pas de npm, pas de webpack, pas de configuration compliquée. C’est à l’ancienne !

Voilà, je me suis dis que pour les développeurs qui me lisent, ça peut vous permettre par exemple d’adapter votre stratégie de lazy loading, de modifier la fréquence de vos appels API, ou même de changer complètement l’architecture de votre app selon le contexte. Vous pourriez par exemple désactiver le polling temps réel des utilisateurs qui ont une petite connexion, et le passer en mode manuel.

Bref, si vous faites du développement web et que vous vous souciez un minimum de l’expérience utilisateur, Obs.js mérite un petit coup d’oeil !

Firefox va ENFIN lire les MKV !

Attendez, attendez, attendez… Kewaaah ?

Firefox va ENFIN pouvoir lire des fichiers MKV ? En 2025 ? Non mais j’hallucine ! Bah oui parce que pendant des années, on a dû jongler avec des extensions pourries ou convertir nos fichiers comme des barbares, et là Mozilla se réveille tranquillement en mode “ah oui tiens, on pourrait peut-être supporter ce format que tout le monde utilise depuis 10 ans”. Mieux vaut tard que jamais comme on dit !

D’après le bug tracker officiel (mis à jour le 30 août dernier), Mozilla a donc enfin assigné un ingénieur sur le projet. L’implémentation devrait prendre 1 à 2 mois.

Pour ceux qui ne connaissent pas, le MKV (Matroska Video) c’est ce conteneur multimédia flexible qui peut embarquer plusieurs pistes audio, vidéo et sous-titres dans un seul fichier. C’est le format préféré de tous ceux qui téléchargent des films en haute qualité (légalement bien sûr, hein ^^). Chrome et Edge le supportent depuis des lustres et même Windows 10 et 11 le gèrent nativement ! Mais Firefox ? Que dalle…

Le déploiement va donc se faire progressivement, histoire de pas tout casser d’un coup. D’abord il y aura des tests dans Firefox Nightly avec les configs les plus courantes (vidéo H.264 avec audio AAC), puis on étendra aux codecs plus modernes comme VP9 ou AV1 avec Opus ou FLAC. C’est prudent, mais bon, vu le temps qu’ils ont mis à s’y mettre, on va pas chipoter.

Le plus drôle dans tout ça, c’est que le ticket de bug date de… attendez… 2017 ! 8 ans donc pour décider d’implémenter un format vidéo standard.

Pour les développeurs web, ça va simplifier la vie car plus besoin de maintenir deux versions de chaque vidéo sur les sites ou de forcer les utilisateurs Firefox à installer VLC ou autre. On pourra enfin utiliser le MKV pour les vidéos embarquées, avec tous ses avantages : meilleure compression, support des sous-titres softsub (les .srt, ce genre de trucs), le chapitrage…

Notez que l’implémentation ne couvrira pas TOUTES les fonctionnalités du MKV (le format est une usine à gaz quand même), mais comme je vous le disais plus haut, au moins les codecs déjà supportés par Firefox pourront être encapsulés en MKV. C’est déjà ça. On pourra enfin arrêter de convertir nos fichiers ou de changer de navigateur juste pour une vidéo.

En attendant, pour ceux qui ont absolument besoin de lire des MKV dans Firefox aujourd’hui, il reste les solutions de contournement habituelles : extensions tierces (qui marchent une fois sur deux), conversion en MP4 (en perdant des fonctionnalités), ou simplement… utiliser un autre navigateur. Mais bientôt, très bientôt, on pourra enfin rester sur notre bon vieux Firefox pour tout faire.

Alléluia !

Source

DCV - Quand votre terminal devient un cockpit Docker

J’ai déniché un truc sympa pour tous ceux qui passent leur vie dans Docker. Ça s’appelle DCV (Docker Container Viewer) et c’est développé par tokuhirom sur GitHub. En gros, imaginez que quelqu’un ait pris toutes les commandes Docker que vous tapez 50 fois par jour et les ait transformées en une interface accessible via le terminal super classe avec tous vos raccourcis Vim préférés.

Comme ça au lieu de vous taper docker ps, docker logs, docker exec et compagnie en boucle, vous avez tout sous les yeux dans une seule interface TUI (Terminal User Interface). Et le plus beau, c’est que c’est développé avec Bubble Tea , un framework Go qui cartonne pour faire des interfaces terminal qui déchirent (jetez y un oeil à l’occasion..).

Alors oui, je sais ce que vous allez me dire. Il existe déjà Lazydocker , Portainer et une chiée d’autres outils mais DCV a quelques atouts dans sa manche qui le rendent particulièrement intéressant.

D’abord, contrairement à Portainer qui nécessite un serveur web et tout le tralala, DCV reste dans votre terminal. C’est léger, ça démarre instantanément, et ça fonctionne partout où vous avez SSH. Pas besoin d’ouvrir des ports ou de configurer quoi que ce soit de compliqué.

Par rapport à Lazydocker, DCV mise sur une interface encore plus minimaliste et des raccourcis clavier inspirés de Vim. Du coup, si vous êtes du genre à ne jamais toucher votre souris, vous allez kiffer. Le truc cool aussi, c’est qu’il gère nativement Docker-in-Docker, ce qui peut être super pratique pour certains workflows de CI/CD.

L’outil vous permet donc de visualiser :

  • Tous vos containers Docker (standalone ou gérés par Compose)
  • Les images Docker disponibles
  • Les réseaux et volumes
  • Les logs en temps réel avec streaming
  • L’intérieur des containers (navigation dans les fichiers)

Mais là où ça devient vraiment intéressant, c’est que vous pouvez exécuter des commandes shell directement depuis l’interface. Plus besoin de copier l’ID du container pour faire un docker exec -it. Vous sélectionnez, vous appuyez sur une touche, et bam, vous êtes dans le container.

Pour l’installer, si vous êtes sur macOS ou Linux avec Homebrew :

brew tap tokuhirom/tap
brew install dcv

Pour les puristes du Go :

go install github.com/tokuhirom/dcv@latest

Ou alors vous pouvez simplement télécharger les binaires pré-compilés depuis les releases GitHub. C’est du Go compilé, donc un seul fichier executable et c’est parti.

DCV cherche ensuite sa configuration dans ~/.config/dcv/config.toml. Vous pouvez y définir avec quelle vue démarrer par défaut (docker, compose ou projects) ce qui est pratique si vous bossez principalement avec Docker Compose par exemple.

Petit exemple de config :

initial_view = "compose"

Et pour debug en cas de souci :

dcv -debug dcv.log

Voilà, je trouve que DCV mérite sa place dans votre boîte à outils Docker. C’est pas révolutionnaire c’est sûr, mais c’est bien foutu et ça fait le job. L’approche minimaliste avec les raccourcis Vim, c’est vraiment agréable quand on a l’habitude.

Puis le fait que ce soit du Go compilé, c’est aussi un gros plus. Pas de dépendances Node.js ou Python à installer, pas de versions qui se marchent dessus. Un binaire, et roule. Voilà, donc si vous cherchez un outil simple pour surveiller vos containers Docker sans quitter votre terminal, je vous invite à donner une chance à DCV . Et si vous êtes déjà accro à Vim, c’est carrément un no-brainer.

WordPress Telex - L'outil IA qui génère vos blocs Gutenberg à partir d'un simple prompt

J’ai testé un truc trop cool ce soir et je pense que ça va vous plaire, si vous utilisez WordPress. Ça s’appelle Telex et c’est un nouveau service expérimental lancé par les petits gars d’Automattic au WordCamp US 2025 . Matt Mullenweg l’a présenté comme leur vision de l’IA pour le développement WordPress, un peu comme le fait v0 de Vercel ou Lovable, mais spécifiquement conçu pour générer des blocs Gutenberg WordPress.

Ces blocs Gutenberg, si vous ne connaissez pas, ce sont ces modules de contenus custom que vous pouvez rajouter dans vos pages WordPress. En général, ça me demande de coder un peu mais avec Telex, vous tapez un prompt décrivant ce que vous voulez, et il vous génère un fichier .zip que vous pouvez installer comme un plugin sur votre site WordPress ou dans WordPress Playground (cette version qui tourne directement dans le navigateur sans hébergement).

L’outil est donc disponible dès maintenant sur telex.automattic.ai si ça vous branche.

Ce qui est vraiment cool, c’est que tout se passe directement dans l’interface WordPress que vous connaissez déjà. Le panneau de prompt se trouve sur la droite, et vous pouvez voir le code généré et le tester en temps réel dans l’éditeur comme ça, pas besoin de jongler entre différentes interfaces comme avec d’autres outils IA.

Pour ma part, je lui ai demandé de me faire un bloc pour mon Patreon et je trouve qu’il s’en est vraiment bien sorti. Mais attention, les résultats sont vraiment variables selon ce que vous demandez.

Du coup si votre premier prompt ne donne pas le résultat escompté, sachez que c’est souvent compliqué de corriger le tir avec des prompts supplémentaires. Mieux vaut donc recommencer avec une approche différente.

Notez qu’Automattic héberge Telex sur son propre domaine plutôt que de l’intégrer directement à WordPress.com. Ça pourrait signifier qu’ils préparent un produit IA indépendant qu’ils pourraient potentiellement proposer en marque blanche aux hébergeurs ou aux développeurs…. On verra bien.

Quoi qu’il en soit, ce lancement s’inscrit dans une stratégie plus large de WordPress de développer des produits IA alignés avec les objectifs long terme de la plateforme. Pour l’instant, c’est gratuit (il faut juste un compte WordPress.com), mais vu le caractère expérimental, ne comptez pas dessus pour vos projets clients. Par contre, pour s’amuser et voir où va WordPress avec l’IA, c’est franchement pas mal.

J’imagine que la prochaine étape, ce sera de proposer des thèmes personnalisés par IA… et qui sait, peut-être qu’un jour, c’est l’IA de WordPress qui rédigera vos articles ?

Source

Ollama - 14 000 serveurs IA laissés en libre-service sur Internet

En ce moment, tout le monde veut son petit serveur local pour faire tourner des modèles IA, mais en vrai, j’ai l’impression que personne ne se pose la question de la sécurité. Du coup, on se retrouve avec un problème totalement anticipable mais j’ai l’impression que tout le monde s’en cogne…

En effet, j’ai découvert qu’il y a littéralement des milliers de serveurs Ollama qui traînent en libre-service sur le net. Pas protégés, pas sécurisés, que dalle. Ils sont juste là, accessibles à qui veut bien se connecter dessus. Le site Malware Patrol parle même de 14 000 instances publiquement accessibles. C’est fou !

Le truc, c’est qu’Ollama par défaut, ça vient sans authentification, car le créateur du truc s’est dit “bon, c’est pour du local, pas besoin de compliquer le choses”. Sauf que les gens installent ça sur des serveurs et ouvrent le port 11434 à tout Internet, comme ça, sans réfléchir.

Alors est ce que c’est grave ? Et bien Cisco Talos a fait une étude récente là-dessus et ils ont trouvé plus de 1 100 serveurs Ollama exposés, dont 20% qui hébergent des modèles vulnérables. Les États-Unis arrivent en tête avec 36,6% des serveurs exposés, suivis de la Chine (22,5%) et l’Allemagne (8,9%). Le Dr. Giannis Tziakouris de l’équipe Talos parle carrément de “négligence généralisée des pratiques de sécurité fondamentales”.

Hé oui parce que derrière cette négligence, il y a surtout des failles techniques vraiment critiques. Il y a par exemple la CVE-2024-37032 , surnommée “Probllama”, qui est une vulnerability d’exécution de code à distance super facile à exploiter. En gros, avec une seule requête HTTP, un attaquant peut prendre le contrôle complet du serveur.

Faut quand même avoir conscience qu’il y a une grande variété d’attaques possibles sur ces trucs. Par exemple, on peut faire de l’extraction de modèles (genre, je pique votre IA propriétaire), de jailbreaking (je contourne les protections), d’injection de backdoors dans les modèles, d’épuisement des ressources pour vous faire exploser votre facture cloud, et même de mouvement latéral dans votre réseau.

The Hacker News a recensé rien que l’année dernière six vulnérabilités dans Ollama qui permettent des attaques par déni de service, du vol de modèles et de l’empoisonnement de modèles et la plupart de ces instances Ollama tournent encore avec des versions obsolètes. Bref, c’est la cata, sans parler des déploiements Docker d’Ollama qui sont encore pire car par défaut, le serveur API tourne avec les privilèges root et se lie à toutes les interfaces réseau.

Et le nombre d’instances exposées ne fait qu’augmenter puisqu’en novembre 2024, on était à 3 000 instances, et maintenant on dépasse les 14 000. Les gens s’amusent bien et installent Ollama plus vite qu’ils n’apprennent à le sécuriser.

Donc, concrètement, si vous avez un serveur Ollama, faites moi plaisir et mettez-le derrière un reverse proxy avec authentification, pensez à bien configurer la variable d’environnement OLLAMA_HOST=127.0.0.1 pour limiter l’accès au localhost, et surtout, mettez à jour vers la dernière version. La vulnérabilité Probllama dont je vous parlais plus haut a été patchée dans la version 0.1.34, mais encore faut-il l’installer.

A bon entendeur…

Source

Une web machine pour fabriquer des autocollants holographiques

Vous vous souvenez de ces autocollants holographiques qu’on trouvait à tous les coins de rue dans les années 90 ? Mais siiiii, ces machins brillants qui changeaient de couleur selon l’angle de vue et qui scintillaient de mille feux grâce à leurs petites paillettes métalliques ? Eh bien, un développeur a réussi à reproduire cet effet en WebGL et en a fait un générateur. Et je dois dire que le résultat est plutôt bluffant.

Le projet en question part d’une observation simple qui est que ces autocollants jouent sur deux phénomènes visuels. D’abord l’iridescence, ce changement de couleur selon l’angle de vue qui rappelle les bulles de savon ou les ailes de papillon. Et ensuite ces minuscules paillettes métalliques qui captent la lumière et créent ces points brillants qui semblent danser à la surface.

Ce qui est vraiment cool du coup, c’est que le développeur a réussi à reproduire ces effets sans simulation physique complexe. Pas de calculs d’interférence de films minces, pas de modélisation de microfacettes métalliques. À la place, une approche purement visuelle qui approxime le rendu final avec des techniques de shader astucieuses.

Le vertex shader gère en réalité un effet de “pelage” de la géométrie en utilisant la formule de rotation de Rodrigues . Pour ceux qui ne connaissent pas, c’est une méthode mathématique élégante pour faire tourner des vecteurs dans l’espace 3D autour d’un axe arbitraire. Ici, elle permet de simuler le décollage progressif de l’autocollant, avec des calculs d’occlusion ambiante et d’intensité de pelage qui donnent cette impression de matière qui se décolle vraiment.

Du côté du fragment shader, c’est là que la magie opère vraiment. Le bruit procédural génère ces fameuses paillettes métalliques. Ainsi au lieu de placer manuellement des milliers de petits points brillants, l’algorithme crée des patches aléatoires de luminosité qui ressemblent à s’y méprendre à des flocons métalliques qui accrochent la lumière. L’échantillonnage de la carte d’environnement ajoute les reflets réalistes, pendant que le calcul d’iridescence utilise des ondes sinusoïdales pour décaler la teinte en fonction de l’angle de vue.

L’effet Fresnel, ce phénomène qui rend les surfaces plus réfléchissantes sur les bords, complète l’illusion. C’est ce qui donne cette impression que l’autocollant “s’allume” différemment selon comment on le regarde. Enfin, le shader combine tout ça avec un contrôle fin de la réflectivité métallique, la taille des paillettes, leur intensité, et même le rendu de la face arrière avec des ombres.

En plus, le dev a tout mis sous licence Creative Commons BY-NC 4.0 donc vous pouvez donc l’utiliser, le modifier, l’adapter à vos projets, tant que c’est non-commercial et que vous créditez l’auteur.

Sérieux, qui aurait cru qu’un jour on pourrait recréer la magie des autocollants holographiques de notre enfance directement dans le navigateur ?

Source

Python - Comment un petit projet de Noël est devenu le langage de l'IA et de la science

Y’a pas une semaine qui passe sans que je code un petit peu de Python, alors quand je suis tombé sur ce documentaire que Cult.Repo vient de sortir , je me suis dit que c’était l’occasion d’en apprendre un peu plus sur ce langage qui fait tourner l’IA chez Google, Meta et OpenAI, et qui (je viens de l’apprendre) a commencé comme un projet de vacances. Guido van Rossum son créateur cherchait juste un truc pour s’occuper pendant les vacances de Noël en 1989. Son bureau était fermé, il s’ennuyait, alors il a pondu les bases d’un nouveau langage en deux semaines. Pour le fun.

Le documentaire montre vraiment bien comment ce petit projet perso est devenu un monstre. Au départ, van Rossum bossait au CWI à Amsterdam sur un langage appelé ABC, sauf qu’ABC avait plein de défauts et surtout, impossible de l’étendre. Python, c’était donc sa revanche… prendre le meilleur d’ABC (comme l’indentation pour structurer le code) et virer tout ce qui l’énervait.

Le nom Python, d’ailleurs, ça n’a rien à voir avec le serpent. Van Rossum était fan des Monty Python. Il cherchait un nom court, mystérieux, et il lisait les scripts de la série à ce moment-là. Voilà donc comment le langage le plus utilisé au monde a hérité du nom d’une troupe de comiques britanniques.

Un fait marquant dans cette histoire, c’est la crise de 2018. Le 12 juillet 2018, Guido van Rossum a tout plaqué . Il était le “Benevolent Dictator For Life” (BDFL) de Python depuis le début, et là, pouf, terminé.

La raison ? Une discussion autour de la PEP 572, qui proposait d’ajouter l’opérateur walrus (:=) à Python. Les échanges sont devenus tellement toxiques sur les mailing-lists que van Rossum a craqué. Il a dit en gros : “J’en ai marre de me battre pour mes décisions et de voir que tout le monde les déteste. Je me casse.” On dirait moi quand je me suis cassé des réseaux sociaux ^^.

Cette histoire de PEP 572, c’était pas juste une dispute technique. C’était l’une des pires discussions de l’histoire de Python , avec des threads énormes sur plusieurs mailing-lists et des sondages. Les développeurs trouvaient que ça allait contre la philosophie de Python, c’est à dire la simplicité avant la complexité et Van Rossum a fini par avoir gain de cause, mais le prix à payer était trop élevé.

Ce qui est fascinant, c’est que Python a survécu à cette crise. Van Rossum n’a pas nommé de successeur et a laissé la communauté se débrouiller. Les 100-200 développeurs avec droits de commit ont alors dû créer un nouveau modèle de gouvernance avec comme deadlines le 1er octobre 2018 pour les propositions, et le 1er novembre pour voter. Et ça a marché.

Notez que Van Rossum est resté dans le Steering Council de Python jusqu’en 2019, puis s’est retiré des nominations pour 2020. Mais il reste confiant sur l’avenir et dit que la communauté Python est solide, avec un noyau dur dynamique, et qu’il ne serait jamais parti s’il pensait qu’ils ne pourraient pas guider le langage pendant encore des décennies.

Cult.Repo prépare déjà des documentaires sur Vite (qui sort le 9 octobre à Amsterdam) et C++ . Si c’est du même niveau que celui sur Python, ça vaut le coup d’œil. Bref, si vous codez en Python ou si vous vous intéressez à l’histoire de la tech, regardez ce documentaire car c’est rare de voir les coulisses d’un langage de programmation racontées comme ça, avec les conflits, les personnalités et les décisions qui ont façonné cet outil qu’on utilise tous les jours.

VimMaster - Un jeu gratuit pour apprendre enfin à utiliser Vim !

Combien d’entre vous ont déjà ouvert Vim par accident en suivant un tuto et se sont retrouvés coincés dedans ? Moi, j’ai dû passer une bonne dizaine de minutes à tâtonner pour trouver une porte de sortie la première fois et après je suis passé sous “nano”. Heureusement, un génie du nom de renzorlive a conçu VimMaster , un jeu gratuit qui transforme cet apprentissage en une aventure ludique des plus passionnantes.

La beauté de VimMaster c’est qu’au lieu de vous assommer avec un pavé de 500 pages de documentation à la con ou de vous forcer à mémoriser des commandes abstraites, il vous fait tout simplement… jouer. Ce jeu comprend donc 16 niveaux progressifs et chaque défi vous permet de maîtriser une nouvelle compétence. Le petit plus c’est que vous pouvez y jouer directement dans votre navigateur, sans avoir à installer quoi que ce soit.

C’est du pur HTML/CSS/JavaScript, pas de framework à la mode, pas de dépendances npm lourdes comme un éléphant. Juste du code propre qui fait le job et au niveau du gameplay, c’est bien pensé. Car contrairement à d’autres outils qui se contentent de vérifier si vous appuyez sur les bonnes touches, VimMaster valide le résultat de chacune de vos actions.

Vous pouvez même arriver à un résultat identique et valide de différentes manières, comme dans le vrai Vim. Il y a même un mode Challenge chronométré pour ceux qui veulent se la jouer speedrun, et un Cheat Mode accessible avec Ctrl+/ pour les moments de désespoir.

Parmi les alternatives disponibles, on a Vim Adventures qui devient payant après quelques niveaux, VimGenius qui propose des flashcards chronométrées, ou VimHero avec ses tutoriels interactifs. Mais VimMaster se démarque surtout par sa simplicité et sa gratuité totale.

En plus, le système de progression est bien ficelé. Vous avez un profil avec des achievements, des badges à débloquer, et même la possibilité d’exporter/importer votre progression. Les cartes d’achievements sont générées dynamiquement en Canvas API et vous pouvez les partager sur les réseaux sociaux pour vous la raconter un petit peu.

Bref, si vous avez toujours voulu apprendre Vim sans vous arracher les cheveux, c’est le bon moment !

TypingSVG - Un générateur d'animations qui rend vos textes vivants

Vous avez déjà vu ces README GitHub avec du texte qui s’écrit tout seul comme si quelqu’un tapait en temps réel ? Hé bien voilà ce qu’il vous faut pour faire pareil sur votre propre site. Ça s’appelle TypingSVG , ça a été créé par un certain whiteSHADOW1234 et c’est donc un générateur d’animations SVG qui transforme n’importe quel texte en animation de frappe dynamique. Et surtout c’est complètement gratuit et ça tourne directement dans votre navigateur.

Le truc sympa avec TypingSVG, c’est qu’il ne se contente pas de faire défiler bêtement du texte. Non non, c’est un vrai système complet avec support multi-lignes, gestion des emojis 😎🚀, et même la possibilité de personnaliser la vitesse de suppression du texte. Parce que oui, l’outil simule aussi l’effacement, comme si quelqu’un revenait en arrière pour corriger une faute de frappe…

L’interface web est dispo sur typingsvg.vercel.app . Vous tapez votre texte, vous réglez quelques paramètres (police, taille, couleur, vitesse d’animation), et hop, vous avez un aperçu en temps réel de votre animation. Pas besoin d’installer quoi que ce soit, pas de compte à créer, juste vous et votre créativité.

Pour les dev, c’est du pain béni car vous pouvez intégrer ces animations directement dans vos README GitHub, vos portfolios, ou même vos sites web. Le générateur vous donne ainsi plusieurs formats d’export : une URL directe, du Markdown pour GitHub, ou du HTML pur pour vos pages web. Et comme c’est du SVG, ça reste léger et ça scale parfaitement sur tous les écrans.

Au niveau de la personnalisation, vous avez le choix entre plusieurs styles de curseur (droit, souligné, bloc, ou même invisible si vous préférez). La police Monaco par défaut donne un côté terminal très classe, mais vous pouvez changer pour n’importe quelle police web. L’espacement des lettres est ajustable, vous pouvez centrer le texte horizontalement et verticalement, et même ajouter une bordure autour de votre SVG si l’envie vous prend.

Le code derrière tout ça, c’est du Next.js avec TypeScript et Tailwind CSS ce qui fait que c’est moderne et maintenable et whiteSHADOW1234 a fait un sacré boulot pour que l’API soit simple à utiliser. Un simple appel à /api/svg avec les bons paramètres et vous récupérez votre animation. Par exemple, pour un “Hello, World!” qui clignote, il suffit d’ajouter ?text=Hello,+World! à l’URL.

Et pour ceux qui veulent aller plus loin, vous pouvez même déployer votre propre instance sur Vercel. Un bouton “Deploy to Vercel” est disponible sur le repo GitHub, et en quelques clics vous avez votre propre générateur personnel. Pratique si vous voulez des fonctionnalités custom ou si vous préférez garder le contrôle total sur vos animations.

Bref, pas de fioritures inutiles mais juste ce qu’il faut pour créer des animations de texte qui claquent, que ce soit pour pimper votre profil GitHub, ajouter un peu de dynamisme à votre site, ou juste pour le fun !

Un terminal qui affiche la vraie position de la Lune en ASCII

Vous avez déjà fixé votre terminal en vous disant “il lui manque quelque chose” ?

Bien sûr que oui, et ce quelque chose, c’est une représentation précise de la Lune en pur ASCII 7-bit !!

Aleyan, un développeur visiblement obsédé par les détails astronomiques, a créé ASCII Side of the Moon , un projet qui va faire de votre terminal un observatoire lunaire minimaliste.

Mais attention, ce n’est pas juste un dessin statique de la Lune. L’outil calcule en temps réel la phase lunaire, la distance Terre-Lune ET même l’angle de libration. Pour ceux qui se demandent, la libration c’est ce petit mouvement d’oscillation de la Lune qui nous permet de voir environ 59% de sa surface au fil du temps, au lieu des 50% théoriques. Et oui, tout ça est visible dans l’ASCII art généré.

Pour les curieux qui veulent tester immédiatement, c’est con comme la Lune (justement ^^). Vous pouvez soit utiliser curl directement dans votre terminal :

curl -s "https://aleyan.com/projects/ascii-side-of-the-moon?date=2025-09-01"

Ou installer le package npm pour l’avoir en local :

npx ascii-side-of-the-moon

L’approche technique est assez sympa puisqu’Aleyan n’a pas bricolé les calculs astronomiques à l’arrache. Selon sa documentation technique , il utilise astronomy-engine de CosineKitty, une bibliothèque de calculs astronomiques très sérieuse. Les images de base ont été rendues dans Blender à partir d’un modèle 3D de la Lune en 2K créé par gerhald3d, avec différentes distances et angles de libration. Et ensuite, Chafa (un convertisseur d’images vers ASCII) transforme ces rendus PNG en glorieux ASCII art.

L’aspect le plus impressionnant reste tout de même la précision des calculs. La taille apparente de la Lune change vraiment en fonction de sa distance à la Terre. Ainsi au périgée (point le plus proche), elle apparaît 14% plus grande qu’à l’apogée. Cette variation est fidèlement représentée dans l’ASCII, avec un ajustement du nombre de caractères utilisés pour dessiner notre satellite.

Bref, l’ASCII n’est pas mort, loin de là. C’est même devenu une forme d’expression artistique à part entière pour les développeurs qui veulent créer quelque chose de beau avec les contraintes les plus minimales possibles… 128 caractères ASCII, pas de couleurs, pas de polices fantaisistes, juste du texte brut et de l’imagination.

C’est chouette non ?

LEANN - L'IA personnelle qui écrase 97% de ses concurrents (en taille)

60 millions de documents, c’est ce que LEANN peut indexer sur votre petit laptop sans faire exploser votre SSD. C’est ouf non ? Car pendant que tout le monde se bat pour avoir le plus gros modèle d’IA avec des milliards de paramètres, des chercheurs de UC Berkeley ont décidé de prendre le problème à l’envers en compressant tout ça pour que ça tienne sur un Macbook Air ou équivalent.

L’idée est tellement… au lieu de stocker tous les embeddings vectoriels (ces représentations mathématiques qui permettent à l’IA de comprendre vos documents), LEANN les recalcule à la volée quand vous en avez besoin. C’est comme si au lieu de garder 10 000 photos de votre chat sous tous les angles, vous gardiez juste une photo + un algorithme capable de reconstituer les autres instantanément.

Le truc vraiment fou, c’est que cette approche réduit l’espace de stockage de 97% par rapport aux solutions classiques comme Pinecone ou Qdrant. Pour vous donner une idée, là où une base vectorielle traditionnelle aurait besoin de 100 Go pour indexer vos documents, LEANN s’en sort avec 3 Go seulement. Et selon les benchmarks publiés , ça maintient 90% de précision avec des temps de réponse sous les 2 secondes.

Concrètement, LEANN utilise une technique qu’ils appellent “graph-based selective recomputation with high-degree preserving pruning” (oui, les chercheurs adorent les noms à rallonge). En gros, au lieu de parcourir tous les vecteurs pour trouver une correspondance, le système navigue dans un graphe optimisé qui ne garde que les connexions les plus importantes. C’est un peu comme utiliser Waze au lieu de vérifier toutes les routes possibles pour aller quelque part.

L’installation est d’une simplicité déconcertante :

curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv
source .venv/bin/activate
uv pip install leann

Et hop, avec ça vous pouvez indexer vos PDFs, vos emails Apple Mail, votre historique Chrome, vos conversations WeChat, et même votre codebase entière. Le système est d’ailleurs assez malin pour comprendre la structure du code (fonctions, classes, méthodes) plutôt que de bêtement découper le texte tous les 500 caractères.

Et LEANN s’intègre directement avec Claude Code via un serveur MCP. Pour ceux qui utilisent Claude Code (coucou les Vibe Coders, on est ensemble !! ^^), vous savez que le plus gros problème c’est qu’il fait toujours des grep qui ne trouvent presque jamais rien. Alors qu’avec LEANN, une seule ligne de config et boom, vous avez de la recherche sémantique intelligente dans votre IDE.

Les cas d’usage sont d’ailleurs assez dingues puisque certains l’utilisent pour créer leur propre second cerveau qui indexe tout ce qu’ils ont lu, écrit ou consulté. D’autres s’en servent en entreprise pour faire de la recherche dans des bases documentaires sensibles sans rien envoyer dans le cloud. Y’a même des développeurs qui l’utilisent pour naviguer dans des codebases monstrueuses de millions de lignes. Moi je suis en train de le dompter pour lui faire bouffer tout le contenu de mon site et voir ce que je peux en tirer…

Le projet arrive donc pile au bon moment pour moi, mais aussi pour tous ceux qui s’inquiètent de leur vie privée et des données qui partent chez OpenAI ou Google. Avoir une solution 100% locale qui tourne sur votre machine, c’est top surtout dans des domaines comme la santé ou la finance où envoyer des données dans le cloud, c’est juste pas une option.

Et les chercheurs de Berkeley ne se sont pas arrêtés là puisqu’ils ont aussi intégré du support multilingue, donc vous pouvez chercher en français dans des documents en anglais et vice versa. Et cerise sur le gâteau, tout est open source sous licence MIT, donc vous pouvez tripatouiller le code comme bon vous semble.

Évidemment, LEANN a ses limites car le recalcul à la volée consomme plus de CPU que de simplement lire des vecteurs pré-calculés. Donc sur une machine vraiment faiblarde, ça peut ramer un peu. Et pour des cas d’usage où vous avez besoin de réponses en millisecondes (genre un moteur de recherche public), c’est peut-être pas l’idéal. Mais franchement, pour 97% d’économie de stockage et une vie privée totale, c’est un compromis que beaucoup sont prêts à faire. Surtout quand on sait que le prochain macOS va probablement embarquer de l’IA partout et qu’on aimerait bien garder nos données pour nous.

Voilà, pour ceux qui veulent creuser, le papier de recherche détaille toute la théorie derrière. Les benchmarks notés dans ce papier montrent même que LEANN bat certaines solutions cloud sur des requêtes complexes, tout en tournant sur un laptop à 2000 euros au lieu d’un cluster à 100 000 balles.

Bref, LEANN c’est l’exemple parfait qu’on n’a pas toujours besoin de plus de puissance ou plus de stockage. Suffit juste d’être plus malin !

Merci à Letsar et Lorenper pour le partage !

NetPeek - Un scanner réseau sous Linux facile à utiliser

Hier soir, je suis tombé sur NetPeek et franchement, ça m’a fait plaisir de voir qu’enfin quelqu’un s’attaque au problème de la complexité de nmap pour les utilisateurs normaux.

NetPeek, c’est donc cette nouvelle application qui vient d’arriver sur Flathub et qui promet de simplifier drastiquement le scanning réseau sous Linux. Développée par ZingyTomato avec Python et GTK4/libadwaita, l’app adopte le design moderne de GNOME pour offrir une alternative graphique aux outils en ligne de commande comme nmap.

La première chose qui frappe quand on lance NetPeek, c’est donc sa simplicité. L’interface est épurée, moderne, et on comprend tout de suite ce qu’on doit faire. Vous saisissez votre plage d’adresses IP (notation CIDR, ranges ou adresses simples), vous cliquez sur “Scanner” et hop, l’application se met au travail.

Ce qui rend NetPeek particulièrement efficace également, c’est son système “multithreadé” qui accélère considérablement les scans. L’app détecte ainsi automatiquement votre plage IP locale, ce qui évite de se prendre la tête avec les configurations et une fois le scan terminé, les appareils s’affichent dans l’ordre croissant avec leurs ports ouverts. Ensuite, vous pouvez copier les adresses IP d’un simple clic.

L’outil s’appuie sur des bibliothèques Python classiques telles que socket pour les opérations réseau, ipaddress pour la validation des IP, threading pour le scan concurrent et ping3 pour tester la disponibilité des hôtes.

Et ce qui me plaît avec NetPeek, c’est qu’il ne cherche pas à rivaliser avec les mastodontes comme nmap ou Zenmap. Non, son objectif est clair, à savoir répondre à la question “Quels sont les appareils actifs sur mon réseau et quels ports sont ouverts ?” sans avoir besoin d’un doctorat en administration réseau. D’une certaine manière, ça me fait penser un peu à Angry IP Scanner

L’installation se fait principalement via Flathub avec la commande

flatpak install flathub io.github.zingytomato.netpeek

Mais les utilisateurs d’Arch Linux peuvent aussi passer par les packages AUR netpeek ou netpeek-git.

L’app s’intègre notamment parfaitement dans l’environnement GNOME moderne avec son interface libadwaita qui respecte les thèmes système. Voilà, si ça vous chauffe, vous pouvez télécharger NetPeek directement depuis Flathub ou consulter le code source sur GitHub .

Ça devrait bien vous aider pour surveiller votre réseau domestique, diagnostiquer des problèmes de connectivité ou simplement découvrir tous les appareils connectés chez vous.

Source

Super Mario 64 - Le jeu qui gaspillait la mémoire de la N64

Ce matin, j’ai lu un truc qui m’a fait tilter. Vous saviez que Super Mario 64, ce chef-d’œuvre absolu qui a changé le jeu vidéo à tout jamais, était en fait un gouffre à mémoire sur Nintendo 64 ? C’est un programmeur nommé Kaze Emanuar s’est amusé à disséquer le code source et les résultats de son analyse sont plutôt… surprenants.

Pour comprendre l’ampleur du problème, il faut se replacer dans le contexte. La N64 avait 4 Mo de RDRAM rapide. Pour vous donner une idée, c’est à peine la taille d’une photo prise avec votre smartphone aujourd’hui. Et dans ces 4 Mo, il fallait caser les textures, le code, la musique, les buffers de sortie et les états des acteurs. Autant dire que chaque octet comptait.

Et pourtant, Mario 64 dilapidait cette précieuse mémoire comme s’il n’y avait pas de lendemain. Le jeu semble en effet avoir été livré dans une version debug avec “du code inutile partout”.

Le système audio à lui seul bouffe 512 Ko. Mais le plus dingue, c’est qu’au lieu de réutiliser intelligemment les buffers, le jeu alloue 4 buffers d’échantillons par note alors qu’un seul suffirait. Du coup c’est 51 Ko de RAM qui partent en fumée, soit l’équivalent de 17 textures. Ouch.

Les fonctions mathématiques ne sont pas en reste non plus. Les tables de sinus et cosinus auraient pu être divisées par quatre grâce à la symétrie circulaire, économisant 12 Ko supplémentaires. C’est assez pour 4 nouvelles textures de plus et un léger gain de performances.

Mais le plus gros gâchis se trouve sans doute dans la gestion des objets. Chaque acteur, même les plus simples, se voit allouer 608 octets peu importe sa complexité. Une allocation uniforme complètement inutile qui fait mal au cœur de tout développeur qui se respecte. Et je ne parle même pas du chargement des assets ! Le jeu charge des banks mémoire complètes incluant des objets totalement non pertinents comme des algues ou des mines aquatiques, alors qu’un seul élément est nécessaire.

Le build NTSC de Mario 64 n’utilisait même pas les optimisations du compilateur. Comme si Nintendo avait oublié d’activer le mode “optimisé” avant de lancer les cartouches en production. Mais bon, avant de taper sur l’équipe de développement, remettons les choses en perspective. On parle de 7 programmeurs qui avaient seulement 20 mois pour créer un jeu incroyable sur une console dont le hardware et les outils de développement étaient encore en cours de finalisation. Dans ce contexte, avoir 4 Mo de RAM rapide, c’était le luxe absolu et l’optimisation pouvait attendre.

Les travaux récents de programmeurs comme Kaze Emanuar montrent donc qu’avec les techniques modernes, on peut obtenir des performances 6 fois meilleures en utilisant le N64 Expansion Pack, qui est quelque chose que l’équipe originale n’avait pas.

La preuve que les développeurs ont appris de leurs erreurs c’est The Legend of Zelda: Ocarina of Time, sorti plus tard, qui était infiniment plus optimisé. Les leçons avaient été tirées et les outils s’étaient améliorés.

Au final, Mario 64 reste un monument du jeu vidéo malgré ses défauts techniques. Et franchement, quand on voit le résultat final, on se dit que quelques Mo gaspillés, ça valait largement le coup pour un jeu qui a changé l’industrie.

Source

CronMaster - Une interface graphique pour gérer vos cron jobs

Si vous avez déjà passé 20 minutes à déboguer un cron job qui ne se lance pas parce que vous aviez mis un espace au mauvais endroit dans la syntaxe * * * * *, vous allez adorer CronMaster .

Car le problème avec cron, c’est pas le concept en lui-même. L’idée de planifier des tâches automatiques reste géniale depuis les années 70. Non, le souci c’est cette syntaxe ésotérique qui fait que même les devs expérimentés doivent vérifier trois fois leur ligne avant de valider. Un petit 0 2 * * 1-5 et vous vous demandez si ça va se lancer tous les lundis ou tous les jours de la semaine à 2h du matin.

CronMaster arrive donc avec une proposition simple qui est de conserver la puissance de cron tout en rendant son utilisation intuitive. L’interface web affiche vos jobs sous forme de cartes visuelles, avec le nom de la tâche, sa fréquence d’exécution en langage humain et la possibilité de les activer/désactiver d’un clic. Plus besoin de commenter/décommenter des lignes dans le crontab.

CronMaster ne réinvente pas cron. Il se pose juste comme une couche visuelle par-dessus le système existant. Vos jobs continuent de tourner via le crontab système, mais vous les gérez depuis une interface moderne avec du dark mode, des stats système en temps réel (CPU, RAM, uptime) et même la possibilité de gérer des scripts bash directement depuis l’interface.

L’installation passe par Docker, ce qui simplifie énormément le déploiement. Un simple docker-compose.yml avec quelques variables d’environnement et vous avez votre interface accessible sur le port 40123. Le projet supporte aussi bien AMD64 qu’ARM64, donc ça tourne aussi bien sur votre serveur que sur un Raspberry Pi.

CronMaster n’est pas le seul dans sur créneau. Y’a Cronicle qui propose par exemple une solution multi-serveurs avec des graphiques de performance en temps réel et une gestion des dépendances entre tâches ou encore Crontab-UI qui mise plutôt sur la simplicité avec import/export de configurations et système de backup automatique.

Mais CronMaster a ses propres atouts. Son système d’informations système intégré permet de voir en un coup d’œil l’état de votre serveur pendant que vos jobs tournent. Et le support des variables d’environnement HOST_PROJECT_DIR facilite l’intégration dans des workflows existants. Sans oublier la possibilité de gérer plusieurs utilisateurs crontab depuis la même interface est pratique pour les équipes.

Un détail technique important… CronMaster nécessite les droits root dans le conteneur Docker pour accéder au crontab système. C’est un choix assumé du dev pour garantir une intégration transparente avec le système existant. Donc si vous préférez une approche plus isolée, Zeit propose une alternative desktop en C++ qui tournera sur votre ordi.

Le format cron reste toujours le même : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12) et jour de la semaine (0-7), mais avec CronMaster, vous avez des sélecteurs visuels qui génèrent automatiquement la bonne syntaxe comme ça, plus besoin de se rappeler que */5 signifie “toutes les 5 minutes” ou que 0,30 veut dire “à la minute 0 et 30”.

L’interface affiche aussi les logs d’exécution de chaque job, ce qui facilite grandement le debug. Au lieu de fouiller dans /var/log/syslog ou de configurer des redirections complexes avec >> /var/log/monjob.log 2>&1, tout est accessible depuis l’interface web.

Pour les développeurs qui bossent sur plusieurs projets, la fonctionnalité de commentaires sur chaque job est également super pratique. Vous pouvez documenter pourquoi tel script doit tourner à 3h du matin ou rappeler les dépendances d’un job particulier. Ces métadonnées restent attachées au job dans l’interface, contrairement aux commentaires dans le crontab qui peuvent facilement se perdre.

Voilà, donc si vous gérez régulièrement des cron jobs et que vous en avez marre de cette syntaxe cryptique, vous adorerez CronMaster !! C’est à découvrir ici !

Happy - L'app qui transforme Claude Code en assistant mobile 24/7

Vous savez ce qui est frustrant quand, comme moi, on fait plein de trucs avec Claude Code ? C’est de devoir rester scotché à son ordi pour suivre l’avancement d’une build ou d’une tâche un peu longue. Heureusement des ingénieurs de San Francisco ont ressenti exactement la même frustration, et au lieu de râler dans leur coin comme des cons, ils ont créé Happy .

L’idée leur est venue dans au café où ils passaient leur temps à vérifier constamment l’avancement de leurs projets sur Claude Code. Comme ils l’expliquent sur leur site , ils checkaient leurs laptops toutes les 5 minutes pendant les pauses déjeuner et ça commençait à les relouter. Du coup, ils ont développé une solution mobile qui permet de garder un œil sur Claude Code depuis n’importe où, avec des notifications push et tout le tralala.

Happy fonctionne de la manière suivante. Sur votre machine, vous remplacez simplement la commande claude par happy dans votre terminal et l’application se charge ensuite de créer un pont chiffré de bout en bout entre votre ordinateur et votre téléphone. Comme ça, quand vous voulez contrôler Claude depuis votre mobile, le système bascule automatiquement en mode distant. Simple et efficace.

L’installation de Happy est simple. Vous téléchargez l’app iOS ou Android, puis vous installez le CLI sur votre ordi avec

npm install -g happy-coder

À partir de là, y’a plus qu’à utiliser happy au lieu de claude dans votre terminal habituel. L’interface mobile reprend alors toutes les fonctionnalités de Claude Code, avec en prime la possibilité de recevoir des notifications push quand une tâche importante se termine ou qu’une erreur survient. C’est vraiment top ! Pour tout vous dire, j’avais ce besoin et je m’étais codé une interface web accessible depuis l’extérieur de chez moi (via un VPN), avec un terminal ttyd dedans pour y lancer Claude Code mais c’était un peu archaïque et pas très pratique.

Niveau sécurité, Happy dispose d’un système de chiffrement de bout en bout comme ça, vos sessions Claude restent privées et sécurisées, même quand elles transitent par les serveurs de Happy pour la synchro. Les développeurs ont clairement pensé aux professionnels qui travaillent sur des projets sensibles et qui ne peuvent pas se permettre de faire fuiter du code propriétaire.

L’aspect open source du projet mérite également d’être souligné car tout le code est disponible sur GitHub, et est divisé en trois composants principaux : happy-cli pour l’interface en ligne de commande, happy-server pour le backend de synchronisation chiffrée, et happy-coder pour le client mobile.

Faut que je prenne le temps d’aller jeter un œil au code aussi pour voir comment ils encapsulent Claude Code dans leur CLI Happy et comment il lui injectent des commandes, parce que ça va me permettre de mettre au point un contrôleur tiers qui viendra faire la même chose mais pour des automatisations complètes de Claude Code (voire, pourquoi pas, pilotable par une autre IA… Du genre GPT-5.0 qui commande Claude Code…). Oui je sais, j’ai des délires chelous.

Au final, Happy résout un problème concret qu’on est nombreux à avoir. Donc pour tous ceux qui passent leur journée à coder avec Claude, pouvoir suivre et contrôler leurs sessions depuis leur téléphone change clairement les chose. Plus besoin de rester collé à son bureau pour superviser un déploiement, le dev d’un bout de code ou une suite de tests.

Source

LocalSite - Créez des sites web avec l'IA 100% en local sur votre machine

Y’a quelques mois, je me suis amusé à reprendre le projet DeepSite d’Enzostvs et à le transformer complètement pour fonctionner en 100% local. J’ai baptisé ça LocalSite , et ça permet en gros de générer des pages web ou des éléments HTML / CSS / JS à l’aide d’une IA mais en local.

Ça s’appuie donc sur Ollama pour faire tourner les modèles d’IA directement sur votre ordinateur, comme ça, pas de connexion cloud, pas d’abonnement à payer, pas de données qui partent on ne sait où en Chine ou ailleurs. Vous tapez une description de ce que vous voulez, vous sélectionnez un modèle Ollama, et hop, votre site web se génère sous vos yeux.

L’installation est assez simple. Il vous faut d’abord Ollama installé sur votre machine et ensuite, vous récupérez un modèle, par exemple deepseek-r1:7b avec la commande

ollama pull deepseek-r1:7b.

Et une fois Ollama lancé avec

ollama serve

il ne reste plus qu’à installer LocalSite avec npm :

git clone https://github.com/Korben00/LocalSite.git
npm instal
npm run dev

Ensuite, direction localhost:3001 et c’est parti.

Pour l’interface, vous avez donc un éditeur Monaco intégré (le même que dans VS Code), une preview en temps réel qui s’adapte aux différentes tailles d’écran (desktop, tablette, mobile), et la possibilité de basculer entre génération et édition manuelle du code. C’est super pratique pour peaufiner le résultat une fois que l’IA a fait le gros du travail.

Pour ceux qui se demandent quels modèles utiliser, d’après les benchmarks 2025 , CodeLlama 34B reste une référence pour la génération de code HTML/CSS/JavaScript. Mais si votre machine est plus modeste, les versions 7B ou 13B font déjà très bien le job. Qwen2.5-Coder est aussi une excellente alternative, surtout si vous voulez intégrer du code plus complexe dans vos pages. Vous pouvez aussi tenter avec des modèles “Thinking” comme GPT OSS si ça vous chauffe…

Bref, là où DeepSite original nécessite obligatoirement une connexion à Hugging Face et utilise les serveurs API de DeepSeek (donc ça coûte aussi des sous), mon petit LocalSite fait tout en local. Vos données restent chez vous, vous pouvez bosser offline, et surtout, pas de limite d’utilisation. Vous pouvez donc générer autant de sites que vous voulez, tester différents modèles, expérimenter sans compter comme dirait Macron.

L’aspect vie privée n’est pas négligeable non plus car ça permet de prototyper rapidement, et avoir une solution 100% locale évite pas mal de questions juridiques sur la confidentialité des données.

Techniquement, l’architecture repose sur Node.js côté serveur et communique avec Ollama via son API locale. Le code généré est du pur HTML/CSS/JavaScript vanilla, donc compatible partout. Et vous pouvez directement copier-coller le résultat ou télécharger le projet HTML complet (j’ai ajouté un import / export de projets zip). Pas de framework lourd, pas de dépendances obscures, juste du code web standard.

Pour les développeurs qui veulent pousser plus loin, le code source est bien sûr disponible et modifiable. Vous pouvez ajouter vos propres templates, personnaliser les prompts système, ou même intégrer d’autres modèles compatibles avec Ollama.

Il vous faudra quand même un minimum de RAM pour faire tourner les modèles (comptez 8 Go pour les modèles 7B, 16 Go pour les 13B, et 32 Go pour les gros modèles 33B+) mais vu les capacités de génération et l’indépendance totale vis-à-vis du cloud, ça vaut le coup surtout que les modèles dispo dans Ollama progressent rapidement et deviennent de plus en plus optimisés. Je pense par exemple à GPT-OSS.

Bref, j’ai pris une idée cool (DeepSite), et je l’ai réadapté à l’aide de Claude Code et de mes maigres connaissances, pour la rendre accessible et respectueuse de la vie privée et du coup, je trouve ça encore plus cool ^^. Par contre, je suis un garçon assez occupé et je ne suis pas mainteneur de projet open source donc si vous voulez des modifs dedans ou si vous voyez des bugs, faudra vous y coller vous-même ^^.

Si ça vous dit de tester, c’est par ici.

Jujutsu (jj) - quand Google réinvente Git en mode ninja

En ce moment, les développeurs s’extasiaient sur un truc appelé Jujutsu , ou “jj” pour les intimes. Au début, j’ai cru à une énième tentative de réinventer la roue puis j’ai creusé, et j’ai compris pourquoi ça fait autant parler.

Vous connaissez cette frustration avec Git ? Quand vous galérez avec l’index, que vous oubliez de stash vos modifs avant de changer de branche, ou que vous priez pour ne pas foirer votre rebase ? Eh bien, Martin von Zweigbergk, ingénieur chez Google et ancien contributeur Mercurial, a décidé qu’on méritait mieux.

Du coup, il a créé Jujutsu, un système de contrôle de version qui garde tous les avantages de Git en supprimant ses complexités.

Le principe de Jujutsu tient en une phrase : votre répertoire de travail EST un commit. Poh Poh Poh !!

Fini l’index, fini le staging area, fini les acrobaties pour synchroniser vos modifications. À chaque fois que vous sauvegardez un fichier, jj crée automatiquement un nouveau commit avec un hash différent, mais conserve un “change ID” stable qui survit aux réécritures. C’est complètement fou et pourtant ça marche.

Installation de Jujutsu

Pour installer jj, vous avez plusieurs options selon votre OS. Sur macOS avec Homebrew :

brew install jj

Sur Linux, utilisez le gestionnaire de paquets de votre distribution ou installez via Cargo :

# Via Cargo (nécessite Rust)
cargo install --locked jj

# Sur Arch Linux
pacman -S jujutsu

# Sur NixOS
nix-env -iA nixpkgs.jujutsu

Sur Windows, utilisez Winget ou Scoop :

# Via Winget
winget install --id martinvonz.jj

# Via Scoop
scoop bucket add extras
scoop install jujutsu

Une fois installé, configurez votre identité (comme avec Git) :

jj config set --user user.name "Votre Nom"
jj config set --user user.email "[email protected]"

Premiers pas avec Jujutsu

Pour initialiser un nouveau repo jj ou coexister avec un repo Git existant :

# Créer un nouveau repo jj
jj git init myproject

# Coexister avec un repo Git existant
cd existing-git-repo
jj git init --git-repo=.

# Cloner un repo Git avec jj
jj git clone https://github.com/user/repo.git

Concrètement, ça change tout. Plus besoin de git add, plus de git stash avant de changer de contexte, plus de commits temporaires pour sauvegarder votre travail en cours. Jujutsu traite votre copie de travail comme n’importe quel autre commit dans l’historique, ce qui simplifie drastiquement le modèle mental.

Voici les commandes de base pour travailler avec jj :

# Voir l'état actuel (équivalent de git status + git log)
jj st
jj log

# Créer une nouvelle branche de travail
jj new -m "Début de ma nouvelle feature"

# Modifier des fichiers (pas besoin de git add !)
echo "Hello Jujutsu" > README.md
# Les changements sont automatiquement suivis

# Voir les modifications
jj diff

# Créer un nouveau commit basé sur le précédent
jj new -m "Ajout de la documentation"

# Revenir au commit précédent
jj edit @-

# Naviguer dans l'historique
jj edit <change-id></change-id>

Gestion des conflits façon Jujutsu

Le système gère aussi les conflits différemment car là où Git vous force à résoudre immédiatement, jj peut sauvegarder les conflits directement dans l’arbre de commits , sous forme de représentation logique plutôt que de marqueurs textuels. Vous pouvez donc reporter la résolution et vous en occuper quand vous avez le temps. Une fois résolu, jj propage automatiquement la solution aux commits descendants.

# Merger deux branches (les conflits sont sauvegardés si présents)
jj new branch1 branch2

# Voir les conflits
jj st

# Les conflits sont stockés dans le commit, vous pouvez continuer à travailler
jj new -m "Travail sur autre chose pendant que le conflit existe"

# Revenir résoudre le conflit plus tard
jj edit <conflict-commit-id>

# Après résolution manuelle
jj squash # Pour intégrer la résolution</conflict-commit-id>

Manipulation de l’historique

L’outil brille aussi par sa puissance d’annulation. L’operation log dépasse largement les reflogs de Git en gardant une trace atomique de toutes les modifications de références simultanément. Comme ça, vous pouvez expérimenter sans crainte, sachant qu’un simple jj undo peut rattraper n’importe quelle erreur.

# Voir l'historique des opérations
jj op log

# Annuler la dernière opération
jj undo

# Revenir à un état précédent spécifique
jj op restore <operation-id>

# Réorganiser des commits (équivalent de rebase interactif)
jj rebase -s <source> -d <destination>

# Éditer un commit ancien
jj edit <change-id>
# Faire vos modifications
jj squash # Pour intégrer dans le commit actuel

# Split un commit en plusieurs
jj split</change-id></destination></operation-id>

Workflow quotidien avec Jujutsu

Voici un exemple de workflow typique pour une journée de développement :

# Commencer une nouvelle feature
jj new main -m "feat: ajout authentification OAuth"

# Travailler sur les fichiers
vim auth.js
vim config.js

# Pas besoin de git add ! Les changements sont auto-trackés
jj diff # Voir ce qui a changé

# Créer un checkpoint pour continuer
jj new -m "wip: OAuth provider setup"

# Oh, un bug urgent à fix sur main !
# Pas besoin de stash, on switch directement
jj new main -m "fix: correction crash login"

# Fix le bug
vim login.js

# Revenir à notre feature OAuth
jj edit @- # Revient au commit précédent

# Finaliser la feature
jj describe -m "feat: authentification OAuth complète"

# Pusher vers Git
jj git push

Intégration avec Git

Côté compatibilité, c’est du 100% Git. Jujutsu utilise les dépôts Git comme backend de stockage, ce qui signifie que vos collègues peuvent continuer avec Git classique sans même savoir que vous utilisez jj. Et si vous changez d’avis, supprimez juste le dossier .jj et tout redevient normal.

# Synchroniser avec le remote Git
jj git fetch

# Pusher vos changements
jj git push

# Créer une branche Git depuis un change jj
jj branch create ma-feature
jj git push --branch ma-feature

# Importer les changements depuis Git
jj git import

# Exporter vers Git (automatique généralement)
jj git export

Commandes avancées utiles

Selon les retours d’utilisateurs , même les experts Git qui maîtrisent parfaitement les rebases complexes découvrent qu’ils n’ont plus peur de manipuler l’historique. Réordonner des commits, corriger une modification ancienne, jongler avec plusieurs branches non mergées… tout devient trivial avec jj.

# Voir l'historique en mode graphique
jj log --graph

# Chercher dans l'historique
jj log -r 'description(regex:"fix.*bug")'

# Travailler avec plusieurs parents (merge commits)
jj new parent1 parent2 parent3

# Abandonner des changements locaux
jj abandon <change-id>

# Dupliquer un commit ailleurs
jj duplicate <change-id> -d <destination>

# Voir les changements entre deux commits
jj diff -r <from> -r <to>

# Créer un alias pour une commande fréquente
jj config set --user alias.l 'log --graph -r "ancestors(., 10)"'
jj l # Utilise l'alias</to></from></destination></change-id></change-id>

Configuration et personnalisation

Pour personnaliser jj selon vos besoins :

# Définir votre éditeur préféré
jj config set --user ui.editor "code --wait"

# Activer les couleurs dans le terminal
jj config set --user ui.color "always"

# Configurer le format de log par défaut
jj config set --user ui.default-revset "@ | ancestors(@, 10)"

# Voir toute la configuration
jj config list --user

# Éditer directement le fichier de config
jj config edit --user

Le projet évolue rapidement et l’équipe travaille sur plusieurs backends, y compris un natif qui pourrait dépasser Git en performance sur de gros dépôts.

Évidemment, Jujutsu reste expérimental. L’écosystème est plus petit, les intégrations IDE limitées (bien qu’il y ait déjà des extensions VSCode et Vim), et la terminologie différente demande un temps d’adaptation. Mais pour ceux qui cherchent une approche plus intuitive du contrôle de version, ça vaut franchement le détour.

Pour aller plus loin, je vous conseille de parcourir le tutoriel officiel qui couvre des cas d’usage plus avancés, ou de rejoindre le Discord de la communauté où les développeurs sont très actifs et répondent aux questions.

Bref, vous l’aurez compris, jj ne remplace pas Git dans l’immédiat . Il le sublime en gardant la compatibilité totale. C’est une approche intelligente qui permet d’adopter progressivement un workflow plus fluide sans perturber les équipes de dev.

Un grand merci à friendly_0day pour le partage !

HRM - L'IA de 27 millions de paramètres qui écrase GPT-4 sur le raisonnement

Une startup de Singapour vient de prouver qu’en matière IA, David peut encore battre Goliath car avec seulement 27 millions de paramètres selon leur papier de recherche , leur modèle HRM (Hierarchical Reasoning Model) pulvérise des géants comme GPT-4 sur des tâches de raisonnement complexe. Alors comment c’est possible ??? Et bien tout simplement en s’inspirant directement du cerveau humain.

L’équipe de Sapient Intelligence a levé 22 millions de dollars en janvier 2025 et vient enfin de libérer leur code sur GitHub . Leur approche consiste en deux modules qui bossent ensemble comme les régions de notre cortex. Le premier est un module “lent” pour la planification abstraite, et le second, un module “rapide” pour tout ce qui concerne les calculs détaillés.

Et les chiffres de ce qu’ils annoncent donnent le vertige. Selon VentureBeat , HRM délivre des performances jusqu’à 100 fois supérieures aux LLM classiques avec seulement 1000 exemples d’entraînement. Pour vous donner une idée, entraîner HRM sur des Sudoku de niveau professionnel prend environ 2 heures de GPU, et pour le benchmark ARC-AGI super complexe, entre 50 et 200 heures. Une broutille comparée aux ressources astronomiques des modèles de fondation d’OpenAI, de Google, d’Anthropic et j’en passe.

Mais sur le terrain, ça donne quoi ?

Et bien HRM cartonne sur l’ARC-AGI Challenge avec 40,3% de réussite selon l’analyse ARC Prize , alors que des modèles bien plus massifs ramassent. Il résout quasi parfaitement des Sudoku extrêmes et trouve le chemin optimal dans des labyrinthes de 30x30. Tout ça sans pré-entraînement, sans données Chain-of-Thought.

D’ailleurs, en parlant de Sudoku, c’est intéressant de noter que des chercheurs français du cluster IA ANITI à Toulouse avaient déjà publié en 2023 à IJCAI une architecture neuro-symbolique qui fait encore mieux. Avec seulement 22 000 paramètres (oui, 22k, pas 22 millions), leur modèle atteint 100% de réussite sur les Sudoku extrêmes après apprentissage sur 1000 grilles. Et le plus fou c’est qu’avec l’augmentation de données (celle que HRM utilise aussi mais ne mentionne pas trop…), une seule grille leur suffit pour apprendre à jouer parfaitement. Leur approche, détaillée dans ce papier , peut même apprendre à partir d’images de grilles et a été adaptée pour résoudre des problèmes de graphes ou concevoir des molécules .

La magie de ce modèle opère grâce à ce qu’ils appellent la “convergence hiérarchique”. En gros, le module haut niveau cogite lentement sur la stratégie générale pendant que le module bas niveau calcule à toute vitesse les détails. Exactement comme votre cerveau quand vous résolvez un problème complexe : une partie planifie, l’autre exécute. C’est d’ailleurs le principe de base de toutes ces approches neuro-symboliques qui combinent apprentissage profond et raisonnement logique, une voie que la recherche européenne explore depuis plusieurs années.

Cette approche ouvre des perspectives énormes pour les entreprises mais également dans le médical, où Sapient teste déjà HRM sur des diagnostics de maladies rares où les données sont éparses mais la précision critique. En climatologie, ils atteignent un joli 97% de précision sur les prévisions saisonnières.

L’aspect le plus dingue c’est que contrairement aux mastodontes verrouillés et payants, HRM est complètement open-source. Le code tourne sur votre laptop, et vous pouvez le modifier, l’améliorer. Même philosophie chez les chercheurs d’ANITI qui mettent aussi leurs travaux en accès libre, permettant à toute la communauté de bénéficier de ces avancées.

Alors faut-il vraiment des centaines de milliards de paramètres quand l’intelligence peut émerger de structures plus compactes mais mieux organisées ? HRM suggère qu’on a peut-être fait fausse route en privilégiant la taille brute à l’efficacité architecturale. Et les travaux antérieurs en neuro-symbolique, comme ceux d’ANITI avec leurs 22k paramètres, montrent qu’on peut aller encore beaucoup plus loin dans la compacité tout en gardant, voire en améliorant, les performances.

Du coup, les géants de la tech vont-ils revoir leur copie pour adopter une approche semblable ? On verra bien ! En tout cas, que ce soit avec HRM ou les architectures encore plus légères développées en Europe, une chose est claire : la course aux milliards de paramètres n’est peut-être pas la seule voie vers l’AGI.

Un grand merci à Lorenper et Thomas pour l’info !

Source

Port Kill - L'app macOS qui règle ses comptes avec les ports squattés

Vous la connaissez cette fatigue de quand vous lancez votre serveur de dev et que ce satané message d’erreur EADDRINUSE vous annonce que le port 3000 est déjà utilisé ? Et bien moi oui, et visiblement je ne suis pas le seul puiqu’un développeur de talent a décidé que c’était la goutte d’eau et a créé Port Kill , une petite app macOS qui vit tranquillement dans votre barre de menu et qui surveille les ports ouverts comme le vigile de Franprix vous surveille.

Comme ça, au lieu de jouer au jeu du chat et de la souris avec lsof, netstat et kill dans votre terminal, Port Kill scanne automatiquement tous les ports entre 2000 et 6000 toutes les 5 secondes et vous dit ce qui est ouvert. Alors pourquoi cette plage ? Hé bien parce que c’est là que la plupart d’entre nous faisons tourner nos serveurs de développement. React sur 3000, Vue sur 8080, votre API custom sur 5000… Vous voyez le tableau.

Ce qui est sympa avec Port Kill, c’est l’interface. L’icône dans la barre de menu change de couleur selon le nombre de processus détectés. Vert quand tout est clean, rouge quand vous avez entre 1 et 9 processus qui traînent, et orange quand ça part en cacahuète avec plus de 10 processus. Un clic sur l’icône et vous avez la liste complète avec la possibilité de tuer chaque processus individuellement ou de faire table rase d’un coup.

Techniquement, c’est du solide puisque c’est écrit en Rust (hé oui parce qu’en 2025, si c’est pas du Rust, c’est has-been), l’app utilise les commandes système lsof pour détecter les processus. Et la stratégie de kill de l’outil est plutôt intelligente puisqu’il fait d’abord un SIGTERM poli pour demander gentiment au processus de se barrer, et si au bout de 500ms ce dernier fait le têtu, PAF, un SIGKILL dans les dents. C’est la méthode douce-ferme, comme quand vous demandez à votre chat de descendre du clavier.

Le contexte, c’est qu’on a tous galéré avec ça. L’erreur EADDRINUSE est un classique du dev web. Vous fermez mal votre serveur avec Ctrl+C, ou pire, vous fermez juste la fenêtre du terminal, et hop, le processus continue de tourner en arrière-plan comme un zombie. Sur macOS, c’est encore plus vicieux depuis Monterey avec AirPlay qui squatte le port 5000 par défaut.

Il existe d’autres solutions, bien sûr. Par exemple, Killport est autre un outil en ligne de commande cross-platform écrit aussi en Rust qui fait un job similaire. kill-my-port est un package npm qui fait la même chose. Mais ces outils nécessitent de passer par le terminal à chaque fois. Port Kill, lui, est toujours là, discret dans votre barre de menu, prêt à dégainer.

L’installation est simple : vous clonez le repo GitHub, un petit cargo build --release si vous avez Rust installé, et vous lancez avec ./run.sh. L’app tourne en tâche de fond, consomme quasi rien en ressources, et met à jour son menu contextuel toutes les 3 secondes. Pas de fenêtre principale, pas de configuration compliquée, juste l’essentiel.

Pour les puristes du terminal, oui, vous pouvez toujours faire lsof -ti:3000 | xargs kill -9. Mais franchement, avoir une interface graphique pour ce genre de tâche répétitive, c’est pas du luxe. Surtout quand vous jonglez entre plusieurs projets et que vous ne vous rappelez plus quel port utilise quoi.

Le seul bémol, c’est que c’est limité à macOS pour l’instant donc les développeurs sur Linux et Windows devront se contenter des alternatives en CLI. Mais bon, vu que le code est open source, rien n’empêche quelqu’un de motivé de faire un portage.

Voilà, donc si comme moi vous en avez marre de cette danse répétitive pour trouver et tuer le processus qui squatte votre port, Port Kill mérite que vous y jetiez un oeil.

❌