Noqta
écrits/blog/2026/05
● Blog16 mai 2026·6 min

Odoo + ZATCA Vague 24 : Chaque piège Fatoora rencontré sur de vrais déploiements saoudiens

Vague 24 : 30 juin 2026 pour les PME saoudiennes 375k-750k SAR. Les cinq pièges Odoo + Fatoora qui mordent, plus une checklist en 10 points.

Anis Marrouchi
·EN · FR · AR

Odoo + ZATCA Vague 24 : Chaque piège Fatoora rencontré sur de vrais déploiements saoudiens

Si votre entreprise saoudienne réalise un chiffre d'affaires entre 375 000 et 750 000 SAR et que vous tournez sous Odoo, vous avez environ six semaines pour être conforme à la Phase 2 de ZATCA.

L'échéance de la Vague 24 est fixée au 30 juin 2026. La Vague 23 (tranche 750k-1M SAR) est déjà passée le 31 mars 2026 — donc le régulateur est en mode application, plus en mode accompagnement. Manquer la date coûte cher : pénalités à partir de 5 000 SAR, jusqu'à 50 000 SAR par infraction, plus la douleur opérationnelle de voir chaque facture B2B rejetée à la soumission.

Nous avons mené plusieurs intégrations Odoo + ZATCA Phase 2 à Riyad, Djeddah et Dammam ces 18 derniers mois. Les cinq mêmes choses reviennent à chaque fois. Cet article est le brief que nous aurions aimé avoir avant notre premier déploiement.

Pour le rappel réglementaire, voir notre guide complet de la facturation électronique ZATCA Fatoorah 2026. Cet article-ci suppose que vous savez déjà ce qu'est la Phase 2 — et zoome sur les pièges propres à Odoo.

Pourquoi Odoo + ZATCA n'est vraiment pas trivial

L'Arabie Saoudite est le 2e marché Odoo mondial par nombre de partenaires — environ 204 partenaires actifs, derrière les États-Unis (~250) — sur plus de 170 000 clients Odoo dans le monde. Cette densité s'explique : Odoo correspond bien au mid-market saoudien (RTL arabe, multi-sociétés, production + retail + services dans une seule pile, tarification raisonnable face à SAP).

Mais ZATCA Phase 2 n'a pas été pensé pour le modèle de données d'Odoo. La friction apparaît à trois endroits :

  1. Architecture du portail Fatoora. Le portail Fatoora est l'interface d'onboarding du régulateur. Vous demandez un identifiant de cachet cryptographique (CSID) par journal de ventes, puis activez l'appareil en environnement simulation ou production. Les flux de clearance et de reporting passent en XML sur API avec une validation stricte du schéma UBL 2.1 — aucune dérogation manuelle possible.
  2. Un appareil par journal. Chaque journal de ventes Odoo (POS, boutique en ligne, services B2B, ventes produits finis de production, etc.) a besoin de son propre appareil ZATCA dans le portail. Les groupes saoudiens multi-sociétés finissent souvent par onboarder 8-15 appareils dans une seule instance Odoo.
  3. Phase de simulation obligatoire. ZATCA exige que vous testiez l'intégration de bout en bout sur l'environnement de simulation, génériez des factures de test, et seulement ensuite promouviez en production. Cette promotion elle-même est une porte à sens unique — détails plus bas.

Ajoutez l'arabe + le calendrier hégirien dans les rapports, la paie conforme GOSI, et les intégrations avec mada / Apple Pay / STC Pay, et un "simple installation du module ZATCA" devient un projet de six semaines.

Les cinq pièges qui mordent vraiment

Classés par nombre de fois où ils nous ont coûté un re-déploiement. Ils renvoient directement à la FAQ en bas — gardez-les en marque-page.

1. L'OTP qui expire en 2 minutes lors de l'onboarding de l'appareil

Lors de l'onboarding d'un appareil de journal de ventes via le portail Fatoora, ZATCA envoie par email (ou SMS) un OTP qui expire en 120 secondes. Vous devez le saisir dans l'assistant ZATCA d'Odoo avant son expiration.

En pratique : le responsable finance ayant accès au portail Fatoora et l'administrateur Odoo doivent être physiquement ensemble pendant l'onboarding (ou en appel live avec partage d'écran). Tenter de le faire en asynchrone — "je t'envoie l'OTP sur WhatsApp" — a échoué plus d'une fois pour nous, rien qu'à cause du délai de livraison du message.

Astuce : pré-positionnez l'assistant Odoo jusqu'à l'invite OTP, puis demandez l'OTP. Vous gagnez les 120 secondes pleines.

2. Le passage sandbox → production à sens unique

Le changement d'environnement ZATCA est irréversible. Une fois qu'un appareil de journal Odoo est promu de la simulation à la production, vous ne pouvez plus revenir en arrière. Si la validation du schéma XML production échoue sur la première vraie facture — par exemple parce que votre numéro de TVA contient un espace parasite, ou que l'adresse de l'acheteur n'a pas la balise UBL streetName requise — vous ne pouvez pas simplement retenter depuis le sandbox. Il faut escalader via le support ZATCA pour désactiver l'appareil et re-onboarder, ce qui nous a pris 3 à 7 jours ouvrés.

Mitigation : générez au moins 50-100 factures représentatives en simulation (B2B, B2C, avoirs, notes de débit, devises étrangères, articles gratuits) et vérifiez qu'elles passent toutes la clearance avant de basculer. L'environnement de simulation se comporte exactement comme la production pour la validation — utilisez-le.

3. Les configurations multi-sociétés KSA multiplient le nombre d'appareils

Les groupes saoudiens utilisent fréquemment plusieurs entités légales dans une seule instance Odoo — une holding, une activité retail, une activité contracting, une entité immobilière. Chaque entité a son propre numéro de TVA. Chaque TVA a besoin de son propre onboarding Fatoora. Chaque journal de ventes à l'intérieur de cette entité a besoin de son propre appareil.

Nous avons vu une seule instance Odoo nécessiter 14 appareils onboardés sur 4 sociétés et leurs journaux POS / en ligne / B2B. Cela fait 14 fenêtres OTP, 14 CSIDs à stocker en toute sécurité, et 14 décisions de bascule production. Budgétez le temps — et documentez l'emplacement de stockage de chaque CSID avant de commencer, pas après.

4. Mauvais déclenchement de la phase de simulation = amendes sur les factures de test

Celui-ci est vicieux. Le portail Fatoora attend que vous activiez le portail de simulation à une étape spécifique de l'onboarding — après les tests sandbox, avant le passage en production. Si votre équipe Odoo configure par erreur le endpoint production alors que l'appareil est encore en mode simulation (ou inversement), certaines factures de test peuvent être marquées comme soumissions live sur un mauvais profil d'appareil — et les soumissions live non conformes entraînent des amendes.

[verify] Nous avons vu un client recevoir un avis pour exactement cette mauvaise configuration ; ZATCA a annulé l'amende après que nous ayons produit les logs d'intégration prouvant l'intention, mais la politique reste à la discrétion de l'inspecteur. Traitez l'activation du mode simulation comme une porte de contrôle de changement formelle : une seule personne bascule, le changement est loggé dans le tracker projet, et aucune transaction marquée production ne touche l'API avant la porte.

5. Rapports arabe / hégirien + couche paie GOSI

ZATCA Phase 2 en soi n'impose pas l'hégirien — les dates grégoriennes sont acceptées sur la facture XML. Mais votre équipe finance saoudienne attendra les rapports mensuels et trimestriels en hégirien, et votre module paie GOSI doit calculer les cotisations sur des cycles de paie hégiriens. La localisation Odoo standard (l10n_sa, l10n_sa_edi, l10n_sa_hr_payroll) couvre les bases mais nécessite couramment des modèles de rapports custom — et les cas limites de conversion hégirien/grégorien (longueur du mois de Ramadan, chevauchement de fin d'année) mordent à la clôture mensuelle.

Ce n'est pas un blocage Vague 24 en soi, mais ce sera l'escalade de la deuxième semaine post-go-live — anticipez maintenant.

Checklist pré-vol en 10 points

Copiez-collez dans votre tracker projet. Nous l'utilisons sur chaque déploiement Odoo saoudien :

  1. Vérifiez que l'enregistrement TVA est actif et correspond exactement à l'orthographe sur le registre du commerce saoudien (CR).
  2. Inventoriez tous les journaux de ventes qui émettront des factures : POS, boutique en ligne, services B2B, intersociétés, projets, produits finis production. Chacun = un appareil ZATCA.
  3. Installez / mettez à jour Odoo l10n_sa_edi dans la version correspondant à votre Odoo majeur (17 ou 19). Lisez le changelog pour les ruptures depuis votre dernière montée de version.
  4. Vérifiez les données maître acheteurs : chaque client B2B doit avoir un numéro de TVA, un nom légal complet en arabe + anglais, et une adresse conforme UBL (ville, code postal, rue, numéro de bâtiment).
  5. Créez les comptes portail Fatoora pour chaque entité légale. Testez la connexion sur chaque compte avant d'avoir besoin de l'OTP.
  6. Onboarder tous les appareils en sandbox d'abord. Stress-testez avec avoirs, factures en devise étrangère, exonérations TVA au niveau ligne.
  7. Faites passer 50-100 factures de simulation par le portail. Capturez et examinez chaque réponse de clearance XML.
  8. Sécurisez le stockage CSID : chaque CSID est un secret. Utilisez le coffre de paramètres chiffré d'Odoo ou un secret manager externe — pas une Google Sheet partagée.
  9. Planifiez la bascule production hors heures de pointe. Le vendredi est mauvais (weekend KSA) ; visez mardi ou mercredi matin pour avoir le support ZATCA pleinement disponible si quelque chose casse.
  10. Formez deux utilisateurs finance à lire les réponses d'échec de clearance. Les codes d'erreur ne sont pas du côté Odoo — ils viennent de ZATCA — et votre équipe doit pouvoir les trier sans escalader chaque cas à l'IT.

Le pattern d'architecture recommandé par Noqta

Nous déployons ZATCA Phase 2 sur Odoo en trois environnements nommés, avec une porte de promotion délibérée à chaque frontière :

[1] Sandbox          [2] Simulation         [3] Production
(Odoo dev DB)    →   (Odoo staging DB)  →   (Odoo prod DB)
+ ZATCA sandbox      + ZATCA simulation     + ZATCA production
- ré-init illimité   - ré-init illimité     - porte UNIQUE

Porte 1 → 2 : tous les journaux de ventes testés avec factures smoke-test, tous les schémas XML de clearance validés, tous les CSIDs émis avec succès en sandbox.

Porte 2 → 3 : 50+ factures représentatives passées en simulation, équipe finance ayant validé la sortie UBL arabe/anglais, secrets dans le secret manager production (pas dans ir.config_parameter en clair), et runbook de rollback existant — même si le rollback complet n'est pas possible, un rollback partiel (désactiver des journaux spécifiques via Odoo sans renverser l'appareil ZATCA) est ce qui donne la sécurité opérationnelle.

Couplez ceci à un audit honnête de la conformité facturation électronique avant le kickoff. Le cadre d'audit est écrit pour le contexte El Fatoora tunisien, mais la structure — qualité des données, hygiène des données maître, inventaire des journaux, chemins d'escalade — s'applique proprement à ZATCA.

Une note sur la sécurité Odoo

À mentionner parce que la confiance compte dans les intégrations finance : l'empreinte CVE d'Odoo est inhabituellement basse — environ 53 CVE publiés pour tout le vendor depuis 2017 (contre des centaines pour des ERP comparables). Le plus récent matériel est CVE-2024-36259 — une faille de divulgation d'information authentifiée dans le module mail d'Odoo 17, corrigée dans les versions de maintenance ultérieures.

Deux implications :

  • Si vous êtes encore sur Odoo 16 ou un mineur non patché d'Odoo 17, mettez à jour avant d'onboarder ZATCA. Vous ne voulez pas patcher l'ERP sous-jacent pendant votre bascule Vague 24.
  • La plupart des advisories sécurité Odoo sont gated derrière un abonnement Enterprise actif. Si vous tournez en Community Edition, prévoyez soit de monter en Enterprise, soit de bâtir votre propre processus de suivi CVE — et budgétez une heure par mois de revue de patching.

FAQ

Q1 : Quand exactement la Vague 24 ZATCA est-elle due ? 30 juin 2026, pour les entreprises avec un chiffre d'affaires annuel assujetti à la TVA entre 375 000 et 750 000 SAR. L'échéance de la Vague 23 (750k-1M SAR) était le 31 mars 2026 et est maintenant en mode application.

Q2 : Peut-on prolonger l'OTP Fatoora au-delà de 2 minutes ? Non. L'OTP expire en 120 secondes et il n'y a aucun moyen de le prolonger. Pré-positionnez l'assistant d'onboarding Odoo jusqu'à l'invite OTP avant de demander le code, et vous aurez la fenêtre complète.

Q3 : Nous avons promu notre journal Odoo en production par erreur — peut-on revenir ? Pas directement. La bascule sandbox-vers-production est à sens unique. Vous devrez ouvrir un ticket de support ZATCA pour désactiver l'appareil, puis re-onboarder. Le délai typique dans notre expérience est de 3-7 jours ouvrés, donc ne promouvez pas tant que vous n'êtes pas certain.

Q4 : Nous avons 4 sociétés saoudiennes dans une seule instance Odoo — chacune nécessite-t-elle un onboarding séparé ? Oui. Chaque entité légale a son propre enregistrement TVA et a besoin de son propre compte portail Fatoora, de son propre set de CSIDs, et d'un onboarding d'appareil par journal de ventes. Une configuration 4 sociétés avec 3 journaux de ventes par société = 12 appareils.

Q5 : ZATCA exige-t-elle le calendrier hégirien dans les rapports ? Non — ZATCA accepte les dates grégoriennes sur la facture XML. Mais votre équipe finance saoudienne attendra les rapports de gestion internes en hégirien, et la paie GOSI calcule sur des cycles hégiriens. Prévoyez des modèles de rapports Odoo custom dès le jour 1, pas au mois 2.

Besoin d'un coup de main sur la Vague 24 ?

Avec six semaines avant l'échéance, le calendrier est serré. Si vous voulez qu'un spécialiste Odoo-Arabie Saoudite challenge votre plan Vague 24, identifie auxquels des cinq pièges vous êtes exposés, et cadre une livraison réaliste, réservez un appel de découverte de 30 minutes avec notre équipe. Nous vous dirons honnêtement si vous pouvez tenir le 30 juin ou s'il vous faut un plan B.

Sources faisant autorité

Lectures connexes