A.15 — Logs et journal d'activités Chapitre A.15 du Manuel PIGBF A.15.15.1 — Vue d'ensemble 15.1 Vue d'ensemble La PIGBF dispose d'un journal d'activités complet qui enregistre automatiquement toutes les actions significatives réalisées par les utilisateurs sur la plateforme. Ce journal est un outil d'auditabilité essentiel pour : Tracer qui a fait quoi, quand et sur quel enregistrement Investiguer les anomalies ou erreurs constatées dans les données Répondre aux exigences d'audit des bailleurs et de la coordination PAAF Détecter des comportements inhabituels (accès suspect, modifications massives non attendues) Le module Logs se divise en deux journaux distincts : Journal Contenu Accès Journal d'activités Toutes les actions sur les entités métier (création, modification, validation, suppression d'écoles, élèves, tuteurs, paiements…) Menu → Logs Journal de collecte Historique détaillé des soumissions ODK traitées (formulaire, enquêteur, date de collecte, Sous-Proved, résultat de l'intégration) Menu → Logs → Collecte A.15.15.2 — Journal d'activités 15.2 Journal d'activités 15.2.1 Accéder au journal Menu latéral → Logs . 📸 Capture d'écran à insérer : Page "Journal d'activités" : zone de filtres en haut (Recherche par description, Module/Log name, Type d'événement, Utilisateur auteur, Date de — Date jusqu'au, Nb par page, bouton Réinitialiser les filtres) ; tableau principal avec colonnes : Utilisateur (avatar + nom), Action/Description, Module concerné, Événement (badge : created/updated/deleted/validated), Objet modifié (type + ID), Date et heure ; pagination en bas ; lien "Voir les détails" sur chaque ligne 15.2.2 Comprendre les colonnes du journal Colonne Description Utilisateur L'utilisateur qui a réalisé l'action (nom + avatar). Les actions système automatisées (jobs, scheduler) sont identifiées par « Système » Description Résumé lisible de l'action (ex : « École Lycée de la Paix créée », « Élève Furaha Mwamba validée pour paiement tranche 1 ») Module Nom du journal auquel appartient cet événement (ex : ecoles , eleves , paiements , utilisateurs , settings ) Événement Type d'action : created (création), updated (modification), deleted (suppression), ou événements métier spécifiques ( validated , rejected , sent …) Objet modifié Type et identifiant de l'enregistrement concerné (ex : Ecole #147 , Eleve #2304 ) Date et heure Horodatage précis de l'action (format JJ/MM/AAAA HH:MM:SS ) 📸 Capture d'écran à insérer : Tableau du journal avec 5 lignes d'exemple : ligne 1 "Jean Mutombo | École Lycée de la Paix créée | ecoles | created | Ecole #147 | 12/06/2026 09:14:22" ; ligne 2 "Marie Kalala | Élève Furaha Mwamba validée pour paiement tranche 1 | paiements | validated | Eleve #2304 | 12/06/2026 10:31:07" ; ligne 3 "Système | QR Code généré | eleves | updated | Eleve #2304 | 12/06/2026 10:31:10" ; badges colorés pour chaque type d'événement (created=vert, updated=bleu, deleted=rouge, validated=violet) 15.2.3 Filtrer le journal La zone de filtres en haut de page permet de cibler rapidement les événements pertinents : Recherche par description — Saisissez un mot-clé (nom d'école, nom d'élève, action…) pour filtrer les lignes dont la description contient ce terme. Module (Log name) — Sélectionnez un module dans la liste déroulante pour n'afficher que les événements de ce module (ex : n'afficher que les logs du module paiements). Type d'événement — Filtrez par type : created , updated , deleted , ou événements métier. Utilisateur auteur — Sélectionnez un utilisateur dans la liste pour voir uniquement ses actions. Plage de dates — Définissez une période (Date de / Date jusqu'au) pour restreindre la recherche à un intervalle temporel. Nombre par page — Choisissez le nombre de lignes à afficher (10, 25, 50, 100). 📸 Capture d'écran à insérer : Zone de filtres du journal avec des sélections actives : Module "paiements" sélectionné, Événement "validated", Date de 01/06/2026 au 12/06/2026 ; le tableau en dessous n'affiche que les validations de paiements sur cette période Pour réinitialiser tous les filtres simultanément, cliquez sur Réinitialiser les filtres . 15.2.4 Consulter le détail d'un événement Cliquez sur le lien Voir les détails sur une ligne du journal pour ouvrir la fenêtre modale de détail : 📸 Capture d'écran à insérer : Modale "Détails de l'événement" : bloc supérieur (Utilisateur : nom + avatar, Date : horodatage exact, Module, Événement, Objet concerné : type + ID + lien vers la fiche si applicable) ; bloc "Données avant modification" (ancien état JSON formaté et coloré) ; bloc "Données après modification" (nouvel état JSON formaté et coloré, différences surlignées en vert/rouge) ; bouton "Fermer" Cette vue de détail est particulièrement utile pour : - Identifier précisément quel champ a été modifié et quelle était la valeur précédente - Vérifier qu'une modification erronée peut être corrigée manuellement - Fournir des preuves documentées en cas de contestation ou d'audit ℹ️ Note : L'état « avant » est vide pour les événements de type created (l'enregistrement n'existait pas). L'état « après » est vide pour les événements de type deleted . A.15.15.3 — Journal de collecte 15.3 Journal de collecte 15.3.1 Présentation Le journal de collecte trace l'historique des soumissions ODK qui ont été traitées par api-pigbf et mises à disposition pour validation dans la PIGBF. Contrairement au journal d'activités qui enregistre les actions des utilisateurs web, le journal de collecte enregistre les événements de collecte terrain . Menu latéral → Logs → Collecte . 📸 Capture d'écran à insérer : Page "Journal de collecte" : zone de filtres (Recherche par enquêteur, Form ID ou ID instance, Année scolaire, Sous-Proved, Date de collecte Du/Au, Nb par page, Réinitialiser) ; tableau principal avec colonnes : Enquêteur (label ODK), Formulaire (form_id), ID Instance ODK (identifiant unique de la soumission), Sous-Proved, Année scolaire, Date de collecte, Statut d'intégration (badge : Intégré / En attente / Rejeté) ; pagination 15.3.2 Colonnes du journal de collecte Colonne Description Enquêteur Identifiant (label) ODK de l'enquêteur qui a soumis le formulaire Formulaire Identifiant du formulaire ODK (form_id : ex : identification_eleves , frais_scolaires …) ID Instance Identifiant unique de la soumission dans ODK Central ( form_instance_id ). Permet de retrouver la soumission exacte dans ODK Central en cas de litige Sous-Proved Sous-Proved du formulaire concerné (issu des métadonnées de la soumission) Année scolaire Année scolaire associée à cette collecte Date de collecte Date à laquelle les données ont été collectées sur le terrain (pas la date de synchronisation) Statut Intégré = données traitées et disponibles en validation ; En attente = données reçues, pas encore traitées ; Rejeté = données rejetées lors de la validation 📸 Capture d'écran à insérer : Tableau journal de collecte avec 6 lignes d'exemple : plusieurs soumissions de différents enquêteurs, différents formulaires (frais_scolaires, identification_eleves), statuts variés (Intégré en vert, En attente en orange) ; filtre "Sous-Proved : Tshikapa 1" actif visible dans la zone de filtres 15.3.3 Filtrer le journal de collecte Recherche — Filtrez par nom d'enquêteur, identifiant de formulaire ou identifiant d'instance ODK. Année scolaire — Sélectionnez une année scolaire dans la liste déroulante. Sous-Proved — Filtrez par Sous-Proved pour ne voir que les collectes d'une zone géographique précise. Plage de dates — Définissez une période de collecte pour restreindre l'affichage. 📸 Capture d'écran à insérer : Zone de filtres du journal de collecte avec "Année scolaire : 2025-2026", "Sous-Proved : Kamonia" et dates "01/05/2026 au 31/05/2026" sélectionnés ; tableau filtré affichant uniquement les collectes correspondantes A.15.15.4 — Bonnes pratiques — Logs et journal d'activités 15.4 Bonnes pratiques — Logs et journal d'activités Consulter le journal avant toute investigation sur une anomalie. Avant de modifier manuellement une donnée qui semble incorrecte, consultez le journal pour comprendre la chronologie des modifications : qui a modifié le champ concerné, quand, et quelle était la valeur précédente. Utiliser les filtres de dates pour les audits périodiques. Pour un audit mensuel, filtrez le journal sur le mois écoulé et exportez ou prenez des captures d'écran des actions sensibles (validations de paiements, modifications de montants, créations d'utilisateurs). Croiser journal d'activités et journal de collecte. Lorsqu'une école ou un élève présente des données incohérentes, il peut être utile de vérifier dans le journal de collecte quelle soumission ODK est à l'origine de l'enregistrement, puis dans le journal d'activités si des modifications manuelles ont été apportées après intégration. Signaler immédiatement les événements suspects. Toute action effectuée par un utilisateur dont le compte devrait être suspendu, ou tout volume inhabituel de suppressions ou modifications en masse, doit être signalé immédiatement à l'équipe IT GROUP (support@itgroup.cd) avec la référence de l'événement visible dans le journal. Conserver l'historique. Les journaux ne sont pas purgés automatiquement. Leur conservation intégrale garantit la traçabilité complète sur toute la durée du programme. Ne jamais supprimer des entrées du journal, même en cas d'erreur. Fin du document — Sections A.1 à A.15 Session 6 à venir : Section B complète — Administrateur ONG / Admin IT ONG (chapitres B.1 à B.8) Note de rédaction — Consignes pour la suite Les notes suivantes sont à conserver d'une session à l'autre pour garantir la cohérence du manuel. Densité et niveau de détail : Chaque chapitre doit décrire toutes les zones de l'interface, toutes les colonnes des tableaux, tous les champs des formulaires et toutes les actions possibles. Ne pas résumer ce qui peut être détaillé. Screenshots : Placer un 📸 Capture d'écran à insérer : description à chaque fois qu'un état d'interface, une modale, un formulaire, un résultat ou un comportement est décrit pour la première fois. Minimum 2–3 screenshots par sous-section fonctionnelle. Tableaux de référence : Toutes les listes de colonnes, champs, statuts, permissions et types doivent être présentées en tableau pour faciliter la lecture. Alertes ⚠️ : Systématiquement signaler les actions irréversibles, les effets de bord immédiats (modification de rôle, clôture d'année) et les règles métier bloquantes (somme 100% des tranches Equity, filtre Province obligatoire pour les rapports). Structure cohérente : Chaque module suit le plan : Vue d'ensemble → Accès au module → Fonctionnalités détaillées étape par étape → Bonnes pratiques / Points de vigilance.