Vous utilisez Claude Code comme moi pour bosser plus vite sur vos projets de dev ? Hé bien j'espère que vous n'avez jamais eu la mauvaise surprise de voir l'agent lancer un petit rm -rf ~/ qui détruit tout votre répertoire home en 2 secondes. Parce que oui, ça arrive malheureusement, et plusieurs devs en ont fait les frais cette année...

Le problème c'est que les agents IA, aussi intelligents soient-ils, peuvent manquer de garde-fous sur ce qui est vraiment dangereux. Vous leur dites "nettoie le projet" et hop, ils interprètent ça un peu trop littéralement et une fois que c'est fait, y'a plus qu'à pleurer devant son terminal vide.

C'est pour ça qu'un développeur du nom de kenryu42 a créé Claude Code Safety Net qui est un plugin pour Claude Code qui agit comme un garde-fou mécanique. Son idée c'est de bloquer les commandes destructives AVANT qu'elles ne s'exécutent, et pas juste avec des règles bêtes genre "si la commande commence par rm -rf".

Le plugin est bien plus malin que ça puisqu'il fait une analyse sémantique des commandes. Il comprend la différence entre git checkout -b nouvelle-branche (qui est safe, ça crée juste une branche) et git checkout -- . qui lui va dégager tous vos changements non committés sur les fichiers suivis. Les deux commencent pareil, mais l'une vous sauve et l'autre vous ruine psychologiquement, vous forçant à vous réfugier dans la cocaïne et la prostitution.

Et c'est pareil pour les force push. Le plugin bloque git push --force qui peut écraser l'historique distant et rendre la récupération très difficile, mais il laisse passer git push --force-with-lease qui est la version plus sûre, car elle vérifie que la ref distante correspond à ce qu'on attend (même si ce n'est pas une garantie absolue).

Et le truc vraiment bien foutu, c'est qu'il détecte aussi les commandes planquées dans des wrappers shell. Vous savez, le genre de piège où quelqu'un écrit sh -c "rm -rf /" pour bypass les protections basiques. Le plugin parse récursivement et repère la commande dangereuse à l'intérieur. Il fait même la chasse aux one-liners Python, Ruby ou Node qui pourraient faire des dégâts.

Côté rm -rf, le comportement par défaut est plutôt permissif mais intelligent... les suppressions dans /tmp ou dans le dossier de travail courant sont autorisées parce que c'est souvent légitime, par contre, tenter de nuke votre home ou des dossiers système, c'est non négociable.

Et pour les paranos (comme moi), y'a un mode strict qu'on active avec SAFETY_NET_STRICT=1. Dans ce mode, toute commande non parseable est bloquée par défaut, et les rm -rf même dans le projet courant demandent validation. Mieux vaut prévenir que pleurer.

Si ça vous chauffe, l'installation se fait via le système de plugins de Claude Code avec deux commandes :

/plugin marketplace add kenryu42/cc-marketplace
/plugin install safety-net@cc-marketplace

Si vous utilisez GitHub Copilot ou ChatGPT pour coder plus vite, voici une nouvelle qui va peut-être vous refroidir un peu. Une fintech a découvert que des attaquants avaient extrait des données clients via un endpoint API qui n'était documenté nulle part. Personne dans l'équipe ne se souvenait l'avoir créé et après 3 semaines d'enquête, le verdict est tombé : c'est Copilot qui l'avait généré pendant une session de code nocturne.

Bienvenue dans l'ère des "phantom APIs" les amis !

J'avoue que le concept m'a fait marrer car on parle quand même d'endpoints qui existent en production mais dont personne n'a connaissance. Ahahaha... y'a pas de documentation, pas de tests, pas de validation de sécurité. C'est juste un peu de code généré par une IA qui a trouvé ça "logique" de créer un /api/v2/admin/debug-metrics qui balance du PII à quiconque tombe dessus par hasard.

J'ai vu le dernier rapport Veracode GenAI Code Security et les chiffres font un peu flipper c'est vrai ! Ils ont testé plus de 100 LLM sur 80 tâches de codage différentes, et le résultat fait mal puisque 45% du code généré par IA contient des vulnérabilités classées OWASP Top 10. En gros, presque une fois sur deux, votre assistant IA vous pond du code troué comme une passoire. Java est le grand gagnant avec 72% de taux d'échec, suivi par Python, JavaScript et C# qui tournent autour de 38-45%.

En effet, l'IA ne pense pas comme un dev qui s'est déjà fait hacker. Par exemple, quand un dev crée un endpoint, il réfléchit authentification, rate limiting, exposition de données, documentation. Alors que l'IA, elle, génère juste ce qui lui semble statistiquement logique vu son dataset d'entraînement, sans comprendre les implications sécurité ou les politiques de l'organisation.

D'ailleurs une autre étude Apiiro montre que les assistants IA ont multiplié par 10 les vulnérabilités introduites en seulement 6 mois dans les dépôts étudiés. Les chemins d'escalade de privilèges ont explosé tout comme les défauts architecturaux. Et le pire c'est que les développeurs qui utilisent l'IA exposent leurs credentials cloud (clés Azure, Storage Access Keys) deux fois plus souvent que les autres.

Y'a aussi le problème du "slopsquatting". Oui, encore un gros mot, je sais... En fait, l'IA peut vous recommander d'installer un package qui n'existe tout simplement pas. Genre elle hallucine un nom de librairie et un attaquant un peu moins con que les autres, peut enregistrer ce nom sur npm ou PyPI et y foutre du code malveillant.

Et là que ça devient vraiment problématique, c'est que les outils de sécurité traditionnels ne voient rien. L'analyse statique compare votre code à des specs documentées, sauf que les phantom APIs n'existent dans aucune spec. Les API gateways protègent les endpoints enregistrés mais laissent passer des routes non déclarées sans authentification.

Pour s'en sortir, certaines boîtes commencent donc à analyser le trafic en temps réel pour détecter les endpoints qui traînent. Y'a aussi l'audit de code spécifique IA pour repérer les patterns de génération algorithmique, et la comparaison continue entre les specs et ce qui tourne vraiment en production.

Bref, relisez votre code généré par IA comme si c'était un stagiaire collégien de 3e qui l'avait écrit, et si vous découvrez un endpoint bizarre dans votre base de code dont personne ne se souvient, y'a des chances que ce soit un "fantôme" laissé par votre copilote préféré...

Boston Dynamics que vous connaissez tous pour ses chiens robots tueurs de la mort, vient de sortir une vidéo de 40 minutes. Pas de saltos arrière ou de robots qui dansent mais plutôt une loooongue session où ça parle stratégie IA et vision à long terme. Et comme j'ai trouvé que c'était intéressant, je partage ça avec vous !

Zach Jacowski, le responsable d'Atlas (15 ans de boîte, il dirigeait Spot avant), discute donc avec Alberto Rodriguez, un ancien prof du MIT qui a lâché sa chaire pour rejoindre l'aventure et ce qu'ils racontent, c'est ni plus ni moins comment ils comptent construire un "cerveau robot" capable d'apprendre à faire n'importe quelle tâche. Je m'imagine déjà avec un robot korben , clone de ma modeste personne capable de faire tout le boulot domestique à ma place aussi bien que moi... Ce serait fou.

Leur objectif à Boston Dynamics, c'est donc de créer le premier robot humanoïde commercialement viable au monde et pour ça, ils ont choisi de commencer par l'industrie, notamment les usines du groupe Hyundai (qui possède Boston Dynamics).

Alors pourquoi ? Hé bien parce que même dans les usines les plus modernes et automatisées, y'a encore des dizaines de milliers de tâches qui sont faites à la main. C'est fou hein ? Automatiser ça c'est un cauchemar, car pour automatiser UNE seule tâche (genre visser une roue sur une voiture), il faudrait environ un an de développement et plus d'un million de dollars.

Ça demande des ingénieurs qui conçoivent une machine spécialisée, un embout sur mesure, un système d'alimentation des vis... Bref, multiplié par les dizaines de milliers de tâches différentes dans une usine, on serait encore en train de bosser sur cette automatisation dans 100 ans...

L'idée de Boston Dynamics, c'est donc de construire un robot polyvalent avec un cerveau généraliste. Comme ça au lieu de programmer chaque tâche à la main, on apprend au robot comment faire. Et tout comme le font les grands modèles de langage type ChatGPT, ils utilisent une approche en deux phases : le pre-training (où le robot accumule du "bon sens" physique) et le post-training (où on l'affine pour une tâche spécifique en une journée au lieu d'un an).

Mais le gros défi, c'est clairement les données. ChatGPT a été entraîné sur à peu près toute la connaissance humaine disponible sur Internet mais pour un robot qui doit apprendre à manipuler des objets physiques, y'a pas d'équivalent qui traîne quelque part.

Du coup, ils utilisent trois sources de data.

La première, c'est la téléopération. Des opérateurs portent un casque VR, voient à travers les yeux du robot et le contrôlent avec leur corps. Après quelques semaines d'entraînement, ils deviennent alors capables de faire faire à peu près n'importe quoi au robot. C'est la donnée la plus précieuse, car il n'y a aucun écart entre ce qui est démontré et ce que le robot peut reproduire. Par contre, ça ne se scale pas des masses.

La deuxième source, c'est l'apprentissage par renforcement en simulation. On laisse le robot explorer par lui-même, essayer, échouer, optimiser ses comportements. L'avantage c'est qu'on peut le faire tourner sur des milliers de GPU en parallèle et générer des données à une échelle impossible en conditions réelles. Et contrairement à la téléopération, le robot peut apprendre des mouvements ultra-rapides et précis qu'un humain aurait du mal à démontrer, du genre faire une roue ou insérer une pièce avec une précision millimétrique.

La troisième source, c'est le pari le plus ambitieux, je trouve. Il s'agit d'apprendre directement en observant des humains.

Alors est-ce qu'on peut entraîner un robot à réparer un vélo en lui montrant des vidéos YouTube de gens qui réparent des vélos ? Pas encore... pour l'instant c'est plus de la recherche que de la production, mais l'idée c'est d'équiper des humains de capteurs (caméras sur la tête, gants tactiles) et de leur faire faire leur boulot normalement pendant que le système apprend.

Et ils ne cherchent pas à tout faire avec un seul réseau neuronal de bout en bout. Ils gardent une séparation entre le "système 1" (les réflexes rapides, l'équilibre, la coordination motrice, un peu comme notre cervelet) et le "système 2" (la réflexion, la compréhension de la scène, la prise de décision). Le modèle de comportement génère des commandes pour les mains, les pieds et le torse, et un contrôleur bas niveau s'occupe de réaliser tout ça physiquement sur le robot.

C'est bien pensé je trouve. Et dans tout ce bordel ambiant autour de la robotique actuelle, eux semblent avoir trouver leur voie. Ils veulent transformer l'industrie, les usines...etc. Leur plan est clair et ils savent exactement ce qu'ils doivent réussir avant de passer à la suite (livraison à domicile, robots domestiques...).

Voilà, je pense que ça peut vous intéresser, même si c'est full english...

Vous savez que depuis quelques années, des startups équipent les camions poubelle et les bus de caméras IA pour cartographier automatiquement l'état des routes ? Comme ça, pendant que le chauffeur fait sa tournée, une intelligence artificielle détecte les nids-de-poule, les fissures et autres joyeusetés routières en temps réel. Chaque défaut est géolocalisé, scoré par gravité, et hop, les équipes de maintenance savent exactement où intervenir.

Bon apparemment, là où j'habite, ils n'utilisent pas ça parce que les routes sont des champs de mines, mais si le Maire se chauffe en DIY, ce projet maintenu par un certain Peter va l'intéresser.

C'est sur GitHub et c'est un stack complet pour faire exactement la même chose que les startups spécialisées en nids de poule... un vrai projet end-to-end avec l'entraînement du modèle sur du GPU cloud, une API backend containerisée, et même une app mobile React Native pour scanner les routes depuis votre téléphone.

Le projet s'appelle pothole-detection-yolo et ça utilise YOLOv8, le modèle de détection d'objets qui fait fureur en ce moment dans le domaine de la vision par ordinateur. Concrètement, le modèle a été entraîné sur un dataset de nids-de-poule disponible sur HuggingFace, avec des images de 640x640 pixels. L'entraînement s'est fait sur Nebius Cloud avec des GPUs H100, donc du sérieux, pas du Colab gratuit qui timeout au bout de 20 minutes.

Ce qui est cool avec ce projet, c'est qu'il ne s'arrête pas au modèle. Y'a une API FastAPI complète qui expose deux endpoints : /detect pour envoyer une image et récupérer les bounding boxes avec les scores de confiance, et /health pour vérifier que le service tourne. Le tout est containerisé en Docker avec support GPU automatique. Et si vous avez pas de carte graphique, ça bascule sur CPU.

Et la cerise sur le gâteau, c'est l'app mobile Expo/React Native. Vous ouvrez l'app, vous prenez une photo d'une route avec votre smartphone, l'image est envoyée à l'API, et vous récupérez les détections en temps réel avec les rectangles dessinés autour des nids-de-poule et les pourcentages de confiance affichés. Bref, c'est exactement ce que font les boites tech à plusieurs millions, sauf que là c'est open source sous licence Apache 2.0.

YOLOv8 atteint facilement entre 93 et 99% de précision pour la détection de nids-de-poule selon les variantes utilisées et des chercheurs ont même combiné YOLOv8 avec des données de nuages de points 3D pour atteindre 95.8% de précision sur des tronçons de tests d'environ 5 km. Bref, c'est du solide et ça fonctionne .

Le truc intéressant pour les bricoleurs, c'est que le modèle entraîné est directement téléchargeable sur HuggingFace donc vous pouvez donc skip toute la partie entraînement si vous voulez juste tester le résultat. Une seule commande Docker pour lancer l'API, et vous êtes opérationnel. Pour les plus motivés qui veulent entraîner leur propre modèle avec des données locales de vos routes françaises pleines de cratères, le code d'entraînement est là aussi avec les configs Ultralytics.

Bref, si vous êtes une petite mairie qui veut cartographier l'état de vos routes sans claquer 50 000 euros dans une solution proprio, ou juste un dev curieux de voir comment fonctionne la stack derrière ces caméras intelligentes qu'on voit de plus en plus sur les véhicules de service, ce projet est une mine d'or.

Tout est là , documenté, et ça fonctionne du feu de dieu.

Voilà un outil qui va plaire à ceux qui chassent les failles de sécurité... Ce projet s'appelle Security Skills et c'est un système de compétences pour agents IA (genre Claude Code ou Gemini CLI) qui transforme votre proxy mitmproxy en chasseur de failles automatisé. Vous lui dites "trouve-moi des problèmes de sécurité sur example.com" et l'IA se met à analyser le trafic HTTP intercepté en appliquant des patterns qu'elle a appris de vrais bugs rémunérés.

Le mec derrière cet outil a commencé par récupérer 10 000 rapports de bugs sur HackerOne via un dataset Hugging Face, qu'ensuite, il a filtré pour ne garder que les 4000 qui ont reçu un paiement, partant du principe que si une boîte a sorti le portefeuille, c'est que la faille était sérieuse. Et avec ces 4000 exemples concrets, il a créé 17 Skills différents qui savent détecter des trucs comme les IDOR (quand vous pouvez accéder aux données d'un autre utilisateur juste en changeant un ID dans l'URL), les SSRF, les injections SQL, les fuites de secrets et j'en passe.

Ce qui est malin avec cette approche, c'est qu'il n'a pas essayé de tout coller dans le prompt système du LLM. Comme sa première version avec 150 descriptions de bugs collées directement dans les instructions faisait exploser les coûts et le contexte, il a décidé de découper ça en modules réutilisables. Chaque Skill étant un fichier markdown avec ses propres patterns de détection, quand vous demandez à l'IA de chercher des failles d'authentification, elle va chercher le bon Skill et l'appliquer intelligemment.

Le système tourne avec CodeRunner, un serveur MCP open source qui exécute du code IA dans une sandbox isolée sur Mac donc c'est plutôt moderne, et ça utilise aussi les conteneurs natifs d'Apple pour l'isolation et ça supporte pas mal de LLM différents comme Claude, ChatGPT, Gemini ou même des modèles locaux.

Et le succès est au rendez-vous car l'auteur raconte avoir testé son système sur Vercel et trouvé une faille sur leur endpoint /avatar?u=USERNAME qui permettait d'énumérer les noms d'utilisateurs. Le genre de bug classique IDOR que l'IA a repéré automatiquement en analysant le trafic capturé. Bon, c'est pas le hack du siècle, mais ça prouve que le système arrive à appliquer ce qu'il a appris des vrais rapports de bug bounty.

Pour l'installer, faut cloner le repo CodeRunner, puis lancer l'installeur et le serveur MCP deviendra accessible localement. Ensuite vous pouvez l'utiliser avec n'importe quel client compatible MCP, que ce soit Claude Desktop, Gemini CLI ou même votre propre interface. Les Security Skills sont dans un repo séparé et contiennent toute la logique de détection dérivée des 4000 rapports en question.

Voilà encore un bel exemple de comment on peut vraiment utiliser les LLM pour des tâches de sécurité concrètes, et pas juste pour générer du code. Et j'ai trouvé l'idée d'apprendre à partir de vrais bugs payés plutôt que de documentation théorique, plutôt pas con.

Voilà, si vous faites du bug bounty ou que vous voulez automatiser vos tests de sécu, ça vaut le coup d'y jeter un œil .

Vous avez des tonnes de vieux documents papier qui traînent dans des cartons, des factures scannées à l'arrache, des formulaires remplis à la main, des tableaux Excel imprimés puis re-scannés par quelqu'un qui n'a visiblement jamais entendu parler du concept de "bien faire son boulot" ?

Considérez que ce problème est réglé puisque Mistral AI vient de sortir OCR 3, un modèle de reconnaissance de documents qui promet de transformer tout ça en données exploitables, et pour pas cher en plus.

Le modèle est capable de déchiffrer du cursif dégueulasse, des annotations griffonnées dans les marges, voire du texte manuscrit par-dessus des formulaires imprimés. Mistral montre même une démo avec une lettre au Père Noël écrite par un gamin et l'OCR arrive à en extraire le contenu structuré. Bon, c'est cool pour les lettres au Père Noël, mais surtout ça veut dire qu'il peut gérer vos ordonnances médicales ou les notes de réunion de votre collègue qui écrit comme un cochon.

Niveau performances, Mistral annonce un taux de victoire de 74% sur leur précédent modèle OCR 2 et sur les solutions concurrentes. Et comme c'est testé sur des cas réels d'entreprises avec des mesures de précision en fuzzy-match, on n'est pas dans du benchmarks théoriques bidon. Le modèle gère les scans pourris avec compression JPEG, les documents de travers, les faibles résolutions, le bruit de fond... Bref, tout ce qui fait que l'OCR traditionnel vous sort de la bouillie.

Et ce qui est vraiment intéressant, c'est surtout la reconstruction structurelle car contrairement aux OCR classiques qui vous crachent un bloc de texte en vrac, Mistral OCR 3 reconstruit la structure du document. Les tableaux complexes avec cellules fusionnées et hiérarchies de colonnes ressortent en HTML propre avec les colspan et rowspan préservés. Vous obtenez du markdown enrichi en sortie, directement exploitable par vos systèmes sans avoir à nettoyer le bordel derrière.

Côté tarifs, c'est 2 dollars pour 1000 pages et si vous passez par l'API Batch, c'est moitié moins cher à 1 dollar les 1000 pages. Pour un modèle qui se dit plus petit que la plupart des solutions concurrentes tout en étant plus précis, c'est plutôt compétitif. Le modèle peut traiter jusqu'à 2000 pages par minute sur un seul nœud, donc même si vous avez des millions de documents à numériser, ça devrait pas prendre des plombes.

Vous faites un peu de l'électronique et vous utilisez KiCad pour vos PCB ?

Et si l'avenir de la conception électronique c'était aussi l'IA ? J'en sais rien mais ce qui a l'air de se profiler à l'horizon avec ce dataset qui vient de sortir sur Hugging Face et qui devrait intéresser pas mal de monde. Ça s'appelle Open Schematics et c'est une collection de plus de 84 000 schémas électroniques au format KiCad, prêts à être utilisés pour entraîner des modèles d'IA.

Le truc c'est que jusqu'à maintenant, si vous vouliez créer une IA capable de comprendre ou de générer des schémas électroniques, y'avait pas vraiment de dataset propre et bien structuré pour ça. Bhupendra Hada (alias bshada sur Hugging Face) a donc décidé de combler ce manque en compilant tout ça à partir de projets hardware open source trouvés sur GitHub.

Chaque entrée de son dataset contient donc le fichier schéma brut au format .kicad_sch, une image PNG du rendu, la liste des composants utilisés, et des métadonnées en JSON et YAML. Du coup vous avez tout ce qu'il faut pour entraîner un modèle à faire du text-to-image, de l'image-to-text, ou de la génération de circuits à partir de specs.

Le dataset pèse 6,67 Go au format Parquet et couvre une variété de projets assez dingue. On y trouve des cartes de programmation UART, des amplificateurs à tubes, des onduleurs triphasés open source, des points d'extrémité Zigbee, des projets ESP32+RS232, et même des macropads custom. Bref, y'a de tout, du projet étudiant au truc bien avancé.

Ce qui est cool c'est que le dataset est structuré pour plusieurs cas d'usage. Vous pouvez l'utiliser pour entraîner une IA à reconnaître des composants sur un schéma, à générer de la documentation automatique depuis un circuit, à détecter des erreurs de conception, ou même à suggérer des améliorations. Y'a aussi un potentiel éducatif évident pour créer des outils d'apprentissage interactifs en électronique.

Bien sûr, la qualité et la complexité des schémas varient pas mal d'un projet à l'autre. Certains ont des métadonnées incomplètes, et les conventions de nommage des composants sont pas toujours cohérentes... C'est le souci quand on scrappe des projets open source, y'a du bon et du moins bon mais pour un dataset de cette taille, c'est déjà une base de travail solide.

Le tout est sous licence CC-BY-4.0, donc vous pouvez l'utiliser librement du moment que vous créditez la source. Que vous bossiez sur de l'IA appliquée à l'électronique ou que vous cherchiez juste une grosse base de schémas KiCad à explorer, c'est clairement une ressource à bookmarker.

Source