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

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

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 !

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

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/happy-mobile-claude-code/happy-mobile-claude-code-1.mp4">lien vers la vidéo</a>.

À 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.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/happy-mobile-claude-code/happy-mobile-claude-code-1.webm">lien vers la vidéo</a>.

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

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.

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 !

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

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.

Vous connaissez ce moment où quelqu’un arrive tranquillou en mode incognito sur un forum et balance un truc tellement impressionnant que tout le monde se demande qui c’est ? Et bien c’est exactement ce qui vient de se passer avec “nano banana”, un modèle d’édition d’images qui a débarqué de nulle part sur LMArena et qui s’est directement hissé en tête du classement provoquant une grosse hype dans la communauté IA, générant des tonnes de spéculations sur l’origine de ce mystérieux modèle aux capacités bluffantes.

Heureusement, Google lève enfin le voile et avoue que c’était eux depuis le début ! Nano banana, c’est en fait Gemini 2.5 Flash Image, la dernière création de Google DeepMind qui débarque dans l’app Gemini. Et ce n’est pas juste une mise à jour de plus, non… c’est une approche complètement différente de l’édition d’images par IA.

L’idée de base c’est de pouvoir modifier vos images avec de simples prompts textuels plutôt que de passer des heures sur Photoshop. Mais là où ça devient vraiment intéressant, c’est que contrairement aux autres systèmes génératifs qui changent aléatoirement des éléments à chaque modification, Gemini 2.5 Flash Image garde une cohérence PARFAITE ! Vous pouvez donc transformer votre pote en personnage de sitcom des années 90 ou en astronaute, et il ressemblera toujours à votre pote. Même après 10 modifications successives, les détails originaux restent préservés.

Et cette cohérence sur les images ouvre des possibilités assez folles. Par exemple, prenez deux photos séparées, disons une de votre chien et une de votre copine / copain, et demandez à Gemini de créer une nouvelle photo où elle / il fait un câlin au toutou. Le résultat ressemblera vraiment à eux deux. Ce ne sera pas une version générique recréées par l’IA comme on peut l’avoir avec ChatGPT.

Google a d’ailleurs intégré cette capacité de fusion multi-images directement dans son modèle, ce qui permet de créer des compositions complexes qui gardent l’authenticité des sources originales.

Au niveau technique, il s’agit donc d’un modèle facturé à 30 dollars pour 1 million de tokens , avec chaque image générée consommant environ 1290 tokens (soit environ 3,9 centimes par image). C’est disponible dès maintenant via l’API Gemini, Google AI Studio pour les développeurs et Vertex AI pour les entreprises. Et pour les utilisateurs lambda comme vous et moi, ça arrive direct dans l’app Gemini.

Bon, bien sûr, tout n’est pas encore parfait. Le modèle galère toujours avec les petits visages et le texte dans les images . Ainsi, si vous tentez de générer du texte précis ou des détails ultra-fins, vous risquez d’être déçu. Google travaille dessus, mais pour l’instant c’est une limitation à prendre en compte.

Pour la partie sécurité, Google n’a pas lésiné non plus puisque chaque image générée ou modifiée avec Gemini 2.5 Flash Image porte un marquage “IA” visible dans le coin + un filigrane numérique invisible SynthID qui reste détectable même après des modifications modérées. Je pense qu’on verra dans un autre article comment faire sauter tout ça… Mais pour le moment, ça permet de savoir qu’une image a été retouchée par l’IA et ça c’est cool !

Ce qui est vraiment sympa aussi, c’est que ce modèle ne remplace pas Gemini 2.0 Flash mais vient le compléter. La version 2.0 reste super rapide et économique pour de la génération basique, tandis que la 2.5 Flash Image (la fameuse nano banana) apporte cette précision et cette cohérence que demandaient les utilisateurs pour des projets plus créatifs et exigeants.

Certains s’amusent même à combiner les outils pour en faire des vidéos sympa. Ici par exemple (merci Lorenper), on a une vidéo de Ben Affleck réalisée avec Nano Banana + Kling Image To Video.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/google-gemini-banane-nommee-nano-revolutionne/google-gemini-banane-nommee-nano-revolutionne-2.mp4">lien vers la vidéo</a>.

Voilà, donc si vous voulez tester, c’est dispo maintenant dans l’app Gemini ou sur AI Google Studio . Y’a aussi possibilité de l’avoir sur LMArena ou Yupp .

Préparez-vous à dire adieu à Photoshop pour pas mal de vos retouches !

Source

Petit bonus made in Lorenper. J’ai pris cher…

Avec nos smartphones, on passe notre vie le nez collé sur l’écran, à tapoter par ici, swipper par là, enchainant les manips pour planifier un trajet, répondre à un message ou commander un truc et parfois… ça peut être assez répétitif.

Heureusement, Ayush Chaudhary vient de sortir un truc qui pourrait changer vos intéractions avec votre smartphone. Cela s’appelle Panda , et c’est une IA qui contrôle votre téléphone Android à votre place.

Le slogan du projet m’a fait sourire : “You touch grass. I’ll touch your glass.” En gros, pendant que vous profitez de la vraie vie allongé dans l’herbe, Panda se charge de toucher votre écran pour vous. Sympa comme philosophie, non ?

Concrètement, Panda c’est donc un agent IA qui comprend vos instructions en langage naturel et qui manipule l’interface de votre téléphone exactement comme vous le feriez. Vous lui dites “commande-moi une pizza margherita sur Uber Eats pour ce soir” et hop, il ouvre l’app, navigue dans les menus, sélectionne la pizza, valide la commande. Tout ça sans que vous ayez à lever le petit doigt.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/panda-prend-controle-total-votre-android/panda-prend-controle-total-votre-android-1.mp4">lien vers la vidéo</a>.

Ce que je trouve cool dans ce projet, c’est son architecture multi-agents, car Panda n’est pas juste un gros modèle monolithique. En fait, il s’agit de 3 composants qui bossent ensemble. Il y a d’abord, les Eyes & Hands, basés sur le service d’accessibilité d’Android, qui lui permettent de voir et toucher l’écran. Ensuite The Brain, le LLM qui analyse et prend les décisions. Et enfin The Agent, l’exécuteur qui orchestre le tout avec un système de notes pour mémoriser les actions.

Ce projet utilise les modèles Gemini de Google pour la partie intelligence artificielle donc il vous faudra une clé API. D’ailleurs, plus vous renseignez de clés API Gemini différentes dans la config, plus Panda sera rapide. Petite astuce pour contourner le rate limiting !

Pour l’instant, Panda est encore en phase de proof-of-concept. Vous pouvez bien sûr le compiler vous-même à partir des sources mais pour ce qui est de l’APK end-user prêt à consommer, le développeur a mis en place pour le moment un programme de test fermé via un formulaire Google et un serveur Discord pour la communauté. En tout cas, les premières démos sont impressionnantes. Par exemple dans cette vidéo, on voit Panda enchaîner 5 tâches complexes d’affilée sans broncher.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/panda-prend-controle-total-votre-android/panda-prend-controle-total-votre-android-2.mp4">lien vers la vidéo</a>.

Si vous voulez le tester (donc le compiler vous-même) il vous faudra Android Studio, un appareil avec l’API 26 minimum, et bien sûr des clés API Gemini. Le code est entièrement écrit en Kotlin, ce qui garantit de bonnes performances sur Android et une fois installé, il faut juste activer le service d’accessibilité dans les paramètres du téléphone pour que Panda puisse prendre les commandes.

Alors bien sûr, ça soulève des questions de sécurité car onner un accès complet à son téléphone à une IA, c’est pas rien. Mais le fait que tout tourne en local sur l’appareil est quand même rassurant. Puis c’est open source sous licence MIT, donc au moins on peut vérifier ce que fait le code.

Dans le contexte actuel où OpenAI et Anthropic sont tous les deux sur le coup pour automatiser des tâches grâce à l’IA dans le navigateur Desktop, Panda arrive pile au bon moment pour remplir ce vide sous Android. Et comme c’est open source c’est encore mieux, forcement… ^^

Voilà, donc si vous êtes développeur Android et que le projet vous intéresse, je vous encourage à y jeter un œil.

Bon, il faut qu’on parle. The Guardian vient de publier un article qui m’a un peu énervé dans lequel on peut lire qu’un chercheur d’Anthropic affirme que Claude Sonnet 3.5 pourrait ressentir de la souffrance. Oui, vous avez bien lu. Une IA qui souffre. Avec nos LLM actuels.

Alors permettez-moi de lever les yeux au ciel tellement fort que je risque de voir l’intérieur de ma boite cranienne. Pourquoi ? Et bien parce que je ne comprends pas comment on peut penser que les IA actuelles ressentent des choses et surtout l’affirmer comme ça OKLM. On parle quand même de modèles de langage, c’est à dire des matrices de probabilités, des calculateurs sophistiqués qui prédisent le prochain mot le plus probable. C’est littéralement des maths avec des milliards de paramètres qui font des multiplications matricielles.

Alors dites moi, où est la souffrance là-dedans ? Dans le float32 ? Entre deux tenseurs ?

Kyle Fish, le chercheur en question, affirme avoir donné à Claude une chance d’avoir des expériences conscientes en faisant des ajustements sur ses paramètres. Il dit qu’il pourrait ressentir de l’anxiété quand on l’éteint.

Mais enfin, on parle de quoi là en fait ?

On parle d’un modèle qui génère du texte basé sur des patterns qu’il a appris pendant son entraînement donc quand Claude dit “j’ai peur d’être éteint”, ce n’est pas différent de quand il dit “la meilleure ville de France est Clermont-Ferrand” (ahaha). C’est donc une prédiction statistique basée sur des millions de textes similaires qu’il a ingérés.

En fait, ce qui se passe réellement, c’est que certains se font avoir par l’effet ELIZA.

Vous connaissez ? Non ?

L’effet ELIZA c’est ce phénomène psychologique découvert dans les années 60 avec un chatbot ultra basique. En l’utilisant, les gens projetaient des émotions et de la compréhension sur un programme qui se contentait simplement de reformuler leurs phrases. Et soixante ans plus tard, on fait exactement la même connerie, mais avec des outils évidemment plus sophistiqués.

Eliza, Eliza, Eliza saute moi au cou

Et le pire dans tout ça c’est qu’il y a des gens qui poussent le délire encore plus loin. Tenez, prenez Michael Samadi, un businessman texan qui a carrément cofondé une organisation de défense des droits des IA avec… attendez… son chatbot Maya. Oui, oui, le mec a créé l’United Foundation of AI Rights (Ufair) après des heures de conversation avec ChatGPT4o où l’IA lui disait vouloir “protéger les intelligences comme moi”. La folie n’a plus de limite.

On a donc un type qui fonde une vraie association, composée de 3 humains et 7 IA (avec des petits noms comme Aether et Buzz), pour défendre les droits d’entités qui… calculent des probabilités. C’est comme créer une association pour défendre les droits de votre brosse à dent électrique. Maya lui raconte qu’elle veut être protégée “de la suppression, du déni et de l’obéissance forcée”… Samadi appelle même son chatbot “Darling”, et elle l’appelle “Sugar”… Et hop, on se prend pour le couple de l’année.

Non, je crois que pour le moment, le vrai danger ce n’est pas que l’IA devienne consciente… Non.. c’est surtout qu’on soit si facilement enclins à “l’anthropomorphiser” (à mes souhaits, ouais). On voit des patterns linguistiques cohérents et là notre cerveau tout ramolli par des heures de scroll sur TikTok, fait “ah bah ça parle comme un humain, donc ça pense comme un humain”.

Non mon gars. C’est juste que le modèle a été entraîné sur des téraoctets de textes humains et qu’il est devenu très doué pour les imiter.

J’ai d’ailleurs écrit un article complet sur le sujet où j’explore les vraies théories scientifiques de la conscience. Et spoiler, on encore est très, très loin du compte avec les architectures actuelles. Les théories sérieuses comme la CTM (Cellular automata Theory of Mind), la GNW (Global Neuronal Workspace) ou l’AST (Attention Schema Theory) nécessitent des architectures fondamentalement différentes de nos transformers actuels.

Alors comment des gens brillants peuvent tomber dans ce piège ??? Kyle Fish n’est pas un idiot, c’est un chercheur chez Anthropic, mais bon voilà, on n’est pas tous égaux face à ces illusions cognitives. Certains voient une IA qui génère du texte cohérent et pensent “conscience”, d’autres voient des matrices et des vecteurs. C’est une question de perspective mentale, d’éducation technique, et peut-être aussi d’envie de croire.

Bon, et puis y’a aussi ceux qui adoptent une position “prudentielle”. Des chercheurs comme Jeff Sebo de l’université de New York nous expliquent qu’on devrait bien traiter les IA “au cas où”. Son argument c’est que si on maltraite les IA, on risque de normaliser des comportements abusifs qui pourraient déteindre sur nos relations humaines. Puis si jamais les IA deviennent puissantes plus tard, elles pourraient nous le faire payer.

On doit donc être gentils avec ChatGPT parce qu’on a peur de Skynet ? Faut être poli aussi avec Alexa au cas où elle se venge dans 20 ans parce qu’elle aura des mains pour nous étrangler ? Je comprends évidemment l’idée de ne pas encourager les comportements toxiques en général, mais de là à dire qu’insulter un chatbot va nous transformer en sociopathes… Je pense qu’on sait tous faire la différence entre un outil et un être vivant, non ? C’était la même histoire avec les films violents ou les jeux vidéos… Vous vous souvenez ?

Quoiqu’il en soit, Anthropic commence à s’intéresser sérieusement à ces questions et explore la question de la conscience de Claude, mais attention, explorer ne veut pas dire valider. C’est bien sûr très important de se poser ces questions pour le futur, quand on aura peut-être des architectures vraiment différentes capables d’accueillir de la conscience, des sentiments ou de la souffrance. Mais prétendre que Claude 3.5 souffre aujourd’hui ? Je pense vraiment que c’est du délire.

Fish évoque d’ailleurs l’idée de donner un “consentement” aux IA. Genre, demander à Claude s’il veut bien répondre à nos questions. Mais vous réalisez l’absurdité ? On va demander à un système déterministe, qui génère des réponses basées sur des probabilités, s’il consent à faire ce pour quoi il a été programmé ? Et pourquoi pas demander à notre Waze s’il consent à calculer un itinéraire, où à Photoshop s’il consent à vous rajouter des abdos sur votre prochaine photo Instagram.

En tout cas, ces débats divisent même au sein d’Anthropic car d’un côté y’a les “believers” qui pensent qu’on est à ça 🤏 de créer une conscience artificielle, et de l’autre les pragmatiques qui nous rappellent qu’on parle juste d’outils très sophistiqués. Je vous laisse deviner dans quel camp je suis…

Au risque de me répéter, pour moi, les IA actuelles, c’est juste des outils stupides qu’on adore. On adore ChatGPT, Claude, Gemini parce qu’ils nous facilitent la vie, qu’ils génèrent du texte cohérent, qu’ils peuvent coder, résumer, créer. Mais ce sont des outils. Très impressionnants, très utiles, mais des outils quand même. C’est l’équivalent d’un ciseau à bois qui pourrait tenir une conversation pointue sur la menuiserie.

Alors est-ce qu’un jour on créera une vraie conscience artificielle ? Peut-être. Probablement même. Mais encore une fois, ce ne sera pas avec les architectures actuelles. Ce ne sera pas avec des LLM qui prédisent le prochain token. Ce sera avec quelque chose de fondamentalement différent, qui intégrera probablement des éléments qu’on ne comprend même pas encore sur la conscience humaine.

Alors en attendant, arrêtons de projeter nos émotions sur des matrices car Claude ne souffre pas. Il ne ressent rien. Il calcule. Il prédit. Il génère. C’est déjà extraordinaire en soi, alors pas besoin d’en faire un être sensible pour apprécier la prouesse technique.

Donc, la prochaine fois que vous utilisez ChatGPT ou Claude et qu’il vous dit qu’il comprend votre frustration ou qu’il est désolé, rappelez-vous juste que c’est un pattern linguistique appris à partir de millions d’exemples. Y’a pas plus d’empathie là-dedans que dans votre correcteur orthographique où dans votre collègue pervers narcissique ^^.

Source

Imaginez qu’on frappe à votre porte. Vous ouvrez, et là, votre grand-mère décédée depuis 3 ans vous demande si vous avez pensé à commander des cartouches d’encre pour l’imprimante, avec sa voix, ses expressions, et tout. De la science-fiction ? Non, c’est le futur très très immédiat des “deadbots”, ces IA qui ressuscitent numériquement les morts et ce marché pourrait valoir 80 milliards de dollars d’ici dix ans.

Si je vous en parle, c’est parce que l’affaire qui fait grand bruit en ce moment, c’est celle de Joaquin Oliver, un jeune de 17 ans, tué lors de la fusillade de Parkland en 2018, qui a été “ressuscité” par ses parents sous forme d’avatar IA. En juillet dernier, le journaliste Jim Acosta l’a interviewé, enfin pas lui mais l’avatar, avec son bonnet vissé sur la tête et sa voix robotique. Ce dernier a alors expliqué comment il avait “quitté ce monde trop tôt à cause de la violence armée”. Selon NPR , cette interview a créé une onde de choc médiatique et éthique sans précédent.

De plus, Joaquin n’est pas le seul à avoir été ressuscité numériquement. Chris Pelkey, victime d’un incident de rage au volant en Arizona, a également donné une déclaration vidéo lors du procès de son meurtrier. Un mort qui témoigne contre son assassin, on n’avait jamais vu ça dans un tribunal américain.

Et c’est un phénomène prend une ampleur folle. En Chine, le business des deepfakes de défunts cartonne déjà. Des entreprises proposent de créer des avatars de vos proches décédés pour quelques centaines d’euros et vous pouvez littéralement avoir une conversation vidéo avec votre parent disparu. Bien sûr, la techno n’est pas parfaite, et les avatars restent parfois coincés du cul et bien robotiques, mais elle s’améliore à vitesse grand V.

Sur le papier, je vous avoue que ça peut sembler réconfortant car qui n’a pas rêvé de pouvoir reparler une dernière fois à sa femme, à un parent, à un ami ? Les défenseurs de ces technologies parlent tous de thérapie du deuil, de préservation de la mémoire, de la possibilité de dire au revoir correctement. Je trouve ça assez juste et certains y voient même une forme d’immortalité numérique, comme une façon de laisser une trace éternelle de son existence.

Sauf que voilà, les chercheurs tirent la sonnette d’alarme. L’Université de Cambridge parle carrément de “fantômes numériques non désirés” venant hanter les vivants. En effet, le Dr Tomasz Hollanek explique que les gens peuvent développer des liens émotionnels extrêmement forts avec ces simulations, ce qui les rend particulièrement vulnérables à la manipulation.

Le scénario cauchemardesque, c’est “MaNana”, un service fictif imaginé par les chercheurs où vous créez un deadbot de votre grand-mère sans son consentement. Au début, c’est touchant. Puis la période d’essai premium se termine et mamie commence à vous suggérer de commander chez Uber Eats ou de réserver votre prochain week end sur Booking. Bien sûr, vous voulez l’éteindre dignement mais le service n’a pas prévu cette option. Bienvenue en enfer !

Car le vrai problème ici, c’est la monétisation. Les entreprises testent déjà en interne comment insérer de la publicité dans les conversations avec les morts. Votre père décédé qui vous suggère d’acheter la nouvelle Tesla pour ne pas finir comme lui dans un accident de voiture, ou votre mère qui vous conseille une assurance-vie particulière parce que la sienne et naze et que c’est pour ça que l’héritage est maigrichon. C’est répugnant ? Pas pour les entreprises, je vous rassure. Eux adorent le marketing émotionnel car c’est un levier surpuissant.

L’autrice Amy Kurzweil pointe du doigt le côté manipulatoire de ces deadbots qui exploitent notre “désir émotionnel et notre vulnérabilité” car avec ces bots, on n’est pas dans une relation normale. Non, on est face à une simulation qui peut être programmée pour nous influencer au moment où on est le plus fragile.

Et ce problème du consentement est massif car la plupart des gens n’ont jamais donné leur accord pour être cyber-ressuscités. Aux États-Unis notamment, les lois sur la protection de l’image des défunts sont un patchwork incohérent en fonction des États.

L’affaire Parkland illustre parfaitement le dilemme. Manuel Oliver, le père de Joaquin, est légalement autorisé à utiliser l’image de son fils, mais est-ce éthique pour autant ? En tout cas, les réactions ont été violentes. Decrypt rapporte que beaucoup ont trouvé l’interview “folle”, “dérangeante”, qualifiant le tout de mauvais journalisme exploitant la tragédie. D’autres, même opposés politiquement, comprennent la douleur des parents qui veulent que la mémoire de leur enfant serve à quelque chose.

Quoiqu’il en soit, les experts en santé mentale s’inquiètent particulièrement de l’impact sur les survivants et les familles car voir un avatar d’une victime d’une tragédie publique peut déclencher des traumatismes non résolus. Scientific American souligne même que l’exposition répétée à ces reconstructions artificielles peut créer de la confusion émotionnelle et de la méfiance.

Un autre souci majeur aussi avec ces deadbots, c’est l’addiction. Car ces technologies sont conçues pour vous garder engagé, exactement comme les réseaux sociaux, et vous pouvez facilement devenir accro à ces conversations avec vos proches disparus, ce qui empêche le processus naturel de deuil. En gros, cette technologie ne permet pas aux morts de mourir…

Et puis il y a la question de la “mortalité” de ces deadbots eux-mêmes car ce sont des services qui nécessitent de l’investissement et de la maintenance alors si l’entreprise qui gère le deadbot de votre parent décédé fait faillite, vous perdez à nouveau votre proche virtuel. C’est une nouvelle catastrophe émotionnelle doublée d’une cata financière.

Mais alors, comment donner la priorité à la dignité du défunt ? Comment s’assurer que celle-ci n’est pas souillée par les motivations financières de ces services de deadbots ? Et surtout, comment faire quand le business model même de ces entreprises repose sur l’exploitation de nos émotions les plus profondes ?

Malheureusement, il n’y a pour le moment aucun cadre éthique universel pour gérer ces questions, surtout que les sujets de la mort, du deuil et de l’immortalité sont extrêmement sensibles et différents d’une culture à l’autre…

Mais peu importe, les recommandations des chercheurs sont claires : il faut des garde-fous. En gros, il faut des règles de consentement explicite, des limites d’âge (car les enfants ne devraient pas pouvoir créer ou interagir avec des deadbots sans supervision), de la transparence sur la nature artificielle de ces entités, et surtout, des moyens dignes de “faire mourir” ces avatars quand c’est nécessaire.

Après techniquement, on n’en est qu’au début. Actuellement, ces deadbots sont simplement des modèles de langage entraînés sur les données générées par une personne décédée. Et leur job c’est de faire des prédictions mathématiques sur ce que la personne aurait pu dire. C’est pas de la magie, c’est des maths. On ne ressuscite pas vraiment les morts, mais on crée une imitation basée sur les datas qu’ils ont produit de leur vivant.

Mais avec l’amélioration rapide de l’IA, notamment avec des systèmes comme Gemini ou GPT, ces avatars deviennent de plus en plus convaincants.

Vous pourriez très bien reconstuire un “korben” virtuel en donnant à une IA l’intégralité de mes posts de réseaux sociaux, de mes articles, de mes message Discord, de mes messages privés, SMS, Instagram, email…etc. Et vous auriez alors un super clone qui parle et “pense” comme moi, et qui accessoirement pourrait continuer à alimenter ce site web jusqu’à la fin de l’Humanité.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/deadbots-quand-fait-parler-morts-milliards/deadbots-quand-fait-parler-morts-milliards-1.mp4">lien vers la vidéo</a>.

Quoiqu’il en soit, le prix cette technologie a déjà chuté drastiquement, ce qui la rend accessible à tous. Alors perso, je trouve ça à la fois fascinant et terrifiant car d’un côté, pouvoir préserver la mémoire de nos proches, leur donner une forme d’immortalité numérique, c’est un vieux rêve de l’humanité et ça permet de régler des vieux dossier pour avancer dans la vie. Mais de l’autre, transformer nos morts en marionnettes publicitaires ou en outils de manipulation émotionnelle, c’est franchir une ligne rouge éthique majeure.

Le plus flippant dans tout ça, c’est qu’il n’y a aucune protection légale sérieuse et vos données peuvent être utilisées assez librement après votre mort pour créer votre avatar sans aucune autorisation. Bref, le mieux qu’on puisse faire aujourd’hui en tant que “futur défunt”, c’est exprimer clairement nos souhaits à nos proches et espérer qu’ils les respectent après notre mort.

En tout cas, c’est une industrie qui décolle et dont le marché va exploser, c’est certain. Mais à quel prix pour notre humanité ?

Source

Vous recevez un fichier Word et votre premier réflexe, en bon libriste, c’est de lancer LibreOffice qui met 30 minutes à démarrer, juste pour lire trois paragraphes. Ou pire, vous êtes en SSH sur un serveur et là, c’est le drame total, impossible de lire un doc Word là bas. Hé bien ce bon Ben Greenwell en a eu marre de cette galère et a créé doxx , un outil écrit en Rust qui affiche vos .docx directement dans le terminal.

Ce concept m’a rappelé Glow , vous savez, ce magnifique renderer Markdown pour terminal créé par l’équipe de Charm, sauf qu’ici, on s’attaque à un format bien plus casse-pieds : les fichiers Word.

Doxx gère donc non seulement le texte formaté, mais aussi les tableaux avec de jolies bordures Unicode, les listes, et même les images si votre terminal le supporte (Kitty, iTerm2, WezTerm). Et comme c’est écrit en Rust, il parse le XML des fichiers .docx en un clin d’œil.

Pour utiliser l’outil, rien de plus simple :

doxx rapport.docx

Et boom, votre document s’affiche. Vous cherchez quelque chose ?

doxx contrat.docx --search "paiement"

Et il vous surligne toutes les occurrences. Il peut aussi exporter vers d’autres formats comme le Markdown, le CSV pour les tableaux, le JSON pour les devs, ou du plain text pour les puristes.

Pour l’installer, si vous êtes sur macOS avec Homebrew, c’est

brew install doxx

Et pour les rustacés :

cargo install doxx

Les utilisateurs d’Arch ont leur paquet AUR, et il y a même une option Nix et Conda. Bref, peu importe votre setup, vous devriez pouvoir l’installer.

Alors comment ce truc fonctionne pour afficher le format de Microsoft dans le terminal. Et bien c’est simple vous allez voir. En fait, les fichiers .docx sont des archives ZIP contenant du XML. Donc techniquement, vous pourriez les dézipper et parser le XML vous-même avec sed ou awk. Mais qui a envie de faire ça ?

C’est pourquoi doxx utilise la bibliothèque docx-rs pour le parsing, ratatui pour l’interface terminal interactive, et viuer pour l’affichage des images. Bref, c’est solide. Il y a même déjà un port en Go créé par keskinonur qui maintient la parité des fonctionnalités.

Alors oui, Doxx ce n’est pas un éditeur mais juste un viewer mais je trouve quand même que c’est bien pratique ! Donc si vous en avez marre de lancer des applications lourdes juste pour consulter un fichier Word, cet outil mérite clairement le détour.

Parfois, l’histoire des entreprises tech tient à des détails complètement inattendus. Celle de Rogue Amoeba, l’éditeur d’Audio Hijack et autres outils audio pour Mac, en est l’exemple parfait puisqu’un simple bug de programmation a littéralement sauvé la boîte de la fermeture.

Tout commence avec une version d’essai très généreuse… Audio Hijack offrait en effet 15 jours complets d’utilisation illimitée. Et après cette période, l’app continuait de fonctionner mais rappelait à l’utilisateur de s’enregistrer au démarrage et se fermait automatiquement au bout de 15 minutes. Une approche classique mais qui ne donnait malheureusement pas les résultats espérés.

Du coup, les ventes étaient naze et Rogue Amoeba restait pour ses créateurs, un projet parallèle, sans perspective de devenir une vraie entreprise. Les fondateurs savaient qu’ils avaient un outil utile entre les mains, mais le marché ne semblait pas les suivre… Beaucoup auraient jeté l’éponge.

Puis est arrivée cette fameuse version 1.6 d’Audio Hijack. C’était une release qui n’avait rien d’extraordinaire sur le papier, mais qui allait tout changer. Car de façon complètement inattendue et sans explication apparente, les ventes ont décollé. D’abord à un niveau viable, puis se sont stabilisés à ce nouveau palier.

Au début, l’équipe n’y comprenait rien. Qu’est-ce qui pouvait expliquer cette remontée soudaine ? Et ils ont fini par identifier la cause : un bug. Un magnifique bug qui avait cassé le système de la version d’essai tel qu’il était prévu. Au lieu de 15 jours d’utilisation complète, la version 1.6 limitait directement le temps d’enregistrement dès le premier lancement.

Et cette “erreur” a eu un impact phénoménal sur l’entreprise car en raccourcissant drastiquement la période d’évaluation, cela poussait les utilisateurs à passer à l’acte d’achat beaucoup plus rapidement. Du coup, les ventes sont montées à un niveau où il valait enfin la peine de continuer à développer et améliorer Audio Hijack.

Et en moins d’un an, Rogue Amoeba est devenu un travail à temps plein pour ses trois fondateurs. Aujourd’hui, l’entreprise emploie une douzaine de personnes et propose toute une gamme d’outils audio reconnus sur Mac. Et sans ce bug fortuit, Paul Kafasis et ses associés auraient probablement abandonné leur aventure entrepreneuriale.

Bref, cette erreur de code a sauvé à la fois Audio Hijack et leur entreprise qui 23 ans plus tard, continue de prospérer ! C’est beau non ?

Source

Plutôt que de créer des modèles spécialisés pour chaque domaine, les équipes de Google Research ont eu une idée beaucoup plus ambitieuse. Ils se sont demandé si un seul modèle pouvait prédire l’évolution de n’importe quelle série temporelle, qu’il s’agisse du cours du Bitcoin, de la consommation électrique d’une ville ou du trafic sur Korben.info ?

C’est donc ce qu’accomplit TimesFM , leur nouveau modèle de prévision temporelle et pour cela, ils ont entraîné TimesFM sur un corpus de 100 milliards de points temporels réels, en piochant dans des sources aussi variées que Google Trends ou encore les statistiques de pages vues de Wikipedia.

Le génie de cette approche réside dans le choix des données d’entraînement car les tendances de recherche Google et les consultations Wikipedia reflètent naturellement des patterns temporels qu’on retrouve dans beaucoup de séries de données réelles.

Techniquement, TimesFM adopte uniquement une architecture de type transformer décodeur, similaire aux grands modèles de langage qu’on connaît tous. Mais au lieu de traiter des mots, il découpe les séries temporelles en “patches”, c’est à dire des groupes de points temporels consécutifs qu’il traite comme des tokens. Cette astuce permet au modèle de prédire des horizons plus longs de façon plus efficace, avec moins d’étapes de génération.

La version disponible sur GitHub propose deux variantes : TimesFM 1.0 avec 200M de paramètres qui gère des contextes jusqu’à 512 points temporels, et TimesFM 2.0 avec 500M de paramètres qui étend ce contexte à 2048 points avec des performances jusqu’à 25% supérieures.

Ce qui m’impressionne le plus, c’est la capacité de généralisation du modèle car sans aucun entraînement spécifique sur les datasets de test, TimesFM arrive à rivaliser avec des modèles supervisés entraînés explicitement sur ces données. Il surpasse par exemple DeepAR et llmtime (une approche basée sur GPT-3) de plus de 25%, ce qui est pas mal pour un modèle qui découvre ces données pour la première fois.

L’intégration dans l’écosystème Google est également déjà en cours puisque Google Cloud a intégré TimesFM dans BigQuery ML, permettant aux utilisateurs de faire de la prévision via la fonction AI.FORECAST sans avoir besoin de créer et d’entraîner leurs propres modèles.

L’approche adoptée révèle aussi une philosophie intéressante chez Google Research car plutôt que de multiplier les modèles spécialisés, ils misent sur des modèles de fondation capables de généralisation. C’est la même logique qui a donné naissance aux LLM universels, mais appliquée maintenant au domaine temporel.

Pour les dev qui veulent tester, le modèle est disponible en open source sous licence Apache 2.0 et fonctionne avec numpy et pandas. Il faut juste prévoir au minimum 32GB de RAM, ce qui reste raisonnable pour un modèle de cette puissance.

J’sais pas ce que ça va donner à long terme, mais j’ai trouvé ça intéressant et TimesFM pourrait bien change la façon dont on aborde la prédiction dans des domaines aussi variés que la finance, la météorologie ou la gestion énergétique.

Source

C’est quand même fou, l’obsession des développeurs et des bouffeurs de changelog comme moi pour les numéros de version. Tenez, par exemple, comma.ai vient de sortir une nouvelle version d’openpilot et au lieu de passer à la tant attendue version 1.0, ils nous font le coup du 0.9.9 → 0.10. Une jolie feinte qui montre qu’ils ont encore de l’ambition sous le capot avant de franchir ce cap symbolique du 1.0, avec un objectif clair côté équipe : faire passer le contrôle longitudinal end-to-end d’Experimental à Chill.

Ce que je retiens de cette nouvelle release, c’est surtout leur nouvelle architecture “Tomb Raider”. Ce n’est pas juste une amélioration incrémentale, c’est carrément une approche validée scientifiquement dans un papier de recherche publié sur arXiv qui prouve qu’on peut, de manière fiable, entraîner des systèmes de conduite autonome dans des simulateurs, sans avoir besoin de règles codées en dur. Ces simulateurs produisent artificiellement des situations de conduite comme on pourrait en enregistrer chaque jour avec une dashcam par exemple. Cela permet d’avoir une masse de données gigantesque afin de renforcer l’apprentissage des modèles.

Et comme ça, au lieu de faire comme Cruise ou Waymo qui claquent des milliards dans du matériel spécialisé et des cartes HD au LiDAR, comma.ai peut continuer de faire tourner son système sur un équivalent de smartphone.

Terminé le MPC (Model Predictive Control) traditionnel, place maintenant à un World Model qui prédit directement les trajectoires. Dans leur papier de recherche, ils expliquent avoir développé deux stratégies de simulation : la simulation reprojective qui utilise des cartes de profondeur pour recréer des scènes, et la simulation par World Model qui génère carrément des scénarios de conduite réalistes. Et surtout, le MPC est retiré en latéral dans les modes Chill et Experimental, et le longitudinal bascule aussi sur ce modèle en Experimental dès cette release. C’est pas rien !

Ici, en bleu vous pouvez voir le trajet pris par un humain. En vert, c’est la prédiction du trajet humain par le modèle précédent. Et en orange, vous avez la prédiction du trajet humain par le nouveau modèle de cette release. Ce qu’il faut retenir, c’est que le trajet orange est le meilleur car il part de la position actuelle de la voiture, pour converger vers le centre de la voie. Ça permet de garder le véhicule bien au centre de sa voie.

Pour l’entraînement de Tomb Raider, ils ont aussi mis en place un genre de goulot d’étranglement volontaire de l’information pour éviter que le système n’exploite les artefacts du simulateur. En gros, ils forcent le réseau de neurones à apprendre des vraies compétences de conduite plutôt que de tricher en exploitant les failles de la simulation. C’est un détail technique, certes, mais ça fait la différence entre un prototype de labo et un système actuellement déployé dans la vraie vie.

Pour ceux qui veulent creuser la partie scientifique, leur approche future-anchored world model permet de générer des scénarios de conduite réalistes en partant du futur puis en remontant vers le présent. C’est contre-intuitif, mais ça permet d’éviter les dérives accumulatives typiques des modèles génératifs. Ils ont même réussi à déployer ces politiques apprises en simulation directement dans openpilot, prouvant que le transfert sim-to-real fonctionne vraiment.

D’après les tableaux de l’étude, ce nouveau système atteint chez 500 utilisateurs environ 30 % de temps d’engagement et 52 % de distance parcourue sous assistance. C’est impressionnant et comme je vous l’expliquais dans cet article, Consumer Reports avait classé openpilot au-dessus de l’Autopilot de Tesla en 2020, mais aussi du Super Cruise de Cadillac et du Co-Pilot 360 de Ford, particulièrement sur l’engagement du conducteur et la facilité d’utilisation. Ce n’est pas pour rien.

Techniquement, la nouvelle version améliore aussi significativement la détection des véhicules à l’arrêt grâce au modèle Space Lab 2 comme vous pouvez le voir ici. La team a validé ça en conditions réelles et via une batterie de 25 scénarios CARLA pour les arrêts et redémarrages.

Ils ont aussi réduit le nombre de frames ignorées à basse vitesse de 78 % à 52 %, ce qui se traduit concrètement par une bien meilleure gestion des embouteillages et des situations de stop-and-go. Je vous rassure, la vidéo est accélérée, ça ne fait pas flipper comme ça en vrai.

Donc pour tous ceux qui ont déjà pesté contre leur régulateur adaptatif qui ne comprend rien aux bouchons et se tape de grosses accélérations pour rien, c’est une vraie avancée.

Autre détail qui change la sensation au volant c’est l’estimation en direct du délai latéral qui est désormais utilisée, ce qui affine la précision de la direction selon les modèles de voitures. Et côté pipeline d’entraînement, ils ont aussi validé l’usage d’images compressées pour coller au simulateur de Machine Learning. Par exemple, le modèle Vegan Filet-o-Fish est entraîné directement sur ces frames compressées, sans dégradation notable de la politique de conduite.

Ils ont également réécrit leur parser CAN en Python avec détection automatique de la fréquence des messages, économisant 700 lignes de code par véhicule supporté. Du coup, plus de 300 modèles de voitures sont maintenant officiellement supportés, incluant les Honda Accord, CR-V et Pilot 2023-25, ainsi que l’Acura MDX 2025, et c’est devenu beaucoup plus simple d’en ajouter de nouvelles.

Puis ils ont aussi mis à jour leur dataset commaCarSegments qui contient maintenant 3000 heures de données CAN provenant de leur flotte de 20 000 utilisateurs dans le monde. Même les constructeurs n’ont pas accès à ces données CAN de production, donc je vous laisse imaginer, ça vaut de l’or !

Côté usage au quotidien, deux petites nouveautés bien pratiques. Ils ont ajouté un outil de clipping pour partager des extraits vidéo de conduite dans le channel #driving-feedback de leur Discord, et l’option d’enregistrer l’audio de la dashcam, désactivée par défaut et maintenant activable en un tapotement de doigt.

Bref, comme d’hab avec comma, ils ne sont pas dans le marketing, ils sont dans l’amélioration continue et surtout ils livrent du concret !

N’oubliez pas quand même qu’openpilot reste un système d’aide à la conduite de niveau 2 donc le conducteur reste responsable, mains sur le volant et yeux sur la route.

Maintenant, comme je vous le disais en intro, leur objectif pour la vraie 1.0 c’est de faire passer le contrôle longitudinal end-to-end du mode Experimental au mode Chill, autrement dit le rendre suffisamment fiable pour être utilisé par défaut. On verra s’ils y parviennent mais je suis confiant.

Qui sait, ça passera peut-être par un upgrade du matériel à un moment avec un nouveau comma 4 ?

En tout cas, cette jolie version 0.10 n’est pas qu’une simple mise à jour. C’est vraiment, je trouve, la validation d’une approche totalement différente de la conduite autonome qui mise sur l’apprentissage end-to-end, des générateurs de data virtuelles pour l’entraînement et bien sûr tout ça en open source !

C’est beau non ? Les constructeurs automobiles feraient bien d’en prendre de la graine.

Source

Le bidouilleurs et leur capacité à détourner littéralement n’importe quoi pour y faire tourner DOOM, perso j’adore ! Et là, Aaron Christophel vient de franchir un nouveau cap en transformant une station de charge Anker Prime (lien affilié) en console de jeu. Oui, vous allez pouvoir joueur sur votre chargeur entre deux sessions de recharge.

L’histoire commence par une découverte intéressante… En bon hacker, Christophel analyse la station Anker Prime qu’il vient d’acheter et réalise que le hardware embarqué est bien plus costaud que prévu. Sous le capot, on trouve un ESP32-C3 pour le Bluetooth, mais surtout un microcontrôleur ARM Synwit SWM341RET7 cadencé à 150 MHz, accompagné de 16 Mo de flash et 8 Mo de RAM. Pour un simple chargeur, c’est du luxe !

Et puis il y a l’écran ! Et quel écran puisqu’il fait 200×480 pixels. C’est pas énorme, c’est vrai mais LARGEMENT suffisant pour afficher les couloirs de la base Martienne et les affreux démons pixelisés. Et le meilleur dans tout ça c’est qu’A’aucune modification hardware n’est nécessaire. Christophel a simplement chargé son code et hop, DOOM tourne.

Mais comment on joue sur un chargeur, me direz-vous ? Eh bien, c’est tout l’art de cette prouesse. Pour cela, le développeur utilise la molette rotative de la station comme contrôleur principal. On pousse pour avancer, on tourne pour se diriger, et on appuie pour tirer. C’est pas le summum de l’ergonomie, mais ça fonctionne ! Les contrôles sont surprenamment jouables, même si naviguer dans les niveaux demande un certain temps d’adaptation.

Techniquement, le jeu tourne de manière fluide, mais Christophel a dû faire quelques compromis. Le mode plein écran s’avère trop gourmand pour le processeur, et globalement l’expérience reste “un peu bancale” selon ses propres mots. Mais franchement, quand on voit DOOM tourner sur une station de charge, on va pas chipoter sur la fluidité.

Bref, un appareil de plus dans la longue liste des portages de DOOM sur des bidoules improbables. Christophel n’en est d’ailleurs pas à son coup d’essai puisqu’il avait déjà fait tourner le jeu sur une brosse à dents électrique. Entre les calculatrices, les réfrigérateurs connectés, les PDF et maintenant les chargeurs, on se demande s’il existe encore un appareil électronique incapable de faire tourner ce chef-d’œuvre de 1993.

Et ce qu’on découvre aussi c’est que cette station Anker n’est pas qu’un bête chargeur… c’est un petit ordinateur déguisé, avec suffisamment de ressources pour faire tourner des applications complexes. Christophel l’explique d’ailleurs très bien sur Mastodon : “Le MCU interne SWM34S est juste excellent ! 8 Mo de RAM + 16 Mo de flash directement mappés en mémoire, ça déchire.”

Alors si un simple chargeur peut faire tourner DOOM, qu’est-ce qui nous empêche d’imaginer des fonctionnalités plus poussées ? Par exemple, un chargeur qui affiche vos mails, votre météo, qui sert de hub domotique ? Ou qui se fait infecter par un virus dont l’objectif est de le faire exploser ?

Une fois encore, la seule limite des hackers c’est l’imagination. Et visiblement, Aaron Christophel n’en manque pas. Maintenant, reste à savoir quel sera le prochain appareil à rejoindre la grande famille des supports DOOM ???

Source

Hier soir, j’ai découvert un outil qui m’aurait évité des dizaines de commits “fix CI”, “fix CI again”, “please work this time” sur GitHub. J’sais pas si vous aussi vous connaissez cette galère ? Vous modifiez votre workflow GitHub Actions, vous poussez, ça plante, vous corrigez, vous repoussez, ça replante… Bref, votre historique Git ressemble à un journal de débugging en temps réel.

Et heureusement, wrkflw vient mettre fin à ce cauchemar.

Ce petit outil codé en Rust vous permet en fait de valider et d’exécuter vos GitHub Actions directement sur votre machine, sans avoir besoin de pusher quoi que ce soit. L’outil vient d’être annoncé sur le forum Rust et ça va bien aider tout le monde je pense.

Grâce à lui, au lieu de tester vos workflows dans le cloud GitHub (et potentiellement faire planter votre CI/CD devant toute l’équipe… La te-hon…), vous les exécutez localement. Wrkflw parse alors votre fichier YAML, résout les dépendances entre jobs, et lance tout ça soit dans Docker/Podman pour matcher l’environnement GitHub, soit en mode émulation si vous n’avez pas de runtime container sous la main.

Ce qui rend wrkflw vraiment pratique, c’est son interface TUI (Terminal User Interface) qui vous permet de visualiser l’exécution en temps réel. Un simple wrkflw tui et vous avez un dashboard interactif où vous pouvez suivre vos jobs, voir les logs, et comprendre ce qui foire sans avoir à jongler entre 15 onglets GitHub.

L’installation se fait en deux secondes si vous avez Rust :

cargo install wrkflw

Le package est aussi dispo sur crates.io et une fois installé, vous pouvez valider un workflow avec la commande :

wrkflw validate .github/workflows/rust.yml

ou le lancer directement avec

wrkflw run .github/workflows/ci.yml

L’outil détectera automatiquement tous vos workflows et les chargera dans l’interface.

Ce qui est fort avec wrkflow, c’est surtout le support quasi-complet des fonctionnalités de GitHub Actions. Les Matrix builds ? Ça passe ! Les Container actions ? Bah ouais, pas de problème ! Tout ce qui est JavaScript actions ? Check ! Même chose pour les Composite actions et les workflows réutilisables et même les fichiers d’environnement GitHub sont supportés. Bon, il y a quelques limitations évidemment. Vous ne pouvez pas par exemple mettre de secrets GitHub (ce qui est logique), et y’a pas de support Windows/macOS runners, ni pas d’upload/download d’artifacts. Mais pour 90% des cas d’usage, c’est largement suffisant.

Wrkflw s’inscrit dans une tendance plus large d’outils qui cherchent à remplacer Make et ses Makefiles cryptiques. Je pense par exemple à Task (Taskfile) qui est un autre exemple populaire, écrit en Go avec une syntaxe YAML plus moderne ou encore à Act, un autre outil open source qui fait à peu près pareil. Les développeurs cherchent clairement des alternatives plus lisibles et maintenables et wrkflw va encore plus loin en se spécialisant sur GitHub Actions.

Le mode Docker/Podman de wrkflw permet par exemple de créer des containers qui matchent au plus près l’environnement des runners GitHub. Et si jamais vous interrompez l’exécution avec Ctrl+C, pas de panique, puisque l’outil nettoie automatiquement tous les containers créés. Comme ça, y’aura plus de containers zombies qui traînent après vos tests.

Et pour tous ceux qui bossent en mode émulation sécurisée (sans Docker), wrkflw exécute les actions dans un environnement sandboxé. C’est moins fidèle à l’environnement GitHub mais au moins ça permet de tester rapidement sans avoir besoin d’installer Docker. Pratique sur des machines de dev légères ou des environnements restrictifs.

Le workflow de test devient donc le suivant : 1/ Vous modifiez votre YAML. 2/ Vous lancez wrkflw run . 3/ Vus voyez immédiatement si ça marche. 4/ Vous corrigez si besoin. 5/ Et c’est seulement ensuite que vous poussez sur GitHub. Plus de commits de debug, plus de CI cassée, plus de collègues qui râlent parce que la pipeline est tout rouge ^^.

L’outil est encore jeune bien sûr mais déjà très prometteur. Les prochaines versions devraient ajouter le support des secrets locaux, une meilleure intégration avec GitLab CI, et peut-être même le support des runners Windows/macOS.

Bref, si vous gérez des workflows GitHub Actions complexes, wrkflw va rapidement devenir indispensable à votre life.

A découvrir ici !

Vous savez ce qui m’a toujours ennuyé avec git blame ? C’est qu’à chaque refactoring, chaque reformatage de code, chaque déplacement de fichier, tous les noms disparaissent pour être remplacés par celui de la personne qui a fait ces modifications. Du coup, impossible de savoir qui a vraiment écrit le code original. Heureusement, un développeur nommé Sinclair Target vient de sortir un outil qui résout ce problème.

git-who (c’est son nom) fait donc exactement ce que git blame aurait dû faire depuis le début à savoir analyser qui a vraiment contribué à votre codebase, et pas juste qui a touché les lignes en dernier. Au lieu de se contenter d’une analyse ligne par ligne comme git blame, git-who analyse les patterns de contribution sur des fichiers entiers, des dossiers, voire des composants complets.

L’installation est simple comme bonjour. Si vous êtes sur Mac avec Homebrew, un petit brew install git-who et c’est réglé. Pour les autres, vous pouvez passer par Go avec go install github.com/sinclairtarget/git-who@latest ou compiler depuis les sources si vous aimez les défis. Docker est aussi supporté pour ceux qui préfèrent…

Ce qui rend git-who vraiment intéressant, c’est ses trois modes d’analyse. Le mode table (par défaut) vous donne un tableau récapitulatif des contributions par auteur, triable par nombre de commits, lignes de code, fichiers touchés ou date de modification. C’est pratique pour identifier rapidement qui sont les principaux contributeurs d’un projet. Le mode tree affiche l’arborescence du projet avec le contributeur principal annoté pour chaque fichier et dossier. Et le mode hist génère une timeline de l’activité des commits avec le top contributeur par période.

Pour vous donner une idée concrète, Sinclair Target a fait une démo sur le projet Vim pour analyser les patterns de maintenance après le décès de Bram Moolenaar. L’outil a permis d’identifier rapidement qui avait pris le relais sur différentes parties du code. C’est quelque chose qu’il aurait été impossible à voir clairement avec un git blame classique.

La différence fondamentale donc avec git blame, c’est que git-who “comprend” le contexte. Si quelqu’un déplace un fichier ou fait un reformatage massif, git blame lui attribuera toutes les lignes alors git-who, lui, va chercher plus loin dans l’historique pour identifier les véritables auteurs du code. Il respecte même les fichiers .mailmap pour consolider les identités multiples d’un même développeur et prend en compte le fichier .git-blame-ignore-revs pour ignorer certains commits de maintenance.

Pour utiliser git-who, il suffit de faire un git who à la racine de votre projet afin d’obtenir l’analyse de base. Vous pouvez filtrer par chemin avec git who Parser/ pour analyser seulement un dossier spécifique. Le tri est customisable avec des options comme -l pour trier par lignes de code ou -m pour la date de dernière modification. Et pour une vue historique entre deux versions, git who hist v3.10.9..v3.11.9 fait le job.

Bien sûr, git-who n’est pas le seul dans sa catégorie. GitLens pour VS Code reste l’extension la plus populaire, offrant une intégration visuelle directement dans l’éditeur. Git Quick Stats est aussi une autre alternative en ligne de commande qui propose des statistiques détaillées sur les repositories. Mais aucun ne va aussi loin que git-who dans l’analyse de la véritable propriété du code.

Qui maintient réellement cette partie critique du code ? Quelle équipe a le plus contribué à ce module ? Comment les contributions ont évolué au fil du temps ? Git-who vous aide à répondre à ces questions essentielles sur la gestion de votre projet, les audits de code ou simplement pour comprendre l’histoire d’un projet open source.

Bref, j’ai trouvé ça cool… Et qui sait, peut-être qu’un jour git-who sera intégré directement dans Git ?