Qui doit voir quoi dans un outil de trésorerie ?
Pour qui : Vous partagez un outil de trésorerie entre un dirigeant, un responsable financier et un comptable. Vous voulez savoir qui reçoit quel droit avant d’ouvrir les comptes.
Quatre règles couvrent l’essentiel : un compte nominatif par personne, lecture et modification séparées, accès retiré le jour du départ, identifiant bancaire jamais partagé.
Ces règles valent avant la connexion des banques. Corrigez-les après, et vous devrez retrouver qui a modifié le plan et qui détient les accès.
Une équipe de deux personnes peut s’en tenir à ceci : chacun a son compte, une seule personne modifie le plan. Au-delà, écrivez la répartition.
Notre avis
Donnez un compte nominatif à chaque personne, séparez la lecture de la modification, retirez l’accès au départ d’un collaborateur et ne partagez jamais un identifiant bancaire.
Pourquoi
- La CNIL recommande un identifiant par utilisateur et proscrit les comptes partagés.
- L’article 69 de la DSP2, la directive européenne sur les services de paiement, demande à l’utilisateur de préserver ses données de sécurité : donner son code revient à perdre la preuve de qui a validé quoi.
- Une ligne de paie détaillée dans un outil partagé expose des données individuelles sans utilité pour la prévision.
Ce qui change le choix
Plusieurs sociétés, des salaires visibles, ou un accès à des paiements : les droits doivent alors être écrits et revus.
L’ordre à suivre
- Un compte par personne
- Le moins de droits possible
- Un responsable de la modification du plan
- Une revue annuelle et un retrait immédiat au départ
Une répartition à adapter
Ce tableau est notre proposition pour une PME mono-société. Il part d’une idée : chaque droit doit répondre à un besoin réel de la personne.
| Rôle | Voit | Modifie | Ne doit pas avoir |
|---|---|---|---|
| Dirigeant | Tout le plan, le solde et les scénarios | Ses scénarios de décision | Un accès bancaire partagé |
| Responsable financier | Tout | Le plan de base, les catégories, les connexions | Un droit de paiement non validé par la banque |
| Comptable ou cabinet | Le réalisé et les catégories | Selon le rôle écrit | Le droit de signer par défaut |
| Responsable de service | Son budget, sans détail de paie | Ses prévisions, si le plan les prévoit | Le solde global s’il n’en a pas l’usage |
Trois vérifications avant d’ouvrir les comptes
Vérifiez d’abord que l’outil sait créer des groupes. L’aide d’Okimia décrit ainsi une gestion des utilisateurs par groupes, dont les permissions se cochent une à une. Nous avons lu cette seule aide sur le sujet : demandez à votre éditeur la liste des droits et si lecture et modification se séparent.
Regroupez ensuite la paie sans détail par salarié, sauf pour celui qui en a besoin. Une ligne par salarié n’améliore pas la prévision et affiche des salaires.
Cherchez enfin qui a validé chaque connexion bancaire. Si cette personne part, la connexion finira par demander une revalidation, cette nouvelle authentification forte demandée à la banque après 180 jours, qu’elle ne pourra plus donner. Cette dernière conséquence est notre déduction.
Au départ d’un collaborateur
Faites ces gestes le jour même, et gardez la liste à côté de votre procédure de sortie.
- Désactivez son compte dans l’outil de trésorerie. La CNIL demande de retirer les droits dès qu’une personne n’est plus habilitée, et au plus tard à la fin de son contrat.
- Retirez ses accès bancaires et ses certificats de signature auprès de chaque banque. Le logiciel ne le fait pas pour vous.
- Réattribuez les connexions qu’il a validées. Mettez à jour le tableau des titulaires.
- Changez tout code partagé. La CNIL demande de renouveler le mot de passe d’un compte partagé dès qu’une personne n’en a plus besoin, quand ce compte est inévitable.
Pourquoi ne jamais partager un identifiant bancaire
L’article 69, 2 de la DSP2 demande à l’utilisateur de prendre toute mesure raisonnable pour préserver ses données de sécurité. L’article 67, 2, b prévoit que l’agrégateur, le prestataire qui lit vos comptes pour votre logiciel, les garde inaccessibles aux tiers. Passer son code à un collègue contourne ces deux protections. Demandez plutôt à la banque un accès au nom de cette personne, avec ses propres limites.
Une fois par an au moins, revoyez la liste des comptes : la CNIL fixe ce rythme minimal pour les habilitations.
Limites de cette page
Les recommandations de la CNIL portent sur les données personnelles : nous les étendons par prudence aux données de trésorerie. Les droits réels de chaque logiciel restent à lire, seule l’aide d’Okimia a été consultée ici. Pour un litige sur un paiement non autorisé, l’enjeu justifie de consulter votre conseil.
Prochaine action
Avant de connecter vos banques, créez un compte par personne, attribuez le rôle écrit et nommez la personne qui modifie le plan. À deux, gardez cette règle simple. Avec plusieurs sociétés ou un droit de paiement, faites valider la répartition et revoyez-la chaque année.
Preuves et sources
Lu le 5 novembre 2026 : guide de sécurité de la CNIL (édition 2023, fiche n° 3), page CNIL sur la gestion des utilisateurs, article 69 de la DSP2, aide d’Okimia sur les utilisateurs et les groupes.
Chaque élément ci-dessous dit s’il s’agit d’un fait lu dans une source, d’une déclaration d’éditeur, de notre calcul, de notre méthode ou de notre avis. Aucun outil n’a été testé. Notre méthode
Fait lu. La fiche n° 3 du guide de sécurité de la CNIL, édition 2023, demande de définir un identifiant unique par utilisateur, d’interdire les comptes partagés, de retirer les droits dès qu’un utilisateur n’est plus habilité et à la fin de son contrat, et de réaliser une revue au moins annuelle des habilitations.
Portée : Données personnelles ; extension aux données de trésorerie par la rédaction
Réserve : Si un compte partagé est incontournable, la CNIL demande validation, traçabilité et renouvellement du mot de passe.
- CNIL : Guide pratique RGPD, sécurité des données personnelles, fiche n° 3 Gérer les habilitations Édition 2023. Lu le 5 novembre 2026. Document d’origine.
Fait lu. La CNIL recommande des politiques d’accès différenciées, en lecture, écriture ou suppression, suivant les personnes et les besoins.
Portée : Page du 27 janvier 2020, écrite pour des développeurs d’applications
Réserve : Extension par la rédaction à l’usage d’un logiciel.
- CNIL : Gérer les utilisateurs 27/01/2020. Lu le 5 novembre 2026. Document d’origine.
Fait lu. L’article 69, 2 de la DSP2 demande à l’utilisateur de prendre toute mesure raisonnable pour préserver la sécurité de ses données de sécurité personnalisées, et l’article 67, 2, b impose à l’agrégateur de les garder inaccessibles à d’autres parties que l’utilisateur et l’émetteur.
Portée : DSP2, en vigueur au 5 novembre 2026
Réserve : Transposition française non relue ligne à ligne.
- Office des publications de l'UE : Directive (UE) 2015/2366 (DSP2) Texte d'origine du 25/11/2015, langue française. Lu le 5 novembre 2026. Document d’origine.
Déclaration de l’éditeur. L’aide d’Okimia décrit l’ajout d’utilisateurs affectés à des groupes dont les permissions se cochent ou se décochent.
Portée : Article du 22 juin 2026
Réserve : Propre à Okimia, non testé.
- Okimia : Comment inviter un autre utilisateur ? Écrit le 22/06/2026. Lu le 5 novembre 2026. Document d’origine.
Notre calcul ou déduction. Une personne partie qui avait validé une connexion bancaire ne pourra plus donner la validation suivante.
Portée : Connexions par agrégateur
Réserve : Déduction de la règle d’authentification ; à confirmer selon la banque.
- Office des publications de l'UE : Règlement délégué (UE) 2018/389, texte consolidé Consolidation du 12/09/2023. Lu le 5 novembre 2026. Document d’origine.
Notre méthode. La répartition des droits par rôle constitue une proposition de la rédaction pour une PME mono-société.
Portée : PME
Réserve : À adapter.
Daté du 5 novembre 2026.
Notre avis. Séparez lecture et modification, retirez l’accès au départ d’un collaborateur et ne partagez jamais un identifiant bancaire.
Portée : PME
Réserve : Avis de la rédaction.
Daté du 5 novembre 2026.