Rôles et permissions du personnel dans le back-office d’un courtier

Un commercial démissionne un lundi et rejoint un concurrent quinze jours plus tard. Aussitôt, ses clients reçoivent des appels de la nouvelle société. Le directeur découvre alors que ce commercial pouvait exporter toute la base clients, pas seulement ses prospects. Personne ne s’était demandé pourquoi.

En bref : chaque permission du back-office répond à trois questions. Quelle partie du système ? Quelle action ? Les fiches de qui ? Construisez les rôles à partir du travail de chaque équipe, pas des intitulés de poste, donnez à chacun le strict nécessaire, séparez les tâches incompatibles, écrivez les procédures d’arrivée, de mobilité et de départ, et revoyez les accès à date fixe.

QUANTIX publie ce guide et commercialise un CRM et back-office de courtage : nous avons donc un intérêt commercial dans le sujet. Les principes ci-dessous valent pour n’importe quel système ; QUANTIX n’apparaît que dans la dernière section. Ce texte n’est pas un conseil juridique : ce que votre régulateur attend de votre contrôle interne, c’est à votre responsable conformité de le confirmer.

Trois questions derrière chaque permission

« Administrateur » et « utilisateur » ne font pas un modèle de permissions. Un modèle exploitable croise trois dimensions :

Dimension	Question	Exemples
Module	Quelle partie du système ?	Prospects, clients, transactions, demandes KYC, trades, paramètres
Action	Que peut faire la personne ?	Voir, créer, modifier, supprimer, importer, exporter
Périmètre de données	Les fiches de qui ?	Les siennes, celles de ses subordonnés, celles de son équipe, toutes

Le périmètre de données est la dimension qu’oublient les systèmes rudimentaires. Deux commerciaux peuvent avoir les mêmes droits sur les clients ; l’un ne voit que son portefeuille, l’autre voit toute la base. C’est la différence entre un salarié qui part avec ses contacts et un salarié qui part avec votre fichier clients.

Deux actions sont souvent sous-estimées. L’export fait sortir les données vers un fichier que vous ne maîtrisez plus. La suppression efface une trace dont vous aurez peut-être besoin lors d’un litige ou d’un audit. Le plus souvent, mieux vaut désactiver une fiche ou changer son statut que la supprimer.

Partir du travail des équipes, pas des intitulés de poste

Les intitulés varient d’une société à l’autre, le travail beaucoup moins. Pour chaque équipe, notez ce dont elle a besoin, son périmètre habituel et ce qu’elle n’a aucune raison de détenir. Ce tableau est un point de départ, pas un modèle à copier :

Équipe	Besoins	Périmètre habituel	Aucune raison de détenir
Commerciaux	Prospects, appels, notes, conversion du prospect en client	Ses prospects et clients	Export des listes, validation des paiements, décision KYC
Responsable commercial	Attribution et réattribution des prospects, suivi de l’équipe	Son équipe	Modification des transactions, paramètres de la plateforme
Rétention	Fiche client, trading et transactions (lecture), notes	Son portefeuille ou son équipe	Validation des retraits, modification des trades
Support	Coordonnées, état des demandes	Selon l’attribution des demandes	Données de paiement complètes, export
Conformité	Documents, demandes KYC, piste d’audit	Toutes	Conversion et attribution des prospects
Service financier	Transactions, validation, export pour le rapprochement	Toutes	Modification des données personnelles, paramétrage des rôles
Salle de marché	Positions, ordres, paramètres des instruments si nécessaire	Toutes	Validation des retraits, modification des prospects
Administrateur système	Utilisateurs, rôles, paramètres	Toutes	Travail courant sur les clients depuis le même compte

Dernière ligne, essentielle : celui qui gère les rôles ne traite pas les dossiers clients depuis ce compte. Gardez le compte d’administration à part et rarement utilisé, pour que chaque modification soit délibérée et tracée.

Le périmètre de données suppose une hiérarchie exacte

Les périmètres « mes subordonnés » et « mon équipe » ne fonctionnent que si les liens hiérarchiques enregistrés dans le système sont justes : qui dépend de qui, qui appartient à quelle équipe. D’où trois réflexes.

• Mettre à jour la hiérarchie avant les permissions. Un commercial encore rattaché à son ancien responsable reste visible pour celui-ci, et invisible pour le nouveau.
• Transférer le responsable avec le client. Quand un client passe des commerciaux à la rétention après son premier dépôt (FTD), changez le responsable sur la fiche. Sinon, le client reste dans la vue du premier et n’apparaît jamais dans celle du second.
• Accorder « toutes » nominativement. Tenez la liste des personnes qui disposent du périmètre le plus large sur un module, et pourquoi. Si cette liste ne cesse de s’allonger, la conception est à revoir.

Les tâches qu’une même personne ne doit pas cumuler

La séparation des tâches veut qu’une étape sensible ne soit pas lancée et conclue par la même personne. Le NIST SP 800-53, l’un des référentiels de mesures de sécurité les plus utilisés, demande d’identifier et de documenter les tâches à séparer, et de n’accorder à chaque utilisateur que les accès nécessaires à ses missions : c’est le principe du moindre privilège. Dans une société de courtage, les couples incompatibles ressemblent généralement à ceci :

1. Saisir un dépôt manuel et le valider. Celui qui saisit ne valide pas. Notre guide de validation des dépôts et retraits détaille ce point.
2. Modifier les coordonnées de paiement d’un client et valider son retrait. Changer la destination, puis valider un retrait vers elle depuis le même compte, c’est le chemin le plus court vers la fraude interne.
3. Apporter un client et trancher son dossier KYC. Le commercial a intérêt à l’acceptation : la décision ne lui revient donc pas. La revue elle-même est décrite dans notre guide du circuit de revue KYC.
4. Modifier les paramètres des instruments et traiter pour le compte des clients. Ajuster un spread ou un effet de levier, puis ouvrir ou modifier un trade, demande un second regard, ou au minimum une revue a posteriori régulière.
5. Gérer les rôles et s’attribuer des droits. Toute modification de rôle doit être relue par une autre personne que son auteur.

Petite équipe où une même personne cumule deux de ces tâches ? Ne faites pas comme si la séparation existait. Compensez par une revue périodique écrite : chaque semaine, le responsable ou le dirigeant relit les dépôts manuels, les retraits validés et les changements de rôles.

Les permissions à surveiller en priorité

Limitez au minimum le nombre de personnes qui détiennent ces droits, et revoyez-les plus souvent que les autres :

• L’export avec le périmètre « toutes » sur tout module contenant des données clients.
• La suppression de prospects, de clients et de transactions.
• L’import, qui peut modifier un grand nombre de fiches d’un coup.
• La création ou la modification de trades pour le compte d’un client.
• Le dépôt manuel et la validation des retraits.
• La décision KYC et l’accès aux pièces d’identité.
• La gestion des utilisateurs et des rôles.

Pour chacun, trois questions. Qui le détient aujourd’hui, nommément ? Quand l’a-t-il utilisé pour la dernière fois ? Chaque utilisation figure-t-elle dans la piste d’audit, avec la valeur avant et après ?

Arrivées, mobilités et départs

Les dérives apparaissent surtout des mois plus tard, quand les personnes changent de poste. Fixez trois procédures écrites.

• Arrivée. Une demande écrite du responsable d’équipe précisant le rôle, l’équipe et le supérieur, validée par une autre personne que le demandeur. Partez du rôle standard et n’ajoutez jamais de droits « temporaires » sans date de fin.
• Mobilité. Quand quelqu’un passe par exemple des ventes à la rétention, retirez les droits de l’ancien rôle avant d’ajouter ceux du nouveau. C’est l’accumulation des droits au fil des mutations qui donne à un ancien salarié plus d’accès que son propre responsable.
• Départ. Désactivez le compte le dernier jour travaillé, réattribuez ses prospects et ses clients, et vérifiez ce qu’il a exporté les semaines précédentes. Le NIST SP 800-53 prévoit lui aussi la désactivation des comptes lorsque l’utilisateur quitte l’organisation ou change d’affectation.

Reste la protection de la connexion du personnel (mots de passe, personnes autorisées, appareils) : elle relève de votre politique de sécurité, pas de la seule matrice de permissions.

Une revue des accès à date fixe

Fixez une échéance, mensuelle ou trimestrielle selon la taille de vos équipes, et posez chaque fois les mêmes questions :

1. Chaque compte actif appartient-il à une personne qui occupe toujours ce rôle ?
2. Qui dispose du périmètre « toutes », de l’export et de la suppression ? En a-t-il encore besoin ?
3. Quels rôles personnalisés ont été créés ou modifiés depuis la dernière revue, et par qui ?
4. La piste d’audit montre-t-elle un export volumineux, une modification de coordonnées de paiement ou de trade que personne ne sait expliquer ?

Consignez le résultat : date, auteur, changements décidés. Si l’on vous demande un jour comment vous contrôlez l’accès aux données clients, ces comptes rendus seront la réponse.

Ce que ce guide ne couvre pas

Ce guide ne traite ni de la sécurité de l’infrastructure (réseaux, postes, serveurs), ni de la politique RH et de la vérification des candidats avant embauche, ni des exigences d’un régulateur particulier. Il ne reprend pas non plus l’ensemble des exigences d’un CRM : elles figurent dans notre guide ce que doit vraiment faire un CRM pour un courtier forex.

La place de QUANTIX

Sur la plateforme QUANTIX, les permissions s’appliquent dans le CRM et back-office, qui partage un même moteur de trading et une même piste d’audit avec le portail trader et la console d’administration. Concrètement :

• Une matrice de permissions de 19 modules × 6 actions (voir, créer, modifier, supprimer, importer, exporter) × 4 périmètres de données (les miens, mes subordonnés, mon équipe, tous), au-dessus d’une hiérarchie d’employés.
• Cinq rôles prédéfinis (Administrateur, Manager, Agent, Agent support et Responsable conformité), plus les rôles que vous créez vous-même, par exemple pour le service financier ou la salle de marché.
• Des employés avec titres, supérieurs hiérarchiques et organigramme. La navigation et les boutons disparaissent lorsqu’un rôle n’a pas la permission.
• Le personnel qui dispose de la permission peut créer ou modifier des trades pour le compte d’un client depuis sa fiche dans le CRM de courtage, et un employé autorisé peut saisir un dépôt manuel depuis la fiche, comme le décrit la page paiements et opérations.
• Une piste d’audit de plus de 70 types d’événements avec valeurs avant et après, filtrable, exportable et affichée sur chaque fiche client.
• Chaque marque dispose d’un espace distinct, avec ses propres utilisateurs et données, géré depuis la console d’administration.

Précision importante : la plateforme ne propose pas aujourd’hui d’authentification à deux facteurs (2FA) ni d’authentification unique (SSO) pour les comptes du personnel ; prévoyez votre politique de mots de passe et d’appareils en conséquence. La conception des rôles et la revue des accès restent des décisions de votre société. QUANTIX fournit des outils d’exploitation et de conformité ; leur utilisation ne rend pas votre société conforme et ne lui confère aucune licence.

Pour voir la matrice de permissions appliquée à votre organisation, réservez une démonstration privée avec la liste de vos équipes et de qui valide quoi aujourd’hui.