Audit technique, fonctionnel et sécurité de la plateforme DCP

01 — Pour le décideur

Synthèse exécutive

La plateforme répond à un besoin métier réel et dispose de plusieurs fondations techniques positives — mais plusieurs mécanismes critiques de sécurité et de gouvernance doivent être renforcés avant de considérer la plateforme comme durablement adaptée à un usage administratif sensible.

Ce que ce rapport établit

• Un diagnostic technique complet, chaque constat étant relié à une preuve vérifiable (code source, base de données, ou point à confirmer explicitement en production).
• Une évaluation des risques réels pour l'organisation — pas seulement des anomalies de code — avec leurs impacts potentiels sur la confidentialité, l'intégrité et la disponibilité des données budgétaires.
• Une matrice de priorisation actionnable (section 13) et une liste de mesures à traiter sans attendre une éventuelle modernisation (section 14).
• Une trajectoire de transformation en trois horizons, non une réécriture brutale (section 19).

Recommandation en un regard

Binaire SAS recommande une démarche en deux temps : (1) sécurisation immédiate de l'existant pour traiter les risques critiques identifiés, puis (2) une transformation progressive vers une architecture 3 tiers sécurisée intégrant les principes Zero Trust. Le détail de cette recommandation est développé en conclusion (section 23).

02 — Présentation de la mission

Mission & périmètre

Binaire SAS a été mandatée par la Direction du Contrôle de la Performance (DCP) de la DGCBF pour réaliser un audit indépendant de l'existant de sa plateforme de suivi de la performance budgétaire, développée sous Laravel/PHP. Cette première phase vise exclusivement à comprendre, auditer et documenter la solution en place, avant toute décision de modernisation.

Périmètre analysé : application Laravel 11 (PHP 8.2) du domaine dcp.dgcbf.online (contrôleurs, modèles, vues, migrations, configuration), deux sauvegardes de bases de données MySQL/MariaDB (dcp — ancien schéma, et dcp_new — base active), ainsi que les fichiers de dépendances et de configuration. Un second domaine présent dans la sauvegarde (page de parking par défaut) a été exclu, hors périmètre applicatif.

03 — Méthodologie

Méthodologie

Analyse statique ciblée : cartographie du framework et des dépendances, lecture des fichiers à forte valeur d'information (contrôleurs, modèles, middlewares, migrations, configuration), recherches par mots clés pour les risques de sécurité, inspection structurelle de la base de données. Chaque constat de ce rapport est relié à une preuve technique précise.

04 — Ce que ces failles signifient pour l'organisation

Risques majeurs pour l'organisation

Les trois constats suivants ne sont pas de simples anomalies de code : ils déterminent si l'organisation peut aujourd'hui garantir que ses données budgétaires et administratives sont accédées, modifiées et conservées par les seules personnes habilitées.

05 — Le cadre d'analyse

Les trois dimensions de la sécurité

Tout risque identifié dans ce rapport se rattache à l'une de ces trois dimensions. Pour une plateforme de suivi budgétaire, l'intégrité des données mérite une attention particulière : une donnée budgétaire modifiée sans autorisation ou de façon incohérente peut fausser une décision, même sans qu'aucune donnée n'ait « fuité ».

06 — État des lieux technique

Architecture existante

Application monolithique Laravel 11, structurée autour du package d'administration Backpack/CRUD 6.7, qui génère l'essentiel de l'interface. Pas de séparation frontend/backend au sens moderne : les vues sont des templates Blade rendus côté serveur. Preuve : code source

Notes par axe

Signe fort d'évolution non maîtrisée : deux modèles de hiérarchie coexistent dans la base (l'ancien couple Ministère/Direction, et une table générique entities auto-référencée), doublés de trois tables pivot distinctes reliant un utilisateur à son périmètre et à son rôle — principale source de risque d'incohérence fonctionnelle identifiée.

07 — Ce que fait réellement l'application

Analyse fonctionnelle

Domaine métier reconstruit à partir du code, hiérarchie à six niveaux :

Anomalies fonctionnelles identifiées

• Trois systèmes de rattachement utilisateur↔périmètre coexistants : selon l'écran, l'application peut afficher des données différentes pour un même utilisateur.
• Code et vues « Old » laissés en production, source de confusion sur ce qui est réellement actif.
• Totaux de crédits stockés sans mécanisme garantissant leur cohérence avec le détail trimestriel.

08 — Détail technique

Audit sécurité

Les trois constats les plus critiques (VULN-001 à VULN-003) sont détaillés en fiche section 04. Le tableau ci-dessous couvre l'ensemble des constats de sécurité, y compris ceux de gravité moindre.

Points vérifiés sans anomalie détectée

• Mots de passe hachés en bcrypt — conforme aux bonnes pratiques.
• Aucune désactivation de la protection CSRF trouvée.
• Aucun mass assignment ouvert ($guarded = []) sur les modèles.
• Aucune injection SQL exploitable trouvée dans le code applicatif propre.

09 — Structure et intégrité

Audit base de données

Preuve : base SQL La base active (dcp_new, 29 tables, MariaDB 11.8) est globalement bien construite : clés primaires, étrangères et index correctement posés sur la majorité des tables métier.

Bonnes pratiques observées : montants financiers typés en decimal(15,2) (pas de float), usage cohérent des clés primaires bigint unsigned. Les deux dumps contiennent des données à caractère personnel réelles — non reproduites dans ce rapport, à traiter avec la même confidentialité qu'une base de production.

10 — Points de vigilance, pas des mesures

Audit performance

Aucun environnement d'exécution n'étant disponible, cette section liste des risques identifiés dans le code, jamais des mesures réelles.

• Agrégations financières sur table non indexée — les requêtes de somme sur les crédits s'exécuteront en parcours complet de table à mesure que le volume augmente.
• Logique dupliquée dans 4 contrôleurs — tout correctif de performance doit être répliqué manuellement à 4 endroits.
• Absence de cache applicatif sur les tableaux de bord.
• Traitement 100% synchrone — l'infrastructure de file d'attente est provisionnée en base mais inutilisée dans le code.

Contexte atténuant : le volume de données actuel reste celui d'un environnement pilote — ces risques ne deviendront probablement sensibles qu'avec la croissance des exercices budgétaires.

11 — Coût des évolutions futures

Qualité et dette technique

12 — Hébergement et déploiement

Audit infrastructure

13 — Vue consolidée et actionnable

Matrice des risques

Chaque risque est relié à une action corrective, une priorité (P0 à P3) et un horizon de traitement recommandé.

14 — À traiter avant toute autre décision

Urgences de sécurisation

Ces mesures ne doivent pas attendre une éventuelle migration vers une nouvelle architecture — elles s'appliquent sur la plateforme actuelle, en service aujourd'hui.

15

Forces & faiblesses

16 — Vision, pas décision automatique

Architecture cible proposée

L'orientation React / Express / MongoDB n'est pas retenue parce qu'elle serait « plus moderne », mais parce qu'elle répond à des objectifs architecturaux précis :

Comparaison des architectures

Comparaison objective avec l'existant

17 — Une distinction essentielle

VPN vs Zero Trust

Dans la cible proposée (section 16), le VPN/ZTNA reste une couche pertinente pour restreindre l'exposition réseau de l'interface d'administration — mais le contrôle d'accès réel doit être appliqué au niveau de l'API, indépendamment du réseau d'où provient la requête.

18 — Traduction architecturale

Architecture Zero Trust — vue d'ensemble

19 — Pas une réécriture brutale

Trajectoire de modernisation — trois horizons

20 — Ce que coûte le statu quo

Coût de l'inaction

Sans chiffrage financier inventé, le maintien de l'architecture actuelle sans action corrective a des conséquences prévisibles :

• Maintien des risques de sécurité identifiés (VULN-001 à 003) sur une plateforme en service
• Augmentation continue de la dette technique (section 11)
• Coût croissant de chaque nouvelle évolution fonctionnelle
• Risque de régression accru en l'absence de tests
• Complexité croissante du modèle de données non unifié
• Difficulté durable de contrôle des habilitations
• Dépendance croissante à l'existant, rendant toute reprise plus coûteuse dans le temps
• Difficulté d'intégration avec de futurs systèmes de l'administration
• Difficulté à industrialiser les déploiements (absence de CI/CD observée)
• Difficulté à appliquer une politique de sécurité homogène sur un socle hétérogène

21 — Plus qu'un changement de framework

Étendue potentielle du programme de transformation

La modernisation ne se résume pas à « remplacer Laravel par React/Express/MongoDB ». Un programme de transformation complet couvre potentiellement :

Aucun coût n'est chiffré dans ce rapport en l'absence de données permettant de le justifier — l'étape suivante recommandée est un atelier de cadrage dédié (section 23).

22 — De l'audit à la supervision

Feuille de route visuelle

23

Conclusion & recommandation

La plateforme DCP répond aujourd'hui à un besoin métier réel et bien modélisé, mais porte une faille de contrôle d'accès critique qui doit être corrigée sans attendre, ainsi qu'une dette technique importante qui limitera sa capacité d'évolution si elle n'est pas traitée.

La modernisation doit être cadrée par une étude fonctionnelle, technique, budgétaire et de migration avant son lancement — ce cadrage fait l'objet d'une mission distincte, non couverte par le présent audit. Binaire SAS se tient à la disposition de la DCP/DGCBF pour accompagner la priorisation et la mise en œuvre de ces recommandations.

↑ Retour en haut du rapport