En juin 2026, Canal+ déploiera un nouveau moteur de recherche dans son application Canal+ (ex-myCANAL). Un modèle de langage OpenAI sera en charge de la recherche, ce qui devrait faciliter certaines requêtes et permettre de poser des questions en langage naturel.
Un projet open source publié sur GitHub début mars 2026 promet de retirer en un clic les mécanismes de refus intégrés aux grands modèles de langage. Baptisé Obliteratus, cet outil analyse la « géométrie du refus » dans les réseaux de neurones afin de neutraliser les garde-fous qui poussent une IA à répondre « je ne peux pas vous aider avec ça ».
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 ^^.
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 :
Connexionbrew install trufflehog
trufflehog git https://github.com/user/project --only-verified
Le flag --only-verified c'est le truc important, ça teste si les secrets trouvés sont encore ACTIFS. Parce que trouver une vieille clé révoquée, on s'en fiche. Attention, ça ne marche pas sur les repos privés sans token d'accès.
Y'a aussi Nosey Parker qui fait le même genre de boulot mais perso, je trouve TruffleHog plus complet pour les clés cloud, même si Nosey Parker est plus rapide pour les gros repos.
Après si vous bossez avec des clés Google spécifiquement, cherchez le pattern AIza dans votre code. Un simple grep suffit :
grep -r "AIza" . --include="*.js" --include="*.py" --include="*.env"
Scanner c'est bien, mais empêcher les secrets d'atterrir dans Git, c'est mieux. Et pour cela, rien de plus simple... Suffit d'installer un pre-commit hook.
git-secrets d'AWS fait exactement ça :
brew install git-secrets
cd mon-projet
git secrets --install
git secrets --register-aws
Du coup, chaque git commit vérifie automatiquement qu'il n'y a pas de clé AWS qui traîne. Vous pouvez ajouter vos propres patterns (genre AIza pour Google) :
git secrets --add 'AIza[0-9A-Za-z_-]{35}'
git secrets --add 'sk-proj-[0-9a-zA-Z]{48}'
Le deuxième pattern, c'est pour les clés OpenAI (format sk-proj-). D'ailleurs, stockez TOUT dans des fichiers .env et vérifiez que .env est dans votre .gitignore. Ça devrait être un réflexe ! Le piège classique c'est surtout le fichier .env.example qui contient en fait de vraies clés... c'est du vu et revu sur GitHub.
Pour aller plus loin, Vault de HashiCorp gère également vos secrets de manière centralisée avec du chiffrement, de la rotation automatique et des audit logs. C'est carrément le niveau supérieur notamment pour les équipes. C'est bien plus safe que le .env .
Notre dev mexicain a découvert sa facture APRÈS 48 heures. Deux jours, c'est une éternité alors voilà comment réagir en minutes, et pas en jours.
Sur Google Cloud, allez dans Billing > Budgets & Alerts. Créez un budget avec des seuils à 50%, 90% et 100% de votre budget mensuel. Activez les notifications par email ET par Pub/Sub pour déclencher une Cloud Function qui coupe automatiquement les clés si le seuil est dépassé.
Chez OpenAI, c'est dans Settings > Billing > Usage limits. Vous pouvez définir un hard cap mensuel. Au-delà... plus rien ne passe. Même chose à peu près pour Claude d'Anthropic aussi...
Et surtout, activez la rotation automatique de vos clés. Sur Google Cloud :
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 restrictions d'API c'est pas un luxe donc sur chaque clé, limitez les services autorisés (Gemini uniquement si c'est son usage), les IPs sources et le nombre de requêtes par minute. Sauf si vous aimez les surprises à 5 chiffres sur votre relevé bancaire, une clé sans restriction, c'est une carte bleue sans plafond.
Perso, je me suis mis des alertes sur tous mes comptes cloud, que ce soit AWS, GCP ou Azure. Genre, si ça dépasse 50 balles en une journée... hop, notification sur le téléphone. Finalement, c'est 5 minutes de config qui peuvent vous éviter des mois de galère.
Dans une étude publiée mi-février 2026, des chercheurs venus d'ETH Zurich, de MATS Research et d'Anthropic démontrent que les grands modèles de langage (LLM) sont capables de désanonymiser des comptes en ligne à grande échelle, avec une précision et une rapidité inédites.
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 !!
Le ministère américain de la Défense donne 72 heures à Anthropic pour lui accorder un accès sans restriction à son modèle d’intelligence artificielle Claude. En cas de refus, l’entreprise s’expose à de lourdes sanctions.
Dans un article de blog publié le 19 février 2026, les chercheurs en cybersécurité d'ESET mettent en lumière un nouveau malware baptisé PromptSpy. Point d'intérêt majeur ? La façon dont ce logiciel malveillant intègre l'IA dans son fonctionnement.
De l'effondrement (temporaire) de la bourse au rachat historique de Warner Bros par Netflix : 2025 a été une année chargée pour l'actualité tech. Numerama revient sur les 15 événements qui ont définitivement redéfini notre futur numérique.
Le ministère de la Défense américain a dévoilé le 8 décembre 2025 GenAI.mil, une nouvelle plateforme d’intelligence artificielle militaire fondée sur Gemini de Google. Elle doit doper la productivité des millions de salariés du Pentagone et préparer l’intégration de systèmes d’IA capables de gérer des données sensibles, voire classifiées.
Google a signalé la mise en place d'une nouvelle procédure de sécurité visant spécifiquement les risques liés à l'intégration imminente d'agents IA dans son navigateur Chrome. La solution à ces nouvelles menaces passera également par l'IA.
