Test des fonctionnalités & manuel d'utilisation par rôle

01 — Pourquoi ce document

Objet & complémentarité avec l'audit précédent

Le premier rapport (audit statique) a diagnostiqué la plateforme par lecture du code source et des sauvegardes SQL, sans exécution. Le présent document vient le compléter par un test dynamique : l'application a été déployée à l'identique et réellement parcourue, profil par profil. Il poursuit deux objectifs distincts :

02 — Comment les tests ont été menés

Environnement & méthode de test

L'application a été déployée en local via Docker, à partir de la sauvegarde transmise, sans modification du code : un conteneur applicatif (PHP 8.2 / Apache) et un conteneur base de données (MariaDB 11.8) chargé avec le dump de production u744010311_dcp_new.sql (29 tables, données réelles).

Protocole appliqué à chaque profil

• 1Connexion réelle avec le compte du profil, via le formulaire /admin/login (jeton CSRF + cookie de session).
• 2Relevé de l'écran d'accueil obtenu après connexion (URL finale après redirection, titre, contenu).
• 3Relevé du menu réellement affiché (liens de navigation présents dans la barre latérale).
• 4Test du contrôle d'accès : tentative d'accès direct, par l'URL, aux écrans d'administration théoriquement réservés (utilisateurs, rôles, entités, etc.).
• 5Captures d'écran authentiques : chaque écran présenté dans ce rapport est une capture réelle de l'application, prise par un navigateur piloté (Chromium/Playwright) après connexion effective au compte concerné — ce ne sont pas des maquettes.

03 — Le point d'entrée commun

Se connecter à la plateforme

La connexion est identique pour tous les profils. La différence de périmètre ne se joue qu'après l'authentification, en fonction du rôle rattaché au compte.

• 1Ouvrir l'adresse de la plateforme. La racine (/) redirige automatiquement vers la page de connexion /admin/login. test
• 2Saisir l'adresse e-mail et le mot de passe du compte, puis valider. L'e-mail sert d'identifiant.
• 3Arrivée sur un tableau de bord qui dépend du rôle : la plateforme oriente automatiquement vers la vue correspondant au profil (voir le manuel par profil ci-dessous).

http://localhost:8088/admin/login

04 — Qui est qui dans le système

Rôles & comptes de test

Un utilisateur est relié à un rôle et à une entité de la hiérarchie budgétaire (Ministère → Mission → Programme → BOP → UO, ou Direction). C'est ce couple rôle + entité qui détermine le tableau de bord affiché.

Par ailleurs, la table des rôles définit d'autres profils (Ministre, Admin du ministère, Directeur, Directeur Général, Responsable d'UO…) qui possèdent leur propre logique et parfois leur propre tableau de bord, mais ne sont rattachés à aucun compte dans la base actuelle. Ils sont décrits en section 10.

05 — Manuel du profil

Super Administrateur

Comment il se connecte

• 1Aller sur /admin/login, saisir superadmin@gmail.com et le mot de passe.
• 2Arrivée directe sur /admin/dashboard, en-tête « Tableau de bord - Administrateur du Système ».

http://localhost:8088/admin/dashboard

Ce qu'il peut faire (menu réellement affiché)

Le Super Administrateur est le seul profil pour lequel le menu d'administration complet s'affiche. Menu relevé au test : test

06 — Manuel du profil

Responsable de Mission

Comment il se connecte

• 1Connexion avec r.mission.mcp@gmail.com.
• 2La plateforme détecte le type d'entité « mission » et redirige vers le tableau de bord de mission.

http://localhost:8088/admin/mission-manager/dashboard

Ce qu'il voit et fait

• Synthèse financière de la mission (valeurs réelles relevées au test) : crédits, ordonnancements, paiements, taux de consommation. test
• Consommation des crédits par titre et graphiques par BOP du programme.
• Réalisation des activités par objectif pour la mission.
• Navigation en profondeur vers le détail d'un programme de la mission (/mission-manager/mission/{id}/programme/{id}).

07 — Manuel du profil

Responsable de Programme

http://localhost:8088/admin/programme-manager/dashboard

Ce qu'il voit et fait

• Vue consolidée du programme et de ses crédits. test
• Ventilation par BOP avec graphiques de consommation (relevés au test : BOP 2, BOP 4, BOP 10…).
• Réalisation des activités par objectif du programme.
• Détail d'un BOP via /programme-manager/programme/{id}/bop/{id}.

08 — Manuel du profil

Responsable de BOP

http://localhost:8088/admin/bop-manager/dashboard

Ce qu'il voit et fait

• Synthèse du BOP et de ses crédits. test
• Détail par Unité Opérationnelle — « Activités par objectif pour UO » relevé au test.
• Consultation d'une UO via /bop/{bop}/uo/{uo}.

09 — Manuel du profil

Point Focal (Direction)

Ce qu'il voit et fait

C'est l'écran le plus riche fonctionnellement : il agrège les statistiques trimestrielles de la direction (cibles/réalisations par objectif et par trimestre) et propose l'édition en ligne des activités.

http://localhost:8088/admin/dashboard (direction : DCP)

Actions disponibles depuis cet écran (routes confirmées) :

• Ajouter une activité / sous-activité (activity/store, sub-activity/store).
• Modifier en ligne une cellule (activity/inline-edit) — cible, réalisation, coût, paiement par trimestre.
• Valider une activité (activity/validate/{id}).
• Supprimer une activité / sous-activité (activity/{id}, sub-activity/{id}).

10 — Prévus dans le système, pas activés

Rôles définis mais non attribués

La table des rôles décrit plusieurs profils supplémentaires, avec pour certains un tableau de bord dédié déjà développé, mais aucun compte ne leur est rattaché dans la base testée. Ils n'ont donc pas pu être parcourus en conditions réelles ; ils sont listés ici pour l'exhaustivité du manuel.

11 — Vue d'ensemble

Cartographie des écrans & opérations

Écrans de type CRUD (générés par Backpack) et opérations autorisées, telles que configurées dans le code. code

À cela s'ajoutent les tableaux de bord métier (mission, programme, BOP, direction) et les routes d'action (saisie d'activités, enregistrement de crédits, BOP/UO) décrites dans le manuel par profil.

12 — Le constat central du test

Contrôle d'accès : démonstration dynamique

L'audit statique avait établi, par lecture du code, que le contrôle d'accès n'était pas appliqué côté serveur (VULN-001 / R-01, gravité Critique). Le test dynamique le confirme sans ambiguïté.

http://localhost:8088/admin/user — connecté en « Responsable de BOP »

Ce comportement s'explique par la cause déjà identifiée en audit : le contrôle d'admission (CheckIfAdmin::checkIfUserIsAdmin()) renvoie systématiquement true, et aucune Policy Laravel ne protège les écrans. code Le test ne fait que le rendre visible en conditions réelles.

13 — Ce qui casse ou dérive

Anomalies fonctionnelles observées

Autres observations confirmant l'audit

• Modèle de rôles inachevé — méthodes de détection de rôle inopérantes (noms anglais vs données françaises), rôles définis non attribués, aiguillage reposant sur un champ texte : cohérent avec R-08 (3 modèles de rattachement) et la dette technique. code SQL
• Vues « Old » / variantes multiples de tableau de bord présentes dans le code (dashboard-old, -ok, -test) — confusion sur ce qui est réellement actif (R-13). code
• Rangement hétérogène — un CreditController hors du namespace Admin, logique de crédits répartie entre plusieurs contrôleurs (cohérent avec R-10, logique dupliquée). code

14 — Points de vigilance, pas des mesures de charge

Performance observée au test

Le test n'est pas un banc de performance : il s'agit d'observations ponctuelles sur un environnement local à faible volume. Elles illustrent les risques de performance identifiés en audit (agrégations sur table non indexée, absence de cache, traitement synchrone).

15 — Du constat de test à la cible

Optimisation du fonctionnement par la refonte

Cette section relie chaque limite observée pendant les tests à la manière dont l'architecture cible proposée dans l'audit (React / Express / MongoDB, principes Zero Trust) permettrait de la corriger structurellement. Elle n'ajoute pas de nouvelle recommandation d'architecture : elle en démontre la pertinence à partir des faits de test.

Ce que la cible doit conserver de l'existant

• Le modèle métier (hiérarchie Ministère→…→Activité, suivi trimestriel des crédits par BOP/UO) — validé fidèle au test.
• La liste des rôles fonctionnels comme base d'un futur RBAC/ABAC propre.
• Les données existantes (à migrer via un plan dédié) et le journal d'audit comme socle de traçabilité.
• La logique des tableaux de bord par profil, déjà pensée par niveau (mission, programme, BOP, direction) — à réimplémenter en front réactif.

16 — En un regard

Conclusion

Le test dynamique confirme que la plateforme est fonctionnelle et fidèle au métier : chaque profil dispose d'un parcours cohérent — administration pour le Super Admin, pilotage par niveau pour les responsables de Mission, Programme et BOP, saisie opérationnelle pour le Point Focal. Le manuel par rôle ci-dessus documente ces parcours de bout en bout.

Il confirme aussi, en conditions réelles, le risque majeur de l'audit : le contrôle d'accès n'est pas appliqué côté serveur — un compte à périmètre restreint atteint l'ensemble des écrans d'administration. À cela s'ajoutent un écran « Programmes » en erreur et des signes de dette technique (modèle de rôles inachevé, vues « Old », page très lourde) déjà relevés par l'audit.

Ce rapport de test complète l'audit statique sans le remplacer. Les tests ont été menés sur un déploiement local à partir de la sauvegarde, sans modification du projet ni exploitation destructrice ; la configuration réseau de production reste à vérifier séparément.