Vérifier les liens et logos de tiers sur un site web

Partir de la source officielle

Pour chaque ressource, enregistrez le nom public actuel, l’adresse officielle, la fonction exacte du service et la date de vérification. Un résultat de recherche ou un ancien communiqué peut aider à retrouver une piste, mais la page de destination doit confirmer que l’offre existe encore.

Ouvrez l’URL finale dans un navigateur et vérifiez ce qu’un visiteur y trouvera réellement. Une réponse HTTP 200 ne garantit pas que la page pertinente existe : elle peut conduire à l’accueil, une page de connexion ou un contenu sans rapport. Le répertoire web illustre des fiches avec une utilité et une destination propres.

• Nom et URL confirmés sur le site officiel.
• Destination contrôlée visuellement.
• Date de contrôle conservée.

Utiliser le bon logo et le bon contexte

Prenez le logo dans les ressources officielles de l’organisme quand elles existent. Respectez ses proportions, ses marges et les règles d’usage publiées. Ne confondez pas une ancienne identité, un favicon générique et le logo du service actuellement lié.

Une marque affichée dans un annuaire identifie une destination ; elle ne signifie pas partenariat, recommandation ou certification. Le titre de la carte doit rester lisible si l’image ne charge pas. Évitez de répéter le nom de la marque dans un texte alternatif décoratif lorsque le même nom figure juste à côté.

• Fichier attribuable à la bonne entité.
• Proportions préservées.
• Aucune relation commerciale suggérée sans preuve.

Contrôler les changements et les erreurs

Examinez les redirections, les codes d’erreur et les changements de domaine à intervalles réguliers. Complétez le contrôle automatique par un échantillon visuel : les liens peuvent rester techniquement valides tout en devenant inutiles. Signalez aussi les logos qui ne chargent plus, surtout lorsqu’ils proviennent d’un serveur tiers.

Quand une ressource ferme ou fusionne, choisissez sa page de remplacement officielle, corrigez la description ou retirez la carte. Ne redirigez pas silencieusement le lecteur vers un acteur différent. Si une vérification nécessite un compte, indiquez la limite de ce qui a été confirmé.

Exercice fictif : l’outil reçoit 405 pour HEAD, tandis qu’un GET de la même URL donne 200 et le bon contenu. Notez les deux méthodes plutôt que « site fermé ». HEAD demande les métadonnées sans corps de réponse ; il ne permet donc pas de lire la page. Un 405 concerne la méthode non prise en charge pour la ressource et doit être examiné avec l’en-tête Allow. Ce scénario illustre un contrôle, sans justifier une mauvaise configuration du serveur.

Conservez URL demandée, méthode, date du contrôle, statuts intermédiaires, URL finale et résultat éditorial. Une redirection vers une connexion, un 200 sans rapport ou un délai dépassé demandent des décisions différentes. Si le contrôle est refusé, indiquez la limite constatée et utilisez un accès autorisé pour la revue ; n’inventez ni fermeture ni validation. Sans réponse HTTP reçue, le statut est inconnu : « 0 » n’est pas un code HTTP du serveur.

• Redirections et erreurs suivies.
• Contrôle visuel en complément.
• Fusions et fermetures expliquées.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Garder une fiche utile dans chaque langue

Rédigez pour chaque ressource une raison d’usage concrète : à quelle question répond-elle, pour qui et dans quel pays ou cadre ? Une simple liste de logos ne donne pas assez d’information pour choisir. Évitez les superlatifs impossibles à vérifier.

Vérifiez les intitulés traduits et les pages de destination selon la langue. Si la source n’existe qu’en français, dites-le plutôt que d’inventer une version anglaise. Le guide multilingue aide à garder les traductions et les liens cohérents.

• Usage décrit en une phrase précise.
• Langue de destination explicite.
• Fiches traduites revues après changement.

Inventorier les fonctions réellement nécessaires à une intégration tierce.

Cas fictif : une carte intégrée fonctionne sans caméra ni microphone, mais un autre composant utilise une fonction autorisée. Testez les politiques sur une copie du parcours et contrôlez chaque directive dans les navigateurs visés. Ne copiez pas une liste de restrictions sans connaître ses effets ; la politique ne remplace pas les permissions demandées à la personne.

• Les fonctions nécessaires restent disponibles, les restrictions ciblées sont contrôlées et les différences de prise en charge sont documentées.

• MDN Permissions-Policy

  En-tête contrôlant l’usage de certaines fonctions du navigateur par un document et ses cadres intégrés, selon leur prise en charge.