Salesforce et la facturation électronique 2026 : comment se mettre en conformité
par Paul Mantez, Co-fondateur & Développeur
Si vos factures naissent dans Salesforce — sur un objet custom, via Sales Cloud, Revenue Cloud ou un module maison —, la réforme de la facturation électronique vous concerne directement. Et l'échéance est plus proche qu'elle n'en a l'air.
On a construit et mis en production une passerelle qui relie Salesforce à une Plateforme Agréée, pour un groupe d'événementiel parisien : plusieurs salles, deux entités légales distinctes, un seul système d'émission. Tout ce qui suit, on l'a appris en le faisant.
L'objectif de cet article : vous donner les dates qui comptent, ce que Salesforce fait (et ne fait pas) pour vous, vos trois options concrètes, et l'architecture qu'on recommande pour ne pas se retrouver coincé dans deux ans.
Ce que la réforme exige (et quand)
Deux échéances structurent le calendrier français.
Le 1er septembre 2026, toutes les entreprises assujetties à la TVA établies en France — franchise en base comprise — devront être capables de recevoir une facture électronique. À la même date, l'émission devient obligatoire pour les grandes entreprises et les ETI. Le 1er septembre 2027, l'obligation d'émission s'étend aux PME et aux TPE.
Concrètement, plus personne n'émet ni ne reçoit de PDF par e-mail entre professionnels : les factures transitent par des plateformes spécialisées. Depuis juillet 2025, ces plateformes — auparavant appelées PDP — portent le nom officiel de Plateformes Agréées (PA). La DGFiP en a immatriculé plus de 200. Une PA est un opérateur privé habilité à émettre, recevoir et transmettre les factures électroniques, et à faire remonter les données à l'administration. C'est par l'une d'elles que vous passerez, que vous le vouliez ou non.
Au centre du dispositif, le PPF (Portail Public de Facturation) tient l'annuaire : pour chaque SIREN/SIRET, il indique quelle plateforme agréée dessert l'entreprise destinataire — et ce sont les PA qui le consultent pour acheminer chaque facture. Les factures, elles, circulent de PA à PA. Côté format, le socle retient trois standards : Factur-X (un PDF lisible qui embarque un XML), UBL et CII — les plateformes agréées savent convertir de l'un à l'autre. Pour le détail des profils de stack et des options selon l'outil d'où sortent vos factures, on a écrit un guide complet de la facturation électronique pour les CRM et outils métier.
Ce que Salesforce ne fait pas pour vous
Salesforce est un excellent CRM. C'est aussi un produit américain, pensé pour un marché mondial, pas pour les obligations fiscales françaises.
Résultat : il n'y a pas de génération Factur-X ou UBL native côté France, et pas de connexion out-of-the-box à une plateforme agréée. Salesforce ne sait pas, par défaut, fabriquer une facture conforme au socle réglementaire ni la déposer sur le réseau.
Or si vous facturez depuis Salesforce — peu importe le montage : objets custom, Sales Cloud doublé d'un module de facturation maison, Revenue Cloud… — c'est bien dans votre org que vivent les données de facturation. La conformité est donc à votre charge. Personne ne la livrera à votre place parce que vous payez une licence Salesforce. C'est à vous de construire (ou de faire construire) le pont entre votre CRM et le réseau des plateformes agréées.
Et ce pont fait plus que générer un fichier. Il authentifie le dialogue avec la plateforme, produit un format conforme au socle, gère les rejets. Surtout, il suit l'évolution du statut de chaque facture côté réseau et renvoie cette information là où vos équipes la consultent. C'est un vrai composant logiciel, pas une option à cocher dans un menu de paramétrage.
Vos 3 options
Il y a trois façons réalistes de relier Salesforce à une plateforme agréée. Aucune n'est mauvaise dans l'absolu ; elles répondent à des situations différentes.
Option A — une app de l'AppExchange. C'est l'approche la plus rapide à mettre en route. Le revers : vous dépendez de l'éditeur de l'app, de sa feuille de route et de sa couverture du marché français, qui reste inégale d'un éditeur à l'autre. Point de vigilance non négociable : vérifiez que la plateforme agréée sur laquelle l'app s'appuie est bien immatriculée par la DGFiP. Une belle intégration adossée à une plateforme non agréée ne vous met pas en conformité.
Option B — le connecteur fourni par votre plateforme agréée. Beaucoup de PA proposent leur propre brique pour Salesforce. C'est un bon choix si vos objets de facturation sont standards et que votre modèle de données ne s'écarte pas du chemin balisé. Dès que le modèle devient custom — champs spécifiques, logique métier particulière, plusieurs entités —, ces connecteurs montrent vite leurs limites.
Option C — une passerelle sur-mesure. C'est souvent la seule option quand le modèle de données est spécifique ou que plusieurs entités légales doivent passer par le même tuyau. On maîtrise alors exactement ce qui est lu, transformé et envoyé, et on s'adapte à la réalité de l'org plutôt que l'inverse. C'est ce qu'on a construit pour le groupe événementiel évoqué plus haut : deux entités, deux SIREN, une seule passerelle, branchée sur un modèle de données qui n'avait rien de standard. Aucun connecteur générique ne couvrait ce cas ; une app de l'AppExchange aurait imposé de tordre les processus pour entrer dans son moule. Le sur-mesure a coûté plus de temps en amont, mais il a évité une dette qu'on aurait traînée des années.
L'architecture qu'on recommande : pull, zéro Apex trigger
Voici le parti pris qui a le plus compté dans notre projet, et qu'on défend pour toute passerelle de ce type : ne déployer aucun code dans l'org Salesforce. Pas d'Apex trigger, pas d'Outbound Message. Salesforce reste une simple source de données.
Concrètement, la passerelle va chercher les factures à émettre dans Salesforce via l'API REST, authentifiée en OAuth 2.0 (client credentials). Elle génère ensuite un fichier conforme — dans notre cas de l'UBL 2.1, accompagné du PDF obligatoire —, puis le dépose sur la plateforme agréée (on a travaillé avec Sage Network). Elle suit enfin le cycle de vie de chaque facture côté réseau : déposée, rejetée, encaissée, et ainsi de suite.
Tout vit donc en dehors de Salesforce. L'org expose ses données via une API standard ; la passerelle s'y connecte comme n'importe quel client externe, sans privilège particulier ni code embarqué. C'est l'inverse de l'approche réflexe — un trigger sur l'objet facture qui pousse vers la plateforme au moment de la validation. Cette approche-là marche le jour de la mise en prod, et devient un piège ensuite.
Ce modèle « pull » a un coût en discipline, mais il paie sur la durée. L'org reste propre : pas de logique de facturation enfouie dans des triggers que personne n'osera toucher dans trois ans. Le système devient remplaçable — changer de plateforme agréée, ou même de CRM, revient à changer un adaptateur, pas à réécrire le cœur du dispositif. Et les montées de version Salesforce ne cassent rien, puisqu'aucun code custom ne dépend des internals de l'org.
Dernier point, et c'est celui que les équipes ressentent au quotidien : on réécrit les statuts dans Salesforce (writeback), dans des champs dédiés. La comptabilité et les commerciaux voient l'état réel de chaque facture directement dans le CRM, sans aller fouiller ailleurs.
On connecte votre Salesforce à une Plateforme Agréée →
Les délais réels
Parlons franchement du temps que ça prend, parce que c'est là que beaucoup vont se faire surprendre.
Sur notre projet, un flux d'émission complet — lecture dans Salesforce, génération du format conforme, dépôt sur la plateforme, suivi des statuts et writeback — a demandé 6 à 10 semaines. On a d'abord tout validé sur l'environnement sandbox de la plateforme agréée avant de basculer en production. C'est sur ce banc d'essai qu'on attrape les cas tordus : un mode de paiement particulier, une mention obligatoire manquante, un rejet de la plateforme qu'il faut savoir interpréter et rejouer. La réception s'ajoute ensuite sur la même infrastructure, sans repartir de zéro — l'authentification, le mapping et le suivi des statuts sont déjà en place.
Faites le calcul. Démarrer maintenant, c'est être prêt confortablement avant l'échéance de septembre 2026, avec le temps de tester. Démarrer en août, c'est non : entre les délais de mise en service côté plateforme, les allers-retours de validation et les inévitables cas particuliers, vous ne tiendrez pas. Ce n'est pas du discours commercial : c'est juste de l'arithmétique de planning.
Et si vous comptez sur un report, comme en 2024 : le pilote national tourne depuis février 2026 — de vraies factures s'échangent en conditions réelles — et la DGFiP a confirmé en mai, au plus haut niveau, qu'il n'y en aurait pas.
Questions fréquentes
Quelle Plateforme Agréée choisir avec Salesforce ?
Le critère qui prime quand on intègre depuis un CRM, c'est la qualité de l'API de la plateforme : clarté de la documentation, robustesse de l'authentification, finesse du suivi des statuts, qualité de l'environnement de test. Une PA peut être parfaitement agréée et offrir une API pénible à intégrer. De notre côté, on a travaillé avec Sage Network et l'intégration s'est bien passée. Vérifiez aussi, évidemment, que la plateforme est bien immatriculée par la DGFiP.
Faut-il changer de CRM ?
Non. Rien dans la réforme n'impose de quitter Salesforce. Tout l'intérêt d'une architecture « pull » est justement de garder votre CRM tel quel : il reste la source de données, et c'est la passerelle qui porte la conformité. Changer de CRM pour cette seule raison serait un très mauvais calcul.
Et l'e-reporting ?
En plus de la facturation électronique entre professionnels, la réforme prévoit l'e-reporting : la transmission à l'administration des données de transactions qui n'entrent pas dans le circuit B2B franco-français (ventes aux particuliers, opérations internationales), ainsi que des encaissements sur les prestations de services, dont la TVA est exigible au paiement. Ces données remontent elles aussi via votre plateforme agréée. La même infrastructure qui gère votre émission peut donc couvrir ce volet.