Logiciel RH multi-sites : présences, SIF et ERP pour la région MENA

Pourquoi les outils RH mono-entité s'effondrent dès qu'on franchit une frontière

La plupart des plateformes RH vendues en Égypte ont été conçues pour une seule entité juridique, un seul calendrier de paie et une seule devise. Dès l'ouverture d'une deuxième agence à Alexandrie ou d'une filiale à Riyad, le modèle de données commence à se fissurer. Les relevés de présence s'accumulent dans des tableaux Excel distincts, les gestionnaires de paie de chaque site font leur propre clôture mensuelle, et le DRH reçoit un rapport d'effectifs consolidé déjà vieux de deux semaines.

Le problème est architectural, pas superficiel. Un logiciel RH multi-sites doit pouvoir héberger des entités juridiques distinctes au sein d'une hiérarchie organisationnelle unique — chacune avec son droit du travail, son calendrier de paie et ses règles bancaires — tout en offrant des tableaux de bord unifiés au niveau du groupe.

Agrégation des présences multi-sites : l'architecture de données qu'il vous faut

Consolider les présences entre plusieurs sites est bien plus complexe qu'il n'y paraît. Prenons une entreprise de 300 salariés répartis entre Le Caire, Dubaï et Riyad :

• Le Caire fonctionne à l'heure standard d'Égypte (UTC+2), avec un week-end vendredi–samedi pour certains départements.
• Dubaï est à UTC+4 avec un week-end vendredi–samedi généralisé.
• Riyad est à UTC+3, également en vendredi–samedi, mais avec un calendrier de jours fériés différent.

Une agrégation naïve qui se contente d'additionner les pointages génère des chevauchements de créneaux fantômes et de fausses alertes d'heures supplémentaires. La bonne approche consiste à normaliser chaque pointage en UTC à l'ingestion, à stocker le décalage local comme métadonnée, et à appliquer les modèles de poste propres à chaque site avant de calculer les heures travaillées. Les données peuvent alors remonter proprement vers un récapitulatif de présences au niveau du groupe.

L'intégration des terminaux est tout aussi déterminante. Les bornes biométriques ZKTeco, Suprema ou Hikvision transmettent leurs journaux bruts via SOAP ou REST. La plateforme RH doit accepter les deux protocoles, dédupliquer les enregistrements (les tentatives de reconnexion réseau provoquent des doublons bien plus souvent que les fabricants ne l'admettent), et les réconcilier avec les plannings dans une tolérance configurable — généralement ±5 minutes pour une journée de travail standard.

Loi du travail égyptienne 12/2003 — ce que les récentes mises à jour ont vraiment changé

La loi du travail égyptienne 12/2003 a fait l'objet de décrets ministériels successifs que les logiciels RH ignorent souvent. Pour une entreprise cairote de 200 salariés, les impacts concrets sont les suivants :

1. Plafond et majoration des heures supplémentaires : les heures supplémentaires sont plafonnées à deux heures par jour et doivent être rémunérées à 135 % pour les prolongations diurnes et à 170 % pour les postes de nuit (entre 19h et 7h). Le moteur de calcul doit signaler automatiquement tout planning qui dépasse ce plafond journalier.
2. Acquisition des congés annuels : les salariés ayant moins de dix ans d'ancienneté acquièrent 21 jours calendaires par an ; au-delà de dix ans ou à partir de 50 ans, ce quota passe à 30 jours. Le moteur d'acquisition doit suivre l'ancienneté et les jalons d'anniversaire, et pas seulement la date d'embauche.
3. Encadrement de la période d'essai : la période d'essai ne peut excéder trois mois, et les obligations de préavis diffèrent. Un système appliquant un workflow de rupture unique quel que soit le statut du salarié produira des lettres juridiquement incorrectes.
4. Assiette des assurances sociales : les tranches minimale et maximale de salaire assurable sont révisées périodiquement. La paie doit récupérer dynamiquement les tranches en vigueur, et non à partir d'une table codée en dur mise à jour pour la dernière fois en 2021.

Tout logiciel RH d'entreprise dont les équipes égyptiennes dépendent doit encoder ces règles sous forme de paramètres configurables — et non de logique enfouie — afin que les responsables de conformité puissent auditer les calculs sans devoir lire le code source.

Export du fichier SIF pour les Émirats : ce que la spécification de la Banque Centrale exige réellement

Le Salary Information File (SIF) des Émirats arabes unis est soumis à la Banque Centrale via le Wages Protection System. Chaque enregistrement du fichier doit contenir 25 champs, notamment le numéro d'enregistrement de l'employeur auprès de la Banque Centrale, l'Emirates ID du salarié, le salaire de base, les indemnités ventilées par catégorie et le montant réel du virement. Le fichier doit être délimité par des pipes et encodé en UTF-8 sans BOM (byte-order mark).

Les causes courantes de rejet par le WPS :

• Des enregistrements salariés avec un Emirates ID expiré — la Banque Centrale valide en temps réel auprès de la base ICA.
• Des montants de salaire arrondis au dirham le plus proche plutôt qu'exprimés à deux décimales.
• Un IBAN manquant ou mal formaté pour la banque destinataire.
• Un montant total dans l'en-tête du fichier ne correspondant pas à la somme des enregistrements individuels, au fils près.

Un module d'export de fichier SIF UAE digne de ce nom génère un rapport de validation pré-soumission signalant chaque erreur au niveau de l'enregistrement avant que le fichier ne quitte le système. Cette seule fonctionnalité fait gagner plusieurs heures à la plupart des équipes paie à chaque cycle.

WPS en Arabie Saoudite : l'intégration MUDAD et ce qui a changé en 2024

Le Wage Protection System d'Arabie Saoudite opère via MUDAD, qui fait office de passerelle technique entre les employeurs et le ministère des Ressources Humaines. Contrairement au modèle de fichier plat des Émirats, MUDAD accepte les données de paie par API — votre plateforme RH doit donc disposer d'une intégration active, pas simplement d'un bouton d'export.

La mise à jour des exigences de 2024 impose que les soumissions de paie incluent le numéro d'Iqama ou de carte d'identité nationale du salarié, mis en correspondance avec son enregistrement GOSI. Si le rapprochement échoue, le virement est bloqué et l'employeur est signalé pour violation potentielle. Pour les entreprises gérant la paie WPS en Arabie Saoudite sur plusieurs centres de coût, l'intégration doit également ventiler les paiements par code de centre de coût si l'entreprise utilise un modèle de décaissement multi-bancaire.

Moteurs d'acquisition de congés : au-delà du simple décompte de jours

Un moteur d'acquisition de congés qui se contente de suivre les jours pris par rapport aux jours acquis est insuffisant pour une entreprise MENA de taille intermédiaire. Un moteur en production doit gérer :

• Les plafonds de report : la loi égyptienne limite le report dans certaines interprétations ; certaines zones franches des Émirats autorisent un report illimité.
• La proratisation à l'entrée et à la sortie : l'acquisition doit commencer à la date exacte d'embauche, pas au premier du mois.
• Le calcul du rachat de congés : lors du départ d'un salarié, le système doit calculer le solde rachetable sur la base du salaire de base actuel, et non du salaire en vigueur au moment où les congés ont été acquis.
• Les politiques multi-juridictions pour un même salarié : un cadre détaché du Caire à Dubaï pendant huit mois peut accumuler des droits selon les termes de son contrat égyptien tout en prenant ses congés dans le calendrier émirati.

Intégration ERP : pourquoi les API point à point ne suffisent pas

La plupart des discussions entre DRH et éditeurs sur l'intégration ERP s'arrêtent à « nous avons une API ». C'est le point de départ, pas la solution. Intégrer les données RH avec SAP, Oracle NetSuite ou Microsoft Dynamics exige de s'entendre sur quatre points : la correspondance des entités (comment les centres de coût RH s'associent aux comptes du grand livre), le modèle de déclenchement (la paie est-elle envoyée à l'approbation ou à la confirmation bancaire ?), le protocole de gestion des erreurs (que se passe-t-il pour un lot partiellement traité ?) et la cadence de réconciliation.

Une couche middleware — qu'il s'agisse d'un iPaaS dédié comme MuleSoft ou d'un orchestrateur de webhooks léger — est presque toujours nécessaire. Les intégrations directes en base de données entre RH et ERP deviennent un fardeau de maintenance à chaque mise à jour de l'un ou l'autre système.

Attendux répond à ce besoin avec une couche d'intégration structurée qui mappe les sorties de paie vers des schémas GL standards et prend en charge l'envoi événementiel vers les points de terminaison ERP, réduisant ainsi le travail de réconciliation qui incombe généralement à un analyste financier le lendemain de la clôture de paie.

À quoi ressemble réellement un dispositif RH multi-sites mature

En synthèse, une entreprise MENA de 100 à 500 salariés présente dans deux pays ou plus doit pouvoir attendre de sa plateforme RH :

• Un organigramme unique avec une configuration juridique par entité et par site
• Une agrégation des présences tenant compte des fuseaux horaires, avec des connecteurs pour terminaux biométriques
• Des moteurs de paie propres à chaque pays — assurances sociales égyptiennes, export SIF UAE, API MUDAD Arabie Saoudite
• Un moteur d'acquisition de congés configurable gérant les variations de politique par entité et par contrat
• Un cadre d'intégration ERP avec journalisation des erreurs et rapports de réconciliation
• Des pistes d'audit sur chaque modification de configuration, parce que les contrôles de conformité arrivent

Attendux a été conçu précisément pour ce profil opérationnel — des entreprises régionales trop complexes pour un SaaS générique, mais qui ne peuvent pas se permettre un module RH ERP enterprise nécessitant dix-huit mois de déploiement.

« Le vide dans le marché ne se situe pas entre les petits outils RH et les grandes suites ERP. Il se situe entre ces deux extrêmes et les besoins réels d'une entreprise de 250 personnes opérant dans trois pays arabes. »

Prêt à en parler ?

Si votre plateforme RH actuelle contraint votre équipe à réconcilier les présences dans Excel, à formater manuellement les fichiers SIF ou à maintenir un processus de paie distinct par pays, l'architecture travaille contre vous. L'équipe ProgMine peut vous montrer concrètement ce que ressemble une implémentation RH multi-sites adaptée à votre structure juridique — sans processus de découverte interminable. Contactez-nous ici et construisons la cartographie ensemble.