Les sites WordPress fonctionnant sur une infrastructure rapide peuvent tout de même rencontrer des problèmes de fiabilité, principalement parce que cette infrastructure ne détermine que la vitesse de chargement des pages. C’est le « processus de gestion des changements » de l’entreprise qui détermine si le site continue de fonctionner après la mise à jour d’une extension, le déploiement d’une refonte ou la mise à niveau de la version de PHP.
C’est pourquoi le processus de contrôle, de test, de validation et de reprise après des modifications apportées à un environnement de production constitue l’un des principaux critères sur lesquels les équipes d’entreprise se basent pour évaluer les plateformes d’hébergement.
Une plateforme incapable de prendre en charge un processus de changement rigoureux oblige les équipes à mettre en place leurs propres contrôles : sauvegardes manuelles avant mise à jour transmises par messagerie instantanée, étapes d’approbation informelles et interventions d’urgence après déploiement qui détournent régulièrement les ingénieurs de leur travail sur les projets.
Pourquoi le risque lié aux modifications est-il la principale préoccupation des entreprises ?
L’ampleur des modifications qu’un environnement WordPress nécessite au cours de son cycle de vie est plus vaste qu’il n’y paraît à première vue. Par exemple :
- Les versions du cœur de WordPress sont généralement publiées selon un calendrier fixe.
- Les mises à jour d’extensions peuvent se compter par dizaines chaque mois sur une installation complexe.
- Les mises à niveau de version de PHP affectent l’ensemble de l’environnement d’exécution.
- Les modifications du schéma de la base de données accompagnent les versions majeures des extensions et peuvent entrer en conflit avec les personnalisations basées sur la structure précédente.
Au sein des entreprises où WordPress alimente un portail client, un flux de travail de contenu essentiel à la conformité ou une plateforme de commerce électronique générant un chiffre d’affaires élevé, chaque modification interagit avec de nombreuses dépendances qui ne sont pas toujours documentées. Cependant, en cas de défaillance, la cause réside souvent dans un déploiement effectué sans processus de test fiable, plutôt que dans l’infrastructure elle-même.
Un hébergeur qui ne dispose pas de procédures formalisées de préproduction, de parcours de retour en arrière ou de contrôles d’accès fait peser la responsabilité de leur mise en place sur votre équipe. Ainsi, les questions principales sont de savoir si le déploiement est prévisible et si la reprise est, par conséquent, rapide.
Comment les environnements de staging créent-ils un parcours de test sécurisé avant la mise en production ?
MyKinsta vous fournit les outils nécessaires pour faire d’un processus de modification rigoureux la norme plutôt qu’une charge supplémentaire, grâce à des environnements de préproduction, des poussées sélectives, des sauvegardes en plusieurs couches et des contrôles d’accès basés sur les rôles.
Chaque formule Kinsta comprend un environnement de staging standard conteneurisé gratuit par site. Pour en créer un, accédez à Sites, sélectionnez le site que vous souhaitez mettre en staging, cliquez sur le sélecteur d’environnement (par exemple, « Live ») et choisissez « Créer un nouvel environnement ». Vous pouvez cloner l’environnement de production existant, installer une instance WordPress vierge ou créer un environnement vide pour une configuration personnalisée.
Le module de staging premium de Kinsta offre jusqu’à cinq environnements de staging premium par site, en plus de l’environnement standard gratuit inclus dans chaque plan. C’est la solution idéale si vous gérez des flux de développement parallèles, si vous devez valider des fonctionnalités gourmandes en ressources ou si vous travaillez dans des conditions qui doivent correspondre à celles de la production. Il est utile de bien comprendre les différences entre ces deux types d’environnements lorsque vous définissez la portée de votre flux de travail :
- L’environnement de staging standard fonctionne toujours sur un seul processeur et dispose d’une allocation de mémoire vive fixe. La mise en cache serveur est disponible sans prise en charge du CDN ni de la mise en cache en périphérie. Il convient aux mises à jour d’extensions, aux revues de conception et aux tests de flux de travail de contenu.
- L’environnement de staging Premium correspond au profil de ressources de votre conteneur de production et vous offre à la fois la disponibilité d’un CDN et la prise en charge de la mise en cache en périphérie. Vous l’utilisez lorsque les tests impliquent des configurations à fort trafic, des intégrations WooCommerce ou des comportements qui n’apparaissent qu’en cas de charges à l’échelle de la production.
Pour les mises à jour d’extensions ou de thèmes, votre flux de travail de staging doit inclure l’exécution de la mise à jour, la vérification de chaque point d’intégration susceptible d’être affecté, l’obtention de l’aval des parties prenantes concernées, puis seulement ensuite la préparation du déploiement en production. Ce processus est simple à mettre en œuvre lorsque les environnements de staging et de production sont distincts.
Itineris, client de Kinsta, construit les flux de travail de ses clients professionnels autour de l’infrastructure de staging de Kinsta :
Les environnements de stagig, les sauvegardes automatisées et une infrastructure robuste ont été essentiels pour rationaliser nos flux de travail et améliorer les performances de nos sites.
Comment les déploiements sélectifs contrôlent la portée de chaque déploiement
L’environnement de staging élimine les risques liés à la phase de test, mais le transfert de l’intégralité de cet environnement vers la production introduit un risque différent. En effet, chaque fichier et chaque table de base de données sont alors remplacés, y compris les modifications ne faisant pas partie du déploiement prévu (telles que le contenu de test).
La fonctionnalité de poussée sélective de Kinsta vous permet de contrôler précisément ce qui est transféré de l’environnement de staging vers la production. Pour l’utiliser, sélectionnez votre environnement de staging dans MyKinsta, cliquez sur Pousser l’environnements, puis choisissez une portée de déploiement :
- Fichiers. Cette option transfère les thèmes, les extensions et les modifications de code tout en laissant la base de données de production intacte. Utilisez-la lorsque la base de données de staging n’est pas synchronisée avec les données de production, ou lorsque la modification n’affecte que le code source.
- Base de données. Cette option vous permet de déployer les modifications apportées à la base de données tout en laissant les fichiers de production inchangés. Utilisez-la pour les modifications structurelles telles que les mises à jour de types de publications personnalisés ou les configurations d’extensions stockées dans la base de données.
Vous disposez également de menus déroulants pour affiner davantage le déploiement. Vous pouvez par exemple choisir de sélectionner des fichiers, des dossiers ou des tables de base de données spécifiques.
Avant chaque déploiement vers un environnement de production, Kinsta crée automatiquement une sauvegarde générée par le système de l’environnement de production, qui capture l’état de celui-ci immédiatement avant le déploiement. Elle est disponible en tant que point de restauration dès que le déploiement est terminé. Si le déploiement produit un résultat inattendu, la restauration en arrière s’effectue en une seule opération dans MyKinsta, plutôt que par une reconstruction à partir d’une sauvegarde.
L’étape de recherche et de remplacement
Si le déploiement implique une modification de la structure des URL ou un changement de domaine, la base de données contiendra des références à l’URL de staging. L’outil de recherche et de remplacement de MyKinsta vous permet de mettre à jour ce type de modifications.
Notez que l’option Exécuter la recherche et le remplacement dans la boîte de dialogue Pousser en production ne fonctionne que sur la base de données ; vous devez donc effectuer une étape supplémentaire pour les fichiers et les dossiers. Pour ce faire, accédez à l’ écran Outils de MyKinsta pour un site, puis recherchez l’outil Recherche et remplacement.
Ici, saisissez l’URL de préproduction dans le champ Rechercher et l’URL de production dans le champ Remplacer par. Une fois que vous aurez cliqué sur Remplacer, MyKinsta exécutera une sauvegarde générée par le système, puis effectuera la recherche et le remplacement.
Ensemble, le déploiement sélectif, les sauvegardes préalables au déploiement et une étape dédiée de recherche et de remplacement transforment la mise en production en un processus comportant des points de contrôle obligatoires à chaque étape.
Comment les sauvegardes à plusieurs niveaux réduisent les répercussions d’une modification qui a échoué
Même avec un environnement de staging et un flux sde travail de déploiement sélectif en place, certaines modifications peuvent entraîner des défaillances imprévisibles. Par exemple, une API tierce peut se comporter différemment avec les identifiants de production par rapport à ceux de l’environnement de staging.
Les sauvegardes peuvent vous aider à limiter les répercussions lorsque cela se produit. Pour un site dans MyKinsta, rendez-vous sur l’écran Sauvegarde pour y accéder :
Kinsta couvre chaque étape du cycle de déploiement grâce à quatre types de sauvegardes :
- Les sauvegardes quotidiennes s’exécutent automatiquement et sont conservées pendant 14 à 30 jours, selon votre plan. Chaque sauvegarde constitue un instantané complet d’un site.
- Les sauvegardes générées par le système se déclenchent automatiquement avant certaines opérations clés, notamment la mise en production d’un environnement de staging, l’application d’une mise à jour d’extension ou de thème, la restauration d’une sauvegarde, l’exécution d’une recherche et d’un remplacement, ainsi que la réinitialisation d’un site. Des points de restauration sont toujours créés avant qu’une opération ne s’exécute automatiquement.
- Les sauvegardes manuelles vous permettent de créer jusqu’à cinq instantanés supplémentaires labellisés à tout moment depuis l’onglet Manuel (le nombre disponible dépend de votre plan). Celles-ci couvrent les opérations qui ne relèvent pas du calendrier automatisé, telles qu’une mise à niveau de la version PHP ou une migration de base de données que vous effectuez via WP-CLI.
- Les sauvegardes horaires sont disponibles sous forme de module payant en deux niveaux : des sauvegardes toutes les 6 heures et de véritables sauvegardes horaires. Consultez la page des modules pour connaître les tarifs en vigueur.
En cliquant sur le bouton Restaurer vers d’une sauvegarde, puis en choisissant l’environnement cible, vous pouvez revenir à cette sauvegarde spécifique. Une fois la restauration terminée, MyKinsta génère une nouvelle sauvegarde système reflétant l’état du système juste avant l’exécution de la restauration.
La mise en place d’un processus de gestion des changements autour de ce type de fonctionnalité réduit les fenêtres de maintenance programmées et les retours en arrière formels à un seul flux de travail exécutable au sein de MyKinsta. Par exemple, Konica Minolta a migré son site marketing vers WordPress sur Kinsta en trois mois et a identifié la fiabilité du déploiement comme le fondement du projet :
Notre principale préoccupation concernait les temps d’indisponibilité et la perte de performances pendant la migration, mais l’équipe de Kinsta a géré l’ensemble du processus sans heurts et sans aucune interruption.
Comment l’accès basé sur les rôles garantit le respect du processus de changement au sein des équipes
Un déploiement d’entreprise implique généralement plusieurs parties prenantes ayant des responsabilités différentes à chaque étape du processus de changement.
Par exemple, les développeurs ont besoin d’accéder à l’environnement de staging pour créer et tester les modifications, tandis que les ingénieurs assurance qualité doivent valider ces modifications. Plus loin dans le processus, les chefs de projet doivent avoir une visibilité sur le contenu de l’environnement de staging sans pouvoir le déployer en production, et les responsables de la validation côté client doivent approuver l’état de l’environnement de staging.
Le modèle d’accès et la gestion des utilisateurs de Kinsta vous permettent de définir et d’appliquer six rôles, bien que, pour la gestion du changement en entreprise, trois d’entre eux soient les plus pertinents :
- Les développeurs de l’entreprise peuvent gérer tous les sites et environnements de staging, accéder au DNS, consulter les analyses et déployer l’environnement de staging vers un environnement de production. Ils ne peuvent pas accéder aux détails de facturation, approuver les migrations, ni ajouter ou supprimer des module payants. Ce rôle convient aux développeurs internes et aux responsables techniques disposant d’une autorité totale en matière de déploiement.
- Les administrateurs de site disposent d’un contrôle total sur un site spécifique et tous ses environnements. Cependant, ils ne peuvent pas supprimer un site du compte d’entreprise ni créer ou supprimer des environnements de staging premium. Ce rôle convient aux responsables techniques en charge d’un site spécifique.
- Les développeurs de site ont accès à tous les environnements de staging des sites qui leur sont attribués, mais ne peuvent pas déployer les modifications de l’environnement de staging vers la production. Pour un prestataire travaillant sur une branche de fonctionnalités, ou un ingénieur assurance qualité validant une version candidate, ce rôle donne accès à la partie du flux de travail nécessairepar leur fonction.
MyKinsta facilite l’invitation d’un utilisateur via la page Réglages de l’entreprise > Utilisateurs. Ici, le bouton Inviter des utilisateurs vous permet de saisir leur adresse e-mail et de choisir d’accorder un accès au niveau de l’entreprise ou au niveau du site.
Centralisation des accès avec l’authentification unique SAML
Si vous êtes une entreprise gérant les accès à plusieurs outils à partir d’un fournisseur d’identité central, Kinsta prend en charge l’authentification unique (SSO) via SAML avec tout fournisseur d’identité (IdP) utilisant la norme SAML. Cela inclut notamment Microsoft Entra ID, Okta, Google Workspace et bien d’autres.
Pour l’activer, accédez à Réglages de l’entreprise > Authentification unique dans MyKinsta, puis cliquez sur Activer. À partir de là, vous configurez l’application SAML dans votre IdP à l’aide des informations de connexion fournies par MyKinsta, puis vous revenez dans MyKinsta pour finaliser la configuration avec l’URL SSO de votre IdP, l’ID d’entité et le certificat public.
Une fois cette fonctionnalité activée, les utilisateurs s’authentifient via votre IdP à l’aide des identifiants existants de l’entreprise. L’activation de l’authentification unique obligatoire empêche les utilisateurs de contourner l’IdP en se connectant directement. Lorsqu’un utilisateur quitte l’organisation, la révocation de son accès dans l’IdP entraîne simultanément sa suppression de MyKinsta, selon le même processus que celui utilisé pour tous les autres outils de la pile.
Enfin, l’authentification à deux facteurs (2FA) est nécessaire par défaut pour tous les comptes non couverts par l’authentification unique SAML. Un propriétaire d’entreprise peut consulter la méthode 2FA de chaque utilisateur depuis l’écran Réglages de l’entreprise > Utilisateurs > 2FA.
La gestion du changement est la clé d’une évolutivité sécurisée de WordPress en entreprise
Pour les grandes entreprises, la plateforme d’hébergement est l’infrastructure qui détermine dans quelle mesure un environnement WordPress peut évoluer en toute sécurité, et pas seulement à quelle vitesse il fonctionne. Ce qui distingue les plateformes au niveau de l’hébergement géré, c’est la capacité d’une équipe à déployer une mise à jour WordPress tout en disposant d’un plan de reprise fiable en cas de problème.
Les environnements de staging de Kinsta, la poussée sélective, le système de sauvegarde à plusieurs niveaux et les contrôles d’accès basés sur les rôles offrent aux équipes d’entreprise les outils nécessaires pour mettre en œuvre un flux de travail de gestion des changements rigoureux sans avoir à gérer elles-mêmes ces contrôles.
Pour découvrir comment cela s’applique à votre organisation, explorez les options d’hébergement WordPress d’entreprise proposées par Kinsta afin de déterminer si vous devez revoir votre processus actuel de gestion des changements.
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.
