La gestion individuelle d’un site WordPress prend du temps. Pour les agences qui gèrent des dizaines, voire des centaines de sites, les tâches telles que la création d’environnements, le nettoyage des caches, l’ajout de domaines ou la restauration des sauvegardes peuvent rapidement s’accumuler. L’équipe ralentit en raison de la boucle répétitive.

Et c’est le schéma typique de beaucoup d’entre elles :

  • Nouveau client embarqué → dev installe WordPress manuellement, ajoute des domaines et configure des extensions.
  • Quelqu’un pousse un déploiement → l’équipe doit se connecter et vider les caches à la main.
  • Un client signale un bogue → l’équipe malware vérifie les journaux manuellement, et peut-être que le site est reconduit via une sauvegarde.

Aucune de ces tâches n’est difficile, mais les effectuer de façon répétée mange du temps qui devrait être investi dans un travail plus important.

C’est pourquoi Kinsta propose non seulement un tableau de bord intuitif et bref, mais aussi l’API Kinsta pour automatiser les tâches de routine que votre agence gère tous les jours.

Explorons quelques tâches de gestion de WordPress que les agences automatisent avec l’API de Kinsta.

Créer et cloner des sites WordPress

L’installation d’un nouveau site WordPress est probablement la chose la plus courante que fait votre équipe. Au début de la gestion de ton agence, cela ne vous semblera pas être une grosse affaire, car vous ne créerez peut-être que cinq à dix sites par semaine. Mais au fur et à mesure que vous grandissez, les choses changent. Vous êtes confronté à des occasions comme le Black Friday ou le lancement d’un client important où vous devez lancer des douzaines de sites en quelques jours.

À ce moment-là, le faire manuellement n’est plus possible. Soit vous ralentissez, soit vous embauchez et formez plus de personnes (ce qui coûte du temps et de l’argent), soit vous l’automatisez.

Avec l’API de Kinsta, vous pouvez l’intégrer à votre outil interne ou à votre tableau de bord pour que la création d’un nouveau site WordPress devienne aussi simple que de cliquer sur un bouton.

Disons que quelqu’un s’inscrit sur le site de votre agence et paie. Vous pourriez avoir un script qui prend les résultats du formulaire d’inscription et appelle l’API pour créer un nouveau site WordPress avec votre thème de base.

Ce n’est pas théorique. L’API contient déjà tout ce dont vous avez besoin :

Si vous gérez de nombreux sites, cela vous permettra de gagner des heures sur votre processus d’installation chaque semaine.

Gérer les domaines par programme

C’est une évidence si vous gérez des sites de clients à grande échelle.

Les agences ajoutent ou modifient régulièrement des domaines, que ce soit lors de l’intégration ou d’une refonte complète de la marque. Si vous êtes une grande agence, vous pouvez vouloir réduire le temps qu’il faut pour cliquer sur MyKinsta pour ajouter des domaines, vérifier les DNS et configurer le SSL.

Avec l’API de Kinsta, vous pouvez intégrer tout cela dans un flux de travail automatisé.

Voici un scénario courant dans le monde réel : Un nouveau client s’inscrit. Vous avez déjà son nom de domaine et ses DNS dans votre CRM. Votre système interne vérifie que les enregistrements DNS pointent vers Kinsta (peut-être en utilisant une recherche DNS en arrière-plan), et dès que c’est confirmé, il appelle l’API pour :

  • Attacher le domaine
  • Le définir comme domaine principal
  • Téléverser le SSL personnalisé si nécessaire

Vous pourriez même avoir une notification Slack qui dit « ✅ clientdomaine.com a été attaché et le SSL est actif. »

Autre scénario : Imaginons que vous refassiez l’image de marque de 20 sites clients de manière groupée. Pour mettre à jour chaque environnement avec les nouveaux domaines, les basculer et appliquer le SSL automatiquement, mettez tous les changements de domaine en file d’attente et passez en boucle par l’API plutôt que de mettre à jour chacun d’entre eux à la main.

Voici quelques-uns des points de terminaison qui permettent cela :

C’est plus qu’un simple avantage. Ce type d’automatisation permet littéralement d’économiser des heures et d’éliminer les erreurs humaines pour les agences qui effectuent cette tâche cinq à dix fois par semaine.

Si vous voulez aller plus loin, vous pouvez même exposer ce contrôle dans votre propre tableau de bord interne. Cliquez sur « Attribuer un domaine », choisissez le site et le domaine, et votre application appelle l’API de Kinsta.

Gérer les sauvegardes : lister, restaurer ou télécharger.

Il arrive qu’un déploiement échoue, que les extensions se comportent mal ou qu’un client signale un problème sur le site en direct. Avec MyKinsta, vous disposez déjà de sauvegardes fiables. Mais lorsque vous gérez plusieurs sites et que vous devez agir rapidement, il est utile d’avoir le contrôle des sauvegardes branché directement sur votre flux de travail.

C’est là que l’API entre en jeu. Les agences l’intègrent dans leurs processus de déploiement pour que :

  • Une sauvegarde manuelle est créée juste avant un déploiement
  • Si quelque chose ne va pas, une restauration est déclenchée automatiquement.
  • Les équipes n’ont pas besoin de quitter Slack ou leur tableau de bord pour revenir en arrière sur un site.

Par exemple, vous pouvez mettre en place une commande Slack du type :

/restore site-name to yesterday

Celle-ci appellerait votre service interne, qui déclencherait alors le point de terminaison de restauration. Ou imaginez un bouton « Restauration rapide » en un clic dans votre outil interne, et l’API ramène le site à un état stable sans avoir à se connecter à MyKinsta.

Voici ce qui est possible avec les points de terminaison disponibles :

L’API donne à votre équipe la possibilité d’agir rapidement, notamment dans les moments de forte pression.

Mise à jour groupée des plugins et des thèmes

Nous avons écrit un guide qui explique comment construire un outil simple utilisant l’API de Kinsta pour vérifier et mettre à jour par groupes les extensions obsolètes sur plusieurs sites WordPress à partir d’un seul tableau de bord.

Mini web app construite pour automatiser les mises à jour des extensions WordPress à l'aide de l'API Kinsta.
Mini web app construite pour automatiser les mises à jour des extensions WordPress à l’aide de l’API Kinsta.

Cette même idée fonctionne encore aujourd’hui, même si Kinsta propose désormais des mises à jour automatiques d’extensions et de thèmes en tant que module premium (qui, soit dit en passant, exécute également des tests visuels et des auto-rollbacks).

Le module de mise à jour automatique des extensions de Kinsta.
Le module de mise à jour automatique des extensions de Kinsta.

Mais si votre équipe souhaite un autre type de contrôle, l’API offre cette liberté. Vous pouvez afficher toutes les extensions de vos sites clients en une seule vue, mettre en évidence celles qui sont obsolètes et laisser vos développeurs choisir celles qui doivent être mises à jour.

Peut-être que votre équipe d’assurance qualité peut en marquer certains pour les tester avant de pousser les mises à jour vers la production. Vous pouvez aussi nettoyer le contenu en filtrant les extensions inactives et en les supprimant directement.

Le point de terminaison des extensions renvoie des détails réels tels que :

{
  "name": "akismet",
  "title": "Akismet Anti-Spam",
  "status": "active",
  "version": "1.0.0",
  "update": "available",
  "update_version": "1.0.1"
}

Avec ces informations, vous pouvez construire la logique que vous voulez :

  • Afficher le nombre d’extensions par site
  • Détecter les dérives de version
  • Déclencher des mises à jour dans plusieurs environnements
  • Ou même construire un bot Slack qui répond avec « Ce site a 4 extensions obsolètes » et un bouton pour le réparer.

Ainsi, même si le nouveau module résout la gestion des extensions pour la plupart des équipes, l’API ouvre un tout nouveau niveau de visibilité et d’automatisation personnalisée qui pourrait convenir à votre style de travail.

Vider le cache, redémarrer PHP, pousser vers le live

Les points de terminaison clear cache et restart PHP font partie des trois points les plus utilisés de l’API Kinsta, et il est facile de comprendre pourquoi.

Tableau de bord d'utilisation de l'API Kinsta montrant les statistiques des requêtes.
Tableau de bord d’utilisation de l’API Kinsta montrant les statistiques des requêtes.

Juste après un déploiement, vider les caches est généralement la première étape. Il en va de même pour le redémarrage de PHP en cas de problème. Il ne s’agit pas d’opérations « sophistiquées ». Il s’agit simplement du genre de tâches que votre équipe effectue fréquemment. C’est donc aussi le genre de choses qui devraient être automatisées.

Si votre équipe utilise déjà Git via SSH pour déployer sur Kinsta, vous pouvez intégrer ces appels d’API directement dans votren pipeline CI, peut-être par le biais des Actions GitHub. Sans qu’un utilisateur se connecte à MyKinsta, tout se réinitialise d’un simple push propre.

Voici un exemple de pipeline :

name: Deploy to Kinsta and clear cache

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy through SSH
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.KINSTA_SERVER_IP }}
          username: ${{ secrets.KINSTA_USERNAME }}
          password: ${{ secrets.KINSTA_PASSWORD }}
          port: ${{ secrets.KINSTA_PORT }}
          script: |
            cd /www/your-site/public
            git fetch origin main
            git reset --hard origin/main

      - name: Clear Kinsta cache
        run: |
          curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/clear-cache \
          -H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
          -H "Content-Type: application/json"

      - name: Restart PHP
        run: |
          curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/restart-php \
          -H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
          -H "Content-Type: application/json"

C’est simple, mais puissant. Vous pouvez aller encore plus loin :

  • Ajouter un bouton « Vider le cache » à votre panneau d’administration interne.
  • Déclencher l’effacement du cache via Slack, à l’aide d’une commande bot comme. /cache-clear client-name
  • Inclure l’effacement du cache et le redémarrage de PHP dans votre flux de déploiement du staging à la mise en ligne.

Et si vous utilisez le point de terminaison Push to Live, les choses deviennent encore plus intéressantes. Vous n’avez pas besoin de tout pousser, car l’API prend en charge la poussée sélective de fichiers à l’aide de push_files_option: 'SPECIFIC_FILES'.

Vous pouvez donc adapter vos déploiements pour ne pousser que les changements d’extensions ou de thèmes :

{
  "source_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "target_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "push_db": true,
  "push_files": true,
  "run_search_and_replace": true,
  "push_files_option": "SPECIFIC_FILES",
  "file_list": [
    "wp-content/plugins",
    "wp-content/themes",
    "wp-content/uploads"
  ]
}

C’est le genre de choses qui permet à vos développeurs de mieux respirer et à vos clients de garder les choses rapides.

Journaux d’accès pour la surveillance ou le débogage

En tant qu’agence, votre équipe gère de nombreux sites clients. Vous savez déjà qu’au moment où un client dit « Le site est en panne », il est généralement en panne depuis un certain temps.

C’est là que le point de terminaison des journaux entre en jeu. Au lieu d’attendre les plaintes de vos clients, vous pouvez les journaux directement via l’API et les afficher dans votre tableau de bord interne. Mieux encore, vous pouvez mettre en place un système d’alerte simple qui signale à votre équipe dans Slack ou par e-mail que quelque chose ne va pas.

Vous n’avez pas besoin d’ouvrir MyKinsta chaque fois que quelqu’un signale une erreur 500. Il vous suffit de récupérer les derniers journaux d’erreur ou d’accès, d’analyser la sortie et d’afficher les résultats là où votre équipe travaille déjà.

Vous avez juste besoin de l’ID de l’environnement et du type de journal que vous voulez, comme error, access, ou kinsta-cache-perf. Vous pouvez aussi limiter le nombre de lignes renvoyées :

curl -i -X GET \
  'https://api.kinsta.com/v2/sites/environments/{env_id}/logs?file_name=error&lines=1000' \
  -H 'Authorization: Bearer '

Vous obtiendrez en retour une simple chaîne de caractères du contenu du journal. À partir de là, vous pouvez construire ce qui correspond à votre flux de travail :

  • Afficher les journaux d’erreurs les plus récents pour chaque site client dans le tableau de bord de votre agence.
  • Mettre en évidence les 500, les requêtes lentes ou les tâches cron qui ont échoué.
  • Déclencher des alertes en cas de pic d’erreurs
  • Laisser vos développeurs saisir /show-logs client-x dans Slack et voir instantanément le résultat en direct.

C’est le genre de visibilité qui vous évite les moments de « oh oh » pendant les appels des clients.

Exemple concret : Comment Sod utilise l’API pour gérer plus de 400 sites

Si vous vous demandez si de vraies agences utilisent l’API de Kinsta de cette façon, c’est le cas.

Prenons l’exemple de Straight Out Digital (Sod), une agence à service complet située à Melbourne, en Australie, qui gère plus de 400 sites WordPress. Lorsque leur liste de clients a explosé, la façon manuelle de faire les choses n’a pas pu suivre. Ils ont donc créé des outils internes à partir de l’API de Kinsta pour tout automatiser, de l’approvisionnement des sites aux mises à jour des extensions.

Ils l’utilisent pour :

  • Configurer automatiquement de nouveaux sites lors de l’intégration des clients.
  • Cloner les configurations existantes sans se connecter au tableau de bord.
  • Effectuer des vérifications et des mises à jour groupées d’extensions sur l’ensemble de leur portefeuille
  • Déclencher des alertes lorsque des erreurs apparaissent dans les journaux.
  • Devancer les problèmes sans avoir à attendre les tickets des clients

Ils utilisent toujours MyKinsta quotidiennement, mais l’API leur permet d’éviter le travail répétitif. Selon leurs propres termes :

L’API de Kinsta nous a permis de développer des outils internes qui automatisent des processus cruciaux comme le provisionnement des sites et d’effectuer des opérations en groupes sur nos sites web, ce qui nous permet d’économiser un temps et des efforts considérables, explique Pete Brundle, responsable du développement chez Sod.

C’est la preuve que ces flux de travail ne sont pas théoriques. Des agences comme Sod les utilisent déjà, et l’entreprise a passé le cap des 400 sites grâce à eux.

Résumé

Si vous dirigez une agence avec plusieurs sites WordPress, l’API de Kinsta n’est pas seulement un atout. C’est ce qui vous permet de gagner du temps.

Que vous la branchiez à votre pipeline CI, que vous déclenchiez des actions à partir de vos outils internes ou que vous vouliez simplement faciliter la vie de vos développeurs, les éléments sont déjà là. Vous n’avez pas besoin de reconstruire votre processus à partir de zéro. Il vous suffit de câbler les parties qui ralentissent le plus votre équipe.

Et comme nous l’avons vu avec des agences comme Sod, les bénéfices s’accumulent au fur et à mesure que l’on évolue.

Explorez la documentation de l’API Kinsta pour voir ce qui est possible, générez votre clé API dans MyKinsta, et plongez dans des tutoriels étape par étape sur la création de bots Slack, le déploiement via Git, et plus encore !

Joel Olawanle 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.