Sin impuesto Con impuesto

Profils et permissions des employés dans le back-office de PrestaShop

Presque toutes les boutiques finissent avec plusieurs super-administrateurs et un ou deux comptes partagés. Nous vous expliquons comment créer des profils avec le strict nécessaire, comment désactiver un employé sans perdre son historique et ce qu'il faut surveiller ensuite.

Equipo Rekire
Updated: 02/10/2026 14
Profils et permissions des employés dans le back-office de PrestaShop
Share:

Ouvrez la liste des employés de votre back-office et comptez combien sont super-administrateurs. Dans beaucoup de boutiques, la réponse est « tous » : le gérant, la personne de la logistique, celle du service client, l'agence qui a fait le thème il y a des années et un compte appelé « boutique » dont la moitié de l'équipe connaît le mot de passe. Cela fonctionne jusqu'au jour où quelqu'un se trompe, part en mauvais termes ou se fait voler son mot de passe.

Comment PrestaShop organise les accès

Les accès se gèrent dans Paramètres avancés → Équipe, avec trois éléments :

  • Employés : chaque personne avec son e-mail, son mot de passe et un profil attribué.
  • Profils : des groupes de permissions. PrestaShop en fournit quelques-uns d'origine (SuperAdmin, Logisticien, Traducteur, Commercial) et vous pouvez créer les vôtres.
  • Permissions : pour chaque profil, ce qu'il peut voir, ajouter, modifier et supprimer dans chaque section du menu, et quels modules il peut configurer.

Le profil SuperAdmin ne peut pas être restreint : il a accès à tout, y compris les employés, la configuration des moyens de paiement, l'installation de modules et le webservice. C'est donc le profil à distribuer avec le plus de prudence.

Le principe du moindre privilège

Chaque personne ne devrait avoir que les permissions dont elle a besoin pour son travail quotidien. Ce n'est pas de la méfiance : c'est limiter ce qui peut mal tourner avec un mot de passe volé ou un mauvais clic. Un point de départ raisonnable :

PosteCe dont il a besoinCe dont il n'a pas besoin
Service clientCommandes (voir et changer le statut), clients, messages, retoursModules, moyens de paiement, prix, employés
LogistiqueCommandes, bons de livraison, stock, transporteursFiches clients complètes, configuration, modules
CatalogueProduits, catégories, images, caractéristiquesCommandes, clients, paiements
MarketingRègles panier, prix spécifiques, contenusPaiements, employés, modules
DirectionStatistiques et lecture généraleSouvent, même pas SuperAdmin au quotidien

Il devrait y avoir deux super-administrateurs au maximum : le responsable de la boutique et la personne qui en assure la maintenance technique. Si votre agence doit se connecter de temps en temps, donnez-lui son propre compte, que vous activez quand elle en a besoin et désactivez une fois le travail terminé.

Attention à la permission sur les modules. Un profil qui peut installer ou configurer des modules peut, en pratique, faire presque n'importe quoi : envoyer un ZIP contenant son propre code ou changer les clés d'une passerelle de paiement. Traitez-le comme s'il était SuperAdmin.

Pourquoi ne pas partager de comptes

Le compte partagé est pratique et pose trois problèmes sérieux :

  1. Vous ne savez pas qui a fait quoi. Si un prix est faux ou qu'une commande change de statut, l'historique indique « boutique », pas une personne.
  2. Vous ne pouvez pas retirer l'accès à une personne sans gêner tout le monde. Quand quelqu'un part, soit vous changez le mot de passe et prévenez les autres, soit vous le laissez tel quel. On le laisse presque toujours tel quel.
  3. Le mot de passe circule. Il finit dans un message WhatsApp, sur un post-it ou dans le gestionnaire de mots de passe d'un ordinateur portable personnel.

Un compte par personne, toujours, même s'il n'y a que deux personnes et que l'une d'elles se connecte une fois par mois.

Quand quelqu'un quitte l'entreprise

C'est le moment le plus négligé. Une liste d'étapes qui tient sur une note :

  1. Désactivez le compte le jour même, ne le supprimez pas. Désactivé, il ne peut plus se connecter, et vous conservez sa trace dans les commandes, les messages et les historiques.
  2. Vérifiez quels autres accès il avait : FTP, panneau de l'hébergement, messagerie de la boutique, comptes des passerelles de paiement, Google, réseaux sociaux, fournisseurs. Le back-office n'en est qu'un.
  3. Changez les mots de passe qu'il connaissait, même s'ils avaient été partagés « juste un instant ».
  4. Vérifiez les clés de webservice qu'il aurait créées. Une clé d'API ne dépend pas du compte de l'employé et continue de fonctionner même si vous le désactivez.
  5. Vérifiez les modules qu'il aurait installés dans ses dernières semaines.

Les comptes dont personne ne se souvient

En plus des départs, passez toute la liste en revue tous les quelques mois :

  • Les employés qui ne se sont pas connectés depuis longtemps.
  • Les e-mails sur des domaines qui ne sont ni le vôtre ni celui de votre agence actuelle.
  • Les comptes de test créés lors d'une installation ou d'une migration.
  • Plus de super-administrateurs que vous ne vous souvenez d'en avoir créé.

Un cas fréquent

Une boutique d'équipement sportif change d'agence. L'ancienne agence avait deux comptes super-administrateur, dont l'un créé pour un stagiaire resté un été. Personne ne les désactive car « ils ne se connectent plus ». Quelques mois plus tard, l'un de ces mots de passe apparaît dans une fuite d'un autre service où il avait été réutilisé, et quelqu'un entre dans le back-office avec. Aucune vulnérabilité n'a été nécessaire : un compte qui n'avait plus de propriétaire a suffi.

Un compte oublié avec un mot de passe faible est une porte que personne ne surveille. Et si des super-administrateurs apparaissent sans que personne ne les ait créés, ce n'est pas un oubli : c'est la trace typique d'une injection SQL dans un module, et il faut la traiter comme un incident.

Mots de passe et accès

  • Des mots de passe longs et uniques pour chaque employé, conservés dans un gestionnaire de mots de passe.
  • Un dossier du back-office avec un nom à vous, et non celui de l'installation par défaut.
  • HTTPS sur tout le back-office, sans exception.
  • Double authentification si votre version ou un module le permet, en commençant par les super-administrateurs.
  • PrestaShop et les modules à jour : les permissions ne servent à rien si une faille dans un module permet de créer un administrateur sans passer par le formulaire.

Le support client sans donner plus de permissions

Une raison fréquente de distribuer des comptes super-administrateur est que le service client « a besoin de voir ce que voit le client ». La solution habituelle consiste à demander son mot de passe au client ou à créer des comptes de test, et ce sont deux mauvaises idées. Mieux vaut disposer d'un moyen contrôlé de se connecter en tant que client, limité aux profils que vous choisissez et avec chaque accès enregistré.

Comment le résoudre dans PrestaShop

RKR Security Alert conserve un instantané des employés et des comptes webservice et vous alerte par Telegram de chaque création, modification ou suppression, en mettant en évidence les comptes super-administrateur et les promotions vers ce profil, même lorsqu'elles sont faites en SQL direct. Il vous prévient aussi lorsqu'un employé se connecte au back-office depuis une IP nouvelle pour lui, et son audit signale les comptes administrateur inactifs. RKR Acceso maestro règle la question du support : il permet d'entrer dans le compte d'un client depuis sa fiche, sa commande ou les listes, avec un lien à usage unique, uniquement pour les profils d'employé que vous choisissez (par défaut, SuperAdmin seulement) et avec un registre indiquant quel employé est entré dans quel compte client, quand et depuis quelle IP.

Chargement...
Consentement aux cookies
Retour en haut