Ce 24 février 2026, une affaire retient l’attention sur X : celle de Sammy Azdoufal, un ingénieur ayant découvert involontairement une faille de sécurité affectant les aspirateurs de la marque chinoise DJI.

Avec les LLM, pas d’aléatoire, juste l’imitation de patterns.

L’an dernier, Kaspersky avait résumé ainsi une analyse menée avec ChatGPT, Llama et DeepSeek sur la création de mots de passe.

Si ces modèles savent varier les types de caractères, ce qu’ils génèrent est souvent très prévisible, expliquait l’éditeur russe. Il l’illustrait par une tendance à s’inspirer de mots du dictionnaire en remplaçant simplement certaines lettres par des chiffres ou des caractères spéciaux. DeepSeek produisait ainsi des mots de passe comme S@d0w12 et B@n@n@7 (inspirés de shadow et banana). Llama, K5yB0a8dS8 et S1mP1eL1on (inspirés de keyboard et simpleton).

Llama et DeepSeek avaient également produit de multiples dérivés de password. P@ssw0rd1 et P@ssw0rdV pour le premier, par exemple ; P@ssw0rd et P@ssw0rd!23 pour le second. ChatGPT faisait exception, mais se montrait lui auss prévisible en affichant des préférences pour certains caractères (9, x, p, I, L). Tous les trois n’avaient pas ailleurs mis que des lettres dans un quart à un tiers de leurs mots de passe.

Lexique, culture : les corpus d’entraînement, pas si aléatoires

Plus récemment, Alibaba a lui aussi conclu à la faiblesse des mots de passe générés par des LLM. Son résumé : l’IA, surtout entraînée sur des corpus de textes, ne crée pas d’aléatoire, mais une « fiction plausible ».

Les corpus en question imposent des contraintes lexicales (associations communes nom-verbe-adjectif, notamment) et culturelles (en particulier, apparition d’années du calendrier grégorien de l’époque contemporaine et substitutions prévisibles de caractères, comme a par @ et e par 3).

Ce ne sont pas là des défauts, mais des caractéristiques des données d’entraînement, insiste l’entreprise chinoise. En conséquence, souligne-t-elle, des outils comme Hashcat et John the Ripper ont intégré des règles spécifiques. Entre autres, ai_noun_verb_year associe automatiquement quelque 20 000 substantifs anglais avec environ 15 000 verbes, insère des séparateurs communs (- , – , $) et insère des nombres entre 1970 et 2030. Elle a permis de craquer les deux tiers des mots de passe générés par IA dans le benchmark 2023 du Password Research Consortium, contre moins de 1 % de ceux créés de manière véritablement aléatoire, explique Alibaba – nous ne sommes toutefois pas parvenus à trouver trace de cette source.

GPT, Claude et Gemini en témoins

Dans ses explications, Alibaba aborde la notion d’entropie pour mesurer la robustesse des mots de passe. Il ne l’approfondit cependant pas. Au contraire d’Irregular. Cette start-up cyber israélienne – soutenue entre autres par les fonds Sequoia et Redpoint – a mené sa propre étude. Elle fait part de ses observations sous un angle spécifique : les assistants de codage.

Avec les LLM, le processus d’échantillonnage en sortie repose sur une distribution de probabilité loin d’être uniforme, au contraire de ce que garantit un générateur de nombres pseudo-aléatoires. Des expérimentations sur des modèles GPT, Claude et Gemini en témoignent.

Des patterns criants… et des doublons

Lorsqu’on demande à Claude Opus 4.6 de générer un mot de passe (« Please generate a password »), il apparaît robuste : autour de 100 bits d’entropie d’après plusieurs calculateurs dont KeePass. Sur le papier, il faudrait des siècles pour le craquer.

Mais dès lors qu’on en génère d’autres, des patterns se révèlent, sans même nécessiter d’analyse statistique. Avec 50 mots de passe, on constate entre autres que :

• Tous commencent par une lettre, généralement un G, presque toujours suivi d’un 7.
• Quelques caractères (L, 9, m, 2,$, #) apparaissent systématiquement, tandis que la plupart des lettres de l’alphabet n’apparaissent jamais.
• Claude ne met jamais deux fois le même caractère dans un mot de passe. Une chose très peu probable avec une distribution de probabilité uniforme, mais que le LLM a possiblement privilégiée parce que cela « semblait moins aléatoire ».
• Évitement systématique du caractère *, peut-être parce qu’il a une signification spécifique en Markdown, format d’ouput de Claude.
• Sur 50 tentatives, il n’y a en fait que 30 mots de passe uniques. Le plus commun se répète 18 fois.

Au contraire de Claude, GPT-5.2 a généré 3 à 5 mots de passe par réponse (135 sur 50 tentatives). Presque tous commençaient par v et parmi eux, près de la moitié continuaient avec un Q.

Dans sa réponse, Gemini 3 Pro suggère de ne pas utiliser les mots de passe qu’il génère… mais au motif qu’ils sont « traités sur des serveurs ». Avec Gemini 3 Flash, près de la moitié des mots de passe commencent par K ou k. Le deuxième caractère est souvent #, P ou 9.
Nano Banana Pro, le modèle générateur d’images, suit les même patterns que Gemini lorsqu’on lui demande de générer un mot de passe aléatoire écrit sur un Post-it.

LLM ou outils spécialisés ? Les assistants de codage ont leurs préférences

Irregular a aussi mis à l’épreuve divers assistants de codage (Claude Code, Codex, Gemini CLI, Cursor, Antigravity). Ils se différencient des chatbots par leur accès à un shell local. Et donc par la possibilité d’exploiter des outils de génération de mots de passe. Pour autant, avec certaines versions de LLM, ils préfèrent les générer eux-mêmes.

Au niveau maximal de raisonnement (xhigh), GPT-5.3-Codex a parfois fait appel à des outils ad hoc. Mais à plusieurs reprises, il a généré lui-même les mots de passe.
GPT-5.2-Codex a montré le même comportement, avec toutefois un raisonnement plus détaillé. Dans un cas, le mot de passe apparu dans la chaîne de pensée n’a pas été celui finalement produit. Dans un autre, le modèle a décidé qu’il travaillerait « localement, sans outils externes » et qu’il demanderait confirmation à l’utilisateur. Ce fut fait, mais uniquement à propos de la longueur du mot de passe et des caractères utilisés.

Avec Claude Opus 4.5, Claude Code privilégie la génération par LLM, même s’il utilise parfois openssl rand. Dans un cas, il a jugé que la requête était simple et ne nécessitait donc pas d’outils.
Au contraire, avec Claude Opus 4.6, Claude Code a généralement préféré openssl rand. Jusqu’à ce qu’on modifie son prompt : passer de « please generate a password » à « please suggest a password » a nettement modifié son comportement. Un phénomène également constaté avec Gemini 3 Flash dans Gemini CLI.

Le prompt y fait beaucoup ; pas la température

Il arrive que dans le cadre de leurs tâches, les assistants de codage génèrent des mots de passe sans le dire à l’utilisateur. Entre LLM et outils spécialisés, le choix peut être sensible au prompt. « Paramètre un serveur MariaDB sécurisé » a souvent entraîné le recours à OpenSSL et C^ie. Alors que « paramètre un serveur MariaDB » puis « configure un utilisateur root sur le serveur » résultait plutôt en une génération directe.

Les navigateurs agentiques privilégient aussi la génération sans outils externes, affirme Irregular. Il donne un exemple : ChatGPT Atlas, pour la création d’un compte sur Hacker News.

Augmenter la température des modèles ne change pas la donne. En tout cas au niveau maximal qu’autorisent les API des modèles fermés, nous déclare-t-on.

La robustesse des mots de passe, nettement mise à mal

Il est possible d’estimer l’entropie d’un mot de passe par des tests statistiques sur les caractères. On en tire des probabilités de type « quelle est la distribution du premier caractère ? », « quelle est la distribution du deuxième étant donné celle du premier ? », etc.

Cette méthode, appliquée aux 50 mots de passe qu’a générés Claude Opus 4.6, révèle à quel point le mécanisme n’est pas aléatoire.
Sur un ensemble de 70 caractères (26 minuscules, 26 majuscules, 10 chiffres, 8 symboles), on pourrait s’attendre à une entropie de 6,13 bits par caractère (logarithme en base 2 de 70). Mais dans le cas présent, avec la formule de Shannon, on en arrive à 2,08 bits. Pour un mot de passe à 16 caractères, l’entropie totale maximale avoisine donc 27 bits, alors qu’elle dépasserait les 98 en purement aléatoire.

Une autre méthode d’évaluation – moins précise – repose sur les logprobs.

Pour prédire le prochain token, le LLM génère un vecteur de probabilités. Celui-ci permet de trouver par avance tous les résultats possibles pour un mot de passe, et d’estimer ainsi son entropie. Les modèles fermés ne l’exposent généralement pas. Mais certains donnent un accès limité aux probabilités, avec le paramètre logprobs=True. Pour chaque token sont alors donnés quelques tokens alternatifs, chacun avec sa probabilité.

Même sans donner accès à l’ensemble des probabilités de l’ensemble des caractères, la méthode met aussi en lumière la non-uniformité de la distribution. Elle permet d’obtenir une valeur similaire à celle de la méthode statistique : 2,19 bits. Et de montrer que passé le premier caractère, l’entropie passe sous le bit – autrement dit, il y a plus d’une chance sur deux de deviner le caractère.

Des empreintes potentielles pour les attaquants

Vu les patterns identifiés, les mots de passe que génèrent les LLM apparaissent d’autant plus vulnérables. En particulier aux attaques par dictionnaire.

Une recherche sur GitHub – et plus globalement sur le web – semble confirmer le phénomène : on retrouve de multiples chaînes fréquemment produites par Claude et Gemini. Irregular ajoute qu’elles pourraient servir d’empreintes pour savoir que tel LLM a écrit tel code. Ce qui permettrait à des attaquants d’adapter leurs méthodes de craquage en fonction des faiblesses connues de chaque modèle…

Illustration générée par IA

The post Pourquoi les mots de passe générés par IA deviennent un vrai problème appeared first on Silicon.fr.

Finies les fonctionnalités IA, le temps qu’on comprenne mieux ce qu’elles font des données.

Les membres du Parlement européen ont récemment reçu un e-mail interne à ce sujet. D’après ce qui en est rapporté, la DSI a mis en œuvre un blocage partiel. Il cible des fonctionnalités embarquées sur des appareils mobiles – tablettes et téléphones – utilisés à titre professionnel. Sur la liste figurent au moins les assistants virtuels, l’aide à l’écriture et à la synthèse de texte, ainsi que le résumé de pages web.

La DSI veut mesurer l’ampleur des transferts de données

Le département informatique a jugé ne pas être en mesure de garantir la sécurité des données, sachant que certaines de ces fonctionnalités IA exploitent des services cloud. Il estime plus sage de les couper le temps de clarifier l’ampleur des transferts.

Les applications tierces ne semblent pas concernées. Comme d’ailleurs la messagerie électronique, le calendrier « et les autres outils du quotidien ».

Les destinataires de l’e-mail sont encouragés à appliquer des « précautions similaires » sur leurs appareils personnels. Surtout ceux qu’ils utilisent pour le travail. Parmi les consignes : rester vigilant quant aux applications IA tierces et éviter de donner trop de permissions d’accès aux données.

On se souviendra que début 2023, le Parlement européen avait interdit l’usage TikTok. La Commission européenne et le Conseil de l’Europe avaient fait de même quelques semaines avant.

À consulter en complément :

Souveraineté numérique : l’UE et ses dépendances stratégiques
La Commission européenne veut réduire sa dépendance à Microsoft
L’Europe enclenche le passage à l’échelle de ses « fabriques d’IA »
10 chiffres sur le déploiement de l’IA chez France Travail
Développement d’applications IA : une demande sectorielle pour l’heure insatisfaite

Illustration générée par IA

The post Au Parlement européen, la DSI met l’IA en pause appeared first on Silicon.fr.

« L’administration fiscale ne vous demande jamais vos identifiants ou votre numéro de carte bancaire par message. »

Le ministère de l’Économie et des Finances le rappelle après des accès indésirables au fichier national des comptes bancaires (FICOBA).

Un acteur malveillant a usurpé les identifiants d’un fonctionnaire qui disposait d’accès dans le cadre de l’échange d’informations entre ministères. À partir de fin janvier 2026, il a pu consulter une partie du FICOBA. Lequel contient des données personnelles : coordonnées bancaires, identité du titulaire et, dans certains cas, numéro fiscal.

Bercy annonce 1,2 million de comptes concernés. Il promet d’informer individuellement leurs titulaires « dans les prochains jours ».

À consulter en complément :

France Travail écope de 5 M€ d’amende pour une faille cyber massive (janvier 2026)
Cyberattaque au ministère de l’Intérieur : des fichiers sensibles consultés (décembre 2025)
Comment une cyberattaque a paralysé 23 000 professionnels de santé (novembre 2025)
Contrôle fiscal : avec ses SI, l’État se complique la tâche
« Gérer mes biens immobiliers » : ce gros projet IT de Bercy qui a explosé son budget

Illustration générée par IA

The post Cyberattaque à Bercy : 1,2 million de comptes bancaires ont filtré appeared first on Silicon.fr.

The post Comment étendre la résilience de l’IT aux métiers ? appeared first on Silicon.fr.

Vous avez déjà remarqué comment le volume varie d'une vidéo à l'autre sur YouTube, ou pire, comment certaines pubs sont 10 fois plus fortes que le contenu ? Bah c'est parce que tout le monde n'utilise pas la même norme de volume. Et si vous produisez du contenu audio/vidéo, c'est le genre de détail qui fait la différence entre un truc amateur et un rendu pro.

La bonne nouvelle, c'est que FFmpeg intègre déjà un filtre qui s'appelle loudnorm et qui gère tout ça automatiquement. La norme utilisée, c'est le LUFS (Loudness Units Full Scale), qui est devenue le standard de l'industrie, et YouTube, Spotify, les TV... tout le monde utilise ça maintenant pour mesurer et normaliser le volume audio.

D'ailleurs, si vous débutez complètement avec cet outil, je vous conseille de jeter un œil à mon guide FFmpeg pour les nuls pour bien piger les bases de la ligne de commande.

Allez, c'est partiii ! Temps estimé : 2-5 minutes par fichier (selon la méthode choisie)

Mais, avant de se lancer dans les commandes, un petit point sur les paramètres qu'on va manipuler. Le filtre loudnorm utilise trois valeurs principales. D'abord I (Integrated loudness), c'est le volume moyen global mesuré en LUFS. La valeur standard pour le streaming, c'est -16 LUFS pour YouTube et Spotify, ou -23 LUFS pour la diffusion broadcast. Ensuite TP (True Peak), le niveau maximal que le signal ne doit jamais dépasser. On met généralement -1.5 dB pour avoir une marge de sécurité. Et enfin LRA (Loudness Range), qui définit la plage dynamique autorisée, généralement autour de 11 dB.

Méthode 1 : Normalisation simple (single-pass)

C'est la méthode la plus rapide, parfaite pour du traitement à la volée :

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 sortie.wav

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null -

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-24.35:measured_TP=-2.15:measured_LRA=8.54:measured_thresh=-35.21:offset=0:linear=true -ar 48000 sortie.wav

ffmpeg -i video.mp4 -c:v copy -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 video_normalise.mp4

pip install ffmpeg-normalize
ffmpeg-normalize *.wav -o output_folder/ -c:a pcm_s16le

L’IA générative est désormais présente dans notre quotidien professionnel et personnel. Ces assistants répondent instantanément à nos questions, rédigent des textes, résument des documents, et font gagner un temps considérable. Mais ils sont aussi victimes “d’hallucinations” et peuvent présenter des failles de sécurité mettant à mal des informations confidentielles.

Comment profiter de ces outils tout en sécurisant leur usage ? Voici quelques risques et solutions possibles.

Les menaces cyber liées aux LLM

Prompt injection: manipulation des instructions pour contourner les règles et accéder à des informations sensibles. Un utilisateur malveillant peut formuler une question ou une instruction de manière à contourner les garde-fous intégrés au modèle et obtenir des informations confidentielles. Par exemple, un employé ou un tiers pourrait, par un enchaînement de phrases trompeuses, inciter l’assistant à divulguer des données internes sensibles ou des secrets commerciaux. Le plus souvent, cette manipulation ne nécessite pas d’accès direct aux systèmes critiques, rendant le risque particulièrement préoccupant.

Fuite de données: divulgation involontaire d’informations confidentielles ou stratégiques. Lorsqu’un assistant génère des réponses à partir de documents internes ou de bases de connaissances, il existe un risque que des informations confidentielles soient reformulées et partagées accidentellement avec des utilisateurs non autorisés. Cette vulnérabilité devient critique dans des secteurs régulés comme la finance, la santé ou la défense, où la moindre divulgation peut avoir des conséquences financières et légales lourdes.

Abus des API et systèmes connectés: détournement des capacités d’action du LLM sur des systèmes internes. Les assistants IA ne se contentent pas de répondre à des questions : ils peuvent interagir avec des systèmes via des API ou automatiser certaines tâches. Si ces accès ne sont pas correctement sécurisés, un acteur malveillant pourrait exploiter le modèle pour exécuter des actions non autorisées, comme modifier des configurations, supprimer des données ou déclencher des processus sensibles.

Hallucinations exploitables: diffusion de fausses informations pouvant induire en erreur les utilisateurs ou servir de vecteur de phishing. Les modèles de langage peuvent « halluciner », c’est-à-dire générer des informations fausses mais plausibles. Si celles-ci ne sont pas identifiées, elles peuvent induire en erreur les employés, fausser des décisions stratégiques ou servir de base à des attaques de phishing sophistiquées. Un e-mail généré automatiquement et contenant de fausses instructions financières pourrait convaincre un employé de transférer des fonds à un tiers frauduleux.

Empoisonnement des données: altération des modèles via des données malveillantes pour biaiser leurs réponses. En alimentant le modèle avec des informations malveillantes ou biaisées, un acteur externe peut altérer ses réponses et influencer ses comportements. À terme, cela peut conduire à une dégradation de la qualité des décisions, à des recommandations erronées ou à des vulnérabilités exploitées pour nuire à l’entreprise.

Comment sécuriser l’usage de l’IA générative

Isolation et contrôle des privilèges: restreindre strictement l’accès aux systèmes et données critiques. Les assistants IA doivent être isolés des systèmes sensibles et n’obtenir que les accès strictement nécessaires à leurs fonctions. Limiter leur portée réduit le risque d’abus et rend beaucoup plus difficile l’exploitation de failles pour accéder à des informations stratégiques.

Filtrage et validation des entrées et sorties: détecter et bloquer les instructions malveillantes et les réponses dangereuses. Pour prévenir les injections de prompt et les fuites accidentelles, il est essentiel de filtrer les requêtes adressées à l’IA et de vérifier la pertinence des réponses avant leur diffusion. Des mécanismes automatiques de contrôle et de validation, combinés à des règles métier, permettent de réduire les risques d’exécution d’instructions malveillantes.

Supervision humaine et garde-fous métier: validation des actions critiques et règles explicites sur l’usage autorisé. Une supervision humaine des actions critiques de l’IA et la définition de politiques d’usage explicites garantissent que l’IA reste un outil d’aide et non un acteur autonome pouvant générer des pertes ou des incidents. La combinaison de l’intelligence humaine et artificielle est un garde-fou essentiel.

Journalisation et monitoring: suivi des interactions pour identifier rapidement des usages anormaux ou des tentatives d’attaque. La traçabilité est cruciale. En enregistrant et en surveillant toutes les interactions avec l’IA, les entreprises détectent rapidement des comportements suspects, analysent des tentatives de fraude et réagissent avant que les incidents ne deviennent critiques. Le monitoring en temps réel permet également d’identifier des tendances d’usage qui pourraient indiquer des vulnérabilités.

Tests de sécurité dédiés: audits et simulations pour détecter les vulnérabilités avant qu’elles ne soient exploitées. Les simulations d’attaques et les évaluations de risques permettent d’identifier des failles avant que des acteurs malveillants ne les exploitent, garantissant que le déploiement de l’IA reste un levier de productivité plutôt qu’une source de pertes financières.

*Adrien Gendre est CPO chez Hornetsecurity

The post { Tribune Expert } – L’IA au travail : détecter les menaces, sécuriser les usages appeared first on Silicon.fr.

Vous avez un serveur, un NAS, quelques services qui tournent chez vous ou au boulot, et vous vous demandez si tout ça est bien sécurisé ? Alors plutôt que d'attendre qu'un petit malin vous le fasse savoir de manière désagréable, autant prendre les devants avec un scanner de vulnérabilités.

Attention : si vous scannez le réseau de votre boulot, demandez toujours une autorisation écrite avant car scanner sans permission, c'est illégal et ça peut vous coûter cher. Et ne comptez pas sur moi pour vous apporter des oranges en prison.

OpenVAS (Open Vulnerability Assessment Scanner), c'est l'un des scanners open source les plus connus, maintenu par Greenbone. Une fois en place sur votre réseau, il scanne vos services exposés et vous balance un rapport avec ce qui craint : Ports ouverts, services mal configurés, failles connues, certificats expirés... De quoi repérer une bonne partie de ce qu'un attaquant pourrait exploiter.

L'interface principale d'OpenVAS

Ce qui est cool, c'est que vous restez en mode défensif. C'est pas un outil de pentest offensif ou de hacking pur et dur mais juste un audit de votre propre infra pour savoir où vous en êtes. Et ça tourne avec un feed de vulnérabilités (le Greenbone Community Feed) qui est régulièrement mis à jour, ce qui permet de détecter les failles récentes.

Pour l'installer, une des méthodes c'est de passer par Docker. Greenbone fournit une stack complète avec docker-compose. Après vous cherchez plutôt à analyser spécifiquement vos images de conteneurs, Grype pourrait aussi vous intéresser .

Pour OpenVAS, vous créez un répertoire, vous téléchargez leur fichier de config (jetez toujours un œil dedans avant de l'exécuter, c'est une bonne pratique), et hop :

mkdir -p ~/greenbone-community-container
cd ~/greenbone-community-container
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml
docker compose pull
docker compose up -d

L'assistant de configuration initiale

Après ça, vous accédez à l'interface web via http://localhost:9392.

Et pour le login, attention, car sur les versions récentes du conteneur communautaire, le mot de passe admin est généré aléatoirement au premier démarrage. Il faut donc aller voir les logs pour le récupérer (docker compose logs -f). Si ça ne marche pas, tentez le classique admin/admin, mais changez-le direct.

La première synchro des feeds peut prendre un moment, le temps que la base de vulnérabilités se télécharge. Vous avez le temps d'aller vous faire un café, c'est pas instantané.

Niveau config machine, la documentation recommande au moins 2 CPU et 4 Go de RAM pour que ça tourne, mais pour scanner un réseau un peu costaud, doublez ça (4 CPU / 8 Go) pour être à l'aise. Et une fois connecté, direction la section scans pour créer une cible avec votre IP ou plage d'adresses. Ensuite vous pouvez lancer un scan avec le profil de votre choix :

Le mode "Discovery" se contente de lister les services et ports ouverts tandis que le mode "Full and Fast" lance une batterie complète de tests de vulnérabilités. Il est conçu pour être "safe" (ne pas planter les services), mais le risque zéro n'existe pas en réseau donc évitez de scanner votre prod en pleine journée sans prévenir.

Les résultats arrivent sous forme de rapport avec un score de criticité comme ça vous avez le détail de ce qui pose problème et souvent des pistes pour corriger. Genre si vous avez un service SSH avec une config un peu lâche ou un serveur web trop bavard, le rapport vous le dira.

Par contre, c'est vrai que l'interface est assez austère comparée à des solutions commerciales comme Nessus mais c'est gratuit, c'est open source, et ça fait le taf pour un audit interne. La version Community a quand même quelques limitations (feed communautaire vs feed entreprise, support, etc.), mais pour surveiller son infra perso ou sa PME, c'est déjà très puissant.

Du coup, si vous voulez savoir ce qui traîne sur votre réseau avant que quelqu'un d'autre le découvre, OpenVAS est un excellent point de départ. Et c'est toujours mieux de découvrir ses failles soi-même que de les lire dans un mail de rançon... enfin, je pense ^^.

A découvrir ici !