Norme EPC & SEPA-QR – Structure technique expliquée

La structure technique du payload EPC

Le contenu d'un GiroCode (appelé « payload » en anglais) est un texte brut de plusieurs lignes, chaque ligne ayant une signification précise. Voici un exemple complet d'un payload EPC valide :

BCD
002
1
SCT
SOGEFRPPXXX
Jean Dupont SARL
FR7612345678901234567890185
EUR1250.00

Facture 2025-042
Règlement facture 2025-042 – Conseil informatique

Voici la signification de chaque ligne :

Ligne 1 : Service Tag – BCD

La première ligne contient toujours la valeur BCD (Business Card Data). C'est un identifiant fixe qui indique aux applications bancaires qu'il s'agit bien d'un QR code de paiement au format EPC. Si cette valeur est absente ou incorrecte, l'application refusera de traiter le code.

Ligne 2 : Version – 001 ou 002

La deuxième ligne indique la version de la norme EPC utilisée. Deux versions existent :

• Version 001 : La version originale, qui exigeait le BIC de la banque bénéficiaire.
• Version 002 : La version actuelle (depuis 2016), où le BIC est devenu optionnel pour les virements intra-SEPA.

La version 002 est aujourd'hui recommandée pour tous les nouveaux GiroCodes.

Ligne 3 : Encodage des caractères – 1

Cette ligne spécifie le jeu de caractères utilisé. La valeur 1 correspond à UTF-8, ce qui permet l'utilisation de caractères accentués et spéciaux comme é, è, ê, ü, ö, ä, etc. C'est le seul encodage recommandé dans la norme actuelle.

Ligne 4 : Identification de la fonction – SCT

La valeur SCT signifie SEPA Credit Transfer (virement SEPA). C'est le type de paiement défini dans le GiroCode. Actuellement, SCT est la seule valeur autorisée dans les GiroCodes standard.

Ligne 5 : BIC de la banque bénéficiaire (optionnel depuis 2016)

Le BIC (Business Identifier Code) identifie la banque du bénéficiaire. Depuis la migration SEPA complète en 2016, le BIC n'est plus obligatoire pour les virements intra-SEPA – les banques peuvent identifier l'établissement à partir de l'IBAN seul. Cette ligne peut donc être laissée vide (ligne vide), mais si vous connaissez votre BIC, il est toujours recommandé de l'inclure pour une compatibilité maximale avec les systèmes plus anciens. La longueur maximale est de 11 caractères (format 8 ou 11 lettres).

Ligne 6 : Nom du bénéficiaire (max. 70 caractères)

Le nom du bénéficiaire est obligatoire et peut contenir jusqu'à 70 caractères. C'est le nom qui s'affichera dans l'application bancaire du payeur pour identifier le destinataire du virement. Il doit correspondre au titulaire du compte bancaire indiqué par l'IBAN. Utilisez votre nom complet ou la raison sociale de votre entreprise exactement comme elle apparaît sur votre relevé bancaire.

Ligne 7 : IBAN du bénéficiaire

L'IBAN est obligatoire. Il doit être saisi sans espaces et dans le format standard international (code pays + chiffres de contrôle + BBAN). Exemples :

• IBAN français : FR7612345678901234567890185
• IBAN allemand : DE89370400440532013000
• IBAN autrichien : AT611904300235473201

Notre générateur valide automatiquement l'IBAN saisi via l'algorithme Mod-97 avant de générer le QR code.

Ligne 8 : Montant (format EUR12.34)

Le montant est optionnel. S'il est inclus, il doit suivre le format précis EUR suivi du montant avec un point comme séparateur décimal. Exemples : EUR12.34, EUR1250.00, EUR0.50. Le montant maximum autorisé est de 999 999 999,99 €. Si cette ligne est vide (pas de montant), le payeur devra saisir le montant manuellement.

Ligne 9 : Type d'objet (généralement vide)

Cette ligne est réservée pour identifier le type d'objet de paiement. Dans la pratique courante, elle est laissée vide. Les valeurs théoriquement possibles (pour une utilisation future standardisée) ne sont pas encore largement implémentées.

Ligne 10 : Référence structurée (optionnel)

Cette ligne peut contenir une référence structurée du type ISO 11649 (référence créancier). Elle est principalement utilisée dans les pays qui l'ont standardisée (Belgique, Pays-Bas). Pour un usage général, elle est laissée vide et la référence libre (ligne 11) est utilisée à la place.

Ligne 11 : Référence de paiement / libellé (max. 140 caractères)

C'est la référence libre du virement – ce qui apparaîtra dans le libellé de votre relevé bancaire. Maximum 140 caractères en UTF-8. Incluez toujours le numéro de facture ici pour faciliter la réconciliation comptable. Exemple :Facture 2025-042 – Développement site web.

Versions EPC comparées : 001 vs. 002

La principale différence entre les versions 001 et 002 de la norme EPC concerne le BIC :

Pour tous les nouveaux GiroCodes, utilisez la version 002. La version 001 est encore reconnue par la plupart des applications, mais son utilisation n'est plus recommandée.

Correction d'erreurs et qualité du QR code

Niveau de correction d'erreurs M (15 %)

La norme EPC spécifie que les GiroCodes doivent utiliser le niveau de correction d'erreurs M (Medium), qui permet de récupérer jusqu'à 15 % de données endommagées. Les codes QR standard peuvent utiliser quatre niveaux de correction d'erreurs :

• L (Low) : 7 % – taille de code plus petite
• M (Medium) : 15 % – niveau requis pour les GiroCodes
• Q (Quartile) : 25 %
• H (High) : 30 % – taille de code la plus grande

Pourquoi le niveau M et pas H ?

Le niveau M représente un compromis optimal pour les GiroCodes :

• Plus de données dans le même espace : Un niveau de correction plus élevé (Q ou H) signifie que plus d'espace est consacré à la redondance, ce qui se traduit par un code QR plus dense (plus de modules/points) pour la même quantité de données, ou par la nécessité d'une plus grande taille d'impression.
• Données critiques limitées : Les GiroCodes contiennent des données relativement courtes (IBAN, montant, référence) et n'ont pas besoin du niveau de protection maximal.
• Lisibilité suffisante : 15 % de correction permet de lire le code même s'il est légèrement endommagé, froissé ou partiellement obstrué.

Taille minimale recommandée

La norme EPC recommande une taille minimale de 2 × 2 centimètrespour les GiroCodes imprimés. En pratique, une taille de 3 × 3 cm est préférable pour une lisibilité optimale avec tous les types de smartphones. Pour les impressions haute résolution (300 DPI et plus), la taille peut être réduite sans perte de lisibilité. Pour les affichages numériques, une taille de 200 × 200 pixels minimum est recommandée.

Contraste et couleur

La norme EPC exige un contraste suffisant entre les modules sombres et le fond clair. L'idéal est noir (#000000) sur blanc (#FFFFFF). Des variations de couleur sont possibles (par exemple bleu foncé sur blanc), mais le rapport de contraste doit rester supérieur à 3:1 pour une lecture fiable. Évitez d'imprimer un GiroCode sur un fond coloré ou texturé.

Implémentation technique : générer un payload EPC

Voici un exemple de fonction JavaScript qui génère un payload EPC valide à partir des données de paiement :

/**
 * Génère un payload EPC (GiroCode) conforme à la norme v002
 * @param {Object} params - Les paramètres du virement
 * @returns {string} Le payload EPC sous forme de chaîne de caractères
 */
function generateEpcPayload({
  bic = '',          // BIC de la banque (optionnel en v002)
  name,              // Nom du bénéficiaire (obligatoire, max 70 chars)
  iban,              // IBAN du bénéficiaire (obligatoire)
  amount = '',       // Montant (optionnel, format EUR12.34)
  reference = '',    // Référence de paiement (max 140 chars)
}) {
  // Validation de base
  if (!name || name.length > 70) {
    throw new Error('Nom invalide (obligatoire, max 70 chars)');
  }
  if (!iban || !/^[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}$/.test(iban)) {
    throw new Error('IBAN invalide');
  }
  if (amount && !/^EUR[0-9]+\.[0-9]{2}$/.test(amount)) {
    throw new Error('Montant invalide (format: EUR12.34)');
  }

  // Construction du payload ligne par ligne
  const lines = [
    'BCD',          // Ligne 1: Service Tag
    '002',          // Ligne 2: Version EPC
    '1',            // Ligne 3: Encodage UTF-8
    'SCT',          // Ligne 4: SEPA Credit Transfer
    bic,            // Ligne 5: BIC (optionnel)
    name,           // Ligne 6: Nom du bénéficiaire
    iban,           // Ligne 7: IBAN
    amount,         // Ligne 8: Montant
    '',             // Ligne 9: Type d'objet (vide)
    '',             // Ligne 10: Référence structurée (vide)
    reference,      // Ligne 11: Référence de paiement
  ];

  return lines.join('\n');
}

// Exemple d'utilisation :
const payload = generateEpcPayload({
  bic: 'SOGEFRPPXXX',
  name: 'Jean Dupont SARL',
  iban: 'FR7612345678901234567890185',
  amount: 'EUR1250.00',
  reference: 'Facture 2025-042',
});

console.log(payload);
// → BCD\n002\n1\nSCT\nSOGEFRPPXXX\nJean Dupont SARL\n...

Une fois le payload généré, vous pouvez le passer à une bibliothèque de génération de QR code (comme qrcode pour Node.js) avec le niveau de correction d'erreurs M pour obtenir le code QR final.

Erreurs courantes avec la norme EPC

Voici les erreurs les plus fréquentes lors de la création de GiroCodes conformes à la norme EPC :

1. IBAN avec espaces

L'IBAN dans le payload EPC doit être saisi sans espaces. Un IBAN comme FR76 1234 5678 9012 3456 7890 185 est invalide dans le payload – il doit être écrit FR7612345678901234567890185.

2. Format de montant incorrect

Le format du montant doit être exactement EUR suivi du montant avec un point décimal, sans espaces. EUR 1250,00 ou 1250.00 EUR sont incorrects. Le format valide est EUR1250.00.

3. Nom du bénéficiaire trop long

Le nom est limité à 70 caractères. Les noms d'entreprises longs peuvent dépasser cette limite – utilisez une version abrégée si nécessaire.

4. Référence de paiement trop longue

La référence de paiement est limitée à 140 caractères. Les descriptions très longues doivent être raccourcies. Concentrez-vous sur l'essentiel : numéro de facture et date.

5. Mauvais niveau de correction d'erreurs

Si vous générez un QR code avec le niveau de correction L (7 %) au lieu de M (15 %), le code sera techniquement lisible mais ne sera pas conforme à la norme EPC. Certaines applications bancaires vérifient ce paramètre et peuvent refuser de traiter le code.

6. Caractères non supportés

Bien que UTF-8 soit supporté, certains caractères spéciaux peuvent poser des problèmes avec certaines applications bancaires. Il est recommandé de s'en tenir aux caractères latins standard et aux accents courants (é, è, ê, à, ü, ö, etc.).

7. Mauvaise version

Utiliser la version 001 sans inclure de BIC entraîne un payload invalide. Si vous utilisez la version 001, le BIC est obligatoire. Préférez la version 002 qui rend le BIC optionnel.

Utiliser GiroCode professionnellement – Recommandations logicielles

Quiconque souhaite utiliser des GiroCodes de manière professionnelle sur ses factures aura tôt ou tard besoin d'un bon logiciel de comptabilité ou de facturation. Créer des GiroCodes manuellement convient pour un usage occasionnel – mais pour une facturation régulière, une solution automatisée est rapidement rentable.

Nous recommandons deux outils éprouvés qui prennent en charge nativement les GiroCodes :

* Lien affilié – Si vous achetez via ce lien, nous percevons une petite commission sans frais supplémentaires pour vous.

Pour un usage occasionnel, nous recommandons notre générateur de GiroCode gratuit – entièrement local, sans inscription.