🔍 Audit de l'application GestionRH - 10/07/2026

Audit réalisé par Claude à la demande de Seer MENSAH-ASSIAKOLEY. Périmètre : application de gestion RH multi-établissements (gestionrh-github/). Nature : audit documentaire et technique - aucune modification du code applicatif, aucun commit. Tous les livrables sont dans ce dossier.

🧭 Comment lire cet audit

Commencez par la synthèse exécutive, puis descendez dans le détail selon votre besoin.

📸 Le projet en une image

• Nom : GestionRH - « Multi-établissements »
• Usage : gérer les salariés, plannings, congés, paie (éléments variables), transport et registre du personnel d'un réseau de boutiques/franchises réparties par ville (Paris, Bordeaux, Lyon).
• Utilisateurs : admin (siège/RH), manager (responsable boutique/ville, périmètre restreint), employee (salarié, self-service).
• Stack : React + Vite + Tailwind (front) · Supabase (base + auth + fichiers) · Netlify (hébergement). Pas de Java, pas de serveur applicatif dédié.
• Taille du code : ~2 800 lignes concentrées dans un seul fichier App.jsx.

🚦 Verdict en 30 secondes

Ce qui est remarquable : pour un produit « one-file », la couverture fonctionnelle est impressionnante (planning, paie variable, transport avec justificatifs, historique de contrats, registre du personnel, self-service salarié, alertes d'échéances). L'UX est soignée et cohérente.

Ce qui doit être corrigé en priorité :

1. 🔴 Sécurité - RLS permissive : n'importe quel compte connecté peut lire et modifier toutes les données (salaires, données personnelles) via l'API, quel que soit son rôle. Le cloisonnement n'existe que dans l'interface.
2. 🟠 Dette structurelle - monolithe : tout dans App.jsx, sans tests, sans lint, édité directement sur main via l'UI GitHub. Maintenance et évolution risquées.
3. 🟠 Schéma de base non documenté : des tables utilisées par le code (transport_receipts, planning_notes, contract_history) ne figurent dans aucune migration SQL du dépôt.

Le détail, les impacts et le plan d'action sont dans la synthèse exécutive.

🗂️ Arborescence de l'audit

docs/audits/audit_10_07_26_Seer/
├── README.md                          ← vous êtes ici
├── 00-synthese-executive.md
├── 01-technologies-et-architecture.md
├── 02-conventions-et-organisation-code.md
├── adr/
│   ├── README.md                      (index + lien vers le format ADR)
│   ├── _template-adr.md
│   ├── 0001-stack-react-vite-supabase-netlify.md
│   ├── 0002-application-monolithique-app-jsx.md
│   ├── 0003-rls-permissive-controle-cote-client.md
│   ├── 0004-multi-tenant-par-scope-applicatif.md
│   ├── 0005-planning-source-de-verite-de-la-paie.md
│   └── 0006-export-csv-pour-la-comptabilite.md
├── features/
│   ├── on-place/    (auth, salariés, planning, congés, paie, transport, registre, contrats, alertes)
│   └── futures/     (alertes avancées, export comptable, nouvelles fonctionnalités, conformité, technique)
├── scenarios/
│   ├── README.md
│   └── user-journeys.md
├── backlog/
│   ├── product-backlog.md
│   └── release-planning.md
├── tech/
│   ├── stack-et-bonnes-pratiques.md
│   ├── commandes-utiles.md
│   └── export-comptable-besoins.md
└── prompts/
    ├── README.md
    ├── 01-corriger-un-bug.md
    ├── 02-refactor-decoupage.md
    ├── 03-nouvelle-fonctionnalite.md
    ├── 04-revue-de-code.md
    └── 05-durcir-securite-rls.md

Des routines réutilisables (commandes /ouverture-session, /preparer-commits, /audit-refresh) sont installées dans .claude/commands/ à la racine du dépôt.

⚖️ Méthode & limites

• Audit statique : lecture du code (App.jsx, fichiers supabase-*.sql, configuration) et de l'historique Git. L'application n'a pas été exécutée avec des données réelles (pas d'accès à l'instance Supabase de production).
• Les constats « base de données » se fondent sur ce que le code appelle (supabase.from(...), storage.from(...)) et sur les migrations présentes.
• Les recommandations sont priorisées (P0 → P3) mais non estimées en jours ; voir le release planning pour un séquencement.