Les droits sont la partie d'un paramétrage ERP qu'on règle « vite, on verra plus tard ». Plus tard, c'est le jour où un commercial exporte le fichier clients complet avant de partir chez un concurrent, ou celui où un salarié découvre les salaires de ses collègues.
Le sujet n'est pas technique : poser des droits demande de décider qui doit voir quoi, et cette décision n'appartient pas au prestataire.
L'essentiel
- Deux niveaux : les groupes donnent accès à des fonctions ; les règles d'enregistrement limitent les lignes visibles à l'intérieur de ces fonctions.
- Le principe : accorder le minimum nécessaire, et élargir à la demande — jamais l'inverse.
- 26 modules documentés sur le dépôt communautaire
server-auth: authentification unique, clés d'API, expiration de session. - Multi-sociétés : un utilisateur qui voit deux sociétés voit aussi leurs chiffres. À accorder nommément.
- Obligation RGPD : la limitation des accès aux données personnelles fait partie des mesures de sécurité attendues.
Groupes et règles : deux leviers différents
La confusion entre les deux est la source de la plupart des mauvaises surprises.
| Levier | Ce qu'il contrôle | Exemple |
|---|---|---|
| Groupe | L'accès à une fonction, et le niveau (lire, écrire, créer, supprimer) | « Accès à la comptabilité en lecture » |
| Règle d'enregistrement | Quelles lignes sont visibles dans cette fonction | « Seulement les devis de mon équipe » |
Accorder un groupe sans règle d'enregistrement donne l'accès à tout le périmètre de la fonction. C'est l'erreur la plus fréquente : un commercial à qui l'on donne accès aux ventes voit, par défaut, les ventes de tous ses collègues.
Inversement, une règle d'enregistrement très fine sur un groupe trop large ne protège pas : il suffit d'un autre écran, ou d'un export, pour contourner.
Les quatre erreurs qui ouvrent toute la base
- Donner le groupe « Paramètres » pour régler un détail. Il ouvre la configuration de l'instance, donc la possibilité de se donner tous les autres droits. C'est l'équivalent d'un accès administrateur.
- Un compte administrateur partagé. Impossible de savoir qui a fait quoi, donc impossible de corriger proprement un incident — et contraire à ce qu'on attend d'une trace d'accès.
- Un jeton d'intégration avec tous les droits. Il traîne dans un fichier de configuration, parfois dans un dépôt de code, et il ouvre la base entière.
- Accorder les droits multi-sociétés par commodité. Un utilisateur qui voit deux sociétés voit leurs marges, leurs clients et leurs salaires. Ce n'est pas un réglage d'ergonomie.
La troisième erreur est aussi un sujet d'intégration : un échange automatisé doit avoir un utilisateur dédié, avec les droits strictement nécessaires. Voir relier Odoo à ses outils existants.
Les trois zones sensibles d'une PME
| Zone | Risque | Qui doit y accéder |
|---|---|---|
| Fichier clients complet | Export avant un départ | Direction commerciale, pas chaque commercial |
| Données RH et rémunérations | Fuite interne, obligation RGPD | Direction et RH, nommément |
| Marges et prix de revient | Négociation affaiblie, fuite concurrentielle | Direction et contrôle de gestion |
La première ligne mérite une mesure concrète : limiter l'export. Un commercial a besoin de voir ses clients ; il n'a pas besoin d'extraire l'intégralité de la base en un fichier. C'est un droit distinct, et le restreindre ne gêne personne dans son travail quotidien.
La deuxième relève du RGPD : la limitation des accès aux données personnelles fait partie des mesures de sécurité attendues d'un responsable de traitement. Ce n'est pas une bonne pratique facultative.
Voir les obligations RGPD d'une PME qui héberge un ERP.
La méthode : partir des métiers, pas des écrans
Poser des droits écran par écran est interminable et produit un résultat incohérent. La méthode qui tient part des métiers.
- Listez les rôles réels, pas les postes : commercial, assistant administratif, comptable, magasinier, conducteur de travaux, direction. Six à huit suffisent dans une PME.
- Pour chaque rôle, écrivez une phrase : ce qu'il doit pouvoir faire, et ce qu'il ne doit pas voir. Une phrase, pas un tableau.
- Traduisez en groupes et en règles, et faites-le vérifier par le responsable du service — pas par l'informatique.
- Testez en vous connectant avec un compte de chaque rôle. C'est la seule vérification qui vaille : lire une matrice de droits ne révèle pas ce qu'un utilisateur voit réellement.
- Relisez à six mois. Les droits s'accumulent : on accorde pour débloquer, on ne retire jamais.
Le point 4 est celui qu'on saute, et c'est lui qui trouve les erreurs. Connectez-vous en tant que commercial et regardez ce que vous voyez : la surprise est fréquente.
Ce que les modules communautaires ajoutent
Le dépôt server-auth compte 26 modules documentés, et trois sont particulièrement utiles dans une PME.
- Authentification unique (OpenID Connect) : les comptes suivent votre annuaire d'entreprise, donc un départ coupe l'accès immédiatement. C'est la mesure la plus efficace contre les comptes oubliés.
- Clés d'API : un identifiant dédié par intégration, révocable séparément, au lieu d'un mot de passe utilisateur partagé.
- Expiration de session : une session inactive se referme. Utile sur les postes partagés — atelier, magasin, caisse.
S'y ajoute la journalisation des accès et des modifications, par un module de suivi dédié : savoir qui a modifié un prix ou supprimé un document est une information de gestion autant que de sécurité. Voir comment choisir un module communautaire.
Questions fréquentes
Un commercial peut-il voir uniquement ses propres clients ?
Oui, par une règle d'enregistrement limitant les lignes visibles à son équipe ou à lui-même. C'est un réglage distinct du groupe d'accès : accorder l'accès aux ventes sans règle d'enregistrement donne par défaut la visibilité sur toutes les ventes de l'entreprise.
Comment empêcher l'export du fichier clients ?
L'autorisation d'exporter est un droit distinct de l'autorisation de consulter : on peut la retirer sans gêner le travail quotidien. C'est l'une des mesures les plus efficaces et les moins coûteuses contre une extraction de base avant un départ.
Faut-il un compte administrateur par personne ?
Non : il faut le moins de comptes administrateurs possible, et aucun compte partagé. Un administrateur partagé rend impossible de savoir qui a fait quoi, ce qui empêche de corriger proprement un incident et va à l'encontre de ce qu'on attend d'une trace d'accès.
Les droits multi-sociétés sont-ils risqués ?
Ils doivent être accordés nommément, parce qu'un utilisateur qui voit deux sociétés voit leurs marges, leurs clients et leurs données RH. Ce n'est pas un confort d'affichage : c'est une décision de confidentialité, à vérifier avant l'ouverture des accès plutôt qu'après.
Les droits relèvent-ils du RGPD ?
Oui : la limitation des accès aux données personnelles fait partie des mesures de sécurité attendues d'un responsable de traitement. Un ERP où chacun voit les données RH de tous est un manquement, indépendamment de la qualité de l'hébergement.
Pour aller plus loin
- Les obligations RGPD d'une PME qui héberge un ERP
- Relier Odoo à ses outils existants
- Le multi-sociétés : ce qui se partage, ce qui se cloisonne
En résumé
Deux leviers — les groupes pour les fonctions, les règles d'enregistrement pour les lignes — et une méthode : partir de six à huit rôles réels, écrire une phrase par rôle, puis se connecter avec un compte de chacun pour vérifier. Retirez l'export là où il ne sert pas, et relisez les droits à six mois. Parlons de vos rôles.
