API et connecteur DGI
API DGI en RDC : comment préparer une intégration de Facture Normalisée ?
Ce qu'une équipe technique doit obtenir, décider et tester avant de connecter un ERP ou un POS au parcours DGI.
Mis à jour le 4 septembre 2026 par l'équipe EazLink. Relecture : Équipe éditoriale EazLink.
Une intégration API DGI en RDC ne doit pas partir d'un endpoint trouvé isolément. L'équipe doit utiliser le référentiel technique et les cas de test fournis pour le parcours SFE concerné, confirmer la version et obtenir les accès prévus. Elle peut ensuite construire un contrat stable entre l'ERP ou le POS et le connecteur fiscal, avec idempotence, statuts et journal d'audit.
Source de référence : Mise à jour 2026 des groupes de taxation et des cas de test SFE.
Deux contrats à ne pas mélanger
Le contrat interne reste stable. L'adaptateur DGI suit la version officielle du parcours.
| Contrat | Relie | Évolution |
|---|---|---|
| API métier EazLink | ERP ou POS vers le middleware | Stable pour les systèmes internes |
| Adaptateur DGI | Middleware vers le parcours fiscal | Mis à jour selon le référentiel applicable |
Cette séparation limite les changements à apporter dans chaque ERP lorsque le protocole fiscal évolue.
À retenir
Il n'existe pas un contrat API générique à deviner pour tous les projets.
Le référentiel, les accès et les cas de test viennent du parcours officiel applicable.
L'ERP ne doit pas dépendre directement de chaque détail du protocole fiscal.
Une reprise réseau doit réutiliser la même référence et vérifier le statut connu.
Figez la version du référentiel avant le premier développement.
Le schéma, les cas de test et la configuration doivent pouvoir être retrouvés pour chaque résultat.
Obtenir les bonnes références
Demandez la documentation correspondant au SFE, à la procédure et à l'environnement de test. Vérifiez sa date et sa version. La DGI a indiqué en février 2026 que des référentiels techniques et des cas de test mis à jour étaient disponibles dans l'espace développeur de e-DEF pour les acteurs concernés.
Ne copiez pas un exemple reçu d'un autre projet sans comparer le contexte. Les groupes de taxation, les champs et les réponses peuvent avoir changé. Conservez la source du document et la date à laquelle l'équipe l'a utilisé.
Définir le contrat côté ERP
Le système métier envoie un document compréhensible : vendeur, client, lignes, taxes, devise, type et référence. Les noms de tables Odoo ou SAP restent dans l'adaptateur. Le coeur de l'intégration ne devrait pas connaître les détails de chaque ERP.
Décidez aussi ce qui bloque avant l'envoi. Un total incohérent ou une ligne vide doit produire une erreur claire. Le middleware ne corrige pas silencieusement le document, car la finance doit savoir quelle valeur a été transmise.
Traiter les réponses et les délais
Une réponse immédiate n'est pas garantie dans tous les incidents. Le document peut être reçu, en cours, en attente, confirmé ou rejeté. L'API interne rend cet état et l'action suivante au logiciel source. Le POS n'a pas besoin de connaître le code technique du service distant.
Chaque demande utilise une clé d'idempotence. Si la connexion tombe après l'envoi, le connecteur consulte le résultat avant de recommencer. Cette règle protège la comptabilité contre les doublons créés par une relance aveugle.
Sécuriser et tester
Les secrets restent hors du code. Ils sont séparés par environnement, limités aux droits nécessaires et renouvelés selon une procédure connue. Les journaux masquent les données sensibles tout en gardant la référence, l'heure, l'état et la version du connecteur.
Le jeu de tests couvre les factures, les avoirs, les taxes, les devises et les erreurs. Ajoutez une expiration de jeton, une réponse lente et une coupure après soumission. Un test réussi doit être reproductible par une autre personne que le développeur initial.
Questions fréquentes
Où trouver la documentation API DGI ?
La DGI a renvoyé les acteurs SFE concernés vers les référentiels et cas de test de son espace développeur e-DEF. L'accès dépend du parcours officiel.
Peut-on connecter directement chaque ERP ?
C'est possible selon l'architecture autorisée, mais une couche commune évite de réécrire la logique fiscale dans chaque système.
Que signifie idempotence ?
Une même référence de demande renvoie le résultat connu au lieu de créer un second document.
Une API disponible prouve-t-elle l'homologation ?
Non. La capacité technique et le statut d'homologation sont deux sujets distincts.
Sources et vérification
Vérifiez les procédures et listes actuelles avant toute décision de conformité.
Mise à jour DGIMise à jour 2026 des groupes de taxation et des cas de test SFECommuniqué DGILancement de la procédure d'homologation des SFEMises à jour officiellesCommuniqués officiels de la DGI RDCVous avez déjà un ERP, un POS ou une documentation technique ?
Indiquez le système, le format disponible et l'état du parcours SFE. Nous examinerons le contrat d'échange et le pilote à préparer.