Données de test réalistes : adresses, téléphones et IBAN

Le faux confort des valeurs faciles

Les données « trop propres » passent souvent par les mêmes chemins que les cas simples. Elles ne testent ni les limites de longueur ni les hypothèses de format. Un code postal en « cinq chiffres » accepte une adresse française classique, mais rejette les codes canadiens comme M5V 3L9 ou les codes britanniques comme SW1A 2AA. Et une adresse « à 30 caractères » ne vous dit pas non plus ce qui se passe quand un nom de voie plus long est tronqué dans un PDF ou un courriel.

Le problème dépasse l'interface. Une valeur peut être acceptée côté navigateur, puis rejetée par l'API, mal stockée en base, ou affichée avec des caractères corrompus. Tester uniquement le formulaire, c'est vérifier une porte sans regarder le couloir derrière.

Réaliste ne veut pas dire « réel »

L'objectif, c'est de reproduire les propriétés structurelles : longueur, ponctuation, alphabet, ordre des éléments, dépendances entre champs. Pas besoin de copier des coordonnées personnelles pour faire ça. En plus du risque RGPD, utiliser des données réelles peut aussi provoquer des comportements indésirables (envoyer un vrai message, afficher une donnée sensible dans un environnement de démonstration).

Concrètement, distinguez trois niveaux :

• Syntaxiquement valides : elles respectent la forme attendue (par exemple un numéro avec indicatif international).
• Cohérentes entre elles : ville, région et code postal vont ensemble.
• Réellement attribuées : elles correspondent à une personne, un compte ou une adresse existante.

Pour la plupart des tests de formulaires, les deux premiers niveaux suffisent. Le troisième doit être évité, sauf besoin métier clair et encadré.

Un jeu de test doit faire tomber les hypothèses fragiles

Inutile de générer des milliers de profils « au hasard ». Commencez par les décisions de votre produit : pays acceptés, règles de livraison, vérification téléphonique, facturation, export de documents. Ensuite, choisissez des exemples qui forcent ces règles à s'exprimer. Souvent, quelques dizaines de cas bien choisis valent mieux qu'une grosse masse de valeurs répétitives.

Le bon critère, c'est simple : votre jeu de test doit pouvoir faire échouer une hypothèse fragile. Si tout passe sans déclencher de branche différente, augmentez la diversité des formats plutôt que le volume brut.

Modéliser les variations avant de générer

Au Royaume-Uni, le code postal a souvent une partie extérieure et une partie intérieure séparées par une espace, comme SW1A 2AA. Au Canada, on voit fréquemment des alternances lettres/chiffres, par exemple K1A 0B1. L'Irlande utilise des Eircodes du type D02 X285. Au Brésil, le CEP s'écrit souvent avec huit chiffres et un tiret, par exemple 01310-100.

Même logique pour le reste de l'adresse : en Allemagne ou aux Pays-Bas, le numéro de bâtiment vient souvent après le nom de la rue. Au Japon, les adresses reposent davantage sur des blocs et des subdivisions, pas sur un nom de rue « équivalent » au modèle français. Et côté affichage, il suffit parfois de demander une adresse sur une ligne : si votre système suppose un format unique, les conversions et les rendus localisés deviennent rapidement pénibles.

Enfin, les Émirats arabes unis n'utilisent généralement pas de code postal « à la européenne ». Le rendre obligatoire partout revient à exclure des utilisateurs ou à les pousser à inventer une valeur.

Relier le code postal à la ville

Générer une ville et un code postal séparément produit des données qui « ont l'air correctes », mais qui ne sont pas cohérentes. Pour améliorer le réalisme, choisissez d'abord une ville, puis appliquez un motif postal lié à cette zone. Les codes de Leeds commencent souvent par LS, ceux de Toronto par M, et ceux de Munich par 80 ou 81.

Pour un jeu de test ciblé, une petite table de référence suffit : pays, ville, région, motif postal, et éventuellement un indicatif téléphonique. Les motifs peuvent utiliser des jetons : # pour un chiffre, % pour un chiffre de 1 à 9 et @ pour une lettre majuscule.

const villes = [
['Munich', 'Bavière', 'BY', '80###'],
['Hambourg', 'Hambourg', 'HH', '2####']
];
function remplir(motif) {
return motif.replace(/[#%@]/g, jeton => {
if (jeton === '#') return String(entierAleatoire(0, 9));
if (jeton === '%') return String(entierAleatoire(1, 9));
return String.fromCharCode(65 + entierAleatoire(0, 25));
});
}

Ce mécanisme donne une forme plausible, pas une preuve que le code postal est réellement livrable ou assigné. Si votre application vérifie l'éligibilité à une livraison, utilisez plutôt un jeu de données contrôlé par le produit, couvrant les zones réellement prises en charge. Et ne vendez pas un motif « généré » comme une validation postale officielle.

Préserver les caractères et les longueurs

Les accents de São Paulo, Düsseldorf ou Kraków doivent survivre à tout le parcours : saisie, API, base de données, génération de PDF et envoi de courriel. Vérifiez l'encodage UTF-8 et testez les caractères dans chaque composant, pas seulement dans le navigateur.

Prévoyez aussi des noms de voie longs, des espaces, des traits d'union et des champs facultatifs. Un schéma adapté à un pays ne doit pas devenir une règle globale implicite. Le modèle doit conserver les informations utiles, tandis que la couche de présentation décide l'ordre et les libellés adaptés au contexte.

Tester plusieurs représentations du même numéro

Au Royaume-Uni, un numéro peut s'écrire 020 7946 0958 en format national, puis +44 20 7946 0958 en format international. En Allemagne, 030 1234567 devient +49 30 1234567. Pour un numéro fixe italien, le zéro reste présent : 06 1234 5678 peut devenir +39 06 1234 5678.

Ces exemples montrent pourquoi une règle du type « supprimer toujours le premier zéro après l'indicatif » est trop simpliste. À l'inverse, conserver systématiquement ce zéro casse des numéros où ce zéro est bien un préfixe domestique. Les règles doivent venir des métadonnées téléphoniques du pays, ou d'une bibliothèque spécialisée, plutôt que d'une expression régulière bricolée à la main.

Pour chaque pays pris en charge, testez au minimum :

• la saisie nationale avec ses espaces ou séparateurs courants ;
• le format international avec le signe + ;
• le format E.164, compact et normalisé, par exemple +442079460958 ;
• les cas où le zéro initial est supprimé ou conservé ;
• les entrées incomplètes, trop longues et contenant des caractères inattendus.

Séparer stockage et affichage

Si votre produit gère les appels internationaux, stocker dans un format normalisé facilite les comparaisons et l'intégration avec des services externes. Ensuite, l'interface peut afficher le numéro selon la langue ou le pays sélectionné.

Mais ne présumez pas que le pays de résidence, l'indicatif du numéro et le pays de facturation sont forcément identiques.

Et gardez la validation proportionnée : vérifier la structure d'un numéro ne prouve pas qu'il est actif, qu'il appartient à la bonne personne, ou qu'il peut recevoir un SMS. Ces vérifications nécessitent un processus métier séparé. Mélanger les deux donne une fausse impression de sécurité et peut bloquer des utilisateurs légitimes.

Éviter d'appeler ou de contacter une vraie personne

Les données de démonstration ne doivent pas déclencher d'appels, de SMS ou de courriels réels. Utilisez des plages explicitement réservées à la fiction quand elles existent pour un pays et un service donnés, et vérifiez leur statut auprès de l'autorité ou du fournisseur concerné. Et surtout : ne déduisez pas qu'un numéro est fictif parce qu'il vous paraît « bizarre ».

Pour les adresses email de test, les domaines réservés comme example.com et example.org évitent d'adresser un message à quelqu'un. Dans vos environnements de développement, désactivez aussi l'envoi réel par défaut : une mauvaise donnée de test ne devrait jamais suffire à déclencher une communication en production.

Utiliser une source aléatoire adaptée

En JavaScript, Math.random() suffit pour beaucoup de besoins « non sensibles », mais ce n'est pas conçu pour la sécurité. Et appliquer valeur % plage à un entier aléatoire peut introduire un biais léger si la plage ne divise pas exactement l'espace des valeurs possibles.

Pour des tests reproductibles, une graine fixe est parfois préférable : vous gardez ainsi le même jeu à chaque exécution. Dans un navigateur, pour générer des données imprévisibles, crypto.getRandomValues() est plus adapté. La génération de données de test n'exige pas automatiquement du crypto partout ; ça dépend de l'usage. En revanche, si vous réutilisez du code pour générer des jetons ou des secrets, évitez une source non sécurisée.

Pour éliminer le biais du modulo : échantillonnage par rejet. Vous tirez une valeur, vous rejetez la partie haute qui ne forme pas un nombre entier de plages, puis vous recommencez. C'est simple et ça évite que certaines valeurs apparaissent plus souvent.

function entierAleatoire(min, max) {
const plage = max - min + 1;
const limite = Math.floor(0x100000000 / plage) * plage;
const tampon = new Uint32Array(1);
let valeur;
do {
crypto.getRandomValues(tampon);
valeur = tampon[0];
} while (valeur >= limite);
return min + (valeur % plage);
}

Respecter les chiffres de contrôle

L'algorithme de Luhn sert à vérifier la structure de nombreux numéros, y compris des numéros de carte. Pour trouver le chiffre de contrôle : on parcourt les chiffres de droite à gauche, on double un chiffre sur deux, on soustrait neuf si le résultat dépasse neuf, puis on choisit le chiffre qui rend la somme divisible par dix.

Attention : un numéro qui « passe Luhn » n'est valide que pour la forme. Il ne prouve pas qu'il a été émis, ni qu'il est lié à un titulaire, ni qu'il peut être utilisé pour payer. Pour tester un parcours de paiement, utilisez les numéros de test fournis par votre prestataire : ils couvrent leurs réponses simulées, leurs règles et leurs cas d'erreur.

Les IBAN utilisent un contrôle modulo 97. Le calcul réorganise les éléments, remplace les lettres par leurs valeurs numériques, puis calcule le reste, sans devoir convertir toute la chaîne en entier natif. Un IBAN généré peut respecter le contrôle arithmétique tout en ne correspondant à aucun compte bancaire. Il ne valide ni l'existence du compte ni son titulaire.

On retrouve un principe similaire pour les ISBN-13, les codes-barres EAN, certains numéros d'acheminement bancaires américains et les numéros VIN. Les règles changent, et le chiffre de contrôle ne se calcule pas de la même façon selon le format.

Construire une matrice de couverture

Commencez par lister les pays réellement pris en charge, et les règles qui changent selon le pays. Pour chaque règle, définissez : un cas nominal, un cas limite et un cas invalide. Par exemple, pour un code postal : une valeur reconnue, une valeur avec lettres et une valeur trop longue. Pour un champ facultatif : un champ rempli et un champ absent.

Une matrice simple peut inclure :

• Format : chiffres, lettres, espaces, tirets, accents et longueur maximale.
• Structure : ordre de l'adresse, région présente ou absente, nom composé ou en une partie.
• Cohérence : ville et code postal compatibles, indicatif conforme au format attendu.
• Parcours technique : formulaire, API, base, export CSV, PDF et courriel.
• Effet métier : livraison, paiement de test, recherche, déduplication, vérification d'identité.

Et ne vous contentez pas des pays « familiers » à votre équipe. Si votre clientèle est européenne, incluez des formats qui cassent les hypothèses françaises : codes postaux alphanumériques, numéros internationaux et champs régionaux optionnels.

Faire passer les données dans toute la chaîne

Un formulaire peut accepter une chaîne, puis la base tronque, ou le modèle de facture l'affiche mal. Faites circuler vos cas du navigateur jusqu'aux sorties visibles par l'utilisateur. Surveillez notamment : limites de caractères, encodage, normalisation et transformations irréversibles.

Ajoutez aussi ces cas aux tests automatisés quand la règle est stable. Les tests de régression sont particulièrement utiles après une modification de validation, de bibliothèque téléphonique ou de schéma de base de données. Gardez les jeux déterministes si vous avez besoin de reproductibilité stricte ; gardez l'aléatoire pour la robustesse, avec une graine enregistrée pour pouvoir rejouer un échec.

Liste de vérification avant livraison

• Le code postal accepte-t-il des lettres, des espaces et des tirets quand le pays l'exige ?
• Le champ région est-il facultatif là où cette notion n'est pas utilisée ?
• Un nom de voie long survit-il au stockage, aux PDF et aux courriels ?
• Les accents et caractères non latins restent-ils lisibles après un aller-retour via l'API ?
• Le téléphone est-il compris dans ses formes nationale, internationale et E.164 ?
• Les noms à un seul élément et les ordres de nom différents sont-ils acceptés ?
• Les environnements de test empêchent-ils tout envoi réel ou tout paiement réel ?
• Les numéros de test à chiffre de contrôle sont-ils clairement séparés des identifiants réels ?

Choisir cinq ou six pays avec des formats vraiment différents peut révéler plus de défauts qu'une semaine limitée à des données « purement françaises ». L'objectif n'est pas de couvrir le monde d'un coup, mais de retirer les hypothèses qui ne tiennent plus sur vos marchés.