On entend beaucoup parler de l'IA générative ces derniers temps. Et dans les médias classiques, c'est souvent pour s'en inquiéter (pas ici, vous savez que j'essaye de rester positif). Il faut quand même reconnaitre que : phishing plus convaincant, deepfakes, malware qui s'adapte tout seul... la liste des risques est longue et légitime.
Mais il y a un angle qu'on oublie parfois : cette même technologie peut aussi renforcer sérieusement nos défenses. C'est exactement la position que défend Surfshark depuis quelques mois. Pas en mode "l'IA va tout résoudre", mais avec une approche pragmatique. À savoir comment utiliser ces outils pour anticiper, tester et contrer les menaces avant qu'elles n'arrivent jusqu'à vous. Je vous explique comment ça fonctionne, ce que ça change concrètement, et pourquoi c'est une bonne nouvelle pour votre sécurité au quotidien.
Quand on parle de cybersécurité et d'IA, le premier réflexe est de penser aux cybercriminels. C'est vrai, ils l'utilisent. Pour écrire du code malveillant plus vite, personnaliser des campagnes de phishing, ou générer des variantes de malware qui contournent les signatures classiques. Mais les équipes de défense ont accès aux mêmes capacités. La différence ? L'intention et le cadre d'utilisation.
La "generative AI", dans ce contexte, c'est la capacité à produire du contenu nouveau à partir de modèles entraînés. Cela peut être du texte, du code ou encore des scénarios d'attaque simulés. Ce n'est pas de la magie. C'est de l'ingénierie appliquée à la sécurité. Concrètement, ça permet trois choses essentielles :
D'abord, la détection proactive. Au lieu d'attendre qu'une menace soit identifiée pour la bloquer, les modèles peuvent simuler des milliers de variantes d'attaques plausibles, puis entraîner les systèmes de détection à les reconnaître. C'est comme faire des exercices d'incendie avant que le feu ne se déclare.
Ensuite, l'analyse comportementale. L'IA peut modéliser ce à quoi un trafic réseau "normal" ressemble pour votre infrastructure, puis signaler les écarts subtils qui échapperaient à des règles statiques. Pas besoin que l'attaque corresponde à une signature connue, si le comportement est suspect, le système alerte.
Enfin, l'automatisation des réponses. Quand un incident est détecté, chaque minute compte. L'IA peut résumer les alertes, suggérer des actions de confinement, isoler un compte compromis, générer un rapport pour l'équipe, etc. Les analystes gardent la main sur les décisions stratégiques, mais ne perdent plus de temps sur des tâches répétitives.
Surfshark n'utilise pas l'IA générative pour faire du marketing ou ajouter des fonctionnalités gadget. L'approche est plus terre-à-terre.
Leur équipe sécurité s'appuie sur ces modèles pour tester en continu leurs propres défenses. Ils génèrent des scénarios d'attaque réalistes, adaptés à leur infrastructure, puis vérifient que leurs systèmes réagissent comme prévu. C'est une forme de "pen-testing" augmenté, plus rapide et plus exhaustif que les méthodes manuelles.
Un autre usage concret c'est l'entraînement des équipes. Plutôt que de se baser uniquement sur des incidents passés, ils peuvent créer des simulations dynamiques, avec des variantes imprévisibles. Ça permet de préparer les analystes à des situations qu'ils n'ont jamais rencontrées, sans attendre qu'elles arrivent pour de vrai.
Côté produit, certaines fonctionnalités bénéficient indirectement de ces avancées. CleanWeb , par exemple, qui bloque pubs et trackers, s'appuie sur des modèles capables d'identifier des schémas de collecte de données de plus en plus sophistiqués. L'IA ne remplace pas les listes de blocage, mais elle aide à les mettre à jour plus vite, face à des acteurs qui adaptent leurs techniques en permanence.
Et pour ceux qui s'inquiètent de la confidentialité, Surfshark précise que les données utilisées pour entraîner ces modèles sont soit synthétiques, soit anonymisées. Rien de ce que vous faites via leur VPN ne sert à nourrir des modèles externes. La politique no-logs, auditée par Deloitte ou très récemment SecuRing (audit en janvier 2026), reste la règle.
Si vous êtes tenté d'expérimenter avec des outils d'IA générative dans votre propre environnement, quelques précautions s'imposent. Déjà, ne partagez jamais d'informations sensibles avec des plateformes publiques comme ChatGPT, Claude, etc. Même si l'outil semble inoffensif, vos requêtes peuvent être conservées, analysées, ou fuiter en cas de brèche. Pour du travail sur des configurations, des logs ou des politiques de sécurité, privilégiez des environnements contrôlés, en local ou avec des fournisseurs qui garantissent la confidentialité des données.
Formez vos équipes. L'IA peut générer du code, du texte, des scénarios très convaincants ... mais elle peut aussi se tromper, introduire des biais, ou proposer des solutions qui semblent logiques alors qu'elles créent des failles. Un œil humain reste indispensable pour valider, contextualiser et décider.
Enfin, gardez une approche critique. L'IA n'est pas une solution miracle. Elle amplifie les capacités humaines, mais ne les remplace pas encore. Une bonne hygiène de sécurité (mises à jour, authentification forte, segmentation réseau) reste la base. L'IA vient en couche supplémentaire, pas en fondation.
Vous le savez maintenant, je ne suis pas de ceux qui voient l'IA comme une menace absolue, ni comme une panacée. C'est juste un outil. Comme un marteau : ça dépend de la main qui le tient.
Ce qui me convainc dans l'approche de Surfshark depuis plusieurs années, c'est le pragmatisme. Pas de promesses grandioses, pas de discours "disruptif". Juste une volonté d'utiliser ce qui fonctionne pour améliorer la protection, tout en restant transparent sur les limites et les risques. Si vous cherchez un VPN qui intègre une réflexion sérieuse sur l'avenir de la cybersécurité, sans sacrifier la simplicité ni la confidentialité, Surfshark coche les cases. L'IA générative n'est pas l'argument principal de leur offre, cela dit c'est un atout discret qui renforce la crédibilité technique de l'ensemble.
Surfshark propose toujours son offre à 87% de réduction plus trois mois offerts sur l'engagement 24 mois. Cela revient à 1,99 euro HT par mois (2.39€/mois TTC), avec une garantie satisfait ou remboursé de trente jours. Vous pouvez tester le service, vérifier par vous-même les performances, la facilité d'usage, la réactivité du support et vous avez en plus l' Alternative ID inclus. Si ça ne correspond pas à vos attentes, vous êtes remboursé, sans justification. C'est le prix d'un sandwich triangle par mois pour protéger un nombre illimité d'appareils !
En plus, du 25 février au 23 mars (et dans la limite du stock disponible), Surfshark frappe fort encore plus fort avec une offre exclusive en partenariat avec CALM, l’application de méditation et de sommeil la plus téléchargée au monde. En choisissant un abonnement Surfshark de 1 ou 2 ans, vous obtenez automatiquement 12 mois de CALM Premium offerts, quelle que soit la formule choisie. Elle est pas belle la vie ?
Note : il s'agit d'un lien affilié. Cela ne change rien pour vous, mais cela me permet de continuer à produire ce type de contenu indépendant, sans recourir à la publicité intrusive.
J'avoue que faire tourner un agent IA en mode YOLO sur votre machine, y'a de quoi flipper un peu. Un mauvais prompt et hop, votre répertoire home part en fumée.
Mais heureusement, pour ça y'a Yolobox , un outil en Go qui fait tourner vos agents IA dans un conteneur Docker isolé. En gros, l'agent a les pleins pouvoirs dans son bac à sable par défaut comme ça, votre répertoire home reste intouchable. Claude Code, Codex, Gemini CLI, GitHub Copilot, tout est compatible, préconfiguré et prêt à l'emploi.
En fait avec Yolobox, seul votre dossier projet est monté en lecture-écriture avec le même chemin que sur votre machine et comme ça, l'agent bosse comme si de rien n'était. Sauf que tout le reste (vos clés SSH, vos credentials, vos photos de vacances à la plage naturiste et j'en passe...) est inaccessible depuis le conteneur. L'agent peut faire sudo, installer ce qu'il veut, déglinguer sa config... en fait RIEN ne s'échappe.
L'installation tient en une ligne :
brew install finbarr/tap/yolobox
Par contre, faut Docker Desktop qui tourne derrière, car sans ça, rien ne démarre. Ensuite c'est yolobox claude pour lancer Claude Code, yolobox codex pour Codex, yolobox gemini pour le CLI Google. Ou yolobox run suivi de n'importe quelle commande si vous avez un agent custom...
Côté sécu, y'a 4 niveaux qui vont du basique au parano. Le mode par défaut avec isolation conteneur standard. Un cran au-dessus avec --no-network et --readonly-project pour couper le réseau et passer le projet en lecture seule. Ensuite du Podman rootless. Et le niveau max avec isolation VM complète, parce que des fois faut pas déconner. Ça supporte aussi le runtime Apple Container pour ceux qui veulent rester full macOS.
Et les outils de dev sont déjà embarqués dans l'image : Node.js 22, Python 3, Go, Bun, ripgrep, fzf, jq... Les volumes persistants gardent également vos installations entre les sessions, donc pas besoin de tout réinstaller à chaque lancement.
Attention quand même, ça ne marche pas contre un escape de conteneur délibéré car hé, Docker reste Docker. Mais si vous utilisez Claude Code en mode autonome et que vous faites du vibe coding, c'est le minimum vital pour éviter qu'un agent aille fouiller là où il faut pas .
Bref, allez voir ça et merci à Lorenper pour le partage !
BYOD, IA, réseaux sociaux professionnels, logiciels à usage industriel… Les derniers « flashs ingérence » de la DGSI ont souvent fait la part belle au numérique.
Le service de renseignement avait institué ce format en 2012. Il y présente brièvement des cas réels d’ingérence économique et y associe des préconisations. Le dernier en date (février 2026) évoque les risques de captation d’informations lors de déplacements à l’étranger.
Le « flash ingérence » précédent (décembre 2025) est consacré à l’usage de l’IA dans le monde professionnel.
L’un des cas présentés est une tentative d’escroquerie par deepfake. Elle a visé le responsable d’un site industriel d’un groupe français. L’intéressé a reçu un appel visio. Son interlocuteur avait l’apparence physique et la voix du dirigeant du groupe. Il n’a cependant pas accédé à la demande qui lui a été faite de transférer des fonds dans le cadre d’un prétendu projet d’acquisition.
Les deux autres cas présentés touchent respectivement à l’usage d’IA sans autorisation et sans vérification. Le premier implique la traduction régulière de documents confidentiels à l’aide d’un outil « grand public » développé par une société étrangère, sans aval de la hiérarchie. Le second concerne le recours à un autre outil d’origine étrangère, pour de la due diligence. La société utilisatrice a systématiquement orienté ses décisions en fonction du retour fait par l’outil, sans contrôle complémentaire.
Le « flash ingérence » précédent (novembre 2025) est dédié aux approches malveillantes sur les réseaux sociaux professionnels.
La DGSI y expose le cas d’une start-up en difficulté financière évoluant dans un secteur sensible. Son dirigeant est approché par un prétendu cabinet de conseil étranger qui déclare opérer en qualité d’intermédiaire pour un fonds d’investissement. Convaincu, il lui dévoile des informations, dont un projet de conception d’un nouveau produit. Le service juridique de la start-up finit toutefois par détecter la supercherie. Ni le cabinet ni le fonds n’avait d’existence légale. Et on n’en trouvait trace dans aucune base de données de leurs pays d’origine déclarés.
Autre fausse promesse de financement : celle qui a ciblé le responsable d’un centre de recherche. Elle provenait du soi-disant chargé de com d’une célébrité internationale. Elle était d’autant plus crédible que cette célébrité avait récemment effectué des actions de soutien dans le domaine d’activité du centre – actions largement relayées sur les réseaux sociaux. La discussion n’est pas allée plus loin lorsque l’individu a demandé le règlement préalable d’une taxe locale de plusieurs milliers d’euros.
Le troisième cas exposé est celui de salariés piégés par un faux profil. L’escroc s’est d’abord fait passer pour un comptable interne, sans succès (le dirigeant avait repéré la supercherie). Il a eu plus de réussite quelques mois plus tard. Avec un autre faux profil, il est parvenu à engager des discussions avec des salariés. Dont un qui lui a révélé des infos stratégiques relatives au calendrier de développement de certaines activités de l’entreprise et à l’état de ses progrès technologiques.
En octobre, il y avait eu un « flash ingérence » concernant les risques associés à l’absence de protection des logiciels à usage industriel.
La DGSI y présente le cas d’une entreprise française développant des systèmes industriels. Un de ses clients avait, avec l’aide d’une entreprise concurrente étrangère, détourné le programme embarqué et l’avait installé sur une machine tierce. Or, ni le programme ni la machine ne bénéficiaient d’une protection par brevet. L’entreprise française avait considéré qu’en déposer un aurait publiquement exposé ses inventions. Le client a justifié la démarche par des temps de livraison jugés trop longs.
Deuxième cas : celui d’une entreprise française commercialisant un logiciel à intégrer dans des machines-outils. Un client étranger, prétextant un défaut de mise à jour, a fait une sauvegarde totale des données et du programme. Ce sans respecter les procédures de l’entreprise française, qui, habituellement, se déplace pour faire elle-même la mise à jour.
En l’absence de possibilité de protection par brevet des logiciels en tant que tels, l’entreprise craint notamment une revente à un concurrent.
La DGSI mentionne aussi un cas d’exfiltration de code source non protégé, survenu dans une entreprise ayant développé un logiciel applicatif pour un secteur industriel de pointe. Deux anciens salariés, qui avaient eu accès à ce code source développé dans le cadre de leurs fonctions, avaient créé une société concurrente pour l’exploiter. Ce quand bien même leurs contrats de travail comprenaient des clauses de confidentialité et de non-concurrence.
Un peu plus tôt dans l’année était paru un « flash ingérence » intitulé « Le facteur humain, principal vecteur de compromission des systèmes d’information ».
Le premier cas présenté est celui d’un salarié d’une société hébergeant des données sensibles. L’intéressé a accédé à sa messagerie professionnelle à partir d’outils personnels, alors même que la charte informatique de son employeur l’interdisait. Cela a permis à des attaquants de pénétrer le SI puis d’exploiter une faille 0-day.
Autre entreprise, autre salarié, quant à lui approché sur un réseau social professionnel par un soi-disant chargé de recrutement dans un grand groupe étranger. Invité à ouvrir une pièce jointe dans un de ses e-mails, il a ouvert la porte à un virus qui a permis d’extraire des centaines de fichiers sensibles. Ainsi que des fichiers appartenant à son ancien employeur.
La DGSI y ajoute une action malveillante d’un salarié travaillant chez un prestataire d’un grand groupe industriel. Il a installé un keylogger sur une clé USB personnelle. Puis l’a mise à disposition de ses collègues en tant que support de stockage professionnel. Cela lui a permis de récupérer les identifiants des personnes qui l’avaient connectée à leur ordinateur.
En mars 2025, la DGSI avait publié un « flash ingérence » sur les risques associés à l’utilisation d’outils numériques personnels à des fins professionnelles.
Premier cas évoqué : un salarié ayant utilisé à de multiples reprises son ordinateur personnel pour se connecter à la plate-forme commerciale de son entreprise. Sans dispositif d’anonymisation ni chiffrement des échanges. Un membre de sa famille utilisait régulièrement cet ordinateur. Qui, pendant une courte période, a eu un fonctionnement inhabituel, non expliqué. Plusieurs mois après, le RSSI de la société a constaté que l’identifiant et le mot de passe du salarié étaient sur le darkweb. Faute d’authentification forte sur la plate-forme commerciale, des tiers ont accédé à la base de données clients.
Autre cas : celui d’un consultant d’un prestataire informatique d’une société sensible. À son domicile, il s’est fait voler son ordinateur personnel. Il y avait transféré des données de la société depuis son poste de travail pro. Elles étaient stockées sans protection particulière et l’ordinateur n’était sécurisé que par un mot de passe. Le presta n’avait pas avisé la société de ce transfert de fichiers.
La DGSI mentionne aussi une entreprise qui encourageait le BYOD sans l’avoir encadré clairement. Et sans posséder de systèmes de gestion des appareils mobiles à distance. Elle n’a pas pu déterminer ce qui est arrivé au téléphone d’un salarié lors d’un contrôle aéroportuaire. Les autorités étrangères l’ont saisi, ont obtenu son déverrouillage et l’ont emporté dans une autre pièce…
Illustration générée par IA
The post Numérique en entreprise : les mises en garde de la DGSI appeared first on Silicon.fr.
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.
Cohesity renforce son dispositif français. L’éditeur américain, qui se positionne comme leader de la sécurisation des données par l’IA, annonce la nomination de Mathias Michiels au poste de Country Manager France. Basé à Paris, il prend la tête des équipes commerciales locales avec pour ambition d’accélérer la croissance de Cohesity sur ce marché qu’elle considère comme stratégique.
Mathias Michiels arrive avec plus de 15 ans d’expérience dans l’industrie du logiciel. Il a débuté dans la gestion de comptes chez Oracle et SAS Institute, avant de consacrer plus d’une décennie à VMware. Là, il a gravi les échelons jusqu’au poste de Senior Sales Director pour les solutions Tanzu sur la région SEMEA, à la tête d’une équipe transverse de 80 personnes. Un passage qui lui a permis de se forger une expertise reconnue sur les problématiques de cloud hybride, de modernisation applicative et d’espaces de travail numériques.
Sa mission chez Cohesity dépasse le simple pilotage commercial. Mathias Michiels devra imposer un changement de perception sur le marché : faire de Cohesity non pas une solution de protection des données parmi d’autres, mais un partenaire à part entière de la cyber-résilience des organisations capables, selon la promesse de l’entreprise, de survivre aux cyberattaques et d’en ressortir « plus fortes, plus intelligentes et plus fiables ».
Le contexte joue en sa faveur. « Nous sommes à un moment aussi critique pour les entreprises et organisations françaises face à l’accélération des cybermenaces », reconnaît lui-même le nouveau Country Manager. Pour Matthieu Gross, directeur des ventes pour l’Europe du Sud chez Cohesity, « son arrivée marque une étape clé pour notre croissance et notre succès continus dans la région ».
Photo : © DR
The post Mathias Michiels nommé Country Manager de Cohesity France appeared first on Silicon.fr.
Je suis journaliste tech depuis 20 ans, j'ai écrit quantité d’articles sur la cybersécurité. Et je me suis quand même fait arnaquer comme un bleu par un faux conseiller Binance. Témoignage d'une escroquerie par téléphone d'une redoutable efficacité (et d'une humiliation personnelle cuisante).
