Une preuve d’intervention est un dossier court que le client peut relire sans vous croire sur parole : heure de début, heure de fin, URL, code HTTP avant, geste effectué, code HTTP après, nom de la personne. Un e-mail qui dit que c’est réparé n’a aucune de ces lignes. Il ne prouve pas que vous étiez sur le bon site, ni qu’une sauvegarde n’a pas écrasé un contenu publié dans la journée.
Le minimum, dans cet ordre
| Pièce | Contenu | Où elle naît |
|---|---|---|
| Ticket | Numéro, ouverture, clôture, nom | L’outil de tickets, pas un chat |
| Constat | URL, code, heure, fuseau | Un contrôle relancé par vous |
| Geste | Version avant et après, ou identifiant de sauvegarde | Le journal de la session |
| Après | Même URL, nouveau code, heure | Le même contrôle, après le geste |
| Effet de bord | Contenus restaurés jusqu’à quelle heure, ou aucun retour de sauvegarde | La fiche, en une phrase |
Si vous n’avez pas restauré de sauvegarde, écrivez-le. Le silence laisse le client imaginer que sa page de 16 h a été effacée. S’il y a eu restauration, donnez l’heure de la sauvegarde utilisée. C’est souvent la seule ligne qui l’intéresse.
Capturer le HTTP avant et après
- Avant le geste, depuis votre poste (pas depuis le serveur lui-même) :
curl -sS -o /dev/null -w "%{http_code}\n" "https://example.com/"
- Copiez le code et l’heure dans le ticket. Si la commande n’est pas disponible, le test d’URL affiche le même code. Notez-le, ne faites pas une capture seule.
- Faites un seul geste principal : retour arrière, ou mise à jour d’une extension, ou restauration nommée. Écrivez le nom de l’extension et les deux versions, ou l’identifiant du snapshot.
- Relancez la même commande sur la même URL. Collez le nouveau code et la nouvelle heure.
- Si d’autres URL comptent (paiement, formulaire), répétez. Ne généralisez pas le site à partir de l’accueil.
Un 200 après un 502, avec deux heures, se lit sans débat. Un 200 sans le 502 d’avant ne montre qu’un site qui répond au moment de la photo. La lecture des codes, quand la situation est moins binaire, se fait comme dans analyser le code HTTP d’une URL.
Relier au changement réel
Le geste doit être identifiable plus tard. Un commit, un numéro de version d’extension, un nom de snapshot chez l’hébergeur. Mise à jour générale n’est pas identifiable. Si le geste est un correctif de fichier, le chemin du fichier et la sauvegarde de l’ancien fichier font partie du dossier. Vous n’envoyez pas le diff complet au client si le contrat ne le demande pas. Vous le rangez dans le ticket, et la fiche dit : correctif de functions.php, copie de l’ancien fichier dans le ticket 1842.
Les accès utilisés sont les vôtres, nominatifs. La preuve n’est pas un mot de passe. Elle ne contient aucun secret, aucun identifiant de base, aucune clé. Un dossier qui fuite ne doit pas ouvrir le site.
Remettre la fiche, pas le flux
Au moment de la clôture, ou avec la facture du mois, joignez la fiche : cinq à quinze lignes, une intervention par bloc. Le client y voit les incidents et les maintenances prévues. Les tentatives internes (pistes écartées) restent dans le ticket. Les citer toutes donne l’impression d’une équipe qui a cherché au hasard. En citer aucune donne l’impression qu’il ne s’est rien passé.
Gardez la fiche et le ticket le temps prévu au contrat, ou le temps dont vous avez besoin pour répondre à une contestation. Sans durée, chacun supprime au bout d’un mois et la preuve disparaît avant la question. La méthode pour tenir le ticket lui-même est dans documenter les incidents.
Le livrable est cette fiche d’intervention, produite à chaque geste qui touche la production. Pas un rapport annuel qui reconstitue les heures de mémoire. Si le geste n’a pas de code avant et après, il n’entre pas dans la fiche : soit vous reprenez le contrôle, soit vous n’appelez pas ça une intervention vérifiable.