Intégrer une plateforme agréée : par où commencer quand on est développeur ?

Table des matières

Le moment où la réforme devient VOTRE ticket Jira

Les deux premiers épisodes ont posé le paysage de la réforme et les formats. Maintenant, la vraie question, celle qui finit dans votre backlog : concrètement, par où on commence pour raccorder son logiciel à une plateforme agréée ?

J’écris cet épisode avec ma casquette de praticien — je passe mes journées côté plateforme, à voir arriver des intégrateurs bien et mal préparés. Voici la checklist que j’aurais aimé pouvoir envoyer à chacun d’eux.

Étape 0 : cartographiez vos flux avant de parler technique

Avant tout choix d’outil, prenez une heure avec un tableau blanc et répondez à ces questions :

• Qu’est-ce que j’émets ? Des factures B2B domestiques (circuit e-invoicing), du B2C ou de l’international (e-reporting), les deux ?
• Qu’est-ce que je reçois ? Des factures fournisseurs ? En quel volume ?
• Qui sont mes utilisateurs ? Une seule entreprise (vous intégrez pour vous) ou des centaines (vous êtes éditeur SaaS et chaque client est un assujetti distinct) ? Cette distinction change tout le design — droits, mandats, rattachement des flux à chaque client.
• D’où viennent mes données de facture ? Sont-elles assez riches pour remplir une facture EN 16931 complète (adresses structurées, numéros de TVA, mentions obligatoires…) ? C’est LE chantier caché : la mise à niveau de la donnée amont prend souvent plus de temps que l’intégration elle-même.

Ce dernier point mérite d’être répété : les mentions obligatoires des factures sont fixées réglementairement (l’article 242 nonies A de l’annexe II au CGI, pour le citer comme le fait le guide officiel). Si votre base clients a des adresses en texte libre et des SIREN facultatifs, commencez par là.

Étape 1 : choisir sa (ou ses) plateforme(s)

La liste officielle des plateformes agréées est publiée sur impots.gouv.fr — c’est le point de départ, et le seul filtre « réglementaire ». Ensuite, les critères qui comptent pour un développeur :

• La qualité de l’API et de sa doc. Les API sont couvertes par une norme (XP Z12-013) et les spécifications externes publient des swaggers — mais chaque plateforme a sa surface, ses environnements, son onboarding développeur. Demandez l’accès à la doc AVANT de signer.
• Les modes d’intégration disponibles. API REST, mais aussi — ne riez pas — dépôt de fichiers SFTP : si votre système est un ERP vénérable, c’est peut-être votre meilleure option de démarrage. (J’ai raconté ici comment ce canal peut être architecturé proprement côté plateforme.)
• Un environnement de test digne de ce nom. Vous voulez un bac à sable où déposer des factures, provoquer des rejets, observer les statuts — sans toucher à la production fiscale. Sa qualité est un excellent révélateur de la maturité de la plateforme.
• Si vous êtes éditeur : le modèle multi-clients. Comment la plateforme gère-t-elle N assujettis derrière un seul intégrateur ? Mandats, consentements, cloisonnement des données — posez ces questions tôt, les réponses structurent votre architecture.

Un mot de vocabulaire pour éviter un piège commercial : une « solution compatible » n’est pas une plateforme agréée. Seule une plateforme immatriculée par l’administration peut transmettre les factures aux autres plateformes et les données à l’administration. Beaucoup d’offres du marché sont des surcouches au-dessus d’une plateforme agréée tierce — ce n’est pas un mal en soi, mais sachez sur quoi vous êtes réellement branché.

Étape 2 : comprendre le voyage d’une facture (et coder pour ses détours)

Le nominal est simple : vous poussez une facture, elle part chez le destinataire, tout le monde est content. Mais votre code doit surtout être écrit pour les détours :

L’adressage d’abord. Avant d’émettre, il faut savoir où livrer : c’est le rôle de l’annuaire central (pensez DNS des entreprises — je l’ai décrit dans l’épisode 1). Votre facture doit porter un destinataire correctement identifié ; le guide officiel de démarrage consacre d’ailleurs une question entière à « que faire si l’annuaire ne permet pas d’identifier la plateforme de réception de mon client ». Prévoyez ce cas dans votre UX : c’est un état, pas une exception.

Les rejets ensuite. Votre facture peut être rejetée par votre propre plateforme (contrôles de forme), ou par celle du destinataire. Puis, distinct du rejet technique : le refus métier par l’acheteur lui-même (« cette facture n’est pas conforme à la commande »). Trois échecs différents, trois traitements différents dans votre logiciel — et l’obligation de pouvoir corriger et réémettre sans créer de doublon. Le guide officiel insiste sur la prévention des « doubles paiements, doubles comptabilisations ou doubles déclarations » en cas de réémission : côté code, cela s’appelle de l’idempotence et une gestion rigoureuse des références entre facture d’origine et facture corrigée.

Les statuts enfin. Une fois la facture livrée, sa vie ne fait que commencer : des statuts de cycle de vie remontent vers vous (mise à disposition, refus, encaissement…). Votre intégration doit les consommer et les refléter dans votre produit — c’est l’objet complet de l’épisode 4.

Étape 3 : construire l’intégration dans le bon ordre

Ma recommandation de séquencement, éprouvée :

1. La réception avant l’émission si vous êtes concerné par les deux : c’est l’obligation la plus large (tout le monde au 1er septembre 2026), et consommer des factures vous apprendra énormément sur les formats avant d’en produire.
2. Le bac à sable avant tout engagement : première facture de test émise et reçue dès la première semaine — c’est votre « hello world », il dérisque tout le reste.
3. Le mapping EN 16931 comme pivot (épisode 2) : votre modèle interne → BT/BG → sérialisation. Les écarts de données apparaîtront ici : traitez-les comme un chantier de données, pas comme des bugs d’intégration.
4. Les chemins d’échec avant la mise en production : rejet, refus, annuaire muet, plateforme indisponible (le guide officiel prévoit explicitement le cas et la conduite à tenir). Chaque état a besoin d’une représentation dans votre produit et d’un chemin de sortie pour l’utilisateur.
5. La traçabilité partout : conservez qui a émis quoi, quand, avec quel résultat. Pendant la phase de démarrage, l’administration attend des entreprises qu’elles puissent démontrer leur trajectoire de conformité — vos logs et registres sont ce dossier. Et en régime de croisière, c’est votre outil de support.

Les questions à poser à votre plateforme (la liste à copier-coller)

Pour votre prochain rendez-vous d’avant-vente, en vrac et sans pitié :

• Quels formats acceptez-vous en entrée, et lesquels convertissez-vous ?
• À quoi ressemble votre bac à sable ? Puis-je y provoquer un rejet ? Un refus acheteur ?
• Comment sont exposés les statuts de cycle de vie — webhook, polling, les deux ? Avec quelles garanties de livraison ?
• Quelles sont vos limites de débit et vos plafonds (par heure, par lot) ? Que se passe-t-il quand je les atteins ? (Vous savez pourquoi je pose toujours celle-là.)
• Comment gérez-vous N assujettis derrière un seul compte intégrateur ? Comment le cloisonnement est-il garanti ?
• Quel est votre processus de gestion des évolutions de spécifications (la v3.2 ne sera pas la dernière) ?

Les réponses — et la vitesse à laquelle elles arrivent — vous en diront plus que n’importe quelle plaquette.

Épilogue

L’intégration d’une plateforme agréée n’est pas un « connecteur de plus » : c’est un flux métier réglementé, avec un annuaire, des états, des échecs typés et des obligations de traçabilité. La bonne nouvelle, c’est que tout cela se conçoit avec les outils d’architecture qu’on connaît déjà — frontières nettes, états explicites, idempotence, refus plutôt que devinette. La suite de la série creuse les statuts (épisode 4) puis le e-reporting (épisode 5).

Et si vous cherchez quelqu’un qui a déjà fait ce chemin — côté plateforme, jusqu’au dossier d’immatriculation — c’est précisément ce que je propose : gaetancottrez.dev/facturation-electronique 🔗.

Vos questions d’intégration sont bienvenues en commentaire — je me ferai une joie d’y répondre.

Sources (consultées en août 2026) : Facturation électronique et plateformes agréées 🔗 (impots.gouv.fr) · Guide pratique de démarrage 🔗 (PDF, DGFiP — questions 10 à 16 notamment) · Spécifications externes et normes 🔗 (impots.gouv.fr).