Lorsqu’une agence est de petite taille, la gestion des accès des utilisateurs relève davantage de l’habitude que d’un véritable processus. Vous partagez les identifiants d’administrateur parce que c’est plus rapide, vous accordez un accès au niveau de l’entreprise dans MyKinsta car la création d’un utilisateur au niveau du site prend quelques minutes supplémentaires, et vous laissez un prestataire dans le système car sa suppression n’est pas urgente.
Le problème, c’est que ces raccourcis finissent par s’imposer comme un modèle pour tous les projets suivants. Lorsque, par la suite, un client vous demande qui a modifié un réglage, ou qu’un prestataire avec lequel vous avez mis fin à votre collaboration au trimestre dernier s’avère disposer toujours d’un accès à un site en production, ce schéma s’est reproduit dans l’ensemble de votre portefeuille.
La gestion des accès clients est le genre de problème qui prend de l’ampleur au fur et à mesure que votre agence se développe, sans attirer l’attention, jusqu’à ce qu’il refasse surface au pire moment possible.
Le modèle d’autorisations de Kinsta vous offre l’infrastructure nécessaire pour prendre des décisions en matière d’accès de manière aussi réfléchie que pour n’importe quelle autre étape du flux de travail de votre agence.
Comment la « prolifération des accès » se développe discrètement au sein d’une agence en pleine croissance
La prolifération des accès commence généralement par une décision qui semblait logique à un moment donné et qui a été répétée sans être réexaminée. Le premier cas est généralement sans grande conséquence, comme le partage des identifiants d’administrateur avec un client lors d’une revue de projet, car la création d’un compte distinct prendrait dix minutes dont vous ne disposez pas.
Le deuxième cas est similaire : vous accordez à un prestataire un accès Développeur de l’entreprise dans MyKinsta, car la création d’un utilisateur au niveau du site vous semble être une charge de travail supplémentaire à la fin d’un appel d’intégration. Ces deux choix semblent proportionnés, mais aucun n’a été pris en tenant compte de l’évolution future.
Cependant, chacun d’entre eux crée un précédent pour le projet suivant. En l’espace d’un an, une agence gérant vingt sites clients peut se retrouver avec une douzaine d’utilisateurs disposant de niveaux d’accès qui n’ont jamais été délibérément définis :
- D’anciens employés dont les droits n’ont jamais été supprimés à leur départ.
- Des prestataires disposant d’autorisations pour des projets terminés depuis des mois.
- Des clients disposant d’une visibilité au niveau de l’entreprise sur des données qui ne leur étaient pas destinées.
Les deux systèmes d’autorisations que toute agence doit comprendre
La configuration de Kinsta repose sur deux systèmes d’autorisations distincts. Vous contrôlez l’accès à l’environnement d’hébergement depuis MyKinsta et définissez les actions que les utilisateurs peuvent effectuer au sein de l’application via WordPress.
Cependant, comme ces deux systèmes fonctionnent de manière indépendante, c’est en les confondant que la plupart des erreurs d’accès trouvent leur origine.
Les rôles MyKinsta et ce qu’ils contrôlent réellement
MyKinsta propose six rôles répartis sur deux niveaux, et c’est en comprenant la distinction entre eux que vous tirerez pleinement parti du système.
Il existe quatre rôles au niveau de l’entreprise :
- Propriétaire de l’entreprise. Il n’y en a qu’un par compte, et c’est le seul rôle qui peut résilier un plan ou transférer la propriété de l’entreprise. Son fonctionnement est identique à celui de l’administrateur de l’entreprise dans l’utilisation quotidienne et ce rôle revient au dirigeant de l’agence.
- Administrateur de l’entreprise. Ce rôle confère un contrôle total sur toutes les données de l’entreprise et un accès complet à tous les sites, y compris aux demandes de migration. Il inclut la visibilité sur la facturation et la possibilité de modifier les plans ; il est donc destiné aux membres seniors de l’équipe à qui vous confiez ces responsabilités.
- Développeur de l’entreprise. Ce rôle vous permet de gérer l’ensemble des sites et des réglages DNS du compte, ainsi que les utilisateurs au niveau des sites. Les développeurs de l’entreprise peuvent consulter la liste des utilisateurs de l’entreprise (y compris les adresses e-mail et les rôles), mais ne peuvent ni modifier les accès au niveau de l’entreprise ni consulter les détails de facturation. Il s’agit du réglage par défaut approprié pour la plupart des développeurs internes.
- Responsable de la facturation de l’entreprise. Ce rôle sert à accorder l’accès aux seules informations de facturation, telles que les factures, les noms d’entreprise et les adresses. Utilisez-le pour les contacts du service financier qui ont besoin de consulter les factures et rien d’autre.
Les deux rôles au niveau du site concernent les accès des clients et des prestataires :
- Administrateur de site. Vous bénéficiez d’un accès complet à un site spécifique et à tous ses environnements, y compris la gestion du DNS pour ce site. Les personnes désignées ne peuvent pas supprimer le site du compte d’entreprise, envoyer de demandes de migration ni créer d’environnements de staging premium.
- Développeur de site. Ce rôle donne accès aux environnements de staging uniquement. Les titulaires de ce rôle ne peuvent pas intervenir sur l’environnement de production, ne peuvent pas transférer les données du staging vers la production, ni consulter aucune donnée au niveau de l’entreprise.
La logique de protection des rôles au niveau du site constitue le fondement d’une politique d’accès client rigoureuse. En résumé, le champ d’action d’un rôle utilisateur est limité à un seul site. Dans le cas d’un développeur de site, il se limite exclusivement à l’environnement de staging.
Les rôles du tableau de bord WordPress et leur place dans le système
Les rôles d’utilisateur WordPress régissent ce que les utilisateurs peuvent faire au sein de WordPress et sont totalement indépendants de MyKinsta. Ainsi, un utilisateur peut détenir un rôle WordPress sans aucun accès à MyKinsta, et inversement.
Une erreur courante consiste à accorder simultanément à un client un accès « Administrateur de site » dans MyKinsta et un accès « Administrateur WordPress » sur le même site. Il en résulte qu’un client peut modifier les réglages au niveau du serveur dans un système tout en installant des extensions, en gérant les utilisateurs et en changeant de thème dans l’autre.
Il est important d’adapter le rôle WordPress à la tâche réelle :
- Un client chargé de la gestion du contenu a besoin d’un accès « Éditeur » dans WordPress et n’a pas besoin d’accès à MyKinsta.
- Un développeur travaillant sur l’environnement de staging a besoin d’un accès « Développeur de site » dans MyKinsta et éventuellement d’un accès « Administrateur » dans WordPress sur cet environnement. Vous devez vérifier ces points avant la mise en production.
- Un client qui prend en charge son site après la remise du projet a besoin d’un accès « Administrateur du site » dans MyKinsta et d’un rôle d’« Administrateur » dans WordPress, si ses compétences et la portée du projet justifient ces deux accès.
Le même principe s’applique aux deux systèmes : n’accordez que le minimum d’accès nécessaire par le rôle. Accorder davantage d’accès sous prétexte que c’est plus simple à expliquer crée une vulnérabilité invisible jusqu’à ce qu’elle entraîne un problème.
Les erreurs courantes commises par les agences lorsqu’elles impliquent leurs clients
La plupart des agences ne parviennent pas à une configuration d’accès défaillante par négligence, mais en raison de convictions raisonnables prises isolément. Cependant, chaque conviction comporte un risque de défaillance qui n’apparaît que lorsque les circonstances le font surgir.
« Nous gérerons les accès manuellement »
La gestion manuelle des accès fonctionne lorsque le portefeuille est restreint et que l’équipe est stable, mais elle échoue dès que ces deux conditions ne sont plus remplies.
Par exemple, un client qui se voit attribuer par erreur un accès « Développeur de l’entreprise » parce qu’une invitation a été envoyée au niveau de l’entreprise plutôt qu’au niveau du site peut consulter les adresses e-mail et les rôles de tous les utilisateurs de votre compte. De même, un prestataire se voyant attribuer un accès « Administrateur WordPress » sur le site d’un projet peut exporter l’intégralité de la table des utilisateurs, y compris les coordonnées des clients qui y sont stockées.
Bien qu’aucun de ces cas ne constitue un incident de sécurité majeur, il s’agit de failles qu’une politique d’accès écrite aurait permis d’éviter. Un simple tableau établissant une correspondance entre les rôles du projet, les rôles MyKinsta et les rôles WordPress suffit :
| Rôle du projet | Rôle MyKinsta | Rôle WordPress | Remarques |
| Propriétaire ou dirigeant de l’agence | Propriétaire de l’entreprise | Administrateur | Un par compte. Seul rôle autorisé à résilier un plan ou à transférer la propriété de l’entreprise |
| Développeur senior ou responsable de compte | Administrateur de l’entreprise ou développeur de l’entreprise | Administrateur | Utilisez le rôle d’administrateur de l’entreprise si l’accès aux informations de facturation est approprié ; utilisez celui de développeur de l’entreprise si ce n’est pas le cas |
| Prestataire de projet | Développeur du site | Administrateur (environnement de staging uniquement) | Accès au staging uniquement. Impossible de déployer vers la production ou de supprimer des environnements de staging |
| Client — gestion de contenu | Aucun | Rédacteur | Aucune visibilité sur l’hébergement n’est nécessaire pour les tâches liées au contenu |
| Client — responsabilité après transfert | Administrateur du site | Administrateur | Uniquement si ses compétences et la portée du projet le justifient |
Lorsque la décision est déjà prise, l’étape d’intégration devient une simple exécution plutôt qu’un choix à prendre sous la pression du temps.
« Les clients n’ont pas besoin d’un accès aussi étendu »
Limiter l’accès des clients peut sembler relever de la gestion des risques, bien qu’en pratique, ce ne soit pas tout à fait la même chose. Par exemple, un client qui doit mettre à jour la biographie d’un collaborateur, remplacer une image d’en-tête ou publier un article de blog n’a pas besoin d’un accès au serveur.
S’il ne dispose pas d’un rôle WordPress lui permettant d’effectuer ces opérations, chaque tâche se transforme en ticket dans votre outil de gestion de projet. Accorder des droits d’accès appropriés est une décision qui évite à votre équipe de devoir répondre à des demandes récurrentes. Par exemple, un client disposant d’un accès « Éditeur » dans WordPress gérera lui-même son contenu sans avoir aucune visibilité sur l’environnement d’hébergement.
Organic Media Group, une agence de marketing numérique gérant des portefeuilles de clients sur Kinsta, décrit l’expérience du point de vue de l’équipe :
Je peux confier cette tâche à un nouveau collaborateur, et celui-ci peut gérer plusieurs de ces comptes sans aucun problème.
La même logique s’applique du côté client. L’interface MyKinsta est accessible aux utilisateurs sans connaissances techniques, et la structure des rôles limite leur accès à ce dont ils sont responsables.
« Cela n’a pas encore posé de problème »
Les incidents liés aux accès apparaissent généralement soit immédiatement, soit plusieurs mois plus tard, lorsque les circonstances s’y prêtent. Ainsi, un prestataire qui dispose toujours d’un accès à l’environnement de staging d’un projet terminé il y a six mois ne pose pas de problème tant qu’il n’effectue pas de modification. Plus l’intervalle entre l’octroi d’une autorisation et le prochain contrôle est long, plus il devient difficile de reconstituer ce qui s’est passé et à quel moment.
De plus, la désactivation manuelle des comptes peut régulièrement passer à côté de certains problèmes d’accès. Par exemple, le fait de supprimer un utilisateur de MyKinsta ne révoque pas automatiquement les clés API qu’il a pu créer ni ne réinitialise ses identifiants SSH/SFTP.
Ces deux opérations nécessitent une étape distincte. Pour révoquer des clés API, rendez-vous dans Réglages de l’entreprise > Clés API, identifiez les clés créées par l’utilisateur sortant, puis supprimez-les. Pour réinitialiser les identifiants SSH/SFTP, accédez au niveau du site, naviguez vers « Info », puis régénérez les identifiants. Aucune de ces opérations ne se fait automatiquement lors de la suppression d’un utilisateur.
Le journal d’activité est utile dans ce cas, mais uniquement si vous le consultez. Les administrateurs d’entreprise et les développeurs d’entreprise peuvent filtrer le journal par utilisateur ou par site, et chaque entrée est cliquable pour afficher l’action en détail. Lors du départ d’un utilisateur, filtrez le journal par son nom avant de le supprimer. Cela vous permet de disposer d’un historique de ses dernières actions et de vérifier si des modifications doivent être examinées ou annulées.
Comment structurer les droits d’accès sur Kinsta à mesure que votre agence se développe
Commencez par examiner la structure de vos rôles. Accédez à Réglages de l’entreprise > Utilisateurs > Inviter des utilisateurs dans MyKinsta. Depuis la fenêtre contextuelle d’invitation, vous pouvez inviter jusqu’à dix utilisateurs à la fois en saisissant leurs adresses e-mail séparées par des virgules, puis choisir de leur accorder un accès à l’entreprise ou au site.
Voici comment attribuer des rôles au sein d’une équipe d’agence type et dans le cadre d’une relation client :
- Le propriétaire ou le dirigeant d’une agence doit se voir attribuer le rôle de « Propriétaire de l’entreprise ».
- Les développeurs seniors et les responsables de compte peuvent se voir attribuer soit le rôle d’« Administrateur de l’entreprise » si l’accès aux informations de facturation est pertinent pour leur fonction, soit celui de « Développeur de l’entreprise » dans le cas contraire. Le rôle de « Développeur de l’entreprise » est le choix par défaut approprié pour la plupart des membres du personnel technique interne.
- Pour les prestataires de projet, attribuez le rôle de « Développeur de site » uniquement sur l’environnement de staging concerné.
- Si certains de vos clients ont des responsabilités en matière de gestion de contenu, attribuez-leur un accès « Éditeur » dans WordPress. Ils n’ont pas besoin d’un accès à MyKinsta, sauf si le périmètre du projet inclut explicitement un hébergement autogéré.
Pour les rôles spécifiques à un site (tels que « Développeur du site »), choisissez « Site » plutôt que « Entreprise » dans la fenêtre contextuelle d’invitation. À partir de là, vous recherchez le site et définissez le rôle approprié.
Pour rappel, attribuez le rôle d’« Administrateur du site » dans MyKinsta et un rôle d’administrateur WordPress aux clients qui prendront en charge le site après la remise, si leurs compétences le justifient.
Un paramètre qu’il est utile d’activer sur l’ensemble de votre compte est l’authentification à deux facteurs (2FA). Kinsta exige la 2FA pour tous les utilisateurs et prend en charge à la fois la vérification par e-mail et via une application d’authentification. Vous pouvez voir quelle méthode chaque utilisateur a activée dans Réglages de l’entreprise > Utilisateurs > 2FA. Pour une agence gérant plusieurs sites clients, s’assurer que chaque utilisateur de votre compte dispose d’une 2FA active constitue une mesure de sécurité de base qui vient compléter votre structure de rôles.
Transfert d’un site vers le compte du client
Lorsqu’un projet est terminé et que le client en prend la pleine propriété, Kinsta vous permet de transférer le site directement vers son propre compte Kinsta plutôt que de le laisser sur le vôtre avec des autorisations reconfigurées.
Pour lancer le transfert, accédez à « Sites » dans MyKinsta, cliquez sur le menu à trois points (menu « kebab ») sur la ligne du site, puis sélectionnez « Transférer le site » dans le menu déroulant.
Dans la boîte de dialogue, saisissez l’adresse e-mail ou l’identifiant d’entreprise du compte de destination. Vous pouvez également sélectionner des domaines DNS à transférer en même temps que le site et, si vous le souhaitez, recommander un plan Kinsta au client. Cliquez sur « Transférer le site » pour envoyer la demande.
Une fois que le client s’est connecté à Kinsta, le site apparaît comme « Transfert en attente » dans sa liste de sites. Il accepte le transfert en cliquant sur le nom du site, puis sur « Valider le transfert » > « Accepter le transfert ».
Réaliser un bilan trimestriel des droits d’accès
La mise en place d’un bilan trimestriel constitue un moyen rapide de combler les lacunes que le processus quotidien de désinscription ne permet pas de détecter. Commencez par vous rendre dans « Réglages de l’entreprise » > « Utilisateurs » dans MyKinsta et affichez la liste complète des utilisateurs. Vous pouvez filtrer par site pour voir qui a accès à chaque propriété du client.
Ensuite, comparez cette liste à vos enregistrements de projets actifs. Toute personne dont le projet est terminé et qui n’a pas été supprimée constitue une lacune. Vous supprimez des utilisateurs en cliquant sur l’icône de corbeille dans leur ligne, ou en sélectionnant plusieurs utilisateurs et en cliquant sur « Supprimer ».
Pour rappel, supprimez toutes les clés API associées et vérifiez que les identifiants SSH/SFTP ont bien été renouvelés pour tous les sites ayant récemment connu des changements de personnel.
Votre structure d’accès client constitue en réalité une infrastructure relationnelle
La gestion des accès est une préoccupation permanente et peut avoir des conséquences en matière de sécurité. La manière dont vous structurez les autorisations indique aux clients si un site est isolé des autres et si votre agence fonctionne selon un processus ou selon des habitudes.
L’étape suivante consiste à consigner par écrit la politique d’accès à l’aide du tableau de correspondance des rôles ci-dessus, puis à effectuer un premier bilan trimestriel de votre portefeuille existant afin de mettre en évidence ce qui s’est déjà accumulé. À partir de là, la structure d’accès que vous mettez en place devient visible pour les clients de la manière appropriée : un prestataire qui ne peut accéder qu’à l’environnement de staging, un client dont les outils de gestion de contenu n’exposent pas votre environnement d’hébergement, et une désactivation en bonne et due forme à la fin d’un projet. C’est ainsi que fonctionne une agence qui s’appuie sur un processus plutôt que sur des habitudes.
Pour les agences gérant des sites clients à grande échelle, le programme de partenariat pour agences de Kinsta vous offre un support dédiée, des ressources de co-vente et des outils conçus spécialement pour répondre aux besoins des agences hébergées chez Kinsta.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
