Lorsque vous recevez un ticket de support urgent, votre instinct vous pousse à intervenir et à résoudre le problème le plus rapidement possible. Cependant, sur un site WordPress en ligne, cette rapidité peut se retourner contre vous.
Une mise à jour ratée d’une extension, une modification rapide de la configuration ou un changement précipité de la base de données peuvent faire passer un site de « partiellement cassé » à complètement hors ligne. Sans une sauvegarde récente, il n’y a pas de retour possible.
Dans ce guide, vous apprendrez à automatiser cette étape. En connectant Zendesk à l’API Kinsta, chaque ticket WordPress urgent peut déclencher une sauvegarde automatiquement, avant même qu’un ingénieur ne l’ouvre. Le résultat est un processus de réponse aux incidents plus sûr et plus cohérent, avec un point de restauration déjà en place.
Pourquoi les agences devraient faire des sauvegardes avant de réparer quoi que ce soit
Un conflit avec une extension, une requête de base de données qui échoue ou une mise à jour incomplète sur un site WordPress en ligne sans sauvegarde est difficile à résoudre. Toute modification apportée avant la création d’une sauvegarde signifie qu’il n’y a pas de point de retour propre en cas de problème.
Gérer plusieurs sites de clients signifie compter sur la personne qui prend le ticket pour créer une sauvegarde avant de commencer. C’est en dépendant de cette étape manuelle que les choses se gâtent.
Pour Pixeled Eggs, ce type d’enjeu est important car ses clients sont au service de personnes en situation de crise. Une personne à la recherche d’un support ou d’une aide d’urgence s’attend à ce que le site se charge, de sorte qu’une tentative de remédiation ratée est une catastrophe.
La solution sans tracas et le temps que nous avons fait gagner à notre équipe de développement ont constitué un retour sur investissement majeur. Cela signifie que nous pouvons nous concentrer sur ce que nous faisons le mieux, à savoir concevoir et développer des sites WordPress performants pour des clients motivés.
Ce dont vous avez besoin avant de commencer
Ce tutoriel nécessite :
- Un compte Kinsta avec au moins un site WordPress dans un environnement réel.
- Un compte Zendesk avec un plan Suite Team ou supérieur (ou un plan Support Team, Professional ou Enterprise). Les Webhooks et les Triggers sont disponibles dans tous ces niveaux.
- Un accès administrateur dans Zendesk pour créer des webhooks et des déclencheurs.
- Node.js installé localement.
Pour vous authentifier avec l’API Kinsta, allez dans [Votre entreprise] > Réglages de l’entreprise > Clés API dans MyKinsta et cliquez sur Créer une clé API.
Ici, donnez un nom à la clé, définissez une date d’expiration et cliquez sur Générer. La clé ne s’affiche qu’une seule fois à ce stade, alors copiez-la avant de fermer le panneau. Vous avez également besoin d’un identifiant de site. Celui-ci apparait dans l’URL MyKinsta lorsque vous ouvrez un site, ou vous pouvez interroger GET /sites une fois que votre clé est en place.
Quoi qu’il en soit, ajoutez la clé API à un fichier .env à la racine du projet :
KINSTA_API_KEY=your_api_key_hereNotez que l’ID du site et l’ID de l’environnement sont deux choses différentes : l’agent saisit l’ID du site et l’intergiciel appelle GET /sites/{siteId}/environments pour récupérer l’ID de l’environnement. De même, le niveau d’accès d’une clé API correspond au rôle qui l’a créée : les clés de développeur sont assorties d’autorisations plus restreintes que celles des propriétaires ou des administrateurs. Si une requête renvoie une erreur de permission, c’est la première chose à vérifier.
Autres conditions préalables au développement
Pour le développement local, l’intergiciel s’exécute sur localhost, que Zendesk ne peut pas atteindre directement. L’utilisation d’un outil de tunneling tel que ngrok expose un port local à l’Internet avec une URL publique temporaire, que vous pouvez utiliser comme point de terminaison du webhook pendant le développement. Une fois que l’intégration fonctionne de bout en bout localement, vous remplacez cette URL par l’adresse de l’intergiciel déployé.
Vous avez également besoin d’un champ de ticket personnalisé dans Zendesk pour transporter l’ID de site Kinsta d’un ticket dans la charge utile du webhook. Dans le menu d’options de Zendesk sur le côté droit de l’écran, naviguez vers Objets et règles > Tickets > Champs et créez un nouveau champ de texte.
Ensuite, donnez-lui un nom reconnaissable et notez l’ID de champ numérique que Zendesk lui attribue. Lorsqu’un agent ouvre un ticket pour un incident WordPress, il remplit ce champ avec l’ID du site affecté.
Comment intégrer Zendesk à Kinsta à l’aide de l’API Kinsta
Pour lancer une sauvegarde basée sur la réception d’un ticket d’assistance pertinent, l’intergiciel Node.js reçoit des appels de webhook de Zendesk. À partir de là, il résout un ID de site Kinsta en ID d’environnement, puis déclenche une sauvegarde manuelle étiquetée.
Le côté Zendesk consiste en deux objets : un webhook qui pointe vers le point de terminaison de l’intergiciel et un Trigger qui se déclenche à l’arrivée d’un ticket approprié.
1. Créer le webhook Zendesk
Dans Zendesk, un webhook et un Trigger sont deux objets distincts. Vous créez d’abord le webhook, puis vous le connectez au Trigger en tant qu’action, et non l’inverse. Vous ne pouvez pas non plus modifier la méthode de connexion d’un webhook après sa création, c’est pourquoi l’ordre est important.
Pour créer le webhook, ouvrez les options Zendesk et naviguez jusqu’à Apps et intégrations > Webhooks > Webhooks, puis cliquez sur Créer un webhook.
Pour la méthode de connexion, choisissez Déclencheur ou automatisation. Cliquez sur Suivant, puis entrez un nom. Pour l’URL du point de terminaison, entrez un espace réservé pour l’instant, car vous le mettrez à jour une fois que l’intergiciel sera déployé. Vous devez ajouter /backup à cette URL, définir la méthode de requête sur POST et le format de requête sur JSON.
Pour la méthode d’authentification, Bearer token est un choix pratique car vous ajoutez une vérification qui valide la requête entrante lorsque vous configurez l’intergiciel. Zendesk inclut également un en-tête de signature (x-zendesk-webhook-signature) que vous pouvez utiliser pour vérifier les demandes. Une fois que vous avez créé le webhook, Zendesk le répertorie dans le panneau webhooks jusqu’à ce que vous le connectiez à un déclencheur.
2. Configurer le déclencheur Zendesk
Une fois le webhook en place, accédez à Objets et règles > Règles de gestion > Déclencheurs et cliquez sur Créer un déclencheur.
Donnez un nom au déclencheur, puis dans la section Conditions, définissez-le pour qu’il se déclenche lorsque le ticket est créé, que la priorité est Urgent, que le champ personnalisé est présent et que les balises contiennent wordpress-emergency. Cette combinaison signifie que le déclencheur ne se déclenche que sur les nouveaux tickets qu’un agent de support a explicitement marqué comme un incident WordPress actif.
Ensuite, cliquez sur Actions > Ajouter une action, sélectionnez Notifier par > Webhook actif et choisissez votre crochet web. Cela ouvre l’éditeur de charge utile de demande, où vous définissez ce que Zendesk envoie à votre intergiciel. La charge utile est JSON standard, et Zendesk prend en charge la syntaxe des espaces réservés pour injecter des données de ticket quand le webhook se déclenche.
Le format du champ personnalisé est {{ticket.custom_fields.FIELD_ID}}, où FIELD_ID est l’ID numérique du champ personnalisé que vous avez créé dans les conditions préalables :
{
"ticket_id": "{{ticket.id}}",
"site_id": "{{ticket.custom_fields.12345678}}" // Replace the numeric placeholder with the Zendesk field ID value.
}Définir cela signifie que Zendesk transmet automatiquement l’ID du site Kinsta du ticket à l’intergiciel.
3. Construisre le point de terminaison de l’intergiciel
L’intergiciel est ce qui permet à Zendesk et à l’API Kinsta de communiquer entre eux. Express.js est un framework web Node.js minimal qui gère le routage, analyse les corps de requête et vous permet de définir le point d’extrémité POST /backup que Zendesk appelle. Une fois que vous avez initialisé un nouveau répertoire de projet, vous installez les deux dépendances :
npm init -y
npm install express dotenvIci, express fournit le serveur et la couche de routage ; dotenv charge votre fichier .env pour que votre clé API soit disponible à l’exécution sans apparaitre dans votre code source.
La création d’un fichier app.js signifie que le serveur démarre Express, analyse le JSON entrant et définit une route POST /backup qui reçoit les données utiles de Zendesk :
// app.js
const express = require('express') ;
require('dotenv').config() ;
const app = express() ;
app.use(express.json()) ;
const KinstaAPIUrl = 'https://api.kinsta.com/v2' ;
const headers = {
content-Type : 'application/json',
Authorization : `Bearer ${process.env.KINSTA_API_KEY}`
} ;
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body ;
if (!site_id) {
return res.status(400).json({ message : 'Missing site ID' }) ;
}
// Placeholder des appels de l'API Kinsta
res.status(200).json({ message : 'Received' }) ;
}) ;
app.listen(3000, () => console.log('Server running on port 3000')) ;Pour une utilisation en production, vérifiez également que la requête provient de Zendesk. Il inclut les en-têtes x-zendesk-webhook-signature et x-zendesk-webhook-signature-timestamp avec chaque invocation, que vous pouvez utiliser pour valider la charge utile par rapport à votre webhook.
4. S’authentifier avec l’API Kinsta
Toutes les requête adressées à l’API Kinsta utilisent l’authentification par jeton Bearer : L’en-tête Authorization contient votre clé API, et la constante headers définie dans app.js gère cela pour chaque requête dans l’application.
La ligne require('dotenv').config() au début du fichier charge .env avant toute autre exécution, de sorte que process.env.KINSTA_API_KEY se résout en votre clé réelle au moment de l’exécution. La clé n’apparait jamais dans le code source.
L’élément suivant dont l’intergiciel a besoin est l’ID de l’environnement pour le site, ce qui implique le point de terminaison de backup de Kinsta. Vous le faites en ajoutant une fonction sous la constante headers :
const getEnvironmentId = async (siteId) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/${siteId}/environments`,
{ method : 'GET', headers }
) ;
const data = await resp.json() ;
return data.site.environments[0].id ;
} ;Cette fonction appelle GET /sites/{siteId}/environments et renvoie l’ID du premier environnement dans la réponse, qui correspond à l’environnement réel. Si vos sites utilisent plusieurs environnements et que vous devez en cibler un en particulier, vous pouvez utiliser le nom de l’environnement plutôt que le premier résultat.
5. Déclencher la sauvegarde via l’API Kinsta
Pour créer la sauvegarde, l’intergiciel appelle POST /sites/environments/{envId}/manual-backups, en utilisant une autre fonction supplémentaire en dessous de getEnvironmentId :
const triggerBackup = async (envId, tag) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/environnements/${envId}/manual-backups`,
{
method : 'POST',
headers,
body : JSON.stringify({ tag })
}
) ;
const data = await resp.json() ;
return data ;
} ;Le paramètre tag étiquette la sauvegarde, ce qui permet de l’identifier facilement dans MyKinsta. L’utilisation de l’ID du ticket Zendesk dans la balise signifie que toute personne regardant la liste de sauvegarde peut remonter jusqu’à l’incident qui l’a déclenchée.
Enfin, mettez à jour la route POST /backup pour appeler les deux fonctions dans l’ordre :
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body ;
if (!site_id) {
return res.status(400).json({ message : 'Missing site ID' }) ;
}
try {
const envId = await getEnvironmentId(site_id) ;
const tag = `pre-remediation-${ticket_id || 'manual'}` ;
const result = await triggerBackup(envId, tag) ;
res.status(200).json(result) ;
} catch (err) {
console.error(err) ;
res.status(500).json({ message : 'Backup failed' }) ;
}
}) ;Une requête réussie au point de terminaison de sauvegarde renvoie un statut 202 avec un corps de réponse qui confirme que l’opération est en cours :
{
"operation_id": "backups:add-manual-abc123",
"message": "Adding a manual backup to environment in progress.",
"status": 202
}Cependant, la réponse 202 n’est pas une confirmation que la sauvegarde est terminée. Les sauvegardes manuelles sont asynchrones, vous interrogez donc le point de terminaison GET /operations/{operation_id} jusqu’à ce que le statut revienne comme étant terminé. Pour la plupart des flux de travail, la réponse 202 est suffisante pour ouvrir un ticket.
Une fois que vous avez lancé node app.js et envoyé une requête de test avec un ID de site et un ID de ticket valides dans le corps, vérifiez que la sauvegarde apparait dans MyKinsta avec le bon tag.
Kinsta peut vous aider à protéger les sites de vos clients en cas de problème
Cette intégration signifie que les tickets de support WordPress urgents dans Zendesk déclenchent une sauvegarde immédiate. L’intergiciel appelle l’API Kinsta pour créer un instantané étiqueté avant même qu’un ingénieur n’ouvre le ticket.
Pour le développement local, ngrok gère la connexion entre Zendesk et localhost. Une fois que vous êtes prêt à déplacer l’intergiciel vers un point de terminaison permanent, Sevalla est une solution naturelle. Vous poussez le projet vers un fournisseur Git, connectez le dépôt, ajoutez votre variable d’environnement dans les paramètres de déploiement et mettez à jour l’URL du point de terminaison du webhook dans Zendesk pour qu’elle pointe vers l’adresse en direct.
Si vous gérez des sites clients à grande échelle, le module de mises à jour automatiques de Kinsta s’associe naturellement à ce flux de travail. Il maintient les extensions et les thèmes à jour, exécute des tests visuels automatisés après chaque mise à jour et annule le changement si quelque chose ne fonctionne pas. De plus, vous pouvez le configurer selon un calendrier personnalisé pour chaque site.
Si vous avez des questions, n’hésitez pas à contacter l’équipe de support à tout moment.
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.
