Suivi des temps en cabinet d'audit : 4 erreurs silencieuses

Je suis Denys, ingénieur full-stack et IA. De mai à octobre 2026, un cabinet d’audit est passé d’un outil où chacun pouvait ouvrir tous les clients à un outil de suivi que j’ai construit pour lui seul, en 388 commits. Le cabinet n’est pas nommé ici. Ce texte s’adresse à ceux qui dirigent un cabinet et choisissent ses outils : ce qu’un cabinet d’audit attend du suivi des temps, les quatre erreurs que j’ai trouvées et la façon de vérifier n’importe quel outil.

Que faut-il à un cabinet d’audit pour le suivi des temps ?

Un cabinet d’audit vend des heures : la gestion des temps est donc le registre sur lequel repose toute l’activité. Le cabinet pour lequel j’ai construit l’outil avait besoin de :

• Heures par client, projet et tâche. Chaque saisie appartient à une seule mission, ce qui permet de lire les heures par client, par projet et par personne.
• Feuilles de temps hebdomadaires avec validation. Les collaborateurs soumettent la semaine, l’administrateur du projet valide ou rejette chaque saisie, et seules les heures validées comptent.
• Rappels. Toute personne dont la feuille de temps est encore vide avant l’échéance reçoit un e-mail. Depuis septembre 2026, il ne relance que pour les heures manquantes et ignore les personnes dont la capacité est nulle.
• Planification des ressources. Qui travaille sur quelle mission dans les semaines à venir, au regard de la capacité de chacun.
• Clients confidentiels. Le propriétaire peut réserver un client, avec ses projets, ses tâches et ses temps, à des membres choisis.
• Archiver, jamais supprimer. Un membre qui part est désactivé et anonymisé, et un projet terminé est archivé, de sorte que l’historique des feuilles de temps reste intact.

L’outil n’émet pas de factures. Le mode de facturation et les budgets d’heures des projets sont derrière une permission à part, et la facturation reste dans le système comptable du cabinet.

Qui doit voir les heures de qui dans un cabinet d’audit ?

Avant ce projet, tout le monde dans le cabinet pouvait ouvrir tous les clients et les heures de chacun. Pour un cabinet d’audit, c’est d’abord un problème de confidentialité, avant d’être un problème de logiciel : tous les membres ne doivent pas voir tous les clients, et personne n’a besoin de voir la semaine d’un collègue sans avoir à la valider.

Le modèle d’accès confirmé par le cabinet se présente ainsi :

Rôle	Voit	Peut valider
Collaborateur	Ses propres heures uniquement	Rien
Admin de projet	Les heures de l’équipe sur ses propres projets	Les semaines de son équipe sur ces projets
Propriétaire	Tous les clients, projets et personnes	Tout
Client confidentiel	Visible uniquement des membres choisis par le propriétaire	—

Le propriétaire façonne chaque rôle dans une matrice de cases à cocher, domaine contre action, et chaque règle vit dans la base de données plutôt que dans les écrans : une page ne peut donc pas montrer ce que la base refuse. Chaque case a été testée sur une copie de la production avant la mise en ligne ; comment, et ce que ce test a trouvé, est expliqué dans comment tester Supabase RLS.

Une question que la matrice ne pouvait pas trancher est venue du cabinet lui-même. En juin 2026, un membre avec le rôle le plus limité voyait d’autres membres et leurs projets sur l’écran de planification, alors qu’il s’attendait à ne voir que lui-même et un collègue. Un membre restreint doit-il voir les personnes de ses propres projets ? La règle retenue : oui, sur les projets communs seulement, la capacité et les congés des autres restant masqués.

Comment obtenir un modèle d’accès que le cabinet approuve vraiment ? Je n’ai pas demandé au client de le décrire de mémoire. J’ai envoyé un questionnaire de 72 questions en 9 sections, avec les grilles de permissions déjà cochées comme le système en production fonctionnait le 7 août 2026. Le client a corrigé ce qui était faux, et chaque cellule modifiée a été signalée. Les gens corrigent mieux la réalité qu’ils ne la décrivent.

Erreur 1 : les totaux des rapports seraient sortis trop bas

La page Feuilles de temps propose les vues « Ce trimestre » et « Depuis le début de l’année » pour tout le cabinet. Elles chargeaient toutes les saisies de la période en une seule requête. L’API de la base de données derrière l’application renvoie au plus 1 000 lignes par requête, et lorsqu’elle s’arrête à 1 000, elle ne lève aucune erreur. Elle renvoie simplement les 1 000 premières.

Supabase documente ce réglage par défaut : un projet renvoie au maximum 1 000 lignes tant que la limite n’est pas modifiée dans les paramètres de l’API.

Dès que le cabinet dépassait 1 000 saisies sur une période, des membres et des semaines auraient disparu de la vue, et les totaux seraient sortis trop bas sans que rien à l’écran ne le signale. À environ 70 saisies par semaine, la vue depuis le début de l’année était en passe de dépasser 1 000 saisies vers la mi-novembre 2026. Un audit du code le 24 septembre 2026 l’a trouvé avant que cela n’arrive. La correction lit chaque période page par page, et chaque export de rapport pagine désormais de la même façon.

Comment vérifier votre outil : choisissez une longue période, exportez les saisies brutes, additionnez-les vous-même et comparez avec le total du rapport. Si les deux diffèrent, le rapport coupe des lignes.

Erreur 2 : « Enregistré » alors que rien n’était enregistré

Quand la base de données refuse un changement à cause d’une permission, ou parce qu’une règle exige une connexion à deux facteurs, elle peut répondre « 0 ligne modifiée » sans aucune erreur. Une trentaine d’endroits de l’application qui modifient ou suppriment des enregistrements lisaient cette réponse comme un succès et affichaient « enregistré ». La personne passe à autre chose. Le changement n’a jamais eu lieu.

La correction consiste à échouer par défaut : une écriture qui ne touche aucune ligne est une erreur, affichée comme telle, et un test vérifie désormais que chaque chemin d’écriture la traite ainsi.

Comment vérifier votre outil : connectez-vous en tant que membre sans le droit de modifier quelque chose, essayez de le modifier, puis rechargez la page. Si vous avez vu « enregistré » et que l’ancienne valeur est revenue, l’outil ment sur les enregistrements.

Erreur 3 : un client confidentiel fuyait par les rapports

Certaines missions ne sont connues que des personnes qui y travaillent. Depuis le 24 août 2026, le propriétaire peut réserver un client à des membres nommés. Tous les autres n’obtiennent rien pour ce client, ses projets, ses tâches ou ses temps. Le propriétaire a toujours accès, et cet accès est calculé d’après celui qui détient aujourd’hui le rôle de propriétaire, sans être stocké, de sorte qu’il suit le rôle.

Masquer le client dans la liste des clients était la partie facile. Les fuites étaient dans les portes latérales. Une revue le 8 septembre 2026 a trouvé que :

• trois fonctions de rapport ignoraient la restriction, parce qu’elles s’exécutent avec des droits qui contournent les règles d’accès normales, si bien que les heures d’un client confidentiel pouvaient apparaître dans les rapports ;
• les compteurs d’utilisation des étiquettes dans l’aperçu administrateur des étiquettes comptaient les projets et les tâches du client confidentiel, ce qui révélait l’existence de la mission et à peu près son ampleur ;
• les messages d’erreur faisaient la différence : tenter de modifier un enregistrement réel mais masqué renvoyait « forbidden », tenter d’en modifier un inventé renvoyait « not found », si bien que n’importe qui pouvait tester l’existence d’un client confidentiel.

Les trois appliquent maintenant le même contrôle que les tables principales, et un enregistrement masqué ressemble exactement à un enregistrement absent. Déplacer un projet ou une saisie hors d’un client confidentiel exige aussi le propriétaire ou une permission dédiée, et chaque déplacement de ce type est journalisé.

Comment vérifier votre outil : réservez un client à une seule personne. Puis, en tant qu’une autre personne, lancez chaque rapport, regardez chaque compteur et chaque filtre, cherchez le nom du client et ouvrez un lien direct vers l’un de ses projets. Vous ne devez trouver aucune trace, y compris dans le message d’erreur.

Erreur 4 : un rejet pouvait être masqué par une validation ultérieure

Une semaine peut contenir des saisies sur plusieurs projets, donc plusieurs personnes la valident. Si un administrateur de projet rejetait une saisie et qu’un autre validait ensuite sa part, la validation tardive pouvait clore toute la semaine et masquer le rejet. Déplacer des saisies entre tâches ou rouvrir une semaine pouvait le masquer de la même façon.

Le 24 septembre 2026, la logique de validation a été modifiée pour qu’une semaine reste rejetée tant qu’une saisie rejetée reste active, et pour qu’un administrateur de projet ne puisse archiver une saisie rejetée que s’il l’a rejetée lui-même. Une sonde de base de données exécute maintenant chacun de ces cas, et chacun doit afficher PASS.

Comment vérifier votre outil : prenez deux validateurs sur une même semaine. Rejetez une saisie en tant que premier, validez tout le reste en tant que second, et regardez dans quel état la semaine se retrouve.

Acheter ou construire un suivi des temps pour un cabinet d’audit ?

Achetez d’abord. Toggl, BigTime, ZenWorkflow et des outils similaires couvrent déjà les chronomètres, les validations hebdomadaires et la facturation des clients, et vous pouvez démarrer sur l’un d’eux cette semaine. Un outil sur mesure se justifie quand le cabinet a des règles que les produits ne savent pas exprimer, par exemple des clients confidentiels visibles uniquement de membres nommés, la validation par plusieurs administrateurs de projet pour une même semaine, ou des rôles que le propriétaire veut façonner case par case.

Quelle que soit la voie choisie, les quatre contrôles ci-dessus prennent un après-midi et en disent plus qu’une liste de fonctionnalités. Chaque page produit annonce des « permissions granulaires ». Peu montrent ce qui se passe quand on décoche une case.

Limites de ce compte rendu

• Un seul cabinet. Le modèle d’accès, le volume d’environ 70 saisies par semaine et le questionnaire viennent d’un seul cabinet.
• L’erreur 1 a été attrapée avant de se produire. La date de mi-novembre est une projection à partir du rythme de saisie du cabinet, pas un incident mesuré.
• Pas de facturation. L’outil tient les heures, le mode de facturation et les budgets d’heures mais ne facture pas les clients, donc je ne peux rien dire des circuits entre le temps passé et la facture.

Les règles d’accès ici sont de la row level security de Postgres. Deux failles qu’une matrice de rôles ne détecte pas sont décrites à part : un utilisateur qui appartient à deux organisations et un IF qui s’ouvre sur NULL. La construction elle-même est dans le cas du suivi du temps pour un cabinet d’audit, et ce type de travail relève des outils internes et tableaux de bord.