Demandez à votre agent de navigation une affirmation par ligne, avec la page d’origine, l’endroit précis qu’il a lu et son verdict. Un relecteur pourra ainsi revenir du rapport au passage pertinent. Dans notre exemple public, deux sources officielles emploient des libellés différents pour HTTP 418. La date et le rôle des documents expliquent cet écart.
Partir d’une question vérifiable
Nous avons posé deux questions : comment le registre actuel présente-t-il le code 418 et d’où vient la formule de la théière ? Le 6 novembre 2026, nous avons ouvert le registre et deux RFC dans Tabbit. L’auteur a revu les verdicts de cette vérification guidée. Pour une tâche autonome, donnez le même périmètre à l’agent et demandez-lui les lignes en suspens avant la rédaction.
Précisez dès le départ la date et les conditions pour retenir une source primaire. « Relever le libellé actuel et le texte historique » se vérifie plus facilement que « expliquer HTTP 418 ». Ouvrez d’abord quelques pages primaires, puis élargissez si une preuve manque. Les cas d’usage de recherche approfondie aident à choisir les questions. La liste de contrôle pour une première tâche permet de définir les sites et les actions.
Remonter de l’affirmation au texte d’origine
| Affirmation à vérifier | Source primaire et emplacement | Verdict |
|---|---|---|
| C1. Le registre actuel indique que 418 est inutilisé. | IANA, ligne 418, avec renvoi au RFC 9110 §15.5.19. | Étayée pour le registre IANA. |
| C2. La formule historique de la théière figure dans le RFC 2324. | RFC 2324 §2.3.2, avril 1998. | Étayée comme formulation historique d’un RFC informatif. |
| C3. La norme actuelle appelle le code 418 « Je suis une théière ». | RFC 9110 §15.5.19, juin 2022. | Contredite. Le titre indique « (Unused) » et le texte explique la réserve. |
| C4. Le RFC fourni confirme un autre comportement du serveur. | Adresse volontairement invalide chez RFC Editor, utilisée comme témoin. | Non vérifiée. Tabbit a observé une réponse HTTP 404. |
Le CSV de l’exemple conserve les URL et le résultat des quatre lignes, y compris le lien volontairement invalide. Le registre IANA renvoie au RFC 9110. Il s’agit d’une même chaîne de référence. Le RFC 2324 répond à la question historique. Pour établir qu’un serveur renvoie 418, il faudrait une preuve sur son implémentation.
Ouvrez les citations des phrases qui comptent et notez la destination après redirection. Retrouvez la section désignée. Gardez les conditions lorsque vous citez ou reformulez. Si la source ne parle que de certaines implémentations, conservez cette limite. Scindez une phrase qui mélange le statut actuel et l’origine historique. Le tutoriel sur la CLI de navigateur présente la lecture de texte et le comparatif MCP et CLI explique comment le résultat parvient à l’agent.
Conserver les échecs et les désaccords
| Verdict | Traitement de la ligne |
|---|---|
| Étayée | Citez dans le périmètre de la source. |
| Contredite | Corrigez l’affirmation avant de rédiger. |
| Partielle | Scindez la phrase et gardez la partie étayée. |
| Non vérifiée | Conservez l’échec ou notez la preuve manquante. |
Utilisez quatre verdicts : étayée, contredite, partiellement étayée et non vérifiée. Une réponse 404 décrit la requête. L’affirmation reste à vérifier. Face à une connexion obligatoire, gardez le titre affiché et signalez que le texte reste inaccessible. En l’absence d’une autre source valable, retirez l’affirmation de la conclusion. Consultez le guide des permissions de navigation avant de traiter les pages protégées.
Lorsque deux documents diffèrent, vérifiez les dates, le périmètre et les définitions. Ici, le registre et la formule historique répondent à deux questions distinctes. Si le désaccord demeure, gardez les deux valeurs et précisez la preuve manquante. Datez les vérifications qui peuvent évoluer et revenez à la source primaire avant de réutiliser le rapport.
Vous pouvez demander : « Rends d’abord le tableau. Pour chaque affirmation, indique l’URL, la section ou la ligne, le passage, la date et le verdict. Conserve les échecs. Tire les conclusions des seules lignes étayées et indique les inférences. » Contrôlez quelques réussites et toutes les lignes en suspens. Le guide d’automatisation et le processus de recherche détaillent les étapes. L’exemple peut être refait dans Tabbit.
Sources : Registre IANA des codes HTTP, RFC 9110 §15.5.19, RFC 2324 §2.3.2.
Questions fréquentes
Que mettre dans un tableau de sources ?
Pour chaque affirmation, consignez un identifiant, l’URL demandée et l’URL finale, l’emplacement, le passage, la date et un verdict motivé.
Un lien qui fonctionne peut-il être une mauvaise citation ?
Oui. La page peut traiter le bon sujet tout en portant sur une autre date, une autre population ou une conclusion différente.
Que noter si la source ne s’ouvre pas ?
Gardez l’URL demandée, la destination connue, la date, la réponse observée et l’affirmation. Laissez celle-ci non vérifiée jusqu’à trouver une source adaptée.
Que faire de deux sources divergentes ?
Comparez les dates, le périmètre, l’autorité et les définitions. Gardez les deux lignes et dites si l’écart a pu être expliqué.
Faut-il citer chaque source mot pour mot ?
Un extrait bref ou une paraphrase fidèle et son emplacement suffisent. Distinguez le contenu de la source de votre conclusion.