# A.1 — Introduction générale Chapitre A.1 du Manuel PIGBF # A.1.1.1 — Présentation du programme PAAF et de la PIGBF ## 1.1 Présentation du programme PAAF et de la PIGBF Le **Projet d'Apprentissage et d'Autonomisation des Filles (PAAF)** est un programme d'appui à la scolarisation des filles dans la province du Kasaï, en République Démocratique du Congo. Dans le cadre de ce programme, les bénéficiaires — des élèves filles identifiées selon des critères précis de vulnérabilité, d'âge et de résultats scolaires — reçoivent une bourse scolaire versée directement à leur école ou à leur tuteur légal selon la configuration définie pour chaque tranche de paiement. Pour assurer la gestion rigoureuse, transparente et traçable de l'ensemble de ce dispositif, le programme PAAF s'appuie sur la **Plateforme Informatique de Gestion des Bourses pour les Filles (PIGBF)**, développée par **IT GROUP Sarl** (169, avenue Kasa-Vubu — Immeuble Triangle Davier — 2ème Niveau, Commune de la GOMBE, Kinshasa). La PIGBF est accessible à l'adresse **https://pigbf.org**. La PIGBF n'est pas un simple outil de saisie : c'est un **écosystème numérique complet** qui couvre l'intégralité du cycle de vie d'une bourse scolaire, depuis l'identification des bénéficiaires sur le terrain jusqu'au paiement effectif et au reporting de redevabilité auprès des bailleurs. `📸 Capture d'écran à insérer : Page d'accueil / écran de connexion de la PIGBF affichant le logo PAAF, la photo de fond illustrant des élèves filles, les champs Email et Mot de passe, et le titre "L'éducation des filles, un droit fondamental"` --- # A.1.1.2 — Ce que la plateforme permet de faire ## 1.2 Ce que la plateforme permet de faire La PIGBF est structurée autour de quatre grandes fonctions complémentaires, qui forment ensemble un cycle continu de gestion du programme : **1. Inscription et gestion des bénéficiaires** Centralisation des données des élèves, des écoles et des tuteurs. Chaque bénéficiaire reçoit un identifiant unique (UID) et un QR Code générés automatiquement par la plateforme. Des outils de détection et de traitement des doublons garantissent l'unicité de chaque dossier. Un processus de validation d'éligibilité contrôle les critères d'accès à la bourse (âge, fréquentation, résultats) avant tout paiement. **2. Gestion des paiements** Deux circuits de paiement sécurisés coexistent : **Equity BCDC** pour les virements bancaires vers les écoles (frais scolaires), et **Vodacom M-Pesa** pour les paiements mobile money aux tuteurs et élèves (subvention). Le cycle complet — génération des instructions → validation par le Validateur PAAF → envoi sécurisé par OTP (Equity) ou API (M-Pesa) → suivi des confirmations — est intégralement géré depuis la plateforme. **3. Suivi des conditionnalités** Collecte et suivi des notes scolaires et des présences des élèves via les formulaires ODK de terrain, permettant de vérifier à chaque tranche de paiement que les bénéficiaires respectent les conditions d'attribution de la bourse (taux de fréquentation minimum, seuil de résultats). **4. Administration, paramétrage et reporting** Gestion des utilisateurs et de leurs droits d'accès par rôle (RBAC), paramétrage des référentiels métier (classes, options, territoires, types de documents, etc.), gestion des années scolaires et de leur clôture, génération asynchrone de rapports paramétrables envoyés par email, et journal d'activités complet pour l'auditabilité de chaque action. `📸 Capture d'écran à insérer : Schéma du cycle complet de gestion d'une bourse : Identification terrain ODK → Validation IT → Base de production → Éligibilité paiement → Génération instructions → Validation PAAF → Envoi Equity/M-Pesa → Suivi confirmations → Reporting` --- # A.1.1.3 — Architecture du système ## 1.3 Architecture du système La PIGBF repose sur **deux applications Laravel distinctes et complémentaires** :
ApplicationRôleAccès
**laravel-pigbf**Interface d'administration (back-office) — l'application décrite dans ce manuelInternet — `pigbf.org`
**api-pigbf**Moteur d'intégration — gère les synchronisations ODK, les exports, les rapports lourds et les paiements Equity/M-PesaRéseau interne — `api.pigbf.org`
**Stack technique :** PHP 8.2+ · Laravel 12 · Livewire 3 · MySQL · Keycloak (SSO) · Ubuntu Server LTS · ODK Central. Du point de vue de l'administrateur, **une seule interface est à maîtriser** : le back-office accessible sur `pigbf.org`. L'application `api-pigbf` opère en arrière-plan de manière totalement transparente. Elle prend en charge tous les traitements longs ou sensibles : synchronisation avec ODK Central, génération de fichiers d'export volumineux, chiffrement PGP et dépôt SFTP des fichiers Equity, appels API M-Pesa. La plateforme front-office lui délègue ces tâches via des appels HTTP et récupère les résultats lorsqu'ils sont disponibles. **Collecte terrain :** Les enquêteurs de terrain n'ont aucun accès à l'interface web. Ils utilisent exclusivement l'application mobile **ODK Collect** (Android) pour collecter les données sur tablette, en mode déconnecté si nécessaire. Les données sont synchronisées vers le serveur **ODK Central** à la prochaine connexion réseau, puis traitées par le scheduler de l'API avant d'être mises à disposition pour validation dans la PIGBF. `📸 Capture d'écran à insérer : Schéma d'architecture simplifié à deux niveaux : (1) Enquêteurs → ODK Collect → ODK Central, (2) Administrateurs → pigbf.org (laravel-pigbf) ↔ api.pigbf.org (api-pigbf) → MySQL` --- # A.1.1.4 — Les utilisateurs de la plateforme — les 7 rôles ## 1.4 Les utilisateurs de la plateforme — les 7 rôles L'accès à la PIGBF est régi par un modèle de **contrôle d'accès basé sur les rôles (RBAC — Role-Based Access Control)**. Chaque utilisateur se voit attribuer un profil qui détermine précisément les modules, les pages et les actions (lecture, création, modification, suppression, validation) auxquels il a accès. La plateforme définit **7 rôles** :
RôlePérimètre d'action
**Super Admin**Accès total à toutes les fonctionnalités de la plateforme, tous programmes et toutes ONG confondus. Seul rôle pouvant créer d'autres Super Admins et modifier les paramètres système critiques.
**Admin**Administration générale de la plateforme sur le périmètre qui lui est assigné. Accès à la quasi-totalité des modules, hors paramétrage système réservé au Super Admin.
**Admin PAAF**Supervision du programme côté coordination PAAF. Accès aux données consolidées, aux paiements, aux rapports de tous les axes et ONG.
**Admin ONG**Gestion des opérations de **son ONG uniquement** : validation ODK, suivi des écoles/élèves/tuteurs de son périmètre, rapports. Accès cloisonné par organisation.
**Validateur paiement PAAF**Rôle **autonome** dédié exclusivement à la validation et à l'envoi des instructions de paiement Equity et M-Pesa. N'a pas accès aux modules de données bénéficiaires.
**Admin IT ONG**Profil technique au sein de l'ONG : gestion des enquêteurs, validation des données ODK, support à la collecte.
**Lecture seule**Consultation sans aucune modification possible — profil audit, supervision externe, bailleurs.
> **Important :** Ce manuel couvre le rôle **Administrateur Plateforme** (Super Admin / Admin), qui dispose du périmètre le plus étendu. Les sections B, C et D du présent manuel documentent respectivement les rôles Admin ONG / Admin IT ONG, Validateur de paiement et Enquêteur terrain ODK. `📸 Capture d'écran à insérer : Tableau ou diagramme des 7 rôles avec leurs niveaux d'accès respectifs aux grands modules : Bénéficiaires, Paiements, Validation ODK, Rapports, Paramètres, Utilisateurs` --- # A.1.1.5 — L'année scolaire — notion centrale du système ## 1.5 L'année scolaire — notion centrale du système Toutes les données de la PIGBF sont **filtrées par année scolaire active**. Cette notion est absolument centrale : chaque écran de liste, chaque rapport, chaque instruction de paiement, chaque statistique du tableau de bord est rattaché à une année scolaire spécifique. L'année scolaire active est affichée en permanence dans la barre supérieure de l'interface. Il est possible de consulter les données des années précédentes (en lecture seule après leur clôture) en changeant la sélection dans la barre supérieure, mais toute création ou modification de données ne s'applique qu'à l'année scolaire active. **Conditions préalables au démarrage d'une année :** Avant de pouvoir utiliser pleinement la plateforme pour une nouvelle année scolaire, un Super Admin doit avoir configuré l'année dans les Paramètres (cf. chapitre A.14) : création de l'année, définition du montant de la bourse par bénéficiaire, configuration des tranches de paiement et de leurs montants respectifs pour les écoles et pour les tuteurs/élèves. La **clôture d'une année scolaire** est une opération irréversible qui verrouille l'ensemble des données de l'année concernée : aucune création, modification ou suppression n'est possible après cette action. Elle est décrite en détail au chapitre A.14. --- # A.1.1.6 — Conventions et symboles utilisés dans ce manuel ## 1.6 Conventions et symboles utilisés dans ce manuel Tout au long de ce document, les conventions de la page de garde s'appliquent. Les captures d'écran sont indiquées par des emplacements réservés de la forme `📸 Capture d'écran à insérer : description détaillée du contenu attendu`. Ces emplacements seront remplacés par les captures réelles lors de la finalisation du manuel. Les procédures pas à pas sont toujours présentées sous forme d'étapes numérotées. Les actions irréversibles sont systématiquement signalées par le symbole ⚠️ avant leur description. --- # A.1.1.7 — Comment utiliser ce manuel ## 1.7 Comment utiliser ce manuel Ce manuel Section A est organisé en **15 chapitres** couvrant l'intégralité des fonctionnalités accessibles à l'Administrateur Plateforme : - **Chapitres A.1 à A.3** — Prise en main : présentation générale, connexion, tableau de bord - **Chapitres A.4 à A.8** — Données métier : organisations, écoles, élèves, tuteurs, validation ODK - **Chapitre A.9** — Paiements Equity BCDC et M-Pesa - **Chapitres A.10 à A.15** — Administration avancée : rapports, utilisateurs et acteurs, rôles et permissions, paramètres généraux, années scolaires, journal d'activités Chaque chapitre est conçu pour être consulté de façon autonome. Des renvois vers d'autres chapitres sont indiqués lorsqu'une action en prérequiert une autre. --- ---