Auditer le contenu du site événementiel avant de changer de CMS
Changer de CMS déplace le lieu où l’équipe modifie le site de l’événement. Même si le domaine et les URL publiques ne changent pas, le nouvel outil peut stocker autrement dates, lieux, langues, fichiers et relations entre pages. Copier l’accueil ne prouve pas que l’ancien programme, le lien de billetterie actuel ou les archives ont suivi. Réalisez cet audit avant l’import : il concerne les contenus et leur validation éditoriale, pas la bascule d’hébergement ou du DNS.
La rédaction de Boletolibre
Publié
Définir le périmètre et la publication
Notez l’ancien et le nouveau CMS, le site exact, l’édition en cours et la personne habilitée à valider les faits. Pour le domaine, les chemins d’URL, la billetterie et l’hébergement des médias, indiquez « inchangé », « modifié » ou « à confirmer ». Le CMS peut changer alors que DNS, paiement et courriel restent chez leurs responsables actuels. Si ces systèmes évoluent aussi, donnez-leur des plans et des responsables distincts.
Fixez l’heure de l’export et ouvrez un journal des modifications. Entre l’export et la mise en ligne, l’équipe peut corriger une entrée, ouvrir la vente ou déplacer une session. Consignez chaque modification publiée, sa source, sa validation et son chemin vers le nouveau CMS. Sans liste des changements tardifs, l’aperçu peut sembler complet tout en rétablissant une information obsolète. Prévoyez une approbation finale de l’inventaire et des points non résolus.
Recenser pages, fichiers et relations
Créez une ligne par URL publique et une par fiche du CMS qui alimente plusieurs pages. Incluez la page permanente de la série, l’édition actuelle, les anciennes éditions, le programme et les sessions, les intervenants, le lieu, l’accès, la FAQ, les partenaires, les comptes rendus, les téléchargements et les traductions existantes. Ajoutez les pages absentes du menu mais accessibles depuis un courriel, un code QR ou une recherche. Comparez l’export du CMS à la navigation en ligne, au plan du site et aux liens déjà diffusés.
Pour chaque ligne, relevez ancienne URL, usage, édition, langue, visibilité, responsable, dernière validation, identifiant source, modèle, médias et liens d’action. Notez les liens entre fiches : quel intervenant rejoint quelle session, quel programme appartient à quel jour et quelle entrée est décrite par l’itinéraire. Des affiches homonymes peuvent être des versions différentes; distinguez révision approuvée et utilisation publique. La grille révèle les exceptions avant l’import massif.
Décider de ce qui doit suivre
Attribuez une décision à chaque contenu : copier après vérification, actualiser d’après une source validée, garder comme archive datée, fusionner avec une page réellement équivalente ou retirer avec une destination approuvée. Un faible trafic ne suffit pas à supprimer une page. Des indications d’arrivée peuvent être indispensables malgré peu de visites; le compte rendu d’une ancienne édition ne doit pas mener directement à la caisse de la nouvelle. Confirmez les faits auprès des responsables du programme, du lieu et des billets.
Inscrivez l’action suivante et la personne qui tranche chaque exception. Si un titre de session est validé mais sa salle reste inconnue, ne reprenez pas celle de l’an dernier. Avant de retirer une page partenaire, vérifiez les pages qui pointent vers elle. L’édition actuelle et les archives conservent leurs dates et leur contexte propres. L’audit se termine lorsque les questions sont résolues ou explicitement exclues de la publication.
Faire correspondre les modèles de contenu
Préparez aussi une grille des types et des champs, au-delà des URL. Pour chaque ancien type, notez son rôle, le champ cible, son format, son caractère obligatoire, son comportement par langue, ses relations et sa règle de transformation. Une date et une heure stockées en texte libre peuvent nécessiter des champs distincts, y compris le fuseau horaire; un nom d’intervenant peut devenir une relation vers une fiche. Conservez les formulations et fuseaux approuvés plutôt que de les déduire de l’export.
Essayez la correspondance sur un événement simple, un programme de plusieurs jours, une traduction, une édition reportée ou archivée et une page avec média particulier. Signalez ce que le nouveau CMS ne représente pas sans champ, composant ou correction manuelle. Si l’ancien site publie des données structurées Event, confrontez leurs dates, lieu, statut et lien de billets aux faits visibles. Google décrit ces propriétés, mais un CMS ne les produit pas nécessairement. Un titre importé ne signifie pas que la fiche est complète.[2]
Séparer les URL des services externes
Gardez les chemins publics qui correspondent toujours à la même page, si le système le permet. En cas de changement, notez ancienne URL, nouvelle destination et motif avant de publier. Google recommande de relier chaque ancienne URL à une destination pertinente, de mettre à jour les liens internes et d’utiliser des redirections pour un vrai déplacement. Une redirection systématique vers l’accueil ne remplace pas une réponse utile. Incluez campagnes, codes QR, fiches d’intervenants et archives.
Distinguez ce que gère le CMS de ce qui appartient à un service externe. Billetterie, carte, formulaire, lien calendrier ou direct vidéo peuvent dépendre d’un autre compte. Notez responsable, destination exacte, accès et solution de repli, sans supposer que la migration les copie. Contrôlez images et téléchargements si leur chemin change. Associez chaque version linguistique à sa destination appropriée. La rédaction valide la correspondance; l’équipe technique réalise et vérifie les URL.[1]
Tester les parcours réels avant la mise en ligne
Choisissez des parcours depuis l’inventaire : ancien favori ou recherche, invitation, page de la série et affichage sur téléphone. Comparez date, fuseau, lieu, conditions d’entrée et action suivante aux sources approuvées. Suivez le lien de billetterie jusqu’au transfert public sans passer commande. Une ancienne édition ne doit pas renvoyer sans explication à la billetterie actuelle.
Comparez des exemples de chaque type de page et de chaque langue à l’ancien site et aux sources. Vérifiez titres, tableaux lisibles, images, légendes, téléchargements, vue mobile, clavier et liens. Le W3C recommande un texte alternatif adapté au rôle de l’image; copier le fichier sans son alternative utile demande une correction. Si des données structurées Event existaient, vérifiez leur accord avec la page visible et utilisez un validateur adapté. Consignez URL, fait attendu, résultat, responsable et nouvelle vérification.[3][2]
Rapprocher l’import et consigner les validations
Avant la publication, comparez les nombres de fiches source et cible par type, édition et langue. Ce n’est qu’un signal de complétude : l’absence d’une page d’accès compte plus que plusieurs brouillons sans enjeu. Reprenez les exceptions et les changements depuis l’export. Faites valider les faits par le responsable de l’événement, les champs par le responsable du CMS et les liens et la visibilité par le responsable web. Conservez la version de l’inventaire approuvée.
Après mise en ligne, ouvrez les URL prévues dans une session de navigation neuve. Contrôlez page actuelle, archives, téléchargements et services externes. Si les URL ont changé, suivez redirections, liens internes, sitemap et Search Console dans le temps; Google précise que le déplacement est traité URL par URL, sans date garantie. Si un fait ou une action importante échoue, appliquez la responsabilité de correction ou de retour arrière documentée et notez les URL touchées. Gardez l’audit pour l’édition suivante.[1]
Télécharger l’audit de contenu et la grille de correspondance des champs (Markdown en anglais)
Sources et lectures complémentaires
- How to move a siteGoogle Search Central · Consulté
- Event structured dataGoogle Search Central · Consulté
- Images TutorialW3C Web Accessibility Initiative · Consulté