Quelle est la Différence Entre Manifest, Report et Finding ? Que Signifient les Termes de Hiérarchie de Données en Architecture Logicielle ? Pourquoi Concevoir une API en Couches ? Comment Diffèrent Metadata, Artifact et Payload !

Sun, 02 Aug 2026 15:08:41 +0800

Avez-vous souvent rencontré des termes tels que Manifest, Report, Finding et Evidence lors de la lecture de documentations API, de rapports de scanners de sécurité ou de journaux de pipelines CI/CD ? Ce ne sont pas des syntaxes propres à un langage de programmation spécifique, mais des termes de hiérarchie de données standardisés dans l’industrie. Que signifient réellement ces termes ?

Concept Clé : Comprendre la Hiérarchie des Données à Travers un « Bilan de Santé »

Nous pouvons les imaginer comme le déroulement d’un bilan de santé à l’hôpital. Ces quatre termes correspondent exactement aux niveaux de données, des résumés de haut niveau aux données brutes au niveau le plus bas.

Terme	Analogie du Bilan de Santé	Explication Correspondante en Architecture Logicielle
`Manifest`	Fiche d’Inscription au Bilan	Déclare les éléments à exécuter, les versions et les configurations d’environnement ; données descriptives.
`Report`	Rapport de Bilan Complet	Résumé complet après exécution, incluant l’état général et les résultats d’audit.
`Finding`	Annotation en Rouge dans le Rapport	Constat spécifique entouré dans le rapport, comme « Hypertension détectée » ou une faille de sécurité.
`Evidence`	Ticket de Données du Tensiomètre	Preuve brute et objective étayant le constat, comme des enregistrements de journaux (logs) ou des mesures.

Ces termes ne sont pas des mots réservés d’un langage de programmation, mais des modèles de données partagés standard de l’industrie.

Nous pouvons utiliser un schéma Mermaid pour illustrer les relations d’inclusion et de flux de données entre ces quatre concepts :

  graph TD
    A["Manifest (Spéc. d'Exécution/Métadonnées)"] -->|Définit le Périmètre et l'Exécution| B["Report (Rapport de Résumé Complet)"]
    B -->|Contient Plusieurs| C["Finding (Constat Spécifique/Observation)"]
    C -->|Associe Plusieurs| D["Evidence (Preuve Brute Objective)"]

Pourquoi Concevoir en Couches ? Les 3 Grands Avantages de la Hiérarchie des Données

Pourquoi découper les données avec autant de détails au lieu de tout placer dans un énorme objet JSON ? Cette conception offre plusieurs avantages majeurs :

Une excellente architecture d’API permet un chargement plus fluide côté frontend et rend les données plus fiables et extensibles.

Avantage	Explication
Séparation des Responsabilités (Separation of Concerns)	Le frontend peut charger d’abord le résumé des `Finding` pour une vue rapide, et n’appeler le lourd `Evidence` que lorsque cela est nécessaire.
Haute Crédibilité	Fournir `Evidence` prouve qu’un `Finding` n’est pas un faux positif, augmentant considérablement l’auditabilité du système.
Extensibilité Flexible	Un seul `Finding` peut être associé de manière flexible à plusieurs `Evidence` sans casser le format de données d’origine.

Autres Termes Courants Complémentaires : Metadata, Artifact et Payload

Outre les quatre niveaux principaux, lors de la conception d’API, de la construction de pipelines ou de la définition de formats de transmission, vous verrez très souvent ces trois termes : Metadata, Artifact et Payload :

Terme	Définition Clé	Analogie de la Vie Réelle	Exemple d’Application Pratique en Architecture Logicielle
`Metadata`	Données décrivant les données elles-mêmes	Étiquette d’expédition sur un colis, données EXIF d’une photo	`HTTP Header`, horodatage `timestamp`, informations de pagination `page`.
`Artifact`	Produit physique généré après un processus	Voiture produite dans une usine, CD de bilan médical	Fichier `.apk` compilé, `Docker Image`, rapport `PDF` d’audit.
`Payload`	Données métier principales réellement transmises	Le smartphone réellement contenu à l’intérieur du colis	Contenu métier `JSON` principal dans le `HTTP POST Body`.

Payload est comme l’objet à l’intérieur du colis, tandis que Metadata est l’étiquette d’expédition collée à l’extérieur.

Pour mieux comprendre comment ces trois concepts collaborent, observons une structure de données API Request typique :

{
  "metadata": {
    "version": "v1.2.0",
    "timestamp": "2026-08-02T15:08:41Z",
    "request_id": "req-98765"
  },
  "payload": {
    "report_id": "REP-2026-001",
    "status": "COMPLETED",
    "artifact_url": "https://example.com/artifacts/build-report.pdf"
  }
}

Dans cet exemple JSON :

metadata fournit le contexte de transmission et d’environnement (version, horodatage, ID de requête).
payload contient les données de logique métier réellement transmises (ID de rapport, statut).
artifact_url pointe vers le fichier physique réel généré par cette tâche de build (Artifact).

Le Pouvoir d’un Vocabulaire Commun : Pont de Communication Entre Systèmes

Lorsque différents outils et équipes adoptent ce modèle de données similaire (Report -> Findings -> Evidence), les coûts de communication inter-équipes diminuent considérablement.

Imaginez que le Report généré par votre outil CI/CD puisse être transmis directement et sans friction au système de sécurité pour analyse — c’est le pouvoir d’intégration d’un langage de domaine partagé.

  sequenceDiagram
    autonumber
    actor CI as CI/CD Pipeline
    participant Scanner as Scanner de Sécurité
    participant Dashboard as Tableau de Bord de Gestion
    
    CI->>Scanner: Fournit le Manifest pour exécuter le scan
    Scanner->>Scanner: Génère le Report et les Findings
    Scanner->>Dashboard: Envoie le Payload structuré (Finding + Evidence)
    Dashboard-->>CI: Affiche les résultats d'audit

Résumé

En réalité, l’objectif de ces termes est de résoudre des problèmes de communication et de structuration des données entre systèmes à grande échelle.