Adresses structurées ISO 20022

Mis à jour le 17 septembre 2026

Les adresses en texte libre disparaissent des messages de paiement. Le principe est acté depuis longtemps, mais 2026 a vu deux reports d'échéance en trois semaines, et la confusion règne : Swift et SEPA ne suivent pas le même calendrier, l'Allemagne maintient une date que la France n'a plus, et personne ne dit clairement quels champs remplir. Ce guide fait le point, à jour au 17 septembre 2026.

L'essentiel en trente secondes

• Une adresse de paiement doit passer du texte libre (les balises AdrLine) à des champs séparés : rue, numéro, code postal, ville, pays.
• Deux calendriers distincts : Swift pour les paiements internationaux, l'EPC pour les paiements SEPA. Les deux ont été repoussés à l'été 2026, à des dates différentes et pour des raisons différentes.
• Aucune nouvelle date ferme n'est connue à ce jour. Swift consultera le marché d'ici décembre 2026, l'EPC devait trancher à sa réunion d'octobre.
• Certaines places n'ont rien reporté : les banques allemandes et luxembourgeoises maintiennent, elles, le 15 novembre 2026 pour la fin des anciens formats de fichiers.
• Le report ne change rien au vrai chantier : la qualité de vos référentiels tiers. Une adresse incomplète dans l'ERP le reste, quelle que soit la date.

Structuré, hybride, non structuré : les trois formats

ISO 20022 décrit une adresse postale dans un bloc PstlAdr. Trois façons de le remplir coexistent, et la confusion entre elles est la première source d'erreur.

Non structuré. Tout est en texte libre, dans des balises AdrLine qui se suivent. C'est ce format qui disparaît.

<PstlAdr>
  <AdrLine>12 RUE DU FAUBOURG SAINT-HONORE</AdrLine>
  <AdrLine>75008 PARIS</AdrLine>
</PstlAdr>

Hybride. La ville et le pays passent dans leurs balises dédiées, le reste demeure en texte libre. C'est le compromis accepté par Swift et par les rulebooks SEPA, et celui que retiennent beaucoup de banques comme minimum acceptable.

<PstlAdr>
  <TwnNm>PARIS</TwnNm>
  <Ctry>FR</Ctry>
  <AdrLine>12 RUE DU FAUBOURG SAINT-HONORE</AdrLine>
</PstlAdr>

Totalement structuré. Chaque information a sa balise. C'est la cible, et c'est ce que l'EPC recommande d'atteindre directement, sans passer par l'étape hybride.

<PstlAdr>
  <StrtNm>12 RUE DU FAUBOURG SAINT-HONORE</StrtNm>
  <PstCd>75008</PstCd>
  <TwnNm>PARIS</TwnNm>
  <Ctry>FR</Ctry>
</PstlAdr>

Un point mérite d'être souligné tout de suite, car il surprend souvent : dans l'exemple ci-dessus, le numéro reste collé à la voie. Ce n'est pas une approximation, c'est la règle du guide CFONB. Nous y revenons plus bas.

Les champs et leurs longueurs

Voici les balises que vous rencontrerez dans un PstlAdr, avec leur longueur maximale. Dépasser la longueur, c'est un fichier rejeté à l'entrée, avant même d'atteindre la banque du bénéficiaire.

Le minimum réclamé partout, y compris dans la version hybride, ce sont TwnNm et Ctry. Une adresse sans ville ou sans pays est le cas de rejet le plus fréquent, et le plus simple à détecter avant envoi.

Deux calendriers à ne pas confondre

C'est ici que la plupart des équipes se trompent. Le report annoncé par Swift ne concerne pas les virements SEPA, et inversement. Les deux univers ont leurs règles, leurs instances et leurs dates.

Autrement dit : si vous n'émettez que du SEPA, la date Swift ne vous concerne pas. Si vous payez des fournisseurs via une banque allemande ou luxembourgeoise, le report européen ne vous met pas à l'abri d'un changement de format en novembre. Et si vous faites les deux, vous menez deux chantiers, pas un.

Ce que le report change, et ce qu'il ne change pas

Deux reports en trois semaines ont produit un effet prévisible : des projets mis en attente, des budgets réaffectés, des équipes dispersées sur d'autres priorités. C'est le principal risque de la période.

Ce que le report change vraiment : la pression du calendrier, donc la possibilité de travailler proprement. Nettoyer un référentiel tiers pendant une fenêtre calme, avec des tests, n'a rien à voir avec le même travail mené trois semaines avant une date couperet.

Ce qu'il ne change pas : la direction. L'obligation n'est pas annulée, elle est décalée. Et surtout, il ne change rien à l'état de vos données. Une adresse sans ville reste une adresse sans ville en juin comme en novembre.

Il y a même un effet moins visible : adapter une passerelle de paiement prend des mois, adapter le modèle de données qui tient les comptes prend des années. Le second travail est le seul qui compte à long terme, et c'est celui qu'on repousse le plus facilement quand la date disparaît.

Le bon usage de cette fenêtre tient en une phrase : garder le créneau prévu, non pour la conformité qui peut attendre, mais pour la qualité des données qui, elle, ne s'améliore pas toute seule.

Qui est vraiment concerné, et quand l'adresse est-elle obligatoire

Une nuance qui évite des mois de travail inutile : l'adresse du bénéficiaire n'est pas une donnée obligatoire du virement SEPA. Beaucoup d'entreprises n'en transmettent aucune, et leurs fichiers passent sans problème. La question ne se pose que dans trois cas.

• Vous transmettez déjà une adresse. Dès qu'elle est présente dans le message, elle doit respecter le format en vigueur. Une adresse partielle vaut parfois moins qu'une absence d'adresse.
• Votre banque l'exige pour certains types d'opérations, ou son portail refuse les fichiers qui n'en contiennent pas.
• Vous sortez de l'espace européen : paiements internationaux, opérations one-leg, contrôles de sanctions. Là, l'adresse est la règle, et c'est le terrain du calendrier Swift.

Avant de lancer une reprise complète de votre base tiers, vérifiez donc ce que vous envoyez réellement aujourd'hui. Un export de vos derniers fichiers de paiement répond à la question en quelques minutes.

Transposer une adresse française : les règles du guide CFONB

Le CFONB a publié un guide de transposition de la norme postale française NF Z10-011 vers ISO 20022. C'est le document de référence en France, et il contient plusieurs règles contre-intuitives que les projets découvrent trop tard.

Le numéro ne se sépare pas de la voie

C'est la règle la plus mal connue. Le numéro n'alimente BldgNb que s'il arrive dans un champ dédié de votre fichier source. S'il est fondu dans la ligne d'adresse, le guide demande expressément de ne pas découper : l'ensemble part dans StrtNm et BldgNb reste vide. Les exemples du guide sont sans ambiguïté, « 22BIS RUE DES FLEURS » comme « 25D RUE DES FLEURS » partent entiers.

La raison pratique saute aux yeux dès qu'on tente l'inverse : « Rue du 8 Mai 1945 » et « Avenue du 11 Novembre » se prêtent mal à une détection automatique du numéro. Découper à tout prix, c'est fabriquer des adresses fausses.

Le nom du bâtiment ne s'utilise pas

Le guide proscrit BldgNm dans les deux cas de figure, entreprise et particulier. Une résidence, un bâtiment, une entrée, une zone industrielle vont dans Flr. Le motif est arithmétique : BldgNm est plafonné à 35 caractères alors qu'une ligne NF Z10-011 en compte 38. Flr en accepte 70.

Boîtes postales et CEDEX

« BP 40122 » va dans PstBx. La mention CEDEX, elle, reste accolée à la ville : « 75008 PARIS CEDEX 08 » donne PstCd 75008 et TwnNm PARIS CEDEX 08. C'est une information de distribution, pas une ligne d'adresse à part.

Étage et appartement chez un particulier

La deuxième ligne d'une adresse de particulier (étage, appartement, escalier) alimente Flr et Room. Chez une entreprise, la même position porte le service ou le destinataire, et va dans Dept.

Le jeu de caractères

Le guide CFONB décrit trois niveaux, et c'est une source de rejets discrets :

• le jeu latin de base est toujours accepté ;
• les accents et le caractère @ sont admis sous accord bilatéral entre votre banque et vous : autrement dit, ça passe souvent, mais ce n'est pas garanti ;
• tout le reste est interdit, y compris deux caractères que les traitements de texte insèrent tout seuls : l'apostrophe typographique et le tiret cadratin.

Un « L'Haÿ-les-Roses » copié depuis un document Word peut donc contenir un caractère invisible à l'œil et bloquant pour la banque.

Les pièges qui font perdre du temps

• Le pays déduit du code postal. Quatre chiffres, c'est peut-être la Belgique, le Luxembourg ou la Suisse. Cinq chiffres, la France ou l'Allemagne. Une déduction automatique sans code pays déclaré produit des erreurs silencieuses : le fichier passe, le paiement part au mauvais endroit des contrôles.
• L'adresse cohérente mais fausse. Un audit cité par la presse spécialisée relevait 92 % de villes renseignées, mais seulement 64 % d'adresses cohérentes entre champs. Le format ne dit rien de l'exactitude.
• Les longueurs. Une ville de plus de 35 caractères, un code postal étranger long, et le message est refusé.
• L'hybride pris pour une cible. Il est accepté, mais l'EPC recommande de viser directement le totalement structuré. Faire deux fois le chantier coûte plus cher que de le faire une fois bien.
• Les adresses étrangères traitées comme des adresses françaises. Les règles NF Z10-011 ne s'appliquent qu'aux adresses françaises. Une adresse néerlandaise ou allemande a sa propre logique de code postal.
• Le champ vide plutôt que le champ faux. Si vous n'avez pas l'information, ne la fabriquez pas. Une adresse absente est plus facile à rattraper qu'une adresse inventée.

Comment chiffrer et mener le chantier

Le coût d'une migration d'adresses ne dépend pas des règles, qui tiennent en quelques pages. Il dépend de la proportion de vos adresses que ces règles ne couvrent pas. Ce chiffre, personne ne peut vous le donner : il est dans votre base.

Exportez votre colonne adresse et posez-lui quatre questions.

1. Combien de lignes commencent par un nombre suivi d'un espace ? Ce sont vos cas simples.
2. Combien n'ont pas de numéro de voie ? Elles ne sont pas fautives, elles demandent une règle à part.
3. Combien contiennent « bâtiment », « appartement », « résidence », « étage », « BP », « CS » ou « CEDEX » ? Ce sont vos compléments, et ils ne vont pas tous dans le même champ.
4. Combien n'ont ni ville ni pays exploitables ? Ce sont les seules qui bloqueront vraiment.

Le total des deux dernières catégories, rapporté à votre volume, c'est votre reprise manuelle. C'est ce chiffre qui fait le budget, et il vous appartient avant toute consultation de prestataire.

Ensuite, la marche à suivre tient en trois temps : corriger à la source dans l'ERP plutôt qu'en sortie, tester un fichier réel sur le portail de votre banque avant de généraliser, et mettre un contrôle de saisie pour que la base ne se redégrade pas.

Les six questions à poser à votre banque

Les règles de place fixent un cadre, mais chaque établissement l'applique à sa façon, et les dates diffèrent d'une banque à l'autre. Voici ce qu'il faut faire préciser, par écrit si possible.

1. Quelle date retenez-vous pour la fin des adresses non structurées, en SEPA et à l'international, après les reports de l'été 2026 ?
2. Acceptez-vous le format hybride (ville et pays structurés, reste en ligne libre), et jusqu'à quand ?
3. Quelles versions de messages acceptez-vous et jusqu'à quand : pain.001.001.03 ou .09, pain.008.001.02 ou .08, MT101 ?
4. Que faites-vous d'une adresse incomplète : rejet du fichier entier, rejet de l'opération, ou acceptation avec avertissement ?
5. Disposez-vous d'un environnement de test où je peux déposer un fichier réel sans le signer ?
6. Vos filiales étrangères appliquent-elles les mêmes règles ? C'est souvent là que se cachent les surprises, notamment en Allemagne et au Luxembourg.

La quatrième question est la plus utile : elle détermine si une adresse imparfaite coûte un paiement ou un fichier entier.

Questions fréquentes

Ce guide suit l'actualité des échéances : les dates sont vérifiées à chaque mise à jour. Si une nouvelle date est annoncée par Swift ou par l'EPC, cette page est corrigée.