Vue lecture

Numérique en entreprise : les mises en garde de la DGSI

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.

Deepfakes, shadow AI… et due diligence sans vigilance

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.

Des approches indésirables sur les réseaux sociaux professionnels

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.

Les points faibles des logiciels industriels

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.

Entre phishing et keyloggers, la DGSI n’oublie pas le « facteur humain »

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.

Le BYOD, consultants compris

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.

  •  

Clés API volées - Comment éviter une facture à 82 000 dollars

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

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"

Empêcher les fuites à la source

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 .

Détecter un vol avant la catastrophe

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.

Source

  •  
❌