Discussion modèle:Lien web

Cette page de discussion est automatiquement archivée. Les sections n'ayant aucune activité depuis une année sont automatiquement déplacées.

Archives

• Lien web/Archives/2006
• Lien web/Archives/2008
• Lien web/Archives/2009
• Lien web/Archives/2010
• Lien web/Archives/2011
• Lien web/Archives/2012
• Lien web/Archives/2013
• Lien web/Archives/2014
• Lien web/Archives/2015
• Lien web/Archives/2016
• Lien web/Archives/2017
• Lien web/Archives/2018
• Lien web/Archives/2019
• Lien web/Archives/2020
• Lien web/Archives/2021
• Lien web/Archives/2022
• Lien web/Archives/2023
• Lien web/Archives/2024
• Lien web/Archives/2025

Cette page est archivée automatiquement par OrlodrimBot.

Paramètres site et périodique

Message déplacé depuis ma PdD. — Vega (discuter) 2 octobre 2025 à 20:42 (CEST)

Bonjour. Nous sommes deux vieux contributeurs qui connaissons bien les us et coutumes de notre chère fr.wikipédia. Voilà près de 20 ans que je contribue principalement à valider les références de sources web. Je l'ai fait pendant de nombreuses années pour les articles proposés au label AdQ, c'est ainsi qu'à la suite de nombreuses discussions, j'ai appris ce que devait être un article de qualité défini comme « un article qui doit raisonnablement se rapprocher de l'article parfait ». Je m'efforce donc d'utiliser les modèles aussi « parfait »ement que possible.

La documentation du {{Lien web}} indique la présence du champ « site », à la fois pour la syntaxe minimale et pour la syntaxe minimale indentée : il est en effet indispensable que le lecteur ait connaissance du site d'où provient l'information. Le champ « périodique » est à utiliser — en complément — lorsque la référence conduit à une page web du périodique. Par exemple, sur le site du quotidien Le Monde, tu as de nombreuses pages web : des pages où figurent les articles publiés par le quotidien, une foule d'articles divers (notamment beaucoup d'infos d'actualité publiées en temps réel, et donc pas dans le périodique), des pages où des auteurs divers (en dehors des journalistes et pigistes du journal) publient des billets, etc. Plusieurs sites de périodiques proposent des pages de tribunes/blogs (les noms sont variés) où des auteurs (extérieurs au périodique) peuvent publier.

Dans le cas de l'article consacré à Sébastien Lecornu, je n'ai trouvé nulle part la preuve que la page web telle que je me suis efforcé de la référencer correctement, soit issue du périodique.

J'espère avoir été clair, mais n'hésite pas à revenir vers moi si nécessaire. Bien cordialement. AntonyB (discuter) 16 septembre 2025 à 18:26 (CEST)

Bonjour. Pris d'un remords, je suis revenu à l'article pour vérifier ce que je t'avais écrit. Je confirme (au moins pour tous les référencements que j'ai vérifiés) qu'il s'agit de pages web publiées en dehors du périodique. Par exemple, la première référence au Monde, est un article publié à 3 heures du matin qui n'a pas été publié dans l'édition du soir. Il est du reste modifié à 10h58 le lendemain, donc s'il avait été publié dans le périodique, alors le contenu de cette page serait différent, et il faudrait référencer cette page web et pas le périodique. Mais le plus important, c'est que nous savons que cette page n'a pas été publiée par le périodique puisqu'elle n'est disponible qu'aux abonnés. À ce sujet, heureusement que nous pouvons lire la plupart de ces pages à accès payant grâce à tous les wikipédiens qui nous font bénéficier de leurs abonnements (voir ici et personnellement pour Diapason étant abonné depuis 1968, ce qui a été bien utile pour répondre à différentes pcw ces dernières années, tout comme mes 40 années de Télérama). En conclusion, je vais remettre le champ « site » et supprimer le champ « périodique » lorsque cela est nécessaire. Bien cordialement. AntonyB (discuter) 17 septembre 2025 à 14:38 (CEST)

Bonjour AntonyB, je me permets de déplacer ton message ici, pour élargir la discussion aux autres wikipédiens. Mes excuses pour le délai de ma réponse.

Nous partageons l'attention à la qualité des articles. Aussi je suis surpris que tu confondes certaines notions du modèle : seul le paramètre url est obligatoire (voir le début de la documentation, que j'évoquais), les autres paramètres donnés dans la « syntaxe minimale » puis la « syntaxe intermédiaire » sont simplement les plus courants, mais on ne peut pas toujours les renseigner, donc ils ne sont pas obligatoires. Techniquement, MediaWiki renvoie une erreur si on ne renseigne pas url.

Ensuite, site reçoit le « nom du site, s'il ne s'agit pas d'un périodique, ou adresse web (votresite.com). » Dans notre cas, Le Monde est bien un périodique, donc on ne devrait pas utiliser site ; peu importe que son site web héberge, bien sûr, d'autres contenus que la version papier, c'est avant tout un journal. On pourrait à la rigueur renseigner |site=lemonde.fr |périodique=[[Le Monde]], mais le modèle n'accepte pas un tel doublon, à raison. Ces deux paramètres site et périodique appliquent aussi la typographie (« Le Monde » en italique, « Wikipédia » en romain), comme tu le sais, qui pourrait changer si quand nous arriverons à nos fins (cf. Discussion modèle:Lien web/Archives/2024#Paramètre site).

Donc écrire |site=le site du quotidien Ouest-France est contraire à la fois au modèle et aux conventions typographiques, c'est problématique.

Je comprends que tu souhaites renseigner au mieux le lecteur (cf. aussi cette discussion sur ta PdD), mais ajouter systématiquement « sur le site du quotidien... » est en fait assez lourd et finalement superflu : si le lecteur ne connaît pas Le Monde, il lui suffit de passer le curseur sur le lien ou de l'ouvrir, comme pour tout LI !

J'espère avoir éclairci ces points, mieux qu'en commentaires de diffs. Salutations — Vega (discuter) 2 octobre 2025 à 20:42 (CEST)

---

Merci Vega pour ce retour sur le sujet. Pour ton info, le titre est obligatoire : voir cet exemple où j'ai retiré le titre.

Je pensais avoir été clair dans mon explication. Je persiste à penser qu'écrire

<ref>
{{Lien web
 |url=https://www.lemonde.fr/m-le-mag/article/2022/02/06/sebastien-lecornu-la-droite-au-service-du-president_6112508_4500055.html
 |accès url=payant
 |titre=Election présidentielle 2022 : l’ascension de Sébastien Lecornu, symbole de la droitisation du quinquennat Macron
 |date=6 février 2022
 |auteur= Grégoire Biseau
 |site=[[Le Monde]]
 |consulté le=9 septembre 2025
}}.</ref>

qui donne

est différent de

<ref>
{{Lien web
 |url=https://www.lemonde.fr/m-le-mag/article/2022/02/06/sebastien-lecornu-la-droite-au-service-du-president_6112508_4500055.html
 |accès url=payant
 |titre=Election présidentielle 2022 : l’ascension de Sébastien Lecornu, symbole de la droitisation du quinquennat Macron
 |date=6 février 2022
 |auteur= Grégoire Biseau
 |site= le site du [[Le Monde|Monde]]
 |consulté le=9 septembre 2025
}}.</ref>

qui donne.

Il faut toujours se mettre à la place du lecteur lambda, et non pas du rédacteur. Dans le premier cas, le lecteur comprend que l'article a été publié par Le Monde (il lit « sur Le Monde ») et dans le second cas que l'article a été publié sur le site du Monde, ce qui est différent : le premier c'est un journal, le second c'est un site Web.

Autre point important que je montre à partir d'un exemple pris au hasard dans l'article France. Je lis :

<ref>
{{Lien web
 |url=https://education.gouv.fr/cid237/les-collectivites-territoriales.html
 |titre=Les collectivités territoriales
 |site=[[ministère de l'Éducation nationale (France)]]
 |consulté le=22/2/2010
}}.</ref>

ce qui est l'exemple type de l'erreur contre laquelle je lutte. Car cela donne,

ce qui prête à sourire, les collectivités territoriales ne sont pas « sur le ministère » et encore moins « sur ministère », ce qui est de l'affreux français. Cette erreur de référencement de source web est bien malheureusement très très très fréquente, on la voit partout et — tu l'as remarqué, j'en suis conscient — toujours en italique !

Je contribue depuis longtemps à la validation des référencements de sources issues du Web ; je suis donc tout disposé à discuter de l'amélioration de l'utilisation de ce modèle.

Bien cordialement. AntonyB (discuter) 2 octobre 2025 à 22:25 (CEST)

Bonjour AntonyB,

1. Le paramètre est presque obligatoire : toujours selon la documentation, il est « obligatoire, sauf si le paramètre description est renseigné ». Tout comme url peut à vrai dire être remplacé par doi. Faut-il le préciser dans la section Syntaxe ?

2. D'accord, mais le journal est aussi publié sur le site web du Monde, n'est-ce pas ? De nos jours, qu'un article soit sur papier ou sur écran, cela ne fait plus vraiment de différence. Si l'on veut vraiment faire référence à une version sur papier, on utilise de toute façon {{Article}} en précisant le n° de parution et la page.

3. Oui, "sur ministère" est un abus de langage assez moche ; le paramètre éditeur (du site) l'évite. En fait il faudrait sans doute supprimer le "sur", tout comme on a supprimé le "www.", en plus de supprimer l'italique, mais on n'y est pas encore.

Salutations — Vega (discuter) 3 octobre 2025 à 14:33 (CEST)

Lien web sur fichier

Bonjour, Comment faire un lien web vers un fichier à télécharger (pour citation en référence), par exemple un fichier xlsx ? Exemple : Sur la page https://ec.europa.eu/eurostat/web/nuts il y a un fichier NUTS2021-NUTS2024.xlsx à télécharger. Ce fichier est sur l'URL https://eurostat/documents/345175/629341/NUTS2021-NUTS2024.xlsx/2b35915f-9c14-6841-8197-353408c4522d?t=1717505289640 mais écrire directement {{Lien web |url=https://eurostat/documents/345175/629341/NUTS2021-NUTS2024.xlsx/2b35915f-9c14-6841-8197-353408c4522d?t=1717505289640 |format={{Xlsx}} ...}} ou {{Lien web |url=https://eurostat/documents/345175/629341/NUTS2021-NUTS2024.xlsx|format={{Xlsx}} ...}} ne fonctionne pas. Je suis obligé d'écrire {{Lien web |url=https://ec.europa.eu/eurostat/web/nuts |format={{Xlsx}} ...}}, ce qui ne donne pas directement le fichier voulu. Yv91 (discuter) 26 octobre 2025 à 10:18 (CET)

Bonjour, si vous retirez la portion après ?t=… de l'URL (qui semble être unique à chaque nouveau téléchargement, en tous cas je n'ai pas eu la même chose que vous), alors le téléchargement fonctionne : « NUTS2021-NUTS2024.xlsx ». — V_VL_LA_AC_C 26 octobre 2025 à 10:29 (CET)

Cependant, je ne sais pas si c'est une bonne idée d'utiliser un lien de téléchargement directement comme source… — V_VL_LA_AC_C 26 octobre 2025 à 10:30 (CET)

Bonjour Yv91 et VVLLAACC, le fichier n'est semble-t-il plus accessible, mais en tout cas il n'est pas nécessaire d'utiliser un modèle pour le format : |format=xlsx suffit, le modèle le met en forme. Bonne journée — Vega (discuter) 26 octobre 2025 à 11:57 (CET)

Le fichier est accessible de mon côté. Cordialement — V_VL_LA_AC_C 26 octobre 2025 à 12:04 (CET)

Merci @VVLLAACC et @Vega.

Cela marche en effet. Il manquait ec.europa.eu/ à mon URL ! Yv91 (discuter) 26 octobre 2025 à 15:05 (CET)

Est-ce une bonne idée ou pas ? Je reste ouvert à tout avis, en tout cas la documentation du modèle "lien web" renvoie à Catégorie:Modèle extension de fichier par le lien "Voir les formats acceptés." de son paramètre "format", ce qui autorise de fait les formats de fichiers indiqués. Yv91 (discuter) 26 octobre 2025 à 15:14 (CET)

Permettre d'obtenir facilement la date du jour dans « consulté le »

Bonjour, je suis un fréquent utilisateur de Lien web (la plupart du temps avec ProveIt), et je dois toujours saisir manuellement la date de consultation de la référence, alors que celle-ci est toujours la date du jour. Alors j'essaie de voir comment insérer cette date plus facilement. Avec l'explication donnée par @Escargot bleu je comprends que le format Chaîne donné au paramètre ne permet pas l'insertion automatique d'une date, alors que Date le pourrait. Le désavantage serait qu'avec Date il faut nécessairement une date formatée aaaa-mm-jj. Pourtant, dans le Modèle:Article, la date de consultation est bien en format Date, et ça semble fonctionner pour tout le monde. J'ai fait plusieurs essais ici, et je constate que, peu importe qu'on utilise Article avec ProveIt, avec le gadget Insérer un modèle ou directement en wikicode, l'utilisateur garde le choix d'utiliser le bouton Aujourd'hui, le calendrier, ou saisir en format lettres, jj-mm-aaaa ou aaaa-mm-jj. Donc il n'y a que des avantages à faire passer le champ Consulté le de Lien web au format Date, à moins que j'aie manqué quelque chose ? Cortomaltais parloir ➔ 20 avril 2026 à 16:40 (CEST)

Voici la version reformulée, sans les sous-titres `===`, remplacés par des tirets/mise en emphase :

---

Proposition de patch : comportement des liens brisés avec archive

Bonjour, à la suite de la discussion sur le lien brisé, je propose un patch du Module:Biblio/Lien web qui gère Modèle:Lien web, concernant le comportement des liens brisés disposant d'une archive.

— Comportement actuel

Actuellement, lorsqu'un lien est signalé comme brisé (« brisé le ») et qu'une « archive-url » est fournie, le lien principal du titre continue de pointer vers l'URL d'origine (morte). L'archive n'est affichée qu'en lien secondaire à la fin de la référence, ce qui incite le lecteur à cliquer d'abord sur un lien mort.

— Modification proposée

Le patch propose que, lorsque les deux conditions suivantes sont réunies :

• le lien est signalé comme brisé avec « brisé le » ;
• une URL d'archive est fournie avec « archive-url » ;

l'archive devienne le lien principal du titre.

Le lien original reste conservé pour la traçabilité et pour identifier le site d'origine. Si le paramètre « site » est explicitement fourni, celui-ci reste prioritaire. Lorsqu'il n'est pas fourni, le nom du site est extrait automatiquement de l'URL originale.

Le rendu permet ainsi d'obtenir le résultat suivant :

Sabrsl, « Test archive comme lien principal » [archive du 1^er janvier 2020] , sur original via Internet Archive, 5 janvier 2015 (consulté le 25 juillet 2026)

Sabrsl, « Test archive comme lien principal » [archive du 1^er janvier 2020], sur original.com via Wikiwix (consulté le 25 juillet 2026)

Le nom du site et la mention du service d'archivage ne sont donc générés automatiquement que dans le cas où l'archive devient le lien principal, c'est-à-dire lorsque « brisé le » + « archive-url » sont présents.

— Compatibilité

Le comportement existant est totalement conservé dans les autres situations :

• « archive-url » sans « brisé le » : comportement actuel conservé ;
• lien brisé sans « archive-url » : comportement actuel conservé, avec les liens proposés vers les services d'archivage ;
• « site » fourni : le nom fourni est conservé.

Le patch ne modifie nullement le comportement général de Lien web, en dehors de ce cas précis.

— Tests dans le bac à sable

J'ai reproduit le comportement dans le Modèle:Lien web/Bac à sable et Module:Biblio/Lien web/Bac à sable, et effectué plusieurs tests :

• lien brisé + archive présents (cas du patch) ;
• archive sans lien brisé ;
• lien brisé sans archive ;
• lien brisé avec archive et « site » explicite ou non renseigné.

Tous les tests passent avec succès. (Les dépendances utilisées dans le bac à sable sont les versions de test.)

Voir les détails des tests ici.

Je propose donc ce patch à la discussion pour modification du module en production.

Merci. — Sabrsl --❯ ♥ ^[discuter] 23 août 2026 à 03:31 (CEST)

Pour fort. Merci beaucoup, @Sabrsl, ce sera déjà une bonne avancée. Ping @Irønie et @Lupin~fr. Question : ne serait-il pas opportun d'ajouter un LI sur Internet Archive et Wikiwix ? — Jules* ^💬 23 août 2026 à 12:22 (CEST)

Merci @Jules* pour ton retour, je t'en prie. Pour les LI vers Internet Archive et Wikiwix, j'ai pensé à la densité d'infos pour le lecteur et je me suis dis non, mais oui c'est plus explicite finalement. Je vais intégrer ce point au patch dans le bac à sable et ajouter les tests ici pour vérifier le rendu. Je confirme une fois ok. — Sabrsl --❯ ♥ ^[discuter] 23 août 2026 à 12:45 (CEST)

Je comprends, mais je ne pense effectivement pas que ce soit gênant : l'usage est déjà, par exemple, de mettre des LI vers le nom de l'éditeur dans chaque ref, même quand il est le même. Là, l'information véhiculée par ces LI est utile pour les lecteurs, sans doute nombreux, qui ne connaissent rien à l'archivage. Merci encore. — Jules* ^💬 23 août 2026 à 12:50 (CEST)

Ca marche, j'ai compris. — Sabrsl --❯ ♥ ^[discuter] 23 août 2026 à 13:06 (CEST)

Re @Jules*, Fait et testé.

● Sabrsl, « Test archive comme lien principal » [archive du 1^er janvier 2020], sur original via Internet Archive, 5 janvier 2015 (consulté le 25 juillet 2026)

● Sabrsl, « Test Wikiwix » [archive du 1^er janvier 2020] , sur exemple.com via Wikiwix (consulté le 22 janvier 2026)

Internet Archive et Wikiwix sont désormais LI WP. — Sabrsl --❯ ♥ ^[discuter] 23 août 2026 à 18:24 (CEST)

Bonjour,

merci pour la notif @Jules*, et pour ce correctif @Sabrsl :)

Ça me semble très bien, en particulier le souci de ne pas changer le comportement actuel, ainsi que le LI proposé par Jules*.

D'un point de vue fonctionnel, je me demandais s'il te semblait possible (et pas trop chronophage) d'afficher un lien vers plusieurs archiveurs comme les 3 que tu prévois actuellement plutôt qu'un seul.

Cela augmenterait la résilience en cas de défaut d'un archiveur.

Par ailleurs, cet affichage permettrait d'y intégrer une archive spécifique si archive-url est présent, en l'intégrant au milieu des autres.

Dans l'idéal, il ne serait affiché que si l'archive existe mais c'est le palier suivant ;). - Lupin (discuter) 23 août 2026 à 17:19 (CEST)

Bonjour @Lupin~fr, merci pour ton retour. En outre, oui, c'est possible sous forme de modal pour donner le choix à l'user de choisir quel archive consulter, c’est une évolution intéressante. Cependant, la vérification de l’existence d’une archive valide chez chacun d’eux constituerait un second niveau. Mais comme tu dis, c'est pour un next cap. — Sabrsl --❯ ♥ ^[discuter] 23 août 2026 à 18:36 (CEST)

Le modèle affiche l'URL d'archive choisie par l'utilisateur, @Lupin~fr. Je ne pense pas souhaitable d'afficher plusieurs archives, ça complexifie le résultat visuel (cf. comportement de {{lien brisé}}). — Jules* ^💬 23 août 2026 à 19:17 (CEST)

Ça me parait bien comme ça. -- Hippo ^{discutez sans frapper} 23 août 2026 à 19:39 (CEST)

@Sabrsl par modal, j'entend fenêtre modale, mais ça ne semble pas ce que tu désignes ici, je me trompe ? :)

Je pensais afficher plusieurs archives, et laisser les gens choisir pour rester simple.

Ah, je trouvais ça intéressant d'afficher au moins deux archives pour ne pas avoir à identifier si une archive est indisponible tout en laissant choisir les lecteurs et lectrices @Jules*. - Lupin (discuter) 24 août 2026 à 01:05 (CEST)

@Lupin~fr, non du tout. Je faisais allusion à un seul service d’archivage utilisé pour les références WP, par exemple :

Sabrsl, « Test archive comme lien principal » [archive du 1^er janvier 2020], sur original via Internet Archive, 5 janvier 2015 (consulté le 25 juillet 2026)

(Alors que toi, tu en proposes au moins deux.)

En effet, je t'ai induit en confusion car j'ai aussi parlé de 3 services d'archives pour l'outil de correction que je développe qui est censé chercher l'archive valide de la référence en question. J'ai mélangé les infos du Patch (1 seul service d'archivage soit Wikiwix - Internet Archive ou arquivot) et celles de l'outil OviX (3 services d'archivage pour aller à la chasse). Désolé pour cette confusion. — Sabrsl --❯ ♥ ^[discuter] 24 août 2026 à 02:41 (CEST)

Pour Après audit rapide (IA), de la proposition et des tests de @Sabrsl: c'est ok pour moi. Détails à corriger ou discuter (maintenant ou plus tard) :

• Wikification : Je suis favorable à la wikification des archiveurs (Internet Archive et Wikiwix) ; pour les gars de la maintenance, ça semble superflu ou encombrant — mais pour un lecteur de l'article, les solutions Waybayck/Wikiwix sont très probablement inconnues et la wikification offre donc la possibilité d'information (et une info "de confiance" sur le site externe où il sera envoyé).
• Les idées très nouvelles (modale), faites ça plus tard et ailleurs. Sinon ça va ralentir ou bloquer la simple modification proposée ici.
• bug (à vérifier) : si site est vide, archive-url et lien brisé remplis -> pas d'affichage du "via Internet Archive". (il faut afficher, même si site vide)
• pour identification de l'archiveur, manque peut-être l'identification de l'url http(S)://wikiwix.com/cache/?url=... (différente de l'url archive.wikikix.com). Ca touche 16k inclusions.
• Cette évolution peut être considérée comme une correction de bug. La modification corrigera immédiatement l'affichage de ~4500 {lien web} qui ont déjà une archive et un paramètre lien brisé.
• CRITIQUE : effet de bord possible : les inclusions {lien web} avec lien brisé et un url-archive sur archive.is ou archive.today (sites blacklistés sur frwiki) deviennent des liens actifs. Ça rendrait compliqué aux contributeurs d'éditer ensuite les articles. Voir Aide:Archive.today (j'ai pas suivi l'évolution). Solution : On modifie le modèle (la priorité) et on voit plus tard pour ce pépin (avec requête WP:RBOT).

Pour les demandes de @Lupin~fr (soucis de monoculture d'archive) :

• Je suis contre la possibilité d'afficher 2 archives en même temps. D'abord ça encombre et complexifie énormément la proposition de "simple" fix/évolution du modèle : ça va ralentir (ou bloquer) sa mise en place, faute de consensus facile. Créer plutôt un débat distinct ultérieur.
• Ensuite, y'a déjà personne pour ajouter une seule archive sur liens vivants ou morts (1,9 millions liens morts à détecter/archiver, seulement 5% réalisé depuis 25 ans…), donc c'est du fantasme de croire qu'un double archivage sera mis en place par des humains (ou même des bots*). Pragmatisme et principe YAGNI : on n'ajoute pas de la complexité inutile pour un futur hypothétique. Si un bot veut demain ajouter une double archive, il en fera la demande.

Irønie 24 août 2026 à 10:29 (CEST)

Bonjour @Irønie, Merci pour tes retours détaillés et constructifs. Je vais répondre aux éléments que tu as soulevés.

Wikification des archiveurs (Internet Archive et Wikiwix) : je suis totalement d’accord. J’ai déjà intégré cette correction dans le bac à sable.

Les idées (modale) : cela reste une proposition de @Lupin~fr, et je suis d’avis que nous pouvons en discuter dans une nouvelle discussion pour ca.

bug (à vérifier : c’est une bonne remarque de ta part. Je viens d'effectuer des tests pour ces situations :

• Vérification bug si site est vide et que archive-url et lien brisé remplis.

- Sabrsl, « Test archive et lien brisé remplis mais Site vide » [archive du 1^er janvier 2020], sur original.com via Internet Archive, 5 janvier 2015 (consulté le 25 juillet 2026)

Aucun bug détecté, car le modèle récupère en priorité l’info depuis les domaines des URLs d’archives renseignées (

web.archive.org

et

archive.wikiwix.com/cache

). Donc, même si le paramètre "Site" est vide, le modèle gère parfaitement le service d’archivage. (Les noms des services d'archivages).

Je me permets de rajouter un autre test de bug potentiel :

• Vérification bug si url principal est vide et que archive-url et lien brisé remplis

- Sabrsl, « Test archive quand Adresse web (URL) est vide » [archive du 1^er janvier 2020], sur original via Internet Archive, 5 janvier 2015 (consulté le 25 juillet 2026)

Le modèle gère bien cette absence d’URL principal, car il active les champs archive-url et lien brisé. C’est un comportement normal, puisque dans ce cas, l’URL principale ne sert pas à grand-chose). Aucun bug détecté.

pour identification de l'archiveur : comme je l’ai dit plus haut, le modèle récupère le service Internet Archive et Wikiwix directement depuis les domaines d'archives. À ma connaissance, le domaine https://archive.wikikix.com/ redirige vers https://archive.wikiwix.com/cache/, et le système se concentre uniquement sur le bon domaine (https://archive.wikiwix.com/cache/). Donc pas de problème de ce côté-là. (Voir les tests).

 Réticence Attendre Effet de bord possible : je ne maîtrise pas trop ce volet concernant archive.is ou archive.today, je vais étudier ça en priorité. Mais d’après ce que je sais, le patch ne modifie en rien le comportement actuel du modèle de lien web, sauf dans le cas précis où une URL d'archive doit devenir l'URLs principale.

Encore merci pour ton aide précieuse ! — Sabrsl --❯ ♥ ^[discuter] 24 août 2026 à 12:36 (CEST)

@Sabrsl @Jules*

J'ai commencé à étudier/mesurer les effets de bord par rapport aux liens archive.is. Compliqué de faire des conclusions faciles. Mon impression actuelle c'est que les bénéfices de ton patch (4500 liens morts sauvés par affichage de l'archive) sont supérieurs aux pépins de liens archive.is (1500?? liens web avec url = archive.is ?). Je verrai plus tard. Irønie 25 août 2026 à 12:09 (CEST)

@Sabrsl Stresse pas. Au pire, si y'a des pépins avec archive.is, on dira que c'est la faute de @Jules* car c'est lui qui avait blacklisté ce site. Irønie 25 août 2026 à 22:29 (CEST)

@Irønie, j’étais entre les murs, moi. Donc si on peut pointer du doigt Jules, autant en profiter. On dira que c’est sa faute alors 😆 — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 08:20 (CEST)

Ouf, j'échapperai à l'échafaud. — Jules* ^💬 26 août 2026 à 12:05 (CEST)

Bonjour @Irønie, j'ai fait quelques vérifications. Si l'URL principale stockée dans url n'est pas modifiée par le patch, celui-ci ne devrait donc pas modifier les liens vers archive.is lorsqu'archive.is est utilisé directement comme url.

En revanche, si une URL archive.is est déjà présente dans archive-url, elle sera effectivement le lien principal du titre lorsque lien brisé + archive-url sont présents. Mais dans ce cas, le patch ne modifie ni ne crée cette URL : il change uniquement le rendu pour utiliser comme lien principal une URL d'archive qui était déjà renseignée. Ce qui veut dire que ca serait un comportement natif du modèle. Sinon, On pourrait aussi lister cette catégorie qui comporte archive.is

comme lien archive-url

afin de les suivre et d'appliquer les corrections progressives s'il le faut à travers ton Bot ou le mien qui le font bien jusqu'ici. Et dans ce cas la seule correction serait juste de modifier archive-url avec la bonne archive fraiche et valide. Qu'en penses-tu ? — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 08:49 (CEST)

@Sabrl : [Conflit édition héhé]

Mini-audit "Est-ce que le patch aurait des effets de bord vis à vis des sites archive.is qui sont blacklistés ?" (Voir Aide:Archive.today).

• Le patch activera des liens vers ce archive.is/etc. Peut-être 352 articles, qui ont actuellement archive-url=archive.today et brisé le. D'un autre côté, le patch activera >4000 liens corrects pour d'autres articles. Avantage/inconvénient. La migration/suppression de toutes les URL archive.today n'a pas été faite ou n'est pas possible (il en reste 10'000), mais elle ne devrait pas être bloquante pour l'évolution de l'affichage de milliers/millions d'autres liens. => Le patch proposé ne gêne pas la maintenance archive.today, et ses effets sont globalement positif.
• Malgré le système de blacklist, la présence d'une URL archive.is dans le paramètre "url" ou "archive-url" de {lien web}, et même l'affichage du lien, n'empêche pas les contributeurs de modifier l'article. Ou même de modifier les données du modèle. J'ai testé ici. => Donc le patch n'aura aucun effet sur les éditions humaines.
• Les bots peuvent ajouter/retirer/modifier des urls archive.is (testé ici). => Donc le patch n'aura aucun effet sur les bots.

Au final je ne vois pas de problème de ce côté (effet de bord) pour le patch {lien brisé}. — Irønie 26 août 2026 à 09:09 (CEST)

@Sabrsl Oui ! bonne idée une catégorie de maintenance pour lister les archive.is dans le modèle. :)

Sinon on a les mêmes conclusions, je crois. — Irønie 26 août 2026 à 09:15 (CEST)

Oui, là, nous sommes sur le même sillage. — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 11:56 (CEST)

Je viens de voir tes tests @Irønie, ca rassurent vraiment. Je vois finalement, qu'il n y a pas d'impact (effet de bord) après patch. Top, mais je pense que ces références mériteront éventuellement une mise à jour de leurs archive-url et lien brisé comme sur ton premier test. — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 11:51 (CEST)

@Sabrsl : J'ai un script de nettoyage (partiel) de archive.today : test. Mais aujourd'hui, si je mets url +archive-url +brisé ça ne cache pas encore le lien mort ! ;) Irønie 26 août 2026 à 12:58 (CEST)

Oui, j’ai vu, c’est parce que le patch n’est pas encore actif. Comme on ne sait pas ce qui va se passer ensuite, on peut attendre de voir i le patch passera en prod ou non. S'il passe, on pourrait s’attaquer aux 1500 liens « archive.is » pour les rendre cohérents.... — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 14:06 (CEST)

Essaye stp de passer par le Bac à sable pour voir. — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 15:16 (CEST)

@Sabrsl Hein bac à sable ? Quoi ça ? Je comprends pas. Oui, je sais que le patch n'est fonctionnel qu'avec {{Modèle:Lien web/Bac à sable}}. Irønie 26 août 2026 à 18:37 (CEST)

Pour encourager la mise en prod du patch, CodexBot propose de convertir quelques centaines ou milliers de liens morts en {lien web|... |lien brise=26 août 2026}. Pour montrer que le patch serait utile ! Irønie 26 août 2026 à 18:39 (CEST)

@Irønie, ce que je te propose, car ce n'est pas une régression, serait de corriger ....archive.today avec ton script en traitant les cas url + archive-url + brisé le.

De cette façon, une fois le patch mis en prod, ces références seront déjà correctement préparées et le rendu du patch pourra s'appliquer automatiquement.

Et dans le pire, si le patch ne rentre pas en prod, ces archive.today auront au moins archive-url + brisé le renseigné. Ce qui est déja pas mal.

Ça me semble être une manière propre de gérer la transition. Qu'en penses-tu ? — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 19:15 (CEST)

J'ai oublié, il faut une validation flag Bot. Fais la proposition. Je suis Pour ....@Irønie — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 19:20 (CEST)

J'ai fait une demande de modification : Wikipédia:Demande d'intervention sur une page protégée#Modèle:Lien web (d · h · j · ↵) — Irønie 28 août 2026 à 15:51 (CEST)

J'ai vu. Juste une petite précision : si l'on décide de déployer le correctif en production, il serait préférable, sans être obligatoire, de modifier les lignes suivantes.

Module Biblio, Lien web, Bac à sable

Ligne 369 :

args = frame:getParent().args or frame.args

Ligne 379 :

args = frame:getParent().args or frame.args

Ces deux appels devraient être remplacés par :

Ligne 369 :

args = frame.args

Ligne 379 :

args = frame.args

Je l'ai fait pour les tests. Cela ne casse rien, mais il est plus propre d'utiliser les appels natifs du modèle. On peut donc supprimer frame:getParent().args et conserver simplement args = frame.args. Merci @Irønie c'est top. — Sabrsl --❯ ♥ ^[discuter] 28 août 2026 à 16:47 (CEST)

Idée de nouveau modèle pour lien mort (déplacé)

(suite de Discussion modèle:Lien web#Proposition de patch : comportement des liens brisés avec archive )

Mes excuses car ma proposition n'était pas claire. Je reformule donc : je ne proposais pas de forcer à entrer ou rechercher les dernières archives dispo sur au moins 2 ou 3 archiveurs, mais juste d'afficher les archives de 2 ou 3 archiveurs en y mettant par défaut le lien vers toute archive de ces archiveurs. Exemple avec https://www.radiofrance.fr :

• si aucune date n'est fournie dans la propriété « brisé le », ça affichera par défaut https://web.archive.org/web/*/https://www.radiofrance.fr et https://archive.wikiwix.com/cache/index2.php?url=https%3A%2F%2Fwww.radiofrance.fr%2F
• si « brisé le=01/01/2024 », ça affichera https://web.archive.org/web/20240101000000/https://www.radiofrance.fr/ et https://archive.wikiwix.com/cache/index2.php?url=https%3A%2F%2Fwww.radiofrance.fr%2F (même lien).

Je ne connais pas assez wikiwix pour savoir si plusieurs archives coexistent et donc si il y a besoin de choisir la plus proche mais postérieure à celle de la date « brisé le ». Est-ce plus clair ? :) - Lupin (discuter) 24 août 2026 à 21:29 (CEST)

@Lupin~fr

Non à ton idée de modèle. Pour deux raisons :

Techniquement, ces liens par défaut renverraient trop souvent le lecteur dans le vide — sans qu'il puisse le savoir avant de cliquer. Une expérience utilisateur fortement dégradée.

Disons que ~90% de ces liens "archives" mènent à une archive InternetArchive (10% 404) ; il faut ensuite que le lecteur attende 30-60 secondes (chargement Javascript) pour obtenir un résultat, avec des chances (30%?) de tomber sur une capture d'écran "404" ou un soft-404 ("nom de domaine à vendre", casino, porno…). Je n'explique pas, mais préciser une date d'archive n'assure pas d'éviter ces problèmes (Wayback).

Idem avec Wikiwix, avec des 40 secondes d'attente pour tomber sur des pages "404" (>30% erreur?).

Se rappeler aussi que seulement 0,3% des lecteurs Wikipédia cliquent sur une ref (un lien externe). Donc le rapport entre la quantité de "liens sales" ajoutés et l'usage utile pour quelques lecteurs est très défavorable.

Un lien qui mène à du vide ou une page pourrie est pire que pas de lien : il coûte un clic,

il donne l'illusion au lecteur qu'une solution est offerte, et il dégrade la confiance dans le modèle lui-même.

2. Sur le fond, ajouter un outil supplémentaire de maintenance humaine ne sert à rien.. Voir ma démonstration plus bas. Cette idée de modèle automatique ajoutera de la complexité aux modèles actuels, au process de maintenance mais ça n'apporte aucun bénéfice. Personne ne vérifiera les liens automatiques IA/Wikiwix (même quand ils sont erronés) et ça n'incitera personne à mettra à jour les liens morts.

Irønie 25 août 2026 à 09:36 (CEST)

Je pense que @Irønie a raison sur toute la ligne. — Sabrsl --❯ ♥ ^[discuter] 25 août 2026 à 09:48 (CEST)

Bonjour @Irønie,

merci pour ces réflexions.

1. Sur l'argument technique, une page non archivée renverrait effectivement à une page inutile (bien que pas vide à strictement parler).

Risque de page vide:

De ce que je comprend, tu as rencontré des archives wikiwix et Internet archive pointant archivant une erreur 404 ou une page de pub. Je n'ai pas eu cette expérience, mais je te crois. :) J'avouerais moi aussi ne pas m'expliquer l'archivage d'erreur 404 par l'un ou l'autre (aurais-tu des exemples de chacun pour voir à quoi ça ressemble ?). Pour la page de pub, ça m'apparaît plus compréhensible si un annonceur a racheté un nom de domaine et y a affiché une pub. Si une redirection a lieu, je crois que Internet archive le signale, et je ne sais pas pour Wikiwix.

Sur le risque d'absence d'archive :

• Wikiwix : un bot archive automatiquement et régulièrement les liens de WPfr
• Internet archive : le bot ne tourne pas sur WPfr( indique « Bot is approved but disabled indefinitely pending software improvements on French Wikipedia (fr), MediaWiki.org, Norwegian Nynorsk Wikipedia (nn), Polish Wikipedia (pl), and Portuguese Wikipedia (pt). »

Je comprend donc qu'on n'a pas de garantie concernant l'existence d'archives Internet archive, et que le nombre de liens archivés dans wikiwix devrait être proche de 100%.

Toutefois, je ne sais pas :

• s'il est possible d'accéder à plusieurs archives d'un même lien avec wikiwix, comme on peut le faire avec Internet archive
• quel est le délai entre la pose d'un lien et son archivage pour wikiwix

Tu estimes que 30 % des liens mènerait à une archive de page non pertinente (404 ou publicité) pour Internet archive comme pour wikiwix.

Peux-tu préciser sur quoi tu bases cette estimation ?

Délai de chargement :

• lorsqu'une page n'est pas archivée, je constate un délai de quelques secondes pour afficher le résultat (4 secondes pour internet archive, exemple: http://web.archive.org/web/20260000000000*/https://www.tarksjnksfd.com, et 5 secondes pour wikiwix , exemple : https://archive.wikiwix.com/cache/index2.php?url=https://www.tarksjnksfd.com).
• lorsqu'une page affiche une archive, je constate le même délai d'affichage de la page de quelques secondes, puis 15 secondes pour charger l'archive avec Internet archive (https://web.archive.org/web/*/https://www.radiofrance.fr), et 7 secondes pour Wikiwix (https://archive.wikiwix.com/cache/index2.php?url=https%3A%2F%2Fwww.radiofrance.fr%2F).

Je comprend donc que ce délai peut être beaucoup plus important dans certains cas, mais que le cas général est bien moins long.

2. ton 2d argument évoque une maintenance humaine, je comprend que tu parles de remplacer manuellement les liens génériques dont je parlais par le bon lien de l'archive qui existe et est pertinente. C'est tout à fait vrai, et je n'ai pas de solution pour cela.

Mon objectif est plutôt de faire face à un problème majeur qui nous pend au nez, celui d'Intenet archive ou wikiwix qui dysfonctionne ou est fermé.

Pour Internet archive, la dépendance totale du site, y compris des miroirs que la fondation a le mérite de mettre en place à l'étranger rend l'existence de ces miroirs inopérants puisqu'ils seraient coupés en cas de coupure légale du site principal.

En pratique, mon idée est de présenter dans le cas où l'archive enregistrée n'est pas trouvée, une alternative, comme actuellement le fait {{lien brisé}}.

On n'empire donc pas les choses par rapport à aujourd'hui, et le patch proposé par @Sabrsl améliore les choses en ne redirigeant plus vers le lien mort.

Dans l'idéal, on pourrait intégrer un test d'une archive Internet archive et Wikiwix pour vérifier que c'est accessible.

J'y vois quelques difficultés, qui n'impose pas de jeter le bébé avec l'eau du bain :

1. le test à l'affichage nécessite du js, ce qui alourdirait l'affichage des articles avec un grand nombre de liens

2. le test pas des bots alourdirait leur tâche, je ne sais s'ils arrivent à suivre actuellement

3. les retours que tu fais sur les archives d'erreurs 404 laissent entendre qu'il faudrait un moyen fourni par les archiveurs concernés de tester si une archive est une erreur 404 ou pas, je ne sais si c'est le cas pour Internet archive et wikiwix.

4. la solution d'avoir un bot en réserve qui commenterait les liens d'un archiveur si celui-ci devient indispo serait sans doute à faire le jour éventuel où ça arrive, ce que je n'espère pas.

Tu sembles avoir bien réfléchi à cette question et je suis intéressé par tes réflexions, je suppose que ce sujet t'a traversé l'esprit.

L'évolution de 2e niveau, que je proposais en plus au delà de l'affichage des liens wikiwix et archive.org, nécessiterait néanmoins de pouvoir tester une archive et vérifier si une archive est valide ou pas, au moins une première fois (au premier clic ?).

Je notifie  Pmartin : qui aura peut-être des éléments pour wikiwix.

Pour Internet archive, le bot ne tournant pas sur WPfr, je ne vois pas vers qui nous tourner. - Lupin (discuter) 25 août 2026 à 15:05 (CEST)

Ton idée, c'est juste {{lien brisé}} (que @Pmartin adore…).

Mais le rendu visuel de {lien brisé} est dégueulasse, un casse-tête pour le lecteur. Une honte d'expérience web pour le lecteur. Aussi la raison pourquoi InternetArchiveBot a quitté frwiki.

D'après les retours du Bistro, les foules 2026 du même avis (moche).

Donc en 2026, on s'en fiche de {lien brisé}. Irønie 25 août 2026 à 22:18 (CEST)

Je précise d'abord que je ne connais pas tes relations passées avec Pmartin mais j'apprécierais de ne pas me voir reproché un ressentiment quelconque s'il existait. :)

Tu sembles avoir une idée de la raison pour laquelle InternetArchiveBot a quitté WPfr, que je ne connais pas, mais ça m'aiderait à comprendre les choix faits par le passé (et peut-être d'autres). Tu aurais un LI pour qu'on puisse comprendre ?

Je comprend que l'ergonomie de {{Lien brisé}} ne soit pas bonne, et de ce point de vue, ne plus lier le titre de la page vers l'url morte est une excellente chose, je suis d'accord avec toi.

Je précise aussi que je ne tiens pas particulièrement à faire survivre ce modèle.

Il me semblerait par contre dommage qu'on ne tienne pas compte d'autres enjeux identifiés, comme la résilience ou le monopole, et le risque de n'avoir qu'un seul archiveur, qu'il s'agisse d'InternatArchive ou de Wikiwix.

Concernant mes interrogations, selon toi, l'enjeu du risque de tomber sur un lien mort est-il toujours d'actualité ?

Et pour le délai de chargement ?

Merci pour ton retour et désolé si mon message précédent t'a heurté, ce n'était pas le but, sois en sûr. :) - Lupin (discuter) 25 août 2026 à 23:02 (CEST)

@Lupin~fr

Au cas où "Internet Archive" (ou Wikiwix) disparaissait, il suffirait de bidouiller le modèle avec une regex qui détecte les url wayback pour au choix : désactiver les liens wayback cassés, transformer en {lien brisé}, créer un lien automatique (vers wikiwix) ou tout autre souhait. Ça prendrait 1/2 journée de discussion et code.

Coût/bénéfice. Un risque de quelques liens cassés pendant 1 journée (avant réparation), ne vaut pas la solution de dégrader l'expérience utilisateur pendant 10-20 ans. Pas de voiture à 8 roues au motif d'un risque de crevaison. — Irønie 26 août 2026 à 09:26 (CEST)

Dac, je comprend ce point de vue. - Lupin (discuter) 26 août 2026 à 09:29 (CEST)

je comprend que le problème du délai de chargement et de risques de pages inutilisables n'en est finalement pas un. - Lupin (discuter) 26 août 2026 à 09:30 (CEST)

Si. Mais je n'argumente pas avec ton IA, et pour mes audits tech propres je facture 5000€. En gratuit, je fournis juste des conseils et tendances. Irønie 26 août 2026 à 09:38 (CEST)

Mon IA ? Est-ce que tu penses que j'utilise une intelligence artificielle pour écrire mes messages ? ou tu parles d'internet archive, qui n'est en aucun cas le mien. :) - Lupin (discuter) 26 août 2026 à 09:49 (CEST)

Bref, comme on est dans un projet collaboratif, je cherchais à comprendre sur quoi se basait ton point de vue personnel exprimé plus haut, je ne comptais pas te faire bosser gratis - Lupin (discuter) 26 août 2026 à 16:46 (CEST)

En cherchant d'où venait le souci soulevé par @Irønie entre Internet archive et wikiwix, j'ai trouvé https://web.archive.org/web/20250613234343/https://blog.wikiwix.com/2016/07/30/un-delit-de-democratie-sur-wikipedia/

En gros, ça indique que Internet archive (à l'époque) ne respectait pas le noarchive et les droits d'auteurs.

Je ne sais pas si c'est avéré ni si c'est toujours le cas. - Lupin (discuter) 26 août 2026 à 09:53 (CEST)

La vraie question, c’est : est-ce qu’ils le font toujours ? Perso, je pense qu’ils trouveront toujours un moyen. Ces balises noarchive, ça représente un gros volume d’archivage, donc je ne pense pas qu’ils sacrifieront leur projet. Ils préféreront prendre le risque et assumer les poursuites, comme le font certaines grosses boîtes… que je ne citerai pas ici.

@Lupin~fr, merci pour ce lien, qui rappelle effectivement un épisode important. — Sabrsl --❯ ♥ ^[discuter] 26 août 2026 à 12:47 (CEST)

Oui @Lupin~fr, c'est très clair. — Sabrsl --❯ ♥ ^[discuter] 25 août 2026 à 09:37 (CEST)

@Lupin~fr, je suis membre de la Fédération Anarchiste donc je n'aime ni les monopoles ni les dépenses énergétiques inutiles et évidemment que ce j'ai toujours proposé ca été de lutter contre les deux  :

La solution retenue fait changer le contenu des articles de wikipedia, l'article sur mon blog a poussé à ce que les différentes communautés soit consultées avant le déploiement.

Je n'ai aucun grief ni contre Internet Archive ni contre les autres archiveurs, mais la méthode utiliser exclusivement IA pour ce passage en force me faisait bondir. Il y avait plusieurs points :

• la base de données d'IAbot ne permettait que de stocker une et unique url d'archiveur pour chaque langue,
• un archiveur je ne me souviens plus lequel avait été écarté parce qu'il ne respectait pas la balise noarchive, et wikiwix qui avait été écarté parce qu'il respectait la balise "noarchive",
• côté énergétique à surveiller l'ensemble des pages qui disparaissent et qui réapparaissent ça reste pour moi une aberration dans le cadre du projet wikipedia,
• la quantité de serveurs , Internet Archive a 750 serveurs https://next.ink/1336/interview-internet-archive-wayback-machine-bots-crawls-et-humains/ coté wikiwix nous avons actuellement un seul serveur qui contient en plus des liens sources de wikipedia, les pages perso d'orange , et les skyblogs,...
• https://en.wikipedia.org/w/index.php?title=List_of_web_archiving_initiatives&oldid=1212709393 j'ajoute un point qui concerne le fait que wikiwix est opensource donc prône un modèle résilient mais qui a disparu de la présentation,

Bref tout çà pour dire, que ce soit Wikiwix ou la Wayback Machine, on adapte nos modèles

https://meta.wikimedia.org/wiki/Wikim%C3%A9dia_France/Subventions/Demande/2026-1/ArchiNum%C3%A9

https://actualitte.com/article/131163/acteurs-numeriques/internet-archive-cree-une-fondation-suisse-pour-sauver-des-archives

Pmartin (discuter) 26 août 2026 à 14:38 (CEST)

Merci pour ce retour @Pmartin :)

Je pense aussi que n'archiver que sur Internet archive créerait un monopole de fait qui serait une erreur, et je crois que ce n'est pas la solution envisagée par @Sabrsl.

Si le remplacement de liens d'archivages problématiques se faisait par une seule solution (IA ou wikiwix), je suppose que ça demanderait de toute façon une consultation de la communauté.

Je ne crois pas qu'il y ait de remise en question du principe de wikiwix, mais j'ai vu et me suis posé plusieurs questions pour voir l'impact de son usage en pratique, en voici quelques unes si tu peux nous éclairer :

• Concernant les archivages de pages web, peux-tu préciser si plusieurs archives sont dispo pour des dates différentes lorsqu'elles diffèrent ? Je ne dis pas que c'est techniquement simple hein (ne serait-ce que parce que l'affichage de dates suffit à rendre une page différente à un diff...)
• as-tu une idée de pourquoi des pages archiveraient une erreur 404 sur wikiwix (ou IA) ?
• Y a-t-il une doc de fonctionnement de wikiwix quelque part ? Une part de ces questions a peut-être déjà une réponse

Merci encore pour ces infos en tout cas :) - Lupin (discuter) 26 août 2026 à 15:24 (CEST)

Je ne doute pas des intentions de @Sabrsl juste pour signaler que ce Gadget permet d'ajouter des copains de l'archivage sur tout les liens externes MediaWiki:Gadget-ArchiveLinks.js après à eux de se débrouiller pour desservir l

• Concernant les archivages de pages web, peux-tu préciser si plusieurs archives sont dispo pour des dates différentes lorsqu'elles diffèrent ? Je ne dis pas que c'est techniquement simple hein (ne serait-ce que parce que l'affichage de dates suffit à rendre une page différente à un diff...) oui, d'ailleurs Utilisateur:CodexBot utilise cette fonctionnalité
• as-tu une idée de pourquoi des pages archiveraient une erreur 404 sur wikiwix (ou IA) ? Sur wikiwix c'est qu'après avoir exploré toutes les pistes, on considère que la page est définitivement perdu
• Y a-t-il une doc de fonctionnement de wikiwix quelque part ? oui mais elle est pour l'instant dans mon garage avec la fermeture de ma société, j'ai été obligé de rapatrier les serveurs mais un membre de l'association travaille actuellement pour le site de l'association. @Irønie on a petit budget pour maintenir wikiwix et on cherche un peu de renfort technique ... Pmartin (discuter) 29 août 2026 à 18:04 (CEST)

Bonsoir, et merci pour ces infos @Pmartin.

D'après ta réponse à ma 1ère question, il est possible d'accéder à plusieurs archives et CodexBot sait comment faire. Peux-tu en dire plus ?

En particulier, dans cette modif, CodexBot remplace des liens wikiwix existant comme par d'autres vers internet archive, donc soit CodexBot ne sait pas toujours le faire, soit il y a une difficulté qui mérite d'être levée.

@Irønie saurais-tu préciser dans quel cas le lien mort est-il remplacé par Internet archive et dans quel cas est-il remplacé par wikiwix ? - Lupin (discuter) 30 août 2026 à 22:35 (CEST)

Comme le point soulevé par cette modif ne concerne pas vraiment le sujet de cette section, je poursuis sur une section plus bas ici : Discussion_modèle:Lien_web#Remplacement_par_défaut_de_liens_avec_archive_wikiwix_par_Internet_archive - Lupin (discuter) 31 août 2026 à 13:58 (CEST)

La maintenance humaine des liens externes morts ne fonctionne pas

Je déplace ici, une remarque (hors-sujet) que j'ai fait plus haut, qui peut éclairer quand aux évolutions possibles du modèle.

Outiller la maintenance humaine des liens morts, c'est un échec, ça ne marche pas .

Selon les mesures de mon Claude/Opus :

• {{lien brisé}} : 49 455 inclusions, dont ~67 % posées par des bots (CodexBot, InternetArchiveBot…).
• {{lien archive}} : 38 993 inclusions, dont ~53 % par des bots (Etambot, InternetArchiveBot…).
• Total : sur ~88 000 inclusions, les humains en ont posé ~34 600 sur 25 ans, arrondissons à ~1500 par an (~4/jour) depuis 20 ans.

Cette maintenance humaine ~1500 liens morts/an est stable (idem 2024, 2025…). Ce n'est pas rien, et je ne prétends pas que personne ne fait rien — mais c'est un plafond, atteint avec les modèles actuels. Et quinze ans de perfectionnement des modèles ne l'ont pas déplacé. La maintenance humaine des liens, c'était un rêve des années 2010, maintenant on sait que ça n'a pas marché. Seulement ~1-2% du boulot nécessaire été fait par les humains, il reste 1,5 à 1,9 millions de liens mort à signaler ou archiver. Et la tendance récente de fuite des contributeurs n'aidera pas.

Améliorer le ramassage avec les doigts des grains éparpillés ne sert à rien. Le champ est trop vaste : il faut des machines

À titre de comparaison : à la cadence CodexBot actuelle (700 liens morts signalés/corrigés par jour), il faut ~2 jours pour égaler la production humaine annuelle, et 1 mois 1/2 pour dépasser tout ce que les humains ont posé depuis 25 ans. Mais il lui faudra certainement plus de 2 ans pour passer partout (détection lien mort) — et >10-15 ans pour ajouter des archives sur les liens vivants.

Je ne dis pas ça pour faire le malin avec mon bot. Mais pour démontrer que la gestion des liens morts est une tâche ingrate, massive et répétitive, que personne n'a envie de faire à la main. Quinze ans de résultats le confirment.

Les liens externes, c'est une maintenance pour des bots. Les humains sont utiles ailleurs.
— Irønie 25 août 2026 à 09:36 (CEST)

Merci pour cette explication, je ne connais pas vraiment CodexBot, j'en profite pour te remercier pour le travail fourni, extrêmement nécessaire bien que peu visible !

Concernant les estimations avec Claude/Opus, je ne sais pas quel niveau de confiance leur accorder étant donné que j'ai lu que les IAg avaient des difficultés à compter.

As-tu croisé ces estimations avec une estimation du nombre d'inclusions de {{Lien brisé}} et {{Lien archive}} par curiosité ? J'avouerais ne pas savoir si c'est faisable simplement (et suis intéressé si quelqu'un a la réponse:)).

Bonne journée - Lupin (discuter) 25 août 2026 à 15:08 (CEST)

C'est moi qui l'écrit, donc c'est ok. Irønie 25 août 2026 à 22:03 (CEST)

Mini-sondage : quand un lien est mort et qu'une archive est déjà renseignée, que doit afficher "Lien web" ?

Bonjour,

Le patch correctif proposé par Sabrsl ci-dessus (section Proposition de patch…) a reçu plusieurs avis favorables (ici) et aucune opposition formelle, mais il touche un modèle protégé et très utilisé. Plutôt que de le faire passer sur un consensus implicite, voici un mini-sondage simple : pour ou contre, ouvert 15 jours.

Le problème, en une phrase

Quand une référence {lien web} contient à la fois un lien mort et l'adresse d'une archive web (renseignée par un contributeur ou un bot), c'est quand même le lien mort qui est cliquable sur le titre. Le lecteur clique, tombe sur une erreur 404 (ou sur une page de casino qui a racheté le domaine), et doit deviner qu'un second lien, plus discret et plus loin dans la référence, mène à la copie archivée.
Autrement dit, le lien affiché est celui qui ne fonctionne pas, et celui qui fonctionne est caché : c'est l'inverse de ce qu'attend un lecteur.

Ce qui est proposé

Intervertir les deux liens : le titre pointe vers l'archive déjà renseignée dans la référence, et le site d'origine reste affiché pour la traçabilité.

Une seule condition, les deux paramètres ensemble : archive-url + brisé le. Dans tous les autres cas, l'affichage ne bouge pas d'un pixel.

Avant / après

Exemple avec le wikicode suivant : {{Lien web |langue=fr |titre=L'invité du jour avec Mohamed… |url=https://www.africa24tv.com/fr/linvite-du-jour-avec-mohamed-beavogui-directeur-general-de-larc |site=africa24tv.com |date=5 janvier 2015 |consulté le=25 juillet 2026 |archive-url=https://web.archive.org/web/20190822211522/https://www.africa24tv.com/fr/linvite-du-jour-avec-mohamed-beavogui-directeur-general-de-larc |archive-date=22 août 2019 |brisé le=2026-08-31}}

Aujourd'hui — le titre envoie vers le lien mort 💀 :

• « L'invité du jour avec Mohamed… » [archive du 22 août 2019], sur africa24tv.com, 5 janvier 2015 (consulté le 25 juillet 2026)

(note: Le lien du titre était en bleu au lancement du sondage…)

Avec le correctif — le titre envoie vers l'archive :

• « L'invité du jour avec Mohamed… » [archive du 22 août 2019], sur africa24tv.com via Internet Archive, 5 janvier 2015 (consulté le 25 juillet 2026)

Idem avec une archive Wikiwix :

• « L'invité du jour avec Mohamed… » [archive du 22 août 2019], sur africa24tv.com via Wikiwix, 5 janvier 2015 (consulté le 25 juillet 2026)

Autres cas de figure testés (URL vide, paramètre site vide, lien brisé sans archive, archive sans lien brisé) : page de tests.

Ce que ça ne change PAS

C'est le point important, et c'est pour ça que la proposition est volontairement minuscule :

• Rien à apprendre : aucun nouveau paramètre, aucune syntaxe à retenir, rien à changer dans les articles. C'est de l'affichage.
• Aucun archiveur n'est privilégié : le modèle affiche l'archive que le contributeur (ou un bot) a lui-même renseignée, qu'elle soit sur Wikiwix, Internet Archive ou ailleurs. Le patch ne choisit pas d'archiveur, n'en ajoute aucun, n'en remplace aucun. Il nomme même explicitement le service utilisé, avec lien interne (« sur exemple.com via Wikiwix ») — une visibilité que l'affichage actuel ne donne pas.
• Aucune modification d'article : pas de bot lancé derrière, pas d'archive ajoutée ou supprimée automatiquement. Le sondage porte uniquement sur le rendu du modèle.
• Aucun autre modèle touché : {{lien brisé}}, {{lien mort}}, {{article}}, {{ouvrage}} continuent de fonctionner exactement comme aujourd'hui. On peut toujours signaler et archiver les liens morts comme avant.
• Toutes les autres combinaisons de paramètres : rendu identique. archive-url sans brisé le → inchangé. brisé le sans archive → inchangé. site renseigné → c'est votre valeur qui est utilisée.
• Réversible en une minute : c'est une modification de module, annulable d'un revert si un effet indésirable apparaît.

En volume : environ 4 500 liens morts déjà en ligne verraient leur archive devenir cliquable immédiatement. Sur les 1,4 million de transclusions {lien web}, tout le reste est strictement inchangé.

Objections déjà soulevées en discussion

« Et si l'archive est mauvaise, ou renvoie elle-même une 404 ? »

Aujourd'hui, dans ce cas de figure, le lecteur a 100 % de chances de tomber sur un lien mort. Avec le patch, il tombe sur l'archive qui a été renseignée. Aucune situation ne devient pire qu'aujourd'hui, et la correction reste la même qu'aujourd'hui : changer archive-url.

« On perd l'accès à l'URL d'origine ? »

Non : le paramètre url reste (caché) dans le wikicode et le nom du site reste affiché. Seul le lien cliquable du titre change. Si le site redevient accessible, il suffit de retirer brisé le pour revenir au rendu actuel.

« Et les liens archive.today, blacklistés sur fr.wikipédia ? »

Vérifié en conditions réelles  : la présence d'un lien archive.today affiché n'empêche ni les humains ni les bots de modifier l'article.

« Pourquoi ne pas afficher plusieurs archives (résilience, éviter la dépendance à un seul archiveur) ? »

Question légitime, mais c'est un autre sujet, avec ses propres arbitrages (encombrement visuel, comportement des liens génériques). Elle mérite sa propre discussion et ne devrait pas retarder cette correction-ci, qui ne la contredit en rien : rien dans ce patch n'empêche une évolution multi-archives plus tard.

-- Irønie 31 août 2026 à 12:41 (CEST)

Vote

Ouvert du 31 août 2026 au 15 septembre 2026. Merci d'indiquer simplement {{Pour}} ou {{Contre}}, avec un mot d'explication si vous le souhaitez.

Question posée : êtes-vous favorable à ce que, lorsqu'une référence {{lien web}} contient à la fois brisé le et archive-url, le titre pointe vers l'archive plutôt que vers le lien mort ?

Pour

1. Pour et effacer l'URL en 404, ça sert à rien d'arriver sur l'URL morte puisqu'on ne peut rien en tirer. Wikipédiennement. Slzbg (discuter) 31 août 2026 à 12:48 (CEST)
2. Pour Il faut éviter de donner la possibilité de cliquer sur le lien mort car il n'est pas rare de trouver des sites vampirisés, auquel cas cela peut poser des problèmes de sécurité. CaféBuzz (d) 31 août 2026 à 13:08 (CEST)
3. Pour dès lors qu'il n'y a pas de favorisation d'un monopole d'archiveur - Lupin (discuter) 31 août 2026 à 13:12 (CEST)
4. Pour avoir un lien direct vers une archive -- et aussi parce que j'ai récemment dû chercher (sur la Wayback Machine) après la seule réf citée dans plusieurs articles "[année] aux échecs", chess-poster.com, qui renvoie actuellement vers un faux casino indonésien... tout ça pour tomber -dans la WM- sur un site quelconque citant absolument zéro sources... — Le Sharkoïste 🦁 ^{c · d} 31 août 2026 à 13:41 (CEST)
5. Pour fort Je pense que ça ne peut être qu'une bonne chose. Remarque : faudrait ajouter quelque chose dans les suggestions de modifications pour ajouter un ien d'archive ou créer une page d'aide. Cordialement BlackJack5671 (d · c · b) 31 août 2026 à 13:46 (CEST) N'hésitez pas à me notifier !

   Oui. Dès que le patch est passé, je refais les pages d'aide. — Irønie 31 août 2026 à 14:43 (CEST)

6. Pour fort mais il serait superbe d'avoir le lien original dans un coin pour les personnes qui ne contribuent pas (comme le « archivé depuis machin » visible sur certains interwikis). --Wyslijp16 (discuter) 31 août 2026 à 13:54 (CEST)
7. Pour fort, c'est évident. Cdlt, Lyon-St-Clair ^{[Hon hon hon]} 31 août 2026 à 13:56 (CEST)
8. Pour fort, amélioration claire par rapport à l'existant. — Mwarf (d) 31 août 2026 à 17:18 (CEST)
9. Pour, cf. discussions préparatoires. — Jules* ^💬 31 août 2026 à 17:47 (CEST)
10. Pour Il faudra aussi en toucher un petit mot dans la documentation du modèle {{Lien archive}}, pour avertir qu'une solution plus générale existe désormais. --Cosmophilus (discuter) 31 août 2026 à 18:59 (CEST)
11. Pour même réflexion que Slzbg, et je rajoute que pour les liens hors wayback archive--Remy34 (discuter) 31 août 2026 à 19:27 (CEST)
12. Pour Oui, on s'y perd, --Pierrette13 (discuter) 31 août 2026 à 20:10 (CEST)
13. Pour. Merci d’avoir pris le temps d’expliquer cela en détail. --Tom Blaireau 31 août 2026 à 22:03 (CEST)
14. Pour fort Merci beaucoup ! Bien à vous. --Mathsi6542 (discuter) 31 août 2026 à 22:27 (CEST)
15. Pour fort Arandomfolk (discuter)
16. Pour fort — Arokyo ^💬 1 septembre 2026 à 13:11 (CEST)
17. Pour fort — Evynrhud (discuter) 1 septembre 2026 à 18:56 (CEST)

Contre

1. Contre J'aurais émis un vote favorable si le sondage avait été formulé en bonne et due forme, mais par principe je suis fortement opposé à ce genre de « mini-sondage » fait en vase clos (c'est-à-dire sans consulter l'ensemble des wikipédiens mais seulement ceux qui suivent cette conversation), qui s'affranchit des règles ou recos des sondages.
   Déjà qu'un sondage n'est pas censé être prescriptif (et modifier le comportement d'un modèle est éminemment prescriptif selon moi, puisque le contributeur voit son message initial transformé sans son accord ou sa notif, même s'il suit la page, c'est quand même le pompon !) mais là on fait des sondages hors de tout cadrage !
   Est-ce que la prochaine étape est de faire un sondage sur une PdDU bien confidentielle ? -- Hippo ^{discutez sans frapper} 31 août 2026 à 20:43 (CEST)

   J'ai pas le temps. Quand ton plombier bosse gratuit, tu peux pas être exigeant. — Irønie 2 septembre 2026 à 10:13 (CEST)

   Nous sommes (quasiment) tous bénévoles ici. -- Hippo ^{discutez sans frapper} 6 septembre 2026 à 11:59 (CEST)

2. Contre sur le principe, cela pourrait sembler positif, mais un effet de bord décrit plus bas me semble nécessiter une évaluation transparente avant d'appliquer un tel changement. - Lupin (discuter) 2 septembre 2026 à 23:05 (CEST)

Neutre / autre

1.  Réticence Je n'aime pas trop le manque de consistance, sur ces deux aspects :
   • bien entendu la différence de base : le texte principal est parfois avec le lien d'origine, parfois avec un lien d'archive
   • et l'aspect qui me dérange davantage : le texte [archive] est parfois sans lien, parfois avec le lien de l'archive

   Au final, on ne sait pas trop "sur quoi on va tomber", et le plus rapide s'avère être d'aller regarder la barre d'état du navigateur pour savoir si c'est le lien d'origine ou un lien d'archive…

   Pour les gens qui veulent "se laisser porter" et juste avoir "le lien le plus efficace" pour consulter la ressource, le système se tient, mais pour les gens comme moi qui ont un grand besoin de "cerner les situations", je trouve le système assez bancal, incohérent.

   Et aussi, même si un lien est marqué mort, je veux toujours vérifier cela par moi-même. Par convaincu non plus par l'argument de sécurité : l'époque où on chopait une vérole juste en allant sur une page est révolue depuis fort longtemps (et pourtant j'en ai ouvertes, des pages inavouables).

   Je préfère le système actuel, qui aurait simplement eu besoin comme amélioration (ou plutôt, correction évidente) de toujours styliser en rouge les liens indiqués morts (c'est-à-dire les mettre en rouge aussi lorsqu'une archive est fournie). Et à la rigueur, si vraiment on veut empêcher d'aller sur un domaine "charogné / vérolé", enlever le lien et garder juste le texte rouge ; soit toujours, soit au cas par cas avec un paramètre (pour limiter aux cas où il y a vraiment problème).

   od†n ↗^blah 2 septembre 2026 à 12:30 (CEST)

   Ceci étant, "disagree and commit" ; même si je considère que ce changement est un antipattern, c'est négligeable en comparaison des interfaces sur tout l'internet qui sont de plus en plus éclatées au sol (nivellement par le bas, dark patterns). od†n ↗^blah 2 septembre 2026 à 12:44 (CEST)

   Oui, sur la consistance. Ça peut s'améliorer plus tard. Le rendu pour ce cas côté enwiki est bien plus cohérent et consistant. La recherche de perfection, c'est 3 mois de débats, blocages, sondages… Pfff… — Irønie 2 septembre 2026 à 18:14 (CEST)

   Edit : comme envisagé tel que j'ai indiqué ci-dessus, je viens d'effectuer 239181210 (« pour les liens indiqués morts (mode "dead" pour produire {{Lien brisé}}, ou paramètre "brisé le"), toujours les afficher en rouge, c'est-à-dire aussi même si un paramètre "archiveUrl" a été fourni »). Je pense qu'il est vraiment important de savoir d'emblée qu'un lien a été marqué mort, au lieu de le découvrir par soi-même. od†n ↗^blah 3 septembre 2026 à 05:31 (CEST)

   Pas élégant Od1n, de modifier le modèle pendant le sondage… Passage de mon exemple initial du bleu au rouge, pour URL 404. Mais ok, pas d'opposition je suppose.

   Pour ton 2ème changement, lien rouge vers bonne archive (ta préférence, alors que >15 avis pour la proposition bleue…)… Ça sert à quoi un sondage, alors ? Aussi il est clairement indiqué "sur blabla.com via Internet Archive" donc le lecteur n'est pas trahi. Aussi ça ajoute du rouge (appel à maintenance), alors que le "problème" est définitivement réglé, et la source de ref accessible. Le besoin utilisateur pour une ref, c'est l'accès OK (vert/bleu) en lecture du texte/source ; Madame Michou s'en fiche des nuances de tech (DNS/domaine/404).

   Cette proposition patch, visait à faire évoluer le modèle pour permettre un rendu propre des liens corrigés par le bot. Eviter le hack actuel de CodexBot avec un rendu url=http://archive.../ et site=blabla.com via [[Internet Archive]]" faute de modèle adapté.

   Pas besoin de réponse, c'était juste pour exprimer mon mécontentement. — Irønie 3 septembre 2026 à 21:25 (CEST)

   • J'ai effectivement appliqué une modif sur le modèle sans attendre, pour rapprocher l'approche actuelle de son fonctionnement corrigé/correct/idéal ; et j'avais anticipé la disruption que tu as mentionnée, c'est pourquoi j'avais pris soin de signaler ma modification. Je la remontre un coup : 239181210.
     • mais effectivement, du coup un lien mort mais "corrigé" en spécifiant manuellement une archive (donc a priori vérifiée) continue d'être affiché en rouge, sans pouvoir virer cela ;
     • mais avant ma modification, les liens pourtant détectés morts étaient affichés en bleu, ce qui me semble être pire.
   • « il est clairement indiqué "sur blabla.com via Internet Archive" donc le lecteur n'est pas trahi » : le truc, c'est que les internautes (moi y compris) lisent en diagonale, parcourent le texte "visuellement". On clique sur le premier lien qui et qui ressemble à un titre ; c'est tout. On ne s'amuse pas à lire derrière "alors là c'est une archive sur machin truc etc". Ce n'est pas une question de paresse ou de stupidité, mais d'efficacité. C'est un peu comme avec l'expérience du gorille invisible : l'attention est tellement focalisée sur la recherche des informations voulues (lien pour accéder à la ressource, parfois éventuellement d'autres informations comme l'auteur, la date…) que l'on zappe absolument tout le reste. (à propos, là j'ai travaillé sur un projet qui sert à organiser/parcourir des éléments d'information, et justement j'avais mis au départ des modes "images" et "textes" : je me suis rendu compte à quel point la navigation avec des images est infiniment plus efficace qu'avec des textes)
   • Je n'ai pas compris « Pour ton 2ème changement, lien rouge vers bonne archive ». J'essaie de comprendre (sans aucune certitude) : si c'est en rapport avec le fait que ton bot, et peut-être certains utilisateurs, mettent des liens archive dans le paramètre "url", c'est un "détournement de paramètre, faute de mieux actuellement", qui est de toute façon absolument inadéquat, et d'une façon ou d'une autre, il faut une solution pour ne plus faire cela.
   • En revanche, un problème majeur et même bloquant avec mon approche : les liens morts resteraient indéfiniment présents sur la page, et en rouge bien visible. Il n'y aurait pas de moyen de procéder à de la maintenance pour les éliminer.

   od†n ↗^blah 5 septembre 2026 à 05:42 (CEST)

   J'ai passé mon vote en neutre / réticence :

   • Déjà parce que j'avais prévu de le faire, parce que "m'en fous / ça m'est égal / je ne veux pas bloquer / je laisse faire".
   • Parce que la nouvelle approche suggérée se défend quand même, ça dépend "comment on pense" (et vu que ma pensée est extrêmement minoritaire…)
   • Et le deal breaker : parce que même si la nouvelle approche suggérée introduit un certain manque de consistance, c'est une piste qui permet, lorsqu'une archive est manuellement spécifiée, de "traiter" les liens morts et de ne plus les afficher, là où l'approche actuelle les laisse indéfiniment sur la page, et en rouge bien visible.

   od†n ↗^blah 5 septembre 2026 à 06:05 (CEST)

   Je laisse mon vote ici (pour laisser mon "bruit" à part), mais je me range maintenant avec les avis d'approbation : la perte de consistance est préférable au fait d'avoir des liens externes rouges sans possibilité de les virer, et je ne vois pas de manière plus élégante que la proposition émise pour intégrer les liens morts traités.

   Le fait que l'ajout d'une archive dans le modèle fasse disparaître le lien archive Wikiwix du gadget JS est une autre considération, que l'on peut traiter à part.

   od†n ↗^blah 6 septembre 2026 à 10:27 (CEST)

Discussion

Ca serait une belle avancée.— Sabrsl --❯ ♥ ^[discuter] 31 août 2026 à 17:33 (CEST)

Ping JackPotte (JackBot spécialiste des conversions). -- Irønie 31 août 2026 à 17:58 (CEST)

Il y a malheureusement un effet de bord apparu depuis le redémarrage de CodexBot en août. Aucun archiveur n'est privilégié : si un lien a été explicitement précisé, alors il est repris. Même si aucun lien d'archive n'a été explicitement précisé, wikiwix archivait automatiquement le lien, et le lien apparaissait donc « [archive] » derrière le {{Lien web}}. Ce lien disparaît quand CodexBot ajoute une url pointant vers Internet archive, ce qui revient en pratique à faire apparaître un lien Internet archive et retirer un lien wikiwix valide (voir Discussion_modèle:Lien_web#Remplacement_par_défaut_de_liens_avec_archive_wikiwix_par_Internet_archive).

Cet effet de bord devient non négligeable quand CodexBot fait plusieurs centaines de modif de liens par jour, et mérite une évaluation sérieuse avant de pouvoir appliquer une telle modif. - Lupin (discuter) 2 septembre 2026 à 23:02 (CEST)

Remplacement par défaut de liens avec archive wikiwix par Internet archive

Bonjour, pour info, j'ai détaillé le comportement de CodexBot observé plus haut ici : Discussion_utilisateur:CodexBot#Remplacement_de_liens_web_avec_archives_par_Internet_Archive_par_défaut. Comme ça a un impact plus général sur le fonctionnement des liens web, je résume ici :

On dirait que les liens brisés avec champ « brisé le » et les liens web devenus morts sont par défaut remplacés par un lien web vers Internet archive, ce même si ils disposaient avant modif d'une archive wikiwix fonctionnelle, et probablement archivée peut de temps après l'ajout du lien. Les archives wikiwix ne semblent subsister que pour les {{Lien brisé}} ne comportant pas de date dans le champ « brisé le ».

Est-ce le comportement attendu ? - Lupin (discuter) 31 août 2026 à 13:56 (CEST)

C'est faux. Irønie 31 août 2026 à 15:13 (CEST)

Sur la forme, ce genre de décision laconique n'aide pas à avancer. Je trouve ce comportement absolument non collaboratif et de ce fait problématique.

Sur le fond, dans la page de discussion de CodexBot plus haut, @Irønie confirme que CodexBot supprime les liens wikiwix actuellement affichés des {{Lien web}} devenus morts et des {{Lien mort}} avec un « brisé le » renseigné pour les remplacer par des liens internet archive au prétexte qu'aucune décision de la communauté ne définit de priorité entre wikiwix et internet archive.

En pratique, cela revient à supprimer 90% (estimation au doigt mouillé, sans doute ) des liens d'archives wikiwix affichés pointant sur des liens morts (les archives les plus utiles) pour les remplacer par des liens Internet archive, ce qui crée un monopole de fait de cet archiveur, sans compter d'éventuels risques juridiques.

Si on peut comprendre que des difficultés techniques existent, une telle décision qui engage le contenu éditorial mérite une réflexion, au delà d'une ou un développeur. - Lupin (discuter) 2 septembre 2026 à 17:00 (CEST)

Le diff du scandale. Irønie 2 septembre 2026 à 18:07 (CEST)

Voici en résumé ce que je comprend de l'évolution du fonctionnement de {{Lien web}} :

1. historiquement, wikiwix archive les {{lien web}} peu de temps après leur ajout sur un article WPfr

2. {{Lien web}} affiche un lien vers l'archive à l'affichage de l'article

3. dans le cas d'un {{lien web}} mort, qui affiche donc un lien vers l'archive faite après son ajout, CodexBot remplace depuis un temps indéterminé le lien vers l'archive wikiwix affiché par un lien vers une archive Internet archive

Pour {{Lien mort}} :

1. historiquement, wikiwix archive les {{lien web}} peu de temps après leur ajout sur un article WPfr

2. lorsque le lien n'est plus accessible, il est transformé en {{lien mort}} avec un champ « brisé le » quand une date est connue (manuellement ou par bot). Il affiche alors un lien vers Internet archive, wikiwix, Google et « Que faire ? »

3. depuis un temps indéterminé, les {{Lien mort}} avec champ « brisé le » sont modifiés et n'affichent plus que le lien vers Internet archive

Note :

• il semble que certains liens d'archives Internet archive et wikiwix soient morts, ce qui rend les liens parfois inutilisables
• Internet archive peut archiver plusieurs fois une même page à des dates différentes et permet de générer une URL automatiquement pour trouver l'archive la plus proche d'une date donnée pour cette URL
• Wikiwix semble capable d'archiver plusieurs fois une même page à des dates différentes (méthode à clarifier). Reste à clarifier comment il est possible de générer une URL à partir d'une date « brisé le » automatiquement...

Les corrections/précisions cordiales sont les bienvenues, idéalement avec les explications pour que chacun puisse comprendre et appréhender le fonctionnement et les difficultés. :) - Lupin (discuter) 2 septembre 2026 à 18:03 (CEST)

Le mode collaboratif est réservé aux abonnements CodexBot PREMIUM (1900 €/mois).

Vous auriez dû garder InternetArchiveBot, comme 400 autres wikis ; c'était bien, open-source et gratuit. Maintenant, vous êtes coincé avec l'arnaque CodexBot ! — Irønie 2 septembre 2026 à 18:36 (CEST)

— Sabrsl --❯ ♥ ^[discuter] 2 septembre 2026 à 20:18 (CEST)

Est-ce que vous refusez vraiment de répondre au nom de WP:contributions rémunérées ?

J'ai expliqué le problème que je constate par des diff et expliqué la méthode qui m'a permis d'arriver à mes conclusions, chaque personne qui veut vérifier peut constater qu'il n'y a pas arnaque mais un comportement problématique de CodexBot.

Puisqu'on parle de l'expérience utilisateur, on a des liens wikiwix qui s'affichaient jusqu'alors et qui ont disparu pour être remplacés par des liens Internet archive.

Il suffit pour s'en convaincre de consulter le diff que j'ai fourni :

• la version du 20 juillet 2026 affiche pour la réf 9 : « Swikr - Le 21 février 2014 », avec un [archive] pointant vers l'archive wikiwix
• celle du 28 août 2026 affiche pour la même réf « Swikr - Le 21 février 2014 », sur swikr.com via Internet Archive, 21 février 2014 (consulté le 28 août 2026). avec le lien qui pointe vers Internet archive.

Il y a donc bien disparition de liens vers les archives wikiwix.

Quand j'interrogeais sur la PdD de CodexBot pour demander si ce comportement assumé était basé sur une décision de la communauté, vous avez répondu La communauté adore CodexBot. Donc ça va. Comprendre : « Circulez, y a rien à voir ».

C'est là un Argumentum ad populum qui cache le fait que CodexBot semble avoir repris son activité depuis le 4 août après un an de pause, passant d'une dizaine de modif/jour alors à près de 800/jour désormais.

Des effets qui étaient négligeables il y a un an changent désormais d'échelle.

Ça mérite de se poser la question pour faire les choses correctement, sans passer les effets de bord indésirables sous le tapis vu l'ampleur des modif effectuées depuis un mois. - Lupin (discuter) 2 septembre 2026 à 22:37 (CEST)

CodexBot remplace les liens archives Wikiwix par des liens vers Internet Archive ? Je ne pense pas. — Sabrsl --❯ ♥ ^[discuter] 3 septembre 2026 à 00:02 (CEST)

As-tu ouvert les deux liens que j'ai mentionné plus haut @Sabrsl ? J'ai détaillé le problème dans le message auquel tu réponds pour faire gagner du temps à tout le monde - Lupin (discuter) 3 septembre 2026 à 01:26 (CEST)

Les liens wikiwix ne sont pas indiqués explicitement dans le wikicode mais apparaissent clairement dans la page chargée juste après le lien, sous la forme « [archive] » - Lupin (discuter) 3 septembre 2026 à 02:18 (CEST)

« 2. {{Lien web}} affiche un lien vers l'archive à l'affichage de l'article » : une correction, qui clarifie pas mal la situation : ces liens « [archive] » vers Wikiwix ne sont pas produits par le modèle {{Lien web}}, mais par le gadget JavaScript ArchiveLinks.js, qui est activé par défaut chez tous les utilisateurs.

Et ce gadget n'ajoute pas son « [archive] » dans deux cas de figure :

• lorsque le module produit déjà des liens "archives" (mode "dead" pour produire un {{Lien brisé}}, ou paramètre "archiveUrl"), et indique au gadget de ne pas rajouter le sien ;
• lorsque le gadget détecte que l'URL est déjà vers un site d'archive (précisément, c'est cela qui a fait disparaître le lien Wikiwix dans ce que tu as indiqué plus haut).

En substance, le gadget JavaScript considère que si un lien "archive" est déjà présent (le service pouvant être déjà Wikiwix, ou un autre), ce lien d'archive est présumé fonctionnel et il serait redondant d'en ajouter un autre.

Et aussi, si l'URL d'origine n'est plus dans le résultat, le gadget serait, en l'état, un peu coincé pour pouvoir générer son lien.

od†n ↗^blah 3 septembre 2026 à 04:37 (CEST)

Merci @Od1n, pour cet éclaircissement. — Sabrsl --❯ ♥ ^[discuter] 3 septembre 2026 à 05:09 (CEST)

merci pour cette clarification @Od1n :)

Ça confirme qu'on a jusqu'à présent des liens wikiwix vers des archives accessibles, qui disparaissent quand CodexBot rajoute des liens.

La solution simple serait donc pour ne pas changer le contenu accessible de remplacer par l'archive wikiwix, non ? - Lupin (discuter) 3 septembre 2026 à 10:54 (CEST)

Sauf qu'il n'y a aucune garantie que les liens Wikiwix ajoutés par le gadget fonctionnent vraiment. Le gadget les ajoute toujours (sauf lorsque désactivation, comme j'ai indiqué avant), mais il ne peut pas vérifier si la page est effectivement archivée sur Wikiwix. D'où l'intérêt d'un bot qui va aller vérifier les archives disponibles (je mets de côté les histoires, apparemment houleuses, de quel service privilégier). od†n ↗^blah 3 septembre 2026 à 12:05 (CEST)

C'est vrai, mais le problème existe pour Internet archive comme wikiwix, puisqu'une archive peut pointer vers une archive qui a été fait alors que le site était déjà squatté par un site publicitaire.

Par ailleurs, je viens de faire une série de vérifications sur 50 liens vers un site mort devenu squatté, ce n'est pas statistiquement représentatif mais sur ces liens, 43 étaient dans des articles, les liens dysfonctionnels ne concernaient que 2 liens, donc c'est assez peu. - Lupin (discuter) 3 septembre 2026 à 12:41 (CEST)

Manifestement, histoires très houleuses de quel service privilégier. Ça sera sans moi.

Une autre piste que je voudrais mentionner : actuellement, on peut spécifier une seule URL d'archive. Donc logiquement, cela force à choisir quoi mettre. On peut même considérer que c'est une régression par rapport à quand il n'y a pas d'archive précisée, car dans ce cas des liens vers plusieurs services sont générés. On pourrait donc implémenter des paramètres du genre archive2-url / archive2-date (avec éventuellement parsage URL pour déterminer quel site d'archivage c'est, et afficher « archive du <date> sur Trucmuche », mais l'affichage irait faire bien long, surtout avec justement plusieurs archives).

Encore une autre piste : faire désactiver au gadget JavaScript l'ajout de son lien « [archive] » si et seulement si l'archive spécifiée dans le modèle est déjà une archive Wikiwix ; c'est-à-dire que si c'est une archive d'un autre service, ne pas désactiver l'ajout par le gadget de son lien, qui serait donc en supplément.

od†n ↗^blah 4 septembre 2026 à 06:04 (CEST)

ça me semblerait une solution viable oui, et ça ne modifierait fondamentalement pas le fonctionnement comme la proposition actuelle - Lupin (discuter) 4 septembre 2026 à 10:22 (CEST)

J'aime bien aussi l'idée de laisser le choix au lecteur. -- Hippo ^{discutez sans frapper} 4 septembre 2026 à 11:52 (CEST)

@Od1n. YAGNI : si y'a pas de bot pour ajouter archive2-url, c'est rajouter de la complexité totalement inutile. Y'aura 20 usages par humains en 5 ans… Le jour où un bot voudra faire, on ajoutera un paramètre. Irønie 4 septembre 2026 à 12:17 (CEST)

@Od1n comme je l'ai toujours soutenu depuis l'époque d'IABot je suis contre les monopoles et contre les modifications en masse qui sont générées dans les articles surtout pour l'archivage des liens externes. Pour çà je rerererererepropose la solution qui consiste à exploiter le gadget Archivelinks et/ou un pendant pour les liens morts de mettre en place une page tampon qui liste les archives accessibles. Comme le fait très justement remarquer @Irønie les lecteurs consultent très peu les liens externes cela ne la dérange pas d'accéder à une page transitoire. PS j'ai répondu ici Ironie pour rappel moi aussi je suis plombier https://fr.wikipedia.org/w/index.php?title=Discussion_utilisateur:CodexBot&diff=prev&oldid=239201819 Pmartin (discuter) 3 septembre 2026 à 23:55 (CEST)

@Pmartin Non t'es un commercial IT, qui vend son logiciel, en invoquant des arguments abracadabrantesques pour dévaluer les concurrents.

Moi je bosse bénévole pour Wikipédia, et je suis ouvert à toutes solutions (même privée, payante, GAFAM ou chinoise), tant que c'est positif pour les articles, lecteurs, contributeurs.

— Irønie 4 septembre 2026 à 01:05 (CEST)

C'est assez ironique @Irønie d'accuser ton contradicteur de bosser pour de l'argent après avoir explicitement demandé de l'argent pour clarifier des éléments de ton argumentation.

Tu es agressif depuis plusieurs semaines, peux-tu revenir à un échange plus collaboratif stp ? - Lupin (discuter) 4 septembre 2026 à 10:21 (CEST)

je suis d'accord, je sens (peut-être à tord) de l'aggressivité dans vos propos Irønie. Vous êtes peut-être un plombier gratuit, mais n'oubliez pas que nous le sommes tout autant que vous. -- Hippo ^{discutez sans frapper} 4 septembre 2026 à 11:59 (CEST)

Je pense que le point intéressant à examiner est donc surtout la logique de la modification : lorsqu’une archive Wikiwix était déjà disponible et fonctionnelle via le gadget.

Le débat me paraît plus constructif si on se concentre sur ce comportement précis et sur la manière d’éviter une régression d’expérience user, plutôt que sur la question de savoir quel service d’archivage doit « gagner ». On veut tous les mêmes choses je pense, ce qui diffère est juste la perception. — Sabrsl --❯ ♥ ^[discuter] 4 septembre 2026 à 13:12 (CEST)

Pourquoi ne pas transformer en lien archive quand archive url = web.archive.org ?

Tout est dans le titre Remy34 (discuter) 31 août 2026 à 16:00 (CEST)

Tu peux. C'est plus compliqué, mais le rendu est identique. Casse-tête wikicode de conversion manuelle de modèle (plutôt qu'ajouter simplement brisé le), avec format machine d'horodatage quasiment illisible. Restreint à un seul archiveur (nom trompeur). Je ne sais pas quel avantage il apporte. - Irønie 31 août 2026 à 17:17 (CEST)

Le modèle est facile à utiliser, pas d'archive url pas d'archive date à ajouter, juste un horodatage archive. Il est facile à utiliser et la waybackmachine est très simple pour voir si une page a été archivée, ça c'est pour les avantages. Le modèle que tu proposes est cependant très utile pour les autres liens d'archive Remy34 (discuter) 31 août 2026 à 19:08 (CEST)

J'utilise beaucoup aussi {{Lien archive}} quand je corrige manuellement des liens brisés, mais je n'y suis pas absolument attaché. Je pense que la solution d'un modèle {{Lien web}} qui gèrerait aussi les liens brisés est une bonne idée, surtout s'il permet d'utiliser aussi les archives wikiwix.

Je suis en revanche sceptique sur la pertinence de renseigner la totalité de l'url de l'archive. La solution de {{Lien archive}} où on ne renseigne que le timestamp me semble bien meilleure : si archive.org change la syntaxe de ses liens, il suffira de modifier le modèle dans le cas où l'horodatage n'est qu'un paramètre, sinon, il faudra reprendre toutes les pages une par une. Un bot peut certainement faire le boulot, mais changer le modèle serait tellement plus simple et efficace.

Si une possibilité similaire est possible pour wikiwix, elle me semblerait préférable aussi, offrant plus de souplesse à wikiwix qui aura juste besoin de conserver l'identifiant de l'archive en cas de réorganisation, plutôt que l'ensemble de l'url.

Peu importe que l'identifiant (timestamp ou autre) soit incompréhensible, il n'est pas visible par le lecteur. -- Hippo ^{discutez sans frapper} 31 août 2026 à 19:59 (CEST)

Si Internet Archive changeait un jour sa syntaxe, une regex dans le module suffirait à reconstruire les liens, sans toucher une seule page.

Côté contributeur : d'un côté un simple copier-coller d'URL ; de l'autre, connaître un modèle supplémentaire avec ses paramètres, extraire un horodatage à la main… Voir mode d'emploi. Simplicité ?

Evaluation coût/risque : une dégradation de l'expérience utilisateur (complexité) qui perdure 20 ans, contre un pépin à faible probabilité qui se réglerait en 2 jours. Pas rentable. YAGNI : on n'ajoute pas de la complexité dont on n'a pas besoin aujourd'hui.

Au final, vous faites comme vous voulez. Ca restera toujours une goutte d'eau dans l'océan.

— Irønie 1 septembre 2026 à 12:10 (CEST)

{{Lien archive}} pouvant être compris comme lien vers une archive ou lien vers l'archive d Internet archive, il a aussi été proposé d'utiliser ce modèle pour accepter une archive wikiwix et Internet archive (avantage : éviter de favoriser un monopole, redondance, il semble aussi qu'il y ait eu des problèmes de légalité d'Internet Archive par le passé). - Lupin (discuter) 2 septembre 2026 à 17:26 (CEST)

archive-url et archive-date déconseillés

Bonjour, comme  Irønie : demandait qui avait déconseillé ces paramètres, un passage dans les archives m'a fait retrouver cette discussion Discussion_modèle:Lien_web/Archives/2023#Comment_utiliser_le_paramètre_'dead-link' (comme quoi certaines questions ne sont pas neuves;)).

 Jona, Ideawipik, Vega, Pmartin, Wyslijp16, Kertraon et Rayquachu : qui avaient participé à l'échange à l'époque. - Lupin (discuter) 2 septembre 2026 à 18:36 (CEST)