Un site sans cookie de mesure d'audience et sans bandeau de consentement, c'est reposant je trouve... Sauf qu'à cause de ça, bah je ne savais plus trop combien de gens venaient me lire tous les jours. Relou hein ?

C'était ma situation depuis un moment déjà, vu que tout ce qui servait à mesurer l'audience a dégagé de korben.info il y a un bon bout de temps. Alors faute de mieux, je me suis rabattu sur AWStats, qui lit bêtement les logs Apache du serveur mais bon, c'est pas terrible, parce qu'avec le cache de Cloudflare, il y a une grosse partie de mon trafic qui n'est pas pris en compte.

En effet, quand Cloudflare possède une copie valide de la page dans son cache, il peut la renvoyer directement sans contacter le serveur d'origine. Vous êtes donc bien un visiteur réel, mais Apache ne voit aucune requête et AWStats ne vous comptabilise pas. Du coup, tous les outils fondés exclusivement sur les logs d'origine sous-estiment la part du trafic absorbée par le cache.

Après il y a bien le classique Google Analytics, mais bon même configuré en mode full RGPD, ça reste Google et ça appelle quand même un service tiers aux US... Vous connaissez aussi déjà des alternatives propres, puisque je vous ai parlé de Matomo, Plausible et de Vince Analytics , mais elles ajoutent toutes une mesure côté navigateur, avec un script, un pixel ou un stockage local (le localstorage) et moi, je ne voulais aucun outil d'audience de plus dans vos pages !

De son côté, Cloudflare lui, voit chaque requête HTTP qui atteint son réseau, y compris celles auxquelles son cache répond. Ses chiffres couvrent donc beaucoup mieux le trafic HTTP que mes logs d'origine. Le souci, c'est que son dashboard, je ne l'aime pas. Je le trouve incomplet, mal foutu, chiant à utiliser, et il ne montre pas ce que j'ai envie de voir.

Donc, histoire d'avoir ce que je voulais, j'ai fini par coder le mien. Enfin, entièrement vibe codé et ça tourne aussi bien sur un serveur qu'en local sur une machine de bureau.

Petite parenthèse pendant que j'y suis, vous ne le savez peut-être pas mais depuis que ChatGPT a débarqué dans nos vies fin 2022, tout ce que je développe moi-même sur ce site et l'ensemble de mes outils internes sont vibes codés avec des LLMs comme ceux d'OpenAI et d'Anthropic. C'était une purge au tout début et maintenant ça s'est tellement amélioré et je me suis tellement spécialisé là-dedans, que le code n'est devenu qu'une formalité. Ne hurlez pas, mon site est statique et j'envoie pas de fusée dans l'espace !

Mon collecteur s'exécute en local, cause à une API, et il n'envoie pas une seule ligne de mesure dans votre navigateur. Bref, que mon backend soit écrit avec un LLM, à la main ou en Brainfuck, vous chargez exactement la même chose de mon outil de stats, c'est-à-dire rien du tout. La garantie est donc architecturale et pas une question de talent.

Et surtout, mon outil de stats n'ajoute aucune mesure dans votre navigateur. Aucun JavaScript ni cookie supplémentaire n'est posé par mon outil. À la place, il lit l'API GraphQL Analytics de Cloudflare, en lecture seule et récupère des compteurs déjà agrégés par jour et par dimension. Cela veut dire par exemple, que quand je récupère le nombre "nombre d'IP distinctes par jour", je ne récupère pas les IPs en tant que telles mais juste un total que Cloudflare me communique et qu'il a déjà traité en amont.

Et vous n'êtes pas obligés de me croire sur parole, parce que c'est vérifiable en 10 secondes... Ouvrez l'inspecteur de votre navigateur, onglet Réseau, et rechargez cette page. Vous ne verrez aucun script de mesure d'audience, aucun appel vers un domaine tiers et aucune iframe. Même les vidéos YouTube ne se chargent qu'au moment où vous cliquez sur la vignette. Le seul truc qui bouge, c'est le compteur du footer qui télécharge un nombre, sans rien renvoyer derrière.

Attention, ce n'est pas à confondre avec Cloudflare Web Analytics et ses mesures RUM (Real User Monitoring) puisque cette fonctionnalité injecte un bout de JavaScript pour mesurer les performances ressenties dans le navigateur. Chez moi, c'est désactivé tout ça.

Maintenant soyons clairs sur un point, parce que c'est l'objection évidente et qu'elle est parfaitement légitime... Cloudflare, lui, voit bien votre adresse IP. Pas à cause de mon outil de stats, mais parce que c'est un reverse proxy et que c'est mécaniquement ce qui se passe dès qu'un site est derrière un CDN. Votre requête arrive chez eux avant d'arriver chez moi, sinon ils ne pourraient ni router, ni mettre en cache, ni bloquer une attaque. Mon outil ne change rien à ça, il se contente de lire des totaux déjà calculés et je ne récupère jamais la moindre IP. Tout est détaillé dans mes CGU, avec les bases légales, les durées et la liste des cookies de sécurité, si vous voulez le détail complet.

Mon outil et le compteur que vous pouvez retrouver dans le footer de mon site reposent sur les requêtes collectées côté serveur chez Cloudflare et sans l'analyse web, je ne peux juste pas suivre par exemple un parcours utilisateur, connaitre un taux de rebond ou évaluer les temps de chargement mesurés chez les lecteurs. Rien de grave donc...

Maintenant, il y a un souci chez Cloudflare, c'est que selon le jeu de données et le forfait que vous payez ou non, le détail ne reste interrogeable que durant une fenêtre limitée de temps. Mon outil doit donc passer chaque jour récupérer les agrégats encore disponibles et les stocker dans une base SQLite sur mon serveur ou en local, selon la façon dont on l'a déployé.

Ça me permet de garder mon propre historique agrégé. J'ai aussi activé le Super Bot Fight Mode de Cloudflare, qui réduit une large partie du trafic automatisé, mais attention, ça ne me donne pas pour autant des stats sans aucun bot. Les crawlers autorisés comme Googlebot et ceux qui passent entre les mailles du filet restent comptabilisés dans mes chiffres, exactement comme avec tous les autres outils de mesure web. Et je préfère le dire clairement plutôt que de vous vendre des chiffres "propres" qui ne le sont jamais totalement, vu qu'un filtre anti-bot ne peut retirer que les bots qu'il a détectés.

À côté de ça, j'ai aussi branché ma Google Search Console, et là non plus sans installer la moindre bibliothèque tierce... Je signe moi-même un JWT en RS256 avec le module crypto natif de Node, je l'échange contre un jeton d'accès chez Google, et le compte de service que j'utilise est restreint au scope lecture seule. Ça m'apporte des statistiques agrégées sur les impressions, les positions, les requêtes de recherche et surtout Discover !!

Si je devais résumer ça, je dirais que Cloudflare estime le volume de trafic et que Search Console montre quelles recherches produisent des impressions et des clics, même si sans aucun tracking en place, ça n'explique évidemment pas la motivation de chaque lecteur. Mais osef ! Et comme Cloudflare embarque aussi son pare-feu, j'en profite pour rapatrier des statistiques sur les événements de sécurité et les routes attaquées, comme ça, je peux tout voir au même endroit.

Maintenant, le vrai plaisir, c'est de pouvoir afficher ce que je veux dans mon propre dashboard. Par exemple, la répartition par langue, les navigateurs, d'où provient le trafic avec un joli petit camembert, les pays, l'état de mon cache, la bande passante, etc. Et quand j'ai un nouveau besoin qui me pête dans le cerveau, je peux ajouter une vue rapidement et je ne m'encombre pas de ce qui ne me sert pas.

Sans traceur placé chez vous, je ne connais donc pas les sessions, le taux de rebond, le parcours de lecture, les entonnoirs de conversion, donc impossible de savoir si vous êtes revenu hier, ni dans quel ordre vous avez lu 3 articles. Mais je m'en tape complètement puisque ces métriques ne m'ont jamais servi à rien.

Ce que je veux connaitre, c'est surtout l'ordre de grandeur de l'audience et le nombre de pages demandées. Le parcours individuel et les entonnoirs de conversion, c'est surtout un besoin de régie publicitaire ou de site e-commerce, et pas d'un site comme le mien. Quand on sait que les bandeaux de cookies nous coûtent 575 millions d'heures perdues collectivement, et que l'Europe réfléchit enfin à les alléger , s'en passer n'est pas vraiment une punition.

Bref, mes stats sont maintenant plus digestes que celles d'AWStats, sans avoir à vous tracker ou vous faire charger quoi que ce soit. Ça me va donc très bien. Et si vous voulez un avant-goût de la technique derrière l'outil, j'ai montré récemment comment vous faire un compteur de fréquentation gratuit , donc n'hésitez pas à y jeter un œil...

Dropbox vient de sortir un plugin pour Claude Code , et leur idée c'est de pouvoir brancher vos fichiers Dropbox directement dans vos sessions de dev Claude Code / Cowork.

Alors je me suis demandé à quoi ça pouvait bien servir et voici ce que j'ai compris. Une fois que le plugin est en place, ça permet à Claude Code d'aller piocher dans votre Dropbox vos docs techniques, vos cahiers des charges, votre code...etc pour s'en faire du contexte. Tout devient de la matière fraiche pour corriger ou générer du code et quand c'est fini, ce qui est produit peut être à son tour stocké sur Dropbox.

Le plugin sait récupérer les fichiers en fonction de leur nom, de mots clés, de leur emplacement et bien sûr en fonction de leurs méta données. Même vos liens partagés il sait comment les gérer. Bref, il fait tout simplement le passe-plats entre tout le bordel que vous stockez sur Dropbox et Claude Code.

Cela dit, gardez la tête froide parce que tout ce que l'IA lit part sur les serveurs d'Anthropic pour être traité. Donc évitez quand même de le lâcher sur le dossier qui contient vos contrats, vos mots de passe ou vos données clients. Lui autoriser juste un dossier dédié avec ce que vous acceptez de partager, ce sera plus sain.

Pour l'installer, ça se passe dans Claude Code sur le web. Vous filez dans le menu Personnaliser, Connecteurs puis vous cherchez Dropbox en parcourant les plugins et vous cliquez sur ajouter. Une auth OAuth plus tard (vos identifiants Dropbox habituels), c'est branché. Un petit /reload-plugins et le plugin s'active alors dans la session en cours.

En plus de ce plugin, Dropbox propose également un serveur MCP classique en ligne de commande qui est un peu plus souple et surtout peut se brancher dans Cursor, Claude Desktop ou Devin.

Un bémol quand même, c'est pas open bar... sniiif. Eh oui, Dropbox plafonne tout ça à 5 Mo par fichier lu ou créé via l'intégration, et le contenu pondu par Claude ne se sauvegarde qu'en texte (.txt, .md, .html, .py), et pas en image ni en PDF. Quant aux limites de débit de l'API, on ne les connaît pas.

Bref, pour les gros fichiers ou les binaires, faudra donc passer par autre chose.

Si vous vivez dans Claude Code et que votre vie est rangée dans Dropbox, ça vaut peut-être le coup de jeter un œil ici.

Tarek, fidèle lecteur de Korben.info m'a envoyé un mail pour me présenter TenMatch , un site web qu'il a codé qui permet de trouver un tournoi de tennis près de chez vous.

Vous le savez, le sport et moi, ça fait 2, alors peu de risque que j'utilise son site. Mais je sais que parmi vous, y'en a qui pratiquent cette forme étrange de ping pong où on est sur la table, comme disait l'autre, alors ça va surement venir se rajouter à vos bookmarks.

La problématique dont s'occupe TenMatch, c'est donc de rechercher pour vous un tournoi du TenUp, qui est l'outil officiel mais reconnu comme une chianlie à utiliser (je vous fais confiance là dessus, j'en sais rien). TenMatch va donc piocher dans les mêmes données publiques de la FFT, les resynchronise chaque nuit, et vous les ressert avec de vrais filtres.

Vous sélectionnez votre classement, la surface que vous voulez, la proximité avec un lieu et même le budget que vous avez, vu qu'une inscription c'est en général 20 balles.

Vous obtenez alors une liste avec les tournois, date par date et vous n'avez plus qu'à vous y inscrire via TenUp. Bref, TenMatch fait le tri, la Fédé encaisse, tout le monde est content.

Bref, si vous tapez dans la baballe, allez jeter un œil à TenMatch. Moi je retourne à mon sport de prédilection, rester assis à vous pondre des articles incroyables !! Et merci à Tarek pour le partage.

Vous supprimez une clé API Google qui a fuité , et l'interface vous confirme que c'est bien réglé, que la clé ne fonctionne plus. Alors vous commencez à vous détendre en vous disant que vous avez bien fait votre boulot.

BAH NAN !

Car vous ne le savez pas, mais cette clé va continuer de fonctionner encore durant 23 minutes. C'est en tout cas ce qu'ont mesuré les chercheurs d'Aikido Security en testant ce truc tout bête de révoquer une clé, puis de taper sur l'API en boucle pour voir quand ça s'arrêtait vraiment.

Et résultat des courses, une clé API classique survit en moyenne 16 minutes après sa suppression, et jusqu'à 23 minutes dans le pire des cas. Cela veut dire que pendant tout ce temps, un attaquant qui a récupéré votre clé peut continuer de l'utiliser peinard. Et vous n'avez aucun moyen de couper plus vite, ni même de savoir quand ça s'arrête pour de bon.

Ce sont les clés API de Schrödinger le bordel... Techniquement comme vous vous en doutez, c'est surtout une histoire de propagation car Google ne tue pas la clé d'un coup sur tous ses serveurs, mais l'info se diffuse petit à petit, et chaque serveur arrête de l'accepter à son rythme. Le souci, c'est que ce délai et largement suffisant par exemple pour vider un bucket pendant que vous pensez que le danger est écarté.

Le plus beau, c'est que Google sait parfaitement faire vite quand il veut puisque les clés de compte de service, elles, sont coupées en 5 secondes. et les clés Gemini récentes en 1 minute. Du coup, ces 16 minutes de moyenne sur les vieilles clés API n'ont rien d'une fatalité technique... c'est juste un choix ! Aikido a bien sûr remonté le problème, et Google a bizarrement classé le ticket en « won't fix », en expliquant que ce délai de propagation était une propriété connue du système, et pas une faille de sécurité.

Donc si vous gérez des clés Google en prod, partez du principe qu'une clé compromise reste exploitable une bonne demi-heure après sa révocation. Et surtout, mettez en place des plafonds de dépenses bien serrés sur votre projet parce que le vrai cauchemar, c'est moins l'accès que la facture qui débarque ensuite. On a déjà vu des devs se prendre des notes à cinq chiffres à cause d'une clé qui traîne, et des utilisateurs Google Cloud facturés par erreur .

Source : Aikido Security

Votre vieux Galaxy S5 qui prend fort la poussière dans un tiroir, mérite mieux je crois !

Un dev, Capcom6 a mis en ligne SMS Gateway for Android , une app Kotlin sous licence Apache 2.0 qui transforme n'importe quel smartphone (Android 5.0+) en passerelle SMS programmable. Cela vous permet de récupérer une API REST pour ensuite envoyer et recevoir vos SMS avec votre propre téléphone et votre propre SIM et ainsi vous passer de services payants équivalents.

Il y a 3 modes au choix. Le mode local quand l'app lance un serveur HTTP sur le port 8080, accessible depuis votre réseau. Le mode cloud où l'app se connecte au service tiers api.sms-gate.app, ce qui est pratique pour ceux qui ont une IP dynamique ou plusieurs appareils. Et le mode "private server" qui permet d'héberger le backend chez vous, en totale autonomie.

Mais dans tous les cas, les requêtes restent les mêmes à savoir du bon vieux POST JSON avec basic auth.

Et côté fonctionnalités, y'a tout ce qu'il faut. Multi-SIM si votre téléphone est compatible, messages multipart automatiquement découpés pour les SMS longs, suivi de statut en temps réel (sent, delivered, failed), webhooks pour 8 événements différents (sms:received, sms:sent, sms:delivered, sms:data-received, mms:downloaded, system:ping...). Et puis du chiffrement bout-en-bout activé sur le mode cloud, comme ça personne ne peut lire vos messages en clair.

Maintenant vous vous demandez peut-être à quoi ça peut servir ??

Bah je pense à de l'envoi SMS 2FA pour vos applications, tout ce qui est messages transactionnels (confirmations de commande, rappels de RDV), des notifications push via SMS, et même du data SMS binaire pour piloter des périphériques IoT à distance. Pourquoi pas ? Y'a plus de limites après... Ah et y'a aussi une intégration n8n officielle (ici sur le repo example-webhooks-n8n ) pour brancher l'API à vos workflows, plus une bibliothèque PHP sur Packagist. Bref, y'a un petit écosystème qui commence à se développer autour.

Pour l'installer, oubliez le Play Store. capcom6 distribue uniquement des APK sur les GitHub Releases. Faut donc activer les sources inconnues, télécharger le .apk, et installer manuellement.

Après quand on fait le calcul côté pognon c'est vite vu. Twilio par exemple facture $0.0083 par SMS aux US, plus 1,15 $ / mois par numéro, plus les frais. Donc pour 1000 SMS par mois c'est vite entre 50 à 80 $. Avec SMS Gateway for Android et votre forfait perso, vous ne payez rien d'autre que votre forfait...

Après y'a quelques limites à connaître... Par exemple, si vous pensiez faire de l'envoi massif pour du marketing (comprenez du spam), votre opérateur va évidemment bloquer rapidement votre SIM. Et puis évidemment, faut que le téléphone soit allumé h24 avec sa connexion data activée. Donc pour du transactionnel léger c'est nickel mais pour du mass-mailing, oubliez ! De toute façon, n'oubliez pas, y'a une place pour vous en enfer, les spammeurs.

Voilà, donc si vous avez un vieux smartphone Android qui fait dodo dans un tiroir et que vous avez besoin d' une API SMS pour vos automations perso ou votre stack interne, c'est une alternative à Twilio très sympa !

Anthropic, la boîte derrière l'IA Claude, a racheté Stainless pour plus de 300 millions de dollars. Stainless, c'est un nom que le grand public ne connaît pas, mais l'outil est partout : il transforme automatiquement la spécification d'une API, l'interface par laquelle deux logiciels se parlent, en SDK.

Pour rappel, un SDK, c'est un ensemble de bibliothèques de code prêtes à l'emploi pour les développeurs, ici dans une dizaine de langages comme Python, TypeScript, Go ou Java.

En clair, quand un développeur veut brancher son application sur l'API de Claude, il utilise un SDK généré par Stainless. La boîte, fondée en 2022 par un ancien ingénieur de Stripe, a produit chaque SDK officiel d'Anthropic depuis les tout débuts de l'API Claude. Le rachat consolide donc une brique que l'entreprise utilisait déjà tous les jours.

Stainless ne s'arrête pas aux SDK. La société fournit aussi de l'outillage pour les serveurs MCP, le protocole poussé justement par Anthropic qui permet aux IA de se connecter à des outils et des données externes. Du coup le rachat fait sens à double titre : Anthropic met la main sur la génération de SDK et sur une partie de l'infrastructure MCP, deux briques où il veut clairement être central.

Sauf que voilà le détail un peu fou. Stainless ne servait pas qu'Anthropic, et sa liste de clients comprend OpenAI, Google DeepMind, Perplexity, Groq et Cloudflare, autrement dit la plupart des concurrents directs d'Anthropic sur le marché de l'IA.

La suite est sans pitié. Anthropic ferme tous les produits hébergés de Stainless, générateur de SDK compris. Les clients actuels gardent les SDK déjà générés et peuvent les modifier, mais le robinet, lui, est coupé. Tout le monde va devoir trouver une alternative ou rapatrier la génération de SDK en interne.

Pourquoi mettre 300 millions sur la table pour ça ? Parce que la vraie bataille n'est plus seulement sur les modèles d'IA, mais sur la couche d'outillage autour.

Celui qui contrôle la façon dont les développeurs branchent leurs applications et orchestrent leurs agents IA contrôle une partie de l'écosystème. OpenAI muscle son propre Agents SDK de son côté. Anthropic, lui, préfère racheter directement l'usine, et au passage priver ses concurrents d'un fournisseur bien pratique.

Source : TechCrunch

60 Mo de source maps (ces fichiers qui permettent de remonter du code minifié à l'original) ont été oubliés dans un paquet npm. Et voilà comment Anthropic a involontairement balancé en public le code source complet de Claude Code, son outil à 2.5 milliards de dollars de revenus annuels.

Alors qu'est-ce qui s'est passé exactement ?

Hé bien hier, la version 2.1.88 du package @anthropic-ai/claude-code sur le registre npm embarquait un fichier .map de 59.8 Mo. Un truc normalement réservé au debug interne, sauf que ce fichier .map contenait les pointeurs vers les 1 900 fichiers TypeScript originaux, en clair. Chaofan Shou, un développeur chez Solayer Labs, a alors repéré la boulette et l'a partagée sur X. Le temps qu'Anthropic réagisse, le code était déjà mirroré partout sur GitHub, avec 41 500+ forks en quelques heures. Autant dire que le dentifrice ne rentrera pas dans le tube !

Pour ma part, j'avais un petit dépôt à moi assez ancien avec quelques trucs relatifs à Claude Code, qui n'avait rien à voir avec tout ça, qui s'est même retrouvé striké... Ils ratissent large avec leur DMCA donc.

Et là, c'est la fête pour les curieux comme moi parce que les entrailles de l'outil révèlent pas mal de surprises. Côté architecture, on découvre environ 40 outils internes avec gestion de permissions, un moteur de requêtes de 46 000 lignes de TypeScript, un système multi-agents capable de spawner des essaims de sous-tâches en parallèle, et un pont de communication entre le terminal et votre éditeur VS Code ou JetBrains. Le tout tourne sur Bun (pas Node.js ^^) avec Ink pour l'interface terminal. Par contre, pas de tests unitaires visibles dans le dump.

Côté mémoire, c'est plutôt bien pensé puisqu'au lieu de tout stocker bêtement dans la fenêtre de contexte du modèle, l'outil utilise un fichier texte MEMORY.md ultra-léger (genre 150 caractères par entrée) qui sert d'index de pointeurs. Les vraies données, elles, sont distribuées dans des fichiers thématiques chargés à la demande, et les transcripts bruts ne sont jamais relus entièrement, mais juste fouillés à la recherche d'identifiants précis. L'agent traite en fait sa propre mémoire comme un "hint" ce qui le force à vérifier toujours le vrai code avant d'agir. En gros, il a une mémoire sceptique, et pour moi c'est clairement le truc le plus intéressant du dump.

Y'a aussi un truc qui s'appelle KAIROS (mentionné 150 fois dans le code) qui est un genre de mode daemon autonome. En fait, pendant que vous allez chercher votre café, l'agent tourne en arrière-plan et fait ce qu'ils appellent autoDream : il consolide sa mémoire dans des fichiers JSON, vire les contradictions et transforme les observations vagues en données structurées. Comme ça, quand vous revenez devant votre écran, le contexte est nettoyé.

Et puis le code balance aussi la roadmap interne d'Anthropic (bon courage au service comm ^^). On y trouve les noms de code des modèles... Capybara pour un variant de Claude 4.6, Fennec pour Opus 4.6, et un mystérieux Numbat qui n'est pas encore sorti. D'ailleurs, les commentaires internes révèlent que Capybara v8 a un taux de fausses affirmations qui tourne autour de 30%, ce qui est une grosse régression par rapport aux 17% de la v4. Y'a même un "Undercover Mode" qui permet à l'agent de contribuer à des repos publics sans révéler d'infos internes (c'est sympa pour les projets open source).

Anthropic a confirmé la fuite : "C'était un problème de packaging lié à une erreur humaine, pas une faille de sécurité. Aucune donnée client n'a été exposée." Mouais, attention quand même, parce que le code est déjà partout et n'en repartira pas. Et même si aucun secret client n'a fuité, exposer l'architecture complète d'un agent IA à 2.5 milliards de revenus, c'est pas rien non plus.

Bon, et maintenant qu'est-ce qu'on peut en faire ? Bah pas mal de choses en fait.

Par exemple, le système de mémoire auto-correcteur est un pattern directement réutilisable pour vos propres agents IA. L'architecture "index léger + fichiers à la demande" résout élégamment le problème de la pollution de contexte qui fait halluciner les LLM sur les longues sessions. Les +40 outils internes permettent aussi de comprendre comment structurer un système de permissions granulaires dans un agent autonome . Et le concept KAIROS/autoDream, la consolidation mémoire pendant l'idle, c'est une idée qu'aucun outil open source n'implémente encore. Autant dire que les alternatives open source à Claude Code ou Codex vont monter en gamme dans les jours qui viennent. Et le code est déjà nettoyé, réécris en Rust et mis sur GitHub si vous voulez fouiller. Bon, pas sûr que le pattern autoDream soit simple à reimplémenter, mais le système de mémoire oui.

Je trouve ça assez marrant que le code proprio d'une boite qui a aspiré tout l'open source du monde voire plus, sans autorisation, pour le revendre sous la forme de temps machine / tokens, devienne lui aussi en quelque sorte "open source" sans qu'on leur demande leur avis ^^. La vie est bien faite.

Maintenant, pour les développeurs qui publient sur npm, la leçon est limpide : Vérifiez votre .npmignore et votre champ files dans package.json. Ou plutôt, lancez la commande npm pack --dry-run dans votre terminal avant chaque publish. Ça prend 2 secondes et ça vous montre exactement ce qui sera inclus dans le paquet. Ça aurait évité 60 Mo de secrets industriels qui partent en public.

Bref, un .npmignore bien configuré, ça coûte 0 euro. Alors qu'une fuite de propriété intellectuelle évaluée à 2.5 milliards... un peu plus !

Source

Les clés API Google que vous collez dans votre JavaScript pour afficher une carte Maps... hé bien elles ne sont plus si inoffensives. Car depuis que Gemini est entré dans la danse, ces mêmes clés donnent maintenant accès à vos fichiers privés et surtout à votre facture IA.

Et personne ne nous a prévenu...

En gros, Google utilise un format de clé unique, les fameuses AIza..., aussi bien pour Maps et Firebase (public, collé dans le HTML, tout le monde s'en fout) que pour Gemini (privé, accès aux fichiers, facturation). Le problème c'est que quand vous activez l'API Gemini sur un projet Google Cloud, TOUTES les clés existantes de ce projet héritent automatiquement de l'accès Gemini. Sans warning, sans notification, sans rien... Ouin !

Les chercheurs de TruffleSecurity ont ainsi trouvé presque 3000 clés API Google valides dans le dataset Common Crawl de novembre 2025. Des clés qui trainent dans du code JavaScript, des pages HTML, des repos GitHub publics... et qui fonctionnent sur l'endpoint Gemini. Il suffit d'un simple curl avec une clé Maps récupérée sur un site web, et hop, vous accédez à l'API Gemini du propriétaire. Fichiers privés, contenu en cache, facturation sur son compte.

Et parmi les victimes, on trouve des institutions financières, des boîtes de cybersécurité, et... Google eux-mêmes (oui oui, vraiment).

Le 21 novembre 2025, TruffleSecurity signale donc le problème et la réponse de Google le 25 novembre c'est : "intended behavior" (comportement normal)... Sauf que le 2 décembre, Google a reclassifié ça en bug, puis le 13 janvier 2026, ça passe finalement en Tier 1. On est donc passé du "c'est normal les frérots" à "ah oui quand même, oupsi oups", en 7 semaines.

Maintenant, pour ceux qui se demandent si leurs clés API Google sont concernées, direction console.cloud.google.com , section "APIs & Services" puis "Identifiants".

Si vous voyez l'API " Generative Language " de Gemini API activée sur un projet avec des clés non restreintes... attention, c'est le moment de faire le ménage. Ajoutez des restrictions IP ou HTTP referrer, et surtout, utilisez des comptes de service plutôt que des clés API pour tout ce qui touche à Gemini (sauf si vous aimez les surprises sur votre facture ^^).

Le truc tordu, c'est que la doc Firebase dit noir sur blanc que les clés API ne sont pas des secrets. Google Maps vous dit carrément de les coller dans votre HTML. Et maintenant, ces mêmes clés donnent accès à une IA qui peut lire vos fichiers. Du CWE-1188 pur et dur ! Et c'est pas la première fois que Google se fait taper sur les doigts pour ce genre de souci avec Gemini .

Du coup, Google a annoncé des nouvelles mesures, du scoped defaults, du blocage de clés fuités, des notifications proactives...etc. Reste donc à voir si ça arrivera avant que les presque 3000 clés exposées soient exploitées par des gens moins bien intentionnés.

Bref, dix ans à dire que c'est public, et hop, aujourd'hui c'est devenu top secret. Bien joué Google !!

Source

Ce matin, je cherchais un moyen simple de tester des webhooks en local sans passer par ce bon vieux Ngrok qui est devenu un peu relou avec ses limites en version gratuite. J'ai d'abord pensé à monter mon propre serveur VPN (coucou Tailscale), mais franchement flemme.

Et puis tout à fait par hasard (aaah les joies de la sérendipité) je suis tombé sur cet outil qui devrait vous plaire, surtout si vous développez des applis qui doivent recevoir des notifications HTTP (GitHub, Stripe, Slack...). Ben oui vous connaissez la galère... votre serveur de dev est sur "localhost", donc inaccessible depuis l'extérieur, du coup, impossible de recevoir ces fameux webhooks sans ouvrir votre routeur ou utiliser un tunnel.

C'est là qu'intervient Webhooks Proxy Tunnel !

Grâce à cet outil, au lieu de multiplier les intermédiaires, vous déployez votre propre tunnel... directement sur l'infrastructure de Cloudflare. Et le meilleur c'est que ça tourne généralement très bien sur leur offre gratuite (dans la limite des quotas Workers évidemment, donc attention si vous bourrinez comme un fifou).

L'outil utilise un Cloudflare Worker couplé à un Durable Object (une sorte de mini-serveur d'état). Le Worker reçoit alors les requêtes publiques sur une URL en HTTPS (genre "truc.workers.dev") et les transmet via une WebSocket à un petit client Node.js qui tourne sur votre machine. Et hop, le trafic arrive sur votre port local.

Perso, je trouve ça brillant car même si le trafic passe techniquement par Cloudflare (puisque c'est leur infra), vous gardez la main sur le code qui s'exécute et vous évitez d'envoyer vos données à un service tiers supplémentaire dont vous ignorez tout.

Pour l'installer, ne plus c'est hyper fastoche. Il vous faut juste un compte Cloudflare et Node.js. J'ai testé l'install en moins de 5 minutes, vous clonez le dépôt, vous installez les dépendances et vous lancez le déploiement (qui vous demandera de vous authentifier) :

git clone https://github.com/peter-leonov/webhooks-proxy-tunnel.git
cd webhooks-proxy-tunnel/worker
npm install
npm run deploy

Après les standards pour les APIs, après les standards pour le web, après les standards pour à peu près tout ce qui touche à l'informatique, voici... un standard pour les champignons !

Et non, je ne parle pas des champignons de Mario qui vous font grandir de partout (hi hi). Je parle de vrais champignons. Ceux qu'on cultive pour les manger. Bref, ceux qui représentent une industrie de 50 milliards de dollars qui gère encore ses données sur des feuilles Excel et des bouts de papier collés sur des bocaux.

Shiitake happens, comme on dit ^^.

Heureusement des champignonistes plus malin que les autres ont créé WOLS, pour WeMush Open Labeling Standard . L'idée c'est d'encoder toutes les infos de traçabilité de vos cultures fongiques directement dans un QR code. Origine du mycélium, substrat utilisé, dates d'inoculation, conditions de croissance... Hop, tout ça compressé dans un petit carré noir et blanc que vous pouvez scanner.

Le truc couvre 5 types de spécimens (de la culture mère jusqu'à la récolte), 4 stades de croissance, et propose 3 formats de QR différents selon vos besoins. Vous voulez juste un truc compact ? 500 octets. Vous voulez du JSON-LD pour faire le malin avec vos métadonnées ? 400 octets en mode embedded. Vous êtes parano et vous voulez chiffrer vos précieuses données de pleurotes ? AES-256-GCM, mon ami.

D'ailleurs, le projet est agnostique côté espèces : Que vous cultiviez du Lion's Mane (le champignon du hipster), du Shiitake (le classique), des pleurotes ou même du Reishi pour vos smoothies santé, le standard s'en fiche et encode tout pareil. De quoi faire pleurer de joie tous les myciculteurs de la planète. Ou les faire pleurote de joie, si vous préférez.

(Oui, je vous ai eu "champignoniste", c'est pas un vrai mot ^^)

Côté technique, c'est du sérieux malgré le sujet rigolo. Y'a des implémentations en JavaScript (@wemush/wols), en Python (wols), et même un conteneur Docker pour les feignasses qui veulent pas installer de dépendances. Le tout sous licence open source , donc vous pouvez forker ça et l'adapter à vos besoins sans vous prendre le cèpe. D'ailleurs si vous cherchez un nom pour votre propre projet open source , évitez les jeux de mots sur les champignons, c'est déjà pris.

Bref, si vous cultivez des champignons (légaux, hein les toxicos) et que vous en avez marre de noter vos infos sur des post-it qui finissent par moisir comme vos substrats ratés, ce standard pourrait bien être la truffe numérique que vous attendiez.