Hubert, fidèle lecteur de Korben.info m'a envoyé un mail pour me dire qu'il avait reçu sa nouvelle carte d'identité. Vous savez celle en petit format avec la puce dedans qu'on peut scanner avec l'app France Identité. Et il en est bien content !

Voilà, l'histoire s'arrête là !

Mais non, je plaisante ! En fait, Hubert s'est posé LA question que personne ne se pose à l'heure de l' identité numérique européenne : Y'a quoi là dedans ?

Et plutôt que d'attendre qu'un employé de mairie expert en technologie ne lui explique (j'rigole, ça n'existe pas), il a passé son week-end à coder cnie-python-tools , un projet codé en python (vous aviez deviné je pense) capable de lire la puce de la CNI et de vous ressortir les infos y compris la photo d'identité.

Le tout sous Linux, évidemment, sans smartphone ni app officielle.

Pour l'utiliser, vous devez brancher un lecteur de carte à contact (un ACR38U , un Omnikey (liens affiliés), ce genre de bestiole compatible PC/SC), vous lancez uv run cnie-dump, et vous tapez le CAN, c'est-à-dire les 6 chiffres imprimés au recto de votre carte.

Photo envoyée par Hubert, je me suis permis d'enlever ses données personnelles #RGPD-way-of-life ^^

Y'a besoin de cette clé car c'est elle qui permet de déverrouiller la puce via un protocole qui s'appelle PACE. C'est ce mécanisme précis qu'utilise la carte France Identité quand elle lit votre carte en NFC sauf que là c'est direct sur votre PC. Son script permet alors de récupérer toutes les data dans des fichiers bruts + un summary.json qui liste tout ce que la carte a bien voulu cracher.

Et c'est qu'elle est bavarde cette coquine, puisqu'avec ce simple script, elle vous sort votre état civil complet (nom, prénoms, date et lieu de naissance, nationalité), votre adresse, votre taille, la MRZ (la fameuse bande de caractères qu'on retrouve aussi sur les passeports), mais aussi la photo qui est dessus au format JPEG 2000, un format parfois un peu pénible à ouvrir.

Bref, de quoi remplir un formulaire administratif sans avoir à tout retaper.

Maintenant rassurez-vous, il y a quand même des données qu'on ne peut pas extraire. Sur la CNIe française, la donnée biométrique sensible, ce sont vos deux empreintes digitales (DG3), et celles-là restent bouclées à double tour derrière l'EAC, une couche de sécurité réservée aux terminaux officiels de l'État. Quand le script tape à cette porte, la carte répond aussi sèchement qu'un agent assermenté sans clim, avec le code 6982, ce qui veut dire "security status not satisfied", cause toujours.

Si ça vous dit d'essayer bien sûr, c'est à utiliser uniquement avec votre propre carte. Et si le lecteur sur la photo ci-dessus vous parle, c'est normal. Plutôt que d'acheter un lecteur de carte tout neuf, Hubert a simplement réalisé ses tests avec le lecteur fourni par les TCL (le réseau de transport Lyonnais) qui visiblement est dans le tur-fu en ce qui concerne la recharge des abonnements de métro ^^.

Merci Hubert pour le partage !!

cnie-python-tools

Swift, le langage maison qu'Apple a sorti en 2014 pour remplacer le vieillissant Objective-C, vient de débarquer sur une machine qui a quarante-neuf ans de plus que lui. Yeo Kheng Meng, un bidouilleur basé à Singapour, a restauré un Apple II Plus puis s'est demandé jusqu'où il pouvait pousser ce vieux tromblon, ce qui a donné SwiftII, un petit environnement Swift qui tourne aussi bien sur l'Apple II d'origine de 1977 que sur les IIe qui ont suivi.

Jean-Marc Biechy est prof d'électronique et d'informatique à l'Institution Saint-Jean de Colmar et il vient de m'envoyer un truc qui m'a scotché. Avec ses élèves, il bidouille des projets Arduino, et plutôt que d'empiler des bouts de code à chaque nouveau montage, il a fait un choix un peu fou : écrire son propre système d'exploitation en partant de zéro pour un microcontrôleur.

Ça s'appelle IoToS, pour Internet of Things micro Operating System, et ça transforme un Arduino UNO R4 ou un ESP32/8266 en vrai petit nœud réseau avec un accès en ligne de commande qui ressemble vachement à du bon vieux terminal Linux.

Vous branchez la carte, vous ouvrez un terminal série (ou un Telnet sur le port 23), et là vous tapez des commandes comme ping, tracert, netstat, dir, ip ou dhcp on tout ça directement sur Arduino.

Ce qui est chouette avec son approche c'est qu'elle est pédagogique car un Arduino tout nu, c'est un automate avec un setup() qui s'exécute une fois, une loop() qui tourne en boucle à l'infini, et basta.

Et à l'autre bout du spectre, vous avez de vrais OS temps réel (RTOS), souvent trop gros ou trop austères pour intéresser un élève de Bac Pro. Et entre les deux, y'avait rien qui faisait vraiment le pont entre l'automate et un vrai petit OS avec sa ligne de commande.

Jean-Marc a donc créé ce chaînon manquant en découpant son code exactement comme un OS. Un Boot Firmware avant le setup, un Load Driver qui gère la connexion réseau et l'écran, un Kernel qui n'est autre que la loop(), un CLI dans un fichier shell_Cmdline.h, et des applis par-dessus.

La bestiole embarque donc un serveur web AJAX qui sert des pages HTML depuis une carte MicroSD, un serveur FTP pour balader les fichiers via FileZilla, une synchro NTP et un datalogger CSV horodaté. Le tout sur un noyau coopératif, sans RTOS, le code métier de votre projet étant compilé dans le même firmware.

Et c'est là qu'on mesure le boulot d'orfèvre puisque ce firmware complet tient dans 142 Ko, soit 54% de la flash de l'UNO R4, et il reste près de 19 Ko de RAM libre sur les 32. Caser un shell réseau, un serveur web et du FTP là-dedans sans tout faire planter, c'est pas donné à tout le monde, le mec est doué !

Et avec cette base, ses élèves montent des prises IP commandables au navigateur, une caméra de surveillance sur LilyGo déclenchée par un détecteur de mouvement, une station météo consultable en ligne, une alarme PIR qui envoie un mail, de la gestion de chauffage à distance, ou du pilotage de LED RVB et de projecteurs DMX par Ethernet.

La prise IP sert d'ailleurs de système minimal de référence, et le reste, vous pouvez l'étendre en ajoutant vos propres commandes CLI et vos pages web dans les fichiers .h prévus pour.

Jean-Marc raconte y avoir passé environ 2000 heures de code et de tests, juste pour voir si c'était possible d'en écrire un tout seul. Il est parti de bibliothèques existantes (LittleFS, ping, FTP, dir) qu'il a patiemment fait discuter ensemble... Faut dire que recoder un OS de zéro pour le plaisir d'apprendre , c'est un sport à part entière et malheureusement, trop peu de gens d'y essayent.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/iotos-micro-os-arduino-esp32/iotos-micro-os-arduino-esp32-1.mp4">lien vers la vidéo</a>.

Le conseil de pilotage de Python, l'instance qui tranche les grandes décisions du langage, a demandé le 5 juin la suspension de tout nouveau développement sur son compilateur JIT.

Un JIT (just-in-time), c'est un compilateur à la volée : au lieu d'interpréter votre code ligne par ligne, il traduit les portions les plus sollicitées en instructions machine pendant l'exécution, histoire de gagner en vitesse. Python en a un, expérimental, depuis la version 3.13 sortie début 2024.

Le problème n'est pas le code. Il est dans la procédure.

Ce JIT est arrivé dans la branche principale de CPython, l'implémentation de référence du langage, sans passer par le circuit de décision habituel. Chez Python, toute évolution majeure doit faire l'objet d'un PEP, un document formel que la communauté discute puis valide. Celui qui couvre le JIT, le PEP 744 signé Brandt Bucher et Savannah Ostrowski, n'est qu'informatif et laisse plusieurs questions en suspens : la maintenance future, la compatibilité avec l'outillage existant, les critères de réussite mesurables.

Le conseil l'a reconnu noir sur blanc : il n'a pas été "aussi strict sur le respect du processus qu'un changement de cette ampleur le méritait". Responsabilité partagée, donc.

En pratique, plus aucune nouvelle fonctionnalité JIT ne peut atterrir sur la branche principale tant qu'un PEP en bonne et due forme n'est pas accepté. Les corrections de bugs et de sécurité, elles, continuent. Le conseil laisse une fenêtre de six mois pour soumettre et faire valider ce document. Passé ce délai, faute d'accord, le code du JIT sera purement et simplement retiré.

Le timing est mauvais. Le JIT amélioré était l'une des nouveautés mises en avant de Python 3.15, dont les fonctionnalités sont déjà gelées et dont la sortie est attendue en octobre. Sur du x86-64 sous Linux, il promet un gain de 8 à 9% en moyenne, même s'il reste désactivé par défaut et consomme 10 à 20% de mémoire en plus.

Mark Shannon, un des principaux contributeurs, n'a pas caché son agacement. Pour lui, tout arrêter d'un coup fait perdre l'élan et risque de faire fuir les nouveaux venus, alors il réclame une période de grâce pour avancer pendant que le PEP se construit. Barry Warsaw, lui, a demandé pourquoi le travail ne pourrait pas se poursuivre dans un dépôt séparé le temps des discussions.

La réponse du conseil tient en une idée : mettre le développement en pause évite que le JIT devienne une cible mouvante pendant qu'on débat de son sort.

Du coup, on se retrouve avec une techno qui fonctionne, déjà embarquée dans le langage, suspendue à un document qui n'existe pas encore.

Geler une techno qui marche pour une procédure oubliée, c'est agaçant sur le moment. Mais sur un langage utilisé par des millions de gens, c'est probablement plus prudent.

Source : The Register

Un développeur connu sous le pseudonyme icitry s'est posé une question que personne de sensé ne formule jamais, peut-on coder un jeu de tir à la première personne en COBOL ? La réponse, contre toute attente, est oui, et le résultat est même tout à fait jouable.

Pour ceux que ce nom laisse de marbre, COBOL, pour Common Business Oriented Language, est un langage né en 1959 qui fait encore tourner aujourd'hui une partie des mainframes chargés de vos virements bancaires et de la paie. C'est l'outil de la gestion et des relevés de compte, à peu près l'inverse de ce qu'on imagine pour un jeu vidéo.

Avec la sortie de CUDA 13.3, NVIDIA renforce son écosystème GPU sur deux fronts importants. La version Python passe officiellement en 1.0 (donc considérée comme stable et utilisable en production), et CUDA Tile arrive nativement pour les développeurs C++.

Petit rappel pour les non-initiés : CUDA, c'est l'outil que tout le monde utilise pour faire tourner du calcul sur les cartes graphiques NVIDIA, principalement pour l'IA et le calcul scientifique. 

Historiquement, c'est du C/C++ à 99%. NVIDIA pousse depuis quelques années pour rendre tout ça accessible en Python, et ce passage en 1.0 marque une étape importante. À partir de maintenant, l'API ne changera plus brutalement entre les versions mineures.

En pratique, les développeurs peuvent désormais compter dessus pour leurs projets long terme. La version 1.0 ajoute aussi le support des "green contexts" (un système pour réserver une partie de la GPU à des tâches isolées) et du checkpointing CUDA (la possibilité de sauvegarder l'état d'une exécution GPU pour la reprendre plus tard).

L'autre gros morceau, c'est CUDA Tile pour C++. Le modèle de programmation "tile" consiste à découper un calcul en blocs uniformes traités en parallèle, plutôt que de gérer chaque fil d'exécution individuellement (la GPU en fait tourner des milliers en même temps).

Il était déjà disponible en Python via des bibliothèques comme Triton. Il arrive maintenant en C++. L'idée est de monter d'un cran en abstraction : vous décrivez ce que vous voulez faire au niveau du bloc, et le compilateur s'occupe de mapper ça sur les threads. Le support couvre les GPU Hopper (l'architecture haut de gamme de NVIDIA pour les datacenters IA) et toutes les architectures plus récentes.

En bonus, NVIDIA introduit CompileIQ, un framework d'auto-tuning du compilateur qui promet jusqu'à 15% de gain sur des opérations critiques comme la multiplication de matrices ou les mécanismes d'attention utilisés dans les modèles d'IA. Le support du C++23 dans les compilateurs NVCC et NVRTC est aussi de la partie.

Pour les développeurs IA, c'est une nouvelle version importante. La programmation GPU est toujours un domaine très technique, mais NVIDIA réduit progressivement la barrière d'entrée, surtout côté Python. AMD a du boulot pour rattraper son retard avec ROCm, leur équivalent maison qui peine encore à convaincre la communauté.

Source : Phoronix

Alexander Petros, qui tient le blog Unplanned Obsolescence , a publié un tutoriel d'environ 3 500 mots qui explique les bases de Prolog, un langage de programmation logique des années 70 très différent des langages courants comme Python ou JavaScript, en utilisant les combats Pokémon comme support pédagogique. C'est étonnamment efficace.

Pour ceux qui n'ont jamais touché Prolog, la grosse différence avec un langage classique style Python ou JavaScript, c'est qu'au lieu de dire à l'ordinateur comment résoudre un problème étape par étape, vous lui décrivez les règles du jeu et vous le laissez chercher les réponses tout seul.

Vous écrivez des faits ("Bulbizarre est un Pokémon", "Bulbizarre est de type plante"), des règles ("un Pokémon vulnérable à X subit le double de dégâts d'une attaque de type X"), et vous posez ensuite des questions au système. Il fait le reste..

L'angle Pokémon est plutôt malin. Les combats Pokémon, c'est en fait un moteur de règles assez tordu : types, faiblesses, talents passifs, priorités d'attaques, statuts.

Bref, exactement le genre de domaine où Prolog brille et où un langage impératif transpire. Petros part de requêtes très simples ("est-ce que Carapuce est un Pokémon ?") et finit avec des filtres complexes qui sélectionnent les équipes en fonction de leur composition. À chaque étape, l'équivalent en SQL serait dix fois plus lourd.

Le passage le plus parlant, c'est quand il ajoute le support du talent Farceur, qui donne une priorité supérieure aux attaques de statut. Implémenter cette règle a pris trois minutes : il a ajouté une seule clause logique au programme.

Faites le même boulot dans un tableur ou une base SQL, et vous repartez pour des heures. C'est exactement le genre de cas où on comprend pourquoi Prolog a une niche stable, même si personne ne s'en sert au quotidien dans l'industrie.

Côté pédagogie, le choix est bon. La plupart des tutoriels Prolog vous balancent des relations familiales du style "Marie est la fille de Pierre, qui est le mari de...", ce qui marche mais reste relativement abstrait. Là, vous lisez le code et vous voyez immédiatement à quoi ça sert : à modéliser un combat Pokémon. Du coup les concepts d'unification, de prédicats et de négation passent presque tout seuls.

Si vous avez toujours voulu vous mettre à Prolog mais que les tutoriels classiques vous tombaient des mains, l'article de Petros est le point de départ qu'il vous faut.

Source : Hackaday

Wolfenstein 3D, pour ceux qui n'étaient pas nés en 1992, c'est le FPS qui a tout lancé. Le jeu de Carmack et sa bande chez id Software, qui a directement mené à DOOM l'année suivante.

Eh bien un dev Rust vient de le recréer de zéro, et c'est 100% jouable dans le navigateur.

Iron Wolf , c'est donc le projet de Michael Bohn, un allemand, qui bosse sur ce truc depuis mai 2021, soit près de cinq ans. On n'est donc pas sur un portage vibe codé à l'arrache. C'est vraiment une réécriture complète.

La version web d'Iron Wolf tournant dans le navigateur

Le bonhomme a carrément créé ses propres crates Rust pour émuler la carte VGA et la puce sonore OPL. J'ai d'abord cru qu'il réutilisait une lib existante, mais non, il a tout écrit from scratch en Rust. Bah ouais, développer ses propres librairies d'émulation hardware juste pour un side-project, what else ?? Je trouve que ça force le respect !

Le truc cool, c'est que la version shareware du jeu est incluse directement dans le dossier testdata/ du repo. Du coup sur macOS, Linux ou Windows, un git clone + just run-sdl-shareware et hop, vous voilà dans les couloirs du château. Attention sur Ubuntu 22.04, faut avoir libsdl2-dev d'installé avec apt install libsdl2-dev, sinon la compilation plante avec une erreur cryptique. Par contre, si vous êtes sur la version Ubuntu 24.04, là ça passe direct. Et si vous avez les fichiers WAD du jeu complet qui traînent sur un vieux CD-ROM quelque part, ce sera encore mieux car la version web permet de les uploader pour jouer à l'intégrale.

Ça tourne donc en WebAssembly sur wolf.ironmule.dev , sans plugin, juste Chrome ou Firefox récent. Voilà, si vous vous demandiez si on peut encore jouer au classique en 2026... la réponse est carrément oui !

Pour les curieux, le raycasting, cette technique de rendu qu'utilisait Wolfenstein 3D, est réimplémenté très fidèlement puisque le moteur de Michael dessine les murs comme le code de Carmack le faisait à l'époque... sauf que là ça tourne dans un onglet de navigateur. Vos fichiers de jeu sont également stockés localement via IndexedDB et un service worker gère le mode hors-ligne ce qui est très pratique pour jouer en avion ou quand on est chez Free (je décoooonnnne, humour humour).

Le projet en est à sa version 0.9.0, sous licence GPL-3.0 et si les classiques d'id Software recréés par des passionnés vous branchent, sachez que DOOM aussi a ses portages bien sympas.

Bref, si la nostalgie du raycasting vous titille, allez faire un tour sur wolf.ironmule.dev.

MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.

Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est RustFS , codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

En ce magnifique mardi matin, moi et mon mal de crâne, nous avons découvert un truc assez cool qui est un genre de wiki personnel en markdown, comme Obsidian ou Notion, mais avec un super pouvoir qui est que vous pouvez y écrire du code qui s’exécute directement dans vos notes !! Hé oui, du vrai code ! Pas des plugins, pas des extensions, mais du code Lua intégré dans votre texte comme si vos notes étaient devenues un environnement de dev à part entière.

Ça s’appelle SilverBullet , c’est open source (licence MIT), et franchement, si vous avez déjà bidouillé des configs Neovim ou des scripts Redis, vous allez kiffer car c’est beaucoup plus simple ^^.

Ça ressemble à n’importe quel wiki markdown moderne. Vous écrivez vos notes en local, elles sont stockées en fichiers statiques .md, vous avez des liens bidirectionnels pour connecter vos idées, et l’interface est optimisée avec des raccourcis clavier. C’est évidemment une Progressive Web App qui fonctionne 100% hors ligne ( comme expliqué sur leur site ), et vous gardez le contrôle total sur vos données, puisque tout est auto-hébergé sur votre machine ou votre serveur.

Ainsi, avec le scripting Lua intégré, vous pouvez littéralement taper ${10 + 2} dans une note et le résultat s’affichera en temps réel : 12 (vous l’aviez les matheux ?? ^^). Et si vous voulez une liste de vos 5 dernières pages modifiées qui se met à jour automatiquement, suffit d’écrire un petit bout de Lua, et hop, votre wiki devient “vivant”.

Alors oui, je sais ce que vous allez me dire, Obsidian a Dataview, Logseq a ses requêtes en Datalog…etc donc c’est pareil non ?

Et bien pas vraiment parce que Dataview ça vous demande quand même d’apprendre un DSL (Domain Specific Language) avec une syntaxe bizarroïde et de vous palucher les 50 pages de doc. Logseq quand à lui vous balance du Datalog sans trop d’explications. Alors que SilverBullet, lui, vous laisse écrire du Lua. Et le Lua, c’est simple, c’est dispo partout (Neovim, Redis, les addons World of Warcraft, OSB, etc.), c’est documenté, et c’est fait pour être embarqué dans des applications.

Si vous êtes data scientist, vous connaissez sûrement les Jupyter Notebooks qui sont markdown avec du code Python exécutable dedans. Hé bien SilverBullet fait exactement la même chose, mais pour vos notes personnelles. Vos notes ne sont plus des fichiers inertes, mais deviennent des mini-programmes qui peuvent calculer, générer du contenu, réagir à des événements…etc

Tenez par exemple, vous pouvez définir une fonction custom directement dans une page :

-- Additionner deux nombres
function adder(a, b)
 return a + b
end

command.define {
 name = "Insérer signature",
 run = function()
 local date = os.date("%Y-%m-%d")
 editor.insertAtCursor("---\nÉcrit le " .. date, false, true)
 end
}

slashCommand.define {
 name = "todo",
 run = function()
 editor.insertAtCursor("- [ ] |^|", false, true)
 end
}

event.listen {
 name = "page:save",
 run = function(e)
 local content = editor.getText()
 local word_count = select(2, content:gsub("%S+", ""))
 editor.flashNotification("Nombre de mots : " .. word_count)
 end
}

chmod +x silverbullet
mkdir mes-notes
./silverbullet mes-notes

.\silverbullet.exe mes-notes

docker run -p 3000:3000 -v ~/mes-notes:/space ghcr.io/silverbulletmd/silverbullet

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

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

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

J’ai une super nouvelle pour vous si vous êtes dev que vous vous intéressez à l’IA générative ! Microsoft vient de sortir une formation complète et gratuite sur son outil GitHub Copilot, et avec les nouvelles fonctionnalités qui débarquent en 2025, c’est le moment ou jamais de s’y mettre.

La formation “Mastering GitHub Copilot for AI Peer Programming” propose donc 10 heures de contenu (en anglais) réparti en plusieurs modules, du niveau débutant jusqu’aux fonctionnalités les plus avancées. Et le timing est parfait parce que GitHub Copilot vient de passer en mode agent, ce qui change complètement la donne. Ce n’est plus d’un simple outil d’autocomplétion mais d’un véritable collègue virtuel qui peut analyser votre base de code, proposer des modifications, exécuter des tests et même corriger ses propres erreurs.

Si vous utilisez Claude Code, le nouvel assistant de programmation d’Anthropic qui vit directement dans votre terminal, vous allez kiffer ce que je vais vous montrer aujourd’hui. Y’a un développeur nommé Anton Knoery (NomenAK sur GitHub) qui vient de sortir SuperClaude, un framework de configuration qui transforme Claude Code en véritable machine de guerre pour les développeurs.

Attention, ce n’est pas encore un outil avec 150 dépendances Node.js à la con qui va foutre le bordel dans votre système. Non non, SuperClaude c’est de la pure configuration, zéro code, zéro dépendance externe. Le truc s’installe tranquillement dans votre dossier ~/.claude/ et améliore discrètement les capacités de Claude Code dans tous vos projets.

Codestral, le tout nouveau modèle de code de Mistral AI, débarque pour le plus grand plaisir (ou pas) des développeurs ! Créé par l’équipe de Mistral AI et lancé hier, Codestral est donc un modèle de génération de code ouvert spécialement conçu pour les tâches de génération de code. Il maîtrise plus de 80 langages de programmation, dont les incontournables Python, Java, C++, JavaScript et même le vénérable Fortran.

Si vous galérez sur une fonction, il vous aidera à la compléter en 2 coups de cuillère à pot et si vous avez besoin de tests, cet expert les génèrera à votre place pendant que vous serez parti à la machine à café. Grâce à sa capacité de remplissage au milieu (fill in the middle), il pourrait ainsi compléter n’importe quel bout de code, même le plus complexe.

En termes de performance, il établit de nouveaux records. C’est un modèle de 22 milliards de paramètres, mais grâce à sa fenêtre contextuelle de 32 000 tokens, il surpasse les autres modèles sur de nombreux benchmarks, y compris le RepoBench pour la génération de code à longue portée. Sur des tests spécifiques comme HumanEval, MBPP pour le Python et Spider pour le SQL, Codestral affiche également des performances impressionnantes devant GPT-4-Turbo et GPT-3.5.

Ce modèle est accessible sur HuggingFace, où vous pouvez le télécharger et avec l’API de Mistral AI, quelques lignes de code suffisent pour l’intégrer dans votre projet. Les adeptes de VSCode et JetBrains seront ravis puisque les plugins Continue.dev et Tabnine ont également intégré ce modèle, pour coder et interagir avec lui directement dans votre IDE préféré. Vous pouvez également y avoir accès via le Chat de Mistral.

Perso, j’utilise Claude 3 Opus et GPT-4o pour mon code mais je vais commencer à tester celui-là également. En tout cas, si ça vous intéresse, rendez-vous sur la documentation officielle de Mistral AI ici.

Source

Les langages de programmation, c’est vraiment un truc incroyable. Ça nous permet de façonner le monde et nos usages mais vous êtes-vous déjà demandé à quel âge les développeurs derrière ces langages avaient conçu leurs bébé ?

Prenons par exemple ce bon vieux Dennis Ritchie, le créateur du célèbre langage C. Et bien, figurez-vous qu’il avait sa modeste 31ème bougie sur son gâteau d’anniversaire quand il a créé ce monument en 1972. Pas mal, non ?

Et JSON, ce format de données ultra populaire ? Son inventeur, Douglas Crockford, avait déjà 46 ans bien tassés quand il a sorti ce truc en 2001. Comme quoi, il n’y a pas d’âge pour innover ! Et que dire de Kenneth E. Iverson, qui a créé le langage J à l’âge de 70 ans en 1993 ? Respect l’ancien !

D’ailleurs, si on regarde les statistiques de plus près, on se rend compte que la moyenne d’âge pour créer un langage de programmation est de 37,5 ans. Avec un record à 70 ans pour Kenneth E. Iverson avec J et un jeune prodige qui a fait ses preuves à 16 ans. Devinez qui c’est ? Roulement de tambour…

Mais oui, c’est bien Aaron Swartz ! Ce petit génie qui nous manque cruellement, a créé le format atx en 2002 à l’âge où la plupart d’entre nous galérait encore sur les équations du second degré. C’était déjà impressionnant et par la suite, Il a d’ailleurs continué à innover, travaillant plus tard avec John Gruber pour créer le format Markdown en 2004.

En parlant de jeunes prodiges, saviez-vous que Rasmus Lerdorf a créé PHP à seulement 27 ans en 1995 ? Et oui, pendant que certains cherchaient encore leur voie en fac de socio, lui changeait déjà la face du développement web !

Et à contrario, regardez aussi TypeScript (2012, Anders Hejlsberg, 52 ans), Go (2009, Rob Pike, Ken Thompson et Robert Griesemer, 53 ans en moyenne) et Clojure (2007, Rich Hickey, 48 ans), ces langages ont été concoctées par des quadras et des quinquas bien expérimentés ! La preuve que l’expérience a du bon.

Notons également que Brendan Eich a créé JavaScript à 34 ans en 1995, Guido van Rossum a développé Python à 35 ans en 1991, et Tim Berners-Lee a inventé HTML à 36 ans la même année. Quant à Richard Stallman, il a conçu Emacs Lisp à 32 ans en 1985 et avant ça Emacs à l’age de 23 ans en 1976.

Bref, si vous rêvez de créer votre propre langage de dev ou votre propre format de données et que vous arrivez dans votre quarantaine ou que vous êtes un petit jeune qui sort à peine de l’école, y’a pas d’age pour vous lancer. C’est fun et gratifiant, et qui sait, peut-être que votre petit monstre deviendra le prochain C ou JavaScript !

Source

Tetris sur NES – c’est un classique indémodable, un monument du jeu vidéo mais c’est aussi un terrain de jeu sans fin pour les hackers et les bidouilleurs de génie. Tenez-vous bien, ces derniers ont trouvé un moyen de reprogrammer Tetris en pleine partie ! Je vous jure, c’est pas une blague. Ils arrivent à exécuter leur propre code en partant d’une cartouche normale, sans aucune modification matérielle.

Voici comment ça marche :

En atteignant des scores très élevés (comme le niveau 155) et en entrant des noms bien spécifiques dans le tableau des high scores, ils réussissent à réécrire des portions de la RAM du jeu. Concrètement, ils peuvent modifier les règles, ajouter des fonctionnalités, ce qu’ils veulent.

Mais le plus dingue, c’est quand ils font leur tour de magie. Bah oui, vous connaissez le fameux kill screen de Tetris ? C’est ce moment où après une partie marathon, il y a tellement de données que le jeu plante… Et bien nos petits génies provoquent volontairement ce crash qui en réalité, devient leur porte d’entrée pour injecter leur code personnel.

Techniquement, ils exploitent une faille dans la gestion des manettes car sur les Famicom, il y avait un port d’extension pour brancher des manettes supplémentaires et quand le jeu crashe, il perd les pédales et va interpréter n’importe quoi comme instruction, y compris les fameuses entrées de manettes. Résultat : vous appuyez sur des boutons bien précis au bon moment, et ça redirige l’exécution du programme exactement où vous voulez !

Évidemment, tout ça c’est d’un niveau de difficulté extrême, il faut connaître le jeu et la console sur le bout des doigts. Mais comme ils ont désassemblé le code de Tetris en langage machine, ils savent exactement ce que fait chaque octet de la ROM. Et la beauté de la chose, c’est que ça fonctionne sur une NES standard, avec une cartouche originale. Pas besoin d’un Game Genie ou d’un émulateur. Du 100% pur jus rétro…

Par contre, il ne faut pas être trop gourmand non plus. On parle de reprogrammer un jeu en passant par les high scores, donc vous n’aurez jamais de quoi coder un truc plus complexe… et puis il faut rusher le truc à chaque partie, parce que dès que vous éteignez la console, pouf ça s’efface. C’est vraiment de la bidouille éphémère, il faut aimer l’art pour l’art.

Mais je trouve ça cool car il y a un côté  »hacker la Matrice » assez jouissif. Ça me donne presque envie de ressortir ma vieille NES pour essayer… Mais je suis pas encore assez bon à Tetris. Mais si vous voulez essayer chez vous, il vous faudra :

• Une NES (ou une Famicom)
• La cartouche Tetris
• 2 manettes NES supplémentaires (ou un adaptateur pour manettes NES sur Famicom)
• De la patience et de la persévérance

Ensuite, vous devrez franchir chacune de ces étapes :

• Étape 1 : Atteignez le level 155 en mode A-Type. Assurez-vous qu’une seule ligne vous sépare du level suivant.
• Étape 2 : Effacez cette ligne SANS appuyer sur bas (pour ne pas marquer de points) et en affichant la pièce suivante dans la zone Next.
• Étape 3 : Branchez vos deux manettes NES supplémentaires (appelons-les manette 3 et manette 4).
• Étape 4 : Sur la manette 3, maintenez Haut. Sur la manette 4, appuyez simultanément sur Gauche, Bas et Droite (bonne chance…).
• Étape 5 : Maintenant, préparez-vous à entrer dans la partie la plus délicate : l’écriture de votre programme via les high scores ! L’astuce consiste à utiliser les noms et scores pour y cacher des instructions destinées directement au processeur de la NES. Pour cela, vous devez placer judicieusement certains caractères dans les high scores. Par exemple, mettez (G comme 2ème lettre du nom en 1ère position du tableau B-Type. Cela indique au processeur de sauter vers une autre zone du tableau et de lire la suite comme un bout de code. Ensuite, en 2ème position B-Type, commencez le nom par )). Puis continuez à remplir les noms et scores suivants selon votre programme. Attention, vous êtes très limité dans les instructions possibles ! Vous ne pouvez utiliser que les 43 caractères autorisés pour les noms et les 10 chiffres pour les scores. La plupart des opcodes du processeur sont impossibles à reproduire ainsi. Mais avec de l’astuce, c’est jouable. Par exemple, essayez ceci pour votre 1ère position en A-Type : (A name of '))"-P)' . Ce code basique injecte deux zéros dans les digits de poids fort du score, ce qui limite son augmentation et retarde le crash du jeu (sans le corriger complètement).
• Étape 6 : Validez le high score. Le jeu va planter, c’est normal. Maintenez les boutons enfoncés sur les manettes 3 et 4.
• Étape 7 : Tadaa ! Votre code personnalisé s’exécute. Vous pouvez maintenant modifier le comportement du jeu. Mais attention, tout s’efface à la prochaine coupure !

Voilà, vous savez tout. Avec un peu d’entraînement, vous pourrez à votre tour hacker Tetris comme un pro mais n’oubliez pas, c’est un grand pouvoir qui se mérite et qui implique de grandes responsabilités ! (non)

Happy hacking !

Source

Bonne nouvelle ! Flyde, un nouvel outil de programmation visuelle pour les développeurs, vient de sortir en Alpha et ça déchire grave !

Bon, je vous vois venir : « Encore un énième outil low-code à la mode… » Que nenni ! Flyde est vraiment unique et a été conçu pour s’intégrer parfaitement à votre base de code existante, que ce soit pour du back-end, du front, des scripts d’automatisation ou même des outils en ligne de commande.

Le truc de ouf avec Flyde, c’est qu’il permet de visualiser et de créer facilement les flux haut-niveau (flows en anglais) de votre application, tout en gardant votre code textuel pour ce qui est bas-niveau. En gros, il sublime votre code « de plomberie » qui intègre plusieurs API de manière hyper concurrente. Vos diagrammes sur Powerpoint deviennent enfin une réalité !

Et les avantages sont multiples :

• La collaboration avec les profils non-dev (product owners, QA, support…) devient hyper intuitive. C’est comme si Zapier et votre base de code avaient un bébé !
• Les flux servent de documentation vivante et toujours à jour pour les nouveaux membres de l’équipe.
• La programmation visuelle ouvre de nouveaux modes de réflexion sur le code. Les nœuds s’illuminent même quand les données les traversent, c’est hypnotique !
• Et les données de monitoring sont directement sur le « code » lui-même. Ainsi, le débogage n’a jamais été aussi rapide.

Mais alors comment ça marche ce truc ?

Et bien Flyde est composé d’un éditeur visuel (extension VS Code ou standalone), d’une bibliothèque d’exécution et d’une bibliothèque plutôt bien fournie de composants prêts à l’emploi.

Dans l’éditeur visuel, on construit des flux en connectant des nœuds via une interface « nodes-and-wires ». On peut alors mixer des nœuds customs et ceux de la bibliothèque de composants. Une fois un flux créé, on peut ensuite l’exécuter depuis son code en utilisant la bibliothèque d’exécution de Flyde. Et c’est là que la magie opère !

Car Flyde ne cherche pas à remplacer vos workflows existants mais à les sublimer. Contrairement à d’autres outils low-code qui vivent en dehors de votre base de code, Flyde s’y intègre complètement. Les fichiers de flux sont committés dans votre gestionnaire de version comme n’importe quel autre fichier, les branches, les pull requests, les revues de code fonctionnent de manière transparente, les flux sont exécutés depuis votre base de code, en réutilisant votre environnement de prod. Comme ça, pas besoin de gérer une plateforme externe ni de vous soucier de la sécurité. Enfin, ces même flux peuvent être testés avec vos frameworks de test habituels. Vous pouvez même écrire des tests en Flyde qui testent votre code traditionnel !

L’intégration avec le code existant se fait de deux manières astucieuses : Premièrement, les noeuds Flyde peuvent être des noeuds visuels ou des noeuds basés sur du code. On peut donc wrapper n’importe quelle fonction de sa base de code dans un noeud Flyde utilisable dans un flux.

Secondo, les flux de Flyde peuvent s’exécuter depuis votre code. Par exemple, si vous construisez my-cool-flow.flyde, il faudra appeler execute('my-cool-flow') dans votre code puis gérer la réponse. Les cas d’usage sont infinis : Gestionnaire de requêtes HTTP, bot, scripts, etc.

Bon, vous l’aurez compris, Flyde s’inspire des principes de programmation basée sur les flux (FBP) mais d’autres outils font déjà ça, comme Node-RED ou NoFlo, bien avant l’arrivée du bouzin.

Quelle est la plus-value de Flyde du coup ?

Déjà, Flyde adopte une approche plus pragmatique et simple que NoFlo qui était un poil trop inspiré par la vision puriste de J. Paul Morrison, l’inventeur du FBP. Ensuite, l’éditeur est une extension VS Code, donc intégré à votre IDE, alors que les autres ont des éditeurs indépendants voire carréement datés. Et surtout Flyde est davantage taillé pour coexister avec les bases de code traditionnelles et toucher un public de développeurs plus large sur des projets variés.

Si vous voulez vous faire la main sur Flyde, le mieux est d’aller direct sur la sandbox en ligne qui permet de créer et d’exécuter des flux dans le navigateur. Puis jetez un œil aux tutos pour intégrer Flyde dans un vrai projet.

Perso, je vois plusieurs cas d’usage hyper prometteurs pour Flyde. C’est d’abord un super accélérateur pour les juniors et les non-devs qui pourront prototyper rapidement des trucs qui claquent sans se prendre la tête. Ca permet également de booster la collaboration en ouvrant sa base de code aux gens du marketing ou à l’équipe produit.

De plus, c’est un formidable outil pédagogique aussi ludique que scratch pour enseigner des concepts de programmation avancés aux étudiants. Sans oublier le gain de productivité pour les devs expérimentés qui aiment bien avoir une vue d’ensemble sur des architectures d’API ou de microservices complexes.

Bref, je suis convaincu que Flyde (ou un de ses futurs fork) va changer notre façon de coder dans les années à venir. Si vous couplez ça à l’IA, ça va faire un malheur.