Une publication manquante sur un serveur Mastodon signifie que ce serveur local n’a pas récupéré ni indexé cet objet, et non que le compte ou la publication est absent du fédivers. Si vous disposez d’une URL exacte d’objet public partagée volontairement, ouvrez-la en étant connecté au serveur que vous vérifiez afin que le serveur puisse tenter de récupérer l’objet public distant connu. S’il ne se résout toujours pas, consignez la limite précise : l’objet n’a pas pu être confirmé depuis ce serveur, et vous vous arrêtez là.
Trouvez des indices sur les profils sociaux publics avec notre application TraceSeek.
Ce qu’un serveur voit réellement
Mastodon est fédéré : aucun serveur unique ne détient donc une vue complète de tous les comptes ni de toutes les publications publiques. Un serveur ne connaît que certaines publications publiques, et il n’existe aucun état de timeline globale partagé qu’un administrateur pourrait inspecter. Lorsqu’une URL publique distante connue est recherchée, le serveur peut récupérer cet objet dans sa vue locale. C’est une découverte, non la preuve que le réseau au sens large contient ou ne contient pas autre chose. [Mastodon : fils fédérés et interactions avec les publications]
- Considérez ce qui apparaît sur votre serveur comme une couverture locale, non comme un recensement mondial.
- Conservez l’URL publique complète lors de la vérification ; la partie hôte seule n’est pas une adresse d’objet.
L’absence est locale, non globale
Si l’URL exacte de l’objet public ne se résout pas sur votre serveur, l’observation étayée est que ce serveur ne peut pas l’afficher lors de cette tentative. Les raisons possibles incluent le fait que le serveur n’a pas récupéré l’objet, que le compte ou la publication est restreint, ou qu’une règle de visibilité et d’autorisation le filtre. Aucun de ces résultats ne justifie d’affirmer que le compte n’existe pas ou que la publication n’a jamais été faite. Notez uniquement la tentative et son résultat local.
Pourquoi un nom de serveur dans un nom d’utilisateur ne suffit pas
Conserver le domaine d'un nom d'utilisateur vous indique où un compte est hébergé, mais cela ne porte pas l'adresse d'une publication particulière. La découverte d'objets fédérés exige l'identifiant exact de l'objet, et non une supposition reconstruite. Si quelqu'un ne partage qu'un nom d'utilisateur ou un domaine de serveur, vous ne pouvez pas en déduire l'URL de la publication, et une reconstruction qui semble fiable peut pointer vers un autre objet. Demandez uniquement une URL d'objet public partagée volontairement ; ne cherchez pas de dossiers privés et n'essayez pas d'atteindre un contenu restreint.
| observation | limite | étape suivante |
|---|---|---|
| L'URL exacte de l'objet public se résout sur votre serveur | Cela prouve seulement que votre serveur peut afficher l'objet maintenant | Lisez l'objet et notez la date et le serveur que vous avez vérifiés |
| L'URL exacte de l'objet public ne se résout pas | Il s'agit d'une non-couverture locale, et non d'une absence globale | Notez la tentative échouée et arrêtez-vous ; ne déduisez ni suppression ni inexistence |
| Vous n'avez qu'un nom d'utilisateur avec un domaine de serveur | Cela identifie un hôte, pas une publication | N'inventez pas d'URL de publication ; demandez ou appuyez-vous sur un lien public partagé volontairement |
| Le lien est ambigu, ne correspond pas ou pointe vers un contenu restreint | Les éléments ne soutiennent aucune affirmation sur le compte ou la publication | Notez la limite précise et ne tirez aucune inférence sur l'identité ou l'activité |
Séparez l'observation de la décision
Gardez deux lignes dans vos notes. La ligne d'observation indique ce que vous avez vu : une URL publique exacte s'est résolue, ne s'est pas résolue, ou n'a jamais été fournie. La ligne de limite indique ce que ce résultat ne peut pas établir. Consignez toute décision sur une troisième ligne, comme suspendre une tâche de vérification ou redemander un lien public. Ne laissez pas un résultat local manquant devenir une affirmation sur la personne derrière le compte, son intention ou son activité actuelle. Un badge, un nom concordant ou un paramètre de confidentialité ne prouvent pas non plus l'identité.
Un parcours hypothétique
Imaginez qu'un collègue partage l'URL exacte d'une publication publique et dise qu'elle ne s'affiche pas sur son serveur Mastodon. Vous ouvrez la même URL connecté à ce serveur et ne voyez toujours rien. La note prudente est : le serveur n'a pas pu confirmer cet objet public lors de la tentative à cette date. Ce n'est pas : l'auteur a supprimé la publication, le compte a disparu, ou le collègue a été bloqué. Si le collègue fournit ensuite un autre lien public, traitez-le comme une nouvelle vérification avec sa propre observation et sa propre limite.
- Notez l'URL exacte et le serveur vérifié dans vos notes.
- Énoncez le résultat comme une couverture locale uniquement.
- Arrêtez-vous avant de déduire une suppression, une identité, une intention ou une activité actuelle.
Quand s'arrêter plutôt que chercher plus fort
Arrêtez-vous lorsque la source est absente, privée, discordante ou ambiguë. Tenter de contourner une restriction, de faire correspondre des visages ou d'identifier un propriétaire à partir d'une photo dépasse la vérification de sources publiques et n'est pas soutenu par cette fiche de travail. Si une image de profil public est le seul élément, une recherche de similarité d'images ou une recherche OCR sur des sources publiques peut faire apparaître d'éventuelles correspondances publiques, mais les résultats ne garantissent pas une couverture et n'identifient pas une personne ni ne prouvent une activité. Traitez toute description générée par IA d'un profil public comme une supposition, sauf si le profil énonce lui-même l'affirmation.
Une fiche de travail pour le lecteur
Dressez un tableau court à trois colonnes : l'URL exacte de l'objet public, le serveur et la date vérifiés, et le résultat local avec sa limite. Ajoutez une dernière colonne pour toute action, comme redemander un lien public ou clore la vérification. Cette fiche de travail est une aide éditoriale pour organiser vos propres notes ; ce n'est pas un test de plateforme ni un contrôle dont vous pouvez supposer l'existence. Limitez-la à du matériel public partagé volontairement. [Mastodon : fils fédérés et interactions avec les publications]
Encore quelques questions
Une publication manquante sur mon serveur Mastodon signifie-t-elle que le compte a été supprimé ?
Non. Cela signifie que votre serveur n'a pas pu afficher cet objet lors de cette tentative. La publication peut exister ailleurs, être restreinte, ou simplement ne pas avoir été récupérée localement. Notez une non-couverture locale et évitez toute affirmation sur une suppression ou une identité.
Puis-je déduire l'URL d'une publication à partir d'un nom d'utilisateur et d'un serveur Mastodon ?
Non. Le domaine du serveur identifie où un compte est hébergé, pas une publication précise. La découverte d'objets exige l'URL exacte de l'objet public, et une adresse reconstruite peut pointer vers autre chose.
Et si le lien public est privé, discordant ou ambigu ?
Notez cette limite précise et arrêtez-vous. Ne tentez pas d'accéder à un compte privé, d'identifier à partir d'une similarité, ni de déduire une intention, un statut relationnel ou une activité actuelle à partir de la vérification échouée.
Une recherche réussie prouve-t-elle que le compte est actif ?
Non. Cela montre que votre serveur pouvait afficher cet objet public à ce moment-là. Cela ne prouve pas qui possède le compte, que le propriétaire est actif maintenant, ni qu'une autre publication existe.
Sources et notes éditoriales
Références officielles vérifiées le 24 octobre 2026. Les listes de contrôle, tableaux comparatifs et exemples de formulation sont des outils éditoriaux de DateClues, et non des tests officiels ni des scores de risque validés.
Informations générales. Aucun guide ou outil ne peut certifier l'identité, les intentions ou la sécurité d'une personne. Lire nos normes éditoriales.