Update references

1 files changed, 4 insertions, 1 deletions

diff --git a/articles/formats-images-web.md b/articles/formats-images-web.md
index af60948..3469f49 100644
--- a/articles/formats-images-web.md
+++ b/articles/formats-images-web.md
@@ -534,11 +534,14 @@ Pour les PNG, il est difficile de choisir entre AVIF et WebP2 dans le cas géné
 Si vous traitez vos images manuellement, testez AVIF et WebP2, voyez celui qui colle le mieux à vos données.
 Si vous effectuez un **traitement automatique**, utilisez de préférence **WebP2**, mais gardez en tête que AVIF est un très bon candidat également, notamment si vous êtes contrains en temps d'encodage ou charge CPU ou que vous avez des images de dimensions arbitrairement grandes.
 
-Ainsi, ce que j'observe entre en contradiction avec d'autres études sur le sujet.
+Ainsi, ce que j'observe entre en contradiction avec d'autres études sur le sujet. [^autres]
 Cela peut être dû aux avancés depuis des encodeurs.
 En effet, libjxl et libheif sont en développement actif alors que [libwp2](https://chromium.googlesource.com/codecs/libwebp2/) est en pause.
 Malgré la maturité de l'encodeur, il semble que [WebP2 ne dépassera pas le stade expérimental](https://chromium.googlesource.com/codecs/libwebp2/+/1251ca748c17278961c0d0059b744595b35a4943%5E%21/).
 
+
+[^autres]: Comme cette étude de [Mozilla de 2013](https://web.archive.org/web/20160524224706/https://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/) ou celle de [Google de 2011](https://web.archive.org/web/20220429073742/https://developers.google.com/speed/webp/docs/webp_study) (mais mise à jour plusieurs fois).
+
 :::details
 Ressources complémentaires