Vérifier et maintenir un catalogue d’applications sans liens morts ni promesses périmées

Inventaire et criticité

Recensez fiches, liens, canonicals, redirections, images, documents et appels à l’action. Attribuez une criticité selon la conséquence : un lien vers un guide est important ; un bouton de paiement ou d’inscription est critique ; une source documentaire est maintenable avec un délai si le contenu reste exact.

La criticité détermine fréquence et profondeur. Les destinations instables ou datées sont contrôlées plus souvent. Les ressources immuables adressées par hash sont contrôlées lors de la publication et peuvent ensuite bénéficier d’un cache long.

Contrôle en quatre niveaux

Le niveau 1 vérifie résolution DNS, TLS et HTTP. Le niveau 2 vérifie le contenu : titre, statut, canonical et absence de redirection inattendue. Le niveau 3 vérifie l’action annoncée avec le profil et l’environnement adaptés. Le niveau 4 compare la formulation du site avec la passation versionnée.

Un échec de niveau 3 ne détruit pas la fiche. Il masque le CTA et conserve le contenu autonome. Un échec temporaire de niveau 1 est retenté de façon bornée avant quarantaine afin de ne pas confondre propagation et panne durable.

Planification sans pollers concurrents

Une seule tâche est propriétaire de la vérification d’une destination. Plusieurs sites consomment son résultat au lieu de lancer des sondes concurrentes. Le planificateur stocke un checkpoint, applique une limite de débit et utilise un backoff avec jitter après échec.

Les contrôles sont idempotents : rejouer le même état ne produit pas une nouvelle publication. Un changement détecté entre dans une file de revue ; il n’active ni ne retire automatiquement une promesse importante sans validation.

Quarantaine et repli

Une destination passe en quarantaine après un nombre borné d’échecs ou une divergence de contenu. Le CTA est masqué, le guide reste public et le responsable reçoit le contexte minimal : identifiant, niveau en échec, heure et statut. Les paramètres privés et contenus utilisateur ne sont jamais joints.

Le repli peut être une démo déjà qualifiée, une page d’aide ou le guide. Il doit être annoncé comme tel et ne pas rediriger silencieusement « S’inscrire » vers une page d’accueil.

Révision des sources et contenus

Les normes et pages officielles ont une date de consultation. Un changement détecté déclenche une comparaison et une revue de la phrase qu’elles soutiennent. Les faits tarifaires, réglementaires ou programmatiques portent une date de validité visible et une alerte d’expiration.

Une source disparue n’est pas remplacée par un blog non équivalent pour conserver le texte. L’affirmation est réduite, reformulée ou retirée jusqu’à trouver une source autoritative actuelle.

Tenir un registre de décisions exploitable

Le registre de maintenance relie chaque destination à un propriétaire, une preuve, une date de prochaine revue et une règle de repli. Il distingue un changement de contenu, une panne de l’hébergeur, une expiration de preuve et une fermeture volontaire. Cette qualification évite de masquer une fiche saine parce qu’une sonde ponctuelle a échoué, ou de conserver un bouton trompeur parce que l’URL répond encore.

Lorsqu’une destination change, la décision note l’ancienne valeur, la nouvelle, le motif, la personne qui a relu la promesse et le candidat de retour. Les contrôles automatiques peuvent alimenter la file, mais la publication d’une capacité, d’un prix ou d’un statut reste une décision humaine appuyée sur la preuve du propriétaire du produit.

Rapport utile

Le rapport de maintenance décrit le défaut utilisateur, la modification minimale et le comportement obtenu. Il conserve l’artefact, le déploiement et le rollback, sans recopier des journaux. Les statuts distinguent public, local non déployé, à finir techniquement et blocage externe.

Les métriques utiles sont liens critiques valides, preuves expirées, délai de correction et régressions évitées. Le nombre brut de pages ou de tests ne mesure pas la qualité.

Checklist ciblée

Utilisez cette checklist pour chaque fiche modifiée, puis arrêtez la validation lorsque le risque distinct est couvert.

• URL et type de destination identiques au registre.
• DNS, TLS et réponse ciblée corrects.
• Libellé cohérent avec l’action réelle.
• Profil, données et environnement de preuve précisés.
• Promesse et limites reprises sans extension.
• Date et expiration mises à jour.
• CTA masqué si une preuve manque.
• Canonical et maillage inchangés hors lot.
• Artefact exact et rollback conservés.