Temps de lecture estimé : 5 min · Publié le
Contrôler les parcours chaque mois
Ouvrez les pages principales sur téléphone et ordinateur. Testez navigation, filtres et formulaire avec une demande de contrôle ; vérifiez sa réception et le message de confirmation.
Regardez les images principales, les cartes, les liens internes et les documents téléchargeables. Une fiche vide peut rester invisible si personne ne parcourt le site comme un nouveau client.
Le contrôle mensuel ne remplace pas un essai après un changement qui touche la reprise. Un nouveau stockage, une rotation de clé, une migration du CMS ou le départ d’un responsable peuvent invalider une procédure auparavant utilisable. Pour chaque événement, choisissez un test ciblé dans un environnement isolé. Relevez la version de la procédure et les références des copies effectivement essayées, plutôt que de reporter automatiquement le précédent résultat « réussi ».
Séparez les preuves : archive retrouvée, lecture ou déchiffrement possible, données cohérentes et parcours fonctionnel. Une empreinte peut contrôler la correspondance avec une référence attendue ; elle ne démontre pas que le CMS, sa base et ses médias fonctionnent ensemble. Chronométrez aussi la récupération des copies et l’accès aux moyens autorisés. Conservez le résultat et les éléments manquants sans inscrire de clés ou de mots de passe dans le compte rendu public.
Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.
| Événement | Essai ciblé proposé | Preuve à conserver |
|---|---|---|
| Changement de stockage | Retrouver le jeu complet depuis le contexte de reprise autorisé | Références des copies, accès et temps de récupération |
| Rotation de clé de sauvegarde | Déchiffrer une génération conservée avec le moyen autorisé | Génération et résultat, sans publier la clé |
| Migration du CMS ou de sa base | Restaurer code, base et médias cohérents en environnement isolé | Versions, éléments retrouvés et parcours métier testé |
| Changement du responsable | Faire suivre la procédure par le remplaçant autorisé | Étapes manquantes, accès nécessaires et procédure corrigée |
Garder les contenus exacts
Attribuez un responsable aux tarifs, horaires, disponibilités, zones couvertes et conditions. Corrigez ensemble les pages qui parlent du même sujet pour éviter les contradictions.
Relisez les articles lorsqu’un outil ou une recommandation évolue. Ne changez une date de mise à jour publique que lorsqu’une modification éditoriale réelle le justifie.
Prévoir la continuité
Documentez la fréquence des sauvegardes et vérifiez qu’une restauration fonctionne. Planifiez les mises à jour des composants et retestez les fonctions essentielles après chaque changement.
Surveillez les erreurs de pages, les demandes et les données de recherche disponibles. Notez ce qui a changé et son résultat avant de décider quelles pages enrichir, fusionner ou retirer.
Dans cet exercice fictif de maintenance, quatre contrôles ont chacun leur critère : un passe, un échoue et deux restent non vérifiés. Un résultat inconnu ne doit pas devenir vert par défaut. L’accueil peut répondre correctement pendant que le formulaire n’enregistre rien ; de même, l’acceptation d’un message par un prestataire et la fin d’une tâche de sauvegarde ne prouvent pas tout le parcours attendu.
Pour chaque écart, notez le responsable, son remplaçant autorisé et la prochaine action vérifiable. Les rôles du tableau sont des exemples, pas l’organisation déclarée d’un client. Conservez date, environnement et référence du test, sans recopier les messages privés. Une série de quatre contrôles ne suffit pas à calculer une disponibilité mensuelle : celle-ci exige une période, un périmètre et une méthode de mesure définis.
Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.
| Contrôle | Résultat et limite | Responsable et suite attendue |
|---|---|---|
| Accueil | Réussite : statut 200 et contenu attendu observés | Rôle web : conserver ce résultat limité à l’accueil |
| Formulaire | Échec : réponse 200 mais aucune demande enregistrée dans le test | Rôle applicatif : rechercher l’écart puis refaire le parcours |
| Courriel de confirmation | Non vérifié : prestataire accepté, réception de test non contrôlée | Rôle messagerie : vérifier le trajet jusqu’au destinataire de test |
| Sauvegarde | Non vérifié : tâche terminée, restauration non essayée | Rôle sauvegarde : réaliser l’exercice isolé prévu |
- Google SRE : Monitoring Distributed Systems
Google SRE, consulté le 22 octobre 2026 : signaux internes et comportement utilisateur. Les quatre contrôles et leurs résultats sont fictifs.
Un suivi qui déclenche une action
Séparez contrôles réguliers, traitement des incidents et évolutions éditoriales. Décrivez pour chaque contrôle le seuil ou état d’alerte, le responsable et l’action attendue. Une liste sans propriétaire ne garantit pas la continuité.
Gardez la trace des modifications et testez le parcours affecté. Lors d’un changement de dépendance ou de prestataire, relisez le périmètre et la reprise. Horaires, contenus saisonniers et formulaires demandent un suivi distinct des mises à jour techniques.
Décider dans une situation concrète
Exemple fictif : une équipe doit choisir entre moderniser un carrousel et corriger un module de connexion obsolète. Examinez exposition, utilisateurs concernés et solution de remplacement ; le changement le plus visible n’est pas forcément le plus utile.
Pour chaque intervention, notez composant, version, raison, responsable et vérification après changement. Regroupez les tâches de présentation séparément des corrections qui conditionnent l’accès ou la sécurité ; une sauvegarde seule ne valide pas la mise à jour.
- Automatiser et vérifier le renouvellement des certificats TLS
Comprendre les échéances TLS 2026–2029, tester le renouvellement, vérifier le certificat réellement servi et préparer les alertes.
Une alerte doit avoir un destinataire et une action
Pour un contrôle automatique, précisez ce qui est observé : réponse de la page, expiration du certificat, exécution d’une sauvegarde ou remise d’un message. Un statut HTTP 200 peut accompagner une page qui affiche une erreur. Définissez donc au moins une vérification du parcours critique et la personne qui examinera l’alerte.
Documents de référence
Contenu mis à jour le