Générer des données de test
Remplir une base de recette avec de vraies coordonnées bancaires est une fuite de données qui attend son heure. Ces valeurs passent tous les validateurs — le vôtre, le nôtre — et ne désignent rien ni personne.
Toutes ces valeurs sont fictives et destinées aux environnements de test. Les numéros de carte proviennent des plages de test publiées par les prestataires de paiement : aucun système de production ne les accepte. Les adresses utilisent les domaines réservés par la RFC 2606, les numéros de téléphone les plages de fiction ARCEP et Ofcom.
Comment le contrôle fonctionne
- 1
Chaque valeur est calculée, pas tirée d'une liste
Le corps du numéro est aléatoire, la clé est calculée dessus : Luhn pour les cartes et les SIRET, mod-97 pour les IBAN, clé GS1 pour les codes-barres, 97 moins le reste pour le NIR.
- 2
Les plages réservées sont respectées
Cartes de test des prestataires de paiement, domaines example.com de la RFC 2606, plages téléphoniques de fiction. Rien de ce qui sort d'ici ne peut atteindre un vrai destinataire.
- 3
Rien ne transite
Le tirage se fait dans votre navigateur, avec l'API Web Crypto quand elle est disponible. Aucune valeur générée n'existe ailleurs que sur votre écran.
Pourquoi ne pas copier des données de production
C'est la pratique la plus répandue et la plus coûteuse : un dump de la base de prod importé en recette, et voilà des milliers de coordonnées personnelles dans un environnement sans les mêmes protections, souvent accessible à des prestataires.
Le RGPD traite ce copiage comme un traitement à part entière, avec sa base légale et sa durée de conservation. Un jeu de données fabriqué n'a aucune de ces contraintes.
Valide ne veut pas dire utilisable
Un IBAN généré ici satisfait le mod-97, donc il franchira le contrôle de saisie de votre application. Il ne désigne aucun compte : un virement émis dessus reviendra en rejet. C'est exactement le comportement attendu d'un jeu de tests.
Questions fréquentes
Ces numéros de carte peuvent-ils servir à payer ?
Non. Ils appartiennent aux plages de test que Stripe, Adyen et les autres prestataires publient et rejettent en production. Ils servent à traverser un formulaire de paiement en environnement de test, rien de plus.
Les IBAN générés existent-ils ?
Non. La clé mod-97 est correcte, ce qui les fait passer tous les validateurs de forme, mais le numéro de compte est tiré au hasard sur un code banque de démonstration. Aucun établissement ne les reconnaîtra.
Puis-je en générer des milliers pour un jeu de charge ?
Rechargez la page autant de fois qu'il le faut, ou reprenez les algorithmes : ils sont décrits sur chaque page d'outil. Pour un volume industriel, l'API de validation vous permet surtout de vérifier que votre propre générateur produit bien des valeurs conformes.
Le même contrôle par API
Cet outil tourne dans votre navigateur. Pour le même contrôle dans votre code, en masse ou côté serveur, l'API répond en JSON.
Voir la documentation