Logiciel RH entreprise Égypte : export SIF, ERP & gestion des congés

Un retailer avec 11 points de vente au Caire, Alexandrie et Dubaï a traité la paie de 340 collaborateurs l'an dernier avec quatre feuilles Excel, deux groupes WhatsApp et une responsable paie sous pression permanente. Chaque jeudi après-midi, elle était encore en train de réconcilier manuellement les données de pointage des branches du Delta. Ce n'est pas un problème de workflow — c'est un problème d'architecture.

Pourquoi la présence multi-sites est plus complexe qu'il n'y paraît

La gestion de présence sur un site unique est un problème résolu. Dès lors que vous avez des branches dans différents gouvernorats — ou pire, dans différents pays — le modèle de données se brise de trois façons précises :

• Décalages horaires et de postes. Un entrepôt en équipe de nuit à Port-Saïd reporte dans la même période qu'une équipe au siège à Maadi en horaires 9h-17h standard. Si votre système stocke des horodatages bruts sans règles de postes par site, chaque rapport d'exceptions est inutilisable.
• Fragmentation des circuits de validation. Les responsables de site approuvent les heures supplémentaires localement, puis quelqu'un en RH doit tout agréger et re-vérifier avant la clôture de paie. Sans vue consolidée, l'agrégation reste manuelle.
• Latence entre les terminaux et le cloud. Les bornes biométriques dans les zones à faible connectivité bufferisent les pointages en local. Si votre plateforme RH ne gère pas gracieusement les enregistrements tardifs, vous devez soit bloquer la paie, soit la clôturer avec des données incomplètes.

La bonne architecture conserve un dossier salarié canonique au niveau de l'entreprise, délègue les règles de postes et les workflows de validation au niveau du site, et fusionne tout dans un jeu de données de paie unique — avec un journal d'audit montrant ce qui a changé et quand. Pour un regard approfondi sur la façon dont les terminaux biométriques s'intègrent dans ce pipeline, le guide pratique de la reconnaissance faciale en MENA couvre les décisions matérielles et de connectivité à prendre avant tout achat de terminaux.

Export du fichier SIF aux Émirats — les erreurs classiques des équipes RH

Le format Salary Information File (SIF) imposé par la Banque centrale des EAU pour la conformité WPS n'est pas compliqué — mais il est implacable. Un seul champ mal formé rejette l'intégralité du lot. Les erreurs les plus fréquentes :

• Des numéros de routage bancaire qui ne correspondent pas au format de compte enregistré par la banque (les conflits IBAN / numéro de compte historique apparaissent souvent après des fusions bancaires).
• Des montants de salaire incluant des indemnités que le système classe en « non-basique » alors que la banque les attend dans le champ du salaire de base.
• Des erreurs d'encodage — la spécification SIF exige un formatage ASCII précis, et les plateformes RH conçues pour des marchés arabophones exportent parfois des caractères UTF-8 dans les champs de noms, rejetés silencieusement par la passerelle de paiement.

La solution pratique consiste à intégrer une couche de validation qui soumet le fichier aux règles de champs de la Banque centrale avant envoi — et non après un lot rejeté le jour de paie. Prévoyez une fenêtre de test le dimanche matin pour que les rejets remontent avec quatre jours ouvrés devant vous avant la date limite du jeudi.

Paie WPS en Arabie Saoudite : règles différentes, même pression de délais

Le WPS saoudien via MUDAD fonctionne différemment du flux SIF des Émirats. Les distinctions clés que les équipes gérant la paie transfrontalière doivent intégrer :

• MUDAD exige que l'employeur enregistre l'IBAN de chaque salarié directement dans le portail — les erreurs de format sont détectées à l'enregistrement, pas au moment du virement, ce qui déplace l'étape de validation nécessaire.
• Les calculs d'indemnité de fin de service selon le droit du travail saoudien divergent du cadre de l'article 80 égyptien. Si votre plateforme RH utilise un moteur de calcul unique, vérifiez qu'il prend en charge des règles par pays plutôt que d'appliquer une formule universelle à toutes les entités.
• Le taux de conformité Nitaqat (saudisation) doit être déclaré parallèlement aux données de paie. Un système RH qui suit les codes de nationalité par rapport aux seuils d'effectifs évite un comptage manuel trimestriel.

Moteurs d'accrual de congés : la fonctionnalité que la plupart des plateformes négligent

« Accrual » paraît simple jusqu'au moment où vous avez des salariés sous trois politiques de congés différentes dans la même entreprise : les recrutements locaux sous le régime légal égyptien (21 jours de congés annuels après un an, selon la Loi du travail 12/2003), les expatriés sous des packages contractuels de 30 jours, et les temps partiels avec accrual proportionnel. Un modèle d'attribution annuelle fixe s'effondre immédiatement dans ce cas de figure.

Un vrai moteur d'accrual nécessite :

1. Des modèles de politique par type de contrat, et non par salarié — afin qu'un changement de politique se propage sans mise à jour manuelle de 200 dossiers individuels.
2. Des règles de report avec dates d'expiration. La loi égyptienne autorise le report, mais beaucoup d'entreprises le plafonnent à 30 jours avec une expiration à 12 mois. Le système doit annuler automatiquement les soldes expirés et générer un rapport pour que les RH le vérifient avant que cela se produise, pas après.
3. Le prorata à l'embauche et à la date de départ. Un salarié qui rejoint l'entreprise le 15 mars ne devrait pas bénéficier d'un droit plein la première année. Cela paraît évident — pourtant un nombre surprenant de plateformes se trompent lorsque la date d'embauche chevauche une frontière d'exercice comptable.

Loi du travail égyptienne 12/2003 : les clauses qui piègent les entreprises

La loi de 2003 et ses amendements ultérieurs ne sont pas figés. Trois domaines où les entreprises de taille intermédiaire font régulièrement des erreurs de calcul :

• Seuils des heures supplémentaires. La loi plafonne la journée standard à 8 heures et la semaine à 48 heures. Les heures supplémentaires au-delà sont rémunérées à au moins 135 % du taux horaire pour le travail de jour, 170 % pour les postes de nuit. Si votre système de présence ne signale pas automatiquement les majorations de nuit, vous sous-payez presque certainement certains salariés et en surpayez d'autres.
• Délais de préavis en cas de rupture. Le préavis légal s'allonge avec l'ancienneté — 2 mois pour les salariés avec 10 ans et plus de service. Un système RH qui ne remonte pas les données d'ancienneté au moment de générer une lettre de rupture crée une exposition légale.
• Calcul de l'assiette des cotisations sociales. Les tranches de salaire minimum et maximum soumises à cotisation sont mises à jour périodiquement par le gouvernement égyptien. Les coder en dur dans la logique de paie — plutôt que de les rendre configurables — signifie que chaque mise à jour réglementaire nécessite une demande de modification logicielle.

Pour une présentation détaillée du calcul correct de ces montants, le guide de calcul de la paie en Égypte couvre en un seul endroit les heures supplémentaires, les indemnités de fin de service et le traitement WPS.

Intégration ERP : ce qu'il faut exiger de votre plateforme RH

La plupart des entreprises de 100 à 500 salariés en Égypte fonctionnent avec SAP Business One, Oracle NetSuite, ou un ERP local comme ERPNext. La plateforme RH doit pousser trois types de données dans l'ERP de manière fiable :

• Les écritures de journal pour les centres de coûts de paie — ventilées par site, département ou projet selon le plan comptable.
• Les mouvements d'effectifs — embauches, départs et mutations qui impactent le suivi budgétaire dans le module finance.
• La provision pour congés acquis — le solde de congés non pris converti en valeur monétaire, qui constitue un vrai passif au bilan et que les auditeurs s'attendent à voir réconcilié.

Les exports de fichiers plats (CSV ou Excel) vers l'ERP ne sont pas une intégration — c'est une étape manuelle déguisée. Exigez une API REST ou, au minimum, un export automatisé planifié avec alertes en cas d'erreur. Lors de l'évaluation de plateformes RH, demandez au prestataire de démontrer en direct une écriture de journal de paie dans un ERP sandbox, et non une capture d'écran.

Attendux gère l'agrégation de présence multi-sites, les règles de paie par pays incluant les exports SIF et WPS, et les politiques d'accrual de congés configurables — conçu spécifiquement pour les structures opérationnelles MENA, et non adapté à partir d'un produit européen.

Liste de contrôle avant de vous engager sur une plateforme

Soumettez chaque prestataire présélectionné à ces questions avant de signer :

• Le système peut-il gérer des règles de postes par site avec une consolidation de paie au niveau de l'entreprise ?
• L'export SIF/WPS inclut-il un rapport de validation avant soumission ?
• Les tranches de cotisations sociales et les multiplicateurs d'heures supplémentaires sont-ils configurables sans déploiement de code ?
• Quel est le mécanisme d'intégration ERP — API, fichier ou export manuel ?
• Comment la plateforme gère-t-elle les enregistrements biométriques tardifs provenant de terminaux hors ligne ?
• La provision pour congés est-elle calculée en temps réel et exportable sous forme de poste de bilan ?

Si la réponse à l'une de ces questions est « nous pouvons vous personnaliser ça » sans délai ni tarif, considérez-la comme un refus. Configuration et personnalisation sont deux choses différentes : la première doit être en libre-service, la seconde doit rester l'exception.

Calendrier de déploiement : ce qui est réaliste

Un déploiement pour 200 salariés, 3 sites et une intégration ERP prend généralement 10 à 14 semaines de bout en bout si l'entreprise dispose de données salariés propres. La principale variable est la qualité des données — les entreprises qui géraient la présence sur des systèmes distincts par site passent souvent 3 à 4 semaines rien qu'à normaliser les identifiants salariés et les codes de postes avant que la plateforme puisse aller en production. Prévoyez explicitement ce travail dans le budget ; les prestataires qui annoncent 6 semaines sans vous interroger sur l'état de vos données vous proposent la version simple de votre projet. Le guide de mise en place du logiciel RH détaille la phase de préparation des données si vous vous apprêtez à entrer dans cette étape.

Prêt à en parler ?

Si vous évaluez des plateformes RH pour une organisation multi-sites ou multi-pays et souhaitez une conversation directe sur ce que votre configuration spécifique exige — modèle de données, obligations de conformité, connecteur ERP — l'équipe de ProgMine traite ces questions régulièrement. Envoyez-nous votre configuration actuelle et les problèmes que vous cherchez à résoudre, et nous vous donnerons une lecture honnête de ce qui fonctionnera ou non.