Le présent document vise à informer les partenaires de PerLE des efforts que fait l’équipe de soutien de PerLE pour trouver un logiciel adéquat pour remplacer celui utilisé actuellement pour produire le rapport bimensuel sur les liens brisés.

Certains partenaires de PerLE ne sont pas satisfaits par ce rapport et peuvent penser que l’équipe de soutien de PerLE n’est pas consciente de leur frustration ou ne la considère pas avec autant de sérieux qu’elle le devrait.

Depuis avril 2011, quand nous avons migré à ExpressionEngine après avoir longtemps utilisé une solution interne qui intégrait ses propres fonctions de vérification des liens, l’équipe de soutien de PerLE utilise Integrity Link Checker for Mac, de PeacockMedia car ce logiciel est l’un des seuls qui peut vérifier adéquatement les URL intégrées aux fichiers créés à l’aide d’ExpressionEngine. Cependant, nous avons alors relevé des problèmes, et certains sévissent toujours.

Parmi ces problèmes, le rapport produit fait systématiquement état de faux positifs, et il n’existe aucun moyen de les y distinguer par simple consultation des liens réellement brisés.¹. La seule façon de s’en assurer est de vérifier manuellement l’URL d’intérêt dans un navigateur Web.

À partir d’août 2012, l’équipe a, afin de chercher à éliminer certains de ces faux positifs, comparé les résultats d’un autre vérificateur de liens, Xenu Link Sleuth à ceux d’Integrity Link Checker, et cerné les liens qu’un seul des deux outils signalait brisés erronément. On a pensé qu’il était bien plus probable qu’un lien soit réellement périmé et donc problématique si plus d’un outil le relevait comme tel, et ceux-là devaient être signalés aux partenaires de PerLE pour qu’ils y voient. Si l’un des deux outils indiquait un état différent pour un lien, ce dernier risquait d’être un faux positif et l’équipe de soutien de PerLE le vérifiait.

On relevait souvent ainsi 300 sinon 400 liens brisés environ, que l’équipe de soutien de PerLE devait ensuite vérifier manuellement dans un navigateur. Établir de la sorte à chaque cycle de signalement des liens brisés lesquels devaient figurer au Rapport des liens brisés exigeait de l’équipe beaucoup de temps et d’efforts… et n’a pas réellement amélioré les choses, car les deux outils signalaient erronément comme faux positifs de nombreuses URL identiques. L’équipe a cessé cette vérification manuelle en octobre 2013.

Depuis, l’équipe de soutien de PerLE n’utilise qu’un seul vérificateur de liens : Integrity Link Checker for Mac.

Nous avons cherché depuis à trouver une autre solution. En 2014, nous avons essayé pour un mois un outil en ligne, LinkTiger, mais nous avons vite remarqué que cet outil ne reconnaissait ni ne vérifiait bien des liens de PerLE. Une question à ce propos envoyée à l’équipe de soutien de LinkTiger est restée sans suite. Nous avons cessé après un mois l’essai de LinkTiger; il n’a jamais servi à alimenter le rapport des liens brisés, car on l’a jugé trop peu fiable.

En mars 2017, un des partenaires de PerLE a demandé à son service informatique de se pencher sur l’origine d’un nombre étrangement élevé d’erreurs SSL relevé pour ses liens dans le rapport de liens brisés. Après que l’équipe de soutien de PerLE l’a renseigné sur le matériel et les logiciels utilisés pour produire le rapport sur les liens brisés, le service informatique du partenaire a conclu que le matériel et les logiciels utilisés étaient brisés, et que cela était probablement la cause des nombreuses erreurs SSL relevées. Une mise à niveau logicielle (SE et du logiciel de vérification) du poste servant à exécuter le vérificateur de liens a presque complètement éliminé les erreurs SSL, le rapport présentait tout de même bien des faux positifs.

En mai 2017, l’équipe de soutien de PerLE a repris ses recherches d’une autre solution à l’outil de vérification des liens actuel.

La gestion d’ISDE a indiqué sa préférence pour un outil en ligne, car il ne serait touché ni par la capacité du réseau interne d’ISDE ni par les interruptions du réseau sans fil interne d’ISDE (ces interruptions forcent habituellement à relancer un processus durant 2 ou 3 heures, uniquement pour recueillir les données brutes servant à créer le rapport des liens brisés). La préférence pour une solution en ligne n’a toutefois pas empêché l’équipe de soutien de PerLE d’évaluer des outils installés localement, et elle a demandé à quelques partenaires de PerLE quel outil leur propre service informatique utilisait. Nous avons reçu cinq réponses, dont les quatre listés ici, plus Xenu Link Sleuth.

1. LinkTiger - [en ligne]
2. Screaming Frog - SEO Spider - [installation locale]
3. Deep Cognition Ltd. - Deep Trawl - [installation locale]
4. Inspyder Software Inc. - InSite - [installation locale]
   • Cette solution vérifie aussi l’orthographe, ce qui serait un avantage pour la préparation annuelle des rapports de GQI.
   • InSite a relevé des erreurs dans un champ URL ignorées par Integrity, et l’équipe de soutien de PerLE entend se pencher sur la question.

Outre les essais d’autres solutions de vérification des liens, l’équipe de soutien a aussi examiné les modèles de champs de ProcessWire, car Integrity a souvent signalé des problèmes dans ces champs. Ces examens ont voulu établir si un problème jusqu’alors ignoré dans le modèle utilisé par le vérificateur de liens pouvait expliquer les erreurs relevées. Nous n’y avons remarqué aucun problème, mais dans certains cas, le serveur Web vérifié signalait un statut HTTP autre que « 200 - OK » même si la page s’affiche sans anicroche dans un navigateur.

Les vérificateurs de liens ne peuvent pas produire de résultats parfaitement fiables; nous utilisons l’outil qui, parmi les solutions choisies, donne les résultats les plus fiables.

Plusieurs facteurs peuvent influer les résultats d’un vérificateur de liens automatisé, et ils peuvent produire des résultats faux positifs pour de nombreuses raisons :

• Des problèmes de connectivité ou de réseau peuvent rendre un site inaccessible.
• Le site Web interrogé peut être hors service (mise à jour ou maintenance) pendant que le vérificateur l’interroge.
• Le serveur interrogé peut être surchargé et incapable de répondre à la requête du vérificateur (cela arrive souvent sur les sites Web partagés ou soumis à un plan de service bas de gamme).
• Le serveur peut avoir été programmé pour bloquer les requêtes de robots Web.
• Des fichiers PDF peuvent être mal formés ou partiellement corrompus (en d’autres termes, consultables par un internaute, mais pas assez conformes pour être évalués par le vérificateur).
• Des problèmes de configuration sur le serveur peuvent entraîner des erreurs relevées par le vérificateur; sur le site Web http://www.clarenville.net/ par exemple, toutes les pages renvoient un message « 500-Erreur interne du serveur », ce qui normalement le rendrait carrément inutilisable, mais on peut quand même le consulter dans un navigateur.

À la lumière de ces facteurs, nous avons conclu qu’aucun vérificateur de liens ne pourra indiquer fidèlement l’état de tous les liens proposé dans PerLE; quel que soit l’outil choisi, certains liens relevés comme problématiques ne le seront pas, ou, pis encore, certains liens réellement problématiques ne seront ni relevés ni signalés aux partenaires de PerLE.

Dorénavant, l’équipe de soutien de PerLE recommencera à utiliser deux vérificateurs de liens pour produire les données brutes utilisées pour le rapport sur les liens brisés publié sur le Site partenaires PerLE. Xenu Link Sleuth sera lancé peu après Integrity Link Checker pour qu’il revérifie les mêmes URL. Cependant, plutôt qu’une vérification manuelle des 300 ou 400 liens dont les résultats divergent entre l’un et l’autre, une nouvelle colonne figurera au rapport pour indiquer, pour chaque URL, l’état relevé par Xenu Link Sleuth.

Cela risque d’entraîner des délais dans la production du rapport et son affichage sur le site des partenaires PerLE, car il faudra à l’équipe plus de temps pour le produire.

Il incombe encore à chaque partenaire de confirmer l’état des URL brisées de sa compétence, mais ils disposeront dorénavant des renseignements sur l’état d’un URL précis fournis par le 2e vérificateur de liens.

Le risque que la 2e vérification signale un même faux positif que la première, par Integrity, reste présent, mais cette situation n’est pas du ressort de l’équipe de soutien de PerLE.

Nous recommandons aux partenaires qui remarquent systématiquement des liens erronés d’en parler aux villes touchées et les conseiller sur la question. Si la ville ne peut régler les choses sur son site Web municipal, vous pourrez demander d’omettre du rapport interne de PerLE sur les liens brisés les liens signalés systématiquement et vérifiés fonctionnels et de le noter dans le rapport. Toutefois, ces liens figureront toujours au rapport sur les liens brisés affiché sur le site des partenaires de PerLE, et il incombe donc toujours aux partenaires de vérifier les liens y figurant.

Les partenaires doivent demander à l’équipe de soutien de PerLE d’exclure ces URL, car cette dernière ne cherchera pas à les relever pour les indiquer dans le rapport des liens brisés.

Vous trouverez à l’annexe A la procédure à suivre, telle que décrite dans le courriel originel du 16 juillet 2016.

Envoyé : 18 juillet 2016, 10 h 07
Objet : [FYI] Change to Broken Links Report | [PVI] Changement au rapport sur les liens brisés

Les partenaires de PerLE indiquent souvent que certains liens mentionnés dans le rapport sur les liens brisés fonctionnent bien quand ils sont utilisés par le truchement d’un navigateur ou de l’application client PerLE.

Pour donner suite aux demandes récentes de retranchement de tels liens du rapport sur les liens brisés, le rapport sera modifié comme suit :

Les partenaires de PerLE peuvent demander (par courriel à soutien@perle-bizpal.ca) que ces liens soient signalés sur le rapport sur les liens brisés. Le lien ne sera pas réellement retranché du rapport, mais il sera signalé comme « Omis du rapport interne PerLE à la demande du partenaire. Le partenaire demeure responsable de la vérification de la validité de ce lien ». La colonne « # Jours Brisés » pour ce lien indiquera aussi « n/a », de la même manière que les codes de statut ci-après qui ne sont pas inclus dans le rapport interne :

• La requête est expirée
• Trop de redirections HTTP
• Le certificate pour ce serveur est non valide²

Voici la procédure qui sera suivie :

Partenaires :

• Devront demander que des liens déterminés soient signalés dans le rapport (si le partenaire constate qu’un lien paraît souvent dans le rapport sur les liens brisés et qu’il fonctionne adéquatement dans un navigateur ou au moyen de l’application client PerLE).
• Devra inclure le(s) numéro(s) de ligne(s) du rapport sur les liens brisés ainsi que l’(es) élément(s) identifiant le permis lorsqu’ils formuleront leur demande.
• Demeureront responsables de la vérification de la validité de tout lien signalé dans le rapport sur les liens brisés, car l’équipe de soutien de PerLE ne vérifiera pas manuellement ces liens.

Équipe de soutien de PerLE :

• Ne retranchera pas réellement le lien du rapport, car elle doit signaler aux partenaires tout lien comportant des problèmes, mas elle n’inclura pas ces liens dans son rapport interne et elle ne fera pas de rappels aux partenaires à ce sujet.
• Ne cherchera pas les liens à signaler dans le rapport sur les liens brisés et elle comptera sur les partenaires pour les lui indiquer, mais elle vérifiera les liens qui, selon les partenaires, fonctionnent dans un navigateur et dans l’application client PerLE.
• Ne signalera dans le rapport aucun lien qui, d’après l’équipe de soutien de PerLE, est réellement brisé.
• Ne signalera aucun lien dans un rapport déjà généré, mais les signalera dans les rapports « à venir », depuis le moment où ils sont indiqués par le partenaire.

¹On entend par « faux positif » un URL signalé comme problématique par un vérificateur de liens - messages d’erreur « 400 Requête incorrecte », « 403 Interdit », « 404 Fichier non trouvé », « 500 Erreur interne du serveur », « 502 Mauvaise passerelle », ou encore le dépassement du délai d’attente - mais qu’on peut facilement consulter à l’aide d’un navigateur. Ces faux positifs peuvent découler du refus par un serveur Web d’honorer les requêtes des robots Web, comme les vérificateurs de liens, ou de plusieurs autres raisons.

²Cette section précise n’est plus valide, car ces liens sont maintenant signalés comme inaccessibles (n/a).

Rapport sur les liens brisés - Problèmes avec des vérificateurs de liens - Survol et recommandations - 12 septembre 2017 / 47 Kb.