00 - Synthèse exécutive
Note globale
| Axe | Note | Commentaire |
|---|---|---|
| Couverture fonctionnelle | 🟢 A | Très riche pour la taille : planning, paie variable, transport, contrats, self-service. |
| Expérience utilisateur (UI) | 🟢 A- | Design cohérent (Tailwind), navigation claire, alertes visibles. |
| Sécurité & confidentialité | 🔴 D | RLS permissive : cloisonnement uniquement côté client. Données sensibles exposées via l'API. |
| Qualité & maintenabilité du code | 🟠 C- | Monolithe de 2 800 lignes, 0 test, 0 lint, 0 typage, commits directs sur main. |
| Fiabilité des données / schéma | 🟠 C | Tables non documentées, dépendances de dates UTC/local incohérentes. |
| Conformité RH / RGPD | 🟠 C | Manque gestion des documents à échéance, traçabilité, minimisation des données. |
| Global | 🟠 C+ | Excellent produit fonctionnel posé sur des fondations techniques fragiles. |
L'essentiel en une page
GestionRH est une application étonnamment complète pour un réseau de boutiques multi-sociétés. Elle couvre le cycle RH courant : dossier salarié, contrats et avenants historisés, planning hebdomadaire par ville, congés/absences avec solde de CP, calcul des éléments variables de paie à partir du planning, remboursement transport avec justificatifs, registre du personnel, et un espace self-service pour les salariés. L'interface est propre et l'ergonomie pensée.
Le problème n'est pas fonctionnel, il est structurel :
La sécurité repose entièrement sur l'interface. Côté base, chaque personne authentifiée peut tout lire et tout écrire. Un manager - voire un salarié - peut, en contournant l'UI (console, requête directe à l'API Supabase avec la clé
anonpublique), consulter ou modifier les salaires et données personnelles de tout le monde. C'est le risque n°1, à la fois sécurité et RGPD.Tout le code tient dans un fichier de 2 800 lignes, sans tests, sans linting, sans typage, et l'historique montre des modifications faites directement sur
mainvia l'éditeur web GitHub. Chaque évolution est risquée (régressions invisibles) et la collaboration est quasi impossible.Le schéma de base a dérivé : le code lit/écrit des tables (
transport_receipts,planning_notes,contract_history) qui n'apparaissent dans aucune migration du dépôt. Impossible de recréer l'environnement à l'identique à partir du repo.
Le reste de l'audit détaille l'existant, ce qui manque (notamment les alertes RH et l'export comptable), et propose un backlog priorisé.
Top 10 des constats
🔴 Bloquants (P0)
| # | Constat | Impact | Où |
|---|---|---|---|
| 1 | RLS Supabase totalement permissive (auth.role() = 'authenticated' sur toutes les tables) |
Fuite/altération de toutes les données (salaires, RIB, données perso) par tout compte connecté | supabase-schema.sql:90-94, -payroll.sql, -planning.sql |
| 2 | Tables non documentées (transport_receipts, planning_notes, contract_history, bucket employee-docs) |
Environnement non reproductible ; onboarding impossible depuis le repo | App.jsx (supabase.from(...)) vs supabase-*.sql |
🟠 Majeurs (P1)
| # | Constat | Impact | Où |
|---|---|---|---|
| 3 | Monolithe App.jsx (~2 800 lignes) sans découpage |
Maintenabilité, temps de compréhension, conflits | src/App.jsx |
| 4 | Aucun test, aucun lint, aucun typage | Régressions silencieuses (paie, dates) | package.json |
| 5 | Commits directs sur main via l'UI GitHub |
Pas de revue, pas de traçabilité, pas de rollback propre | historique Git |
| 6 | Incohérence de dates UTC vs local (toISOString().slice(0,10) mêlé aux helpers locaux) |
Décalages d'un jour possibles sur planning/paie autour de minuit | App.jsx computeHoursFromPlanning vs getMonday/addDays |
🟡 Importants (P2)
| # | Constat | Impact | Où |
|---|---|---|---|
| 7 | Alertes incomplètes : pas d'alerte anniversaire (perso), documents à valider, titre de séjour, visite médicale | Oublis RH à risque légal | App.jsx const alerts |
| 8 | Export comptable limité au CSV récap | Ressaisie côté cabinet, pas de format normalisé par société | App.jsx exportPayrollCSV |
| 9 | Pas de notification hors-app (email/SMS) | Les alertes ne servent qu'à qui se connecte | - |
| 10 | .env.example référencé mais absent ; README évoque des étapes non reproductibles |
Friction d'installation | README.md vs repo |
Le détail complet est dans features/futures et le backlog.
Plan d'action recommandé (résumé)
| Horizon | Objectif | Actions clés |
|---|---|---|
| Immédiat (P0) | Fermer le trou de sécurité et fiabiliser le repo | Écrire des policies RLS par rôle/périmètre ; committer toutes les migrations manquantes ; ajouter .env.example, .gitignore |
| Court terme (P1) | Rendre le code évolutif | Découper App.jsx (pages/composants/services/hooks) ; ESLint + Prettier ; premiers tests sur la logique paie ; flux branche → PR |
| Moyen terme (P2) | Compléter la valeur RH | Alertes avancées (anniversaires, documents, titres de séjour, visite médicale) ; module export comptable normalisé par société ; notifications email |
| Long terme (P3) | Industrialiser | Reporting/analytics (turnover, masse salariale, absentéisme) ; onboarding/offboarding ; conformité RGPD (registre, durées de conservation) |
Voir le release planning pour le séquencement en versions.
Ce qui est vraiment bien (à conserver)
- Le modèle « planning = source de vérité de la paie » (heures calculées depuis le planning, majorations dimanche, heures sup) - élégant et juste.
- L'historique de contrats (
contract_history) avec la version « en vigueur à la date » (contractAsOf) - rare et précieux pour la paie et le juridique. - Le self-service salarié (ma fiche, mon planning, dépôt de justificatif transport).
- L'export CSV « compatible Lys-MPG » : la bonne intention est là, il faut la généraliser et la normaliser.
- La cohérence visuelle et les primitives UI (Btn, Modal, Badge, Card…) bien factorisées - une bonne base pour un futur design system.