Aller au contenu

Suivi du temps d’un cabinet d’audit

Suivi du temps des projets et des équipes d’un cabinet d’audit · Construit de zéro, en solo

Mis à jour

Avant

Clients, projets et heures vivaient au même endroit, où tout le cabinet pouvait tout voir et tout modifier.

Après

87

cases de permissions prouvées sur la base avant chaque déploiement ; les 30 inutiles ont été masquées.

Comment ça marche
  1. 1Personne:Propriétaire

    Crée des rôles avec des cases à cocher par domaine (clients, projets, temps, rapports) pour consulter, créer, modifier et supprimer.

  2. 2Personne:Collaborateur

    Saisit ses heures sur un client, un projet et une tâche, ou pose des congés.

    Logiciel:Application web

    Relance toute personne dont la feuille de temps est encore vide avant l’échéance.

  3. 3Personne:Administrateur de projet

    Approuve ou rejette la feuille de temps de la semaine pour l’équipe de son projet.

  4. 4Logiciel:Base de données

    Ne montre à chacun que ce que son rôle autorise : les collaborateurs voient leurs propres heures, les administrateurs de projet leur équipe, les propriétaires tous les clients.

  5. 5Personne:Propriétaire

    Consulte les heures par client, par projet et par personne dans les tableaux de bord et les rapports.

En continu

  • Avant, tout le cabinet pouvait ouvrir tous les clients et les heures de chacun. Désormais, la base de données refuse tout ce qu’un rôle n’autorise pas, même si un écran le demande.
  • Avant chaque push, chaque rôle est testé sur une copie isolée de la base de données.

Problème

Un cabinet d’audit gérait ses clients, ses projets et les heures de ses équipes dans un outil où chacun pouvait ouvrir tous les clients et le temps de tout le monde.

Diagnostic

Le contrôle d’accès échoue en silence quand il vit dans l’écran ; chaque règle devait donc vivre dans la base de données, prouvée par des tests.

Options étudiées

  1. Chaque rôle voit des données différentes. Où vivent les règles d’accès ?

    Retenue

    Dans la base de données elle-même, testées pour chaque rôle avant chaque déploiement

    L’écran ne peut pas divulguer ce que la base refuse. Coût : une exécution de tests sur une copie isolée avant chaque push.

    • Écartée

      Uniquement dans les écrans

      Une personne pouvait voir ou modifier des données que l’écran voulait masquer.

  2. Un enregistrement n’est plus utile. Le supprimer ou le conserver ?

    Retenue

    L’archiver et l’anonymiser

    L’historique des feuilles de temps reste intact.

    • Écartée

      Le supprimer

      La suppression entraîne en cascade celle de l’historique des feuilles de temps.

Solution

Une application web monopage sur Postgres managé. Chaque règle d’accès vit dans la base de données et est prouvée par une matrice de rôles automatisée avant chaque déploiement.

Application
  • React
  • Vite
  • TanStack Router
  • TanStack Query
  • shadcn/ui
  • Chart.js
Données et sécurité
  • Supabase
  • PostgreSQL row-level security
  • Edge Functions (Deno)
Hébergement
  • Cloudflare
Qualité
  • GitHub Actions
  • Role-matrix tests
  • Vitest
  • Property-based tests
  • Accessibility tests

Services associés

Chiffres: Contrôle automatisé des rôles, 2026-09-25