Relier ses déploiements à son suivi SEO : la recette, et ce qu'elle ne règle pas

Le scénario ne change jamais. Une courbe décroche le 14 mai. Le 6 juin, quelqu'un demande ce qui s'est passé ce jour-là. Les réponses arrivent en vrac : « il me semble qu'on a mis en production cette semaine-là », « non, c'était la semaine d'avant », « attends, je regarde les tags ». Trois personnes, vingt minutes, et une conclusion à laquelle personne ne tient vraiment.

L'information existe pourtant déjà, datée à la seconde près, dans votre outillage de déploiement. Elle n'est simplement pas là où on la lit.

Trois champs, et le reste est de la plomberie

Quel que soit l'outil dans lequel vous suivez vos performances, un déploiement n'est exploitable que s'il arrive avec trois choses :

• Une date. Celle de la mise en production, pas celle de la fusion de la branche ni celle du ticket.
• Une nature. Un changement de gabarit, une correction technique, une publication de contenu : ces trois-là n'appellent pas la même vérification.
• Une portée. Quelles pages. C'est le champ le plus utile et celui qu'aucun pipeline ne connaît tout seul.

La suite de cet article montre comment faire écrire les deux premiers par le pipeline lui-même. Le troisième restera votre travail, et la dernière section explique pourquoi.

Ce qu'il faut avant de commencer

Un plan Pro ou Agence, qui ouvre l'accès à l'interface MCP. Puis un jeton, créé dans Réglages → API & MCP : il commence par mcp_ et ne s'affiche qu'une fois. Enfin l'identifiant du client concerné, que l'API vous donne elle-même :

curl -s https://app.colonelsearch.com/api/mcp \
  -H "Authorization: Bearer $COLONEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"list_clients","arguments":{}}}'

Il n'y a pas de client MCP à installer. L'interface est du JSON-RPC 2.0 sur HTTPS : une requête POST, un en-tête d'autorisation, un corps JSON. Ce que votre pipeline sait déjà faire.

L'appel qui pose le jalon

curl -sS --fail-with-body https://app.colonelsearch.com/api/mcp \
  -H "Authorization: Bearer $COLONEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d @- <<JSON
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
  "name":"create_event",
  "arguments":{
    "clientId":"$COLONEL_CLIENT_ID",
    "title":"Refonte du gabarit fiche produit (1 800 pages)",
    "category":"release",
    "startDate":"$(date -u +%F)",
    "description":"$GITHUB_SHA — nouveau gabarit, fil d'Ariane.",
    "siteUrl":"https://www.example.com/",
    "visibility":"agency"
  }
}}
JSON

Quatre champs sont obligatoires : le client, le titre, la catégorie et la date de début. siteUrl limite le jalon à un seul site du client — sans lui, il vaut pour tous. visibility vaut client par défaut, ce qui le rend visible dans les rapports remis ; agencyen fait une note interne. La réponse contient l'événement créé, avec son identifiant.

Le brancher au pipeline

Une seule règle : à l'étape finale, quand le déploiement a réussi. Le reste est du câblage ordinaire — voici la forme qu'il prend chez GitHub Actions, il se transpose sans difficulté ailleurs.

- name: Poser le jalon dans colonelSearch
  if: success()
  continue-on-error: true
  env:
    COLONEL_TOKEN: ${{ secrets.COLONEL_TOKEN }}
    COLONEL_CLIENT_ID: ${{ vars.COLONEL_CLIENT_ID }}
  run: ./scripts/annotate-release.sh

Deux détails comptent plus qu'ils n'en ont l'air. continue-on-error d'abord : une annotation manquante est ennuyeuse, un déploiement bloqué par une annotation manquante l'est bien davantage. --fail-with-body ensuite : une erreur d'outil sort en HTTP 500 avec son motif en clair — « Client not found in this org », « startDate must be a YYYY-MM-DD date » — et sans ce drapeau, curl rendrait la main sans un mot. L'étape ne doit pas casser votre déploiement, mais elle doit se plaindre dans le journal.

Les quatre choses que cette recette ne règle pas

1. Rien n'empêche les doublons

Deux appels identiques créent deux jalons. Nous l'avons vérifié plutôt que de l'espérer : la même requête envoyée deux fois donne deux événements, à la même date, avec le même titre. Un pipeline rejoué après un échec réseau double donc le repère. Attachez l'appel à quelque chose qui n'arrive qu'une fois — une étiquette, une publication de version — plutôt qu'à chaque exécution d'un workflow.

2. Un déploiement ne connaît pas sa portée

siteUrl restreint le jalon à un site. Rien, dans votre pipeline, ne sait dire quelles pageschangent de comportement. Or c'est exactement l'information dont vous aurez besoin trois semaines plus tard. Elle n'a qu'un endroit où vivre : le titre et la description, écrits par quelqu'un qui sait ce que la livraison contenait.

« Deploy v2.4.1 » ne vous servira à rien. « Refonte du gabarit fiche produit (1 800 pages) » vous dira, en juin, quel périmètre comparer à quel autre.

3. Le jeton porte toute l'organisation

Il n'est pas restreint au client dont vous déployez le site : il peut écrire sur n'importe quel client de votre organisation, et les écritures sont attribuées à la personne qui l'a créé. Un secret de production, donc, rangé comme tel, et révoqué quand la personne change d'équipe.

4. Un jalon n'est toujours pas une cause

Automatiser la pose ne change rien à sa lecture. Une date posée à côté d'une inflexion ne démontre pas le lien — elle indique où regarder. C'est le sujet d'un autre article : ce qu'une annotation établit, et ce qu'elle ne prouve pas.

Ce que vous gagnez vraiment

Pas une explication automatique de vos courbes : une mémoire qui ne dépend plus de la personne la plus ancienne de l'équipe. Au bout d'un trimestre, la chronologie d'un site raconte ses livraisons dans l'ordre, avec leurs dates exactes. Les vingt minutes de reconstitution du 6 juin n'ont plus lieu d'être, et la discussion commence là où elle aurait dû commencer : qu'est-ce que cette livraison a touché, et comment le vérifier.