Adresses structurées dans les paiements SWIFT et SEPA : l'échéance a bougé, le travail non

2026-11-05

La date qui a discrètement disparu

Pendant presque toute l'année écoulée, novembre 2026 était entouré en rouge dans le calendrier du secteur des paiements. À partir de ce mois, les messages de paiement transfrontaliers sur le réseau Swift devaient cesser d'accepter les adresses postales rédigées en texte libre, et les paiements SEPA en Europe devaient suivre à partir du 15 novembre. Les banques ont passé des mois à refaire leurs formulaires et leurs fichiers en conséquence.

Puis, à la fin de l'été, les deux dates ont disparu du calendrier. Le 27 août 2026, Swift a annoncé le report des changements liés aux paiements de sa release de standards 2026, y compris la suppression des adresses non structurées, et indiqué qu'il consulterait le secteur avant de fixer un nouveau calendrier, avec une mise à jour attendue d'ici décembre. Le 9 septembre, le comité de gestion des schémas de l'European Payments Council a fait de même pour les cinq rulebooks SEPA : la date de fin du 15 novembre a été supprimée, une nouvelle sera fixée plus tard.

Si votre entreprise envoie ou reçoit des paiements internationaux, il est tentant d'y lire « rien à faire ». Ce n'est pas tout à fait le cas.

Texte libre, structurée, hybride : de quoi parle ce changement

Les messages de paiement modernes, fondés sur la norme ISO 20022, prévoient un champ distinct pour chaque élément d'une adresse : rue, numéro, code postal, ville, pays. Les anciens formats comportaient quelques lignes de texte libre, et beaucoup de paiements y entassent encore toute l'adresse, dans l'ordre choisi par la personne qui l'a saisie.

Le secteur travaille avec trois formats :

• Non structurée : toute l'adresse en texte libre. C'est celle qui est en cours de suppression.
• Entièrement structurée : chaque élément dans son propre champ, avec au minimum la ville et le pays.
• Hybride : ville et pays dans leurs propres champs, plus jusqu'à deux lignes de texte libre de 70 caractères maximum chacune pour le reste. Elle sert de passerelle aux organisations qui ne peuvent pas encore découper proprement chaque adresse.

Pour les banques le long du parcours, le BIC reste un moyen accepté d'identifier la banque elle-même. Le changement concerne surtout les personnes et les entreprises aux deux bouts du paiement : vous, vos clients, vos fournisseurs.

Pourquoi l'emplacement du nom de rue importe

Une adresse en texte libre est facile à lire pour une personne et malcommode pour une machine. « Unit 4, 12 Harbour Road, Limassol 3035, CY » et « Cyprus, Limassol, Harbour Rd 12/4 » désignent le même endroit, mais un contrôle automatisé doit deviner quelle partie est la ville et laquelle est le pays. Le filtrage des sanctions et la surveillance anti-blanchiment dans chaque banque de la chaîne reposent sur ces données. Quand elles ne peuvent pas être lues avec certitude, le paiement est arrêté pour un examen manuel, et quelqu'un vous écrit pour demander des précisions.

Les champs structurés suppriment l'essentiel des suppositions. Un pays dans son propre champ peut être vérifié instantanément, et une ville placée au bon endroit n'est pas confondue avec une partie d'un nom de société. Le bénéfice : moins de paiements bloqués pour des questions et moins de paiements renvoyés. C'est pourquoi le changement arrive malgré tout, même sans date.

Pourquoi le report a eu lieu

En bref : le secteur n'était pas prêt. Les chiffres de préparation cités à l'époque situaient autour de 61% la part des paiements comportant encore des adresses non structurées en avril 2026, et de grandes banques ainsi que des systèmes de paiement nationaux ont demandé plus de temps. Déplacer l'échéance revenait à reconnaître l'ampleur des données encore à nettoyer. Ce n'était pas un changement de cap. J.P. Morgan, par exemple, a qualifié la décision de report, et non d'abandon.

La partie qui vous revient

Les banques peuvent refaire leurs formats de message. Ce qu'elles ne peuvent pas faire facilement, c'est réparer une adresse mal saisie dès le départ. Swift a été explicite : les données d'adresse doivent être justes à la source, et pour une entreprise la source, ce sont généralement ses propres fichiers : listes de fournisseurs, fichiers clients, modèles de facture, bénéficiaires enregistrés dans la banque en ligne.

C'est à cela que sert le temps supplémentaire :

• Découper les adresses en éléments. Pour chaque contrepartie régulière, enregistrez séparément la rue, le numéro, le code postal, la ville et le pays, et non un seul bloc de texte.
• Utiliser des codes pays cohérents. « Germany », « DE » et « Deutschland » devraient devenir une seule valeur, idéalement le code ISO à deux lettres.
• Demander dès l'entrée en relation. Quand un fournisseur envoie ses coordonnées bancaires, demandez en même temps son adresse enregistrée, élément par élément. La plupart répondent une fois et n'y pensent plus.
• Aligner les documents. Le nom et l'adresse du bénéficiaire dans le paiement doivent correspondre à la facture et au contrat. Les divergences sont une cause fréquente de questions, et parfois d'un virement renvoyé.
• Vérifier vos propres coordonnées. L'adresse que voient vos clients lorsqu'ils vous paient doit être votre adresse enregistrée, écrite de la même façon partout.
• Utiliser les champs disponibles. Si un formulaire de paiement ou un fichier d'import comporte des champs distincts pour la ville et le code postal, remplissez-les au lieu de tout mettre sur la première ligne.

Rien de tout cela n'est difficile. C'est fastidieux, et cela touche la finance, les achats et la personne qui gère le système comptable, et c'est exactement pour cette raison que cela passe à la trappe quand il n'y a pas d'échéance.

Ce que cela signifie aujourd'hui pour vos paiements

Rien ne doit changer du jour au lendemain dans vos paiements. Les adresses non structurées, hybrides et structurées restent toutes valides selon la norme Swift actuelle, et les rulebooks SEPA continuent d'autoriser le format non structuré jusqu'à ce que l'EPC fixe une nouvelle date de fin. La mise à jour de Swift sur le calendrier est attendue d'ici la fin de cette année. Quelle que soit la date retenue, il est plus simple d'avoir déjà des données propres que de commencer le nettoyage à ce moment-là.

En attendant, des données désordonnées ont leur propre coût. Un paiement bloqué pendant qu'une banque du parcours demande qui est le bénéficiaire, ou renvoyé parce que les informations ne concordent pas, coûte du temps et souvent des frais. Les paiements SWIFT peuvent transiter par des banques correspondantes, et chacune applique ses propres contrôles. Notre guide sur les virements renvoyés explique ce qui se passe quand les coordonnées sont erronées, et notre présentation SEPA vs SWIFT explique quand chaque circuit s'applique.

La place de Polydirection

Polydirection propose des comptes et des paiements internationaux pour les entreprises aux dossiers complexes : SEPA, SWIFT, IBAN multidevises et Mastercard, regroupés sur un seul compte et examinés individuellement. Les entreprises de crypto, de jeux d'argent, de forex et de rencontres bénéficient d'un gestionnaire dédié, et non d'une lettre de refus standard.

Si vous payez des fournisseurs et des partenaires dans de nombreux pays, cela signifie qu'il y a une personne à qui poser la question quand un paiement est bloqué ou que les coordonnées d'une contrepartie semblent floues. Si vous remettez de l'ordre dans la façon dont vos données de paiement sont organisées, ou si vous voulez vérifier ce qu'il faut pour un paiement sortant avant de l'envoyer, contactez-nous.

Polydirection propose des comptes Personal et Business pour les entreprises de crypto, jeux d'argent, forex et rencontres — consultez la grille tarifaire complète sur la page des tarifs.