Les types de données de l'entreprise

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 2 sur 6 du chapitre Comprendre les données de l’entreprise, chapitre 4 du cours Data Architect. Chaque module est autonome. Précédent : Salesforce est un système parmi d’autres · Suivant : Les systèmes autour de Salesforce

La question à laquelle répond ce module : quels types de données une entreprise détient-elle, et pourquoi ont-ils leur place à des endroits différents ?

Une fiche client. Une liste de pays. Une commande. Une définition de champ. Cinq ans de totaux de ventes. Quatre millions de photos de livraison. Ce sont toutes des données, mais du point de vue de l’architecture, ce n’est pas la même chose. Elles changent différemment, grossissent différemment, sont utilisées différemment et appartiennent à des personnes différentes, et elles ne devraient pas vivre automatiquement au même endroit. Alors quand quelqu’un dit « il nous faut ces données dans Salesforce », ma question suivante est : de quel type de données s’agit-il ? La réponse commence à me dire quoi en faire.

Commencez par le type, pas par l’objet

En tant que gens de Salesforce, nous traduisons les exigences en structures presque instantanément : client, compte ; photo, fichier ; statut, liste de sélection. C’est utile, à terme. À l’échelle de l’entreprise, je veux d’abord savoir à quel type d’information j’ai affaire. Il existe beaucoup de façons de la classer (le corpus de connaissances DAMA est la référence standard), et je trouve six types utiles : données maîtres, de référence, transactionnelles, métadonnées, analytiques et non structurées. Les catégories ne sont pas l’architecture. Ce sont une manière de poser de meilleures questions.

Les données maîtres : les choses que l’entreprise connaît

Les données maîtres décrivent les éléments durables autour desquels une entreprise fonctionne : clients, produits, tarification, employés, fournisseurs, sites, actifs. Dans une organisation Salesforce dédiée aux ventes, ce sont vos comptes et vos contacts, vos produits et vos catalogues de prix. Chez Steve Trucking, un partenaire distributeur (Retail Partner) est une donnée maître. Keystone n’est pas un événement ; c’est une organisation avec laquelle Steve Trucking entretient une relation durable. Les neuf centres de distribution sont aussi des données maîtres.

Les données maîtres survivent aux transactions qui les utilisent : un seul partenaire distributeur peut avoir des millions de livraisons. La première question à leur sujet est donc toujours qui les possède ? Ce n’est peut-être pas Salesforce. L’ERP peut posséder les produits. Salesforce peut posséder les prospects tandis que l’ERP fait autorité une fois qu’ils sont clients. Une plateforme MDM peut posséder l’identité d’entreprise d’un client assemblée à partir de plusieurs systèmes. Le chapitre 6, Données maîtres et identité, va en profondeur. Pour l’instant, reconnaissez la forme.

Les données de référence : le vocabulaire que l’entreprise partage

Les données de référence sont le vocabulaire contrôlé qui sert à classer d’autres données : codes pays, devises, catégories de produits, codes motif, statuts. Les statuts de livraison de Steve Trucking (planifiée, chargée, en cours de livraison, en approche, livrée, installée, incident, retournée) sont des données de référence. Ce ne sont pas des livraisons ; ce sont les mots qui servent à décrire les livraisons.

Elles paraissent petites et inoffensives, souvent une liste de sélection de huit valeurs. Ne confondez pas petit et sans importance. Si Salesforce dit Delivered, que l’ERP dit Complete et qu’un partenaire distributeur envoie D, quelqu’un doit définir ce que chacun signifie et comment ils se correspondent. Les données de référence sont l’endroit où se cachent les hypothèses d’intégration.

Les données transactionnelles : ce qui s’est passé

Les données transactionnelles enregistrent l’activité : une commande passée, un paiement effectué, une livraison terminée, une requête ouverte. Dans la même organisation de ventes, ce sont les devis et les lignes de devis, les commandes et les articles de commande, les paiements : chacun renvoie à un client et à un produit. Le million de livraisons par an de Steve Trucking est transactionnel, et leurs mises à jour de statut aussi : environ huit par livraison, donc huit millions de changements de statut par an, dans une entreprise qui croît de 30 % par an.

C’est une courbe de croissance complètement différente de celle des données maîtres. Trois partenaires distributeurs en haut ; des millions de lignes en dessous. C’est là que le Nombre de zéros de Steve compte : vous ne pouvez pas regarder Partenaire distributeur → Livraison → Statut et donner le même poids à chaque boîte. Avec les données transactionnelles, je pense immédiatement au volume, à la vélocité, à la conservation, à l’historique, à l’archivage, à l’intégration, et à la façon dont les gens ont réellement besoin de les retrouver. La partie 2 y consacre beaucoup de temps.

Les métadonnées : des données sur les données

Vous travaillez avec des métadonnées depuis le début du cours : la définition d’un objet, le type d’un champ, sa description, ses relations. Toute l’entreprise en a : schémas d’entrepôt de données, mappages d’intégration, catalogues de données, contrats d’API, et pour chaque champ un propriétaire, un niveau de sensibilité, une définition, un lignage et une règle de conservation. Les valeurs sont des données ; la description de leur sens, ce sont des métadonnées. Comme l’a dit le chapitre 3, Flag2__c ne dit rien à personne, et cela compte davantage maintenant que l’IA lit les métadonnées pour comprendre ce que signifient les données.

Les données analytiques : des données fabriquées à partir d’autres données

« Quel est notre taux de ponctualité par partenaire distributeur sur les cinq dernières années ? » n’est pas une transaction. C’est une question analytique, à laquelle on répond en dérivant de nouvelles données à partir de millions de livraisons : pourcentage de ponctualité, taux de dommages, chiffre d’affaires par partenaire, qualité d’installation, tendances des équipes. Et c’est un autre travail. Le répartiteur qui demande « quel est le prochain arrêt du camion 217 ? » n’a pas besoin de parcourir cinq ans d’historique. La direction qui compare cinq ans de ponctualité par région, si. C’est pourquoi les données analytiques vivent généralement dans un entrepôt de données, un lakehouse ou une plateforme analytique conçue pour ce travail. Que Salesforce puisse stocker quelque chose ne fait pas de la plateforme opérationnelle l’endroit où exécuter chaque analyse.

Les données non structurées : ce qui ne tient pas dans des lignes

Documents, PDF, images, audio, vidéo, e-mails, transcriptions, articles de connaissances. Chez Steve Trucking, les photos de livraison : environ quatre par livraison, davantage avec les installations, quatre à cinq millions par an. Une photo n’est pas juste un champ de plus. Elle est volumineuse, elle peut montrer l’intérieur du domicile de quelqu’un, elle a ses propres règles de conservation, et on la recherche différemment, si on la recherche.

Ce type compte davantage chaque année, car l’IA peut désormais faire des choses utiles avec des informations qui restaient hors du modèle structuré. Une transcription est une donnée. Un manuel PDF est une donnée. Une photo d’installation est une donnée. Cela ne veut pas dire qu’elle a sa place dans le cœur de Salesforce. Cela veut dire qu’elle a sa place sur le paysage.

Click to enlarge

Six types, quatre questions chacun. Les réponses changent d’un type à l’autre, et c’est tout l’intérêt.

Le type n’est que la moitié de la question : la charge de travail

Savoir quel type de données nous avons ne suffit pas. Je veux aussi savoir ce que nous en faisons. Trois charges de travail comptent ici, et les confondre produit une mauvaise architecture.

Opérationnelle : faire tourner l’entreprise. Un répartiteur met à jour une livraison, une équipe termine un arrêt, un agent ouvre une requête. Beaucoup de petites lectures et écritures : trouve ceci, mets à jour cela, montre-moi les arrêts du jour. C’est l’OLTP, le traitement transactionnel en ligne, et Salesforce est très bon pour cela ; c’est là que vivent les administrateurs et les développeurs.

Analytique : comprendre l’entreprise. Chaque livraison sur cinq ans, regroupée par partenaire et par centre de distribution, comparée d’une année sur l’autre, jointe à la finance. Là, nous parcourons et agrégeons. C’est l’OLAP, le traitement analytique en ligne, et c’est pour cela que sont conçus les entrepôts de données, les lakehouses et les plateformes d’analytique. Pour le dire simplement : l’organisation fait tourner l’entreprise ; les entrepôts et les lacs l’analysent. Une erreur classique consiste à mettre cette charge sur la plateforme opérationnelle et à être surpris quand les zéros augmentent. Si quelqu’un veut parcourir d’énormes quantités d’historique à répétition, ne le traitez pas comme « juste un rapport de plus ». Demandez-vous si c’est la bonne plateforme. La partie 2 y revient dans Concevoir pour le volume (coming soon) (ne faites pas du cœur votre entrepôt de données), et la partie 3 montre comment les structures analytiques sont construites dans Beyond Relational (coming soon).

En flux : les données en mouvement. Événements, télémétrie, changements de statut, relevés de capteurs. Les camions de Steve Trucking envoient environ 200 000 relevés GPS par jour. Le répartiteur veut savoir où est le camion 217 maintenant. Salesforce doit-il garder chaque relevé minute par minute de chaque camion ? Peut-être pas. « Où est-il maintenant ? » et « quelles étaient les tendances d’efficacité des tournées le trimestre dernier ? » viennent de la même source et mènent à des décisions de stockage complètement différentes.

À quelle vitesse doivent-elles circuler ?

Ensuite, la latence. En cours, je le dis ainsi : le temps réel, c’est attendre à la porte que quelqu’un revienne. Vous l’envoyez et vous restez là, parce que vous ne pouvez pas continuer avant son retour. C’est synchrone. Le quasi temps réel, c’est le regarder partir et passer à autre chose ; quand il revient peu après, vous vous en occupez. C’est asynchrone. Et puis il y a le traitement par lots : personne ne passe la porte un par un. Les données attendent et se déplacent en groupe selon un calendrier : toutes les heures, toutes les quelques heures ou chaque jour. Il y a beaucoup de situations où le traitement par lots suffit, et certaines où ce n’est pas le cas. Savoir lesquelles, c’est le travail. Ces trois-là ne sont pas seulement des termes d’intégration ; ce sont des choix d’architecture.

Prenez l’intégration ERP courante. Un nouveau produit est créé dans l’ERP à 11 h. Les ventes ont-elles vraiment besoin de le vendre avant midi ? J’ai entendu les deux réponses. Certains clients le veulent le plus tôt possible ; d’autres disent : si nous ne vous avons pas encore livré ce SKU, nous ne pouvons pas attendre de vous que vous le vendiez. Donc pour les produits, c’est généralement une fois par jour, parfois plus vite. Les clients, au minimum chaque jour ; j’ai vu toutes les heures et, dans les cas extrêmes, du quasi temps réel. Les commandes, c’est différent : l’exécution doit démarrer, donc quasi temps réel. Le commercial conclut l’affaire et passe à autre chose, et la commande arrive dans l’ERP en quelques secondes à une minute ou deux. Il n’y a pas de latence unique et juste pour « les données de l’entreprise ». Demandez ce dont le métier a réellement besoin, et ne mettez pas tout en temps réel parce que ça fait impressionnant. Le temps réel a un coût.

Les quatre questions derrière les catégories

Vous n’avez pas besoin de vous promener en annonçant « ce sont des données transactionnelles ! » La classification est là pour déclencher quatre questions sur chaque jeu de données important :

• Qui les possède ? Quel système fait autorité ? Je le décompose en trois : où sont-elles créées, où sont-elles modifiées, et où sont-elles référencées ? Le chapitre 6 approfondit ces questions (Créé, modifié, référencé, et à quelle vitesse ?).
• À quelle vitesse changent-elles ? Une fois par an, chaque jour, des dizaines à des centaines de fois par seconde ?
• Quelle taille atteignent-elles ? Dix enregistrements, dix mille, dix millions, dix milliards ?
• Quel est leur cycle de vie ? Vivent-elles pour toujours, sont-elles archivées, doivent-elles être supprimées, perdent-elles de la valeur avec le temps ?

Ces quatre questions m’en disent bien plus que « Salesforce peut-il stocker cela ? » Et elles rassemblent ce que nous avons déjà appris : la propriété, le cycle de vie, le Nombre de zéros, l’endroit où vivent les données.

Une seule entreprise produit tous les types

Chez Steve Trucking, le partenaire distributeur est une donnée maître ; le vocabulaire des statuts, une donnée de référence ; chaque livraison est transactionnelle ; les définitions de ses champs sont des métadonnées ; le tableau de bord de ponctualité sur cinq ans est analytique ; la photo d’installation est non structurée ; et le flux GPS est en flux continu. Tout cela, ce sont « les données de Steve Trucking ». Rien de cela ne veut dire qu’elles ont leur place dans la même base de données. C’est ça, le changement.

Au-delà de l’examen : ce que l’IA change. Pour répondre à une seule question, un agent peut avoir besoin d’une fiche client structurée, d’une transaction récente, d’un manuel PDF, d’une transcription de service et de télémétrie en direct. Les données non structurées et en flux deviennent des éléments à part entière de l’architecture même quand elles n’ont pas leur place dans la base de données du CRM, et l’architecte doit toujours savoir qui possède chaque source, à quel point elle est à jour, et si l’agent doit s’y fier.

Ce qu’un architecte décide ici

• De quel type est chaque jeu de données important, et qui le possède.
• Si sa charge de travail est opérationnelle, analytique, en flux, ou un mélange.
• À quelle vitesse il change, et à quelle vitesse les autres systèmes ont vraiment besoin de voir le changement.
• Comment le volume et le cycle de vie déterminent où il vit et pour combien de temps.
• Si Salesforce doit le posséder, en garder une copie, le référencer, ou le laisser ailleurs, dans un endroit mieux adapté à la charge de travail.

Quand quelqu’un vous remet une exigence, ne sautez pas à quel objet, quel champ, quelle API. Demandez d’abord de quel type de données il s’agit, qui les possède, à quelle vitesse elles changent, quelle taille elles atteignent, combien de temps elles vivent, et ce que nous essayons d’en faire. Un compte, un événement de livraison, un agrégat sur cinq ans et une photographie peuvent tous compter pour la même entreprise sans être le même problème d’architecture.

Pour aller plus loin

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2e édition (2017) : la référence standard pour les catégories de données et la gestion des données.
• Le dossier Steve Trucking (en anglais), section 4 (volumes).