Sachez ce que signifie la flèche
Aussi en 19 langues
English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Chapitre 9 de Data Architect, Partie 2 : Architecturer à grande échelle. Précédent : Architecture des requêtes et de la récupération.
Dans une organisation connectée, la plupart des problèmes de qualité des données arrivent par une intégration. Des doublons dus à une clé manquante. Des valeurs périmées dues à un traitement par lots qui a cessé de tourner sans bruit. Des champs écrasés par un système qui n’était jamais censé les écrire. L’architecte de données n’a pas à construire l’intégration. Mais c’est l’architecte de données qui décide ce qu’elle a le droit de faire aux données.
Image generated with AI. ⟲
Ce chapitre est donc une assiette de dégustation : un avant-goût de l’intégration pour l’architecte de données, le repas complet étant dans le cours Integration Architect. Il reprend là où le chapitre 4 s’était arrêté : chaque flèche du paysage a besoin d’un mécanisme. Maintenant, chaque flèche a besoin d’un sens.
Les idées de ce chapitre
Section intitulée « Les idées de ce chapitre »- Zoom out, then zoom in. Start with the whole landscape, then take one arrow at a time and ask what it means to the data. ⟲
- Sachez ce que prévoit l’architecte d’intégration, même quand quelqu’un d’autre le construit. La forme du trafic change la conception des données.
- Qui lance la conversation, ce n’est pas le sens dans lequel circulent les données, et seul le client voit l’aller-retour complet.
- Freshness is a requirement, not a default. And a database stores; a process calls: polling needs a process, and polling for nothing is waste. ⟲
- Singles, sets or bulk: respect the zeros. Integration volume becomes data volume. ⟲
- One key per record, one-to-one, in an External ID field marked unique. When one customer has several external records, add records, not fields: a hierarchy, peers or a child object (chapter 6), never a key field per system. ⟲
- A key isn’t authority. Integrations write the fields their system owns, not “the Account.” Two-way movement still has one owner per field. ⟲
- Proof of delivery: the client owns the conversation; whoever knows what should arrive proves that it did. Log every call, restart gracefully, retry safely, and send increments, not the universe. ⟲
- Les platform events sont la colonne vertébrale ; l’outbound messaging est hérité, pris en charge mais pas le point de départ des nouvelles conceptions.
- Every important arrow gets a contract, written before the mechanism is chosen, and it outlives the technology. ⟲
Le contrat de données d’intégration
Section intitulée « Le contrat de données d’intégration »Every important arrow gets one, eleven lines: ⟲
| Line | The decision |
|---|---|
| Initiateur | Qui lance la conversation ? |
| Sens des données | Dans quel sens circulent les données métier ? |
| Freshness | How current must the data be, in a number? |
| Volume and shape | How much, and as singles, sets or bulk? |
| Key | How do we identify the same record across systems? |
| Write authority | Which system owns, and may write, which fields? |
| Pattern | Request and reply, fire and forget, batch, or events? |
| Mécanisme | Qu’est-ce qui le met en œuvre ? |
| Proof of delivery | Who proves it arrived, and owns recovery? |
| Sensitivity and travel | How sensitive is the data, and where does it pass through? |
| Change | How does the contract change without breaking the other side? |
Le parcours de ce chapitre
Section intitulée « Le parcours de ce chapitre »Quatre modules, chacun autonome.
- Before the Arrow. Steve Trucking’s landscape, then one arrow: who starts it and which way the data moves, how current, polling or listening, singles, sets and bulk, and what happens when it fails. ⟲
- Keys and Write Ownership. One key per record, upsert and safe retries, add records not fields, field-level authority, and loops. ⟲
- Proof of Delivery. Who proves it arrived, the integration log, restarts and retries, the return receipt, the four shapes and monitoring. ⟲
- The Integration Data Contract. Nine contracts on the landscape, one line by line; requirement, then pattern, then mechanism; the standard API or your own; where the data travels; and when the contract says don’t move it. ⟲
Not moving data at all (Salesforce Connect, mashups, zero copy) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). ⟲
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- What each arrow means: initiator, direction, freshness, volume. ⟲
- Comment les enregistrements restent appariés d’un système à l’autre, et qui peut modifier quels champs.
- Qui prouve l’exhaustivité et répond de la reprise pour chaque mouvement.
- Si les données doivent bouger tout court.
Au-delà de l’examen : chaque chemin de lecture et d’écriture d’un agent est une flèche d’intégration. Un agent qui « met à jour le client » a besoin d’une clé, d’un contrat d’écriture étroit, de nouvelles tentatives sûres et d’observabilité, parce qu’un appelant probabiliste invoque des opérations d’entreprise déterministes. Chaque module se termine par ce que l’IA change.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Salesforce Architects, Data Integration with Salesforce (s'ouvre dans un nouvel onglet) (decision guide), checked 2026-11-01. ⟲
- Salesforce Architects, Integration Patterns (s'ouvre dans un nouvel onglet), checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes (s'ouvre dans un nouvel onglet), Winter ‘27, checked 2026-11-01. ⟲
Suivant : Migration et synchronisation