Pourquoi l'événementiel s'impose en 2026

La réforme de la facturation électronique transforme la facture en objet vivant. À partir du 1ᵉʳ septembre 2026, chaque facture émise entre assujettis TVA français transite par une Plateforme Agréée et porte, tout au long de son parcours, un code statut normalisé par la DGFiP. Quatre statuts sont obligatoires : 200 Déposée, 213 Rejetée (rejet technique), 210 Refusée (refus commercial du destinataire) et 212 Encaissée — ce dernier déclenchant le pré-remplissage de la déclaration de TVA. Six statuts supplémentaires sont recommandés pour fluidifier la relation fournisseur-client.

Pour un CTO d'ESN, un éditeur SaaS ou une DSI, la question n'est donc plus « comment émettre une facture conforme », mais « comment mon système d'information apprend-il qu'une facture a changé d'état ? ». Une facture refusée qui dort trois jours dans un tableau de bord, c'est un avoir en retard, une relance décalée, un cash-flow dégradé. La réponse architecturale standard de l'industrie — celle des PSP de paiement et des plateformes fintech — est le webhook : un appel HTTP sortant que la plateforme émet vers votre serveur à l'instant où l'événement se produit.

Webhook vs polling : deux architectures d'intégration

Le réflexe historique consiste à interroger l'API de la plateforme en boucle : toutes les cinq minutes, un batch demande « quelles factures ont changé ? ». Ce polling fonctionne, mais il cumule les défauts dès que le volume monte.

Critère Polling (pull) Webhook (push)
Latence Minutes (intervalle de scrutation) Secondes (dès l'événement)
Charge API Requêtes permanentes, souvent à vide Un appel par événement réel
Complexité côté ERP Curseur, pagination, diff d'états Un endpoint HTTP à exposer
Risque de manque Fenêtre ratée, quota atteint Retries automatiques côté PA
Passage à l'échelle Coût linéaire avec le volume Coût proportionnel à l'activité

Le polling reste utile en filet de sécurité (réconciliation quotidienne, reprise après incident), mais il est fragile et lent comme mécanisme principal : chaque minute d'intervalle est une minute de retard sur un statut 213 qui exige une correction, et chaque requête à vide consomme du quota pour rien. Le webhook pousse l'événement dès qu'il survient — l'ERP réagit au lieu de scruter.

Les événements à écouter : la grammaire des statuts DGFiP

Le détail des dix statuts est couvert dans notre guide du cycle de vie d'une facture électronique. Côté intégration, quatre événements structurent la majorité des automatisations :

  • Facture entrante reçue : une facture fournisseur arrive sur votre PA. Le webhook permet de la pousser immédiatement dans le circuit de validation de l'ERP ou de l'outil comptable, sans saisie ni scrutation.
  • 212 Encaissée : le paiement est perçu. C'est le déclencheur naturel de la comptabilisation (lettrage, écriture d'encaissement) et, côté DGFiP, du pré-remplissage TVA. Un webhook sur le 212 synchronise la comptabilité avec la réalité fiscale.
  • 210 Refusée : refus commercial du destinataire, motivé. L'événement doit alerter le commercial ou l'ADV en charge du compte : plus le motif est traité vite, plus l'avoir et la facture corrigée partent tôt.
  • 213 Rejetée : rejet technique (format non conforme à l'EN 16931, mention manquante, SIREN inconnu). L'événement déclenche une relance du circuit d'émission : correction du document — qu'il soit en Factur-X, UBL ou CII (voir notre comparatif des formats) — puis redépôt.

Dans tous les cas, le webhook transporte l'identifiant de la facture et le nouveau statut ; l'ERP décide du traitement métier.

Anatomie d'un webhook bien conçu

Recevoir des webhooks de sa Plateforme Agréée, c'est exposer une petite surface d'API… et en accepter les responsabilités. Cinq pratiques font la différence entre une intégration robuste et une source d'incidents.

Un endpoint HTTPS dédié

Exposez une route dédiée aux événements e-invoicing (par exemple POST /webhooks/einvoicing), servie exclusivement en HTTPS. Ne mutualisez pas cette route avec d'autres intégrations : le jour où vous devez couper, tracer ou faire évoluer le flux, vous serez heureux qu'il soit isolé.

Répondre 2xx vite, traiter en asynchrone

L'émetteur du webhook attend une réponse HTTP rapide. Accusez réception en 2xx immédiatement, puis traitez l'événement en tâche de fond (file de messages, job queue). Si votre endpoint met trente secondes à comptabiliser une écriture avant de répondre, il finira en timeout — et l'événement sera considéré comme non livré.

Idempotence par identifiant d'événement

Un même événement peut être livré plusieurs fois (retry après timeout, replay manuel). Chaque livraison porte un identifiant d'événement unique : stockez-le et ignorez les doublons. Sans idempotence, un retry innocent devient une double écriture comptable.

Gérer les retries

Si votre serveur est indisponible ou répond en erreur, la plateforme retente la livraison selon une politique d'espacement. Votre traitement doit donc tolérer des événements arrivant en retard ou dans le désordre : c'est le statut porté par l'événement qui fait foi, pas l'ordre d'arrivée.

Vérifier la signature

Un endpoint webhook est une porte ouverte sur votre SI : n'importe qui connaissant l'URL peut y poster du JSON. La parade standard est la signature : la plateforme signe chaque payload avec un secret partagé, et votre serveur recalcule la signature avant tout traitement. Payload non signé ou signature invalide → rejet silencieux, sans détail dans la réponse.

Squelette type d'un événement de changement de statut (illustration simplifiée) :

{
  "event_id": "evt_01J9ZK7Q3E8Y",
  "type": "invoice.status_changed",
  "created_at": "2026-09-14T09:31:22Z",
  "data": {
    "invoice_id": "inv_8842",
    "status_code": "212",
    "status_label": "Encaissée"
  }
}

Les webhooks WeInvoice en pratique

L'API publique WeInvoice — documentée sur api.weinvoice.fr/documentation/, avec une spec machine-readable sur api.weinvoice.fr/openapi-public.json — implémente ce modèle de bout en bout :

  • Abonnements : vous créez un abonnement webhook sur les événements e-invoicing qui vous intéressent.
  • Secret de signature : délivré une seule fois à la création de l'abonnement — stockez-le dans votre gestionnaire de secrets, il ne sera pas ré-affiché.
  • Rotation du secret : le secret se régénère à la demande, et l'ancien reste valide 24 h pour permettre une bascule sans coupure.
  • Ping de test : un test synchrone signé permet de vérifier en une requête que votre endpoint répond et valide correctement la signature.
  • Historique des livraisons : chaque livraison est consultable — payload envoyé et réponse de votre serveur — pour diagnostiquer un échec sans deviner.
  • Replay : une livraison passée se rejoue avec un nouvel event id, ce qui respecte votre logique d'idempotence tout en resoumettant l'événement.

L'authentification de l'API repose sur OAuth2 client_credentials : un couple client_id / client_secret s'échange contre un jeton d'accès de courte durée.

curl -X POST https://api.weinvoice.fr/oauth/token \
  -d grant_type=client_credentials \
  -d client_id=$CLIENT_ID \
  -d client_secret=$CLIENT_SECRET

Une sandbox permet de dérouler tout le cycle (émission, statuts, webhooks) sans facture réelle, et des SDK Node.js, Python, PHP, .NET et Java couvrent les principaux stacks. Les guides « integration-guide » et « sandbox-guide » du centre d'aide (app.weinvoice.fr/fr/aide) déroulent le parcours pas à pas ; la page Technologie — API donne la vue d'ensemble.

Pour les ESN et les éditeurs : intégrer une PA en marque grise

Si vous êtes une ESN ou un éditeur SaaS, vos clients attendront de votre produit qu'il gère nativement la facturation électronique — sans forcément voir la plateforme qui opère derrière. C'est le rôle de l'offre PA Connect : la même API, en marque grise, à 200 €/mois HT plus un coût au document dégressif de 0,15 € à 0,05 € selon le volume. Les webhooks décrits ci-dessus sont le canal par lequel votre produit reste synchronisé avec le cycle de vie DGFiP de chaque document. Le modèle est détaillé dans notre article sur l'API marque grise pour Plateforme Agréée.

Questions fréquentes

Q : Comment vérifier qu'un webhook vient bien de ma Plateforme Agréée ?

R : En vérifiant la signature de chaque livraison. À la création de l'abonnement, la PA vous délivre un secret de signature ; votre serveur recalcule la signature du payload reçu et la compare à celle transmise par la plateforme. Toute requête non signée ou mal signée doit être rejetée avant tout traitement. Chez WeInvoice, le secret est délivré une seule fois à la création et peut être tourné, l'ancien restant valide 24 h.

Q : Que se passe-t-il si mon serveur est indisponible quand le webhook est envoyé ?

R : La livraison échoue puis est retentée automatiquement selon une politique d'espacement. Votre traitement doit donc être idempotent, car un même événement peut arriver plusieurs fois ou en retard. Si l'indisponibilité dépasse la fenêtre de retries, l'historique des livraisons permet d'identifier les échecs et de rejouer chaque livraison manquée avec un nouvel event id.

Q : Le webhook remplace-t-il complètement le polling ?

R : En mécanisme principal, oui : le webhook offre une latence de quelques secondes là où le polling se compte en minutes. En pratique, on conserve souvent une réconciliation périodique par API comme filet de sécurité, pour vérifier qu'aucun événement n'a été perdu après un incident prolongé. Le webhook pilote le temps réel, le polling audite.

Q : Quels statuts DGFiP faut-il écouter en priorité ?

R : Les quatre statuts obligatoires : 200 Déposée (confirmation d'émission), 213 Rejetée (correction technique à relancer), 210 Refusée (refus commercial à traiter par avoir et refacturation) et 212 Encaissée, qui déclenche le pré-remplissage TVA et la comptabilisation de l'encaissement. Les six statuts recommandés affinent ensuite le suivi de la relation client.

Q : Comment tester mon intégration sans émettre de vraies factures ?

R : En utilisant la sandbox de la plateforme, qui déroule le cycle complet — émission, changements de statut, webhooks — sans document fiscalement réel. WeInvoice propose en complément un ping synchrone signé pour valider l'endpoint et la vérification de signature en une requête, ainsi qu'un guide sandbox dédié dans le centre d'aide.

À retenir

  • À partir du 1ᵉʳ septembre 2026, chaque facture B2B domestique porte des statuts DGFiP normalisés — le webhook est le moyen standard de les suivre en temps réel depuis son ERP.
  • Push > pull : le webhook notifie en secondes ce que le polling découvre en minutes, sans requêtes à vide.
  • Quatre réflexes d'implémentation : endpoint HTTPS dédié, réponse 2xx rapide avec traitement asynchrone, idempotence par event id, vérification systématique de la signature.
  • L'API WeInvoice ajoute l'outillage d'exploitation : rotation de secret (ancien valide 24 h), ping de test signé, historique des livraisons, replay avec nouvel event id, sandbox et SDK multi-langages.
  • Pour les ESN et éditeurs, l'offre PA Connect expose ces capacités en marque grise, à 200 €/mois HT plus un coût au document dégressif.

Pour aller plus loin

Article publié le 2026-07-06 par Gauthier Jozan.

WeInvoice by Weproc est une Plateforme Agréée immatriculée par la DGFiP sous le numéro PA n° 0104.

Article publié le 6 juillet 2026 par Gauthier Jozan.

WeInvoice by Weproc est une Plateforme Agréée immatriculée par la DGFiP sous le numéro PA n° 0104. Voir la fiche conformité.