Une data marketplace, un lieu de rencontre pour quel type d’utilisateurs ?
Les « values brokers » ou « négociateurs internes » ont la capacité d’animer l’organisation d’une data marketplace. Selon Forrester, c’est une plateforme centralisée qui facilite l’échange, l’achat / vente de données entre différentes organisations… elle permet d'accélérer l'innovation, d'améliorer la prise de décision et de réduire les coûts liés à la collecte et à la préparation des données.
Comme on peut le voir dans le tableau ci-dessus, la data marketplace ne se limite pas à l’achat / vente de « données externes » à l’entreprise mais ça doit être avant tout un vecteur de valorisation des savoir-faire internes pour créer de la valeur.
Mais quels types d’utilisateurs va-t-on retrouver autour d’une data marketplace ?
Si un entrepôt de données physique peut être vu comme une « machine à remonter le temps business », comment positionner une data marketplace comme moyen de « réconciliation » des acteurs sur l’axe du temps business ?
Le tableau ci-dessous catégorise les 3 profils d’utilisateurs d’une data marketplace :
Comme on peut le voir dans le tableau ci-dessus, la data marketplace ne se limite pas à l’achat / vente de « données externes » à l’entreprise mais ça doit être avant tout un vecteur de valorisation des savoir-faire internes pour créer de la valeur.
Mais quels types d’utilisateurs va-t-on retrouver autour d’une data marketplace ?
Si un entrepôt de données physique peut être vu comme une « machine à remonter le temps business », comment positionner une data marketplace comme moyen de « réconciliation » des acteurs sur l’axe du temps business ?
Le tableau ci-dessous catégorise les 3 profils d’utilisateurs d’une data marketplace :
Figure 5 : articulation sur l’axe du temps des business drivers, inducteurs et indicateurs.
Les « négociateurs internes » dans une entreprise étendue sont prioritaires à identifier pour le déploiement d’une data marketplace. En tant que maîtrise d’ouvrage de cas d’usage, ils sont à identifier parmi les acteurs de programmes de transformation, des acteurs de l’agilité à l’échelle et en dernier recours aux acteurs de la gouvernance de la donnée. Un principe lean consiste à s’assurer que la data marketplace aide à optimiser l’ensemble d’un processus, de bout en bout, plutôt que d'optimiser des parties individuelles du processus qui peuvent ne pas ajouter de valeur au processus dans son entièreté.
Ils travaillent en collaboration avec les acteurs clefs du processus qui vont apporter agilité et dynamique. Ces acteurs, en tant que « knowledge workers » s’appuient sur des ressources qu’il est intéressant de pérenniser et partager. Dans un environnement business caractérisé par des connaissances imparfaites, des informations incomplètes, une multitude de données et de choix, les décisions que ces acteurs prennent sont limitées par le temps, le coût et les bonnes informations disponibles. Ce sont les premiers utilisateurs des data products car ceux-ci vont leur permettre de résoudre complètement leur problème, ne pas leur faire perdre leur temps en leur fournissant la valeur quand et où ils le souhaitent, tout en réduisant le nombre de décisions à prendre pour résoudre leur problème.
La dernière catégorie d’utilisateurs les « Citizen data » apportent au processus une compétence d’analyse des données et de data science. Ils ont des savoir-faire techniques qui vont permettre de simuler, benchmarker et modéliser le processus en utilisant des datasets internes et externes.
la data marketplace va jouer le rôle de « pourvoyeur » de datasets à valeur.
Ceux-ci sont capitalisés, actualisés et mis à disposition selon des workflows spécifiques au domaine de données. De nouveaux rôles organisationnels vont ainsi apparaître pour gérer ces « actifs » en données.
A différente maille de l’entreprise, ces référentiels doivent être identifiés par les acteurs de la gouvernance des données de par leur capacité à « créer de la valeur » lorsqu’elles sont croisées avec des données d’autres domaines.
Ils travaillent en collaboration avec les acteurs clefs du processus qui vont apporter agilité et dynamique. Ces acteurs, en tant que « knowledge workers » s’appuient sur des ressources qu’il est intéressant de pérenniser et partager. Dans un environnement business caractérisé par des connaissances imparfaites, des informations incomplètes, une multitude de données et de choix, les décisions que ces acteurs prennent sont limitées par le temps, le coût et les bonnes informations disponibles. Ce sont les premiers utilisateurs des data products car ceux-ci vont leur permettre de résoudre complètement leur problème, ne pas leur faire perdre leur temps en leur fournissant la valeur quand et où ils le souhaitent, tout en réduisant le nombre de décisions à prendre pour résoudre leur problème.
La dernière catégorie d’utilisateurs les « Citizen data » apportent au processus une compétence d’analyse des données et de data science. Ils ont des savoir-faire techniques qui vont permettre de simuler, benchmarker et modéliser le processus en utilisant des datasets internes et externes.
la data marketplace va jouer le rôle de « pourvoyeur » de datasets à valeur.
Ceux-ci sont capitalisés, actualisés et mis à disposition selon des workflows spécifiques au domaine de données. De nouveaux rôles organisationnels vont ainsi apparaître pour gérer ces « actifs » en données.
A différente maille de l’entreprise, ces référentiels doivent être identifiés par les acteurs de la gouvernance des données de par leur capacité à « créer de la valeur » lorsqu’elles sont croisées avec des données d’autres domaines.
Figure 6 : positionnement d'une marketplace par rapport à un datawarehouse physique ou logique
Pour terminer, nous rapprochons une data marketplace à la partie implicite de la mémoire épisodique de l’entreprise, celle qui traite les événements business spécifiques et leur contexte. Si la partie explicite est incarnée par l’entrepôt physique et logique, la partie implicite, incarnée par la data marketplace va jouer le rôle de « lien » en mettant en œuvre des interconnections entre acteurs de processus et acteurs d’un domaine de données.
Ces interconnections vont faciliter l'accès à l’information grâce à un « stimulus » préalable qui peuvent être les suivants :
- Les index liés au chainage : ils permettent d'accéder rapidement à des informations spécifiques d’un domaine de données. Ces index permettent de suivre de « bout en bout » l’objet métier grâce au chaînage de l’intégration des données et des processus. L’objet métier sera ainsi analysé tout le long des différents systèmes opérationnels, l’entrepôt physique et logique.
Il est à noter que tous les états d’un objet métier n’apportent pas de la valeur. Il est nécessaire de s’attarder sur les états les plus pertinents pour la mémoire de l’entreprise afin de pouvoir les transformer par la suite en « amorce ».
Les approches de types « hub and spoke » sont des approches permettant de mettre en place cette indexation. Les solutions de type BPM peuvent la mettre en œuvre.
La data marketplace valorise cette indexation qui fait partie des métadonnées.
Ces interconnections vont faciliter l'accès à l’information grâce à un « stimulus » préalable qui peuvent être les suivants :
- Les index liés au chainage : ils permettent d'accéder rapidement à des informations spécifiques d’un domaine de données. Ces index permettent de suivre de « bout en bout » l’objet métier grâce au chaînage de l’intégration des données et des processus. L’objet métier sera ainsi analysé tout le long des différents systèmes opérationnels, l’entrepôt physique et logique.
Il est à noter que tous les états d’un objet métier n’apportent pas de la valeur. Il est nécessaire de s’attarder sur les états les plus pertinents pour la mémoire de l’entreprise afin de pouvoir les transformer par la suite en « amorce ».
Les approches de types « hub and spoke » sont des approches permettant de mettre en place cette indexation. Les solutions de type BPM peuvent la mettre en œuvre.
La data marketplace valorise cette indexation qui fait partie des métadonnées.
- Les méta-données d’un data product et les tags de contexte : Elles servent d'index, de catalogue, et peuvent être considérées comme des amorces pour retrouver les informations pertinentes des produits de données. Les méta-donnés en lien avec le « temps » et la « contextualisation » sont primordiaux pour indexer les produits dans les différents contextes d’utilisation.
Exemples :
o À la date du 01/07/2024, quelles « offres actives » utilisaient le service de support de telle Business Unit et à quel prix ?
o Quelle était l’exposition au risque fournisseur XX en début d’année et quels projets d’offres avaient recours à ce fournisseur au 31/12/2024 ?
o Quels projets d’offres ont été arrêtés ou suspendus sur le 2nd semestre de 2024 ?
o Quel composant d’une offre commerciale abandonnée mérite une évaluation afin d’être réutilisé dans une autre offre ?
Les méta-données dans une data marketplace se distinguent des méta-données d’un datawarehouse logique ou physique : elles sont étendues avec des considérations sur la « valeur apportée » dont l’entreprise souhaite garder « souvenir » pour usage dans d’autres contextes opérationnels. On utilisera ainsi des « marqueurs » ou des « tags » permettant de retrouver les « produits de données » selon des états différents de ceux des processus opérationnels et qui contribuent à la gestion des connaissances.
Si les états du processus opérationnels couvrent le cycle « opérationnel » de l’objet métier, dans la data marketplace, les états « taggués » seront liés aux connaissances qu’on veut « analyser » et « évaluer » avant capitalisation et les connaissances qui ont déjà été « capitalisées ». Les produits de données capitalisés peuvent être vus comme des « cas d’école » pour l’entreprise. Ils sont par la suite actualisés pour des considérations de domaine.
Exemples :
o À la date du 01/01/2024, quelles offres étaient catégorisées dans la catégorie « offre au meilleur P&L / Pertes & Profits », « offre qui a généré le moins de support client » ?
o À la clôture de l’offre commerciale « XXX », que fait-on du bundle « d’offres » ? quel composant est réutilisable pour d’autres offres en cours de préparation ?
- Les schémas de données et la couche sémantique normalisée : la structure organisée des données, définie par des schémas, permet de naviguer efficacement dans l'entrepôt physique et logique. Un schéma bien conçu agit comme un guide, orientant les requêtes vers les informations recherchées. Dans une data marketplace, ils permettent d’inter-relier les data products et leurs différents utilisateurs (producteurs / consommateurs).
Exemples :
o Retrouver grâce à une ontologie structurée en RDF (Resource Description Framework) , tous les risques projets qui sont du même type et qui sont en cours de « mitigation » dans des plans d’actions de BU.
o Retrouver les demandes de supports (SAV) traités en interne ou par un tiers (prestataire) pour une même offre commerciale.
o Pour une Nouvelle Offre (NO) du marché à lancer prochainement, quel est le coût à appliquer au composant « SAV téléphonique » commun à toutes mes nouvelles offres marché de l’année ?
- Les vues virtualisées ou les datamarts : Ce sont des résultats de requêtes pré-calculeés et persistées ou non. Techniquement, elles permettent d'accélérer l'exécution de requêtes fréquemment utilisées, en agissant comme des amorces pour des calculs plus complexes.
Exemple : un type de risques est commun à toutes les BU commerciales. Il est suivi dans plusieurs projets d’offres. Le calcul de sa probabilité d’occurrence est porté en transverse par un seul et unique acteur (risk manager) en charge de sa gestion. Cette responsabilité couvre plusieurs activités du domaine dont son actualisation à fréquence régulière ou sur événement. L’actualisation de l’occurrence va « lancer » l’actualisation de l’exposition de chaque risque dans son contexte et son processus de gestion (exposition = occurrence x impact).
- Les plans d’actions : ils constituent la mémoire des savoir-faire accumulés avec leurs contextes. Ces plans peuvent correspondre à des objectifs business atteints (ou non). Ils peuvent avoir les statuts suivants : « en cours » ou « clôturés » et « capitalisés ».
La data marketplace utilise les éléments d'amorçage (métadonnées, schémas, vues, index et plans d’actions) pour aiguiller une recherche et identifier les données pertinentes. Elle permet ainsi de « naviguer » rapidement dans de gros volumes de données, méta-données et méta-modèles, en étant guidé.
Cela peut être un vecteur pour une « sobriété » en termes de données stockées : à quoi bon stocker toutes les données possibles, si celles-ci n’apportent pas de valeur à l’organisation ? après tout, la vie business d’une entreprise, n’est pas ce qu’elle a vécu mais plutôt ce dont elle se souvient et comment elle s’en souvient . Construire un modèle paramétrique par exemple, en tant que data product, nécessite l’analyse d’une quantité de données « qualifiée » et « pertinente » du point de vue business. C’est le fruit d’un processus itératif et fortement basé sur les retours d’expériences de plusieurs projets.
La data marketplace trouve ainsi toute sa place en tant que mémoire des savoir-faire et les mécanismes d’activation qui permettent d’interpréter différemment les nouvelles informations stockées dans l’entrepôt.
Exemples :
o À la date du 01/07/2024, quelles « offres actives » utilisaient le service de support de telle Business Unit et à quel prix ?
o Quelle était l’exposition au risque fournisseur XX en début d’année et quels projets d’offres avaient recours à ce fournisseur au 31/12/2024 ?
o Quels projets d’offres ont été arrêtés ou suspendus sur le 2nd semestre de 2024 ?
o Quel composant d’une offre commerciale abandonnée mérite une évaluation afin d’être réutilisé dans une autre offre ?
Les méta-données dans une data marketplace se distinguent des méta-données d’un datawarehouse logique ou physique : elles sont étendues avec des considérations sur la « valeur apportée » dont l’entreprise souhaite garder « souvenir » pour usage dans d’autres contextes opérationnels. On utilisera ainsi des « marqueurs » ou des « tags » permettant de retrouver les « produits de données » selon des états différents de ceux des processus opérationnels et qui contribuent à la gestion des connaissances.
Si les états du processus opérationnels couvrent le cycle « opérationnel » de l’objet métier, dans la data marketplace, les états « taggués » seront liés aux connaissances qu’on veut « analyser » et « évaluer » avant capitalisation et les connaissances qui ont déjà été « capitalisées ». Les produits de données capitalisés peuvent être vus comme des « cas d’école » pour l’entreprise. Ils sont par la suite actualisés pour des considérations de domaine.
Exemples :
o À la date du 01/01/2024, quelles offres étaient catégorisées dans la catégorie « offre au meilleur P&L / Pertes & Profits », « offre qui a généré le moins de support client » ?
o À la clôture de l’offre commerciale « XXX », que fait-on du bundle « d’offres » ? quel composant est réutilisable pour d’autres offres en cours de préparation ?
- Les schémas de données et la couche sémantique normalisée : la structure organisée des données, définie par des schémas, permet de naviguer efficacement dans l'entrepôt physique et logique. Un schéma bien conçu agit comme un guide, orientant les requêtes vers les informations recherchées. Dans une data marketplace, ils permettent d’inter-relier les data products et leurs différents utilisateurs (producteurs / consommateurs).
Exemples :
o Retrouver grâce à une ontologie structurée en RDF (Resource Description Framework) , tous les risques projets qui sont du même type et qui sont en cours de « mitigation » dans des plans d’actions de BU.
o Retrouver les demandes de supports (SAV) traités en interne ou par un tiers (prestataire) pour une même offre commerciale.
o Pour une Nouvelle Offre (NO) du marché à lancer prochainement, quel est le coût à appliquer au composant « SAV téléphonique » commun à toutes mes nouvelles offres marché de l’année ?
- Les vues virtualisées ou les datamarts : Ce sont des résultats de requêtes pré-calculeés et persistées ou non. Techniquement, elles permettent d'accélérer l'exécution de requêtes fréquemment utilisées, en agissant comme des amorces pour des calculs plus complexes.
Exemple : un type de risques est commun à toutes les BU commerciales. Il est suivi dans plusieurs projets d’offres. Le calcul de sa probabilité d’occurrence est porté en transverse par un seul et unique acteur (risk manager) en charge de sa gestion. Cette responsabilité couvre plusieurs activités du domaine dont son actualisation à fréquence régulière ou sur événement. L’actualisation de l’occurrence va « lancer » l’actualisation de l’exposition de chaque risque dans son contexte et son processus de gestion (exposition = occurrence x impact).
- Les plans d’actions : ils constituent la mémoire des savoir-faire accumulés avec leurs contextes. Ces plans peuvent correspondre à des objectifs business atteints (ou non). Ils peuvent avoir les statuts suivants : « en cours » ou « clôturés » et « capitalisés ».
La data marketplace utilise les éléments d'amorçage (métadonnées, schémas, vues, index et plans d’actions) pour aiguiller une recherche et identifier les données pertinentes. Elle permet ainsi de « naviguer » rapidement dans de gros volumes de données, méta-données et méta-modèles, en étant guidé.
Cela peut être un vecteur pour une « sobriété » en termes de données stockées : à quoi bon stocker toutes les données possibles, si celles-ci n’apportent pas de valeur à l’organisation ? après tout, la vie business d’une entreprise, n’est pas ce qu’elle a vécu mais plutôt ce dont elle se souvient et comment elle s’en souvient . Construire un modèle paramétrique par exemple, en tant que data product, nécessite l’analyse d’une quantité de données « qualifiée » et « pertinente » du point de vue business. C’est le fruit d’un processus itératif et fortement basé sur les retours d’expériences de plusieurs projets.
La data marketplace trouve ainsi toute sa place en tant que mémoire des savoir-faire et les mécanismes d’activation qui permettent d’interpréter différemment les nouvelles informations stockées dans l’entrepôt.
Figure 7 : types de mémoires dans un datawarehouse
Conclusion : les plateformes EPM (Entreprise Performance Management) ont introduit le chaînage des données, des objets métiers et des processus afin de répondre aux besoins de pilotage stratégique et opérationnel. C’est l’usage business de « bout en bout » qui a poussé à cette transversalité d’usage i.e. la gestion de la performance.
Même si la brique d’intégration des données (ETL/ELT) est une composante structurante de ce type de plateformes, un EPM est avant tout un moyen d’interconnexion entre acteurs de l’organisation et un support aux processus de domaines. Contrôleur de gestion, analyste financier et commissaires aux comptes travaillent sur les mêmes données.
Les data marketplace arrivent avec pour certaines plateformes de puissantes fonctionnalités techniques (ETL/ELT, API et virtualisation). Ces vecteurs d’interaction et d’interopérabilité facilitent la gestion des « actifs de données » de domaines. Elles contribueront ainsi à la gestion des connaissances de l’entreprise. Des fonctionnalités clefs, tels que l’interconnections entre acteurs, l’intégration de processus et les workflows de collaboration inter-domaines permettent de capter la valeur métier en capitalisant les structures sémantiques les plus pertinentes.
La mémoire construite stocke les données d’entrée pertinentes pour un modèle d’apprentissage et de l’IA générative. Au lieu de s’attarder sur l’ensemble des données du domaine (y compris ses données brutes), le modèle s’appuiera sur les données à forte valeur business.
Même si la brique d’intégration des données (ETL/ELT) est une composante structurante de ce type de plateformes, un EPM est avant tout un moyen d’interconnexion entre acteurs de l’organisation et un support aux processus de domaines. Contrôleur de gestion, analyste financier et commissaires aux comptes travaillent sur les mêmes données.
Les data marketplace arrivent avec pour certaines plateformes de puissantes fonctionnalités techniques (ETL/ELT, API et virtualisation). Ces vecteurs d’interaction et d’interopérabilité facilitent la gestion des « actifs de données » de domaines. Elles contribueront ainsi à la gestion des connaissances de l’entreprise. Des fonctionnalités clefs, tels que l’interconnections entre acteurs, l’intégration de processus et les workflows de collaboration inter-domaines permettent de capter la valeur métier en capitalisant les structures sémantiques les plus pertinentes.
La mémoire construite stocke les données d’entrée pertinentes pour un modèle d’apprentissage et de l’IA générative. Au lieu de s’attarder sur l’ensemble des données du domaine (y compris ses données brutes), le modèle s’appuiera sur les données à forte valeur business.
Figure 8 : actifs en données et fréquence des purges de données
Nous terminons cette section par quelques recommandations qui constituent selon nous les piliers d’une démarche réussie de mise en place d’une data marketplace :
- Une data marketplace dédiée à la création de valeur en croisant 3 domaines de données maximum dans un souci de maitrise de la complexité. Partager une représentation commune entre plusieurs domaines nécessite une maturité de processus qui se bâtit au fur et à mesure.
- Une utilisation d’ontologie de domaine robuste interne ou externe. Elle servira à normaliser et uniformiser les descriptions des objets manipulés. La déployer totalement ou en partie peut constituer une transformation à part entière. Le recours à une ontologie business externe a l’avantage de standardiser les processus métiers, les objets manipulés et enfin les data products en mode « entreprise étendue ».
- Une priorisation des « value broker » comme acteurs à identifier et futurs utilisateurs. Les identifier permet de prioriser les data products à valeur pour l’entreprise. Les rendre acteurs de cette transformation est la meilleure garantie de cibler la valeur métier pertinente pour réussir cette transformation. Ils seront les sponsors les plus légitimes d’un cas d’usage à mettre en œuvre.
- Une mise en place de workflows robustes entre acteurs métiers afin d’éviter le phénomène de « data cow-boys » ou des acteurs « francs-tireurs » qui donnent peu visibilité sur l’usage qui est fait des data products et donc de la valeur qui en est tirée pour l’entreprise. La capitalisation des connaissances devient dans ce type de situation un casse-tête autant organisationnel que technique.
- Une optimisation de processus de bout en bout, plutôt que l’optimisation de parties individuelles qui apportent peu de valeur ajoutée au processus dans son entièreté. Optimiser une phase de réponse à appel d’offres en mode « design to cost » permet d’optimiser par ricochet toutes les phases aval d’ingénierie et de management de projets. Construire un référentiel de sous-traitants ou partenaires industriels privilégiés permet de fluidifier et optimiser toutes les phases de sourcing des projets de l’entreprise.
- Une limitation des états à collecter pour les objets structurant un processus. Seuls les états qui vont déclencher des points de synchronisations entre domaines de données dans les représentations communes seront pertinents à collecter.
- Une data marketplace dédiée à la création de valeur en croisant 3 domaines de données maximum dans un souci de maitrise de la complexité. Partager une représentation commune entre plusieurs domaines nécessite une maturité de processus qui se bâtit au fur et à mesure.
- Une utilisation d’ontologie de domaine robuste interne ou externe. Elle servira à normaliser et uniformiser les descriptions des objets manipulés. La déployer totalement ou en partie peut constituer une transformation à part entière. Le recours à une ontologie business externe a l’avantage de standardiser les processus métiers, les objets manipulés et enfin les data products en mode « entreprise étendue ».
- Une priorisation des « value broker » comme acteurs à identifier et futurs utilisateurs. Les identifier permet de prioriser les data products à valeur pour l’entreprise. Les rendre acteurs de cette transformation est la meilleure garantie de cibler la valeur métier pertinente pour réussir cette transformation. Ils seront les sponsors les plus légitimes d’un cas d’usage à mettre en œuvre.
- Une mise en place de workflows robustes entre acteurs métiers afin d’éviter le phénomène de « data cow-boys » ou des acteurs « francs-tireurs » qui donnent peu visibilité sur l’usage qui est fait des data products et donc de la valeur qui en est tirée pour l’entreprise. La capitalisation des connaissances devient dans ce type de situation un casse-tête autant organisationnel que technique.
- Une optimisation de processus de bout en bout, plutôt que l’optimisation de parties individuelles qui apportent peu de valeur ajoutée au processus dans son entièreté. Optimiser une phase de réponse à appel d’offres en mode « design to cost » permet d’optimiser par ricochet toutes les phases aval d’ingénierie et de management de projets. Construire un référentiel de sous-traitants ou partenaires industriels privilégiés permet de fluidifier et optimiser toutes les phases de sourcing des projets de l’entreprise.
- Une limitation des états à collecter pour les objets structurant un processus. Seuls les états qui vont déclencher des points de synchronisations entre domaines de données dans les représentations communes seront pertinents à collecter.
Notes
(5) Le terme amorce vient des sciences cognitives. C'est le fait d’utiliser une information connue (l'amorce) pour retrouver une autre information (le souvenir) qui lui est associée. Les associations de mots, les indices contextuels (lieu, temps, …) ou les manières de mémoriser sont autant d’exemples d’amorces.
(6) Le « hub and spoke » est un pattern d’intégration de données : dans ce modèle d'interaction, tous les systèmes qui souhaitent fournir ou recevoir des données interagissent uniquement avec un système centralisé dans l’entrepôt. Le chaînage de données (et donc de processus) est ainsi consolidé dans l’entrepôt physique.
(7) Resource Description Framework: modèle de graphe permettant de décrire formellement les ressources web et leurs métadonnées afin de permettre le traitement automatique de ces descriptions. Il introduit donc une structuration et une normalisation des données.
(8) La formule est empruntée à Gabriel Garcia Marquez : « La vie n'est pas ce que l'on a vécu, mais ce dont on se souvient et comment on s'en souvient ».
(6) Le « hub and spoke » est un pattern d’intégration de données : dans ce modèle d'interaction, tous les systèmes qui souhaitent fournir ou recevoir des données interagissent uniquement avec un système centralisé dans l’entrepôt. Le chaînage de données (et donc de processus) est ainsi consolidé dans l’entrepôt physique.
(7) Resource Description Framework: modèle de graphe permettant de décrire formellement les ressources web et leurs métadonnées afin de permettre le traitement automatique de ces descriptions. Il introduit donc une structuration et une normalisation des données.
(8) La formule est empruntée à Gabriel Garcia Marquez : « La vie n'est pas ce que l'on a vécu, mais ce dont on se souvient et comment on s'en souvient ».
