Facturation électronique : ce que mes premiers tests m'ont appris

J'ai réalisé des tests d'émission et de réception de factures électroniques avec Dolibarr et une plateforme de facturation. Les deux sens ont fonctionné dans le cadre de mes essais. C'est une étape utile, mais elle m'a surtout permis de préciser ce qu'il faut vérifier autour de la connexion.

Pour une petite entreprise, la question pratique est simple : la facture créée dans son outil arrive-t-elle au bon endroit, avec les bonnes données, et peut-on suivre ce qui lui arrive ensuite ? Une connexion qui répond ne donne qu'une partie de la réponse.

Commencer par une configuration identifiable

Mon installation associe Dolibarr, un module de facturation électronique et SuperPDP. Le bac à sable m'a permis de tester les échanges. Je distingue ce résultat d'essai d'une validation de tous les scénarios de production : les avoirs, les erreurs et les cas particuliers demandent leurs propres vérifications.

Avant de lancer les échanges, il faut savoir quel compte et quel environnement sont utilisés. Les accès de test et de production doivent rester distincts. Les paramètres du module, les identifiants de connexion et les droits associés doivent également être documentés.

Je conseille de noter les versions de Dolibarr et du module au moment d'un test réussi. Cela donne un repère concret si le comportement change après une mise à jour. On peut alors comparer une configuration connue à la nouvelle situation, au lieu de chercher sans point de départ.

Regarder les données derrière le document

Une facture lisible à l'écran n'est pas nécessairement complète pour un échange structuré. Le logiciel doit fournir des informations exploitables : identité des parties, références, dates, lignes, taxes et totaux. Les coordonnées et identifiants des tiers méritent donc une vérification avant le premier envoi.

Les formats UBL, CII et Factur-X reviennent dans les solutions de facturation électronique. UBL et CII organisent des données structurées ; Factur-X associe un PDF lisible à des données structurées intégrées. Ce dernier ne se résume donc pas à un PDF ordinaire envoyé par courriel.

Pour l'entreprise, le choix utile consiste à vérifier ce que son module produit réellement et ce que sa plateforme accepte. Il n'est pas nécessaire de maîtriser toute la syntaxe, mais il faut pouvoir rapprocher les informations transmises de la facture présente dans Dolibarr.

Vérifier l'émission et la réception séparément

J'ai testé les deux directions. Cette distinction compte : réussir un envoi ne démontre pas que la réception est correctement configurée. Les accès, le traitement des documents entrants et leur mise à disposition peuvent suivre des chemins différents.

Pour l'émission, je recommande de suivre une facture depuis sa création jusqu'au retour disponible dans la plateforme, puis de vérifier l'information récupérée dans l'outil. Pour la réception, il faut contrôler où le document arrive, comment on identifie son fournisseur et comment il entre dans le circuit interne de validation.

Un test ne devrait pas se terminer sur le seul message « envoyé ». Il faut conserver la référence de l'échange et comprendre le statut observé. Un dépôt accepté, une facture rejetée et une facture payée décrivent des situations différentes. Leur interprétation dépend des retours effectivement disponibles dans la solution.

La connexion ne corrige pas les habitudes de saisie

Un autre point m'a amené à regarder la chronologie des factures : une date portée sur le document et une date de création dans le logiciel ne racontent pas toujours la même chose. C'est un sujet à clarifier dans l'organisation de la facturation, avec la personne qui suit la comptabilité.

Plus généralement, il faut vérifier les dates, les références, les montants et les règles de numérotation avant d'automatiser l'envoi. La plateforme transmet les données qu'on lui donne ; elle ne remplace pas la compréhension du dossier.

Pour élargir les essais, je recommande ensuite un avoir, une donnée manquante et une interruption de connexion. L'objectif est de savoir comment corriger un problème et reprendre l'échange sans produire un doublon ni perdre la trace du document initial. Ces scénarios restent à distinguer des tests déjà réussis.

Préparer un fonctionnement quotidien

La terminologie actuelle parle de plateforme agréée, là où l'on utilisait auparavant le sigle PDP. Au moment du choix, le statut de la plateforme doit être vérifié dans la liste officielle, ainsi que son adéquation avec le logiciel utilisé.

Mes premiers essais m'ont donné une base technique encourageante. Pour rendre cette base exploitable au quotidien, je retiens trois priorités : des données fiables, des statuts compréhensibles et une personne désignée pour traiter les exceptions.

La bonne question pour une PME n'est donc pas seulement « sommes-nous connectés ? ». C'est aussi « savons-nous retrouver une facture, comprendre un rejet et reprendre le traitement ? ». C'est à ce niveau que les essais deviennent un outil de préparation concret.