Ajouter comme source préférée sur Google
L’automatisation prend de plus en plus le relais dans les opérations WordPress qui nécessitaient autrefois l’intervention d’une personne devant son clavier.
Les déploiements, les mises à jour, les mesures de sécurité et les modifications de l’infrastructure peuvent désormais s’effectuer sans qu’une personne ne supervise chaque étape. Cependant, la question qui reste encore en suspens est de savoir lesquelles de ces étapes nécessitent encore une intervention humaine.
Il existe quatre catégories d’opérations à prendre en compte dans WordPress, mais grâce aux fonctionnalités et à l’infrastructure de Kinsta, votre serveur est déjà conçu pour les prendre en charge.
Un agent qui ne sait pas quand s’arrêter représente un risque pour l’automatisation
Comme il s’agit d’une machine, un agent IA cherchera toujours à exécuter vos instructions. Par exemple, il peut exécuter un workflow complet comprenant la mise en production d’une mise à jour WooCommerce, l’exécution de tests de régression visuelle réussis, le vidage du cache et la mise à jour des journaux indiquant que l’opération s’est bien déroulée. Cependant, un client peut tout de même signaler ultérieurement un problème lors de la commande.
À première vue, cela ressemble à un problème lié à l’IA. Si un test de régression vérifie la mise en page mais ne contrôle pas l’intégration de la passerelle de paiement sous-jacente, cela provoquera des erreurs. Dans ce cas, l’agent IA fait exactement ce pour quoi il a été conçu ; il ne saura donc pas ce qui doit encore faire l’objet d’une vérification. Il s’agit en réalité d’un problème humain.
Cela ne constitue toutefois pas un argument contre l’automatisation. Un workflow a toutefois besoin de points de pause délibérés pour effectuer les vérifications nécessaires. Si la plupart des workflows WordPress ne nécessitent pas de moments où un agent IA peut expliquer ce qu’il sait et attendre une décision, certains en ont besoin. C’est particulièrement vrai pour les workflows plus complexes, mais cela n’est pas toujours évident.
L’analyse de Zylos Research sur les schémas de transfert entre agents et humains indique que les déploiements d’IA en production s’établissent autour d’un taux de décisions automatisées de 70 à 80 %, le reste faisant l’objet d’une vérification humaine.
Pour les opérations WordPress, vous pouvez tout de même planifier à l’avance en tirant parti de cette répartition de plusieurs manières :
- Les déploiements se répartissent clairement entre un transfert de fichiers de routine et une migration de base de données affectant les commandes en cours.
- Les mises à jour se répartissent entre les correctifs d’extensions à faible risque et tout ce qui concerne une passerelle de paiement ou un système d’abonnement.
- La publication de contenu se répartit entre les articles planifiés et tout contenu comportant des informations relatives aux tarifs, aux aspects juridiques ou à la sécurité.
- Les incidents de sécurité peuvent être répartis entre un confinement automatique et une évaluation manuelle des causes à l’origine de l’incident.
- Les modifications d’infrastructure et de facturation se répartissent entre une alerte d’utilisation et une décision de mise à niveau, de rétrogradation ou de transfert d’un site.
Une distinction ne consiste pas simplement à gérer une catégorie résiduelle de tâches non automatisées. C’est tout ce qui sort d’un schéma déjà rencontré par un agent IA (comme les modifications irréversibles ou les transactions en temps réel) qui entraine les erreurs les plus couteuses.
Une mauvaise escalade coute plus cher que ce que l’automatisation permet d’économiser
Le projet NANDA du MIT a révélé que 95 % des projets pilotes d’IA générative en entreprise ne présentent aucun retour mesurable en termes de bénéfices ou de pertes. Un schéma bien connu vient étayer ce constat :
- Une équipe automatise d’abord la majeure partie des tâches simples d’un flux de travail.
- Ensuite, elle traite ce qui reste comme une question secondaire.
- Enfin, elle en assume le cout lorsque cette petite partie s’avère présenter un risque élevé.
Un pipeline de contenu nécessitant occasionnellement une intervention humaine est tolérant, par exemple lorsqu’un brouillon reste en attente une heure de plus. En revanche, un pipeline de déploiement qui corrompt parfois une commande en cours n’est pas aussi tolérant, car certaines erreurs ne s’équilibrent pas :
- Une migration de base de données qui échoue en cours de paiement peut entrainer la perte des commandes passées entre la sauvegarde et la défaillance, et pas seulement les retarder.
- Des passerelles de paiement défaillantes continuent d’accueillir du trafic et d’entrainer des pertes de chiffre d’affaires tant que le problème passe inaperçu.
- Une réponse de sécurité mal gérée peut transformer un incident circonscrit en une interruption plus longue que celle qu’aurait provoquée l’attaque initiale.
Des études récentes révèlent que 85 % des responsables de l’expérience client (CX) affirment qu’un seul problème non résolu suffit à faire perdre un client. Si un workflow qui automatise en toute confiance et ne fait que rarement remonter les problèmes peut sembler être une solution efficace et optimale, il finira par laisser un client face à un problème non résolu, sans qu’aucune personne ne soit en boucle pour le repérer.
5 opérations WordPress où la décision humaine a sa place
La meilleure stratégie consiste à automatiser ce qui est réversible, puis à escalader le reste. Une modification réversible (ou du moins peu couteuse en cas d’erreur) et correspondant à un schéma déjà traité par le flux de travail peut être automatisée en toute sécurité.
Les modifications irréversibles ou couteuses, ainsi que celles qui ne correspondent pas à un schéma reconnu, doivent en revanche faire l’objet d’une escalade. Voici comment cette distinction s’applique aux cinq catégories qui constituent l’essentiel du travail quotidien d’une opération WordPress.
1. Déploiements : automatisez le transfert et transmettez la migration à un niveau supérieur
Une tâche telle que le transfert de fichiers vers un site de contenu est peu risquée si un problème survient. Il suffit de restaurer la sauvegarde et de procéder à un nouveau transfert, ce qui ne prend que quelques minutes. En revanche, une migration de base de données en cours de paiement sur une boutique WooCommerce en ligne constitue un tout autre type d’erreur. Les commandes passées entre la sauvegarde et l’échec ne figureront pas dans la copie restaurée ; une annulation ne suffira donc pas à réparer les dégâts.
La fonctionnalité de poussée sélective de Kinsta vous permet de gérer ce type d’incidents. Au lieu de transférer l’environnement dans son intégralité, vous pouvez choisir de ne transférer que les fichiers, la base de données, ou les deux à la fois. Kinsta effectue une sauvegarde automatique de l’environnement cible avant toute exécution.
L’utilisation de cette fonctionnalité permet de fournir à une couche d’automatisation suffisamment d’informations pour traiter une synchronisation de fichiers de routine différemment d’une migration nécessitant une vérification supplémentaire.
Pour les déploiements basés sur l’API Kinsta, la séquence fiable est la suivante :
POST/sites/environments/{env_id}/manual-backupscréer une sauvegarde avec un horodatage enregistré avant que quoi que ce soit n’atteigne l’environnement de production.PUT/sites/{site_id}/environmentstransfère l’environnement de staging vers l’environnement de production.POST/sites/cdn/clear-cachevide ensuite le cache du CDN.
Chaque étape renvoie un statut « operation_id » que le script vérifie avant de poursuivre. Si une étape échoue, le workflow s’arrête plutôt que de continuer au-delà de l’échec vers un état que personne n’avait prévu. La séquence complète des points de terminaison est documentée ici, accompagnée d’exemples montrant comment les agences l’intègrent dans leurs pipelines CI/CD.
Sod, client de Kinsta, sait exactement ce qui se passe lorsque cette distinction n’est pas intégrée à un workflow. L’agence de Melbourne gère plus de 400 sites WordPress et, dès qu’elle a cessé de traiter tous les sites de la même manière, l’équipe a constaté des avantages considérables :
L’API Kinsta nous a permis de développer des outils internes qui automatisent des processus cruciaux tels que la mise en service des sites et effectuent des opérations en masse sur l’ensemble de nos sites web, ce qui nous fait gagner un temps et des efforts considérables.
– Pete Brundle, responsable du développement chez Sod
2. Mises à jour : automatisez l’application des correctifs et faites appel à la passerelle de paiement
De nombreuses erreurs de site sont des problèmes mineurs, comme la mise à jour d’une extension sur un site vitrine, car le pire scénario est une mise en page défectueuse que vous remarquerez et corrigerez. Ce sont les fonctionnalités en arrière-plan qui peuvent vous jouer des tours, comme une boutique en ligne dotée d’une passerelle de paiement ou d’un système d’adhésion. Même si une page de commande peut sembler tout à fait normale, la transaction sous-jacente peut cesser de fonctionner sans que vous ne vous en rendiez compte.
C’est là que les mises à jour automatiques de Kinsta entrent en jeu. Cet outil vous permet de définir un calendrier et une plage horaire pour activer les mises à jour des extensions et des thèmes. Il automatise la prise et la comparaison de captures d’écran du site avant et après chaque mise à jour afin de détecter tout changement visible. En cas de différences, il restaure automatiquement la sauvegarde antérieure à la mise à jour.
Cependant, la différence entre ce qu’un contrôle visuel permet ou non de détecter est précisément la raison pour laquelle WP Umbrella a développé sa propre couche de surveillance en utilisant l’infrastructure de Kinsta, plutôt que de se fier uniquement aux mises à jour.
Nous avons créé un ticket, et en quelques heures, le problème était résolu. Croyez-moi, après avoir contacté plusieurs hébergeurs, c’est rarement aussi simple.
– Aurelio Volle, cofondateur de WP Umbrella
WP Umbrella dispose désormais de données précises sur l’impact qu’a une réponse rapide et humaine lorsqu’un problème passe entre les mailles du filet.
3. Publication de contenu : automatisez la planification et valorisez le fond
Un pipeline de publication peut gérer la planification, les métadonnées SEO, la mise à jour du cache après publication et la diffusion sur les réseaux sociaux sans aucune intervention humaine. La catégorie qui pose le plus de problèmes est celle des contenus dont les erreurs peuvent avoir des conséquences concrètes.
Un article de blog expliquant comment installer une extension présente peu de risques en cas d’erreur. Il en va tout autrement d’un article citant des tarifs, formulant des recommandations médicales, expliquant des exigences légales ou traitant du lancement d’un produit avec une date précise. Si un brouillon rédigé avec l’aide de l’IA publie un prix erroné ou des consignes de sécurité obsolètes, les conséquences sont immédiates et concrètes.
Le critère déclencheur de l’escalade n’est pas « ce texte a-t-il été rédigé par une IA ? » C’est « ce contenu a-t-il des conséquences s’il est erroné ? ». Les changements de prix, les sujets YMYL (santé, finance, droit), les lancements de produits datés et les avis de sécurité doivent tous faire l’objet d’une vérification humaine avant leur publication, quel que soit le mode de production du contenu.
L’automatisation du processus est efficace, mais c’est l’automatisation du jugement sur ce qui doit y être intégré qui conduit à la publication à grande échelle d’un problème spécifique et évitable.
4. Sécurité : automatisez le confinement et renforcez la réponse
La rapidité est essentielle lors d’une attaque en cours contre votre site et votre serveur. Une fois cette attaque contenue, la prochaine étape consiste à prendre la bonne décision. Ces deux étapes nécessitent des actions et des processus différents.
Par exemple, bloquer une adresse IP malveillante confirmée est toujours la bonne mesure à prendre, c’est pourquoi on peut sans risque confier cette tâche à un agent IA. En revanche, déterminer si un pic de trafic est dû à un concurrent qui collecte vos prix, à une intégration défaillante, à un robot d’indexation IA ou à tout autre élément justifiant d’être autorisé nécessite un contexte dont un système automatisé ne dispose pas.
La protection anti-robots de Kinsta classe le trafic entrant en temps réel et bloque les acteurs malveillants grâce à quatre niveaux de protection prédéfinis que vous pouvez appliquer par site ou de manière groupée. Un commutateur dédié bloque spécifiquement les robots d’exploration IA, tandis que les robots vérifiés (tels que Googlebot) passent toujours sans être affectés. Cela signifie que votre visibilité dans les moteurs de recherche ne subit jamais de dommages collatéraux lors d’une décision concernant le trafic généré par l’IA.
Cependant, cet outil ne détermine pas si un comportement inhabituel mérite un examen plus approfondi ; c’est pourquoi une intervention humaine est ici nécessaire.
Pour Adapting Social, une bonne gestion des incidents signifie que l’équipe ne passe plus autant de temps à éteindre des incendies :
Nous avions besoin d’une solution d’hébergement à la hauteur de notre engagement envers l’excellence et qui nous donne la confiance nécessaire pour proposer des services d’hébergement à nos clients. Une solution fiable, performante et capable d’assurer la sécurité des sites web de nos clients. C’est alors que nous avons découvert Kinsta.
– Christopher Iafelice, directeur des opérations chez Adapting Social
5. Infrastructure et facturation : automatisez les alertes et transmettez les décisions
Les changements liés à l’infrastructure et à la facturation sont ceux qui présentent le moins d’ambigüité parmi les cinq catégories, ce qui signifie qu’il est facile de se tromper. On peut sans risque automatiser la détection d’un problème. Il n’est toutefois presque jamais sans risque d’intervenir, car des tâches telles que le transfert d’un site ou la modification des réglages DNS (et bien d’autres qui affectent le trafic en direct) ne sont pas réversibles, contrairement au vidage du cache.
La structure des plans de Kinsta vous permet de tirer parti de ces aspects plutôt que de les contrer :
- Des notifications d’utilisation à 80 % et 100 % de votre quota de visites, de stockage ou de bande passante peuvent être envoyées automatiquement, bien avant que des frais de dépassement ne s’appliquent.
- La décision de passer à un plan supérieur, d’ajouter un module d’espace disque ou d’assumer un dépassement ponctuel dépend du budget et du contexte ; elle reste donc à l’appréciation de chacun.
- Les modifications de plan, l’ajout d’utilisateurs au niveau de l’entreprise ou les mises à jour de facturation sont réservées, dans MyKinsta, au propriétaire ou à l’administrateur de l’entreprise, quelles que soient les autres personnes ayant accès au compte.
Ce dernier point repose sur le même principe « d’automatisation et d’escalade » appliqué aux personnes plutôt qu’aux flux de travail : c’est la personne responsable du compte qui prend la décision financière, et non celle qui se trouve connectée au moment où un seuil est franchi. Pour une agence gérant des centaines d’environnements clients, c’est cette structure qui empêche un pic imprévu de se transformer en litige avec les clients.
Veillez à fournir du contexte à vos clients plutôt que de simplement envoyer une alerte
Si votre procédure d’escalade se contente d’indiquer ce qui nécessite une attention particulière, la personne qui reçoit l’alerte doit reconstituer le fil des évènements avant de pouvoir prendre une décision. Cela entraine un retard important et peut nuire à la rapidité d’une éventuelle escalade.
Un transfert bien conçu comprend trois éléments, au lieu de laisser cette tâche à la personne qui prend le relais :
- Ce que le flux de travail était en train de faire au moment de sa suspension, afin que personne n’ait à deviner la nature globale de la tâche.
- Le déclencheur précis de l’interruption, formulé en langage clair plutôt que dissimulé dans un fichier journal.
- Si une décision est désormais en attente d’une intervention humaine, celle-ci devant être présentée comme un choix unique et clair plutôt que comme un problème ouvert.
En résumé, la personne qui reprend un déploiement suspendu doit pouvoir voir en un seul endroit le push en attente, l’environnement ciblé et le résultat de la régression qui a provoqué l’arrêt. Le workflow doit également reprendre exactement à ce point dès qu’une personne l’approuve, plutôt que de repartir de zéro.
Pour un déploiement basé sur l’API Kinsta, cela signifie que la sauvegarde existera déjà et que la mise en production sera préparée. Cela confère au décideur une seule tâche à accomplir, plutôt que de devoir passer au crible l’ensemble du pipeline.
Les journaux d’activité et les écrans d’activité des utilisateurs propres à Kinsta reflètent cette même logique à plus petite échelle. Chaque entrée indique qui a effectué une action, à quel moment et si celle-ci a abouti.
L’ouverture des détails complets d’une entrée vous permet de poser directement une question concernant une action à l’équipe d’assistance de Kinsta, plutôt que de partir d’une description vague d’un problème que quelqu’un d’autre devra reconstituer.
L’automatisation gère ce qui est prévisible, tandis que le jugement s’occupe du reste
Plutôt que de vous demander si une étape peut être automatisée au sein de votre flux de travail WordPress (car presque toutes les étapes le peuvent), vous devriez vous concentrer sur ce qui se passe lorsque votre flux de travail rencontre un élément ne correspondant pas à ses paramètres attendus.
Pour y parvenir, il s’agit d’automatiser ce qui est réversible afin que la majeure partie du flux de travail puisse s’exécuter. À partir de là, vous pouvez définir par écrit les seuils d’escalade et joindre le contexte à chaque transfert. Ainsi, la personne qui prend le relais peut agir immédiatement au lieu de repartir de zéro.
Découvrez l’API Kinsta pour commencer à créer des flux de travail avec un point de transfert défini, ou découvrez comment l’hébergement pour agences de Kinsta aide les équipes à gérer simultanément des dizaines de sites clients.
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.
