# 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** :

<table id="bkmrk-journal-contenu-acc%C3%A8"><thead><tr><th>Journal</th><th>Contenu</th><th>Accès</th></tr></thead><tbody><tr><td>**Journal d'activités**</td><td>Toutes les actions sur les entités métier (création, modification, validation, suppression d'écoles, élèves, tuteurs, paiements…)</td><td>Menu → Logs</td></tr><tr><td>**Journal de collecte**</td><td>Historique détaillé des soumissions ODK traitées (formulaire, enquêteur, date de collecte, Sous-Proved, résultat de l'intégration)</td><td>Menu → Logs → Collecte</td></tr></tbody></table>

---

# 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**.

`<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> 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</callout>`

### 15.2.2 Comprendre les colonnes du journal

<table id="bkmrk-colonne-description-"><thead><tr><th>Colonne</th><th>Description</th></tr></thead><tbody><tr><td>**Utilisateur**</td><td>L'utilisateur qui a réalisé l'action (nom + avatar). Les actions système automatisées (jobs, scheduler) sont identifiées par « Système »</td></tr><tr><td>**Description**</td><td>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 »)</td></tr><tr><td>**Module**</td><td>Nom du journal auquel appartient cet événement (ex : `ecoles`, `eleves`, `paiements`, `utilisateurs`, `settings`)</td></tr><tr><td>**Événement**</td><td>Type d'action : `created` (création), `updated` (modification), `deleted` (suppression), ou événements métier spécifiques (`validated`, `rejected`, `sent`…)</td></tr><tr><td>**Objet modifié**</td><td>Type et identifiant de l'enregistrement concerné (ex : `Ecole #147`, `Eleve #2304`)</td></tr><tr><td>**Date et heure**</td><td>Horodatage précis de l'action (format `JJ/MM/AAAA HH:MM:SS`)</td></tr></tbody></table>

`<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> 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)</callout>`

### 15.2.3 Filtrer le journal

La zone de filtres en haut de page permet de cibler rapidement les événements pertinents :

1. **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.
2. **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).
3. **Type d'événement** — Filtrez par type : `created`, `updated`, `deleted`, ou événements métier.
4. **Utilisateur auteur** — Sélectionnez un utilisateur dans la liste pour voir uniquement ses actions.
5. **Plage de dates** — Définissez une période (Date de / Date jusqu'au) pour restreindre la recherche à un intervalle temporel.
6. **Nombre par page** — Choisissez le nombre de lignes à afficher (10, 25, 50, 100).

`<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> 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</callout>`

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 :

`<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> 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"</callout>`

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**.

`<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> 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</callout>`

### 15.3.2 Colonnes du journal de collecte

<table id="bkmrk-colonne-description-"><thead><tr><th>Colonne</th><th>Description</th></tr></thead><tbody><tr><td>**Enquêteur**</td><td>Identifiant (label) ODK de l'enquêteur qui a soumis le formulaire</td></tr><tr><td>**Formulaire**</td><td>Identifiant du formulaire ODK (form\_id : ex : `identification_eleves`, `frais_scolaires`…)</td></tr><tr><td>**ID Instance**</td><td>Identifiant unique de la soumission dans ODK Central (`form_instance_id`). Permet de retrouver la soumission exacte dans ODK Central en cas de litige</td></tr><tr><td>**Sous-Proved**</td><td>Sous-Proved du formulaire concerné (issu des métadonnées de la soumission)</td></tr><tr><td>**Année scolaire**</td><td>Année scolaire associée à cette collecte</td></tr><tr><td>**Date de collecte**</td><td>Date à laquelle les données ont été collectées sur le terrain (pas la date de synchronisation)</td></tr><tr><td>**Statut**</td><td>`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</td></tr></tbody></table>

`<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> 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</callout>`

### 15.3.3 Filtrer le journal de collecte

1. **Recherche** — Filtrez par nom d'enquêteur, identifiant de formulaire ou identifiant d'instance ODK.
2. **Année scolaire** — Sélectionnez une année scolaire dans la liste déroulante.
3. **Sous-Proved** — Filtrez par Sous-Proved pour ne voir que les collectes d'une zone géographique précise.
4. **Plage de dates** — Définissez une période de collecte pour restreindre l'affichage.

`<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> 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</callout>`

---

# 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 `<callout class="info">📸 <strong>Capture d'écran à insérer :</strong> description</callout>` à 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.

---