Numéro de carte bancaire générique
Matche un numéro de carte bancaire générique à 16 chiffres, avec espaces ou tirets optionnels entre les groupes.
Pattern proposé
^(?:\d{4}[- ]?){3}\d{4}$
Test rapide
Guide regex
Regex Carte Bancaire - Exemples
La validation de cartes bancaires est fréquente dans les formulaires, pages de paiement et interfaces de checkout. Ce guide propose des exemples pratiques de regex pour les formats de numéros de carte, explique les patterns par marque, et montre pourquoi une regex doit toujours être complétée par une validation de checksum et par le prestataire de paiement.
15 exemples
Numéro de carte bancaire générique
Carte Visa
Mastercard
American Express
Carte bancaire avec espaces ou tirets
Carte Discover
Carte JCB
Carte Diners Club
Les 4 derniers chiffres
Extraire des numéros de carte bancaire
Accepter plusieurs formats de carte bancaire
Masquer un numéro de carte bancaire
Validation d’un formulaire de paiement
Numéro de carte strict à 16 chiffres
Rechercher des numéros de carte dans des logs
9 guides
Une regex peut-elle valider une carte bancaire ?
Comprendre la structure d’un numéro de carte bancaire
Regex Visa vs Mastercard
Gérer les espaces et les tirets
Extraire des numéros de carte bancaire depuis un texte
Masquer les numéros de carte bancaire
Erreurs regex fréquentes
Compatibilité entre moteurs regex
Considérations de performance
Pour aller plus loin
Carte Visa
Matche les numéros de carte Visa. Les cartes Visa commencent par 4 et contiennent 13 ou 16 chiffres.
Pattern proposé
^4\d{12}(?:\d{3})?$
Test rapide
Mastercard
Matche les numéros Mastercard, avec l’ancienne plage 51–55 et la plage plus récente 2221–2720.
Pattern proposé
^(?:5[1-5]\d{14}|2(?:2[2-9]|[3-6]\d|7[01]|720)\d{12})$
Test rapide
American Express
Matche les numéros American Express, qui commencent par 34 ou 37 et contiennent 15 chiffres.
Pattern proposé
^3[47]\d{13}$
Test rapide
Carte bancaire avec espaces ou tirets
Matche les numéros de carte bancaire formatés avec des espaces ou des tirets entre chaque groupe de quatre chiffres.
Pattern proposé
^\d{4}(?:[- ]\d{4}){3}$
Test rapide
Carte Discover
Matche les principaux numéros de carte Discover commençant par 6011, 65 ou 644–649.
Pattern proposé
^(?:6011\d{12}|65\d{14}|64[4-9]\d{13})$
Test rapide
Carte JCB
Matche les numéros de carte JCB, y compris les anciens préfixes 2131 et 1800.
Pattern proposé
^(?:2131|1800|35\d{3})\d{11}$
Test rapide
Carte Diners Club
Matche les numéros de carte Diners Club commençant par 300–305, 36 ou 38.
Pattern proposé
^3(?:0[0-5]|[68]\d)\d{11}$
Test rapide
Les 4 derniers chiffres
Matche les quatre derniers chiffres d’un numéro de carte bancaire, souvent affichés pour des raisons de sécurité.
Pattern proposé
\d{4}$
Test rapide
Extraire des numéros de carte bancaire
Extrait les numéros de carte bancaire à 16 chiffres présents dans un texte, avec espaces ou tirets optionnels.
Pattern proposé
\b(?:\d{4}[- ]?){3}\d{4}\b
Test rapide
Accepter plusieurs formats de carte bancaire
Accepte les numéros de carte à 16 chiffres, avec ou sans espaces ou tirets.
Pattern proposé
^(?:\d{16}|(?:\d{4}[- ]?){3}\d{4})$
Test rapide
Masquer un numéro de carte bancaire
Matche les chiffres centraux d’un numéro de carte afin de les remplacer par des caractères de masquage.
Pattern proposé
(?<=\d{4})\d(?=\d{4})
Test rapide
Validation d’un formulaire de paiement
Accepte les formats de carte bancaire les plus courants saisis dans un formulaire de paiement.
Pattern proposé
^\d(?:[ -]?\d){12,18}$
Test rapide
Numéro de carte strict à 16 chiffres
Matche uniquement un numéro de carte composé de 16 chiffres consécutifs, sans espace ni séparateur.
Pattern proposé
^\d{16}$
Test rapide
Rechercher des numéros de carte dans des logs
Recherche des numéros de carte bancaire dans des fichiers journaux ou des documents texte afin de les masquer ou de les supprimer.
Pattern proposé
\b(?:\d{4}[ -]?){3}\d{4}\b
Test rapide
Une regex peut-elle valider une carte bancaire ?
Une expression régulière permet uniquement de vérifier qu’un numéro de carte bancaire respecte le format attendu. Elle ne peut pas déterminer si la carte existe réellement, si elle est expirée ou si elle est encore valide.
Même un numéro parfaitement formaté peut être invalide. Une validation complète doit toujours combiner une regex, l’algorithme de Luhn et une vérification réalisée côté serveur par votre prestataire de paiement.
Utilisez la regex comme première étape de validation afin d’améliorer l’expérience utilisateur, mais jamais comme unique mécanisme de validation.
Comprendre la structure d’un numéro de carte bancaire
La plupart des cartes bancaires possèdent entre 13 et 19 chiffres selon l’émetteur. Les premiers chiffres identifient le réseau de paiement, tandis que les suivants correspondent au compte du titulaire.
Le dernier chiffre est une clé de contrôle calculée grâce à l’algorithme de Luhn. Cette clé permet principalement de détecter les erreurs de saisie.
Comprendre cette structure permet de choisir la regex adaptée à chaque type de carte plutôt que d’utiliser un unique pattern générique.
Regex Visa vs Mastercard
Les cartes Visa commencent toujours par le chiffre 4, tandis que Mastercard utilise les anciennes plages 51–55 ainsi que les nouvelles plages 2221–2720.
De nombreux exemples de regex disponibles sur Internet ignorent encore les nouveaux préfixes Mastercard, ce qui entraîne des validations incorrectes.
Lorsque cela est possible, vérifiez toujours vos patterns à partir des spécifications officielles des réseaux de paiement.
Gérer les espaces et les tirets
Les utilisateurs saisissent rarement un numéro de carte sans séparateur. Les espaces et les tirets améliorent la lisibilité et sont généralement acceptés par les formulaires de paiement.
Une regex suffisamment souple peut accepter ces séparateurs tout en vérifiant le nombre total de chiffres.
Une autre approche consiste à supprimer les espaces et les tirets avant la validation, ce qui simplifie à la fois la regex et le traitement des données.
Extraire des numéros de carte bancaire depuis un texte
Les expressions régulières sont souvent utilisées pour rechercher des numéros de carte dans des journaux, des e-mails ou des documents importés.
Après leur extraction, ces données sensibles doivent être masquées, chiffrées ou supprimées avant le stockage ou le partage des fichiers.
Évitez les patterns trop permissifs, qui risquent de détecter d’autres identifiants numériques sans rapport avec des cartes bancaires.
Masquer les numéros de carte bancaire
N’afficher que les quatre derniers chiffres d’une carte bancaire est une pratique de sécurité largement utilisée par les banques et les prestataires de paiement.
Les lookarounds permettent de remplacer uniquement les chiffres centraux tout en conservant les premiers et les derniers chiffres.
Le masquage protège les informations sensibles tout en permettant aux utilisateurs d’identifier facilement la carte utilisée.
Erreurs regex fréquentes
Une erreur fréquente consiste à oublier les ancres. Sans ^ et $, une regex peut matcher seulement une partie de la saisie au lieu de valider toute la valeur.
Une autre erreur consiste à rendre les séparateurs trop permissifs, ce qui peut accepter des valeurs mal formées avec un mélange d’espaces et de tirets.
Pour les patterns de validation, décidez toujours si vous voulez valider toute la saisie ou simplement trouver une valeur dans un texte plus long.
Compatibilité entre moteurs regex
La plupart des regex de cartes bancaires fonctionnent en JavaScript, PCRE, Python, Java et dans de nombreux autres moteurs, car elles utilisent surtout une syntaxe simple.
Cependant, les exemples avancés utilisant les lookbehinds ou les groupes nommés peuvent se comporter différemment selon le moteur regex.
Quand un pattern est destiné à la production, testez-le toujours dans le même moteur et le même langage que votre application.
Considérations de performance
Les regex de cartes bancaires sont généralement rapides, car elles reposent surtout sur des longueurs fixes, des classes de chiffres et des alternatives simples.
Les problèmes de performance apparaissent plutôt avec les quantificateurs imbriqués, les alternatives ambiguës ou les patterns qui essaient d’analyser trop de contexte.
Gardez les regex de validation simples, ancrées et spécifiques. Cela améliore la lisibilité, la performance et la sécurité.
Questions fréquentes
Quelle regex de carte bancaire utiliser pour un formulaire de paiement ?
Utilisez un pattern flexible qui accepte les chiffres avec espaces ou tirets optionnels, puis normalisez la valeur avant les contrôles plus avancés.
Pour un vrai paiement, la regex ne doit être qu’un premier filtre. Le numéro doit ensuite être vérifié avec l’algorithme de Luhn et par le prestataire de paiement.
Une regex peut-elle détecter Visa, Mastercard ou American Express ?
Oui, une regex peut détecter les réseaux de cartes courants grâce aux préfixes et aux longueurs attendues.
Mais les plages d’émetteurs peuvent évoluer, donc les patterns spécifiques aux marques doivent être vérifiés régulièrement et ne remplacent pas la validation du prestataire de paiement.
Pourquoi ma regex accepte-t-elle des numéros de carte de test ?
Une regex vérifie uniquement le format visible du numéro.
De nombreux numéros faux ou de test ont une structure valide en apparence, donc ils peuvent matcher une regex sans être de vraies cartes utilisables.
Faut-il accepter les espaces et les tirets dans les numéros de carte ?
Oui, la plupart des formulaires de paiement acceptent les espaces, car ils rendent les longs numéros plus faciles à lire et à saisir.
Une approche courante consiste à accepter espaces ou tirets dans le formulaire, puis à les supprimer avant la validation et le traitement du paiement.
Est-il sûr de rechercher des numéros de carte dans des logs avec une regex ?
Une regex peut aider à détecter des numéros de carte potentiels dans des logs, mais elle doit être utilisée avec prudence.
Les valeurs détectées doivent être masquées, supprimées ou traitées selon vos règles de sécurité et de conformité.
La validation de carte doit-elle se faire en JavaScript ou côté serveur ?
La validation côté client est utile pour donner un retour immédiat à l’utilisateur, mais elle ne doit jamais être la seule couche de validation.
Une validation côté serveur et les contrôles du prestataire de paiement sont indispensables pour tout vrai parcours de paiement.
Pour aller plus loin
📘 Guide recommandé
Limites des regex
Une regex est excellente pour vérifier une structure, un format ou des règles de caractères, mais elle ne comprend pas la logique métier.
Pour les cartes bancaires, cela signifie qu’une regex peut détecter si un numéro ressemble à un numéro de carte, mais pas confirmer que la carte existe, appartient à un utilisateur ou peut être débitée.
Utilisez la regex comme premier filtre rapide, puis appliquez des règles spécialisées, des algorithmes de checksum et des validations fiables côté serveur.
Lire le guide complet →
📘 Guide recommandé
Tester une regex
Les regex de cartes bancaires doivent être testées avec des numéros valides, des préfixes invalides, des saisies incomplètes, des séparateurs et des exemples réalistes.
Ne testez pas uniquement les cas favorables. Ajoutez des numéros compacts, avec espaces, avec tirets, avec séparateurs mélangés, trop courts, et des préfixes de marques qui doivent être rejetés.
Un bon jeu de tests vérifie les deux côtés du pattern : il accepte les formats valides et rejette les saisies mal formées ou dangereuses.
Lire le guide complet →
📘 Guide recommandé
Compatibilité regex
La plupart des patterns de cartes bancaires utilisent une syntaxe simple comme les ancres, classes de chiffres, groupes et alternatives, ce qui les rend compatibles avec JavaScript, PCRE, Python, Java et .NET.
Les exemples plus avancés utilisant lookbehind, groupes nommés ou syntaxe de remplacement peuvent varier selon le moteur regex.
Testez toujours les patterns destinés à la production dans le même langage et le même moteur regex que votre application.
Lire le guide complet →
📘 Guide recommandé
Performance des regex
Les patterns de cartes bancaires sont généralement rapides, car ils reposent sur des longueurs fixes, des classes de chiffres et des alternatives simples.
Les problèmes de performance apparaissent surtout lorsqu’une regex devient trop large, utilise des alternatives ambiguës ou tente d’analyser trop de contexte autour du numéro.
Pour la validation, gardez un pattern ancré, explicite et concentré sur le champ saisi, plutôt que de scanner inutilement de grands blocs de texte.
Lire le guide complet →
📘 Guide recommandé
Bonnes pratiques de validation
Dans un formulaire de paiement, une regex ne doit être qu’une couche de validation après normalisation et avant vérification côté serveur.
Normalisez d’abord la valeur en supprimant espaces et tirets, puis validez le format, puis appliquez les contrôles de checksum et du prestataire de paiement.
La validation regex côté client améliore l’expérience utilisateur, mais toute validation sensible liée au paiement doit toujours être répétée côté serveur.
Lire le guide complet →
📘 Guide recommandé
Classes de caractères
Les regex de cartes bancaires reposent principalement sur des classes de chiffres comme \d et des classes de caractères explicites.
Comprendre les classes de caractères facilite la lecture, la personnalisation et la maintenance de ces patterns.
Lire le guide complet →
📘 Guide recommandé
Quantificateurs
Les regex de cartes bancaires utilisent de nombreux quantificateurs comme {4}, {16} ou des séparateurs optionnels.
Maîtriser les quantificateurs permet de construire des validations précises tout en gardant des patterns simples.
Lire le guide complet →