La lecture d'une entrée de journal recharge-t-elle son image distante ?
En règle générale, une entrée de journal contenant l'URL d'une image peut amener l'application ou le navigateur à demander cette image lors de l'affichage de l'entrée. Cependant, cela ne signifie pas que l'image est téléchargée depuis le serveur distant à chaque fois : un cache de navigateur valide peut la fournir, ou l'application peut gérer les images d'une autre manière. La première vérification pratique consiste à déterminer si l'entrée pointe vers une URL web ou vers une image enregistrée avec le journal. Un test hors ligne peut donner des indices, mais il ne peut pas prouver qu'aucune requête réseau n'a eu lieu.
Que signifie un lien d'image en Markdown ?
En Markdown standard, la syntaxe d'image telle que `` identifie une image par son URL. Le [tutoriel sur les images CommonMark](https://commonmark.org/help/tutorial/08-images.html) montre explicitement des URL web complètes comme destinations d'image valides. La syntaxe en elle-même n'indique pas que l'image a été copiée dans le journal ou stockée localement.
Lorsqu'un lecteur affiche cette entrée, le logiciel peut restituer l'URL en tant que source d'image. Dans une page web, l'élément `<img>` du navigateur intègre une image dans le document, et son attribut `src` identifie la ressource à afficher, comme décrit dans la [référence `<img>` de MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img). Le fait qu'une requête atteigne le serveur distant dépend de la mise en cache ainsi que de l'application, du navigateur et du chemin réseau spécifiques.
Le navigateur contacte-t-il le serveur à chaque lecture ?
Aucune règle immuable n'impose de récupérer chaque image à nouveau. Les navigateurs vérifient leur cache HTTP lors de l'envoi de requêtes ; s'il existe une réponse en cache correspondante et valide, le navigateur peut l'utiliser sans contacter le serveur d'origine pour cette image. Le [guide du cache HTTP de web.dev](https://web.dev/articles/http-cache) explique que la fraîcheur dépend des informations de mise en cache de la réponse et qu'une réponse en cache peut être réutilisée tant qu'elle reste fraîche.
Si une réponse en cache est périmée ou nécessite une validation, le navigateur peut contacter le serveur pour vérifier si la copie stockée est toujours à jour. Le serveur peut confirmer que la copie reste valide, ce qui signifie que cette vérification n'implique pas nécessairement un nouveau téléchargement complet de l'image. Le [guide de mise en cache HTTP de MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching) aborde la fraîcheur, la validation et les cas où les réponses ne doivent pas être mises en cache. La suppression du cache, l'expiration, la modification des URL, le comportement de l'application ou les paramètres de cache peuvent tous modifier ce qui se passe lors d'une lecture ultérieure.
La réponse prudente est donc la suivante : l'affichage d'une image distante peut entraîner une requête réseau, mais cela ne transfère pas nécessairement les octets de l'image à chaque fois — ni ne contacte l'origine à chaque consultation. Un affichage mis en cache et une nouvelle récupération peuvent paraître strictement identiques à l'écran.
Comment faire la distinction entre une URL et une pièce jointe enregistrée ?
Inspectez la référence de l'image ou les informations relatives aux pièces jointes de l'application, si celle-ci les affiche. Une destination commençant par `https://` ou `http://` pointe vers une adresse web distante. Un chemin relatif ou un nom de pièce jointe propre à l'application nécessite des vérifications supplémentaires. Dans une page web, un chemin relatif peut renvoyer à une autre adresse web ; cela ne prouve pas qu'un fichier est stocké localement sur votre appareil. Les règles de stockage et de rendu de l'application de journal déterminent la destination. Markdown à lui seul ne garantit pas qu'une référence d'apparence locale soit portable ou que le fichier soit stocké à l'intérieur de l'entrée.
Une distinction utile réside dans ce qui doit rester accessible : une URL distante dépend du maintien de l'existence et de l'accessibilité de la ressource distante ; une pièce jointe locale dépend de la présence du fichier concerné là où l'application l'attend. Pour préserver les fichiers photo de votre journal, suivez les instructions d'exportation ou de sauvegarde propres à l'application. Cet article se concentre sur la question distincte du chargement distant, et ne constitue pas une garantie quant au format de stockage d'une application particulière.
Que peut révéler une comparaison hors ligne ?
Pour un test sans risque, utilisez l'URL d'une image non sensible dans une entrée de test jetable. Consultez-la lorsque vous êtes en ligne, puis déconnectez l'appareil du réseau et rouvrez l'entrée. Si l'image apparaît hors ligne, cela concorde avec la disponibilité d'une copie en cache ou d'une autre copie locale. Si elle n'apparaît pas, l'application peut avoir besoin de la ressource distante à ce moment-là — mais ce résultat seul n'explique pas précisément pourquoi.
Cette comparaison ne permet pas d'établir qu'une lecture normale en ligne n'effectue aucune requête réseau. Le navigateur a pu effectuer une requête avant la déconnexion, vérifier un service worker ou un cache d'application, ou afficher une image déjà stockée localement. De même, voir l'image hors ligne ne prouve pas que le Markdown de l'entrée contient une pièce jointe : l'application a pu simplement mettre en cache la réponse distante. Pour un journal basé sur un navigateur, observez le comportement des requêtes à l'aide des outils de développement réseau du navigateur lorsque vous êtes en ligne, et inspectez la requête d'image ainsi que son état dans le cache ; les résultats décrivent cette configuration de test précise, et non chaque lecture ultérieure ou chaque appareil.
Liste de contrôle pratique
Pour une entrée qui doit s'afficher de manière prévisible, inspectez la référence de l'image, puis vérifiez si la pièce jointe locale correspondante existe s'il s'agit d'un fichier censé être local. S'il s'agit d'une URL distante, prévoyez que la disponibilité et le comportement de mise à jour dépendront de l'hébergeur et de la mise en cache. Utilisez le panneau réseau en ligne pour observer les requêtes et une réouverture hors ligne à titre de comparaison limitée. Considérez chaque résultat comme un indice propre à l'application, au navigateur et à l'état du cache testés — et non comme une garantie universelle.