Pourquoi vous ne devriez pas utiliser l’IA pour générer des mots de passe (et quoi utiliser à la place)

L’intelligence artificielle peut écrire du code, résumer des livres, traduire des langues et répondre à des questions complexes — mais ce n’est pas le bon outil pour générer des mots de passe.

Avec ChatGPT, Claude, Gemini et d’autres assistants, il devient courant de demander un « mot de passe fort et aléatoire ». Au premier regard, le résultat paraît convaincant.

Les apparences trompent

G7$kL9#mQ2&xP4!w

Il coche toutes les cases traditionnelles : long, majuscules et minuscules, chiffres et symboles, et l’air complètement aléatoire.

Malheureusement, les apparences trompent.

Des analyses indépendantes d’Irregular et de Kaspersky montrent que les mots de passe générés par les grands modèles de langage (LLM) sont plus prévisibles qu’ils n’en ont l’air. Au lieu d’une sortie cryptographiquement aléatoire, les LLM introduisent des biais statistiques mesurables qui peuvent réduire l’entropie effective par rapport à un générateur de nombres aléatoires cryptographiquement sûr (CSPRNG).

La distinction peut sembler subtile, mais en sécurité, elle est critique.

L’IA imite l’aléatoire — elle ne le crée pas

La raison tient à une différence architecturale fondamentale.

Les grands modèles de langage sont des moteurs de prédiction. Leur but est de prédire le jeton le plus probable selon des motifs appris à l’entraînement — ce qui les rend excellents pour le langage, les réponses et le code.

C’est aussi pourquoi on ne devrait pas leur confier des mots de passe destinés à protéger des comptes ou systèmes sensibles.

Un générateur de mots de passe sûr fait l’inverse : au lieu de prédire le prochain caractère, il tire des valeurs d’un CSPRNG fourni par le système d’exploitation ou le navigateur — conçu pour être computationnellement imprévisible.

Les navigateurs modernes exposent cela via l’API Web Crypto, ce qui permet à passwords.lu de générer des mots de passe cryptographiquement sûrs entièrement dans le navigateur. Aucune requête de génération vers un serveur, aucun modèle d’IA dans le processus.

Un LLM n’a pas d’équivalent. Il prédit seulement ce qui a l’air aléatoire. Ce sont des objectifs fondamentalement différents.

Avoir l’air aléatoire n’est pas être aléatoire

Les humains sont de mauvais générateurs de nombres aléatoires. Demandez une suite « aléatoire » de chiffres : on évite les répétitions, on alterne impair/pair, on crée des motifs qui « font » aléatoire — et deviennent plus prévisibles.

Les LLM montrent une limite similaire. En apprenant des motifs statistiques dans d’énormes corpus, ils reproduisent ces motifs plutôt qu’une sortie uniformément aléatoire. Leur objectif est le plausible, pas l’imprévisible.

Ces préférences sont mesurables. Dans l’étude « Vibe Password Generation » d’Irregular, Claude Opus n’a produit que 30 chaînes uniques sur 50 essais pour des mots de passe de 16 caractères — et G7$kL9#mQ2&xP4!w est apparu 18 fois. Chez GPT, Claude et Gemini : préfixes répétés, fréquences biaisées et symboles récurrents.

L’analyse Kaspersky pour la Journée mondiale du mot de passe aboutit à la même conclusion à plus grande échelle : 1 000 mots de passe chacun pour ChatGPT, Llama et DeepSeek, avec biais de fréquences, chiffres/symboles souvent absents, et — pour Llama et DeepSeek — des substitutions de type P@ssw0rd.

Pour un humain — ou même un indicateur de force classique — ces mots de passe semblent sûrs. Mais un attaquant qui connaît ces tendances peut prioriser des guesses alignés sur les motifs du modèle, réduisant l’espace de recherche effectif.

Pourquoi l’entropie compte

La sécurité d’un mot de passe ne dépend pas de son apparence aléatoire, mais de son imprévisibilité réelle.

Les cryptographes parlent d’entropie — une mesure d’incertitude. Un mot de passe issu d’un CSPRNG est conçu pour que chaque caractère soit choisi indépendamment d’une source uniformément aléatoire.

Un LLM ne fonctionne pas ainsi. Il prédit le prochain caractère d’après ce qu’il a déjà produit. Même de petites préférences statistiques réduisent l’entropie effective.

Irregular estime l’entropie de Shannon pour des mots de passe Claude de 16 caractères à environ 27 bits via les statistiques de caractères (contre ~98 bits attendus pour un tirage uniforme ASCII imprimable) — et encore moins via les log-probabilités du modèle. Cet écart sépare les estimations « des siècles » des espaces qu’un attaquant peut prioriser.

Des travaux académiques convergent. Une étude arXiv de 2025 sur l’aléatoire et l’entropie des tâches LLM montre que mots de passe et chaînes « aléatoires » générés par les modèles ont une faible entropie, échouent souvent aux tests NIST, et répètent des mots de passe ou sous-chaînes d’une génération à l’autre.

La différence peut être invisible à l’œil humain, mais les attaquants s’appuient sur la probabilité. Quand les probabilités sont biaisées, le guessing devient plus efficace.

L’illusion des indicateurs de force

La plupart des indicateurs évaluent des caractéristiques visibles : longueur, majuscules/minuscules, chiffres, symboles, mots du dictionnaire, répétitions.

Un mot de passe généré par IA obtient souvent un excellent score — souvent « Très fort ». Irregular note que zxcvbn peut encore attribuer une entropie quasi maximale à des mots de passe bien plus faibles sous une analyse adaptée aux LLM.

Kaspersky a trouvé que 88 % des mots de passe DeepSeek et 87 % des Llama échouaient leur barre de sécurité — ainsi que 33 % des ChatGPT — malgré une apparence complexe.

Le problème : ces outils évaluent le mot de passe, pas le processus qui l’a créé. Ils ne détectent pas s’il vient d’une aléatoire cryptographique ou d’un modèle biaisé.

Un mot de passe peut satisfaire toutes les règles de complexité tout en ayant moins d’entropie effective que prévu.

Le risque caché des assistants de code

Le problème ne se limite pas à demander un mot de passe à ChatGPT.

Les développeurs s’appuient de plus en plus sur des assistants IA pour fichiers de config, scripts de déploiement, templates d’infra et exemples. Quand on demande de « générer un mot de passe » ou de « remplir des credentials », l’assistant peut inventer un secret au lieu de recommander un appel à un CSPRNG. Irregular a aussi vu des agents de code préférer et insérer des secrets LLM sans que l’utilisateur le remarque.

• fichiers .env
• templates Docker Compose
• manifests Kubernetes
• scripts de déploiement
• environnements de test
• projets d’exemple

Les secrets temporaires ont tendance à devenir permanents

Si ce mot de passe est copié dans l’un de ces endroits, ses biais statistiques peuvent passer inaperçus pendant des années. Il paraît raisonnable en revue de code, mais hérite toujours du comportement statistique du modèle.

Même remplacés « avant la prod », l’histoire montre que secrets d’exemple, de test et temporaires deviennent souvent permanents.

L’ingénierie de prompts peut-elle corriger cela ?

Certains essayent « Génère un mot de passe vraiment aléatoire », « Aléatoire maximale » ou « Augmente la température ».

Rien de cela ne résout le problème de fond. Changer le prompt change les sorties plus probables — cela ne transforme pas un modèle de langage en CSPRNG.

La conclusion d’Irregular est nette : les mots de passe issus directement d’un LLM sont fondamentalement faibles, et cela ne se corrige pas par le prompt ou la température. Les LLM prédisent des sorties probables — ils ne génèrent pas d’entropie cryptographique.

L’IA reste utile pour la sécurité des mots de passe

Cela ne signifie pas que l’IA est mauvaise pour la cybersécurité — bien au contraire.

Elle peut expliquer les bonnes pratiques, recommander un gestionnaire, enseigner le MFA, aider à reconnaître le phishing, expliquer le hachage, et répondre aux questions générales.

La seule chose qu’elle ne devrait pas remplacer, c’est le générateur de nombres aléatoires lui-même.

Mots de passe IA vs générateurs cryptographiques

Générer de vrais mots de passe aléatoires avec passwords.lu

Pour l’e-mail, la banque, le cloud, les comptes développeur ou les systèmes métier, utilisez des outils conçus pour la sécurité cryptographique.

Chez passwords.lu, la génération ne repose jamais sur l’IA. Chaque mot de passe est créé dans votre navigateur via l’API Web Crypto, à partir du CSPRNG du système d’exploitation.

• génération locale sur votre appareil
• rien n’est transmis à nos serveurs pendant la génération
• aucun modèle d’IA n’influence la sortie
• aucun motif linguistique n’affecte le choix des caractères
• chaque caractère vient d’une aléatoire cryptographiquement sûre

Conclusion

Le résultat est exactement ce qu’un mot de passe doit être : réellement imprévisible — pas seulement l’air aléatoire.

L’IA transforme le développement, l’éducation et la productivité. La génération de mots de passe exige toutefois une propriété complètement différente de la génération de langage.

Les LLM produisent des sorties probables. Les générateurs sûrs produisent des sorties imprévisibles.

La différence entre « qui a l’air aléatoire » et « cryptographiquement aléatoire » peut être invisible — mais elle compte pour les attaquants.

Quand votre sécurité dépend de l’imprévisibilité, utilisez un générateur basé sur l’aléatoire cryptographique, pas sur la prédiction linguistique.

Vos mots de passe protègent votre identité, vos finances, vos systèmes et vos données. Ils méritent une vraie aléatoire.

Sources et lectures complémentaires

• Irregular — Génération de mots de passe « vibe » : prévisible par conception
• Kaspersky — Créer un mot de passe fort et mémorable (analyse IA, Journée mondiale du mot de passe 2025)
• arXiv:2510.12080 — Qualité de l’aléatoire et de l’entropie dans les tâches prises en charge par les grands modèles de langage
• Bruce Schneier — Les LLM génèrent des mots de passe prévisibles

À lire aussi

• D’où vient l’aléatoire des mots de passe
• Générateur de mots de passe