# SETUP.MD — CAHIER DES CHARGES V5 # SYSTÈME PROFESSIONNEL DE GESTION D'UNE MUTUELLE **Nom fonctionnel :** Système Intégré de Gestion Mutualiste **Version :** 5.0 **Statut :** Cahier des charges de référence **Langue de l'application :** Français **Monnaie de référence :** Franc CFA (FCFA) **Pays cible initial :** Côte d'Ivoire **Type de solution :** Application web professionnelle **Architecture cible :** Moderne, modulaire, sécurisée, évolutive --- # 1. OBJET DU PROJET Le présent cahier des charges définit intégralement les besoins fonctionnels, métier, techniques, de sécurité et d'exploitation d'un système professionnel destiné à gérer une mutuelle. Le système doit permettre de gérer de manière centralisée : - les adhérents ; - les demandes d'adhésion ; - les adhésions ; - les cotisations ; - les échéances ; - les paiements ; - les avances ; - les dons ; - la trésorerie ; - les dépenses ; - les budgets ; - les aides sociales ; - les prêts ; - les remboursements ; - les garants ; - les événements de vie ; - les réunions ; - les convocations ; - les procurations ; - les décisions ; - les communications ; - les documents ; - les cartes de membre ; - les notifications ; - les tableaux de bord ; - les rapports ; - les exports ; - les utilisateurs ; - les rôles ; - les autorisations ; - la traçabilité ; - les sauvegardes ; - la configuration générale de la mutuelle. Le système doit être conçu comme un **produit autonome**, indépendant de toute application, base de données ou architecture préexistante. Aucune hypothèse ne doit être faite concernant un système antérieur. --- # 2. VISION DU PRODUIT La solution doit devenir le système central de gestion de la mutuelle. Elle doit permettre à la direction et aux responsables de disposer à tout moment d'une vision fiable : - des adhérents ; - de leur situation ; - des cotisations ; - des recettes ; - des dépenses ; - de la trésorerie ; - des aides ; - des prêts ; - des remboursements ; - des engagements financiers ; - des événements ; - des activités de la mutuelle. L'objectif est de remplacer les traitements dispersés réalisés avec : - cahiers ; - feuilles Excel ; - fichiers texte ; - documents papier ; - calculs manuels ; - tableaux indépendants ; - échanges informels. Le système doit fournir une **source unique, cohérente et traçable de l'information**. --- # 3. PRINCIPES DIRECTEURS Le développement doit respecter les principes suivants. ## 3.1 Métier avant technique Le fonctionnement de la mutuelle doit être défini avant les détails d'implémentation. ## 3.2 Données fiables Une information importante ne doit exister qu'une seule fois comme donnée de référence. ## 3.3 Traçabilité Toute opération importante doit pouvoir être expliquée : - qui ; - quoi ; - quand ; - pourquoi ; - avant ; - après. ## 3.4 Intégrité financière Les montants financiers doivent être exacts. Aucun calcul financier critique ne doit dépendre d'approximations dangereuses. ## 3.5 Séparation des responsabilités La personne qui saisit une opération ne doit pas nécessairement être celle qui l'approuve. ## 3.6 Configuration Les règles métier susceptibles de changer doivent être configurables. ## 3.7 Évolutivité Le système doit pouvoir évoluer sans réécriture complète. ## 3.8 Simplicité d'utilisation L'utilisateur doit pouvoir comprendre immédiatement : - ce qu'il voit ; - ce qu'il peut faire ; - ce qui est obligatoire ; - ce qui est en attente ; - ce qui est validé ; - ce qui est refusé. --- # 4. VOCABULAIRE OFFICIEL L'interface utilisateur doit utiliser exclusivement une terminologie française cohérente. | Concept | Terme officiel | |---|---| | Personne inscrite à la mutuelle | Adhérent | | Compte permettant de se connecter | Utilisateur | | Inscription à la mutuelle | Adhésion | | Somme périodique à payer | Cotisation | | Somme devant être payée à une date donnée | Échéance | | Somme effectivement reçue | Paiement | | Somme versée avant son échéance | Avance | | Somme offerte à la mutuelle | Don | | Somme dépensée par la mutuelle | Dépense | | Soutien financier accordé | Aide sociale | | Somme prêtée | Prêt | | Somme versée pour rembourser un prêt | Remboursement | | Personne garantissant un prêt | Garant | | Réunion officielle | Réunion | | Invitation officielle | Convocation | | Autorisation de représentation | Procuration | | Carte officielle | Carte de membre | | Historique des actions | Journal d'audit | Les libellés visibles par les utilisateurs doivent rester en français. --- # 5. UTILISATEURS ET RÔLES Le système distingue clairement : - la personne adhérente ; - le compte utilisateur permettant l'accès au système. Un adhérent peut avoir un compte utilisateur. Un utilisateur peut éventuellement exercer une fonction administrative sans être adhérent. ## 5.1 Administrateur Responsabilités : - configuration ; - utilisateurs ; - rôles ; - permissions ; - paramètres ; - sécurité ; - supervision ; - maintenance fonctionnelle ; - consultation globale ; - journal d'audit. L'administrateur ne doit pas pouvoir contourner les règles de traçabilité financière. ## 5.2 Président Accès notamment à : - tableau de bord général ; - adhérents ; - activités ; - aides ; - prêts ; - décisions ; - réunions ; - rapports ; - validation des opérations selon les règles définies. ## 5.3 Secrétaire Accès notamment à : - adhérents ; - adhésions ; - événements ; - réunions ; - convocations ; - procès-verbaux ; - communications ; - documents administratifs. ## 5.4 Trésorier Accès notamment à : - cotisations ; - paiements ; - avances ; - dons ; - dépenses ; - trésorerie ; - prêts ; - remboursements ; - rapprochements ; - rapports financiers. ## 5.5 Adhérent Chaque adhérent doit pouvoir consulter : - son profil ; - son adhésion ; - sa situation ; - ses cotisations ; - ses échéances ; - ses paiements ; - ses avances ; - ses prêts ; - ses remboursements ; - ses aides ; - ses documents autorisés ; - sa carte de membre ; - les communications qui lui sont destinées. Un adhérent ne doit jamais pouvoir consulter les données privées d'un autre adhérent. --- # 6. GESTION DES ADHÉRENTS ## 6.1 Fiche adhérent La fiche doit pouvoir contenir notamment : ### Identité - numéro d'adhérent ; - nom ; - prénom(s) ; - sexe ; - date de naissance ; - lieu de naissance ; - nationalité ; - photographie ; - situation matrimoniale. ### Coordonnées - téléphone principal ; - téléphone secondaire ; - adresse électronique ; - adresse ; - ville ; - pays. ### Informations administratives - profession ; - employeur ; - fonction ; - personne à contacter en cas d'urgence ; - téléphone de la personne à contacter. ### Informations mutualistes - catégorie d'adhérent ; - date de demande ; - date d'adhésion ; - date d'activation ; - statut ; - date de sortie éventuelle ; - motif de sortie. --- # 7. NUMÉROTATION DES ADHÉRENTS Chaque adhérent doit posséder un identifiant unique. Exemple : `ADH-2026-000001` Le format doit être configurable. La numérotation doit : - éviter les doublons ; - être contrôlée par le système ; - rester traçable ; - ne pas dépendre du nom de l'adhérent. --- # 8. STATUTS DES ADHÉRENTS Les statuts métier doivent être en français. - En attente - Actif - Suspendu - Inactif - Démissionnaire - Exclu - Décédé - Archivé Les transitions entre statuts doivent respecter des règles métier. Exemple : `En attente → Actif` `Actif → Suspendu` `Actif → Démissionnaire` `Actif → Décédé` `Actif → Exclu` Une transition importante doit être enregistrée dans l'historique. --- # 9. DEMANDE D'ADHÉSION Le système doit permettre de gérer une demande d'adhésion avant la création définitive de l'adhésion. Étapes : 1. demande ; 2. vérification ; 3. étude ; 4. décision ; 5. acceptation ou refus ; 6. paiement éventuel du droit d'adhésion ; 7. activation. La décision doit être traçable. --- # 10. ADHÉSION Une adhésion constitue le lien officiel entre une personne et la mutuelle. Elle doit contenir : - numéro d'adhésion ; - adhérent ; - date de début ; - date de fin éventuelle ; - catégorie ; - régime ; - statut ; - conditions applicables ; - historique. Le système doit permettre plusieurs catégories d'adhésion si la mutuelle le souhaite. --- # 11. CATÉGORIES D'ADHÉRENTS Les catégories doivent être configurables. Exemples : - membre ordinaire ; - membre fondateur ; - membre honoraire ; - membre bienfaiteur ; - membre partenaire ; - autre catégorie définie par la mutuelle. Chaque catégorie peut avoir : - un droit d'adhésion ; - une cotisation ; - des conditions particulières ; - des droits ; - des restrictions. --- # 12. AYANTS DROIT ET BÉNÉFICIAIRES Le système doit permettre d'associer des bénéficiaires à un adhérent. Informations : - nom ; - prénom ; - lien avec l'adhérent ; - date de naissance ; - téléphone ; - statut ; - observations. Le système doit pouvoir déterminer quels bénéficiaires sont éligibles à certains dispositifs. --- # 13. DOCUMENTS DES ADHÉRENTS Les documents peuvent comprendre : - pièce d'identité ; - photographie ; - justificatif ; - certificat ; - document administratif ; - document relatif à un événement ; - document relatif à une aide ; - document relatif à un prêt. Chaque document doit posséder : - type ; - propriétaire ; - date ; - fichier ; - auteur ; - statut ; - niveau de confidentialité. Les documents privés ne doivent jamais être accessibles uniquement parce qu'une personne connaît leur identifiant. --- # 14. COTISATIONS La gestion des cotisations doit distinguer : **Ce qui doit être payé** et **Ce qui a effectivement été payé.** Cette distinction est fondamentale. --- # 15. CAMPAGNES DE COTISATION Le système doit permettre de définir des campagnes. Une campagne peut définir : - période ; - catégorie concernée ; - montant ; - fréquence ; - date d'échéance ; - règles d'exonération ; - règles de retard. Fréquences possibles : - mensuelle ; - trimestrielle ; - semestrielle ; - annuelle ; - unique ; - exceptionnelle. --- # 16. ÉCHÉANCES DE COTISATION Chaque échéance doit contenir notamment : - adhérent ; - campagne ; - période ; - montant attendu ; - montant payé ; - solde ; - date d'échéance ; - statut. Statuts : - À payer ; - Partiellement payée ; - Payée ; - En retard ; - Exonérée ; - Annulée. --- # 17. CALCUL DU RETARD Une échéance est en retard lorsque : - la date d'échéance est dépassée ; - et que le montant restant dû est supérieur à zéro. Le système doit pouvoir calculer : - nombre de jours de retard ; - montant restant ; - nombre d'échéances en retard ; - ancienneté de l'impayé. --- # 18. PAIEMENTS Chaque paiement doit être identifié de manière unique. Exemple : `PAI-2026-000001` Informations : - numéro ; - adhérent ; - date ; - montant ; - mode de paiement ; - référence ; - compte financier ; - utilisateur ayant enregistré l'opération ; - justificatif ; - statut. --- # 19. MODES DE PAIEMENT Le système doit prendre en charge : - Espèces ; - Virement bancaire ; - Carte bancaire ; - Mobile Money ; - Chèque ; - Autre. Les modes de paiement doivent être configurables. --- # 20. AFFECTATION DES PAIEMENTS Un paiement peut couvrir plusieurs échéances. Exemple : Un adhérent verse 50 000 FCFA. Le système peut affecter : - 10 000 FCFA à une échéance ; - 10 000 FCFA à une deuxième ; - 10 000 FCFA à une troisième ; - 20 000 FCFA comme avance. Chaque affectation doit être enregistrée. --- # 21. AVANCES Une avance correspond à une somme reçue avant qu'elle ne soit due. Une avance doit être suivie séparément. Elle peut ensuite être affectée à : - une cotisation future ; - une échéance particulière ; - une autre obligation autorisée. Une avance ne doit jamais être confondue avec une cotisation déjà acquittée. --- # 22. QUITTANCES Après validation d'un paiement, le système peut générer une quittance. Elle doit contenir : - numéro ; - adhérent ; - montant ; - date ; - mode de paiement ; - motif ; - référence ; - identité de la mutuelle ; - élément de vérification. Une quittance validée ne doit pas pouvoir être modifiée silencieusement. --- # 23. DONS Le système doit gérer les dons. Informations : - donateur ; - date ; - montant ; - nature ; - destination éventuelle ; - mode de paiement ; - compte financier ; - justificatif ; - observations. Le don doit être distingué d'une cotisation. --- # 24. TRÉSORERIE Le système doit gérer plusieurs comptes financiers. Exemples : - Caisse ; - Compte bancaire ; - Compte Mobile Money ; - Autre compte financier. Chaque compte possède : - nom ; - type ; - devise ; - solde ; - statut ; - date d'ouverture ; - date de clôture éventuelle. --- # 25. MOUVEMENTS FINANCIERS Toute opération financière doit produire un mouvement financier traçable. Types : - Entrée d'argent ; - Sortie d'argent ; - Transfert entrant ; - Transfert sortant ; - Correction ; - Annulation. Catégories : - Cotisation ; - Droit d'adhésion ; - Don ; - Octroi de prêt ; - Remboursement de prêt ; - Aide sociale ; - Dépense ; - Transfert ; - Remboursement d'avance ; - Autre. --- # 26. SOURCE DE VÉRITÉ FINANCIÈRE Les soldes financiers ne doivent pas être considérés comme de simples valeurs saisies manuellement. Ils doivent pouvoir être reconstruits à partir des mouvements financiers validés. Toute opération financière importante doit être réalisée dans une transaction atomique. Exemple : Lors d'un paiement : 1. création du paiement ; 2. création des affectations ; 3. création du mouvement financier ; 4. mise à jour des éléments nécessaires ; 5. validation globale. Si une étape échoue, l'ensemble de l'opération doit être annulé. --- # 27. ANNULATION DES OPÉRATIONS FINANCIÈRES Une opération financière validée ne doit pas être supprimée physiquement. Elle doit être : - annulée ; - corrigée ; - ou compensée par une opération inverse. Le système doit conserver : - l'opération originale ; - l'auteur ; - la date ; - le motif ; - l'opération corrective. --- # 28. RAPPROCHEMENT FINANCIER Le système doit permettre de comparer : - solde théorique ; - solde réel ; - mouvements ; - écarts. Pour les comptes bancaires : - période ; - relevé ; - opérations rapprochées ; - opérations non rapprochées ; - écarts. --- # 29. DÉPENSES Une dépense doit contenir : - numéro ; - date ; - montant ; - catégorie ; - bénéficiaire ; - compte financier ; - motif ; - justificatif ; - auteur ; - statut ; - validation. Exemple : `DEP-2026-000001` --- # 30. APPROBATION DES DÉPENSES Selon les règles de la mutuelle, une dépense peut suivre : 1. saisie ; 2. contrôle ; 3. approbation ; 4. paiement ; 5. enregistrement financier. Les seuils d'approbation doivent être configurables. --- # 31. BUDGETS Le système doit permettre de définir des budgets. Exemples : - budget annuel ; - budget d'aide sociale ; - budget de fonctionnement ; - budget des événements ; - budget des investissements. Le système doit comparer : - budget prévu ; - montant engagé ; - montant payé ; - solde disponible. --- # 32. AIDES SOCIALES Le système doit gérer les demandes d'aide. Types possibles : - Décès ; - Naissance ; - Mariage ; - Maladie ; - Hospitalisation ; - Accident ; - Sinistre ; - Urgence ; - Autre. Les types doivent être configurables. --- # 33. DEMANDE D'AIDE Une demande doit pouvoir contenir : - numéro ; - adhérent ; - type ; - date ; - motif ; - montant demandé ; - documents ; - observations ; - statut ; - décision. Exemple : `AID-2026-000001` --- # 34. PROCESSUS D'AIDE Workflow : 1. demande ; 2. dépôt des justificatifs ; 3. contrôle ; 4. étude ; 5. décision ; 6. approbation ; 7. paiement ; 8. clôture. Le système doit conserver la justification de la décision. --- # 35. RÈGLES D'ÉLIGIBILITÉ Les règles d'aide doivent pouvoir prendre en compte : - ancienneté ; - statut de l'adhérent ; - cotisations à jour ; - type d'événement ; - plafond ; - fréquence ; - nombre d'aides déjà reçues ; - justificatifs nécessaires. Les règles doivent être configurables. --- # 36. PRÊTS Le système doit gérer le cycle complet du prêt. Étapes : 1. demande ; 2. étude ; 3. analyse ; 4. décision ; 5. garanties ; 6. approbation ; 7. décaissement ; 8. remboursement ; 9. suivi des retards ; 10. clôture. --- # 37. DEMANDE DE PRÊT Informations : - numéro ; - adhérent ; - montant demandé ; - objet ; - durée ; - date ; - justificatifs ; - observations ; - statut. Exemple : `PRT-2026-000001` --- # 38. STATUTS DES PRÊTS - Demandé ; - En cours d'étude ; - Étudié ; - Approuvé ; - Refusé ; - Annulé ; - Décaissé ; - En remboursement ; - En retard ; - Remboursé ; - Clôturé. --- # 39. GARANTIES Le système doit permettre de gérer : - garant personne physique ; - garantie financière ; - garantie documentaire ; - autre garantie autorisée. Pour un garant : - adhérent garant ; - engagement ; - montant garanti ; - date ; - statut ; - validation. --- # 40. CALCUL DES PRÊTS Le système doit pouvoir prendre en charge différents modes : - sans intérêt ; - intérêt forfaitaire ; - amortissement ; - autres modes configurables. Les calculs doivent être déterministes. Les règles d'arrondi doivent être explicites. La dernière échéance peut être ajustée afin de supprimer les écarts d'arrondi. --- # 41. ÉCHÉANCIER DE PRÊT Chaque prêt doit générer un échéancier. Une échéance contient : - numéro ; - date ; - capital ; - intérêt éventuel ; - montant total ; - montant payé ; - solde ; - retard ; - statut. Statuts : - À venir ; - Partiellement payée ; - Payée ; - En retard ; - Annulée. --- # 42. REMBOURSEMENTS Un remboursement doit être enregistré comme une opération financière. Le système doit pouvoir calculer : - capital restant ; - montant déjà remboursé ; - échéances restantes ; - retard ; - pénalités éventuelles ; - montant total dû. --- # 43. REMBOURSEMENT ANTICIPÉ Le système doit pouvoir gérer le remboursement anticipé. Il doit calculer : - capital restant ; - intérêts éventuels ; - montant à régler ; - éventuels frais ; - clôture du prêt. --- # 44. ÉVÉNEMENTS DE VIE Le système doit gérer les événements importants concernant les adhérents. Types : - Naissance ; - Mariage ; - Décès ; - Hospitalisation ; - Accident ; - Retraite ; - Autre. --- # 45. DÉCLARATION D'ÉVÉNEMENT Un événement doit pouvoir être : 1. déclaré ; 2. vérifié ; 3. approuvé ; 4. rejeté ; 5. clôturé. Il peut être associé à : - documents ; - aides ; - notifications ; - décisions ; - historique. --- # 46. DÉCÈS D'UN ADHÉRENT Lorsqu'un décès est validé : - le statut de l'adhérent devient Décédé ; - les nouvelles échéances futures doivent être traitées selon les règles de la mutuelle ; - les opérations historiques sont conservées ; - les données ne sont pas supprimées ; - les bénéficiaires peuvent être identifiés ; - une aide éventuelle peut être déclenchée. --- # 47. RÉUNIONS Le système doit gérer : - Assemblée générale ; - Réunion du bureau ; - Réunion de commission ; - Réunion ordinaire ; - Réunion extraordinaire ; - autres réunions. Informations : - titre ; - type ; - date ; - heure ; - lieu ; - ordre du jour ; - participants ; - décisions ; - procès-verbal. --- # 48. CONVOCATIONS Une convocation doit pouvoir contenir : - réunion ; - destinataires ; - date ; - lieu ; - ordre du jour ; - message ; - date d'envoi ; - statut. --- # 49. PRÉSENCE AUX RÉUNIONS Le système doit enregistrer : - présent ; - absent ; - excusé ; - représenté. Il doit également permettre de gérer les procurations. --- # 50. PROCURATIONS Une procuration doit préciser : - mandant ; - mandataire ; - réunion ; - date ; - statut ; - document éventuel. Une même personne ne doit pas pouvoir recevoir un nombre de procurations supérieur à la limite autorisée par les règles de la mutuelle. --- # 51. DÉCISIONS ET PROCÈS-VERBAUX Les décisions importantes doivent être enregistrées. Informations : - réunion ; - numéro de décision ; - sujet ; - décision ; - vote éventuel ; - résultat ; - responsable ; - date. Les procès-verbaux doivent pouvoir être archivés. --- # 52. COMMUNICATIONS Le système doit permettre de publier : - annonces ; - informations ; - avis ; - rappels ; - convocations ; - messages importants. Les communications peuvent cibler : - tous les adhérents ; - une catégorie ; - un groupe ; - certains adhérents. --- # 53. NOTIFICATIONS Notifications possibles : - nouvelle échéance ; - retard de cotisation ; - paiement enregistré ; - demande d'aide ; - décision d'aide ; - demande de prêt ; - décision de prêt ; - échéance de prêt ; - retard de remboursement ; - réunion ; - convocation ; - annonce importante. Canaux prévus pour l'évolution : - notification interne ; - courrier électronique ; - SMS ; - messagerie instantanée ; - autres services. --- # 54. CARTE DE MEMBRE Chaque adhérent actif peut disposer d'une carte de membre numérique. La carte peut afficher : - logo ; - nom de la mutuelle ; - photographie ; - nom ; - prénom ; - numéro d'adhérent ; - catégorie ; - date d'adhésion ; - date d'expiration ; - statut ; - code QR. --- # 55. CODE QR Le QR code doit permettre de vérifier l'authenticité de la carte. Le QR code ne doit pas contenir directement des données sensibles. Le système doit utiliser un identifiant aléatoire suffisamment long. Pour la recherche interne, le jeton peut être représenté par une empreinte cryptographique adaptée. La page publique de vérification doit révéler le minimum nécessaire. Réponses possibles : - Carte valide ; - Carte expirée ; - Carte révoquée ; - Carte inconnue. Aucune information financière privée ne doit être exposée. --- # 56. GESTION DES DOCUMENTS Le système doit gérer : - documents administratifs ; - justificatifs ; - pièces liées aux aides ; - pièces liées aux prêts ; - procès-verbaux ; - rapports ; - documents de gouvernance. Chaque document doit être protégé contre : - accès non autorisé ; - téléchargement non autorisé ; - modification non autorisée ; - suppression non autorisée. --- # 57. TABLEAU DE BORD GÉNÉRAL Le tableau de bord doit afficher notamment : - nombre d'adhérents ; - adhérents actifs ; - nouvelles adhésions ; - cotisations attendues ; - cotisations encaissées ; - impayés ; - trésorerie ; - dépenses ; - aides ; - prêts ; - remboursements ; - alertes. --- # 58. TABLEAU DE BORD DU TRÉSORIER Indicateurs : - recettes ; - dépenses ; - solde des comptes ; - cotisations encaissées ; - impayés ; - avances ; - prêts décaissés ; - remboursements ; - aides versées ; - mouvements récents. --- # 59. TABLEAU DE BORD DU SECRÉTAIRE Indicateurs : - nouvelles demandes ; - adhésions ; - événements ; - réunions ; - convocations ; - documents ; - communications. --- # 60. TABLEAU DE BORD DU PRÉSIDENT Vue synthétique : - situation des adhérents ; - situation financière ; - aides ; - prêts ; - décisions en attente ; - réunions ; - alertes importantes ; - indicateurs de performance. --- # 61. ESPACE ADHÉRENT L'adhérent doit disposer d'un espace personnel. Il peut consulter : ### Mon profil - informations personnelles ; - coordonnées ; - bénéficiaires. ### Ma situation - statut ; - adhésion ; - ancienneté ; - catégorie. ### Mes cotisations - échéances ; - paiements ; - impayés ; - avances. ### Mes prêts - prêts ; - échéanciers ; - remboursements ; - soldes. ### Mes aides - demandes ; - décisions ; - versements. ### Mes documents Documents auxquels il est autorisé à accéder. ### Ma carte Carte de membre numérique. --- # 62. RAPPORTS Le système doit produire des rapports : ## Rapports administratifs - liste des adhérents ; - nouveaux adhérents ; - sorties ; - adhérents actifs ; - adhérents suspendus ; - événements de vie. ## Rapports financiers - recettes ; - dépenses ; - trésorerie ; - cotisations ; - impayés ; - dons ; - aides ; - prêts ; - remboursements. ## Rapports de gouvernance - réunions ; - présences ; - procurations ; - décisions ; - procès-verbaux. --- # 63. EXPORTS Les données autorisées doivent pouvoir être exportées en : - PDF ; - CSV ; - XLSX. Les exports doivent respecter les permissions de l'utilisateur. Les données confidentielles ne doivent jamais être exportées par défaut. --- # 64. PÉRIODES FINANCIÈRES Le système doit gérer les périodes financières. Une période peut être : - ouverte ; - en cours de clôture ; - clôturée. Une période clôturée ne doit plus accepter de modification financière normale. Toute correction ultérieure doit être réalisée selon une procédure contrôlée. --- # 65. CLÔTURE FINANCIÈRE Avant clôture : - vérifier les mouvements ; - vérifier les soldes ; - vérifier les rapprochements ; - vérifier les opérations en attente ; - produire les rapports ; - valider la période. La clôture doit être traçable. --- # 66. JOURNAL D'AUDIT Le système doit conserver un journal des actions sensibles. Informations : - utilisateur ; - action ; - date ; - heure ; - adresse réseau lorsque nécessaire ; - objet concerné ; - ancienne valeur ; - nouvelle valeur lorsque pertinent ; - résultat ; - justification. Actions à tracer notamment : - création ; - modification ; - validation ; - refus ; - annulation ; - suppression logique ; - changement de rôle ; - changement de permission ; - opération financière ; - décision ; - accès à certaines données sensibles. --- # 67. SÉCURITÉ DES ACCÈS Le système doit appliquer : - authentification sécurisée ; - mots de passe protégés ; - contrôle des sessions ; - expiration appropriée ; - protection contre les tentatives répétées ; - limitation de débit ; - protection CSRF ; - validation serveur ; - autorisation serveur. --- # 68. AUTORISATIONS La sécurité ne doit jamais reposer uniquement sur l'interface. Chaque action sensible doit être contrôlée côté serveur. Le système doit empêcher : - accès à un autre adhérent ; - modification d'une opération non autorisée ; - téléchargement d'un document privé ; - modification d'un prêt non autorisé ; - validation par une personne sans permission ; - contournement d'une étape métier. --- # 69. PROTECTION CONTRE LES ATTAQUES COURANTES Le système doit intégrer des protections contre : - injection SQL ; - XSS ; - CSRF ; - élévation de privilèges ; - accès direct non autorisé aux objets ; - téléchargement de fichiers dangereux ; - attaques par force brute ; - fixation de session ; - divulgation d'informations ; - manipulation des paramètres ; - falsification des requêtes. --- # 70. PROTECTION DES DONNÉES Les données personnelles doivent être traitées conformément aux exigences légales applicables. Le système doit appliquer notamment : - minimisation ; - contrôle d'accès ; - confidentialité ; - traçabilité ; - conservation maîtrisée ; - suppression ou anonymisation lorsque légalement applicable ; - protection des exports ; - protection des sauvegardes. --- # 71. SUPPRESSION DES DONNÉES Les données financières et historiques importantes ne doivent pas être supprimées physiquement simplement pour corriger une erreur. Le système doit privilégier : - annulation ; - archivage ; - correction ; - remplacement contrôlé ; - anonymisation lorsque nécessaire et autorisée. --- # 72. ARGENT ET PRÉCISION Les montants financiers ne doivent pas être traités comme des nombres flottants imprécis. Les montants doivent être stockés dans une représentation garantissant une précision exacte. La monnaie de référence est : **FCFA** Les règles d'arrondi doivent être définies explicitement. --- # 73. CONCURRENCE ET INTÉGRITÉ Deux utilisateurs pouvant agir simultanément sur une même opération financière ne doivent pas pouvoir produire un solde incohérent. Les opérations critiques doivent utiliser : - transactions ; - verrouillage approprié ; - contrôles de cohérence ; - contraintes d'unicité ; - contrôles d'idempotence. --- # 74. IDEMPOTENCE Une même opération ne doit pas être enregistrée deux fois accidentellement à cause : - d'un double clic ; - d'un rafraîchissement ; - d'une coupure réseau ; - d'une nouvelle tentative ; - d'un traitement automatique répété. Les opérations sensibles doivent disposer d'une stratégie d'idempotence. --- # 75. NUMÉROTATION DES DOCUMENTS Les documents métier importants doivent posséder des numéros uniques. Exemples : `ADH-2026-000001` `PAI-2026-000001` `REC-2026-000001` `AID-2026-000001` `PRT-2026-000001` `DEP-2026-000001` `REU-2026-000001` Le format doit être configurable. --- # 76. DATES ET HEURES Le système doit utiliser une stratégie cohérente de gestion des dates et heures. La zone horaire de référence doit être configurable. Pour la Côte d'Ivoire : **UTC+00:00** Les dates métier importantes doivent être conservées sans ambiguïté. --- # 77. PARAMÈTRES DE LA MUTUELLE Un espace de configuration doit permettre de gérer : - nom ; - logo ; - coordonnées ; - devise ; - zone horaire ; - formats de numérotation ; - catégories d'adhérents ; - types de cotisations ; - règles d'aide ; - règles de prêt ; - modes de paiement ; - comptes financiers ; - seuils d'approbation ; - modèles de documents ; - modèles de notifications. --- # 78. RÈGLES MÉTIER CONFIGURABLES Le système ne doit pas enfermer dans le code les règles susceptibles de changer. Exemples : - montant d'une cotisation ; - fréquence ; - plafond d'une aide ; - durée maximale d'un prêt ; - taux éventuel ; - nombre maximal de garants ; - seuil d'approbation ; - délai de grâce ; - pénalité ; - conditions d'éligibilité. --- # 79. MOTEUR DE RÈGLES À terme, le système doit pouvoir appliquer automatiquement certaines règles. Exemple : > Un adhérent doit être actif et respecter les conditions définies pour pouvoir demander telle aide. Le résultat d'une règle doit être explicable. Le système doit pouvoir indiquer pourquoi une condition est : - satisfaite ; - non satisfaite ; - impossible à déterminer. --- # 80. TÂCHES AUTOMATIQUES Le système pourra exécuter automatiquement : - génération des échéances ; - détection des retards ; - notifications ; - rappels ; - génération de rapports ; - contrôles de cohérence ; - archivage ; - traitements périodiques. Les tâches automatiques doivent être traçables. --- # 81. NOTIFICATIONS AUTOMATIQUES Exemples : > Votre échéance de cotisation arrive à échéance. > Votre cotisation présente un retard. > Votre demande d'aide a été enregistrée. > Votre demande de prêt a été approuvée. > Votre prochaine échéance de prêt arrive à échéance. Les messages doivent être rédigés en français. --- # 82. RECHERCHE La recherche doit être disponible sur les principaux modules. Elle doit permettre de rechercher notamment : - numéro d'adhérent ; - nom ; - prénom ; - téléphone ; - courrier électronique ; - numéro de paiement ; - numéro de prêt ; - numéro d'aide ; - numéro de dépense. --- # 83. FILTRES Les listes doivent permettre des filtres adaptés. Exemples : - statut ; - période ; - catégorie ; - montant ; - retard ; - compte financier ; - type ; - responsable ; - date. --- # 84. TRI ET PAGINATION Les grandes listes doivent être : - paginées ; - triables ; - filtrables. Le système ne doit pas charger inutilement plusieurs milliers de lignes. --- # 85. PERFORMANCES L'application doit être conçue pour éviter : - requêtes répétitives inutiles ; - chargement massif ; - problèmes de requêtes N+1 ; - calculs lourds dans les vues ; - absence d'index ; - exports bloquant complètement l'application. --- # 86. ARCHITECTURE LOGIQUE Le système doit être organisé en domaines fonctionnels. Domaines principaux : 1. Identité et accès 2. Adhérents 3. Adhésions 4. Cotisations 5. Paiements 6. Trésorerie 7. Dépenses 8. Dons 9. Aides sociales 10. Prêts 11. Événements 12. Réunions 13. Communications 14. Documents 15. Cartes 16. Rapports 17. Audit 18. Configuration --- # 87. SÉPARATION DES RESPONSABILITÉS TECHNIQUES Le système doit séparer : - présentation ; - validation ; - autorisation ; - logique métier ; - accès aux données ; - traitement financier ; - génération de documents ; - notifications ; - tâches automatiques. Les contrôleurs ne doivent pas devenir de gigantesques blocs contenant toute la logique métier. --- # 88. SERVICES MÉTIER Les opérations complexes doivent être encapsulées dans des services métier spécialisés. Exemples : - service de génération des cotisations ; - service d'enregistrement des paiements ; - service d'affectation des paiements ; - service de trésorerie ; - service d'aide sociale ; - service de prêt ; - service de remboursement ; - service de carte ; - service de notification ; - service de clôture financière. --- # 89. ÉVÉNEMENTS MÉTIER Le système peut utiliser des événements pour découpler certaines opérations. Exemples : - Adhérent créé ; - Adhésion activée ; - Paiement validé ; - Aide approuvée ; - Prêt approuvé ; - Prêt décaissé ; - Remboursement enregistré ; - Réunion créée. --- # 90. TRAITEMENTS ASYNCHRONES Les traitements lourds peuvent être exécutés en arrière-plan : - génération de gros rapports ; - export ; - envoi massif de notifications ; - génération de documents ; - traitement de fichiers. Le système doit empêcher les traitements identiques de se multiplier inutilement. --- # 91. BASE DE DONNÉES CONCEPTUELLE Le modèle conceptuel doit notamment prévoir des entités correspondant à : - Utilisateur ; - Rôle ; - Permission ; - Adhérent ; - Bénéficiaire ; - Adhésion ; - Catégorie d'adhérent ; - Campagne de cotisation ; - Échéance ; - Paiement ; - Affectation de paiement ; - Avance ; - Don ; - Compte financier ; - Mouvement financier ; - Dépense ; - Budget ; - Aide ; - Demande d'aide ; - Prêt ; - Garant ; - Échéance de prêt ; - Remboursement ; - Événement de vie ; - Réunion ; - Convocation ; - Présence ; - Procuration ; - Décision ; - Document ; - Carte de membre ; - Notification ; - Journal d'audit ; - Période financière ; - Paramètre. Cette liste est conceptuelle et pourra évoluer pendant la conception détaillée. --- # 92. INTÉGRITÉ DES RELATIONS Le système doit utiliser des contraintes permettant d'empêcher : - références inexistantes ; - doublons ; - suppressions incohérentes ; - montants négatifs non autorisés ; - associations invalides ; - états incompatibles. --- # 93. HISTORISATION Les changements importants doivent être historisés. Exemples : - changement de statut ; - changement de catégorie ; - changement de montant ; - modification d'une règle ; - décision ; - annulation ; - correction. --- # 94. SAUVEGARDES Le système doit prévoir : - sauvegardes régulières ; - sauvegardes automatiques ; - conservation de plusieurs générations ; - vérification des sauvegardes ; - restauration testée. Une sauvegarde qui n'a jamais été restaurée avec succès ne doit pas être considérée comme pleinement fiable. --- # 95. PLAN DE RESTAURATION La procédure de restauration doit être documentée. Elle doit permettre de répondre à : - où se trouve la sauvegarde ? - quelle sauvegarde utiliser ? - comment restaurer ? - comment vérifier ? - comment reprendre le service ? --- # 96. ENVIRONNEMENTS Prévoir au minimum : - développement ; - test ; - production. Les données réelles de production ne doivent pas être utilisées librement dans l'environnement de développement. --- # 97. TESTS Le système doit être couvert par des tests : ### Tests unitaires Pour les règles métier. ### Tests d'intégration Pour les interactions entre modules. ### Tests fonctionnels Pour les parcours utilisateur. ### Tests de sécurité Pour les permissions et accès. ### Tests financiers Pour : - cotisations ; - paiements ; - affectations ; - avances ; - prêts ; - remboursements ; - soldes ; - annulations. --- # 98. TESTS DES CALCULS FINANCIERS Les scénarios doivent notamment tester : - paiement exact ; - paiement partiel ; - paiement supérieur au montant dû ; - avance ; - plusieurs échéances ; - remboursement anticipé ; - retard ; - annulation ; - correction ; - arrondi. --- # 99. CRITÈRE DE QUALITÉ Une fonctionnalité n'est considérée comme terminée que lorsque : - le code fonctionne ; - les règles métier sont respectées ; - les autorisations sont correctes ; - les erreurs sont traitées ; - les tests passent ; - les données restent cohérentes ; - l'interface est compréhensible ; - la documentation nécessaire est disponible. --- # 100. INTERFACE UTILISATEUR L'interface doit être : - entièrement en français ; - claire ; - professionnelle ; - responsive ; - adaptée aux ordinateurs ; - adaptée aux tablettes ; - adaptée aux téléphones. --- # 101. ACCESSIBILITÉ L'interface doit prendre en compte : - contraste ; - taille des textes ; - navigation clavier ; - libellés explicites ; - messages d'erreur compréhensibles ; - structure sémantique. --- # 102. MESSAGES UTILISATEUR Les messages doivent être compréhensibles par des utilisateurs non techniques. Éviter : > Exception SQLSTATE... Préférer : > Impossible d'enregistrer le paiement. Veuillez vérifier les informations saisies. Les détails techniques doivent être réservés aux journaux appropriés. --- # 103. CONFIRMATION DES ACTIONS SENSIBLES Les actions importantes doivent demander une confirmation. Exemples : - annulation ; - validation ; - approbation ; - rejet ; - clôture ; - changement de rôle ; - changement de permission. Pour certaines opérations, un motif doit être obligatoire. --- # 104. PRÉVENTION DES ERREURS L'interface doit empêcher autant que possible : - montants invalides ; - dates incohérentes ; - doublons ; - affectations impossibles ; - transitions de statut interdites. --- # 105. RAPPORTS FINANCIERS Les rapports doivent pouvoir présenter : - total des recettes ; - total des dépenses ; - solde ; - cotisations ; - dons ; - aides ; - prêts ; - remboursements ; - mouvements par compte ; - mouvements par période. Les rapports doivent pouvoir être filtrés par période. --- # 106. INDICATEURS DE PERFORMANCE MUTUALISTE Le système pourra calculer : - taux d'adhérents actifs ; - taux de paiement des cotisations ; - taux d'impayés ; - montant moyen des cotisations ; - montant moyen des aides ; - nombre de prêts ; - montant des prêts ; - taux de remboursement ; - délai moyen de traitement ; - évolution des adhésions. --- # 107. TABLEAUX DE BORD GRAPHIQUES Les tableaux de bord peuvent présenter : - graphiques d'évolution ; - répartitions ; - tendances ; - indicateurs financiers ; - alertes. Les graphiques ne doivent jamais remplacer les chiffres détaillés. --- # 108. IMPORTATION DE DONNÉES Le système pourra permettre l'importation de données depuis : - CSV ; - XLSX. L'importation doit prévoir : 1. sélection du fichier ; 2. analyse ; 3. validation ; 4. aperçu ; 5. détection des erreurs ; 6. confirmation ; 7. importation ; 8. rapport final. Les imports financiers doivent être particulièrement contrôlés. --- # 109. EXPORT ET CONFIDENTIALITÉ Un export contenant des données personnelles doit être traité comme une donnée sensible. Le système doit pouvoir : - limiter les permissions ; - tracer l'export ; - générer uniquement les colonnes autorisées ; - protéger les documents générés. --- # 110. API Le système doit pouvoir évoluer vers une API. L'API pourra être utilisée pour : - application mobile ; - Mobile Money ; - paiement en ligne ; - SMS ; - intégration bancaire ; - outils externes. Les règles d'autorisation de l'API doivent être aussi strictes que celles de l'interface web. --- # 111. APPLICATION MOBILE FUTURE L'architecture doit permettre ultérieurement une application mobile donnant accès à : - profil ; - carte ; - cotisations ; - paiements ; - prêts ; - aides ; - notifications ; - communications. --- # 112. PAIEMENTS EN LIGNE FUTURS Le système doit pouvoir évoluer vers : - Mobile Money ; - carte bancaire ; - paiement en ligne ; - intégrations bancaires. Une transaction externe devra être rapprochée d'une opération interne. Le système ne doit jamais considérer une simple demande de paiement comme un paiement définitivement encaissé. --- # 113. INTELLIGENCE ARTIFICIELLE Une future couche d'intelligence artificielle peut assister les utilisateurs pour : - recherche documentaire ; - synthèse de rapports ; - analyse statistique ; - assistance aux utilisateurs ; - détection d'anomalies ; - aide à la rédaction ; - recherche dans les procédures. L'intelligence artificielle ne doit jamais décider seule : - d'accorder un prêt ; - d'accorder une aide ; - de supprimer une donnée ; - de modifier une permission ; - d'effectuer un paiement ; - de modifier un solde financier. Toute décision sensible doit rester sous contrôle humain. --- # 114. JOURNALISATION TECHNIQUE Les journaux techniques doivent permettre de diagnostiquer : - erreurs ; - exceptions ; - traitements automatiques ; - échecs d'envoi ; - erreurs d'intégration ; - anomalies. Les journaux techniques ne doivent pas exposer inutilement les données personnelles ou financières. --- # 115. SURVEILLANCE La production doit pouvoir surveiller : - disponibilité ; - erreurs ; - performances ; - traitements automatiques ; - espace disque ; - sauvegardes ; - tâches échouées. --- # 116. GESTION DES ERREURS Une erreur métier doit être distinguée d'une erreur technique. Exemple : **Erreur métier :** > Cet adhérent ne remplit pas les conditions nécessaires pour demander cette aide. **Erreur technique :** > Une erreur interne est survenue lors de l'enregistrement. --- # 117. EXTENSIBILITÉ La conception doit permettre d'ajouter ultérieurement : - nouvelles catégories ; - nouveaux types d'aide ; - nouveaux types de prêts ; - nouveaux modes de paiement ; - nouveaux rapports ; - nouveaux rôles ; - nouveaux canaux de notification ; - nouveaux comptes financiers. --- # 118. GOUVERNANCE Le système doit soutenir la gouvernance de la mutuelle. Il doit permettre de retrouver : - qui a décidé ; - quand ; - sur quelle base ; - avec quel résultat ; - sur quel document ; - avec quelles personnes présentes. --- # 119. SÉPARATION DES POUVOIRS Lorsque cela est nécessaire, le système doit permettre une séparation entre : - saisie ; - contrôle ; - approbation ; - paiement ; - rapprochement. Cette séparation doit être configurable selon l'organisation de la mutuelle. --- # 120. PRÉVENTION DE LA FRAUDE Le système doit faciliter la détection de situations inhabituelles : - paiement répété ; - double dépense ; - modification répétée ; - annulation fréquente ; - prêt inhabituel ; - aide dépassant les habitudes ; - opération financière inhabituelle ; - accès anormal aux données. Ces mécanismes doivent servir d'alerte et non remplacer le contrôle humain. --- # 121. ARCHIVAGE Les données historiques doivent rester consultables selon les droits. L'archivage ne doit pas supprimer la traçabilité. --- # 122. CONFORMITÉ La solution doit être conçue en tenant compte : - des règles applicables à la protection des données personnelles ; - des obligations administratives ; - des règles financières internes ; - des statuts et règlements de la mutuelle ; - des procédures de gouvernance. Les règles propres à chaque mutuelle doivent être configurables. --- # 123. DOCUMENTATION Le projet doit disposer de documentation : - fonctionnelle ; - technique ; - installation ; - configuration ; - sécurité ; - sauvegarde ; - restauration ; - exploitation ; - procédures administratives. --- # 124. PRINCIPES DE DÉVELOPPEMENT Le développement doit être progressif. Chaque fonctionnalité doit être : 1. analysée ; 2. conçue ; 3. implémentée ; 4. testée ; 5. vérifiée ; 6. documentée lorsque nécessaire. Les grosses modifications incontrôlées doivent être évitées. --- # 125. DÉVELOPPEMENT PAR LOTS Le projet doit être construit par modules. Ordre indicatif : ### Lot 1 Socle technique et sécurité. ### Lot 2 Utilisateurs, rôles et permissions. ### Lot 3 Adhérents et adhésions. ### Lot 4 Cotisations et échéances. ### Lot 5 Paiements et avances. ### Lot 6 Trésorerie et dépenses. ### Lot 7 Dons. ### Lot 8 Aides sociales. ### Lot 9 Prêts et remboursements. ### Lot 10 Événements de vie. ### Lot 11 Réunions et gouvernance. ### Lot 12 Documents et cartes. ### Lot 13 Notifications. ### Lot 14 Rapports. ### Lot 15 Importations et exports. ### Lot 16 Optimisation et industrialisation. --- # 126. DÉFINITION DE TERMINÉ Une fonctionnalité n'est pas terminée simplement parce que son écran existe. Elle doit être considérée terminée uniquement lorsque : - le modèle de données est cohérent ; - les règles métier fonctionnent ; - les validations fonctionnent ; - les permissions fonctionnent ; - les erreurs sont gérées ; - les opérations sensibles sont tracées ; - les tests passent ; - les données sont cohérentes ; - l'interface est utilisable ; - la fonctionnalité est intégrée au reste du système. --- # 127. OBJECTIF FINAL Le produit final doit constituer un véritable système de gestion mutualiste permettant à une organisation de gérer professionnellement : **SES ADHÉRENTS** **SES ADHÉSIONS** **SES COTISATIONS** **SES PAIEMENTS** **SES AVANCES** **SES DONS** **SA TRÉSORERIE** **SES DÉPENSES** **SES AIDES SOCIALES** **SES PRÊTS** **SES REMBOURSEMENTS** **SES GARANTIES** **SES ÉVÉNEMENTS DE VIE** **SES RÉUNIONS** **SES DÉCISIONS** **SES COMMUNICATIONS** **SES DOCUMENTS** **SES CARTES DE MEMBRE** **SES RAPPORTS** **SES UTILISATEURS** **SES AUTORISATIONS** **SON HISTORIQUE** tout en garantissant : **INTÉGRITÉ** **SÉCURITÉ** **CONFIDENTIALITÉ** **TRAÇABILITÉ** **FIABILITÉ** **ÉVOLUTIVITÉ** --- # 128. RÈGLE FONDAMENTALE DU PROJET Ce cahier des charges constitue la **spécification métier de référence**. Il est indépendant de toute application existante. Il ne doit pas être interprété comme une description ou une amélioration d'un logiciel antérieur. Toute implémentation future devra partir de ce cahier des charges et déterminer ensuite : 1. l'architecture ; 2. le modèle de données ; 3. les technologies ; 4. les modules ; 5. les interfaces ; 6. les règles détaillées ; 7. les tests ; 8. le déploiement. **Le métier définit le système.** **La technique doit servir le métier.** --- # FIN DU CAHIER DES CHARGES V5.0