À l’approche d’une mise en production, l’attention se concentre naturellement sur le fonctionnement nominal.
La facture doit être émise dans le bon format, transmise par le circuit prévu, reçue sur la plateforme désignée, intégrée dans le système d’information puis orientée vers les contrôles et validations internes.
Lorsque ce chemin fonctionne de bout en bout, la démonstration paraît convaincante.
Mais une bascule ne se juge pas uniquement sur le scénario idéal. Elle se juge aussi sur la capacité de l’organisation à détecter, contenir et corriger le premier incident sans interrompre l’activité.
Dans le contexte de la facturation électronique, cette préparation devient particulièrement concrète. À compter du 1er septembre 2026, toutes les entreprises concernées doivent être en mesure de recevoir des factures électroniques. Les grandes entreprises et les entreprises de taille intermédiaire sont également soumises à cette date à l’obligation d’émission et de e-reporting. Calendrier officiel du ministère de l’Économie
Le jalon réglementaire est clair. La réalité opérationnelle l’est parfois moins.
Une facture peut être correctement adressée à la plateforme et néanmoins ne pas rejoindre le processus interne attendu. Le problème peut provenir d’un paramétrage, d’un connecteur, d’une donnée de routage, d’un référentiel, d’une règle de gestion ou d’une organisation encore incomplète.
Le projet doit donc préparer non seulement la cible, mais aussi la continuité pendant la correction.
Recevoir une facture ne signifie pas encore savoir la traiter
La réception réglementaire constitue un point de passage essentiel. Elle ne couvre toutefois pas toute la chaîne Procure-to-Pay.
Après réception, plusieurs opérations restent nécessaires :
- identifier l’entité et le fournisseur ;
- contrôler les données de la facture ;
- rapprocher la commande, la réception et la facture ;
- déterminer l’imputation comptable et analytique ;
- orienter l’exception vers le bon interlocuteur ;
- recueillir les validations utiles ;
- comptabiliser la facture ;
- préparer le paiement ;
- conserver les preuves nécessaires.
Un flux peut donc avoir franchi la porte d’entrée sans être réellement exploitable.
Cette distinction ne remet pas en cause la réforme. Elle rappelle qu’une obligation d’échange électronique doit s’insérer dans un processus Finance et SI plus large.
Le cycle P2P ne commence pas à la facture et ne se termine pas à sa réception technique.
Ce que prévoit le guide pratique de la DGFiP
Le guide pratique publié pour accompagner le démarrage de la réforme traite explicitement du cas dans lequel une facture électronique est reçue, mais ne peut pas encore être traitée correctement par le logiciel ou l’organisation interne.
Il indique qu’une difficulté d’organisation, de paramétrage ou d’intégration informatique ne doit pas conduire à interrompre le traitement, à retarder artificiellement le paiement ou à désorganiser la relation commerciale.
L’entreprise doit identifier la difficulté, solliciter les acteurs capables de la corriger et peut mettre en place des modalités internes transitoires, à condition de conserver une traçabilité suffisante. Guide pratique de la DGFiP
Les éléments conservés doivent notamment permettre d’établir :
- la date de réception ;
- la difficulté rencontrée ;
- les démarches engagées ;
- la modalité transitoire retenue ;
- le retour au fonctionnement normal.
Cette approche articule conformité, continuité d’activité et correction.
Le traitement transitoire n’est pas une dispense durable. Il s’agit d’un dispositif maîtrisé pour éviter qu’un incident de démarrage ne devienne un blocage de paiement ou une rupture dans la relation fournisseur.
Pourquoi le plan B est un livrable du projet
Le scénario de repli est parfois laissé à l’équipe support après la mise en production.
Cette séparation est risquée.
L’équipe projet connaît les flux, les hypothèses de conception, les règles de routage, les interfaces et les points de contrôle. Elle est donc la mieux placée pour identifier les incidents probables et préparer les réponses attendues.
Le plan B doit être conçu avant la bascule, testé pendant la recette et transmis à l’équipe qui assurera l’hypercare.
Il répond à quatre objectifs.
Continuer à traiter les factures
Une facture reçue mais non intégrée ne doit pas disparaître dans un écart technique.
Elle doit rester visible, être qualifiée puis orientée vers un traitement temporaire clairement identifié.
Le dispositif doit éviter les fichiers personnels, les boîtes mail non surveillées et les listes parallèles sans responsable.
Éviter les doublons et les paiements indus
Lorsqu’un flux est rejoué après correction, la même facture peut apparaître une seconde fois dans le système.
Le scénario de repli doit donc définir :
- l’identifiant utilisé pour rapprocher les occurrences ;
- le statut de la facture traitée temporairement ;
- le contrôle préalable au rejeu ;
- le responsable autorisé à clôturer les deux traces.
Continuer l’activité sans contrôle anti-doublon déplace simplement le risque.
Conserver la preuve
La traçabilité ne doit pas être reconstruite plusieurs semaines plus tard.
Chaque exception doit laisser une preuve proportionnée : date, facture concernée, nature de l’incident, décision prise, traitement appliqué, contrôle réalisé et date de retour au nominal.
Cette information sécurise le suivi opérationnel, l’audit et l’amélioration du processus.
Refermer le dispositif transitoire
Un processus temporaire qui n’a ni échéance ni responsable finit souvent par devenir permanent.
Le plan B doit donc prévoir ses conditions de sortie :
- correction validée ;
- tests de non-régression réussis ;
- flux rejoué ou rapproché ;
- backlog d’exceptions résorbé ;
- contrôles réalisés ;
- communication de fin d’incident ;
- clôture formelle de la mesure transitoire.
Le retour au nominal est une étape à part entière.
Sept informations à formaliser
1. Le signal d’alerte
Comment l’incident est-il détecté ?
Il peut s’agir d’un rejet de plateforme, d’un échec d’intégration, d’une absence de facture attendue, d’un écart entre deux compteurs ou d’un délai de traitement anormal.
Un incident invisible n’est pas maîtrisable.
2. Le responsable du diagnostic
Une personne ou un rôle doit coordonner l’analyse.
Selon le cas, le diagnostic mobilisera la Finance, la DSI, l’éditeur, l’intégrateur, la plateforme agréée ou le support.
3. La procédure transitoire
Le document doit expliquer comment la facture continue à être traitée pendant la correction.
Cette procédure précise le canal, le lieu de stockage, les statuts, les responsables et les délais.
4. Le contrôle compensatoire
Toute dérogation au flux nominal peut créer un risque.
Le contrôle compensatoire vise notamment la perte de facture, le doublon, l’imputation erronée, la validation insuffisante ou le paiement indu.
5. Les preuves à conserver
La preuve doit permettre de relier la facture, l’incident et le traitement effectué.
Elle doit rester accessible dans l’espace de travail défini par le projet.
6. Le délai et l’escalade
Chaque incident doit posséder une cible de résolution.
Lorsque ce délai est dépassé ou que le volume d’exceptions augmente, l’escalade doit être déclenchée vers le bon niveau de décision.
7. La règle de retour au nominal
Le projet doit définir qui autorise le retour au flux normal et selon quels critères.
Cette règle évite les reprises prématurées et les procédures temporaires qui se prolongent sans décision.
L’hypercare doit piloter un flux, pas seulement des tickets
Après la mise en production, le suivi ne doit pas se limiter au nombre d’incidents ouverts et fermés.
Pour un processus de facturation, il faut également suivre :
- le nombre de factures reçues ;
- le nombre intégré avec succès ;
- le volume et l’âge des exceptions ;
- les traitements transitoires engagés ;
- les rejets et rejeux ;
- les doublons détectés ;
- les paiements menacés ;
- le délai moyen de retour au nominal.
Ces indicateurs permettent de distinguer un incident technique isolé d’une dégradation réelle du processus.
Ils donnent aux décideurs une vision plus utile qu’un simple statut « vert » ou « orange ».
Tester le scénario de repli avant le jour J
Le plan B doit être testé, pas seulement rédigé.
La recette peut intégrer les scénarios suivants :
- une facture reçue mais non intégrée ;
- un fournisseur non reconnu ;
- une donnée de routage incorrecte ;
- une facture rapprochée d’une mauvaise entité ;
- une interface indisponible ;
- un rejeu créant un risque de doublon ;
- un volume d’exceptions supérieur à la capacité de traitement.
Pour chaque cas, le test doit vérifier le résultat métier attendu : la facture reste visible, le risque est contenu, le traitement se poursuit, les preuves sont conservées et le retour au nominal est contrôlé.
Cette démarche complète la recette fonctionnelle fondée sur des résultats attendus.
Le rôle de l’AMOA
L’AMOA relie le fonctionnement technique aux conséquences métier.
Elle aide notamment à :
- cartographier les scénarios de rupture ;
- identifier les impacts Finance et fournisseurs ;
- définir les procédures transitoires ;
- formaliser les contrôles compensatoires ;
- préparer les cas de test ;
- organiser l’hypercare ;
- relier incidents, décisions, actions et risques ;
- construire les critères de sortie.
Le pilotage de projets Finance et SI doit rendre cette préparation visible avant le go-live.
Un plan B maîtrisé renforce la confiance
Prévoir un scénario de repli ne signifie pas anticiper l’échec.
Cela signifie reconnaître qu’une transformation met en relation des processus, des données, des interfaces, des organisations et des acteurs différents.
La maturité du projet ne consiste pas à affirmer qu’aucun incident ne surviendra.
Elle consiste à savoir :
- comment il sera détecté ;
- qui le prendra en charge ;
- comment l’activité continuera ;
- quels risques seront contrôlés ;
- quelles preuves seront conservées ;
- quand le fonctionnement normal sera rétabli.
À quelques jours du 1er septembre 2026, la question utile n’est pas seulement :
« Notre plateforme est-elle désignée ? »
Elle est aussi :
« Sommes-nous capables de traiter, tracer et corriger le premier incident sans perdre le contrôle du processus ? »
Bazire Consulting accompagne les directions Finance, les métiers et les DSI dans le cadrage, la recette, la préparation de la bascule et le pilotage opérationnel des projets de facturation électronique et de transformation P2P/O2C.
