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

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

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

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

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

Pour l'installer, c'est hyper simple :

pip install sqlit-tui

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

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

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

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

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

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

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

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

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

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

cordon system.log

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

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

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

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

cordon --anomaly-range 0.05 0.15 app.log

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

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

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

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

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

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

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

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

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

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

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

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

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

npm install mediabunny

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

const duration = await input.computeDuration();

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

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

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

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

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

Alors HTTP Breakout Proxy c’est quoi ?

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

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

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

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

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

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

A découvrir ici !

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

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

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

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

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

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

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

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

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

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

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

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

Source

Vous connaissez le Spotify Wrapped qui vous rappelle chaque décembre que vous avez écouté “Africa” de Toto 847 fois ? Hé bien GitWrap fait pareil mais pour votre code sur GitHub. Et tout ça avec une interface qui sent bon le DOS et les moniteurs à phosphore vert.

Vous entrez votre nom d’utilisateur GitHub, et l’outil génère alors un récapitulatif de votre année de commits, de pull requests et de contributions diverses et variées. Le tout emballé dans une esthétique rétro qui ferait pleurer de nostalgie n’importe quel dev qui a connu l’époque où “git” n’existait pas encore et où on faisait des sauvegardes sur disquettes.

L’interface vous accueille avec un prompt style années 80… genre > Enter GitHub username to begin. On se croirait dans WarGames avant de lancer une partie de morpion thermonucléaire et il ne manque plus que la voix synthétique qui demande “Shall we play a game?” et c’est parfait.

Y’a aussi un leaderboard pour les compétitifs qui veulent comparer leur nombre de commits avec les autres. Parce que oui, apparemment certaines personnes ont besoin de savoir qu’elles ont codé plus que leur voisin de bureau. Chacun ses kinks.

A vous de tester maintenant pour savoir si vous avez bien bossé sur votre code cette année ou si vous n’avez rien branlé comme l’année dernière.

Et accessoirement vous pouvez même vous faire une jolie image pour frimer sur LinkedIn ! Ça prend 30 secondes et ça vous donnera une excuse pour procrastiner avant de retourner à ce bug que vous évitez depuis trois jours.

Source

Dessiner des schémas en ASCII art, c’est un peu le sport national des devs qui documentent leur code dans des fichiers texte. Sauf que jusqu’ici, soit on se tapait ça à la main caractère par caractère, soit on passait par des outils en ligne qui demandent de se créer un compte et gardent vos diagrammes sur leurs serveurs. Heureusement, Cascii règle le problème puisqu’il s’agit d’un éditeur graphique complet qui tient dans un seul fichier HTML !

Et comme Cascii est écrit en JavaScript pur, y’a aucune dépendance, aucun framework, aucun npm install…etc. Vous téléchargez juste le fichier HTML, vous l’ouvrez dans votre navigateur, et c’est parti mon kiki.

Et pour l’installer, une commande suffit :

curl https://cascii.app -o cascii.html && open cascii.html

Ahaha ouais c’est la commande curl la plus nulle de l’histoire des commandes curl mais ça vous montre que je n’abuse pas.

Côté fonctionnalités, on a donc tout ce qu’il faut pour dessiner des diagrammes propres. Des lignes libres, des lignes en escalier, des carrés, des cercles, des losanges, du texte, des tableaux. Un système de calques permet d’organiser les éléments et de les grouper. Le plus malin, je trouve, c’est les “jointures intelligentes” qui connectent automatiquement les formes entre elles… parce que dessiner des flèches qui arrivent pile au bon endroit à la main, c’est l’enfer. Même comme ça, je suis pas doué, cela dit…

Ne le jugez pas…

L’éditeur propose plusieurs charsets tels que ASCII classique ou Unicode pour ceux qui veulent des lignes plus jolies et il y a 3 styles de lignes (pointillées, solides fines, solides épaisses) ainsi que des flèches directionnelles. Côté thèmes, du sombre, du clair, ou un mode “console” pour les nostalgiques du terminal.

La sauvegarde se fait automatiquement dans le stockage local du navigateur, donc même si vous fermez l’onglet par erreur, votre travail n’est pas perdu et pour partager ou archiver, il y a un export en Base64 qui permet de tout récupérer plus tard. Si vous utilisez la version hébergée sur cascii.app, vous pouvez aussi générer des liens courts pour partager vos créations.

Le projet est sous licence Apache 2.0 et le code source est dispo sur GitHub et pour les raccourcis clavier, c’est du classique : Ctrl+Z pour annuler, Ctrl+C/V pour copier-coller, Ctrl+G pour grouper des éléments, Shift+Click pour la multi-sélection. L’historique est illimité donc vous pouvez revenir en arrière autant que vous voulez.

Voilà, si vous documentez du code, dessinez des architectures système ou avez juste besoin de faire un petit schéma rapide sans sortir l’artillerie lourde, Cascii fera le job !

Vous développez une app SwiftUI et Claude vous balance du NavigationView alors qu’Apple recommande NavigationStack depuis la sorite d’iOS 16 ? Ou encore il vous sort @ObservableObject et @Published alors qu’on est passé à @Observable ?

Bienvenue dans le club des devs qui passent plus de temps à corriger les hallucinations de leur IA qu’à coder…

Ce problème, Aleahim, un développeuse macOS, en a eu marre alors elle a créé Cupertino, un serveur MCP qui donne accès à Claude à plus de 22 000 pages de documentation Apple en local. Plus besoin d’aller sur le net, et surtout plus d’excuses pour mélanger du code iOS 12 avec du SwiftUI moderne.

Ainsi, au lieu de laisser Claude deviner les API (et se planter une fois sur deux), on lui file l’accès direct à la vraie doc. Les 261 frameworks Apple sont là, indexés dans une base SQLite locale, avec un moteur de recherche full-text qui répond en moins de 100ms. SwiftUI, UIKit, AppKit, Foundation, Core ML, ARKit… tout y est.

L’écosystème se découpe ensuite en plusieurs repos GitHub. D’abord le serveur MCP principal qui fait le boulot d’indexation, ensuite un repo avec la doc pré-crawlée (parce que se taper 20 heures de téléchargement, merci mais non merci), et une collection de 606 projets d’exemple Apple officiels pour la route.

De quoi transformer Claude en assistant qui connaît VRAIMENT la plateforme.

Si ça vous intéresse, sachez qu’avant de vous lancer, faut être sur macOS 15 minimum avec Xcode 16 et Swift 6.2+. Côté espace disque, prévoyez 2-3 GB. Et si vous avez déjà bidouillé dans le terminal, que vous connaissez Git et que vous avez Claude Code installé, vous êtes bons. Comptez environ une quinzaine de minutes pour tout mettre en place.

Et rassurez-vous, je ne vous laisse pas tomber, on va attaquer l’installation ensemble. D’abord, récupérez le projet et compilez-le :

git clone https://github.com/mihaelamj/cupertino.git
cd cupertino
make build
sudo make install

git clone https://github.com/mihaelamj/cupertino-docs.git ~/.cupertino

# Swift Evolution, ~5 minutes
cupertino fetch --type evolution
# Doc complète, ~20-24h
cupertino fetch --type docs
# Sample code Apple, ~4 minutes
cupertino fetch --type samples

cupertino save

cupertino serve

claude mcp add cupertino --scope user -- /usr/local/bin/cupertino

L’accessibilité web c’est comme le tri sélectif… tout le monde dit que c’est génial mais azy, j’ai pas le temps. Et pourtant, c’est super important car près de 80% des pages web ont des problèmes de contraste de texte.

C’est le souci noumber ouane détecté sur le million de sites analysés chaque année par WebAIM . En gros, si vous avez un site, y’a de fortes chances que certains visiteurs galèrent à lire votre contenu, et je ne vous parle pas uniquement des personnes malvoyantes, hein… y’a aussi le daltonisme qui touche environ 8% des hommes et 0,5% des femmes. Rajoutez à ça les gens qui lisent leur téléphone en plein soleil, ceux qui ont une dalle de laptop toute pourrie, et vous comprendrez vite que le problème concerne pas mal de monde.

Alors est ce que vous connaissez les normes WCAG ?

Hé bien c’est le standard international pour l’accessibilité web. Ainsi pour être conforme au niveau AA (le minimum recommandé), votre texte doit avoir un ratio de contraste d’au moins 4,5:1 avec son arrière-plan. Pour le niveau AAA (l’idéal), c’est 7:1. Et là vous vous dites “super, je vais calculer ça à la main pour mes 47 couleurs de palette, mais va bien te faire cuire le cul, Korben”. (Oui, c’est comme ça que je vous imagine quand vous lisez mes articles).

Heureusement, y’a un outil qui vient de sortir et qui va vous changer la vie : CM-Colors . Vous lui donnez vos couleurs, et il les ajuste automatiquement pour qu’elles soient accessibles, le tout en modifiant les teintes le moins possible pour garder votre design intact.

L’installation est super fastoche…. C’est du Python donc un petit pip install cm-colors et hop c’est réglé. Ensuite, vous pouvez l’utiliser soit en ligne de commande directement sur vos fichiers CSS, soit via l’API dans votre code. Par exemple, vous avez un gris #5f7887 sur un fond #e6f0f5 qui passe pas les tests, hop, CM-Colors le transforme automatiquement en #5c6f7b et maintenant c’est conforme AA. Et la différence à l’œil nu est quasi invisible. Bref, c’est nickel pour l’accessibilité !

from cm_colors import ColorPair

# Your colors
pair = ColorPair("#999999", "#ffffff")

# Fix them and preview in the terminal
fixed_color, success = pair.make_readable(show=True)

print(f"Use {fixed_color} instead of #999999")
# Output: Use #8e8e8e instead of #999999

Le truc vraiment cool, c’est que l’outil gère plusieurs niveaux de lisibilité. Y’a “Readable” qui correspond au AA, “Very Readable” pour le AAA, et même une option large_text=True pour les gros titres qui ont des exigences moins strictes. Vous pouvez donc adapter selon vos besoins et pour les devs qui bossent sur de gros projets, y’a aussi une fonction make_readable_bulk qui permet de corriger plusieurs paires de couleurs d’un coup.

from cm_colors import make_readable_bulk

my_colors = [
 ("#777", "#fff"),
 ("#888", "#000"),
]

results = make_readable_bulk(my_colors)

for color, status in results:
 print(f"{color} is {status}")

Vous lui balancez une liste de tuples (texte, fond) et il vous retourne tout ça au propre. Et si vous voulez traiter directement vos fichiers CSS, la commande cm-colors styles.css génère un nouveau fichier styles_cm.css avec toutes les couleurs corrigées. L’outil peut même générer des rapports HTML pour visualiser les changements avant/après.

Alors oui, je sais, se taper de l’accessibilité c’est un peu relou car on a toujours l’impression que c’est du temps perdu sur des détails. Mais dites vous que ça impacte vraiment l’expérience de millions d’utilisateurs, donc ça vaut le coup d’y passer 5 minutes, surtout avec un outil automatisé !

Bref, CM-Colors c’est gratuit, c’est open source sous licence GPL-3, et ça peut vous éviter pas mal de galères. Toute la documentation est ici et y’a même une démo interactive sur leur site si vous voulez tester avant d’installer.

Scène du crime, mardi matin, vous demandez à Claude Code de vous générer un middleware Next.js qui vérifiera un JWT dans les cookies. Et l’IA vous pond sans sourciller 15 lignes de code bien propres, bien commentées… Elle est parfaitement confiante et vous ça vous rassure. Vous copiez son œuvre, vous collez. Et là, PAF, une erreur de compilation !!

Hé oui, la fonction qu’elle a utilisée n’existe plus depuis Next.js 14. En gros, Claude Code a halluciné tranquillement avec de la vieille doc pourrie de 2020.

Et dire qu’on a passé 20 ans à se foutre de la gueule des devs qui copient-collent du code depuis de vieux posts Stack Overflow alors qu’aujourd’hui, on copie colle sans réfléchir ce que nous donne une IA qui fait exactement pareil ! C’est ça le progrès les amis !

Hé bien Context7 vient régler exactement ce problème ! Il s’agit d’un serveur MCP (Model Context Protocol) développé par Upstash qui branche votre assistant de code sur la documentation officielle à jour, comme ça vous esquivez les fonctions dépréciées, les API fantômes, et les best practices d’il y a trois ans.

Context7 est donc compatible avec Cursor, Claude Code, Windsurf, VS Code, Zed, Gemini CLI, et tous les éditeurs qui supportent le protocole MCP (donc à peu près tout ce qui existe…) et une fois que c’est en place, y’a plus qu’à l’oublier. Si vous hésitez, y’a une démo ici pour tester .

Mais avant de commencer, sachez que vous aurez besoin de Node.js 18+ pour la méthode locale. Et pour la méthode serveur distant, juste un navigateur et votre éditeur de code.

La méthode serveur distant consiste à aller sur context7.com , à vous créer un compte gratuit, à récupérer une clé API, puis à ajouter cette config dans votre éditeur comme ceci :

{
 "mcpServers": {
 "context7": {
 "url": "https://mcp.context7.com/mcp",
 "headers": {
 "CONTEXT7_API_KEY": "votre_cle_api_ici"
 }
 }
 }
}

{
 "mcpServers": {
 "context7": {
 "command": "npx",
 "args": ["-y", "@upstash/context7-mcp", "--api-key", "votre_cle_api_ici"]
 }
 }
}

Vous savez ce qui est marrant avec reCAPTCHA ? C’est que pendant des années, on nous a fait déchiffrer des plaques d’immatriculation floues, cliquer sur des feux tricolores bizarres, et identifier des vélos volés dans des images pixelisées, tout ça pour prouver qu’on était pas un robot. Alors qu’en fait, on entrainait gratos les IA de Google à reconnaitre ce genre de choses… Du coup, faudrait savoir s’en passer maintenant.

Et ça tombe bien puisqu’il existe une alternative qui change le game : ALTCHA . C’est un système de protection anti-spam et anti-bot open source qui utilise le Proof-of-Work à la place des puzzles visuels. Comme ça, au lieu de faire bosser votre cerveau ramolli pour Google, c’est votre processeur qui fait le boulot, tout ça en local, depuis chez vous, sans envoyer le moindre octet de donnée à Mountain View.

En gros, quand vous validez un formulaire, votre navigateur résout un petit calcul cryptographique. Pour un humain avec un ordinateur normal, c’est transparent et instantané mais pour un bot qui essaie de spammer 1000 formulaires par seconde, ça devient très vite coûteux en ressources. Et le plus beau c’est qu’il n’y a pas besoin de serveurs externes, pas de tracking, pas de cookies, pas de fingerprinting puisque tout se passe en local.

En plus, ALTCHA pèse 30 KB une fois compressé alors que reCAPTCHA c’est 300 KB… Vous vous demandez pourquoi reCAPTCHA est si gros en vrai ? Hé bien c’est parce qu’il est composé d’un tas de scripts de tracking, de fingerprinting, d’analyse comportementale et j’en passe…

ALTCHA est sous licence MIT , donc vraiment libre et ça fonctionne avec tous les navigateurs modernes (Chrome 67+, Firefox 63+, Safari 11+), avec plus de 50 langues dispo et niveau conformité, c’est carré sa Cnil : GDPR, WCAG 2.2 AA, HIPAA, CCPA…etc.

ALTCHA détecte aussi les headless browsers (les navigateurs sans interface graphique utilisés pour automatiser), les scripts automatisés, et même les bots qui utilisent du machine learning. Le système analyse le contenu et le contexte utilisateur pour adapter le niveau de protection et vous pouvez le déployer partout sans problème : AWS, Azure, Kubernetes, Docker, ou juste sur votre serveur web classique. Il y a même un plugin WordPress si vous voulez pas vous embêter avec du code.

En plus, comme c’est à 100% auto-hébergé, vous ne dépendez d’aucun service externe. Alors que quand reCAPTCHA tombe en panne (spoiler : ça arrive régulièrement), votre site est pété.

Bref, si vous en avez marre de faire bosser les visiteurs de votre site gratos pour Google qui en profite pour les tracker, jetez un œil à ALTCHA . Pour une fois que l’Europe arrête de mendier ses outils de sécurité auprès des géants américains et qu’en plus c’est meilleur, ce serait dommage de s’en priver.

Modifier un PDF, c’est toujours la galère surtout si c’est un PDF avec que des images sans texte sélectionnable. Soit vous avez Adobe Acrobat qui coûte une couille, soit vous vous tapez des outils en ligne douteux, soit vous exportez en Word et vous priez pour que la mise en page survive. Bref, vous faites vos trucs de losers….

Mais ça c’était sans compter sur Nano-PDF qui propose une approche radicalement différente : Vous décrivez ce que vous voulez changer en langage naturel, et l’IA se chargera du reste.

Par exemple, si vous avez une présentation PDF avec une faute de frappe sur la slide n°5, au lieu de galérer avec un éditeur, vous tapez juste

`nano-pdf edit ma_presentation.pdf 5 "Corrige la faute sur le mot 'investisement'"`

`pip install nano-pdf`

Si vous avez grandi avec les bips et les blops des consoles 8 bits et que vous avez toujours rêvé de composer vos propres musiques façon NES, Game Boy ou Mega Drive, pas besoin d’investir dans un Ableton Live ou un FL Studio à whatmille boules car je vous ai trouvé un truc qui va vous permettre de composer de la musique 8 bit comme un chef !

Ça s’appelle Furnace et c’est un tracker de chiptune open source qui émule plus de 60 puces sonores différentes et vous fera peut-être regretter de pas avoir appris le solfège quand vous étiez plus jeune..

Alors pour ceux qui ne connaissent pas, un tracker c’est un logiciel de composition musicale où on empile des notes et des patterns les uns sur les autres, un peu comme dans les jeux de rythme (Guitar Hero ?), sauf que là c’est vous qui créez la musique. Et Furnace, c’est probablement le plus gros tracker multi-système jamais créé avec plus de 200 configurations prêtes à l’emploi dispo.

Le truc vraiment cool, c’est que ce logiciel utilise des cœurs d’émulation de qualité comme Nuked, MAME, SameBoy ou encore reSID pour reproduire fidèlement le son du hardware original. Donc que vous vouliez le son crunchy du Commodore 64, les nappes FM de la Mega Drive ou les samples de l’Amiga, tout y est émulé avec une précision quasi parfaite !

Côté puces supportées, y’a vraiment de quoi faire… La famille Yamaha FM au complet (YM2151, YM2612, YM2413, l’OPL3…), les puces Nintendo (NES, SNES, Game Boy), le mythique SID du C64, les puces d’arcade Neo Geo et CPS-1, et même des trucs plus exotiques comme l’Atari 2600 ou le Vectrex. En tout, le tracker gère jusqu’à 32 puces simultanées soit 128 canaux au total… De quoi composer une symphonie 8 bits de compétition.

L’interface est entièrement modulable et vous pouvez arranger les fenêtres comme bon vous semble. Y’a même un oscilloscope par canal avec centrage de la forme d’onde pour les perfectionnistes et si vous utilisiez DefleMask avant, bonne nouvelle puisque Furnace charge et sauvegarde les fichiers .dmf et .dmw donc vous pouvez migrer tranquillou.

Pour l’export, c’est pas mal non plus puisque vous pouvez sortir vos compos en WAV (par puce ou par canal), en VGM, en ZSM pour le Commander X16, et même directement en ROM Atari 2600 ou 400/800. Hé oui, vous pouvez littéralement mettre votre musique sur une vraie cartouche si ça vous éclate, les nerdzzzz.

Le projet tourne sous licence GPL, donc c’est gratuit et open source et il est dispo pour Windows, macOS (Intel et Apple Silicon), Linux et FreeBSD.

Voilà, si vous avez la fibre chiptune et que vous cherchez un outil complet pour composer de la musique rétro, foncez tester Furnace . Peut-être que ça vous permettra enfin de créer la bande son du jeu vidéo de vos rêves !!!

Si vous bidouiller un peu de machine learning et que vous avez la flemme de coder une interface web from scratch pour montrer vos jolis modèles, vous connaissez probablement Gradio , cette librairie Python qui permet de créer des démos interactives en quelques lignes de code.

Hé bien, excellente nouvelle, la version 6 vient de sortir et elle apporte pas mal de nouveautés intéressantes.

La grosse news de cette mise à jour , c’est d’abord la refonte complète de l’architecture avec le passage à Svelte 5 . Pour ceux qui s’en fichent du frontend, ça veut dire concrètement que vos apps seront plus légères et plus rapides à charger. L’équipe a aussi bossé sur l’optimisation des files d’attentes (quand y’a du monde sur votre démo), surtout pour les serveurs MCP (Model Context Protocol), donc si vous hébergez des trucs sur Hugging Face Spaces, vous devriez sentir la différence.

Côté fonctionnalités, y’a aussi quelques ajouts sympas comme le support natif des sous-titres pour les vidéos et l’audio, une nouvelle interface “MultimodalTextbox” améliorée pour le mobile (qui était franchement pas terrible avant), et pour ceux qui font des apps multipages, y’a maintenant un composant “Navbar” dédié à ça !

Le truc qui va plaire aux devs aussi, c’est qu’on peut désormais écrire des composants web personnalisés directement en HTML/JavaScript inline dans le code Python. Comme ça, plus besoin de sortir l’artillerie lourde avec des outils de build externes. Vous collez juste votre HTML, votre JS, et c’est parti mon kiki.

Par contre, attention si vous avez des projets existants… Y’a des changements qui vont casser des trucs. Par exemple, le format tuple dans le Chatbot a été supprimé, le composant Sketch est déprécié, et pas mal de paramètres ont bougé dans les composants graphiques natifs. L’équipe a quand même prévu un guide de migration avec des warnings de dépréciation pour vous aider à faire la transition.

A partir de maintenant, seule la branche 6.x sera maintenue, donc si vous êtes encore sur une vieille version, c’est le moment de migrer. La mise à jour se fait classiquement avec un

pip install --upgrade gradio

Notez que Gradio 6 nécessite Python 3.10 minimum et le support de Python 3.14 a été ajouté pour vous, les early adopters ^^.

Voilà, si vous faites du ML ou autre et que vous voulez montrer vos démos sans vous prendre la tête avec du React ou du Vue, Gradio reste une valeur sûre, et avec cette version 6 qui arrive, ce sera encore plus fluide et rapide !

Source

Bon, j’étais un petit peu occupé aujourd’hui parce que c’est mercredi et c’est le jour des enfants, mais je ne pouvais pas finir ma journée sans vous parler de cette histoire incroyable.

Si vous faites partie des gens qui utilisent des sites comme JSONFormatter ou CodeBeautify pour rendre votre JSON lisible ou reformater du code, et bien figurez-vous que des chercheurs en sécu viennent de découvrir que ces outils ont laissé fuiter des tonnes de données sensibles durant des années. Et quand je dis tonnes, c’est pas une figure de style puisque ce sont plus de 80 000 extraits de code contenant des credentials en clair qui ont fuité, soit plus de 5 Go de données.

En effet, les chercheurs de WatchTowr ont découvert que la fonction “Recent Links” de ces plateformes permettait d’accéder à tous les bouts de code collés par les utilisateurs. Les URLs suivaient un format prévisible, ce qui rendait le scraping automatique hyper fastoche pour n’importe qui, et c’est comme ça qu’on a découvert que JSONFormatter a exposé durant 5 ans de données les données de ses utilisateurs. Et du côté de CodeBeautify, ça a duré 1 an.

Les chercheurs ont mis la main sur des identifiants Active Directory, des identifiants de bases de données et services cloud, des clés privées de chiffrement, des tokens d’accès à des repos Git, des secrets de pipelines CI/CD, des clés de passerelles de paiement, des tokens API en pagaille, des enregistrements de sessions SSH, et même des données personnelles de type KYC. Bref, le jackpot pour un attaquant, quoi.

Et côté victimes, c’est un festival puisqu’on y retrouve des agences gouvernementales, des banques, des assurances, des boîtes d’aéronautique, des hôpitaux, des universités, des opérateurs télécom… et même une entreprise de cybersécurité. On a même retrouvé les credentials AWS d’une bourse internationale utilisés pour leur système Splunk, ainsi que des identifiants bancaires provenant de communications d’onboarding d’un MSSP (Managed Security Service Provider). C’est cocasse comme dirait Macron.

Et pour prouver que le problème était bien réel et exploitable, les chercheurs de WatchTowr ont utilisé un service appelé Canarytokens dont je vous ai déjà parlé. Ils ont implanté de faux identifiants AWS sur les plateformes et ont attendu de voir si quelqu’un y accédait…

Résultat, quelqu’un a tenté de les utiliser 48 heures après que les liens étaient censés avoir expiré, et 24 heures après leur suppression supposée. Les données restaient donc accessibles bien au-delà de ce que les utilisateurs pouvaient imaginer.

Et le pire dans tout ça c’est qu’au moment de la publication des articles, les liens “Recent Links” étaient toujours accessibles publiquement sur les deux plateformes. Bref, aucune correction n’a été déployée.

Donc, voilà, si vous avez utilisé ces outils par le passé et que vous y avez collé du code contenant des identifiants et autres clés API (même par inadvertance), c’est le moment de faire une petite rotation de vos secrets.

Et même si c’est une évidence, de manière générale, évitez de balancer du code sensible sur des outils en ligne dont vous ne maîtrisez pas la politique de conservation des données.

Source

Vous avez surement un vieux smartphone qui traîne au fond d’un tiroir, non ? Bah au lieu de le laisser pourrir ou de le balancer à la déchetterie, pourquoi ne pas en faire un vrai serveur web ?

Je sais ce que vous pensez… Ce mec est fou. Et pourtant, c’est exactement ce qu’a fait Louis Merlin avec son projet Far Computer . Son site tourne littéralement sur un Fairphone 2 posé dans un tiroir, avec PostmarketOS comme système d’exploitation. Le site affiche en temps réel les stats de la machine donc au moment où j’écris ces lignes, 5% de CPU, 280 Mo de RAM utilisés sur 1.8 Go disponibles… C’est presque de la puissance gâchée pour servir quelques pages statiques, mdr.

Ce projet s’inscrit dans cette mouvance du “sustainable computing” où l’idée c’est de donner une seconde vie aux appareils qu’on jette après 2-3 ans alors qu’ils ont encore plein de ressources à offrir. D’ailleurs, PostmarketOS est parfait pour ça puisque c’est une vraie distrib Linux basée sur Alpine, ultra légère, et qui supporte plus de 200 appareils différents, des vos vieux Nokia N900 aux tablettes en passant par les liseuses…

D’ailleurs le guide d’installation dispo sur far.computer/how-to est hyper bien fait si vous voulez vous lancer. En gros vous avez besoin d’un PC Linux (ou une VM), vous installez pmbootstrap, vous flashez le téléphone en mode bootloader, et hop, une fois PostmarketOS installé, vous vous connectez en SSH, vous configurez le WiFi avec nmcli, vous créez votre dossier /var/www/html/, vous lancez httpd et voilà. Votre vieux téléphone est devenu un serveur web.

Alors bien sûr, pour mon site avec son million de visiteurs uniques par mois, ça le ferait moyen et faudrait quand même coller un CDN devant pour encaisser la charge, mais pour un projet perso, un blog à faible trafic, une API interne ou juste pour le plaisir de dire aux inconnus dans la rue, “Hey bonjour, on ne se connait pas mais mon site tourne sur un téléphone”, c’est vraiment cool (et un peu creepy).

Certains vont même plus loin en montant des clusters Kubernetes avec plusieurs vieux smartphones . Quand on sait que ces machins ont souvent des specs supérieures à un Raspberry Pi et qu’ils consomment que dalle en électricité, je me dis qu’il y a vraiment un truc à explorer.

Point important à garder en tête quand même, évitez de laisser le téléphone branché en permanence sur le chargeur car les batteries n’aiment pas trop ça, et ça peut finir en feu de joie improvisé. Idéalement faut virer la batterie si c’est possible ou mettre en place une gestion de charge intelligente.

Le code source du projet Far Computer est dispo sous licence CC BY-NC-SA 4.0 donc vous pouvez vous en inspirer, le modifier, le partager… tant que c’est pas pour du commercial bien sûr et que vous gardez la même licence.

Voilà, vous savez ce qu’il vous reste à faire si vous avez des vieux smartphones qui prennent la poussière.

Benjamin, lecteur de korben.info, m’a envoyé un email pour me parler d’ Ackify , son nouveau projet open-source. L’idée avec Ackify c’est de pouvoir confirmer qu’un document a bien été lu !

Je parle pas de signature électronique, hein. Pour ça y’a déjà DocuSign, Adobe Sign, HelloSign…etc. Non, je vous parle des cas où vous avez juste besoin de prouver que Thérèse de la compta a bien reçu, ouvert et lu le PDF de la nouvelle procédure RGPD. Et pour ça, les solutions du marché sont soit surdimensionnées, soit inexistantes, du coup, les boîtes bidouillent avec des Google Forms pourris ou des macros Excel qui traînent dans le coin depuis 2003.

Ackify tourne en Docker distroless, s’installe en 5 minutes avec un script, et fonctionne sur PostgreSQL 16. L’authentification se fait via Magic Link sans mot de passe, ou OAuth 2 si vous préférez Google, GitHub ou GitLab. Ensuite, une fois connecté, vous lisez le document, vous cliquez sur “J’ai lu”, et c’est terminé. Une signature cryptographique Ed25519 est générée, le checksum SHA-256 du document est vérifié, et tout part dans un audit trail immuable.

Le principe est donc super solide et chaque utilisateur ne peut signer qu’une seule fois par document. Ensuite, vous en tant qu’admin, vous avez un dashboard pour tracker qui a lu quoi. Il y a également des rappels automatiques par email pour ceux qui traînent et des widgets que vous pouvez intégrer dans votre intranet si ça vous amuse !

Sans oublier que c’est multi-lingue !

Bref, que ce soit pour obtenir des attestations de lecture de politiques de sécurité, des formations internes avec validation, la prise en compte de directive RGPD, des procédures de conformité…etc, Ackify pourra vous aider sans avoir à sortir l’artillerie lourde de la signature électronique traditionnelle.

Voilà, c’est gratuit, open source et vous pouvez avoir tous les détails sur le site officiel du projet : ackify.eu .

Si vous aimez tout ce qui est rétro, vous avez peut-être déjà essayé de donner un look MS Dos , Windows 95 , Windows 98 , Windows XP ou encore Windows 7 à votre site web.

Ce que vous n’avez jamais osé faire, c’est de lui donner un look Apple System 6 !

Et ça c’est quand même un OS qui est sorti en 1988 soit 7 ans avant Windows 95 et ce qui est incroyable c’est qu’il avait déjà une interface parfaitement mature avec des fenêtres, des icônes, des menus déroulants et tout ça était en noir et blanc, mais c’était pas moche, bien au contraire !

Et ce qu’on oublie c’est que Windows 3.0 a débarqué deux ans plus tard en 1990 avec une interface… étrangement familière. Alors on ne va pas se mentir, Microsoft s’est LARGEMENT inspiré de ce qu’Apple faisait depuis 1984 avec le premier Macintosh qui se sont eux-mêmes inspiré des interfaces vues lors de la visite de Steve Jobs au Xerox PARC.

Apple qui ne doute de rien, a même attaqué Microsoft en justice pour ça en 1988. Le procès a été perdu, mais bon, l’histoire retient qui a copié qui !

Du coup, plutôt que de continuer à cloner les clones, system.css ferme la boucle en revenant à la source. Ce projet est développé par Saket Choudhary et prend son inspiration directe des guidelines de design d’Apple pour System 6, la dernière version monochrome de macOS avant l’arrivée de System 7 en couleur en 1991.

Le truc cool avec system.css, c’est que ça fonctionne exactement comme 98.css. Y’a aucun JavaScript… Vous incluez juste le fichier CSS via CDN ou npm, et hop, tous vos composants HTML prennent instantanément l’apparence d’une interface Macintosh de 1988. Des boutons arrondis, des fenêtres avec une bordure de 19 pixels, des barres de titre, des menus déroulants incroyables, des checkboxes carrées, des boites de dialogues avec double bordure. Tout est là !

L’installation se fait en deux lignes. Via CDN, vous balancez ce code dans votre HTML:

<link rel="stylesheet" href="https://unpkg.com/@sakun/system.css">

`npm i @sakun/system.css`

Linus Torvalds vient de donner son avis sur l’IA et le vibe coding et ça ne va pas plaire à tout le monde, ahahaha.

Hé oui car pendant que le monde tech se déchire entre les évangélistes de l’IA qui veulent tout automatiser et les énervés qui refusent l’IA par principe idéologique, Linus débarque dans le game avec un avis… de complet normie.

Lors de l’Open Source Summit à Séoul qui vient d’avoir lieu, Linus a partagé sa vision sur l’IA générative et le fameux “vibe coding”. Et son avis, c’est que l’IA c’est juste un outil de plus !

Ah putain, ça fait plaisir de lire ça ! ( Tout comme cet article d’ailleurs )

Le vibe coding, pour ceux qui débarquent, c’est ce terme inventé par Andrej Karpathy d’OpenAI qui consiste à décrire ce que vous voulez coder à un LLM. Ce dernière génère alors le code, et vous testez si ça marche ou si ça marche pas. Et ensuite vous demandez des ajustements et ainsi de suite !

Autant dire que c’est devenu un sujet chaud pour pleiiiins de raisons.

Bref, Linus se déclare “plutôt positif” sur le vibe coding mais uniquement comme point d’entrée en informatique. Pour des petits projets, des prototypes rapides…etc c’est top car ça permet à des gens qui ne savent pas coder de faire des trucs super ! Mais après pour du code critique en production, il est cash en expliquant que ça risque d’être “horrible, horrible d’un point de vue maintenance”. Et je ne peux pas lui donner tort.

Linus n’utilise pas personnellement d’IA pour coder mais il voit bien que des gens testent l’IA pour travailler sur du code critique dans le noyau Linux et ça il s’en méfie à raison car les mainteneurs du kernel se prennent régulièrement des bugs reports et des security notices complètement bidons générés par des gens qui utilisent mal les IA.

Les crawlers IA posent aussi des problèmes techniques sur kernel.org car ces bots qui aspirent tout le code pour nourrir leurs modèles font ramer les serveurs. Quoiqu’il en soit, Linus est plutôt modéré sur le sujet de l’IA générative pour coder et attend avec impatience le jour où l’IA sera un truc moins hype. En gros, qu’on arrête d’en parler H24 et qu’on l’utilise juste quand c’est pertinent…

C’est vrai que d’un côté, vous avez ces fifous pro-IA à toutes les sauces qui pensent qu’on va tous devenir des prompt engineers et que les devs vont disparaître (spoiler : non). Et de l’autre, les donneurs de leçons en pureté technologique qui refusent l’IA en bloc sans jamais se poser la moindre question.

Du coup, je vous avoue que je suis content de voir qu’au milieu de tout ce bordel, y’a ce bon vieux Linus qui nous explique que c’est juste un stupide outil et qu’il faut simplement apprendre à l’utiliser intelligemment.