Ajouter comme source préférée sur Google
Une agence gère 35 sites clients avec une petite équipe de développement. Les sites sont en ligne, l’infrastructure tient le coup et, vu de l’extérieur, rien ne semble particulièrement urgent.
Au sein de l’agence, cependant, les failles sont plus faciles à repérer. Par exemple :
- Un ancien développeur senior dispose toujours d’un accès Administrateur de l’entreprise à tous les sites du compte, même après six mois d’absence.
- Un environnement de staging WooCommerce existe, mais personne ne sait avec certitude s’il reflète l’état actuel du site de production.
- Les mises à jour d’extensions s’accumulent sur les installations des clients, et l’équipe s’en occupe dès que quelqu’un a un moment de libre.
Rien n’est encore techniquement défaillant, mais chaque nouveau client ajoute davantage de frictions internes. Il y a davantage d’identifiants, d’environnements de staging, de décisions de mise à jour, de transferts de tâches et de questions concernant l’utilisation, les performances et les coûts.
Pour les agences WordPress, la croissance met souvent en évidence des problèmes de workflow avant même de révéler des problèmes d’hébergement. Cet article aborde cinq des points de rupture les plus courants, leurs causes et ce à quoi ressemble une meilleure configuration sur Kinsta.
Le problème caché : la dette du workflow
Les workflows des petites agences commencent souvent par des raccourcis pratiques :
- Accès partagé
- Validations via Slack
- Mises à jour manuelles
- Habitudes de mise en production ancrées
- Connaissances spécifiques au client détenues par une ou deux personnes seulement
Cela fonctionne lorsque la liste des clients est restreinte, car l’équipe peut suivre tous les détails. Mais à mesure que l’agence se développe, ces raccourcis deviennent de plus en plus lourds à gérer.
Le nombre croissant de sites, de prestataires, d’environnements, de validations et de tâches de maintenance rend l’ancienne méthode plus difficile à gérer. L’agence dispose peut-être encore d’une capacité d’hébergement suffisante, mais l’équipe a plus de mal à y voir clair quant à la marche à suivre.
C’est ce qu’on appelle la « dette du workflow ». Elle s’accumule lorsque les collaborateurs doivent se souvenir du processus avant de pouvoir le suivre.
1. Le problème des droits d’accès : tout le monde dispose d’un accès trop étendu
Les petites agences accordent souvent des droits d’accès étendus, car cela semble plus rapide, mais cette commodité engendre des risques à mesure que l’agence se développe. Par exemple, d’anciens membres de l’équipe conservent leurs droits d’accès trop longtemps, ou des clients ont accès à des environnements auxquels ils ne devraient pas avoir accès.
Les conséquences se traduisent rarement par une faille de sécurité. Il s’agit le plus souvent d’un risque invisible qui reste latent dans le compte jusqu’à ce que quelqu’un apporte une modification irréversible.
Un meilleur flux de travail commence par des droits d’accès adaptés au rôle réel de chaque personne. La gestion des utilisateurs de MyKinsta permet aux agences d’attribuer des droits d’accès au niveau de l’entreprise ou au niveau du site, avec des rôles distincts pour chacun :
Pour les tâches quotidiennes liées à WordPress, MyKinsta propose également la connexion automatique à WP Admin, ce qui permet de limiter le partage d’identifiants. Lorsqu’un utilisateur dispose déjà des droits d’accès appropriés sur MyKinsta, il peut se connecter à WordPress sans avoir à transmettre d’identifiants d’administrateur distincts.
2. Le problème du chaos dans les environnements de staging : personne ne sait quel environnement est à jour
La phase de staging devient chaotique lorsque l’équipe s’agrandit plus vite que le processus ne le permet. Un développeur peut créer un environnement de staging pour une refonte, tandis qu’un autre peut apporter une correction rapide sur le site en production. Très vite, plus personne ne sait avec certitude quel environnement reflète l’état actuel du site.
Avec cinq clients, l’équipe peut encore garder tout cela en tête. Avec 20 clients, ce n’est plus possible.
Une organisation plus rigoureuse attribue à chaque environnement un rôle bien défini. Par exemple : le développement local sert à la création et aux tests, l’environnement de staging est dédié à la révision interne, à la validation par le client et aux vérifications avant lancement, tandis que le site en production est réservé exclusivement aux modifications validées.
Kinsta prend en charge ce flux de travail grâce à DevKinsta pour le développement local.
Et des environnements de staging pour chaque installation WordPress. Des URL de préproduction cohérentes facilitent également les cycles de révision, car les clients et les équipes internes savent où se rendre.
Le processus de transfert est également important. Grâce aux options de poussée sélective, les agences peuvent déplacer des fichiers, la base de données ou les deux entre les environnements. Ce contrôle est particulièrement utile pour les boutiques WooCommerce, les sites d’adhésion et d’autres sites où les données en production changent constamment.
Pour les projets de plus grande envergure ou plus sensibles, les environnements de staging premium offrent aux agences une configuration de staging qui reflète plus fidèlement l’environnement de production. Cela peut s’avérer utile pour les sites à fort trafic, les boutiques en ligne, les sites d’adhésion et les travaux où les performances sont cruciales.
Toutefois, les outils ne sont utiles que si l’équipe les utilise de manière cohérente. Les agences ont besoin de conventions de nommage, de règles de révision et d’autorisations de déploiement claires afin que chacun sache quel environnement est à jour et qui est habilité à mettre les modifications en production.
3. Le problème du retard accumulé dans les mises à jour : la maintenance devient un travail à temps plein
À un certain stade de la croissance de la plupart des agences, quelqu’un se rend compte que les mises à jour des extensions sont devenues une tâche à part entière. Un membre de l’équipe se connecte à un tableau de bord après l’autre, effectue les mises à jour, vérifie que tout fonctionne correctement, puis passe au site suivant. Avec 40 sites clients, cela peut facilement représenter trois à quatre heures par semaine.
Vient ensuite la question des vulnérabilités. À grande échelle, une agence peut très bien avoir des sites fonctionnant avec des extensions obsolètes présentant des failles de sécurité connues à l’heure actuelle, sans avoir aucun moyen d’identifier rapidement lesquels.
Si un développeur consacre quatre heures par semaine aux mises à jour manuelles, à un coût total de 60 $ de l’heure, cela représente 240 $ par semaine et 12 480 $ par an en main-d’œuvre, une charge que ce processus de mise à jour structuré élimine en grande partie.
Deux fonctionnalités de MyKinsta se combinent pour résoudre ce problème.
La première est le filtre de vulnérabilité de la liste des sites. Dans MyKinsta, les agences peuvent filtrer l’ensemble de la liste des sites afin de n’afficher que ceux comportant des extensions ou des thèmes vulnérables.
La deuxième solution est le service de mises à jour automatiques de Kinsta (3 $/mois par environnement). Ce service inclut des tests de régression visuelle qui comparent les captures d’écran avant et après chaque mise à jour et effectuent automatiquement une restauration si un élément visuel ne s’affiche plus correctement.
Les mises à jour peuvent également être planifiées afin d’éviter les heures de pointe et les périodes de mode maintenance, ce qui permet aux visiteurs de ne pas constater de dysfonctionnements.
Pour les agences qui souhaitent créer leurs propres workflows de maintenance, l’API Kinsta offre également un accès programmatique aux données des extensions et des thèmes sur tous les sites du compte, ce qui permet aux équipes de consulter l’état des mises à jour sur l’ensemble du portefeuille sans avoir à ouvrir chaque tableau de bord individuellement.
4. Le problème de la passation : l’intégration et le départ des clients révèlent des systèmes désorganisés
L’intégration et le départ des clients révèlent la qualité réelle du fonctionnement d’une agence.
Lorsqu’un nouveau client signe un contrat, l’équipe migre le site, met en place un environnement de staging, configure les accès, l’attribue au développeur approprié et l’étiquette correctement dans le tableau de bord. Lorsque ce processus est bien mené, il suit à chaque fois un parcours cohérent ; dans le cas contraire, il est légèrement improvisé à chaque fois, avec de petites variations qui s’accumulent pour former une dette opérationnelle.
Avec cinq clients, l’improvisation ne pose pas de problème. Un développeur se souvient de la pile d’extensions. Un chef de projet sait où se trouvent les identifiants. Cependant, avec 40 clients, ce modèle reposant sur la mémoire ne tient plus la route.
Le problème lié au départ d’un client est souvent plus grave encore. Lorsqu’un client part, le site doit être transféré vers son propre hébergement, et l’agence doit dissocier ses identifiants de l’installation WordPress, désactiver l’environnement de staging, vérifier qui dispose encore d’un accès et assurer la transition sans perdre d’informations importantes.
Kinsta aide les agences à mettre en place une version plus claire de ces deux processus.
Les migrations infogérées gratuites éliminent le pic de charge de travail le plus important lors de l’intégration. À partir de là, les agences peuvent suivre une configuration cohérente : environnement de staging, rôles d’accès attribués et libellés de site qui organisent le portefeuille par client, niveau de service ou statut du compte.
Lors de la désinscription, le transfert de site offre aux agences un processus de transfert fluide. Un site peut être transféré vers un autre compte Kinsta, ou vers un utilisateur non Kinsta qui sera invité à créer un compte. Les enregistrements DNS gérés dans MyKinsta sont transférés avec le site. Les modules tels que Redis et Premium Staging sont transférés automatiquement.
Pour les agences qui intègrent un grand nombre de clients, l’API Kinsta permet aux équipes de provisionner de nouveaux sites WordPress, de créer des environnements de staging et de configurer les accès par programmation, supprimant ainsi les étapes manuelles sur le tableau de bord d’un processus qui se répète pour chaque client.
5. Le problème de visibilité : l’utilisation, les robots et les coûts pour les clients deviennent plus difficiles à expliquer
Lorsque l’utilisation d’un client commence à augmenter, mais que les conversions stagnent et que le chiffre d’affaires reste inchangé, l’agence doit expliquer une hausse des coûts sans résultat commercial clair pour la justifier.
Cette discussion s’avère difficile lorsque l’équipe ne parvient pas à identifier rapidement la cause de ce pic. Une campagne a peut-être généré un trafic réel. Des robots d’IA ont peut-être exploré une grande partie du site. Des robots indésirables ont peut-être accédé aux mêmes pages à plusieurs reprises. Les robots des moteurs de recherche, les outils de surveillance et les visiteurs légitimes ont peut-être tous contribué simultanément à cette augmentation.
La nuance est importante. Tout le trafic automatisé n’est pas néfaste. Les moteurs de recherche doivent explorer les sites des clients. Les outils de disponibilité doivent vérifier l’accessibilité. Certains outils de commerce électronique, de sécurité et d’intégration reposent également sur une activité automatisée. Tout bloquer engendre ses propres problèmes. Autoriser tous les robots par défaut rend l’utilisation plus difficile à gérer et les explications plus compliquées à fournir.
Les agences ont besoin de visibilité avant de pouvoir apporter une réponse utile à leurs clients.
La protection contre les robots de Kinsta offre aux agences des contrôles par site pour le trafic automatisé. C’est important, car chaque site client peut nécessiter une approche différente. Un client peut souhaiter bloquer les robots d’indexation basés sur l’IA. Un autre peut avoir besoin d’exceptions pour les outils de surveillance, les intégrations ou l’automatisation classique de WordPress.
La protection contre les robots inclut des rapports permettant aux équipes de voir comment le trafic automatisé affecte chaque site individuellement, au lieu de devoir deviner après des pics d’utilisation.
La ventilation du cache apporte un niveau de visibilité supplémentaire. Si le trafic augmente mais que l’efficacité du cache diminue, l’équipe peut déterminer si le problème provient de requêtes non mises en cache, de l’activité des robots ou d’un problème de configuration au niveau du site, plutôt que d’attribuer l’ensemble de ce phénomène à une croissance organique.
Lorsque l’utilisation évolue, quelqu’un doit l’expliquer clairement. Une meilleure visibilité aide l’équipe à établir des liens entre le trafic, les robots, la mise en cache et les coûts d’une manière compréhensible pour les clients. Sans ce contexte, chaque pic devient un jeu de devinettes.
Des workflows plus solides rendent la croissance moins fragile
La croissance d’une agence ne met pas toujours en péril l’infrastructure WordPress en premier lieu. Le plus souvent, elle perturbe les workflows informels qui, auparavant, assuraient la cohésion de l’ensemble.
Les agences en pleine croissance n’ont pas besoin de complexité pour la complexité. Elles ont besoin de systèmes plus clairs pour le travail qu’elles effectuent déjà au quotidien, comme l’attribution des droits d’accès, le test des modifications, la gestion des mises à jour, l’intégration des clients, le transfert de propriété et l’explication de l’utilisation.
Si votre agence acquiert de nouveaux clients WordPress à un rythme que vos processus de travail ne parviennent pas à suivre, l’hébergement pour agences de Kinsta et le programme de partenariat pour agences sont conçus pour répondre aux besoins des agences en pleine croissance.
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.
