Produit : Papillon HR Suite + ALTARYS ENTERPRISE HR Suite
Périmètre géographique : CI (Côte d'Ivoire) — MVP
Version : 1.0
Date : 25/02/2026
Auteur : ANALYST (Claude Code)
ALTARYS ENTERPRISE développe une plateforme SaaS multi-Tenants pour la gestion des ressources humaines et les finances d'entreprise,
spécialement conçue pour les entreprises opérant dans le cadre juridique de l'OHADA (Organisation pour l'harmonisation en Afrique du droit des affaires) dans 17 États membres.
Les entreprises de la zone OHADA, en particulier les PME, gèrent leurs ressources humaines et leur paie à l'aide de feuilles de calcul Excel, de registres papier registres et des processus manuels. Cela entraîne :
Risque de non-conformité : les actes uniformes de l'OHADA, les normes comptables SYSCOHADA et les codes du travail nationaux imposent des obligations complexes et spécifiques à chaque pays. Les processus manuels entraînent des erreurs dans les déclarations CNPS, les déclarations fiscales et les registres des employés.
Inefficacité opérationnelle : approbation des congés via WhatsApp, suivi des présences sur papier, calcul manuel des fiches de paie dans Excel... Les responsables RH consacrent 60 à 80 % de leur temps à des tâches administratives au lieu de se concentrer sur des tâches stratégiques.
Fragilité des données : pas de piste d'audit, pas de sauvegarde, pas d'intégrité des données. La perte d'un fichier Excel entraîne la perte de l'historique des paies.
Problèmes de connectivité : en Afrique occidentale et centrale, l'internet est intermittent, ce qui signifie que les solutions exclusivement basées sur le cloud ne fonctionnent pas au moment où les employés en ont le plus besoin.
ALTARYS propose deux marques SaaS à partir d'une base de code unique :
Marque
Cible
Employés
Phase
Papillon HR Suite
PME (TPE/PME)
2–350
Phase 1 : mois 1 à 18 (priorité principale)
ALTARYS ENTERPRISE HR Suite
Grandes entreprises (ETI + Grands Comptes)
351–5 000+
Phase 2 : Mois 18+
La plateforme offre 14 fonctionnalités RH/financières modulaires ainsi qu'une base Control Plane non commercialisable, toutes conçues offline-first, mobile-first et conformes à l'OHADA par défaut.
Côte d'Ivoire (CI).
Expansion : Bénin + Cameroun (mois 9), RDC (mois 15), Sénégal (mois 18), puis déploiement progressif dans les autres pays de l'OHADA.
A.2 Architecture à deux marques : pourquoi une base de code unique¶
Décision : ALTARYS exploite deux marques commerciales, mais conserve une base de code backend unique déployée sur différentes infrastructures. Il s'agit d'une décision architecturale fondamentale que toutes les équipes doivent comprendre.
Pourquoi une base de code unique est la bonne solution¶
Préoccupation
Deux bases de code
Base de code unique (choisie)
Correction de bogues
Corriger deux fois, tester deux fois, déployer deux fois
Corriger une fois, tester une fois, déployer partout
Correctif de sécurité
Doubler la surface d'attaque à maintenir
Une surface, un correctif
Développement de fonctionnalités
Décider pour chaque fonctionnalité quelle base de code l'obtient
Construire une fois, contrôler via la configuration
Taille de l'équipe
Développeur solo + petite équipe — la maintenance de 2 bases de code n'est pas viable
Viable avec une petite équipe
Tests
Deux suites de tests, deux pipelines CI
Une suite de tests couvre les deux marques
Cohérence des API
Les API évoluent avec le temps, les modèles de données divergent
Même image Docker / Même JAR Spring Boot
│
├── Déploiement Papillon (infrastructure partagée)
│ └── Base de données partagée, espace de noms Kubernetes partagé
│ └── SLA de 99,5 %, ressources partagées
│
└── Déploiement d'entreprise (infrastructure dédiée)
└── Schéma par Tenant ou base de données par Tenant
└── SLA de 99,9 %, ressources dédiées
└── Cluster potentiellement dédié par Grand Compte
Enterprise -only (consolidation multi-entités, SSO/SAML, chaînes d'approbation avancées, opérations par lots à grande échelle, rôles personnalisés, accès API pour l'intégration ERP) existent dans la même base de code, mais sont contrôlées via le module gating + les indicateurs de marque/niveau sur l'entité Tenant.
La bibliothèque de composants partagés (packages/shared-components/) utilise l'injection de thème : les deux interfaces utilisent les mêmes composants, mais ceux-ci sont rendus différemment en fonction du thème de la marque.
Utilisations : tableaux de bord, approbations (auto-approbations en tant que propriétaire de l'entreprise), rapports de haut niveau
Compétences numériques : Moyenne à élevée
Appareil : ordinateur portable + téléphone
Préoccupation principale : « Mon entreprise est-elle conforme ? Montrez-moi les chiffres. »
Contexte Papillon : souvent propriétaire de l'entreprise (gérant SARL). Peut également être le responsable des ressources humaines dans les très petites entreprises (S1-S2).
Contexte de l'entreprise : PDG professionnel avec des équipes RH/finances dédiées. A besoin de tableaux de bord exécutifs, pas d'écrans opérationnels.
P2 : Responsable RH / Directeur des ressources humaines —¶
Utilisations : dossiers des employés (HR Core), intégration/départ (Employee Mgmt), absences, supervision de la paie
Compétences numériques : moyennes
Appareil : principalement un ordinateur de bureau, un téléphone pour les approbations
Préoccupation principale : « Traiter rapidement les demandes de congé, garantir la conformité OHADA, suivre le cycle de vie des employés. »
Contexte Papillon : souvent le conjoint du directeur général ou un employé de confiance assumant plusieurs fonctions. En transition depuis Excel/papier. A besoin d'une expérience utilisateur accompagnée.
Contexte de l'entreprise : directeur des ressources humaines professionnel gérant une équipe de responsables RH. A besoin d'opérations par lots, de rapports avancés, de workflows de délégation.
Utilisations : lignes budgétaires, engagements, dépenses, comptabilité, lecture des fiches de paie
Compétences numériques : moyennes à élevées (utilise beaucoup Excel)
Appareil : ordinateur de bureau (deux écrans de préférence)
Préoccupation principale : « Conformité SYSCOHADA, équilibre des comptes, piste d'audit. »
Contexte Papillon : souvent un comptable externe (cabinet comptable) gérant 5 à 20 entreprises clientes. ** Nécessite un accès multi-Tenants** via un commutateur de Tenants.
Contexte de l'entreprise : Contrôleur financier interne avec une équipe dédiée.
Utilisations : Demandes de congés, consultation des fiches de paie, pointage à l'arrivée/au départ, consultation de base du profil en libre-service
Compétences numériques : Faibles à moyennes
Appareil : Téléphone Android (souvent d'entrée de gamme, âgé de plus de 8 ans, connectivité intermittente)
Préoccupation principale : « Soumettre facilement ma demande de congé, vérifier mon salaire, consulter mon profil. »
Contexte Papillon : Peut ne pas avoir d'adresse e-mail. Activation du compte par SMS. Nécessite une simplicité absolue.
Contexte de l'entreprise : Meilleure maîtrise du numérique. Dispose d'une adresse e-mail professionnelle. Attend une expérience utilisateur moderne et soignée.
US-PV-001 : Statut spécial du propriétaire de l'entreprise¶
En tant que propriétaire de l'entreprise (gérant/DG),
je souhaite que la plateforme reconnaisse mon statut spécial et me laisse choisir si je suis un employé (salarié) ou indépendant,
afin que la paie, la CNPS et la gestion des congés me traitent correctement.
Critères d'acceptation :
- Étant donné que je suis propriétaire de l'entreprise, lorsque je suis signalé comme indépendant, je n'apparais pas dans la paie, je n'ai pas de fiche de paie et je n'ai pas de solde de congés.
- Étant donné que je suis propriétaire de l'entreprise, lorsque je suis signalé comme salarié, alors je suis également un employé avec un bulletin de paie, des cotisations CNPS et des droits à congés.
- Étant donné que je suis le propriétaire de l'entreprise, lorsqu'une unité organisationnelle n'a pas de responsable attribué, je suis alors l'approbateur de secours pour les employés de cette unité.
En tant qu' employé,
je souhaite télécharger mes propres données (profil, bulletins de paie, historique des congés) au format PDF/ZIP,
afin de pouvoir exercer mon droit à la portabilité des données en vertu de la loi n°2013-450 de la CI.
Critères d'acceptation :
- Étant donné que je suis un employé avec un compte actif, lorsque je navigue vers mon profil, je trouve une option « Exporter mes données ».
- Étant donné que je demande l'exportation des données, lorsque l'exportation est générée, elle inclut mon profil, tous mes bulletins de paie et l'historique de mes congés dans un fichier ZIP téléchargeable.
< 2 secondes pour tout chargement de page sur une connexion 3G
Critique pour l'utilisation mobile en Afrique de l'Ouest
Capacité hors ligne
Navigation complète hors ligne. Écritures simples (pointage, saisie des dépenses, projet de congé) hors ligne. Les approbations et les opérations financières nécessitent une connexion. Les écritures en attente sont synchronisées dans les 30 secondes suivant la reconnexion.
Le CRM interne (CRMMGT) n'est PAS un module destiné aux Tenants. Il s'agit d'un outil interne à ALTARYS utilisé par :
Les commerciaux indépendants d'ALTARYS — vente directe, à la commission
Les sociétés de conseil partenaires — ventes indirectes/recommandations, partage des revenus à hauteur d'environ 10 % avec ALTARYS
ALTARYS et les sociétés partenaires accèdent au CRM en tant que Tenants « opérateurs » spéciaux. Le CRM est gratuit — il s'agit d'un centre de coûts ALTARYS, et non d'un module générateur de revenus. L'accès des partenaires est financé par l'accord de partage des revenus.
Le CRM doit faire la distinction entre les commerciaux directs (modèle à commission) et les sociétés partenaires (modèle de partage des revenus).
Facturation mensuelle disponible pour tous les Tenants.
Facturation annuelle disponible : le Tenant paie pour 12 mois et bénéficie de 14 mois (2 mois gratuits en bonus, PAS une réduction). Il s'agit d'une incitation à la valeur perçue, et non d'une réduction de prix.
Lorsqu'un Tenant désactive un module ou quitte la plateforme, ALTARYS propose un service payant d'archivage : conservation des données pendant toute la période de conformité OHADA de 10 ans dans un stockage à froid. Il s'agit d'une source de revenus supplémentaire.
Tarification pour les entreprises [ENTREPRISES UNIQUEMENT — V2]¶
Tarification personnalisée pour les entreprises à définir au cours des mois 12-13. Non incluse dans ce PRD.
Papillon HR Suite se positionne comme le SaaS RH natif conforme à l'OHADA pour les PME africaines francophones, avec une tarification modulaire, aucune contrainte et une expérience utilisateur mobile-first capable de fonctionner hors ligne.
Conformité native à l'OHADA : comptabilité SYSCOHADA, intégration CNPS/CNSS, code du travail CI intégré — et non ajouté.
Tarification modulaire adaptée aux PME africaines : segments S1-S6 avec tarification en XOF. Pas de dollar américain, pas de tarification par poste pour une entreprise de 5 personnes.
Offline-first : fonctionne en 3G, fonctionne hors ligne. Essentiel en Afrique de l'Ouest.
Mobile-first : conception 360px Android-first. Cibles tactiles de 48px.
Pas de verrouillage : facturation mensuelle, abonnements modulaires, exportation des données disponible.
Priorité au français : interface utilisateur, assistance, documentation, tout en français.
Paiement local : CinetPay (Orange Money, Wave, MTN Mobile Money) — pas seulement les cartes de crédit.
Profil DB : les 4 profils — A (base de données partagée), B (schéma par Tenant), C (base de données par Tenant), D (base de données BYO)
7 modules : plan de contrôle + absences + présence QR + lignes budgétaires (incluses automatiquement avec l'engagement) + engagement + CRM interne + paie
Remarque : les lignes budgétaires s'activent automatiquement car la gestion des engagements est en MVP
Application web : responsive, mobile -first (360px)
PWA : installable sur l'écran d'accueil du téléphone
Hors ligne : navigation complète + écritures sélectives (pointage, saisie des dépenses, projet de congé). Les approbations/opérations financières nécessitent une connexion.
Pièce jointe de document de base : téléchargement/téléversement simple via MinIO (tous les modules)
Application de la conservation de base : conservation OHADA de 10 ans pour les documents de paie/comptabilité, même sans ADVDOC
Paie : génération de fiches de paie et calcul des salaires uniquement. Pas de fichiers d'ordres de paiement.
SMS : passerelle SMS de base pour les liens d'activation de compte/création de mot de passe uniquement
Utilisateur multi-Tenant : connexion unique + sélecteur de Tenant (cas d'utilisation d'un cabinet comptable)
Facturation : mensuelle + annuelle (14 mois pour le prix de 12). Intégration de CinetPay.
Essai gratuit de 14 jours pour les Tenants auto-intégrés
Remarque : les objectifs commerciaux sont ambitieux et peuvent différer des dates de livraison techniques. L'ordre de construction technique (ci-dessus) fait autorité pour la planification du développement.
Ces points doivent être clarifiés avant ou pendant la mise en œuvre :
#
Question
Priorité
Statut
OQ-01
Autorisation de transfert transfrontalier de données ARTCI : l'hébergement se trouve en Europe. Autorisation ARTCI requise en vertu de la loi n °2013-450. Processus non lancé. Potentiellement bloquant pour le MVP.
🔴 CRITIQUE
Non résolu — consultation juridique nécessaire
OQ-02
Calcul de l'ITS (Impôt sur Traitements et Salaires) : Tranches, taux et méthode pour CI non couverts dans la recherche sur la vision de la plateforme. Reporté à la recherche juridique sur le module Paie.
🟡 ÉLEVÉ
Reporté au PRD Paie
OQ-03
Sources primaires des taux de cotisation CNPS : Pension (14 %), PF (5 %), Maternité (0,75 %), AT/MP(2-5 %), CMU (1 000 FCFA) — toutes issues de sources secondaires ou de l'ordonnance de 2012. Nécessite une nouvelle recherche avec les citations du décret actuel.
🟡 ÉLEVÉ
Reporté au PRD Paie
OQ-04
Vérification des plafonds CNPS : 70 000 FCFA/mois (PF/Maternité/AT) et 3 375 000 FCFA/mois (pension) — citation au niveau du décret et clarification nécessaires (plafond sur le salaire de base ou sur le montant de la cotisation ?).
🟡 ÉLEVÉ
Reporté au PRD Paie
OQ-05
Seuils de sélection automatique du profil DB pour la V2 : à partir de quel nombre d'employés les Tenants passent-ils du profil A → B → C ? Nombre d'employés uniquement ou également niveau du plan ?
🟢 MOYEN
Portée de la V2
OQ-06
Tarification du stockage supplémentaire : combien coûte le stockage supplémentaire par Go pour les Tenants qui dépassent leur quota ?
🟢 MOYEN
Décision de tarification nécessaire
OQ-07
Spécificités de la forme juridique SAS : les sociétés SAS ont-elles des obligations sociales ou fiscales différentes de celles des SARL en CI ? Pertinent pour le marché cible.
🟢 MOYEN
Nécessite des recherches
OQ-08
Taxes d'apprentissage et de formation en CI : les taux et les seuils d'applicabilité ne sont pas couverts par la recherche sur la vision de la plateforme.
🟢 MOYEN
Reporté au PRD Paie
OQ-09
Article exact du registre des employés en CI (Registre d'Employeur) : la recherche cite « Art. 18.x » — format provisoire. L'article exact de la loi 2015-532 doit être confirmé.
🟢 MOYEN
Nécessite vérification
OQ-10
Modèle de tarification pour les entreprises : tarification personnalisée pour les segments ETI et Grands Comptes.
🟢 FAIBLE
Mois 12-13
OQ-11
Tarification ADVDOC : tarification du module autonome à déterminer.
Ces éléments sont mis en œuvre tels quels, mais signalés pour vérification ou mise à jour ultérieure :
#
Élément
Valeur actuelle
Risque
Action requise
TV-01
Configuration de l'exercice fiscal
Par défaut, janvier-décembre, mais le Tenant peut personnaliser.
L'OHADA impose l'année civile (AUDCIF Art. 7). Les Tenants qui dérogent à cette règle le font à leurs propres risques en matière de conformité. La plateforme affiche un avertissement.
Confirmation juridique que la plateforme peut autoriser la modification sans engager sa responsabilité.
TV-02
Taux de cotisation CI CNPS (à titre indicatif uniquement — NON prêt à être mis en œuvre)
Chaque Tenant a exactement UN propriétaire d'entreprise pour MVP. Le propriétaire est identifié lors de l'intégration (auto-intégration : la personne qui crée le compte ; CRM/Admin : désigné lors de la création).
FR-PV-002
Le propriétaire de l'entreprise dispose d'un champ owner_employment_status avec deux valeurs : INDEPENDANT (par défaut) ou SALARIE.
FR-PV-003
SI owner_employment_status = INDEPENDANT ALORS le propriétaire est uniquement un utilisateur (et non un employé). Pas de fiche de paie, pas de cotisations CNPS, pas de solde de congés. Il peut approuver les demandes et accéder aux tableaux de bord via son rôle DG.
FR-PV-004
SI owner_employment_status = SALARIE ALORS le propriétaire est ÉGALEMENT créé en tant qu'employé. Il reçoit une fiche de paie, ses cotisations CNPS sont calculées et son solde de congés est suivi.
FR-PV-005
SI une unité organisationnelle n'a pas de responsable attribué, ALORS le propriétaire de l'entreprise est l'approbateur de secours pour les demandes des employés de cette unité (congés, engagements, dépenses).
FR-PV-006
Le propriétaire de l'entreprise approuve lui-même ses propres demandes (congés, dépenses, etc. ). Aucune approbation externe n'est requise pour le MVP.
FR-PV-007
[V2] Prise en charge de plusieurs propriétaires d'entreprise par Tenant (par exemple, SARL avec co-gérants). Chacun peut être indépendamment salarié ou indépendant.
La structure organisationnelle est une arborescence flexible avec une profondeur illimitée. Chaque nœud possède un id, tenant_id, name, type (ENTITY | SITE | DEPARTMENT | CUSTOM), parent_id (FK auto-référencé), status (ACTIVE | INACTIVE), manager_id (FK vers Employee, nullable).
FR-PV-011
Le nœud racine (type=ENTITY) est automatiquement créé lors de l'intégration du Tenant à partir du nom de l'entreprise. Il ne peut être ni supprimé ni désactivé.
FR-PV-012
Lors de l'intégration, le système crée 5 à 6 départements par défaut sous l'entité racine : Direction Générale, Ressources Humaines, Comptabilité, Commercial, Production. L'administrateur du Tenant peut les renommer, les supprimer (désactiver) ou en ajouter d'autres.
FR-PV-013
Aucune suppression définitive des unités organisationnelles. Désactivation uniquement. L'intégrité des données historiques doit être préservée.
FR-PV-014
Chaque employé est affecté à une seule unité organisationnelle (FK). La réaffectation crée un enregistrement historique avec effective_date.
Chaîne d'approbation (basée sur l'unité organisationnelle)¶
Règle
Description
FR-PV-020
Le circuit d'approbation est basé sur l'unité organisationnelle : l'approbateur d'un employé est le manager_id de l'unité organisationnelle à laquelle il est affecté.
FR-PV-021
SI l'unité organisationnelle de l'employé n'a pas de manager_id attribué, ALORS l'approbateur revient au propriétaire de l'entreprise (FR-PV-005 ).
FR-PV-022
SI l'employé EST le responsable de l'unité organisationnelle, ALORS l'approbateur est le manager_id de l'unité organisationnelle parent. Si le parent n'a pas de responsable, le propriétaire de la société est désigné.
FR-PV-023
Le propriétaire de la société (DG) s'approuve lui-même. Ses demandes sont automatiquement approuvées avec le statut SELF_APPROVED et consignées dans la piste d'audit.
FR-PV-024
[V2] Chaînes d'approbation à plusieurs niveaux (N+1 → N+2 → DG, en fonction des seuils de montant). Organisations matricielles (responsable fonctionnel + hiérarchique). Délégation du pouvoir d'approbation.
Le plan de contrôle suit les abonnements aux modules par Tenant dans un tableau tenant_modules : tenant_id, module_code, status (ACTIVE | INACTIVE | TRIAL), activated_date, deactivated_date.
Modules non vendables inclus automatiquement : BUDMGT (s'active lorsque EXPMGT OU COMMIT est ACTIF ; se désactive uniquement lorsque AUCUN des deux n'est ACTIF).
FR-PV-033
Le plan de contrôle et les données de base organisationnelles sont toujours actifs. Jamais bloqués.
FR-PV-034
Contrôle au niveau de l'API : chaque point de terminaison API vérifie si le Tenant demandeur dispose du module requis ACTIF. SI le module est INACTIF, renvoyer HTTP 403 avec le message « Module non souscrit ».
FR-PV-035
Contrôle au niveau du frontend : les éléments de navigation pour les modules non souscrits sont masqués ou affichés sous forme d'« invites de mise à niveau » (opportunité de vente incitative).
FR-PV-036
SI ADVDOC est ACTIF, TOUS les modules passent automatiquement en mode versionné avec conservation des données.
FR-PV-037
SI EMPMGT est ACTIF mais HRCORE est INACTIF, la gestion des employés fonctionne sur l'entité employé de base CP (ensemble de fonctionnalités réduit mais fonctionnel).
SI un Tenant désactive un module précédemment actif, les données du module deviennent en lecture seule pendant 6 mois.
V2
* FR-PV-041*
Pendant la période de 6 mois en lecture seule, le Tenant a la possibilité d'exporter les données du module (CSV/Excel/ZIP).
V2
FR-PV-042
Après 6 mois, les champs enrichis sont masqués dans l'interface utilisateur. Les données sont conservées dans la base de données mais invisibles pour le Tenant.
* V2*
FR-PV-043
ALTARYS propose un service payant d'archivage des données : conservation des données dans un stockage à froid pendant toute la période de conformité OHADA de 10 ans. Si le Tenant souscrit à ce service, les données restent conservées dans le stockage à froid.
V2
*FR-PV-044 *
SI le Tenant n'achète PAS le service d'archivage ET que la période de lecture seule de 6 mois est écoulée, ALORS les données sont automatiquement archivées dans un stockage à froid (elles ne sont pas supprimées). ALTARYS les conserve pour se conformer à l'OHADA, mais elles ne sont pas accessibles au Tenant sans réabonnement ou achat du service d'archivage.
V2
Comportement MVP : dans MVP, la désactivation d'un module le définit immédiatement comme INACTIVE. Les données du module sont conservées dans la base de données, mais ne sont pas accessibles via l'interface utilisateur. La période de 6 mois READONLY_GRACE, l'état HIDDEN et le service d'archivage (FR-PV-040 à FR-PV-044) sont tous en V2.
L'administrateur du Tenant peut importer en masse des employés via le téléchargement d'un fichier Excel.
FR-PV-051
Après le téléchargement, le système analyse le fichier Excel et affiche un tableau de confirmation modifiable présentant tous les employés importés. L'administrateur peut modifier n'importe quel champ directement dans le tableau avant de valider.
FR-PV-052
Pour chaque employé du tableau, l'administrateur doit sélectionner un mode de contact préféré : E-MAIL ou SMS. Cette étape est obligatoire, car certains employés ne disposent pas d'adresse e-mail.
FR-PV-053
Lors de la soumission : le système crée des enregistrements d'employés, crée des comptes d'utilisateurs et envoie des liens de création de mot de passe via le canal sélectionné (e-mail ou SMS) pour chaque employé.
FR-PV-054
Les liens de création de mot de passe par SMS nécessitent l'intégration d'une passerelle SMS de base (voir FR-PV-080).
L'application est entièrement navigable hors ligne (PWA + Service Worker pour l'application shell, IndexedDB pour le cache de données).
FR-PV-061
Écritures hors ligne (mises en file d'attente dans IndexedDB, synchronisées lors de la reconnexion dans les 30 secondes) : pointage d'arrivée/de départ, saisie/brouillon de dépenses, brouillon de demande de congé, affichage du profil de l'employé.
FR-PV-062
Opérations en ligne uniquement : actions d'approbation (approbation de congés, approbation d'engagements), opérations financières (calcul des salaires, réservation budgétaire), activation/désactivation de modules, gestion des utilisateurs, opérations de facturation.
FR-PV-063
Un indicateur d'état de synchronisation est toujours visible dans l'interface utilisateur.
FR-PV-064
Enregistrement automatique dans tous les champs du formulaire. Aucune perte de données en cas de perte de connexion.
Une même personne peut être utilisateur de plusieurs Tenants simultanément (par exemple, un comptable externe gérant 5 entreprises clientes).
FR-PV-071
Une adresse e-mail/un numéro de téléphone = un compte Keycloak. L'utilisateur se connecte une seule fois et voit apparaître un sélecteur de Tenant répertoriant tous les Tenants auxquels il appartient.
FR-PV-072
L'utilisateur peut passer d'un Tenant à l'autre dans l'application sans avoir à se réauthentifier. Le JWT est réémis avec le tenant_id sélectionné.
FR-PV-073
Les rôles et les autorisations sont par Tenant : un utilisateur peut être comptable dans le Tenant A et employé dans le Tenant B.
Notifications dans l'application via WebSocket (en temps réel lorsque l'utilisateur est en ligne, mises en file d'attente pour une livraison hors ligne).
FR-PV-076
Notifications par e-mail pour les actions critiques (congés approuvés/refusés, paie prête, avertissements d'expiration de CDD, activation de compte).
FR-PV-077
Les préférences de notification sont contrôlées par l'administrateur pour MVP : l'administrateur du Tenant configure les événements qui déclenchent les notifications par e-mail/dans l'application pour chaque rôle.
FR-PV-078
[V2] Préférences de notification au niveau des employés (activation/désactivation par type de notification).
MVP intègre une passerelle SMS de base (Twilio, Orange SMS API ou fournisseur CI local) pour les liens d'activation de compte/création de mot de passe uniquement.
** FR-PV-081**
La même infrastructure de passerelle SMS est réutilisée pour les SMS de notification générale dans la V2. Le travail de la V2 consiste à créer le moteur de préférences de notification et les déclencheurs événementiels, et non la plomberie SMS.
FR-PV-082
[V2] Notifications SMS générales (congés approuvés, paie prête, etc.) utilisant la même passerelle.
La conservation de base OHADA est TOUJOURS appliquée, quel que soit le statut du module ADVDOC : les documents de paie et les documents comptables ne peuvent pas être supprimés avant 10 ans (exigence AUDCIF).
FR-PV-091
Les entrées de la piste d'audit sont immuables : elles ne peuvent être ni supprimées ni modifiées. Elles sont conservées pendant au moins 10 ans.
Règle
Description
FR-PV-095
Tous les employés peuvent consulter un profil de base en lecture seule affichant les données de référence du plan de contrôle : nom, e-mail, téléphone, service, poste, type de contrat, responsable, date d'embauche. Ce profil est disponible quel que soit le statut du module HR Core.
FR-PV -096
SI HR Core est ACTIF, alors la vue du profil est enrichie avec : les coordonnées personnelles, les contacts d'urgence, la photo, les informations bancaires, les pièces jointes, l'historique des modifications.
L'exercice fiscal est par défaut de janvier à décembre (année civile) pour tous les Tenants de la zone OHADA.
FR-PV-101
Les Tenants peuvent personnaliser le mois de début de l'exercice fiscal. SI un Tenant remplace la valeur par défaut, ALORS la plateforme affiche un avertissement : « L'OHADA (AUDCIF Art. 7) impose une clôture fiscale à la fin de l'année civile (31 décembre). Le non-respect de cette exigence peut entraîner des risques de non-conformité. »
FR-PV-102
L'avertissement est consigné dans la piste d'audit. Le Tenant assume la responsabilité de la conformité pour les exercices financiers non calendaire.
Lors de l'intégration d'un Tenant, le système effectue une recherche approximative sur : le nom de l'entreprise (flou), le pays et l'adresse e-mail de l'administrateur.
FR-PV-106
SI un doublon potentiel est détecté, l'intégration n'est PAS bloquée. Au lieu de cela, la correspondance est signalée pour examen par l'administrateur ALTARYS dans la console d'administration.
FR-PV-107
L'administrateur ALTARYS peut fusionner, lier ou rejeter les doublons signalés.
Le RCCM (Registre du Commerce et du Crédit Mobilier) est facultatif lors de l'intégration.
FR-PV-111
SI le RCCM n'est pas fourni dans les 3 mois suivant l'activation, le statut du Tenant devient ACTIVE_INCOMPLETE et le compte + les modules souscrits deviennent en lecture seule -only jusqu'à ce que le RCCM soit fourni.
FR-PV-112
Ce délai de grâce correspond au statut ACTIVE_INCOMPLETE défini dans le cycle de vie du Tenant (voir §B.2).
stateDiagram-v2
[*] --> ACTIF : Employé créé (intégré)
ACTIF --> EN CONGÉ : Début de la période de congé
ACTIF --> SUSPENDU : Suspension administrative
ACTIF --> RÉSILIÉ : Départ/résiliation
EN CONGÉ --> ACTIF : Fin de la période de congé
EN CONGÉ --> RÉSILIÉ : Résiliation pendant le congé
SUSPENDU --> ACTIVE : Levée de la suspension
SUSPENDED --> TERMINATED : Licencié pendant la suspension
TERMINATED --> [*] : État final (données conservées)
stateDiagram-v2
[*] --> INACTIVE : Module non acheté
INACTIF --> ESSAI : Essai commencé
INACTIF --> ACTIF : Module acheté
ESSAI --> ACTIF : Payé après l'essai
ESSAI --> INACTIF : Essai expiré
ACTIF --> READONLY_GRACE : Module désactivé (délai de grâce de 6 mois) [V2]
ACTIF --> ACTIF : Renouvelé
READONLY_GRACE --> HIDDEN : 6 mois écoulés [V2]
HIDDEN --> ACTIVE : Réactivé (données restaurées et visibles) [V2]
Remarque V2 : READONLY_GRACE et HIDDEN ne sont pas disponibles dans MVP. Dans MVP, la désactivation d'un module le ramène immédiatement à l'état INACTIVE (données conservées dans la base de données mais inaccessibles). La période de grâce de 6 mois et les états de données masquées sont des fonctionnalités de la V2.
Modèle de données à trois niveaux pour les employés¶
Niveau 1 — Plan de contrôle (toujours présent) :
Employé de base : nom, prénom, e-mail, téléphone, numéro d'employé,
type_de_contrat_id (FK), org_unit_id (FK), position_id (FK),
category_id (FK ou dérivé de Position→Catégorie),
date_d'embauche, statut (ACTIF | EN CONGÉ | SUSPENDU | LICENCIÉ),
contact_préféré (EMAIL | SMS)
↓ Suffisant pour que les fonctions Absence, Présence et Paie fonctionnent.
↓ MVP Payroll utilise uniquement cette couche.
Couche 2 — HR Core (facultatif, vendable) :
Enrichi : date_of_birth, nationality, national_id_number,
marital_status, dependents_count, photo, emergency_contacts[],
bank_info (bank_name, account_number, IBAN),
current_contract_snapshot (start, end, probation_end, salary, grade),
pièces jointes[], historique des modifications[]
↓ Dossier du personnel complet
↓ Post-MVP : les informations bancaires permettent les ordres de paiement de la paie.
Couche 3 — Gestion des employés (facultative, vendable) :
Couche de processus : événements d'intégration[], événements de départ[],
historique des contrats[], historique des réaffectations[],
suivi de la période d'essai, suivi du renouvellement des CDD,
chronologie des événements immuables[], exportations de conformité
↓ « Actes administratifs » — gestion formelle des processus RH
Colonne tenant_id dans chaque table. Chaque requête inclut WHERE tenant_id = ?.
Isolation du schéma. Les requêtes ne nécessitent pas de filtre tenant_id (le schéma EST le filtre).
Isolation complète de la base de données. Pool de connexions par Tenant.
Le Tenant fournit la connexion. Isolation complète.
Contrôle des modules
Table tenant_modules dans la base de données partagée.
Même table dans le schéma du Tenant.
Même table dans la base de données du Tenant.
Même table dans la base de données du Tenant.
Configuration du pays
Table à l'échelle de la plateforme (pas au niveau du Tenant). Tous les Tenants lisent à partir de la même configuration.
Identique — table à l'échelle de la plateforme dans un schéma partagé.
Identique — base de données de la plateforme, pas base de données du Tenant.
Identique — base de données de la plateforme.
Piste d'audit
Lignes au niveau du Tenant dans la table d'audit partagée.
Table d'audit par schéma.
Table d'audit par base de données.
Table d'audit par base de données.
Données organisationnelles et données de référence
Lignes au niveau du Tenant.
Tables par schéma.
Tables par base de données.
Tables par base de données.
Utilisateur multi-Tenant
Table de mappage utilisateur→Tenant. JWT réémis à chaque changement de Tenant.
L'utilisateur existe dans la base de données de la plateforme. Le changement de Tenant modifie le contexte du schéma.
L'utilisateur existe dans la base de données de la plateforme. Le changement de Tenant modifie la connexion à la base de données.
Identique.
Principe de conception : concevez d'abord pour BYO-DB (cas le plus difficile), puis simplifiez. Le modèle de données doit fonctionner sans dépendre des JOIN entre Tenants.
Détaillé dans §A.7 (événements et dépendances API). Principes clés :
Les limites des modules Spring sont sacrées : les modules communiquent via des événements d'application pour les opérations asynchrones et via l'API REST pour les lectures synchrones. Ne jamais effectuer d'appels de méthode directs au-delà des limites des modules.
Les noms d'événements sont des contrats : modifier le nom ou la charge utile d'un événement constitue une modification majeure. Les schémas d'événements doivent être versionnés.
Les points de terminaison API sont des contrats : le backend sert à la fois les frontends Papillon et Enterprise. Les points de terminaison doivent être indépendants de l'interface utilisateur : ils doivent renvoyer des données, pas une présentation.
Le contrôle des modules est appliqué au niveau de l'API : chaque point de terminaison vérifie TenantContext pour l'activation du module avant le traitement.
L'OHADA fournit un *droit commercial supranational * via 11 actes uniformes. Actes clés pour ALTARYS :
Acte uniforme
Pertinence
Impact sur la plateforme
AUDCIF (Comptabilité)
Cadre comptable révisé SYSCOHADA (2017). Plan comptable obligatoire. Clôture de l'année civile.
Données de base du module comptable. Exercice fiscal par défaut janvier-décembre. Conservation des documents pendant 10 ans.
* AUSCGIE* (Sociétés commerciales)
Formes de sociétés (SARL, SAS, SA, EI). Seuils pour les commissaires aux comptes.
Champ « forme de société » du Tenant. Implications pour la catégorie des employés.
AUPSRVE (Recouvrement de créances)
Règles de saisie sur salaire.
Règles de retenue sur salaire (V2).
Critique : l'OHADA *
PAS* harmonise le droit du travail. Chaque pays a son propre Code du travail, son propre système de sécurité sociale et ses propres règles fiscales. La plateforme doit être configurable par pays, et non uniforme pour l'OHADA.
Loi* : Loi n°2013-450 relative à la protection des données à caractère personnel
Autorité : ARTCI (Autorité de Régulation des Télécommunications/TIC de Côte d'Ivoire)
Transfert transfrontalier : nécessite l'autorisation formelle de l'ARTCI pour les données hébergées en dehors de la CEDEAO
Droits des employés : droit d'accès, de rectification et de portabilité des données personnelles
Implications pour la plateforme :
🔴 ACTION CRITIQUE : l'autorisation de l'ARTCI pour le transfert transfrontalier de données N'A PAS ENCORE ÉTÉ DEMANDÉE. L'hébergement est prévu en Europe. Cela pourrait bloquer le MVP. Une consultation juridique est nécessaire immédiatement.
La fonctionnalité d'auto-exportation des employés (FR-PV-092) répond au droit à la portabilité.
Une politique de confidentialité et des accords de traitement des données doivent être mis en place.
CI Sécurité sociale (à titre indicatif uniquement — NON prêt à être mis en œuvre)¶
⚠️ Les taux suivants sont fournis à titre informatif uniquement. Ils proviennent de sources secondaires (Cleiss.fr) et d'une ordonnance de 2012. Ils DOIVENT faire l'objet de nouvelles recherches avec des citations de décrets primaires avant la mise en œuvre du module Paie.
Cotisation
Taux
Part de l'employeur
Part de l'employé
Plafond
Retraite
14 %
7,7 %
6,3 %
3 375 000 FCFA/mois
Prestations familiales (PF)
5 %
5 %
0 %
70 000 FCFA/mois
Maternité
0,75 %
0,75 %
0 %
70 000 FCFA/mois
Accidents du travail (AT/MP)
2-5 %
2-5 %
0 %
70 000 FCFA/mois
CMU (Santé)
1 000 FCFA/personne
500 FCFA
500 FCFA
Forfait
Source : Cleiss.fr, barèmes CNPS CI, ordonnance n°2012-03. [À TITRE INDICATIF UNIQUEMENT — source non vérifiée, à confirmer auprès de la CNPS CI avant la mise en service de la paie]
ITS (Impôt sur Traitements et Salaires) : tranches et taux NON couverts par la recherche sur la plateforme. Renvoyé à la recherche juridique du module Paie.
** Identifiant fiscal** : format IDU (Identifiant Unique) pour les entreprises CI.
Plan comptable standard applicable dans les 17 États membres de l'OHADA.
Préconfiguré lors de l'intégration du Tenant dans le cadre de la configuration du pays.
Principales classes de comptes pour les RH/la paie : classe 6 (charges), en particulier les comptes 64x (frais de personnel) et 66x (cotisations sociales).
L'exercice fiscal DOIT se terminer le 31 décembre conformément à l'article 7 de l'AUDCIF (voir TV-01 pour la décision de remplacement de la plateforme).
Keycloak (OIDC/OAuth2). E-mail + mot de passe pour MVP. SSO/SAML pour Enterprise V2.
Revendications JWT
user_id, tenant_id,country_code, roles[]. Rôles uniquement dans JWT — autorisations résolues côté serveur et mises en cache par session.
Isolation des Tenants
Chaque requête de base de données inclut le contexte du Tenant. Le filtre Spring Security extrait tenant_id de JWT et définit TenantContext. Aucune fuite de données entre Tenants.
Modèle d'autorisation
RBAC : mappage rôle → autorisation. Format d'autorisation : module.entity.action (par exemple, absence.leave_request.approve). Contrôle par module : autorisation refusée si le module est inactif.
Rôles par défaut
DG, RH Manager, Comptable, Employé, Manager (attribués lors de l'intégration). Rôles personnalisés dans la version 2.
Piste d'audit
Chaque création/mise à jour/suppression génère une entrée d'audit immuable. Valeurs avant/après au format JSON. Conservées pendant 10 ans.
Chiffrement
HTTPS partout. Données au repos chiffrées (PostgreSQL TDE ou chiffrement du disque).
CAPTCHA
Requis sur point de terminaison public d'auto-intégration. Limitation du débit sur tous les points de terminaison publics.
Données financières
BigDecimal UNIQUEMENT pour tous les calculs financiers. Jamais double/flottant.
Politique en matière de mots de passe
Minimum 8 caractères, majuscules et minuscules + chiffres. Géré par Keycloak.
Gestion des sessions
Expiration JWT (configurable, 1 heure par défaut). Jetons d'actualisation.
Basé sur une base de données (non codé en dur) — l'administrateur peut effectuer des mises à jour sans redéploiement
Versionné par exercice fiscal
Stocke : barèmes fiscaux, taux de cotisations sociales, droits à congés, jours fériés, plan comptable SYSCOHADA, catégories par défaut, types de contrats par défaut
Performance et objectifs (PERFOB) : évaluations, commentaires, indicateurs clés de performance
Compétences et GPEC (GPEC) : cadre de compétences, analyse des écarts, planification de la relève
Apprentissage et formation (LTRAIN) : catalogue de formations, sessions, budgets
Recrutement/ATS (ATSMGT) : offres d'emploi, pipeline de candidats, embauche
14. Gestion avancée des documents (ADVDOC) — Post-MVP¶
Moteur de documents à l'échelle de la plateforme (backend MinIO)
Gestion des versions, politiques de conservation, gestion du cycle de vie, recherche avancée
Améliore les fonctionnalités de base de tous les modules en matière de pièces jointes lorsqu'il est actif
Prix : à déterminer (module vendable séparément)
*Ce PRD+FSD a été produit par la personnalité ANALYST sur la base d'un entretien exhaustif avec le Business Analyst/Product Owner. Il sert de référence fondamentale pour TOUS les PRD, documents d'architecture et spécifications de conception ultérieurs au niveau des modules. *
Tous les PRD au niveau des modules doivent faire référence à ce document pour : l'infrastructure partagée, les événements inter-modules, les conventions de modèle de données, la segmentation des Tenants, la logique de la chaîne d'approbation, la stratégie hors ligne et le cadre réglementaire.