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

On est vendredi, j'ai un mal de tête carabiné mais je me pose quand même devant l'ordi pour vous annoncer une bonne nouvelle ! Firefox 151 sur desktop vient enfin d'implémenter une fonctionnalité que Mozilla refusait catégoriquement de supporter depuis 6 ans : le support de l'API Web Serial.

Alors non, c'est pas un gros mot, hein, ça veut surtout dire qu'un site web ouvert avec Firefox peut maintenant lire et écrire directement sur du matériel que vous branchez en USB, genre un Arduino, un ESP32, une imprimante 3D, une clé crypto ou que sais-je encore, sans que vous ayez à installer le moindre logiciel ou pilote.

Le cas d'usage le plus parlant, c'est le flashage de microcontrôleurs. Avant, pour mettre un firmware sur un ESP32, il fallait installer esptool en Python, ou l'IDE Arduino, galérer avec les drivers série, choisir le bon port à la main. Maintenant des outils comme ESPHome ou Home Assistant font tout ça depuis un onglet, en quelques clics. Vous branchez la carte, le site demande l'autorisation d'accéder au port, et c'est réglé. Adafruit fait pareil pour installer CircuitPython sur ses cartes ESP32-S2.

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

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

82 314 dollars, c'est l'incroyable facture que s'est mangé un dev mexicain après 48 heures d'utilisation frauduleuse de sa clé API Gemini. Sa dépense habituelle était de 180 dollars par mois environ, j'imagine que ça lui a fait un peu mal aux fesses. Et c'est une bonne raison pour moi de vous inciter une nouvelle fois à bien sécuriser vos clés API !

Le gars bosse dans une petite startup et de ce que j'ai compris, quelqu'un a chopé ses credentials et s'est lâché sur Gemini 3 Pro pendant deux jours. La réponse de Google ? "Responsabilité partagée". En gros, eux sécurisent l'infra, et vous sécurisez vos clés. Si vous vous faites plumer, c'est votre problème !

Et c'est pas un cas isolé car les chercheurs de Truffle Security ont scanné le web et trouvé 2 863 clés Google API exposées en clair sur des sites publics. Toutes identifiables par le préfixe AIza.

Sauf que comme je vous l'expliquais dans un article précédent, ces clés, à la base, étaient conçues comme de simples identifiants de projet pour Maps et Firebase et la doc Google disait carrément qu'elles n'étaient pas secrètes ! Et quand l'API Gemini a été activée sur ces projets, hé bien ces clés sont devenues des clés d'authentification, sans que personne ne réalise ce changement de paradigme.

Mais bon, plutôt que de chialer comme des fragiles, voyons comment éviter de se retrouver dans cette situation ^^.

Scanner vos secrets existants

Avant tout, faut savoir si vous avez déjà des fuites. Deux outils open source font ça très bien.

TruffleHog scanne vos dépôts Git, vos fichiers, et même vos buckets S3 pour trouver des secrets qui traînent. L'install est simple :

brew install trufflehog
trufflehog git https://github.com/user/project --only-verified

grep -r "AIza" . --include="*.js" --include="*.py" --include="*.env"

brew install git-secrets
cd mon-projet
git secrets --install
git secrets --register-aws

git secrets --add 'AIza[0-9A-Za-z_-]{35}'
git secrets --add 'sk-proj-[0-9a-zA-Z]{48}'

gcloud services api-keys list
gcloud services api-keys create --display-name="gemini-prod-$(date +%Y%m)"
gcloud services api-keys delete ANCIENNE_CLE_ID

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

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

Si vous n’utilisez pas encore n8n pour automatiser vos tâches, c’est le moment de vous y mettre parce que c’est open source et c’est la meilleure alternative que vous pourrez trouver à Zapier et ce genre de services payants.

La boîte a levé 180 millions de dollars récemment avec une valorisation à 2,5 milliards, et contrairement à Zapier qui facture à la tâche (et ça devient vite très cher), n8n facture à l’exécution ! Mais bien sûr, si vous aimez mettre les mains dans le cambouis c’est totalement gratuit !

Si vous connaissez pas encore n8n, c’est vraiment le genre d’outil qui peut vous changer la vie car ça vous permet de connecter vos apps entre elles avec une interface visuelle (genre des blocs qu’on relie), et vous pouvez automatiser à peu près n’importe quoi : synchroniser des données entre outils, envoyer des notifications, créer des pipelines de traitement… Et comme c’est open source et que vous pouvez l’héberger sur votre propre serveur, ce qui règle tous les problèmes de confidentialité des données.

Après, j’avoue que créer des workflows from scratch, c’est parfois un peu relou. Heureusement, y’a ce super dépôt GitHub qui contient plus de 4 300 workflows prêts à l’emploi que vous allez pouvoir utiliser pour vous !

La collection est organisée en 15 catégories : Marketing, Sales, DevOps, et tout ce que vous voulez ! Y’a même un système de recherche full-text qui répond en moins de 100ms, des filtres par niveau de complexité (Low, Medium, High), par type de trigger, par service… Bref, vous trouverez ce que vous cherchez en quelques secondes.

Pour l’utiliser, vous avez plusieurs options. Soit vous passez par l’interface web hébergée sur GitHub Pages, soit vous installez ça en local avec Python :

git clone https://github.com/Zie619/n8n-workflows.git
cd n8n-workflows
pip install -r requirements.txt
python run.py

docker run -p 8000:8000 zie619/n8n-workflows:latest

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

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

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

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

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

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

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

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

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

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

Source

Vous avez un site WordPress et vous voulez ajouter de l’IA dedans ?

Alors pour faire ça, vous installez un super plugin qui utilise ChatGPT. Parfait ! Sauf que 2 mois après, vous découvrez l’existence d’un nouvelle version de Claude qui est bien meilleure. Ou Gemini sort une fonctionnalité que vous voulez absolument..

Mais bon, votre plugin est marié avec OpenAI, et impossible de divorcer. Du coup, vous êtes coincé. Bienvenue dans le grand bordel de l’IA, où chaque outil parle sa propre langue et refuse de discuter avec les autres.

Heureusement, WordPress vient de sortir un truc qui pourrait bien changer tout ça. En gros, ils ont créé trois outils qui fonctionnent ensemble pour transformer WordPress en “traducteur universel” pour les IA. Ça s’appelle l’Abilities API, le PHP AI Client SDK, et le support du MCP (Model Context Protocol).

D’après l’annonce officielle sur Make WordPress , l’idée c’est donc de créer un registre central où toutes les capacités de WordPress sont décrites de manière lisible par les machines. Jonathan Bossenger explique que l’Abilities API ne se limite pas à découvrir les capacités du site, mais gère aussi les permissions et l’exécution de manière sécurisée. Votre site peut dire à une IA “Voilà ce que je sais faire, voilà ce que tu peux toucher, et voilà comment tu exécutes ça”.

// N'importe quel plugin peut enregistrer ses capacités avec le hook `init`.
wp_register_ability( 'my-seo-plugin/analyze-content-seo', [
 'label' => __( 'Analyser le SEO du contenu', 'my-seo-plugin' ),
 'description' => __( 'Analyse le contenu de l\'article pour améliorer le SEO.', 'my-seo-plugin' ),
 'thinking_message' => __( 'Analyse de votre contenu en cours !', 'my-seo-plugin' ),
 'success_message' => __( 'Contenu analysé avec succès.', 'my-seo-plugin' ),
 'execute_callback' => [ 'MySEOPlugin', 'analyze_content' ],
 'input_schema' => [
 'type' => 'object',
 'properties' => [
 'post_id' => [
 'type' => 'integer',
 'description' => __( 'L\'identifiant de l\'article.', 'my-seo-plugin' ),
 'required' => true
 ],
 ],
 'additional_properties' => false,
 ],
 'output_schema' => [
 'type' => 'number',
 'description' => __( 'Le score du contenu en pourcentage.', 'my-seo-plugin' ),
 'required' => true,
 ],
 'permission_callback' => 'edit_posts',
] );

Ce qui est super relou avec les IA qu’on peut utiliser en local, genre avec Ollama, c’est que si on lui demande des infos un peu trop récente, ça nous sort des vieux chiffres de 2023 avec la confiance d’un vendeur de voitures d’occasion. Bon bah ça, c’est fini puisqu’ Ollama vient de sortir une API de recherche web qui permet enfin à vos modèles locaux d’accéder à des infos fraîches dispo sur le net.

Woohoo \o/ !

Baptisée Ollama Web Search, cette API REST permet donc à vos modèles de faire des recherches sur le web en temps réel comme ça plus besoin de se contenter des données d’entraînement figées dans le temps. Selon la doc officielle , l’API fournit “les dernières informations du web pour réduire les hallucinations et améliorer la précision”. En gros, votre IA locale devient aussi à jour que ChatGPT, mais sans envoyer vos données perso à OpenAI.

Les modèles compatibles avec cette nouvelle fonctionnalité incluent qwen3, LLama, gpt-oss (la version open source d’OpenAI), deepseek-v3.1, et plein d’autres. Et d’après les premiers tests de la communauté , qwen3 et gpt-oss sont même plutôt doués pour exploiter cette fonctionnalité. Le modèle comprend qu’il lui manque une info, fait sa recherche, analyse les résultats et nous sort une réponse documentée !

C’est trop incrrrr ! Vous allez pouvoir booster vos scripts / bots / outils d’IA locale pour qu’ils puissent surveiller des choses dispo en ligne, les comparer, générer des résumés à partir de sites web, fact checker ou compléter des infos…etc.

Mais alors comment s’en servir ? Bon, on est vendredi soir et j’ai la flemme de tourner un tuto vidéo, donc même si je risque de détailler tout ça bientôt à mes Patreons d’amour , voici quand même quelques explications.

D’abord, il faut créer une clé API Ollama . La doc explique que vous avez un essai gratuit généreux pour commencer, mais s’il vous en faut plus, il faudra prendre un petit abonnement Ollama Cloud …

Une fois votre clé en poche, exportez-la dans votre environnement comme ceci :

export OLLAMA_API_KEY="votre_clé_ici"

Le plus simple ensuite pour tester, c’est avec curl :

curl https://ollama.com/api/web_search \ --header "Authorization: Bearer $OLLAMA_API_KEY" \ -d '{ "query": "dernières vulnérabilités CVE janvier 2025" }'

Mais bon, soyons honnêtes, on va plutôt utiliser Python car c’est quand même plus cool ;-) . Voici donc un exemple de script basique qui compare une réponse avec et sans recherche web :

import ollama
from ollama import chat, web_search, web_fetch

model = "qwen3:4b"

# 1. Sans recherche web
response_classic = chat( # pas ollama.chat
 model=model,
 messages=[{
 "role": "user",
 "content": "Quelles sont les features de React 19?"
 }]
)
print("Sans recherche web:", response_classic.message.content[:500]) # .message.content

# 2. Avec recherche web
search_results = web_search("React 19 features dernières nouveautés")
print("Résultats:", search_results)

# 3. Avec outils
available_tools = {'web_search': web_search, 'web_fetch': web_fetch}
messages = [{
 "role": "user",
 "content": "Utilise la recherche web pour me dire les dernières features de React 19"
}]

response_with_tools = chat(
 model=model,
 messages=messages,
 tools=[web_search, web_fetch],
 think=True
)

# Accès aux tool_calls
if response_with_tools.message.tool_calls:
 for tool_call in response_with_tools.message.tool_calls:
 function_to_call = available_tools.get(tool_call.function.name)
 if function_to_call:
 args = tool_call.function.arguments
 result = function_to_call(**args)
 print(f"Outil utilisé: {tool_call.function.name}")
 print(f"Résultat: {str(result)[:500]}...")

print("Réponse finale:", response_with_tools.message.content)

import ollama
from ollama import chat, web_search

class SecurityAgent:
 def __init__(self):
 self.model = "qwen3:4b"

 def check_vulnerabilities(self, technologies):
 rapport = "🛡️ RAPPORT SÉCURITÉ\n\n"

 for tech in technologies:
 # Recherche directe des CVE récentes
 results = web_search(f"{tech} CVE vulnerabilities 2025 critical")

 # Demande au modèle d'analyser
 response = chat(
 model=self.model,
 messages=[{
 "role": "user",
 "content": f"Résume les vulnérabilités critiques de {tech}: {results}"
 }]
 )

 rapport += f"### {tech}\n{response.message.content}\n\n"

 return rapport

# Utilisation
agent = SecurityAgent()
rapport = agent.check_vulnerabilities(["Node.js", "PostgreSQL", "Docker"])
print(rapport)

from ollama import web_search, web_fetch, chat

# 1. Recherche d'articles pertinents
search_results = web_search("React 19 vs Vue 3 comparison 2025")
top_url = search_results.results[0]['url'] # ou .url selon le type
print(f"📰 Article trouvé: {search_results.results[0]['title']}")

# 2. Récupération du contenu complet de la page
page_content = web_fetch(top_url)
print(f"📄 {len(page_content.content)} caractères récupérés")

# 3. Analyse approfondie du contenu
response = chat(
 model="qwen3:4b", # ou "gpt-oss" si disponible
 messages=[{
 "role": "user",
 "content": f"""
 Analyse cette comparaison technique:
 {page_content.content[:4000]}

 Donne-moi:
 1. Les points clés de chaque framework
 2. Le gagnant selon l'article
 3. Les cas d'usage recommandés
 """
 }]
)

print(f"\n🔍 Analyse:\n{response.message.content}")

Vous êtes en train de lire tranquillement un long tuto, et voilà que votre écran s’éteint.

Relou, non ?

Alors si vous en avez marre de devoir toucher votre souris toutes les 30 secondes pour garder votre écran allumé, j’ai déniché un petit outil sympa qui va vous changer la vie : LumoSprite.

Le truc génial avec LumoSprite, c’est que c’est une application web toute simple qui empêche votre écran de s’endormir. Pas besoin d’installer quoi que ce soit, pas de logiciel lourd qui tourne en arrière-plan, juste une page web à garder ouverte.

C’est totalement gratuit et ça utilise la fameuse Wake Lock API pour faire sa magie. Pour ceux qui se demandent comment ça marche techniquement, la Screen Wake Lock API c’est une technologie web qui permet aux sites de demander au système de ne pas éteindre l’écran. Cette API est maintenant supportée par tous les navigateurs majeurs (Chrome, Safari, Firefox), ce qui rend l’outil super compatible.

Il suffit donc que votre navigateur supporte JavaScript et la Wake Lock API, et c’est parti. Vous arrivez sur le site, vous activez la fonction, et voilà, votre écran restera allumé tant que l’onglet est ouvert et au premier plan. L’outil propose même plusieurs langues (anglais, chinois, japonais, coréen… Pas de français encore) et différents thèmes pour personnaliser l’expérience.

C’est vraiment pensé pour être accessible à tous et les cas d’usage sont nombreux. Par exemple, vous lisez un livre numérique ou vous suivez une recette de cuisine sans avoir à toucher votre écran avec vos mains pleines de beurre ? Vous présentez quelque chose à distance ? Ou vous surveillez simplement un process au boulot ? Ça répond à tous ces besoins.

Des alternatives comme nosleep.page ou Keep Screen On proposent des fonctionnalités similaires mais LumoSprite se démarque par sa simplicité et son look sympa. Pas de fioritures inutiles non plus et niveau vie privée, c’est nickel puisque tout fonctionne localement dans votre navigateur, et qu’aucune donnée n’est collectée ou envoyée quelque part.

L’outil consomme d’ailleurs moins de 1% des ressources de votre machine, donc pas de souci pour la batterie ou les performances car c’est du JavaScript léger, qui fait juste ce qu’il faut. Après si vous cherchez une solution plus permanente, il existe aussi des extensions navigateur comme Keep Awake pour Chrome ou des solutions système comme PowerToys Awake pour Windows.

Mais franchement, pour un usage ponctuel, LumoSprite fait largement le job sans encombrer votre navigateur d’extensions supplémentaires.

Le succès de ce type d’outils montre bien qu’il y avait un vrai besoin. D’ailleurs, Betty Crocker (le site de cuisine américain) a vu une augmentation de 300% de l’intention d’achat après avoir implémenté la Wake Lock API sur leur site directement. Comme ça, les gens peuvent enfin suivre leurs recettes sans que l’écran s’éteigne toutes les deux minutes ! Pour un site de tuto, c’est peut-être un move pertinent.

Bref, si vous cherchez un moyen simple et efficace de garder votre écran allumé, foncez tester LumoSprite.

Vous en avez marre de réécouter 50 fois la même vidéo YouTube pour prendre des notes, en ratant systématiquement les passages importants ? Alors vous n’êtes manifestement pas au courant qu’il existe un petit outil Python qui extrait automatiquement tous les sous-titres d’une vidéo en 3 lignes de code.

Spoiler : ça marche même avec les sous-titres auto-générés par YouTube (et c’est souvent plus précis que vos grosses oreilles fatiguées).

Vous êtes un irréductible de Windows 7, mais vous lorgniez avec envie sur certaines applications récentes uniquement disponibles pour Windows 8, 8.1 ou 10 ? Pas de stress, avec VxKex, vous allez pouvoir les faire tourner sur votre Seven adoré !

Mais qu’est-ce que c’est que ce truc au nom imprononçable ? Eh bien, pour faire simple, c’est est un ensemble d’extensions d’API qui vont permettre à votre Windows 7 de comprendre et d’exécuter des programmes normalement réservés aux versions plus récentes de l’OS de Microsoft. Bref, c’est un peu comme si on greffait des bouts de Windows 8 et 10 dans votre Seven. Génial, non ?

Pour en profiter, rien de plus simple. Rendez-vous sur la page des releases sur GitHub et téléchargez la dernière version. Installez la, et vous voilà prêt à dompter ces applis récalcitrantes !

L’utilisation est un jeu d’enfant. Faites un clic droit sur le programme que vous voulez lancer (fichier .exe ou .msi), ouvrez les propriétés, puis sélectionnez l’onglet « VxKex ». Là, cochez la case « Enable VxKex for this program » (« Activer VxKex pour ce programme ») et lancez l’application. Tadaaa !

Bon, pour certains programmes un peu complexes, il faudra peut-être bidouiller quelques réglages supplémentaires, mais rien d’insurmontable. Vous trouverez toutes les infos nécessaires dans le fichier « Application Compatibility List.docx » inclus dans le dossier d’installation de l’outil (par défaut dans « C:\Program Files\VxKex »). Et la liste des applications compatibles est longue comme le bras ! Ça va de Blender à Spotify en passant par Chromium, Discord, Python, Qt Creator et même des émulateurs comme Citra et Yuzu. Bref, y’a de quoi s’amuser.

Mais attention, ce truc ne fait pas de miracles non plus. N’espérez pas faire tourner les derniers jeux AAA dessus, il est plutôt orienté applications. Ceci dit, les développeurs planchent déjà sur le support des jeux, alors gardez l’œil ouvert ! Autre question que vous vous posez sûrement : est-ce que ça va bousiller mon Windows 7 chéri ?

Eh bien non, pas du tout ! VxKex n’altère aucun fichier système, il se contente de charger des DLLs lorsque vous lancez une application compatible. Donc pas de panique, votre Seven restera aussi stable qu’un roc.

Côté configuration requise, c’est très léger. Il vous faut juste le Service Pack 1 et idéalement les mises à jour KB2533623 et KB2670838 d’installés sur votre Windows 7. Et si vous avez les derniers correctifs de sécurité (les fameux ESU), pas de problème non plus, il est compatible.

Même les applications en ligne de commande sont de la partie ! Une fois que c’est activé pour votre programme, vous pouvez l’utiliser dans l’invite de commandes comme si de rien n’était.

Bref, de quoi redonnez un coup de jeune à votre Windows 7 et profitez enfin de toutes ces applications qui vous faisaient de l’œil sur Windows 8 et 10 ! Mais bon, n’oubliez pas que Windows Seven est quand même un vieux machin et que niveau sécurité, c’est pas top… Donc pensez à mettre à jour vers Windows 11 (ou 10 si vous avez un PC pourri).

Vous débarquez dans votre laverie automatique préférée, les bras chargés de linge sale, et là, magie magie, grâce à une petite bidouille bien sentie, vous pouvez lancer une lessive gratuite, sans débourser un centime. C’est le rêve, non ? Eh bien, figurez-vous que c’est exactement ce qu’ont réussi à faire des étudiants un peu hackers sur les bords.

Alexander Sherbrooke et Iakov Taranenko, 2 petits génies de l’université de Santa Cruz, ont découvert une faille de sécurité dans le système des laveries connectées de CSC ServiceWorks. Je vous parle quand même d’un réseau de plus d’un million de machines à laver installées un peu partout dans le monde, des campus universitaires aux hôtels en passant par les résidences. Bref, un sacré parc de machines qui tournent à plein régime.

Pour y arriver, ils ont bidouillél’API utilisée par l’appli mobile CSC Go. Pour ceux qui ne sont pas familiers avec le jargon technique, une API c’est un truc qui permet à des applis et des appareils de communiquer entre eux au travers du réseau. Dans le cas présent, l’appli CSC Go permet aux utilisateurs de recharger leur compte, de payer et de lancer un cycle de lavage sur une machine proche. Cependant, les serveurs de CSC ne vérifiaient pas correctement qui avait le droit de faire quoi. N’importe qui peut entrer et faire ce qu’il veut. Et c’est exactement ce qu’ont fait nos deux compères.

En analysant le trafic réseau pendant qu’ils utilisaient l’appli CSC Go, Alexander et Iakov ont réussi à court-circuiter les contrôles de sécurité pour envoyer des commandes directement aux serveurs de CSC. Résultat des courses : ils ont pu modifier leur solde, ajouter des millions de dollars virtuels pour le budget lessive, et même localiser et interagir avec toutes les machines du réseau CSC ServiceWorks.

Bien sûr, avoir la lessive gratuite, c’est cool. Mais Alexander et Iakov ont surtout voulu montrer les dangers d’avoir des appareils connectés à Internet sans une sécurité au top. Le pire dans l’histoire, c’est qu’ils ont prévenu CSC ServiceWorks de la faille à plusieurs reprises depuis janvier, mais la société n’a jamais répondu. Pourtant, un simple petit formulaire de contact pour signaler les problèmes de sécurité, ça ne coûte pas bien cher et ça peut éviter de gros dégâts… J’espère juste que ces derniers ne préparent pas une action en justice…

Évidemment, bidouiller des machines à laver pour avoir des lessives gratuites, ce n’est pas l’attaque du siècle mais cela montre qu’il y a encore du boulot côté sécurité pour tous ces objets connectés. Alors pour se protéger de telles vulnérabilités, il est crucial de sécuriser les API en effectuant la vérification des commandes côté serveur plutôt que côté client et en utilisant des tokens d’authentification sécurisés.

En attendant, si vous croisez Alexander et Iakov sur leur campus, vous pouvez leur donner vos slips sales, ils savent y faire pour vous les rendre plus blanc que blanc. ^^

Source

Si vous êtes développeur, vous connaissez sûrement les galères quand on doit débugger des applis web ou mobiles à savoir intercepter les requêtes HTTP pour voir ce qui s’y passe, simuler des API… etc.

Et bien bonne nouvelle, puisqu’il y a un outil parfait pour ça : HTTP Toolkit ! C’est un soft open source développé par un certain Tim Perry, qui fonctionne sous Windows, Linux, macOS et qui permet :

• D’intercepter en temps réel le trafic HTTP/HTTPS de n’importe quel client (browser, mobile, scripts, containers Docker…)
• D’explorer, filtrer et inspecter en détail les requêtes et réponses (URL, statut, headers, body…)
• De faire des breakpoints et éditer le trafic à la volée (modifier requête, simuler réponse, injecter erreurs…)
• Mais également de prototyper entièrement des API, créer des règles pour router les requêtes sur vos endpoints

Et encore, je vous la fais courte mais y a 1000 autres features et c’est super simple à prendre en main grâce à une interface plutôt soignée avec plein de petites explications. De plus, ça s’intègre avec l’éditeur Monaco de VS Code, les DevTools, le protocole adb, les spéc Open API… Et surtout, y’a une grosse communauté de fans qui soutiennent le projet.

Avec cet outil vous pourrez par exemple intercepter en 1 clic ce qui se passe dans une fenêtre Chrome ou une application mobile spécifique sans avoir à configurer un proxy, récupérer des certificats SSL et autres joyeusetés.

Je vous invite à le tester, vous m’en direz des nouvelles. Ça se passe par ici.

Merci à Lorenper pour le soft !