SMART PEOPLE — Cahier des charges

Plateforme de pilotage People & Culture de Smart Energy (groupe Eranove)
Spécifications fonctionnelles et techniques — Django · Angular · hébergement cPanel o2switch

Lecture rapide. Les sections 1 à 4 donnent la vision d’ensemble (une heure de lecture pour un DG). La section 5 détaille chaque module, fonctionnalité par fonctionnalité, avec ses règles de gestion. Les sections 6 à 8 décrivent les interfaces, les exigences de qualité et l’architecture technique. Les sections 9 à 11 portent le planning, la recette et les risques. Les annexes rassemblent les paramètres légaux ivoiriens, les indicateurs et les échelles.

Plan du document

1. Contexte et enjeux
2. Objectifs, périmètre et principes directeurs
3. Acteurs, profils et droits d’accès
4. Architecture fonctionnelle
5. Spécifications fonctionnelles détaillées (modules M0 à M9)
6. Interfaces et reprise des données
7. Exigences non fonctionnelles
8. Spécifications techniques
9. Lotissement, planning et charge
10. Recette et critères d’acceptation
11. Gouvernance, prérequis et risques
12. Annexes (glossaire, paramètres légaux, indicateurs, échelles, calendrier, modèles, sources, 90 premiers jours)

1. Contexte et enjeux

1.1 Les acteurs

Smart Energy est la société du groupe Eranove spécialisée dans l’énergie solaire et l’efficacité énergétique. Elle compte environ 44 collaborateurs et prévoit une croissance de ses effectifs dans les 18 prochains mois : ingénieurs, chefs de projet, techniciens d’installation et de maintenance sur sites, commerciaux et fonctions support.

GS2E, autre société du groupe Eranove, assure déjà pour Smart Energy, en externalisé, l’administration du personnel et la paie. Cette organisation reste en place : la paie continue d’être produite par GS2E.

Le poste de People & Culture Manager s’ouvre en interne chez Smart Energy. Il marque le passage d’une gestion administrative (externalisée) à une fonction RH stratégique portée dans l’entreprise : compétences, performance, recrutement, fidélisation des talents, conformité sociale, climat et culture, et pilotage par les indicateurs auprès du Directeur Général.

1.2 Le problème à résoudre

Aujourd’hui, l’information RH de Smart Energy est principalement tenue pour les besoins de la paie. Elle ne répond pas aux questions qu’un P&C Manager doit traiter dès sa prise de poste :

• Quelles compétences chaque poste exige-t-il, à quel niveau, et où sont les écarts ?
• Les objectifs de l’année sont-ils fixés, suivis, évalués de façon équitable ?
• Où en est chaque recrutement, et combien de temps prend-il ?
• Qui sont les personnes clés, et risque-t-on de les perdre ?
• Sommes-nous en règle (contrats, CNPS, CMU, médecine du travail, congés, instances représentatives, CSST) ?
• Comment va le climat social ?
• Quels chiffres présenter au DG, chaque mois, en une page ?

1.3 Un seuil à franchir pendant le projet

La croissance prévue fera passer l’effectif au-delà de 50 salariés. En Côte d’Ivoire, ce seuil déclenche des obligations nouvelles qu’il faut anticiper :

L’application surveille ces seuils et prévient le P&C Manager avant qu’ils ne soient franchis (voir INS-01, section 5.6.6).

1.4 Le contexte réglementaire bouge

Le 15 avril 2026, le Gouvernement a adopté 11 décrets d’application du Code du travail (préavis, règlement intérieur, registre d’employeur, temps partiel, services de santé au travail, conventions collectives, etc.). D’autres textes récents (période d’essai, délégués du personnel, obligations déclaratives, décrets de 2024 en vigueur depuis février 2025) modifient aussi les règles. Toutes les durées, taux et seuils légaux sont donc des paramètres datés de l’application, et non des valeurs écrites dans le code (voir annexe B).

1.5 Une exigence de confidentialité particulière

Le porteur du projet travaille aujourd’hui chez GS2E, prestataire de paie de Smart Energy. Les données des salariés de Smart Energy dont il a connaissance à ce titre relèvent du contrat d’externalisation. Avant la prise de poste, l’application est construite et démontrée uniquement avec des données fictives. La reprise des données réelles intervient après la nomination, avec l’accord de la Direction générale et dans le cadre défini avec GS2E (voir section 6.3 et 11.2).

2. Objectifs, périmètre et principes directeurs

2.1 Objectifs

2.2 Ce que couvre l’application

2.3 Hors périmètre

• Le calcul de la paie et les déclarations sociales elles-mêmes : ils restent chez GS2E. L’application échange avec GS2E (export des variables RH, import des données de paie pour le pilotage) et suit que les déclarations ont été faites.
• La comptabilité, la gestion des notes de frais et des déplacements.
• Le pointage biométrique ou la géolocalisation des techniciens (traitements soumis à formalités spécifiques auprès de l’ARTCI).
• Une plateforme d’e-learning (l’application gère le plan de formation, pas la diffusion de cours).

2.4 Principes directeurs

1. Une donnée, une source. La paie reste la source des montants payés ; l’application est la source des données RH (postes, compétences, évaluations, conformité). Aucune double saisie entre les deux : des échanges de fichiers normalisés.
2. Paramétrable sans développement. Taux, durées, seuils, échelles, formulaires, étapes de recrutement, modèles de documents et de courriels se règlent dans l’administration.
3. Confidentialité dès la conception. Chaque donnée a un niveau de sensibilité ; chaque profil voit seulement son périmètre ; les accès aux données sensibles sont journalisés ; l’anonymat des enquêtes est garanti par construction.
4. Pensé pour le terrain. Les managers et techniciens sont souvent sur chantier : interface responsive, utilisable sur téléphone en 4G, actions courantes en trois gestes au plus.
5. Aide à la décision, pas décision automatique. Les scores (risque de départ, écarts, notes) éclairent le P&C Manager et le DG ; aucune décision n’est prise automatiquement sur un salarié.
6. Tout est tracé. Validations, modifications et signatures sont horodatées et attribuées.
7. Dimensionné pour grandir. Jusqu’à 150 collaborateurs et plusieurs sites sans changement d’architecture ; multi-société possible (autre filiale du groupe) par paramétrage.

3. Acteurs, profils et droits d’accès

3.1 Profils utilisateurs

3.2 Périmètres de données

Chaque droit s’exerce sur un périmètre :

Un manager absent peut déléguer ses validations à un autre manager pour une période donnée ; la délégation est tracée.

3.3 Niveaux de sensibilité des données

Secret médical. L’application ne contient aucun diagnostic : seulement les dates de visite, le type de visite et la conclusion d’aptitude (apte, apte avec restrictions, inapte temporaire, inapte), avec, le cas échéant, la restriction de poste formulée en termes non médicaux par le médecin du travail.

3.4 Matrice des droits

Légende : G gérer (créer, modifier, supprimer) · V valider · L lire · — aucun accès. Le périmètre est indiqué entre parenthèses.

4. Architecture fonctionnelle

4.1 Carte des modules

4.2 Le fil conducteur : le poste

Le poste est la pièce centrale qui relie les modules :

• le référentiel (M1) dit ce que le poste exige (compétences, niveaux, habilitations) ;
• l’évaluation (M2) mesure le niveau réel du titulaire et calcule les écarts ;
• la performance (M3) fixe les objectifs du titulaire et évalue ses résultats ;
• le recrutement (M4) part de la fiche de poste et évalue les candidats sur ses compétences ;
• les talents (M5) repèrent les postes critiques et leurs successeurs ;
• la conformité (M6) vérifie les habilitations et la périodicité des visites médicales propres au poste ;
• le tableau de bord (M8) consolide le tout par direction, site et catégorie.

4.3 Le cycle annuel RH outillé

En continu : recrutements et intégrations, échéances de conformité, instances (délégués du personnel chaque mois, CSST chaque trimestre), tableau de bord mensuel.

5. Spécifications fonctionnelles détaillées

Conventions. Chaque fonctionnalité porte un identifiant (ex. REF-04), une priorité et un lot de livraison.

Les règles de gestion sont numérotées RG-<module>-nn. Toute valeur chiffrée suivie de (param.) est un paramètre modifiable dans l’administration.

5.0 M0 — Socle : organisation, postes et dossiers collaborateurs

Objectif. Disposer d’une image exacte et à jour de l’organisation et de chaque collaborateur, base de tous les autres modules.

Fonctionnalités

Règles de gestion

• RG-ORG-01 Un poste a au plus un titulaire principal à une date donnée (intérim possible, tracé comme affectation temporaire).
• RG-ORG-02 Le lien hiérarchique d’un collaborateur est porté par son poste : changer le N+1 d’un poste change celui de son titulaire.
• RG-ORG-03 Une structure ou un poste ne se supprime pas s’il a un historique : il se clôture à une date.
• RG-COL-01 Le matricule est unique et identique à celui de GS2E (clé de rapprochement des échanges).
• RG-COL-02 Une sortie n’est enregistrable qu’avec un motif codifié (démission, fin de CDD, licenciement, rupture en période d’essai, retraite, décès, autre) ; elle déclenche l’entretien de sortie (M5) et la checklist de départ (restitution du matériel et des EPI, solde de tout compte via GS2E, certificat de travail).
• RG-COL-03 Les modifications de données C2/C3 sont historisées (ancienne valeur, nouvelle valeur, auteur, date).

5.1 M1 — Référentiel des compétences : conduire l’étude

Objectif. Outiller toute l’étude de construction du référentiel — du cadrage jusqu’à la publication — puis sa mise à jour. C’est le module qui transforme des interviews en un référentiel validé, opposable et utilisable par les autres modules.

Déroulé de l’étude

Fonctionnalités

Exemples de compétences métier à valider pendant l’étude : dimensionnement d’installations photovoltaïques ; installation et raccordement (AC/DC) ; mise en service et maintenance des onduleurs et batteries ; audit énergétique ; supervision et monitoring à distance ; conduite de projets EPC ; sécurité électrique (habilitation) ; travail en hauteur ; relation client B2B et avant-vente technique ; achats et logistique de chantier.

Règles de gestion

• RG-REF-01 Un emploi est « couvert » quand au moins 1 titulaire et 1 manager (param.) ont été interviewés.
• RG-REF-02 Une compétence n’est publiable que si elle a une définition et un indicateur observable pour chacun des niveaux 1 à 4.
• RG-REF-03 Un poste compte de préférence 8 à 15 compétences (param.) ; au-delà ou en deçà, avertissement (non bloquant).
• RG-REF-04 Modifier un référentiel publié crée une nouvelle version ; les évaluations restent rattachées à la version en vigueur au lancement de leur campagne.
• RG-REF-05 Les notes brutes d’interview ne sont visibles que du P&C (et de l’interviewer s’il est différent) ; les managers ne voient que les synthèses consolidées.
• RG-REF-06 Une habilitation réglementaire requise par un poste (ex. habilitation électrique) est reprise automatiquement dans le suivi de conformité (M6).

5.2 M2 — Évaluation des compétences, écarts et développement

Objectif. Pour chaque poste : ce qu’il faut savoir (référentiel), le niveau réel de chaque titulaire, les écarts, et les actions pour les combler (plans de développement individuels, plan de formation).

Fonctionnalités

Règles de gestion

• RG-EVC-01 Échelle de niveaux : 0 Non acquis · 1 Notions · 2 Pratique · 3 Maîtrise · 4 Expertise (annexe D).
• RG-EVC-02 Le niveau retenu est celui du manager après consolidation ; en cas de désaccord persistant, le P&C arbitre et l’historique conserve les trois valeurs.
• RG-EVC-03 Taux de couverture du poste = Σ (min(niveau retenu, niveau requis) × criticité) ÷ Σ (niveau requis × criticité).
• RG-EVC-04 Un écart est critique quand il porte sur une compétence de criticité 3 et vaut au moins 2 niveaux ; tout écart critique exige une action dans le PDI.
• RG-EVC-05 Une compétence est rare en interne quand moins de 2 collaborateurs (param.) la détiennent au niveau requis ; elle alimente l’analyse des postes critiques (M5).
• RG-HAB-01 Un collaborateur dont une habilitation requise par son poste est expirée apparaît « non conforme » au tableau de conformité ; son manager en est informé.

5.3 M3 — Performance : objectifs, entretiens, résultats

Objectif. Un cycle annuel complet, du cascadage des objectifs de l’entreprise jusqu’à la calibration des notes et à leur traduction en rémunération variable (calculée par GS2E).

Cycle de la campagne

Fonctionnalités

Règles de gestion

• RG-PERF-01 La somme des pondérations des objectifs d’un collaborateur vaut exactement 100 % ; sinon la fiche ne peut pas être validée.
• RG-PERF-02 Atteinte d’un objectif quantitatif : 0 % sous le seuil minimum ; 100 % à la cible ; interpolation linéaire entre les deux ; au-delà de la cible, interpolation jusqu’à 120 % (param.) au seuil d’excellence. Pour un indicateur « moins = mieux » (délai, coût), le sens est inversé. Un objectif qualitatif est noté sur l’échelle 1–5 par le manager.
• RG-PERF-03 Note globale = 70 % × score objectifs + 30 % × note comportements (pondérations param.), convertie sur l’échelle : 1 Insuffisant · 2 À améliorer · 3 Conforme aux attentes · 4 Supérieur aux attentes · 5 Exceptionnel.
• RG-PERF-04 Un collaborateur entré après le 30 septembre (param.) n’est pas noté sur l’année : son entretien porte sur l’intégration.
• RG-PERF-05 Toute modification de note en calibration conserve la note d’origine, la note finale, l’auteur et le motif.
• RG-PERF-06 Un entretien signé est figé (PDF horodaté) ; toute correction ultérieure crée un avenant signé à son tour.
• RG-PERF-07 Les notes et propositions de rémunération sont des données C3 : invisibles des autres collaborateurs et des managers hors ligne hiérarchique.

5.4 M4 — Recrutement et intégration (onboarding), avec suivi des délais

Objectif. Piloter chaque recrutement depuis le besoin jusqu’à la fin de la période d’essai, en mesurant les délais à chaque étape.

Processus et délais cibles

Les délais affichés sont des valeurs par défaut (param.), réglables par type de poste.

Fonctionnalités — recrutement

Fonctionnalités — pré-intégration et intégration

Règles de gestion

• RG-REC-01 Délai de pourvoi (time to fill) = date d’acceptation de l’offre − date de validation de la demande ; délai d’embauche (time to hire) = date d’acceptation − date de candidature. Jours calendaires.
• RG-REC-02 Le chronomètre d’une étape démarre à l’entrée dans l’étape et s’arrête à sa sortie ; un recrutement suspendu (gel validé par le DG) arrête tous les chronomètres.
• RG-REC-03 Les candidatures non retenues sont conservées 24 mois (param.) puis anonymisées, sauf accord du candidat pour une durée plus longue.
• RG-ONB-01 Période d’essai (décret n° 2024-900) : durée maximale selon la catégorie — 8 jours (payés à l’heure ou à la journée), 1 mois (payés au mois), 2 mois (agents de maîtrise, techniciens), 3 mois (ingénieurs, cadres, techniciens supérieurs), 6 mois (cadres supérieurs) ; renouvelable une seule fois ; le renouvellement doit être notifié par écrit au moins 2 jours, 8 jours, 15 jours ou 1 mois avant la fin, selon la durée de l’essai. Faute de notification à temps, l’essai prend fin à la date prévue.
• RG-ONB-02 L’application calcule la date limite de notification et alerte le manager et le P&C à J-10 et J-3 (param.) avant cette date.
• RG-ONB-03 Un collaborateur ne peut pas être affecté sur un poste à risque avant d’avoir reçu l’induction sécurité et, si le poste l’exige, une aptitude médicale et les habilitations requises.

5.5 M5 — Sécurisation des talents clés et rétention

Objectif. Savoir qui sont les personnes et les postes dont la perte mettrait l’entreprise en difficulté, mesurer le risque de départ, et agir avant qu’il ne se réalise. Module strictement confidentiel (P&C et DG).

Fonctionnalités

Règles de gestion

• RG-TAL-01 Le score de risque de départ est une aide à la décision : il n’est visible que du P&C et du DG, n’est jamais communiqué au collaborateur ni à son manager, et ne déclenche aucune décision automatique.
• RG-TAL-02 Un talent clé est un collaborateur de la case « haute performance × haut potentiel » ou titulaire d’un poste critique sans successeur prêt ; il doit avoir un plan de rétention actif.
• RG-TAL-03 Taux de couverture des successions = postes critiques ayant au moins un successeur « prêt dans 1 an ou moins » ÷ postes critiques.
• RG-TAL-04 Le départ d’un talent clé déclenche une alerte au DG et une analyse obligatoire (entretien de sortie, causes, actions).
• RG-TAL-05 Les réponses individuelles aux enquêtes anonymes (M7) ne sont jamais utilisées pour calculer un risque de départ individuel.

5.6 M6 — Conformité sociale Côte d’Ivoire

Objectif. Ne manquer aucune échéance légale et pouvoir prouver, à tout moment, que l’entreprise est en règle : contrats, CNPS, CMU, santé au travail, congés, instances représentatives (délégués du personnel, CSST), registres et déclarations.

Répartition des rôles avec GS2E. GS2E reste en charge des déclarations et paiements liés à la paie (cotisations CNPS et CMU, DISA). L’application ne les refait pas : elle suit qu’elles ont été faites (statut, date, attestation déposée) et alerte si une preuve manque.

Paramètres légaux. Toutes les durées, seuils et taux cités ci-dessous sont des paramètres datés (valeur + date d’effet + texte source), modifiables sans développement. Les valeurs par défaut figurent à l’annexe B et doivent être validées avant la mise en production, notamment au regard des décrets du 15 avril 2026.

5.6.1 Contrats et échéances

• RG-CTR-01 La durée maximale d’un CDD, le nombre de renouvellements autorisés et les cas de recours sont des paramètres (Code du travail, art. 15.1 à 15.10) ; dépasser la limite est bloquant sans validation explicite du P&C et du DG, tracée.
• RG-CTR-02 Un CDD arrivé à terme sans décision enregistrée passe en alerte rouge au tableau de conformité.

5.6.2 CNPS

5.6.3 CMU (Couverture maladie universelle)

• RG-CMU-01 Cotisation par défaut : 1 000 FCFA par mois et par personne, partagée à parts égales entre employeur et salarié pour le salarié ; pour le conjoint sans emploi et les enfants de moins de 21 ans, prise en charge employeur de 50 %, dans la limite de 6 enfants (param.). Ces montants servent au contrôle ; le calcul reste chez GS2E.

5.6.4 Santé et sécurité au travail

5.6.5 Congés et absences

• RG-ABS-01 Un congé ne peut être demandé au-delà du solde disponible, sauf anticipation autorisée par le P&C.
• RG-ABS-02 Une demande non traitée par le manager sous 3 jours ouvrés (param.) est relancée puis escaladée au P&C.

5.6.6 Instances représentatives : délégués du personnel et CSST

Un même moteur de réunions sert toutes les instances : convocation, ordre du jour, présence, procès-verbal, recommandations et plan d’actions.

• RG-INS-01 Une recommandation ne peut être close qu’avec une preuve de réalisation ou une décision motivée d’abandon validée par le président de l’instance.
• RG-INS-02 Taux de mise en œuvre = actions réalisées dans les délais ÷ actions échues.
• RG-INS-03 Tant que l’effectif habituel ne dépasse pas 50, la délégation du personnel tient lieu de CSST : les sujets de santé-sécurité sont suivis dans ses réunions avec le même moteur.

5.6.7 Registres, déclarations et calendrier légal

• RG-LEG-01 Le taux de conformité = obligations à jour ÷ obligations suivies (visites médicales, habilitations, contrats, immatriculations, enrôlements CMU, déclarations, réunions d’instances, affichages).

5.7 M7 — Climat social, culture et engagement

Objectif. Mesurer régulièrement le climat et l’engagement, agir sur les résultats, et faire vivre la culture et les valeurs de Smart Energy au quotidien.

• RG-ENG-01 Un résultat (score, verbatim, taux de participation) ne s’affiche que pour un groupe d’au moins 5 répondants (param., minimum autorisé 3).
• RG-ENG-02 Protection contre la déduction : un segment est masqué si sa soustraction du total (ou d’un autre segment affiché) laisse un groupe sous le seuil ; pas de croisement de deux critères si l’un des groupes est sous le seuil.
• RG-ENG-03 eNPS = % de promoteurs (notes 9–10) − % de détracteurs (notes 0–6).
• RG-ENG-04 Le P&C peut masquer un verbatim contenant une information identifiante (masquage tracé), jamais le modifier.

5.8 M8 — Pilotage et tableau de bord du DG

Objectif. Une page, à jour, qui dit au DG où en est le capital humain de Smart Energy, et un rapport mensuel commenté.

Contenu de la vue synthèse

Les formules des indicateurs sont à l’annexe C. Les indicateurs sont calculés chaque nuit et historisés (photographies mensuelles), pour des tendances fiables et un affichage rapide.

5.9 M9 — Fonctions transverses et administration

Administration (refaite entièrement en Angular)

L’administration Django n’est pas exposée en production. Toute l’administration se fait dans l’application Angular, en deux espaces :

Administration fonctionnelle (P&C)

• Structures, sites, nomenclatures (motifs de sortie, types de contrats, catégories professionnelles, types de documents, types d’absences…).
• Paramètres légaux datés (annexe B) : valeur, date d’effet, texte source, historique.
• Échelles (compétences, performance, potentiel), pondérations, formulaires.
• Étapes et délais de recrutement, parcours d’intégration types.
• Modèles de documents et de courriels.
• Circuits de validation, délégations.
• Jours fériés, seuils des feux tricolores, cibles annuelles des indicateurs.
• Utilisateurs métier : attribution des profils et des périmètres.

Administration technique (ZDS)

• Comptes, réinitialisation d’accès, double authentification.
• Paramètres de messagerie, état des tâches planifiées et des sauvegardes, journaux techniques.
• Aucun accès au contenu des données C3/C4 (chiffrées en base, voir 8.7).

6. Interfaces et reprise des données

6.1 Échanges avec GS2E (paie externalisée)

Les échanges se font par fichiers Excel normalisés, horodatés et tracés ; une interface programmée (API) pourra les remplacer plus tard si GS2E le propose.

• RG-INT-01 La clôture RH du mois fige les variables transmises ; une correction ultérieure passe par une variable rectificative le mois suivant.
• RG-INT-02 Chaque transmission est tracée (fichier, empreinte, auteur, date, accusé de réception GS2E).
• RG-INT-03 L’import de paie rejette toute ligne dont le matricule est inconnu et produit un rapport d’anomalies.

6.2 Autres interfaces

6.3 Reprise des données

• La reprise utilise les imports Excel guidés (TRV-09) : simulation, rapport d’erreurs, puis import définitif.
• Avant la prise de poste, seules des données fictives sont utilisées (environnement de démonstration). La reprise réelle a lieu après la nomination, avec l’accord du DG et un cadre convenu avec GS2E pour la transmission des extractions.

7. Exigences non fonctionnelles

7.1 Utilisateurs et volumes

7.2 Performance

• Affichage d’une page courante en moins de 2 secondes sur une connexion 4G.
• Réponse de l’API : 95 % des requêtes en moins de 500 ms.
• Paquet initial de l’application Angular inférieur à 500 Ko compressés ; modules chargés à la demande.
• Génération d’un PDF (contrat, entretien, rapport mensuel) en moins de 10 secondes.

7.3 Disponibilité et continuité

• Disponibilité visée : 99,5 % en heures ouvrées (lundi–samedi, 7 h–20 h, heure d’Abidjan).
• Sauvegardes : base de données chaque nuit (rétention 30 jours) + sauvegardes automatiques de l’hébergeur + copie hebdomadaire chiffrée hors de l’hébergement.
• Perte de données maximale admissible (RPO) : 24 heures ; délai de remise en service (RTO) : 4 heures.
• Test de restauration chaque trimestre, consigné.

7.4 Sécurité

• HTTPS obligatoire (certificat automatique), en-têtes de sécurité (HSTS, CSP, X-Frame-Options, Referrer-Policy).
• Mots de passe : 12 caractères minimum, vérification contre les mots de passe courants, renouvellement non imposé mais double authentification (TOTP) obligatoire pour les profils P&C, DG et administrateur technique, facultative pour les autres.
• Verrouillage après 5 échecs de connexion (param.) ; expiration de session après 30 minutes d’inactivité.
• Chiffrement des champs C3/C4 en base ; clé hors du dépôt de code et hors de la base.
• Contrôle des droits côté serveur sur chaque requête (le masquage d’un bouton dans l’interface n’est jamais une sécurité).
• Journalisation des accès aux données sensibles ; journaux conservés 12 mois.
• Dépôts de fichiers : types autorisés (PDF, DOCX, XLSX, JPG, PNG), taille maximale, renommage, stockage hors de la racine web, téléchargement uniquement via un contrôle de droits.
• Référentiel visé : OWASP ASVS niveau 2.

7.5 Protection des données personnelles (loi n° 2013-450)

• Responsable de traitement : Smart Energy. Maîtrise d’œuvre et hébergeur : sous-traitants, liés par contrat (clauses de confidentialité et de sécurité).
• Formalités auprès de l’ARTCI à accomplir par Smart Energy avant la mise en production avec des données réelles : déclaration ou autorisation des traitements RH, et autorisation du transfert si l’hébergement est situé hors de Côte d’Ivoire (o2switch héberge en France). À valider avec le juriste du groupe.
• Information des collaborateurs et des candidats (mentions dans l’application, page de politique de confidentialité).
• Minimisation : pas de diagnostic médical, pas de données biométriques, pas de géolocalisation.
• Durées de conservation paramétrées par catégorie (candidats non retenus, dossiers des salariés sortis, enquêtes, journaux), purge ou anonymisation automatique.
• Droits d’accès et de rectification exercés depuis l’espace libre-service ; export des données personnelles d’un collaborateur sur demande.

7.6 Ergonomie et accessibilité

• Interface responsive : téléphone (360 px), tablette, ordinateur. Les parcours terrain (congés, validations, objectifs, enquêtes, interview) sont conçus d’abord pour le téléphone.
• Application installable (PWA) ; notes d’interview sauvegardées localement en cas de coupure réseau.
• Accessibilité visée : WCAG 2.1 niveau AA (contrastes, navigation au clavier, libellés des champs).
• Langue : français ; formats : dates JJ/MM/AAAA, montants en FCFA sans décimales, fuseau Africa/Abidjan.
• Charte graphique de Smart Energy / Eranove (logo, couleurs, typographie) à fournir au Lot 0.

7.7 Maintenabilité et documentation

• Code versionné sur un dépôt Git privé dont Smart Energy reçoit l’accès ; conventions de code et revues.
• Documentation livrée : guide d’installation et d’exploitation, documentation de l’API (OpenAPI), dictionnaire des données, guide utilisateur intégré, guides hors connexion, procès-verbaux de recette.
• Mises à jour de sécurité des dépendances au moins mensuelles.

8. Spécifications techniques

8.1 Architecture générale

Application web en deux parties, servies sous un même domaine (pas de CORS, cookies stricts) :

• un frontend Angular (application monopage) qui porte toute l’interface, y compris l’administration ;
• un backend Django + Django REST Framework qui expose une API JSON versionnée, applique toutes les règles de gestion et tous les contrôles de droits.

8.2 Pile technologique

8.3 Hébergement cPanel o2switch

8.3.1 Topologie

8.3.2 Arborescence sur le serveur

/home/<compte>/
├── people.<domaine>/                 # racine web : build Angular
│   ├── index.html  main-*.js  styles-*.css  assets/  guides/
│   └── .htaccess                     # bloc Passenger (cPanel) + réécriture SPA + en-têtes
├── smartpeople_api/                  # application Python (Passenger)
│   ├── passenger_wsgi.py
│   ├── manage.py  config/  apps/  requirements.txt
│   └── tmp/restart.txt               # redémarrage : touch tmp/restart.txt
├── smartpeople_media/                # documents (hors web, droits 700)
├── smartpeople_backups/              # sauvegardes chiffrées locales
├── logs/                             # journaux applicatifs et des tâches
└── virtualenv/smartpeople_api/3.12/  # créé par « Setup Python App »

8.3.3 Réécriture de l’application Angular

Le bloc de configuration Passenger que cPanel ajoute en tête du .htaccess est conservé tel quel ; les règles suivantes viennent après lui.

RewriteEngine On
# L'API est servie par Passenger
RewriteCond %{REQUEST_URI} ^/api/ [NC]
RewriteRule ^ - [L]
# Fichiers et dossiers existants servis directement
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
# Toute autre adresse : application Angular
RewriteRule ^ index.html [L]

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "DENY"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: blob:; style-src 'self' 'unsafe-inline'; script-src 'self'; connect-src 'self'; frame-ancestors 'none'"
</IfModule>
<FilesMatch "\.(js|css|woff2)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
<FilesMatch "^index\.html$">
  Header set Cache-Control "no-cache"
</FilesMatch>

8.3.4 Contraintes de l’hébergement mutualisé et parades

Plan B. Le code ne dépend d’aucune spécificité de cPanel (configuration par variables d’environnement, stockage de fichiers abstrait). Si les besoins grandissent ou si la politique du groupe impose un autre hébergement (VPS, infrastructure Eranove), la même application se déploie en conteneurs Docker (avec PostgreSQL et Celery/Redis) sans réécriture.

8.3.5 Environnements et déploiement

Procédure de mise en production (scriptée, idempotente) : sauvegarde de la base → copie du build Angular dans la racine web → mise à jour du code backend → pip install -r requirements.txt → python manage.py migrate → python manage.py check --deploy → touch tmp/restart.txt → test de santé /api/v1/sante. Retour arrière : restauration de la version précédente et de la sauvegarde.

8.4 Backend Django

8.4.1 Découpage en applications

backend/
├── config/            # settings (base, dev, recette, prod), urls, wsgi
├── apps/
│   ├── noyau/         # utilisateurs, profils et périmètres, paramètres datés, audit,
│   │                  # notifications, tâches différées, documents, modèles, circuits, formulaires
│   ├── organisation/  # structures, sites, emplois, postes, plan d'effectifs
│   ├── personnel/     # collaborateurs, ayants droit, contrats, affectations, mouvements
│   ├── competences/   # dictionnaire, référentiel versionné, étude (projets, interviews, éléments)
│   ├── evaluations/   # campagnes de compétences, évaluations, écarts, PDI
│   ├── formation/     # besoins, plan, sessions, habilitations
│   ├── performance/   # campagnes, objectifs, entretiens, calibration, rémunération variable
│   ├── recrutement/   # demandes, annonces, candidats, candidatures, entretiens, offres
│   ├── integration/   # dossiers d'embauche, parcours, tâches, fins d'essai
│   ├── talents/       # postes critiques, revues, 9 cases, risques, successions, rétention, sorties
│   ├── conformite/    # CNPS, CMU, visites, accidents, registres, calendrier légal, veille
│   ├── conges/        # règles, acquisitions, soldes, demandes, jours fériés
│   ├── instances/     # instances, mandats, élections, réunions, PV, recommandations, actions
│   ├── engagement/    # enquêtes, invitations, réponses, valeurs, reconnaissance, idées, actualités
│   ├── pilotage/      # indicateurs, photographies mensuelles, tableaux de bord, rapports
│   └── echanges/      # imports / exports GS2E, imports Excel guidés
└── tests/

Chaque application suit la même organisation : models.py, serializers.py, views.py (ViewSets), permissions.py, services.py (règles de gestion, sans dépendance HTTP, testées unitairement), selectors.py (requêtes de lecture optimisées), tasks.py (tâches différées). L’admin Django n’est pas routé en production.

8.4.2 Conventions

• Modèle de base ModeleTrace : identifiant public UUID, cree_le, cree_par, modifie_le, modifie_par.
• Pas de suppression physique des objets métier : clôture ou archivage ; la purge relève des règles de conservation.
• Historisation (django-simple-history) des modèles C2/C3.
• Paramètres datés : modèle Parametre(code, valeur JSON, date_effet, source, commentaire) et fonction parametre("conges.jours_par_mois", a_la_date) — aucune valeur légale codée en dur.
• Transactions atomiques pour les opérations multi-objets (clôture RH, calibration, import).
• Requêtes : select_related / prefetch_related systématiques sur les listes ; pagination côté serveur.

8.5 Frontend Angular

8.5.1 Organisation du code

frontend/src/app/
├── core/           # authentification, intercepteurs (jeton, rafraîchissement, erreurs), gardes,
│                   # coquille (barre latérale, barre haute, pile du bord), notifications
├── shared/         # tableau de données serveur, filtres, puces de statut, feux tricolores,
│                   # dialogues, téléversement, éditeur riche, graphiques, formulaire dynamique,
│                   # directive *siPermission, pipes (FCFA, dates)
├── api/            # services et types générés depuis l'OpenAPI — jamais modifiés à la main
├── aide/           # guide intégré : modele.ts, fiches.ts, ecrans.ts, texte.ts…
├── features/
│   ├── accueil/            # « Mes actions », accueil selon le profil
│   ├── pilotage/           # tableau de bord DG, rapports
│   ├── organisation/  personnel/  competences/  etude/  evaluations/  formation/
│   ├── performance/  recrutement/  integration/  talents/  conformite/  conges/
│   ├── instances/  engagement/
│   ├── moi/                # libre-service collaborateur
│   ├── administration/     # fonctionnelle et technique
│   └── public/             # carrières, candidature, réponse à une offre, dossier d'embauche, enquête
└── app.routes.ts

8.5.2 Principes

• Composants autonomes, détection de changements OnPush, signals et SignalStore par module ; chaque module chargé à la demande.
• Formulaires réactifs typés ; validations miroir de celles du serveur (le serveur reste l’autorité).
• Gardes de route par permission (data.permissions) et directive *siPermission pour l’affichage — la sécurité réelle est côté serveur.
• Intercepteur : ajout du jeton, rafraîchissement transparent sur 401, une seule tentative, puis retour à la connexion.
• Listes : pagination, tri et filtres dans l’adresse (liens partageables, retour arrière fidèle).
• Formulaire dynamique : un composant unique rend les formulaires définis dans l’administration (entretiens annuels, guides d’interview, enquêtes, fins d’essai, sorties).
• Mode interview (M1) : sauvegarde locale (IndexedDB) toutes les 10 secondes, synchronisation au retour du réseau, contrôle de version pour éviter d’écraser une saisie plus récente.
• Navigation : barre latérale par module (filtrée par profil) ; barre haute avec recherche, notifications, aide ? et profil ; sur téléphone, barre de navigation basse pour le libre-service (Accueil, Congés, Objectifs, Documents, Plus).
• Guide utilisateur intégré selon le standard ZDS : une fiche par écran et par profil déduite de l’adresse, tiroir rangé à côté de la page sur grand écran, touche ?, page /aide avec recherche et sommaire suiveur, guides hors connexion générés au build, contrôle npm run verify:aide (fiches ↔︎ écrans ↔︎ routes ↔︎ gardes) bloquant dans la CI.
• La PWA ne met en cache que la coquille de l’application, jamais les réponses de l’API contenant des données personnelles.

8.6 Modèle de données

8.6.1 Vue d’ensemble (entités principales)

Organisation et personnel

Compétences et performance

Recrutement, conformité et instances

8.6.2 Entités par application (extrait)

Le dictionnaire de données complet (champs, types, contraintes, sensibilité) est un livrable du Lot 0, tenu à jour à chaque lot.

8.7 Sécurité et confidentialité

8.7.1 Authentification

• Connexion par identifiant et mot de passe, puis code TOTP pour les profils qui l’exigent.
• Jeton d’accès JWT de courte durée (15 min), conservé en mémoire seulement ; jeton de rafraîchissement (8 h (param.)) en cookie HttpOnly, Secure, SameSite=Strict, limité au chemin /api/v1/auth/, avec rotation et liste de révocation à la déconnexion.
• Liens externes (candidat, dossier d’embauche, réponse à une offre, enquête) : jetons signés à usage unique et à durée limitée, sans compte.
• Limitation de débit : connexion (5 / min / IP), candidature publique (10 / h / IP), réinitialisation de mot de passe.

8.7.2 Contrôle des droits

• Chaque action de l’API exige une permission nommée (ex. performance.entretien.valider) accordée par un profil, sur un périmètre (SOI, ÉQUIPE, LIGNE, DIRECTION, TOUT).
• Un filtre de périmètre commun restreint chaque requête aux collaborateurs visibles (calcul de la ligne hiérarchique mis en cache par requête).
• Les champs C3/C4 sont retirés des réponses par les sérialiseurs quand l’utilisateur n’a pas la permission de lecture correspondante.
• Une batterie de tests vérifie la matrice des droits (chaque profil × chaque point d’API × chaque périmètre).

8.7.3 Chiffrement et traçabilité

• Champs C3/C4 chiffrés par MultiFernet (rotation de clé possible) ; clés dans les variables d’environnement de l’application cPanel, jamais dans le dépôt ni dans la base ; l’administrateur technique qui consulte la base ne lit pas ces valeurs.
• Les sauvegardes sont chiffrées avant de quitter le serveur.
• Journal d’accès : toute consultation d’une donnée C3/C4 et tout export sont enregistrés (qui, quoi, quand, d’où).

8.7.4 Anonymat des enquêtes, garanti par construction

• L’invitation (qui a été invité, a-t-il répondu, pour les relances) et la réponse (ce qu’il a répondu) sont dans deux tables sans lien.
• Les réponses transitent par une table d’attente vidée par une tâche horaire, dans un ordre aléatoire, avec une date arrondie au jour et un identifiant aléatoire : on ne peut pas rapprocher une réponse d’une invitation par l’heure ou l’ordre d’arrivée.
• Seuls des segments grossiers définis par la campagne sont enregistrés (ex. direction, tranche d’ancienneté, catégorie).
• Aucun point d’API ne renvoie une réponse individuelle ; les agrégats appliquent le seuil et la protection contre la déduction (RG-ENG-01 et 02) côté serveur.

8.8 API

8.8.1 Conventions

8.8.2 Principaux points d’accès

8.9 Tâches planifiées (Cron cPanel)

Chaque commande est idempotente, protégée par un verrou de fichier, journalisée, et écrit un « battement de cœur » ; une alerte part si une tâche n’a pas tourné à l’heure prévue.

8.10 Qualité, tests et intégration continue

• Tests unitaires des règles (services) : acquisition des congés, dates limites d’essai, limites des CDD, calcul des atteintes et des notes, écarts de compétences, seuils d’effectif, eNPS, seuil d’anonymat et protection contre la déduction, délais de recrutement. Couverture visée ≥ 80 % sur les services, ≥ 70 % globale.
• Tests de l’API : matrice des droits complète ; contrats d’API vérifiés contre l’OpenAPI.
• Tests Angular : composants et stores ; Playwright sur 10 parcours clés (connexion avec double authentification ; demande et validation de congé ; fixation d’objectifs ; entretien annuel signé ; recrutement complet jusqu’à l’embauche ; fin d’essai ; alerte de visite médicale ; réunion CSST → PV → action ; réponse à une enquête anonyme ; tableau de bord DG).
• CI (GitHub Actions) : lint, tests backend sur MySQL 8, tests Angular, verify:aide, build de production, audit des dépendances ; la fusion est bloquée si un contrôle échoue.
• Jeu de démonstration : commande charger_demo (entreprise fictive de ~45 collaborateurs, données plausibles) pour la recette et les démonstrations.

8.11 Exploitation et supervision

• Journaux applicatifs en fichiers tournants ; erreurs serveur notifiées par courriel à l’administrateur technique sans donnée personnelle (option : Sentry avec masquage des données personnelles).
• Point de santé /api/v1/sante (base, disque, dernière exécution des tâches) surveillé par un service externe de disponibilité.
• Alerte d’espace disque à 80 % du quota.
• Mises à jour de sécurité mensuelles des dépendances ; montée de version mineure de Django et d’Angular à chaque lot.
• Cahier d’exploitation : déploiement, retour arrière, restauration, rotation des clés, ajout d’un utilisateur, clôture RH mensuelle, procédure d’incident.

9. Lotissement, planning et charge

9.1 Hypothèses

• Équipe de réalisation : 2 développeurs (un chef de projet technique full-stack et un développeur Django/Angular).
• Disponibilité du porteur (maîtrise d’ouvrage) : environ une journée par semaine pour les ateliers, les arbitrages et la recette.
• Démarrage indicatif : fin novembre 2026. Les fenêtres ci-dessous glissent avec la date réelle de démarrage.
• Les charges sont indicatives ; elles seront affinées à la fin du Lot 0, une fois les maquettes validées.

9.2 Lots

9.3 Cohérence avec le calendrier RH

• Échéances de janvier 2027 (déclaration annuelle de la main-d’œuvre avant le 31 janvier) : si le Lot 1 n’est pas encore en production, elles sont suivies manuellement ; le calendrier légal de l’application prend le relais en février.
• Objectifs 2027 : si la campagne doit démarrer avant la livraison du Lot 2, les objectifs sont recueillis avec le modèle Excel d’import puis chargés dans l’application à la livraison — aucun travail n’est perdu.
• Étude du référentiel : outillée dès le Lot 2 pour que les interviews démarrent pendant les premiers mois de la prise de poste ; l’évaluation des compétences (Lot 3) suit la publication du référentiel.
• Entretiens annuels 2027 (novembre–décembre) : Lot 3 livré en mai, laissant le temps de former managers et collaborateurs.
• Passage des 50 salariés : la surveillance des seuils (Lot 1) alerte dès l’approche ; le moteur des instances (Lot 3) prend en charge le CSST. Si le seuil est franchi plus tôt, le module Instances est avancé.
• Premier baromètre d’engagement : septembre–octobre 2027, après la livraison du Lot 4.

10. Recette et critères d’acceptation

10.1 Démarche

1. Recette interne par la maîtrise d’œuvre (tests automatisés verts, contrôles manuels).
2. Recette utilisateur sur l’environnement de recette, avec les données fictives : le P&C, deux managers pilotes, le DG pour le tableau de bord.
3. Procès-verbal de recette du lot (réserves éventuelles et dates de levée).
4. Mise en production, puis vérification de service régulier pendant 30 jours.

10.2 Scénarios d’acceptation (extraits)

11. Gouvernance, prérequis et risques

11.1 Gouvernance du projet

Les demandes nouvelles alimentent un carnet priorisé (Must / Should / Could) ; toute demande qui modifie le planning est arbitrée en comité de pilotage.

11.2 Prérequis à la mise en production avec des données réelles

1. Nomination effective au poste de P&C Manager et accord du DG sur l’outil.
2. Avis de la DSI du groupe Eranove (sécurité, hébergement, authentification).
3. Compte d’hébergement et domaine au nom de Smart Energy.
4. Formalités ARTCI accomplies par Smart Energy (traitements RH, transfert hors de Côte d’Ivoire si l’hébergement est en France).
5. Cadre d’échange avec GS2E : formats des fichiers, calendrier de clôture, interlocuteurs, mode de transmission des extractions de reprise.
6. Charte graphique, organigramme, fiches de poste et modèles de documents actuels.
7. Validation juridique des paramètres légaux (annexe B), notamment au regard des décrets du 15 avril 2026.
8. Désignation des utilisateurs pilotes et planning de formation.

11.3 Risques

11.4 Propriété et réversibilité

• Le code source, la documentation et les données sont la propriété de Smart Energy (à formaliser dans le contrat de réalisation).
• Le dépôt Git est accessible à Smart Energy ; toute donnée est exportable (Excel et JSON) depuis l’application.
• En fin de contrat de maintenance, la maîtrise d’œuvre remet les accès, la documentation à jour et une session de passation.

12. Annexes

Annexe A — Glossaire

Annexe B — Paramètres légaux par défaut

Valeurs de départ, à valider par le P&C Manager et le conseil juridique avant la mise en production. Chaque paramètre est daté (date d’effet) et modifiable dans l’administration sans développement.

Annexe C — Dictionnaire des indicateurs

Annexe D — Échelles

Niveaux de compétence

Notation de la performance

Matrice 9 cases (performance × potentiel)

Criticité d’un poste : quatre critères notés de 1 à 3 (impact sur l’activité, rareté sur le marché, délai de remplacement, compétences rares en interne) ; poste critique si le total ≥ 9 (param.).

Risque de départ : faible (< 40), modéré (40–69), élevé (≥ 70) sur un score de 0 à 100 (seuils param.).

Annexe E — Calendrier RH et légal annuel type

(Les réunions du CSST s’appliquent une fois l’effectif habituel au-delà de 50 salariés.)

Annexe F — Modèles de documents et de courriels à prévoir

Documents : contrat CDI · contrat CDD · avenant · convention de stage · lettre d’offre · renouvellement de période d’essai · confirmation d’embauche à l’issue de l’essai · rupture de période d’essai · fin de CDD · attestation de travail · certificat de travail · convocation à la visite médicale · fiche emploi et fiche de poste · compte rendu d’entretien annuel · PDI · convocation, ordre du jour et procès-verbal (délégués, CSST) · liste nominative des membres du CSST · bilan annuel et programme annuel de prévention · statistiques de la déclaration annuelle de la main-d’œuvre · registre d’employeur · livret d’accueil · rapport mensuel au DG.

Courriels : accusé de réception de candidature · convocation à un entretien · refus · offre · bienvenue · rappel de pièces manquantes · convocation à un entretien d’interview (étude) · lancement et relances de campagnes · alertes d’échéance · invitation et relance d’enquête · récapitulatif quotidien.

Annexe G — Sources réglementaires consultées

• Code du travail, loi n° 2015-532 du 20 juillet 2015 — civlii.laws.africa
• Décret n° 2020-955 relatif au Comité de santé et sécurité au travail — civlii.laws.africa
• Décret n° 2024-900 relatif à la période d’essai — civlii.laws.africa
• Décret n° 2024-901 relatif aux délégués du personnel et délégués syndicaux — civlii.laws.africa
• Décret n° 2024-902 relatif aux obligations déclaratives des employeurs — civlii.laws.africa
• Décret n° 2026-198 du 15 avril 2026 relatif à la durée du préavis — loidici.biz
• Adoption de 11 décrets d’application du Code du travail le 15 avril 2026 — koaci.com
• Convention collective interprofessionnelle de 1977 — civlii.laws.africa
• CNPS, guide du recouvrement — cnps.ci
• Cotisations sociales en Côte d’Ivoire (taux au 1er janvier 2025) — cleiss.fr
• Loi n° 2013-450 et formalités ARTCI — cio-mag.com

Annexe H — Les 90 premiers jours du P&C Manager avec SMART PEOPLE

Fin du document — SMART PEOPLE, cahier des charges v1.0, 8 novembre 2026.