Ressources · 10

Intégrité informationnelle : vérifier provenance, contexte et transformations

Une procédure pour qualifier un document, une image ou une vidéo avant de la citer, la partager ou l’utiliser dans une décision.

Mis à jour le 23 octobre 2026 · 12 min

Illustration · scène fictive

Ce que ce guide permet

Retrouver la version la plus ancienne accessible
Séparer fichier authentique et légende trompeuse
Documenter les transformations
Corriger sans effacer la trace

Contrôle express

Qui publie le fichier et d’où le tient-il ?
Une version antérieure existe-t-elle ?
Le lieu et la lumière sont-ils compatibles ?
Les métadonnées sont-elles cohérentes mais non suffisantes ?
Quels contenus dépendent de cette preuve ?

Méthode pas à pas

01
Préserver l’élément
Conservez URL, date de consultation, fichier reçu, contexte visible et empreinte lorsque cela est licite. Travaillez sur une copie et notez toute conversion.
Livrable : entrée de journal et empreinte.
02
Remonter la provenance
Cherchez la publication la plus ancienne, l’auteur revendiqué, les relais intermédiaires et les éventuelles versions recadrées ou recompressées.
Livrable : chaîne de provenance.
03
Vérifier contenu et contexte
Comparez relief, bâtiments, météo, ombres, langue, chronologie et événements connus. Une image vraie peut être réutilisée avec un lieu ou une date faux.
Livrable : hypothèses confirmées et réfutées.
04
Examiner les métadonnées
Utilisez EXIF, encodage, dimensions et historique comme indices. Leur absence ou leur présence ne prouve jamais seule l’authenticité.
Livrable : relevé technique interprété.
05
Corroborer indépendamment
Recherchez source primaire, autre angle, document officiel ou témoin distinct. Identifiez les reprises qui dépendent toutes du même fichier.
Livrable : matrice de corroboration.
06
Publier et corriger
Exposez niveau de confiance, limites, méthode et source. Si la conclusion change, mettez à jour les pages liées et conservez une note de correction datée.
Livrable : décision éditoriale et registre de corrections.

Comprendre · essayer · décider

Photo réelle : distinguer l’image, sa légende et la page qui la publie

La NASA décrit cette image « Earthrise » comme une vue de Lunar Orbiter 1, avec la Terre à droite de la Lune, et la crédite à la NASA. La page affiche une date de publication en 2017. Cette date de page ne suffit pas à dater la prise de vue. Le titre « Earthrise » seul ne permet pas d’attribuer une image à une mission.

Commencez par une affirmation précise à vérifier : quel objet, quelle mission, quelle date ou quel lieu ? Revenez ensuite à la page institutionnelle et conservez le lien vers le fichier. Comparez les détails visibles et la légende ; notez les transformations faites pour l’affichage.

Un crédit ou une source institutionnelle documente la provenance, sans valider toutes les interprétations d’une image. De même, une empreinte de fichier permet de retrouver une copie précise ; elle ne prouve pas la vérité de la scène. Pour une publication, consignez séparément ce que la source affirme et ce que vous avez vérifié.

Repères et preuves à conserver

Repère	Ce que vous pouvez conclure	Preuve à conserver
Fichier	La copie que vous avez consultée	URL du fichier, date de consultation et empreinte
Légende	L’attribution donnée par l’éditeur	Mission, crédit et texte de la page source
Date de page	Une information sur la publication	Libellé exact ; date de prise de vue à vérifier séparément
Droits et transformations	Conditions de réutilisation et modifications	Consignes NASA, crédit et redimensionnement local

Du constat à la décision

Formuler l’affirmation
Retrouver la source
Comparer fichier et légende
Documenter les limites

Deux « Earthrise », deux attributions

Le titre commun ne désigne pas un fichier unique. La première page NASA attribue sa vue à Lunar Orbiter 1. La seconde attribue la photo couleur à Bill Anders, mission Apollo 8, et distingue sa date historique de sa date de publication. Comparer les deux fichiers aide à vérifier l’attribution avant toute interprétation.

Photographie NASA montrant la surface de la Lune et la Terre sur la droite. — Photo réelle — NASA, Lunar Orbiter 1. Copie redimensionnée pour le site. Source et consignes de réutilisation ci-dessous. NASA — Lunar Orbiter 1

Photographie couleur NASA : la Terre bleue et blanche au-dessus de l’horizon lunaire gris. — Photo réelle — NASA/Bill Anders, Apollo 8. Date historique indiquée : 24 décembre 1968. Copie redimensionnée, sans modification de la scène. NASA/Bill Anders

Lire les libellés de date sur la page Apollo 8
Date affichée	Libellé et portée	Conclusion possible
24 décembre 1968	Historical Date	Date historique attribuée à la photographie par la NASA.
22 février 2019	Date de publication de la page	Date de cette publication, distincte de l’événement.
9 septembre 2023	Original, dans la section Downloads	Date affichée pour cette entrée de téléchargement ; pas une nouvelle prise de vue.

Dates relevées sur la page NASA consultée le 14 octobre 2026. Une date de fichier local après téléchargement ne remplace aucun de ces libellés.

Fiche d’attribution minimale
Élément	Copie Lunar Orbiter 1	Copie Apollo 8
Titre	Earthrise	Apollo 8’s Iconic Earthrise
Mission dans la source	Lunar Orbiter 1	Apollo 8
Crédit dans la source	NASA	NASA/Bill Anders
Repère visuel	Terre sur la droite de la vue lunaire	Terre bleue et blanche au-dessus de l’horizon gris

Les repères visuels servent à rapprocher une copie de sa source ; ils ne constituent pas une preuve autonome de lieu ou de date.

Contrôles avant de conclure

Identifier l’affirmation examinée, la page source et le fichier exact. Un résultat de recherche ou une miniature ne suffit pas.
Noter mission, crédit et libellés de date séparément ; ne pas transformer une date de publication en date de prise de vue.
Conserver la description des transformations : redimensionnement ici, recadrage ou retouche si une autre publication en applique.
Vérifier les conditions de réutilisation et l’éventuelle présence de droits tiers. Le crédit NASA ne signifie pas un soutien de la NASA au site.

Décision : attribuer chaque copie à la mission indiquée par sa propre source. Une scène réelle peut être accompagnée d’une légende erronée sans que le fichier ait été retouché.

Changer une hypothèse

Vérifier une légende avant de juger le fichier

Les photos historiques ci-dessus montrent pourquoi une attribution se vérifie séparément de la réalité de la scène.

Identifier
Rapprocher la copie de la vue Lunar Orbiter 1 ou de la photo Apollo 8.
Attribuer
Relever mission, auteur ou crédit et date historique dans la source correspondante.
Publier
Décrire la copie et ses transformations sans reprendre une légende non vérifiée.

Exercice de lecture : les variantes décrivent des situations fictives.

Et si le nom du fichier contient « Apollo » ?

Nouvel élément: La vue correspond à Lunar Orbiter 1 malgré son nom de fichier.
Ce que cela change: Un nom local peut être modifié librement. Donner priorité à la correspondance avec la source et expliquer l’erreur d’attribution.

Et si la page a été mise à jour cette semaine ?

Nouvel élément: La date récente concerne la page ou sa fiche, pas nécessairement la photographie.
Ce que cela change: Conserver séparément date historique, publication et mise à jour. Ne pas déduire une nouvelle prise de vue de la seule date du site.

Exemple d’application

Situation illustrative

Une image virale prétend montrer un événement récent. L’équipe recherche la publication la plus ancienne, compare les lieux visibles et lit les métadonnées de provenance si elles existent.

Décision et preuve attendue

La note distingue ce que la provenance technique atteste, ce que des sources indépendantes confirment et ce qui reste impossible à conclure.

Indicateurs de pilotage

Indicateur	Ce qu’il mesure	Première action
Provenance	Éléments reliés à une origine documentée	Traiter d’abord les preuves décisives sans source
Corroboration	Conclusions soutenues par des indices indépendants	Éliminer les reprises circulaires
Délai de correction	Temps entre découverte d’une erreur et mise à jour des contenus	Maintenir la liste des pages dépendantes
Inconnues visibles	Limites importantes explicitement signalées	Empêcher une hypothèse de devenir un fait

Erreurs fréquentes

Confondre absence d’EXIF et falsification
S’arrêter à une recherche inversée sans résultat
Prendre plusieurs republications pour plusieurs sources
Corriger une page mais pas ses reprises

Questions fréquentes

Les métadonnées prouvent-elles qu’une image est vraie ?

Non. Elles peuvent être supprimées, modifiées ou héritées d’un appareil. Elles doivent être recoupées avec le contenu, le contexte et la provenance.

Comment traiter un contenu synthétique ?

Cherchez les informations de provenance disponibles, examinez cohérence et contexte, puis évaluez surtout la véracité de l’affirmation associée.

Faut-il supprimer une erreur ?

Corrigez clairement le contenu et sa diffusion. Lorsque l’erreur a déjà influencé des lecteurs, une note datée explique mieux le changement qu’une disparition silencieuse.

Références : données, usages et limites

Documentation consultée le 2026-10-22.

Références : données, usages et limites
Source et objet	Donnée ou repère vérifié	Comment l’utiliser	Limite à conserver
FIRST · Traffic Light Protocol Indiquer à qui une information peut être redistribuée.	TLP 2.0 utilise RED, AMBER, GREEN et CLEAR ; AMBER+STRICT limite le partage à l’organisation du destinataire. Les libellés ne se traduisent pas.	Conservez le marquage avec l’information et vérifiez les destinataires avant transfert. En cas d’ambiguïté, demandez une clarification à la source. Approfondir la méthode →	TLP n’est ni une classification formelle ni une licence de réutilisation. Il ne garantit pas l’exactitude du contenu.
C2PA · Content Credentials Décrire et vérifier certaines informations de provenance d’un contenu.	La spécification C2PA 2.4 décrit des manifestes, assertions et mécanismes de liaison cryptographique associés aux médias.	Examinez ce que le manifeste affirme, qui l’a signé et si la validation aboutit. Testez la conservation de ces informations après transformation et diffusion. Approfondir la méthode →	Une provenance validée ne prouve pas la vérité de la scène. L’absence de manifeste ne démontre pas qu’un média est faux.

Provenance des médias et validation C2PA

Un rapport de provenance rassemble des constats de portée différente. La signature, la confiance dans le certificat, la liaison au contenu et le contexte de la scène ne sont pas une seule garantie. Conservez le fichier précis et le rapport complet avant de résumer un résultat.

Repères sur C2PA 2.4, dont l’historique date cette version d’avril 2026. L’explorateur explique douze codes sélectionnés ; il ne valide aucun fichier, ne recherche aucun manifeste et ne détecte pas les images générées. Les cas sont fictifs et les propositions de vérification sont éditoriales.

Références consultées le 2026-10-22.

Quatre dimensions techniques, puis une vérification du contexte

Lire douze codes C2PA sans extrapoler

Les trois groupes ci-dessous sont ceux de la spécification : success, informational et failure. Un code de succès porte sur son contrôle précis ; il ne remplace pas l’ensemble de la validation. Une information manquante et un échec de contrôle ne se résument pas par « faux ».

Lire douze codes C2PA sans extrapoler
Code et groupe dans C2PA 2.4	Constat décrit	Vérification complémentaire proposée	Conclusion à éviter
`claimSignature.validated` Succès · success	La signature du claim a été validée.	Lire aussi la confiance, la période de validité et la liaison à l’actif concerné.	Toute la scène est vraie ou toutes les vérifications sont terminées.
`signingCredential.trusted` Succès · success	Le justificatif de signature est reconnu comme fiable par le validateur.	Noter la liste de confiance, sa version et la politique appliquée.	Le nom d’un signataire suffit à confirmer l’événement représenté.
`timeStamp.validated` Succès · success	Le jeton d’horodatage passe les contrôles décrits par la spécification.	Distinguer cet horodatage de la prise de vue et lire la confiance dans l’autorité d’horodatage.	L’heure attestée est nécessairement celle de la scène photographiée.
`assertion.dataHash.match` Succès · success	La liaison de hachage des données correspond pour le périmètre vérifié.	Examiner l’assertion et les plages exclues, ainsi que les autres liaisons applicables.	Tous les octets et toutes les métadonnées du fichier sont couverts sans exception.
`signingCredential.ocsp.inaccessible` Information · informational	Une vérification OCSP en ligne a été tentée sans réponse.	Conserver les conditions réseau et distinguer absence de réponse et statut retourné.	Le certificat est révoqué ou, à l’inverse, certainement non révoqué.
`signingCredential.ocsp.unknown` Information · informational	La réponse OCSP indique un statut unknown pour le justificatif de signature.	Lire le rapport et la politique de traitement de ce statut.	Unknown est synonyme de good ou de revoked.
`ingredient.unknownProvenance` Information · informational	L’ingrédient concerné ne possède pas de manifeste C2PA.	Identifier cet ingrédient et ce que l’historique permet effectivement de retrouver.	Tous les ingrédients ont été vérifiés, ou cet ingrédient est nécessairement faux.
`assertion.dataHash.additionalExclusionsPresent` Information · informational	La liaison exclut des plages autres que le magasin de manifestes C2PA.	Relever précisément les zones exclues et leur importance pour l’affirmation examinée.	Le succès du hachage protège automatiquement les métadonnées exclues.
`claimSignature.mismatch` Échec · failure	La vérification de la signature du claim échoue.	Conserver fichier, manifeste et rapport ; comparer avec la copie source disponible.	La cause de l’échec ou l’intention d’une personne est déjà établie.
`signingCredential.untrusted` Échec · failure	Le justificatif ne figure sur aucune liste de confiance applicable du validateur.	Vérifier la politique et la liste retenues ; ne pas confondre ce résultat avec une signature mathématiquement incorrecte.	Le fichier est forcément fabriqué ou la signature est nécessairement invalide mathématiquement.
`assertion.dataHash.mismatch` Échec · failure	Une plage de données ne correspond pas à l’empreinte déclarée dans l’assertion.	Identifier la copie contrôlée et ses transformations avant d’expliquer la différence.	Toute différence démontre une falsification intentionnelle de la scène.
`signingCredential.ocsp.revoked` Échec · failure	La réponse OCSP indique une révocation dans le contrôle appliqué.	Lire les éléments temporels et la procédure de validation qui ont conduit au résultat.	Un résumé détaché de sa date et de son rapport permet de conclure sur toutes les copies.

C2PA 2.4 · §15.2 →

Quatre points de version utiles aux équipes éditoriales et techniques

Version publiée: L’historique indique C2PA 2.4 en avril 2026. Enregistrer la version du validateur reste nécessaire : lire une page récente ne met pas votre outil à jour.
specVersion: Dans cette version, le champ recommandé figure dans claim_generator_info. Il est informatif ; le validateur ne devrait pas changer sa logique uniquement sur sa valeur.
crJSON: Cette représentation JSON-LD est une vue dérivée des données C2PA, utile aux rapports et à l’interopérabilité. Elle n’est pas vérifiable indépendamment et n’est pas un format d’entrée de validation.
c2pa.ai-disclosure: L’assertion fournit une déclaration de transparence sur l’IA. Ne la transformez pas en détecteur universel, ni son absence en preuve d’une origine humaine.

Six situations fictives pour préparer une décision de publication

Six situations fictives pour préparer une décision de publication
Situation fictive	Vérification concrète	Décision proportionnée aux preuves
Une photo signée reçoit une nouvelle légende	Rapprocher le fichier et le rapport de la scène, de la date et du lieu affirmés dans la nouvelle légende.	Décrire la provenance vérifiée et laisser l’attribution événementielle en attente si elle n’est pas corroborée.
Une variante redimensionnée ne correspond plus à l’ancienne liaison	Comparer original, outil de transformation, variante diffusée et manifeste effectivement associé à chacun.	Traiter la rupture de validation sans conclure à une manipulation malveillante sur le seul code de hachage.
Deux validateurs ne reconnaissent pas le même signataire	Noter versions, listes de confiance et politique, puis comparer les autres résultats.	Expliquer l’écart de confiance ; éviter de présenter deux politiques différentes comme deux vérités incompatibles sur la scène.
Une capture d’écran ne présente plus de Content Credential	Rechercher le fichier antérieur et documenter la chaîne de copies connue.	Conserver le statut de la capture et l’incomplétude de son historique ; l’absence de manifeste ne démontre pas une image fausse.
Un succès de liaison accompagne des métadonnées exclues	Identifier les champs ou plages exclus et les informations de légende qui en dépendent.	Limiter la conclusion au périmètre réellement couvert et vérifier les champs décisifs par une autre voie.
Un fournisseur ne transmet qu’un rapport crJSON	Demander l’actif et les données de provenance nécessaires à la vérification, avec la version de l’outil et sa politique.	Utiliser le rapport comme élément à examiner, sans prétendre avoir refait sa validation cryptographique.

Conserver une fiche de vérification exploitable

Objet exact: Fichier ou flux examiné, origine connue, copie et transformations.
Outil et politique: Validateur, version, configuration et listes de confiance pertinentes.
Résultats complets: Codes, objet concerné, explications et éléments temporels ; conserver aussi les informations non conclusives.
Affirmation examinée: Phrase précise sur le lieu, la date, l’auteur ou l’usage d’IA, avec sa source.
Décision éditoriale: Ce qui est établi, ce qui manque et ce qui ferait réviser la conclusion.

Examiner les origines et les reprises d’une information →

Références primaires et limites de lecture

Cette sélection n’est pas un inventaire exhaustif des codes C2PA. Les procédures complètes, formats et politiques de confiance restent ceux de la spécification et de votre validateur. Les schémas, cas et fiches sont des propositions pédagogiques CIE.

C2PA · Content Credentials Technical Specification 2.4 · 2.4 · April 2026 · 2026-04
§5.3.1; §14.3; §15.2; §15.7–15.12
C2PA · Content Credentials Explainer · 2.4
§2; §7.2–7.4
C2PA · Security Considerations · 2.4
§2.2–2.6; §4; §5

Indicateurs STIX et partage TLP

Contrôler le périmètre TLP avant de publier un extrait

La traçabilité d’une note ne donne pas à elle seule le droit de la redistribuer. Le marquage TLP, les restrictions complémentaires et le destinataire prévu doivent accompagner la décision de caviardage ou de publication.

AMBER+STRICT limite le partage à l’organisation ; la possibilité AMBER de protéger des clients ne s’y applique pas par défaut.
GREEN exclut les canaux publics ; CLEAR ne supprime pas les règles de droit d’auteur ni les restrictions distinctes.
Vérifier les marquages de chaque champ cité et obtenir l’accord explicite de la source si le partage envisagé dépasse le périmètre reçu.

Consulter la fiche STIX, observations et partage TLP →

Sources vérifiées le 2026-10-22 · FIRST · TLP 2.0

OSINT : preuves et conservation

La provenance déclarée et la conservation répondent à des questions distinctes

Un historique de modifications ou un manifeste ne remplace pas le contexte de collecte. La conservation relie les objets effectivement reçus, les copies produites et leurs manipulations documentées.

Distinguer intégrité binaire, identité de la source et véracité d’une affirmation.
Conserver les versions dérivées avec leurs propres identifiants et références.
Documenter les éléments absents avant de formuler une conclusion de confiance.

Voir la filiation des copies et les huit cas de conservation →

Sources vérifiées le 2026-10-22 · NIST · Digital Evidence Preservation · NIST IR 8387 · Full report · NIST · SP 800-86 · NIST SP 800-86 · Full report · NIST · FIPS 180-4 · Secure Hash Standard

PDF : expurgation et diffusion

Une transformation documentée doit aussi passer la revue de diffusion

La filiation d’un dérivé explique sa provenance technique ; elle ne prouve pas que toutes les informations exclues ont été retirées. Les surfaces visibles, cachées et incorporées restent à vérifier.

Distinguer marquage en attente, expurgation appliquée et nettoyage des données cachées.
Vérifier le témoin positif avant d’interpréter une recherche négative.
Associer la décision à la version réellement remise et à ses destinataires.

Voir les surfaces et la matrice de revue avant partage →

Sources vérifiées le 2026-10-22 · Adobe · Redacting and sanitizing PDFs · Adobe · Redact sensitive content · Adobe · Sanitize PDFs · ICO · Avoid accidental breaches when redacting · ICO · Hidden information in documents · Microsoft · Document Inspector

Chaînes de reprises et veille sociale

Distinguer origine, reprise et corroboration

Une capture ou une signature de provenance peut documenter une pièce sans prouver l’affirmation qu’elle contient. Avant de citer plusieurs publications, vérifier si elles renvoient au même document.

Conserver la version consultée et sa référence exacte.
Nommer les citations absentes plutôt que supposer leur contenu.
Traiter les documents distincts comme des pièces à comparer, sans présumer leur indépendance.

Lire la méthode et explorer les chaînes de reprises →

Government Communications · RESIST 3 · RESIST 3 · 2025 · consulted 2026-10-23

Government Communications · RESIST 3 quick reference · RESIST 3 · 2025 · consulted 2026-10-23

Références officielles

Date de consultation des références : 23/10/2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.