Valider le format, la longueur et le checksum d’un IBAN

Ce validateur normalise les espaces et traits d’union usuels, identifie le code pays, vérifie la longueur officielle attribuée à ce pays et applique la règle de checksum mod-97 de l’ISO 7064. Il renvoie chaque décision séparément, ce qui vous permet de contrôler un compte ou de décider par logiciel si une fiche de paiement peut passer à l’étape suivante.

Commencez par un IBAN complet et reconnaissable

Collez ou transmettez l’IBAN complet, avec son code pays de deux lettres et ses deux chiffres de contrôle. Les espaces servant à regrouper les caractères pour faciliter la lecture sont acceptés, tout comme les traits d’union, puis supprimés avant le contrôle. Les minuscules sont converties en majuscules dans le résultat normalisé. Aucun autre signe de ponctuation n’est retiré silencieusement, car cela risquerait de masquer une erreur de copier-coller. Une valeur exploitable doit commencer par deux lettres suivies de deux chiffres, puis ne contenir que des lettres ou des chiffres. La réponse fournit l’IBAN normalisé afin qu’une intégration puisse conserver ou comparer une représentation cohérente. Elle expose également le code pays, la longueur réelle et la longueur attendue au lieu de renvoyer une réponse imprécise. Si le préfixe national ne figure pas dans le registre IBAN pris en charge, la requête produit une erreur de saisie. Cette distinction est essentielle : un schéma inconnu ne peut pas être évalué de manière fiable et ne doit pas être assimilé à un simple échec du checksum.

Comprenez les contrôles de longueur et mod-97

Tous les IBAN n’ont pas un nombre universel de caractères. Chaque pays participant fixe sa propre longueur ; un IBAN allemand n’a donc pas la même taille attendue qu’un IBAN norvégien ou maltais. Le validateur recherche la longueur associée au code pays initial et la compare à la valeur normalisée. Il applique ensuite la procédure IBAN définie par l’ISO 7064 : les quatre premiers caractères passent à la fin, les lettres deviennent des valeurs numériques allant de A égal à 10 jusqu’à Z égal à 35, puis la séquence décimale obtenue est évaluée modulo 97. Un checksum valide laisse un reste de un. L’implémentation calcule progressivement le reste, chiffre par chiffre, plutôt que de construire un entier immense susceptible de dépasser la plage numérique sûre du langage. La réponse présente séparément `length_valid` et `checksum_valid`, puis active `valid` uniquement si les deux contrôles réussissent. Une longueur erronée empêche la validation du checksum, ce qui garantit une décision prudente et facile à exploiter dans les processus automatisés.

Placez le contrôle au bon endroit du parcours de paiement

Effectuez ce contrôle dès qu’un IBAN entre dans votre système : lors de l’envoi d’un formulaire, de l’importation d’un CSV, de l’ajout d’un bénéficiaire ou de la dernière révision avant la création d’un ordre de paiement. Un résultat négatif révèle un problème de format, de longueur ou de checksum et permet donc de détecter rapidement les erreurs de transcription courantes. Il ne prouve pas que le compte bancaire existe, qu’il est ouvert, qu’il appartient au bénéficiaire nommé ni qu’il peut recevoir un virement donné. Ces questions nécessitent les services d’une banque ou d’un prestataire de paiement et peuvent impliquer des contrôles d’identité réglementés. Limitez le rôle du validateur : refusez les identifiants manifestement mal formés, indiquez précisément les contrôles en échec et demandez à l’utilisateur de confirmer le numéro auprès d’une source fiable. L’algorithme est déterministe et n’utilise ni réseau, ni valeur aléatoire, ni horloge, ni consultation externe. Une requête API coûte $0.002, tandis que la page exécute la même logique pure dans le navigateur.