Résumé

  • Selon les RFC 9745 et 8594, Deprecation annonce le statut déprécié d’une ressource et Sunset le moment où elle risque de ne plus répondre ; aucun de ces indices n’atteste la migration de ses consommateurs.
  • Une fiche de bascule client doit relier le signal observé au périmètre déclaré, au service de remplacement, aux propriétaires des usages, aux essais de compatibilité, aux dérogations, au retour arrière et au constat final.

Analyse

Le piège tient dans une réponse sans incident. Une requête aboutit, le statut reste favorable et la charge utile paraît inchangée. Seul un nouvel en-tête livre une date de dépréciation. Pour le fournisseur, l’avertissement est parti. Pour l’équipe qui exploite le client, rien ne prouve encore qu’il soit arrivé jusqu’à une personne capable d’agir.

La RFC 9745 donne à cette alerte une forme interopérable. Le champ de réponse Deprecation contient une date structurée. Située dans le futur, elle indique quand la dépréciation doit prendre effet ; située dans le passé, elle indique quand elle a pris effet. La dépréciation ne modifie pourtant pas le comportement de la ressource. Un succès après la date n’est donc ni une contradiction ni la promesse que ce succès durera.

La relation de lien deprecation complète le champ. Elle conduit vers une documentation qui peut préciser la politique, un calendrier, un successeur ou une marche à suivre. Le registre IANA stabilise le sens de cette relation : il s’agit d’une documentation destinée à l’être humain sur la dépréciation du contexte. Le registre ne certifie pas que le document soit complet, actuel ou détenu par la bonne autorité.

Avec Sunset, la RFC 8594 traite une autre étape. La date signale qu’un URI risque de ne plus répondre à partir d’un moment futur. Elle reste un indice. La ressource peut cesser de répondre plus tôt, continuer plus tard, renvoyer une erreur, rediriger ou devenir injoignable. Lorsque Sunset accompagne Deprecation, la RFC 9745 interdit que la première date précède la seconde. Cet ordre évite une incohérence flagrante ; il ne crée pas pour autant une promesse de disponibilité.

Un avertissement à portée limitée

Par défaut, chaque champ porte sur la ressource qui l’a renvoyé. Un fournisseur peut expliquer que l’annonce affichée sur la racine d’un service vaut pour toute une version. Cette extension n’est intelligible que pour les consommateurs qui connaissent la règle. Celui qui interroge directement un chemin plus profond peut ne jamais voir l’en-tête de la racine ; celui qui le voit ne peut pas deviner seul quels autres chemins sont concernés.

Cette asymétrie empêche de confondre présence du signal et couverture de la population. Les deux RFC rappellent d’ailleurs que ces informations sont facultatives et que les clients doivent savoir fonctionner sans elles. Un mécanisme d’observation peut donc détecter l’en-tête sans avoir retrouvé le propriétaire de l’application. À l’inverse, une équipe peut recevoir une lettre de retrait sans savoir quelle tâche planifiée utilise encore la ressource.

Il faut conserver cette portée étroite dans la preuve : URI exact, heure d’observation, valeur reçue, réponse concernée et règle explicite qui étend éventuellement le périmètre. « Tout le service » ne devrait jamais apparaître par simple déduction.

Le remplaçant n’est pas auto-approuvé

Une page de migration est précieuse, surtout si elle nomme un successeur. Elle n’autorise pas une réécriture automatique de la destination. La RFC 8594 souligne qu’une instruction de migration lisible par machine peut déplacer à grande échelle l’identité des ressources. Son authenticité, son exactitude et son périmètre doivent être vérifiés afin qu’une politique ne détourne pas des ressources qu’elle ne gouverne pas.

Dans la pratique, une nouvelle adresse peut changer bien davantage que l’adresse. Le régime d’authentification, l’audience des jetons, les quotas, les champs obligatoires, l’ordre des effets, les codes d’erreur ou le lieu de conservation des données peuvent différer. Une redirection compatible avec une lecture peut casser une requête signée. Une bibliothèque présentée comme équivalente peut modifier les reprises après échec.

Ce sont des propriétés du service et du client, non du signal de dépréciation. Exiger qu’un en-tête les résolve rendrait la norme inutilisable. Les ignorer rendrait la bascule aveugle.

La fiche de bascule

Le bon complément n’est pas un tableau de bord vert, mais une fiche de bascule client révisable. Elle commence par le constat protocolaire : URI canonique, empreinte de la réponse, date et lieu de l’observation, valeurs Deprecation et Sunset, liens associés. Elle nomme ensuite le périmètre, sa source et l’autorité habilitée à l’élargir.

Vient la comparaison entre ancien et nouveau service. Il faut y inscrire les différences de sens et pas seulement deux adresses : formats d’entrée et de sortie, authentification, autorisation, quotas, garanties d’ordre, reprises, conservation, régions desservies et comportement attendu après l’arrêt. La documentation prouve ce qui a été annoncé ; un essai témoin prouve ce qui a été vu dans une condition donnée. Aucun ne remplace l’autre.

Puis la fiche inventorie les clients connus. Chaque ligne associe un usage à un responsable, une criticité, une dernière activité observée, la source de cette mesure, l’état de migration et la prochaine décision. L’absence dans les journaux doit porter sa réserve : cache, intermédiaire, exécution trimestrielle, environnement secondaire ou télémétrie incomplète. Le silence réduit une probabilité ; il ne prouve pas l’absence.

Les dérogations méritent leur propre section. Le remplaçant peut manquer d’une fonction, une localisation de données peut attendre une validation, ou un éditeur tiers peut imposer son calendrier. Une dérogation valable désigne son décideur, sa justification, sa mesure compensatoire et son expiration. Une dépendance oubliée n’est pas une dérogation.

Enfin, la décision de bascule fixe le groupe témoin, les critères de réussite, la cible de retour arrière, les déclencheurs et le dernier instant où le retour reste possible. Après l’heure prévue, la fiche consigne le comportement réel de l’ancienne ressource. Une réponse maintenue ne blanchit pas la préparation ; un retrait anticipé ne se transforme pas en réussite parce qu’une date avait été publiée.

Plusieurs dates, plusieurs pouvoirs

La date de dépréciation appartient au jugement du fournisseur sur le statut de la ressource. La date de Sunset exprime une intention concernant sa disponibilité. La date cible d’un client appartient à son propriétaire. L’expiration d’une dérogation appartient à une décision de risque. La limite du retour arrière dépend des opérations techniques. L’arrêt réel est un fait observé.

Les fusionner dans un seul compte à rebours efface les responsabilités. Un client peut migrer avant la dépréciation ; un appel rare peut réapparaître après Sunset ; le fournisseur peut repousser l’arrêt sans recommander de nouveau l’ancien service. La bonne gouvernance garde ces horloges côte à côte et demande pour chacune qui peut la modifier et avec quelle conséquence.

Sources

  1. RFC 9745 — The Deprecation HTTP Response Header Field
  2. RFC 8594 — The Sunset HTTP Header Field
  3. Registre IANA des types de relations de lien