# architect Guides de décision (decision-guides) - Full Documentation

<!-- document id=131d947fb96c814b5e17110d9ea27007bcc210d4520294b1728786b2fefd0a79 url=/architect/current/fr-fr/decision-guides/guides/event-driven.md -->

# Utilisation des outils et schémas appropriés pour les architectures pilotées par les événements

Les architectures pilotées par l'événement prennent en charge la production et la consommation efficaces d'événements, qui communiquent les changements d'état du système ou de l'application. Ces architectures permettent des connexions flexibles entre les systèmes, et prennent en charge les processus et les mises à jour en temps quasi réel qui fonctionnent entre les systèmes. Les avantages des architectures pilotées par l'événement sont faciles à voir, mais les détails d'implémentation ne sont pas toujours aussi clairs. Quelles capacités devez-vous prendre en compte dans les modèles architecturaux pilotés par l'événement ? Quels problèmes spécifiques ces modèles résolvent-ils ? Quelles considérations particulières s'appliquent à vos solutions et quels sont les modèles optimaux pour les résoudre ?

## Présentation du guide

Ce guide présente les modèles utilisés pour élaborer des architectures pilotées par les événements optimales lors de l'utilisation de technologies Salesforce. Il traite également des outils d'événements disponibles dans Salesforce et fournit des recommandations d'outils pour une sélection de cas d'utilisation. Pour plus d'informations sur les intégrations au niveau des données impliquant Salesforce, consultez notre [Data Integration Decision Guide](/docs/architect/fr-fr/decision-guides/guide/data-integration).

## Points à retenir

- **Utilisez des architectures pilotées par l'événement pour les processus qui ne nécessitent pas de réponses synchrones aux requêtes.** Les schémas présentés dans ce guide sont conçus pour la cohérence, l'évolutivité et la réutilisation des données, ce qui permet de réduire au minimum les dettes techniques à mesure que le paysage applicatif de votre organisation évolue. (Pour plus d'informations, consultez [Bien archivé - Fiabilité](/docs/architect/fr-fr/well-architected/guide/reliability.html)).

- **Si MuleSoft ou une autre solution Enterprise Service Bus (ESB) fait partie de votre paysage existant, utilisez-la dans la mesure du possible.** Ces solutions sont spécialement conçues pour prendre en charge les modèles d'architecture pilotée par l'événement et offrent de puissantes capacités qui permettent de réutiliser les intégrations dans votre entreprise.

- **Utilisez l'API Pub/Sub pour les futurs modèles de publication/abonnement au lieu d'élaborer vos propres gestionnaires d'événements en utilisant d'autres API, notamment l'API Streaming.** L'API Pub/Sub étant désormais globalement disponible, utilisez-la pour tous les nouveaux modèles de publication/abonnement. Planifiez la migration des communications d'événements existantes en utilisant d'autres API de plate-forme, telles que l'API Streaming ou des services Apex personnalisés, vers l'API Pub/Sub lorsque cela est possible.

- **Les événements de plate-forme et la Capture des données de modification (CDC) sont les mécanismes privilégiés pour publier les modifications des enregistrements et des champs qui doivent être consommés par d'autres systèmes.** Nous recommandons de ne pas utiliser PushTopic et des événements génériques pour les nouvelles implémentations. Salesforce continuera de prendre en charge PushTopic et les événements génériques dans les limites des capacités fonctionnelles actuelles, mais n'envisage pas d'autres investissements dans cette technologie.

## Produits concernés

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Platform</a> est une plate-forme complète pilotée par l’IA qui unifie les employés, les agents IA autonomes, les données de l’entreprise et les applications dans un système unique et de confiance pour améliorer la productivité et l’expérience client. Il permet la création d'une "entreprise agentique" en connectant les applications Customer 360, Data Cloud, et Slack pour une automatisation de bout en bout.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: MuleSoft logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/mulesoft-new.png" alt="MuleSoft"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/mulesoft/">MuleSoft</a> est la plate-forme d'intégration leader de Salesforce qui permet aux organisations de connecter des applications, des données et des appareils à travers des environnements sur site et cloud. MuleSoft est une plate-forme qui fournit aux TI les plates-formes nécessaires pour déverrouiller les données entre les systèmes, développer des infrastructures d'intégration et d'automatisation évolutives, et créer rapidement des expériences connectées différenciées.</td>
    </tr>
  </tbody>
</table>

## Points de décision

Les architectures pilotées par l'événement (EDA) sont recommandées pour les scénarios qui nécessitent des notifications en temps quasi réel, la distribution de la charge de traitement pour les messages à haut volume ou complexes, et l'intégration de systèmes tels que l'Internet des objets et les appareils mobiles qui nécessitent une résilience de la connectivité via la mise en file d'attente. Cependant, les AED ne devraient pas être mises en oeuvre pour des processus qui nécessitent des réponses humaines immédiates et synchrones, car elles sont conçues pour une exécution asynchrone. Elles ne conviennent pas non plus si les données sources changent si rarement qu'un schéma plus simple, tel que le traitement par lot, suffit.

### Quand utiliser une architecture pilotée par l'événement

Voici plusieurs scénarios courants qui conviennent souvent à une architecture pilotée par l'événement :

<table style="width:100%">
<thead>
<tr><th scope="col">Point de décision</th><th scope="col">Guide</th></tr>
</thead>
<tbody>
<tr><td><strong>Notifications en temps quasi réel</strong></td><td>Les modèles d'architecture pilotée par l'événement, tels que publier/s'abonner, fanout et streaming, fonctionnent généralement bien dans les scénarios où plusieurs applications doivent être notifiées en temps quasi réel des changements de statut ou des mises à jour d'enregistrement.</td></tr>
<tr><td><strong>Traitement parallèle</strong></td><td>Les modèles tels que publier/s'abonner fonctionnent généralement bien dans les scénarios où des volumes de données importants ou des messages très complexes nécessitent de distribuer la charge de traitement entre plusieurs systèmes.</td></tr>
<tr><td><strong>Lectures à haut volume</strong></td><td>Les modèles Messages transmis et File d'attente sont fréquemment utilisés dans les situations où les organisations subissent des augmentations et où le volume de messages produits peut dépasser la capacité des abonnés à les traiter immédiatement.</td></tr>
<tr><td><strong>Écritures à haut volume</strong></td><td>Les schémas Streaming et Queuing fonctionnent bien dans de nombreux scénarios où les organisations subissent une augmentation du nombre de messages produits.</td></tr>
<tr><td><strong>Envoi des mêmes données à différents systèmes</strong></td><td>Bien que publier/s'abonner tende à être une solution assez courante pour les organisations qui doivent envoyer les mêmes données à plusieurs systèmes, elle peut être traitée par la plupart des modèles couverts ici. Assurez-vous de les examiner en détail pour trouver le meilleur ajustement.</td></tr>
<tr><td><strong>Introduction fréquente de nouveaux systèmes ou dispositifs</strong></td><td>Les schémas Publier/S'abonner, Streaming et File d'attente fonctionnent généralement bien dans les scénarios où le paysage global tend à évoluer, avec de nouveaux systèmes et appareils ajoutés régulièrement. Dans ce scénario, un nouveau système ou appareil doit simplement devenir abonné au bus d'événement ou associé à une file d'attente, pour commencer à recevoir des messages plutôt que de demander une intégration point à point personnalisée.</td></tr>
<tr><td><strong>Appareils IoT</strong></td><td>Les appareils Internet des objets fournissent généralement des mises à jour fréquentes et peuvent également générer une augmentation des messages dans certains scénarios. Par conséquent, les modèles Streaming et Queuing fonctionnent généralement bien lors de leur intégration dans un paysage informatique.</td></tr>
<tr><td><strong>Appareils et systèmes mobiles hors ligne</strong></td><td>Les appareils mobiles qui doivent travailler dans des zones avec un accès Internet de faible qualité ou inexistant, ou des systèmes qui peuvent être hors ligne au moment de la remise des messages, bénéficieront du modèle Queuing, qui leur permet de se connecter à leurs files d'attente et de récupérer tous les messages pertinents une fois de retour en ligne.</td></tr>
</tbody>
</table>

La plupart des grandes organisations ont des paysages informatiques complexes qui combinent des systèmes avec différentes capacités. Il est possible, ou peut-être probable, que votre organisation ait des systèmes hérités qui ne prennent pas en charge les intégrations pilotées par l'événement. Vous pouvez également avoir des cas d'utilisation où les intégrations pilotées par l'événement ne sont pas logiques, même si les systèmes les prennent en charge (par exemple, les transferts de fichiers SFTP de tiers). Si vous prenez un peu de recul et examinez le paysage informatique de votre organisation dans son ensemble, il est probable que, comme avec d'autres solutions architecturales, vous emploierez une combinaison de modèles pour prendre en charge différents scénarios. Lorsque vous choisissez de définir l'approche pilotée par l'événement comme votre approche préférée des intégrations, considérez-la comme un autre outil dans votre boîte à outils. Elle peut et doit être utilisée dans les scénarios appropriés, mais ce n'est pas une approche à imposer à chaque système. Le développement d'une stratégie d'intégration complète vous aidera à déterminer quand les modèles décrits dans ce guide peuvent être appropriés ou non.

### Quand ne pas utiliser une architecture pilotée par l'événement

De nombreux scénarios font appel à des architectures pilotées par l'événement, et dans certains cas, les architectures pilotées par l'événement fonctionnent même si elles ne sont pas adaptées. Cependant, dans certains scénarios, les architectures pilotées par l'événement ne doivent tout simplement pas être utilisées. Voici quelques questions de point de décision pour vous aider à identifier les scénarios suivants :

<table style="width:100%">
<thead>
<tr><th scope="col">Point de décision</th><th scope="col">Guide/Questions à poser</th></tr>
</thead>
<tbody>
<tr><td><strong>Exigences métier</strong></td><td>Existe-t-il un réel besoin métier pour l'une des fonctionnalités décrites dans la section [Quand utiliser une architecture pilotée par un événement] (#quand-utiliser-une-architecture-pilotée-par-un-événement) ?</td></tr>
<tr><td><strong>Exigences techniques</strong></td><td>L'intégration que vous concevez correspond-elle à un schéma différent, par exemple virtualisation des données, lot ou requête/réponse ? En d'autres termes, essayez-vous d'insérer une cheville carrée dans un trou rond ?</td></tr>
<tr><td><strong>Processus exigeant que les humains attendent des réponses</strong></td><td>Toute intégration impliquant un humain attendant une réponse du système cible n'est pas adaptée aux architectures pilotées par l'événement, car elles sont conçues pour une exécution asynchrone et ne peuvent pas garantir un temps de réponse. Déterminez si de tels processus sont optimaux pour votre organisation avant d'implémenter des solutions techniques. Pour plus d'informations, consultez [Bien archivé - Excellence opérationnelle](/docs/architect/fr-fr/well-architected/guide/operational-excellence.html).</td></tr>
<tr><td><strong>Données sources rarement modifiées</strong></td><td>Si les données de votre système source changent si rarement que les mises à jour périodiques sont suffisantes, vous pouvez probablement simplifier votre architecture en utilisant [batch patterns] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) au lieu de modèles pilotés par l'événement.</td></tr>
<tr><td><strong>Exigences de mise en œuvre</strong></td><td>La majorité des systèmes impliqués dans votre solution prennent-ils en charge les architectures pilotées par les événements ? Que faudrait-il pour utiliser des architectures pilotées par l'événement avec les systèmes qui ne les prennent pas en charge (par exemple, mises à niveau, personnalisations ou middleware) ? Quel niveau d'effort serait nécessaire pour satisfaire à ces exigences?</td></tr>
<tr><td><strong>Stabilité de la structure du message</strong></td><td>À quelle fréquence vos structures de messages doivent-elles changer ? Quels systèmes seront touchés par un tel changement et quel sera le processus de remédiation ?</td></tr>
<tr><td><strong>Gouvernance organisationnelle</strong></td><td>Avez-vous mis en place une structure de gouvernance pour vous assurer que toutes les parties prenantes sont informées des changements apportés aux structures de messages, aux déclencheurs et à d'autres décisions liées à l'architecture et aux processus, et qu'elles sont en mesure d'y contribuer ?</td></tr>
<tr><td><strong>Compétences requises</strong></td><td>Votre personnel a-t-il de l'expérience avec les architectures pilotées par les événements et saura-t-il comment les prendre en charge ?</td></tr>
</tbody>
</table>

## Cas d'utilisation

Il existe divers modèles d'architectures pilotées par les événements. Certains modèles à usage général peuvent être appliqués dans des cas d'utilisation qui n'ont pas d'exigences particulières en plus d'être pilotés par l'événement. Par exemple, consultez [Bien archivé - Fiabilité](/docs/architect/fr-fr/well-architected/guide/reliability.html). D'autres modèles s'appliquent aux cas d'utilisation spécifiques discutés ici, tels que les intégrations impliquant des volumes de données importants ou les scénarios qui nécessitent une rétention plus longue des messages.

### Modèles en un coup d'œil

Le tableau ci-dessous compare les attributs des modèles décrits dans ce document. Utilisez-le comme référence rapide lorsque vous devez identifier des modèles potentiels pour un cas d'utilisation donné.

<table style="width:100%">
<thead>
<tr><th scope="col">Modèle</th><th scope="col">Temps quasi réel</th><th scope="col">Copie de message unique</th><th scope="col">Garantie de livraison</th><th scope="col">Réduire la taille du message</th><th scope="col">Transformer les données</th></tr>
</thead>
<tbody>
<tr><td>Publier / S'abonner</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Fanout</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Messages transmis</td><td>✓</td><td></td><td>✓</td><td>✓</td><td>✓</td></tr>
<tr><td>Streaming</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Mise en file d'attente</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
</tbody>
</table>

### Outils pour l'architecture pilotée par les événements

Salesforce offre plusieurs outils pour vous aider à gérer vos cas d'utilisation pilotés par les événements. Le tableau ci-dessous présente une vue d'ensemble des outils disponibles.

<table style="width:100%">
<thead>
<tr><th scope="col"></th><th scope="col">Outil</th><th scope="col">Description</th><th scope="col">Compétences requises</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Plate-forme qui active l'intégration de données en utilisant des couches d'API.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connecteur Salesforce Pub/Sub</a></td><td>Connecteur pour l'API Pub/Sub, qui fournit une interface unique de publication et d'abonnement aux événements de plate-forme, aux événements de surveillance des événements en temps réel et aux événements de capture des données de modification.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">Connecteur MuleSoft Anypoint JMS</a></td><td>Connecteur qui permet d'envoyer et de recevoir des messages dans des files d'attente et des rubriques pour n'importe quel service de messagerie qui implémente la spécification Java Message Service (JMS).</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">Connecteur MuleSoft Anypoint Apache Kafka</a></td><td>Connecteur permettant de déplacer des données entre Apache Kafka et des applications et services d'entreprise.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Connecteur MuleSoft Anypoint Solace</a></td><td>Un connecteur pour les courtiers d'événements Solace PubSub+ avec une intégration d'API native utilisant le kit de développement Java JCSMP</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connecteur MuleSoft Anypoint MQ</a></td><td>Un service de messagerie cloud multilocataire qui permet aux clients d'effectuer une messagerie asynchrone avancée entre leurs applications.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connecteur MQTT MuleSoft Anypoint</a></td><td>Une extension MuleSoft conforme au protocole MQTT (Message Queuing Telemetry Transport) v3.x.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connecteur MuleSoft Anypoint AMQP</a></td><td>Un connecteur qui permet à votre application de publier et de consommer des messages en utilisant un courtier conforme AMQP 0.9.1.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">API MuleSoft Anypoint Event-Driven (ASync)</a></td><td>Langage agnostique du secteur d'activité qui prend en charge la publication d'API pilotées par l'événement en les séparant en couches événement, canal et transport.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Service de messagerie cloud multitenant qui permet aux clients d'effectuer une messagerie asynchrone avancée entre leurs applications.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">Flux de données MuleSoft Anypoint</a></td><td>Infrastructure disponible dans MuleSoft Anypoint pour la publication et l'abonnement à des données en continu.</td><td>Pro-code</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka sur Heroku</a></td><td>Complément Heroku qui fournit Apache Kafka en tant que service avec une intégration complète de la plate-forme à la plate-forme Heroku.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Capture de données de modification</a></td><td>Journal des événements de modification, qui publie les modifications apportées aux enregistrements Salesforce. Les modifications comprennent la création d'un enregistrement, la mise à jour d'un enregistrement existant, la suppression d'un enregistrement et l'annulation de la suppression d'un enregistrement.</td><td>Du low-code au pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Messages sortants</a></td><td>Actions qui envoient des messages XML à des points de terminaison externes lorsque les valeurs de champ sont mises à jour dans Salesforce.</td><td>Code faible</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Événements de plate-forme</a></td><td>Messages sécurisés et évolutifs contenant des données d'événement personnalisées.</td><td>Du low-code au pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>API qui active les abonnements aux événements de plate-forme, aux événements Capture des données de modification et/ou aux événements Surveillance des événements en temps réel.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relais d'événements</a></td><td>Permet l'envoi d'événements de plate-forme et d'événements de capture des données de modification depuis Salesforce vers Amazon EventBridge. Notez que les relais d'événements se connectent uniquement à AWS Eventbridge.</td><td>Code faible</td></tr>
<tr><th scope="row"></th><td></td><td></td><td></td></tr>
</tbody>
</table>

### Publication/Abonnement

Lorsqu'un enregistrement critique change d'état dans une application principale (par exemple, le statut d'une commande passe de « Traitement » à « Expédié »), plusieurs autres systèmes nécessitent probablement une notification en temps quasi réel pour effectuer leurs tâches respectives. Un besoin métier spécifique survient lorsque le volume de ces changements est élevé et que les messages sont complexes, ce qui rend les intégrations point à point traditionnelles difficiles à gérer. L'établissement de connexions fragiles et personnalisées pour chaque application dépendante entraîne une dette technique et empêche l'organisation d'évoluer rapidement. Une approche d'intégration robuste est nécessaire pour gérer ces synchronisations de données fréquentes sans coupler le système source directement à chaque système consommateur.

#### Le modèle Publier/S'abonner

Le diagramme ci-dessous montre un modèle typique de publication/abonnement avec plusieurs éditeurs et abonnés qui partagent des données via un bus d'événement. Ce schéma de base constitue la base des schémas plus spécifiques que l'on peut trouver dans le reste de ce guide. Voici quelques caractéristiques clés de ce modèle :

- Il n'existe aucun lien direct entre les éditeurs et les abonnés. Les éditeurs envoient simplement des messages à un bus d'événement, qui les diffuse vers tout autre système qui souhaite les écouter.

- Le même système peut être à la fois éditeur et abonné.

- Les systèmes peuvent publier ou s'abonner à plusieurs types d'événement.

- Comme avec tous les modèles de ce guide, le modèle publier/s'abonner appartient à une catégorie générale de modèle d'intégration appelée invocation de procédure à distance (RPI) ou simplement [« virer et oublier ».](/docs/architect/fr-fr/fundamentals/guide/integration-patterns#invocation-de-processus-distant--lancer-et-oublier)

<!-- Image: Publish/subscribe pattern diagram (Level 2) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Publish - Subscribe L2.png" alt="Ce diagramme de niveau 2 montre un exemple de modèle Publier / S&apos;abonner qui inclut plusieurs éditeurs, plusieurs abonnés et plusieurs événements livrés via des canaux dans un bus d&apos;événement. Dans ce modèle, le même système peut être à la fois un éditeur et un abonné et un système peut s&apos;abonner à plusieurs événements.">

#### Outils relatifs au modèle publier/s'abonner

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flux et comportement des événements</th><th colspan="2" scope="colgroup">Considérations relatives à la charge utile</th></tr>
<tr><th scope="col">Outils disponibles</th><th scope="col"></th><th scope="col">Compétences requises</th><th scope="col">Publier via</th><th scope="col">S'abonner via</th><th scope="col">Période de relecture</th><th scope="col">Structure de la charge utile</th><th scope="col">Limites de charge utile</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connecteur Salesforce Pub/Sub</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">Connecteur MuleSoft Anypoint JMS</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">Connecteur MuleSoft Anypoint Apache Kafka</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Connecteur MuleSoft Anypoint Solace</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connecteur MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connecteur MQTT MuleSoft Anypoint</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connecteur MuleSoft Anypoint AMQP</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">MuleSoft Anypoint Event-Driven (ASync) API</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka sur Heroku</a></td><td>Pro-code</td><td>APIs, modifications des enregistrements dans Heroku Postgres</td><td>S.O.</td><td>1 à 6 semaines</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Capture des données de modification</a></td><td>Du low-code au pro-code</td><td>Modifications d'enregistrement</td><td>Apex, APIs, Composants Web Lightning (LWC)</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Prédéfini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Messages sortants*</a></td><td>Code faible</td><td>Règles de flux et de workflow</td><td>S.O.</td><td>24 heures</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_wsdl.htm">Utilisateur défini</a></td><td>100 notifications par message</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Événements de plate-forme</a></td><td>Du low-code au pro-code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Utilisateur défini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>API Pub/Sub ou APIs, Apex, Flow</td><td>API Pub/Sub</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Utilisateur défini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relais d'événements**</a></td><td>Code faible</td><td>Événements de plate-forme, Capture des données de modification</td><td>API</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Utilisateur défini</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Salesforce continuera de prendre en charge les messages sortants dans les limites des capacités fonctionnelles actuelles, mais n'envisage pas d'autres investissements dans cette technologie. **Les relais d'événements se connectent uniquement à AWS Eventbridge</td></tr>
</tbody>
</table>

### Fanout

Lorsqu'une organisation doit envoyer des mises à jour instantanées à un grand nombre d'applications clientes, par exemple des notifications push ou des SMS sur des appareils mobiles, le processus traditionnel de création de transmissions uniques pour chaque destinataire devient rapidement un obstacle à l'évolutivité. Dans ce cas, le besoin métier principal est la distribution rapide et performante d'un seul élément d'information, par exemple une alerte de compte ou un avis de changement de service critique, simultanément à de nombreuses applications de point de terminaison. Une approche rationalisée pour satisfaire à cette exigence consiste à acheminer tous les messages à travers une file d'attente unique, qui agit comme le point central des informations sur les événements pour tous les systèmes consommateurs. Cette approche améliore les performances en éliminant la nécessité de gérer de nombreuses copies de messages séparées.

#### Le modèle Fanout

Avec le modèle fanout, les messages sont livrés à une ou plusieurs destinations (c'est-à-dire des clients ou des abonnés à l'écoute) via une file d'attente de messages unique. Les abonnés récupèrent le même message dans la file d'attente, plutôt que leur propre copie unique. (Notez que même si cela améliore les performances, il peut également être plus difficile de vérifier si un abonné particulier a reçu ou non le message).

<!-- Image: Fanout pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Fanout L3.png" alt="Ce diagramme de documentation et d&apos;implémentation de niveau 3 montre un exemple de schéma de fanout. Il montre un événement publié et écrit dans une file d&apos;attente unique lorsqu&apos;un enregistrement est modifié via une interaction utilisateur, un flux ou une tâche par lot. Le système abonné a plusieurs services qui reçoivent le même événement de la file d&apos;attente des messages.">

#### Outils relatifs au modèle fanout

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flux et comportement des événements</th><th colspan="2" scope="colgroup">Considérations relatives à la charge utile</th></tr>
<tr><th scope="col">Outils disponibles</th><th scope="col"></th><th scope="col">Compétences requises</th><th scope="col">Publier via</th><th scope="col">S'abonner via</th><th scope="col">Période de relecture</th><th scope="col">Structure de la charge utile</th><th scope="col">Limites de charge utile</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">Connecteur MuleSoft Anypoint JMS</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connecteur Salesforce Pub/Sub</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">Connecteur MuleSoft Anypoint Apache Kafka</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Connecteur MuleSoft Anypoint Solace</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connecteur MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connecteur MQTT MuleSoft Anypoint</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connecteur MuleSoft Anypoint AMQP</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Utilisateur défini</a></td><td>Aucun</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka sur Heroku</a></td><td>Pro-code</td><td>APIs, modifications des enregistrements dans Heroku Postgres</td><td>S.O.</td><td>1 à 6 semaines</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Utilisateur défini</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Utilisateur défini</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Capture des données de modification</a></td><td>Du low-code au pro-code</td><td>Modifications d'enregistrement</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Prédéfini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Événements de plate-forme</a></td><td>Du low-code au pro-code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Utilisateur défini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Pro-code</td><td>Pub/Sub API ou Apex, APIs, Flow</td><td>API Pub/Sub</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Utilisateur défini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relais d'événements*</a></td><td>Code faible</td><td>Événements de plate-forme, Capture des données de modification</td><td>API</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Utilisateur défini</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Les relais d'événements envoient uniquement des données à AWS Eventbridge</td></tr>
</tbody>
</table>

### Messages transmis

Certains scénarios d'événement sont caractérisés par un afflux important de volume de messages qui menace de submerger la capacité des processus de synchronisation et de transformation, ou par une logique complexe à plusieurs étapes requise pour traiter et transformer les données d'événements.

Voici quelques exemples :

- **Pics de volume saisonniers :** Il peut y avoir des pics de volume que les détaillants en ligne connaissent lorsqu'une sélection de leurs produits sont « en saison ». Lorsqu'un grand nombre de clients effectuent des achats en même temps, le nombre d'événements générés peut temporairement dépasser la capacité des processus de synchronisation et de transformation. Pour plus d'informations, consultez [Bien archivé - Fiabilité](/docs/architect/fr-fr/well-architected/guide/reliability.html#scalability-and-capacity-planning).

- **Gestion des cas ou des réclamations :** Les entreprises de services peuvent connaître une augmentation du nombre de dossiers ou de réclamations lors de pannes.

- **Transformations de données complexes :** Les organisations qui nécessitent une logique complexe pour transformer les messages craignent souvent que les événements soient générés plus rapidement qu'ils ne peuvent être transformés.

#### Le modèle de messages transmis

Ce schéma répond au défi de générer des messages plus rapidement qu'ils ne peuvent être transformés. Il garantit que les volumes importants de messages et les manipulations de données requises peuvent être traités de façon fiable, en incorporant une plate-forme de messagerie en continu et en segmentant la logique de traitement des messages dans des composants dédiés.

Le modèle Messages transmis fonctionne en segmentant la logique de traitement des messages en plusieurs composants :

- Un composant gère l'acheminement des messages, détermine les transformations requises et la destination finale.

- Un ensemble séparé de composants gère différentes couches de transformation de message (par exemple, mappages de champs, relations d'objet, etc.).

- Le dernier composant écrit le message final modifié.

<!-- Image: Passed messages pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Passed Messages L3.png" alt="Ce diagramme de documentation et d&apos;implémentation de niveau 3 montre un exemple de flux de processus pour le modèle de messages transmis qui comprend un éditeur, un abonné et un message. Le message est divisé en plusieurs parties, qui sont transformées individuellement, puis réassemblées avant d&apos;être envoyées à l&apos;abonné.">

#### Outils relatifs au modèle de messages transmis

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flux et comportement des événements</th><th colspan="2" scope="colgroup">Considérations relatives à la charge utile</th></tr>
<tr><th scope="col">Outils disponibles</th><th scope="col"></th><th scope="col">Compétences requises</th><th scope="col">Publier via</th><th scope="col">S'abonner via</th><th scope="col">Période de relecture</th><th scope="col">Structure de la charge utile</th><th scope="col">Limites de charge utile</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">Connecteur MuleSoft Anypoint Apache Kafka</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connecteur Salesforce Pub/Sub</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka sur Heroku</a></td><td>Pro-code</td><td>API, changements d'enregistrement dans Heroku Postgres</td><td>S.O.</td><td>1 à 6 semaines</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Capture des données de modification</a></td><td>Du low-code au pro-code</td><td>Modifications d'enregistrement</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Prédéfini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Événements de plate-forme</a></td><td>Du low-code au pro-code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Défini par l'utilisateur</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Pro-code</td><td>API Pub/Sub ou APIs, Apex, Flow</td><td>API Pub/Sub</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Défini par l'utilisateur</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relais d'événements*</a></td><td>Code faible</td><td>Événements de plate-forme, Capture des données de modification</td><td>API</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Défini par l'utilisateur</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Les relais d'événements envoient uniquement des données à AWS Eventbridge</td></tr>
</tbody>
</table>

### Streaming

Certains producteurs génèrent un flux continu d'événements. Un exemple courant est le streaming média, qui implique des interactions utilisateur qui se produisent naturellement sous forme d'événements discrets. Plusieurs systèmes doivent réagir simultanément au même comportement des utilisateurs sans bloquer l'expérience principale de diffusion en continu.

Tenez compte des événements d'une plate-forme de streaming musical. Il peut s'agir de :

- Événements de démarrage/pause/saut de piste

- Événements de session d'écoute avec horodatage

- Événements de création/modification de listes de lecture

- Événements de partage social

- Télécharger pour l'écoute hors ligne

#### Le schéma de streaming

Dans le schéma Streaming, les abonnés accèdent à chaque flux d'événements et traitent les événements dans l'ordre exact de réception. Des copies uniques de chaque flux de messages sont envoyées à chaque abonné, ce qui permet de livrer des contenus spécifiques à l'abonné et d'identifier les abonnés qui reçoivent les flux.

<!-- Image: Streaming pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Streaming - L3.png" alt="Ce diagramme de documentation et d&apos;implémentation de niveau 3 montre un exemple de schéma de diffusion en continu qui représente un flux d&apos;événements en cours de publication. Les abonnés qui écoutent les flux les reçoivent et les traitent en conséquence.">

#### Outils correspondant au schéma de diffusion en continu

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flux et comportement des événements</th><th colspan="2" scope="colgroup">Considérations relatives à la charge utile</th></tr>
<tr><th scope="col">Outils disponibles</th><th scope="col"></th><th scope="col">Compétences requises</th><th scope="col">Publier via</th><th scope="col">S'abonner via</th><th scope="col">Période de relecture</th><th scope="col">Structure de la charge utile</th><th scope="col">Limites de charge utile</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">Flux de données MuleSoft Anypoint</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connecteur Salesforce Pub/Sub</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">Connecteur MuleSoft Anypoint Apache Kafka</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka sur Heroku</a></td><td>Pro-code</td><td>API, changements d’enregistrement dans Heroku Postgres</td><td>S.O.</td><td>1 à 6 semaines</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Pro-code</td><td>API Pub/Sub ou APIs, Apex, Flow</td><td>API Pub/Sub</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Défini par l'utilisateur</a></td><td>1 MB</td></tr>
</tbody>
</table>

#### Gestion des commandes d'événements en continu

Pour qu'un flux soit pertinent, tous ses événements et leurs messages associés doivent être dans l'ordre approprié. Si vous générez les données dans un flux à partir de différents systèmes, vous devez incorporer une logique de commande supplémentaire dans le processus de conception.

### Mise en file d'attente

Les cas d'utilisation de mise en file d'attente sont omniprésents. Exemples :

- **Connexions Internet de faible qualité :** Les organisations d'assistance sur site ou les autres organisations dans lesquelles les équipes avec des appareils mobiles doivent travailler dans des zones avec un accès Internet de mauvaise qualité ou intermittent bénéficient de la mise en file d'attente, car les applications sur ces appareils peuvent se connecter à leurs files d'attente et récupérer tous les messages pertinents lorsque la connectivité est rétablie.

- **Tamponnage du message :** Lorsque le volume de messages dépasse occasionnellement la capacité de traitement d'un abonné et que l'augmentation de la latence ne crée pas de problèmes supplémentaires, les files d'attente peuvent servir de tampon pour stocker les messages excédentaires et éviter la perte de données.

- **Gestion des transports :** Les organisations logistiques qui doivent surveiller leur flotte peuvent utiliser ce modèle pour visualiser les itinéraires que chaque véhicule suit en temps quasi réel et s'assurer que les conducteurs sont aussi efficaces que possible.

- **Objets connectés :** Les fabricants utilisent souvent des systèmes qui génèrent des flux de données rapides, et ces flux peuvent avoir des effets en aval sur des systèmes supplémentaires. Ce schéma peut être utilisé pour identifier des séquences d'événements qui nécessitent une intervention humaine avant que des pannes catastrophiques ne surviennent dans plusieurs systèmes.

#### Le schéma de mise en file d'attente

Dans le schéma File d'attente, les producteurs envoient des messages aux files d'attente, qui conservent les messages jusqu'à ce que les abonnés les récupèrent. La plupart des files d'attente de messages suivent l'ordre premier entré, premier sorti (FIFO) et suppriment chaque message une fois récupéré. Chaque abonné a une file d'attente unique, qui nécessite des étapes de configuration supplémentaires mais permet de garantir la livraison et d'identifier les abonnés qui ont reçu les messages.

<!-- Image: Queuing pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Queuing L3.png" alt="Ce diagramme de documentation et d&apos;implémentation de niveau 3 montre un exemple de schéma de mise en file d&apos;attente qui représente un événement publié et écrit dans une file d&apos;attente lorsqu&apos;un enregistrement est modifié. Les abonnés reçoivent des copies de l&apos;événement depuis leur file d&apos;attente associée et effectuent les mises à jour appropriées sur leurs propres enregistrements.">

#### Outils relatifs au schéma de mise en file d'attente

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Flux et comportement des événements</th><th colspan="2" scope="colgroup">Considérations relatives à la charge utile</th></tr>
<tr><th scope="col">Outils disponibles</th><th scope="col"></th><th scope="col">Compétences requises</th><th scope="col">Publier via</th><th scope="col">S'abonner via</th><th scope="col">Période de relecture</th><th scope="col">Structure de la charge utile</th><th scope="col">Limites de charge utile</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/4.3/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Connecteur Salesforce Pub/Sub</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">Connecteur MuleSoft Anypoint Apache Kafka</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">Connecteur MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Connecteur MQTT MuleSoft Anypoint</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Connecteur MuleSoft Anypoint AMQP</a></td><td>Pro-code</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Tel que configuré</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Défini par l'utilisateur</a></td><td>Aucun</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka sur Heroku</a></td><td>Pro-code</td><td>API, changements d'enregistrement dans Heroku Postgres</td><td>S.O.</td><td>1 à 6 semaines</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Défini par l'utilisateur</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Change Data Capture</a></td><td>Du low-code au pro-code</td><td>Modifications d'enregistrement</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Prédéfini</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Événements de plate-forme</a></td><td>Du low-code au pro-code</td><td>API, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Défini par l'utilisateur</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Pro-code</td><td>API Pub/Sub ou APIs, Apex, Flow</td><td>API Pub/Sub</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Défini par l'utilisateur</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Relais d'événements*</a></td><td>Code faible</td><td>Événements de plate-forme, Capture des données de modification</td><td>API</td><td>3 jours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Défini par l'utilisateur</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Les relais d'événements envoient uniquement des données à AWS Eventbridge</td></tr>
</tbody>
</table>

#### Gestion de la mémoire et du stockage

En raison de la nature asynchrone du modèle Queuing, un délai important peut exister entre l'ajout d'un message à une file d'attente et sa récupération. Les files d'attente nécessitent de la mémoire ou de l'espace de stockage pour contenir leurs messages. Par conséquent, elles ne peuvent pas s'allonger indéfiniment, ce qui signifie qu'un abonné hors ligne indéfiniment peut entraîner un échec si suffisamment de messages s'accumulent dans la file d'attente. La mise en mémoire tampon des messages peut avoir le même effet si les temps de traitement des abonnés deviennent trop longs, ce qui entraîne l'accumulation de volumes importants de messages dans leurs files d'attente. Pour atténuer ces risques, effectuez une analyse approfondie des besoins en stockage de toutes les files d'attente de messages et, si nécessaire, concevez des processus qui purgent et désactivent les files d'attente si les messages ne sont pas récupérés dans un délai donné ou lorsqu'ils atteignent un volume prédéterminé.

## Considérations non fonctionnelles

En plus des considérations fonctionnelles énumérées dans les sections précédentes, il y a aussi des considérations non fonctionnelles à prendre en compte dans votre décision.

### Migration des intégrations point-à-point

Même si vous êtes convaincu qu'une architecture pilotée par l'événement convient à votre organisation, vous commencez peut-être par un paysage qui contient déjà un grand nombre d'intégrations de point à point. Obtenir le financement d'un projet pour remplacer toutes vos intégrations à la fois peut s'avérer difficile, et il peut même ne pas être possible d'utiliser une architecture pilotée par l'événement directement avec certains systèmes hérités. Dans ces scénarios, vous pouvez adopter une approche incrémentielle pour migrer vers une architecture plus vaguement couplée en convertissant d'abord les applications les plus critiques de l'entreprise, puis en convertissant d'autres systèmes à mesure qu'ils sont mis à jour ou remplacés dans de futurs projets. Cette approche facilite l'ajout de nouvelles applications au bus d'événements, et permet à votre paysage informatique global de rester évolutif et résilient à mesure que les systèmes s'ajoutent au fil du temps.

### Compromis au sein des systèmes faiblement couplés

En tant qu'architectes, nous savons que chaque architecture est associée à des compromis. Une architecture pilotée par l'événement ne fait pas exception. Bien qu'un paysage rempli de systèmes peu couplés soit hautement évolutif et résilient, il y a aussi quelques compromis à prendre en compte :

- **Stratégie globale d'intégration&nbsp;:** Quels que soient les outils et les modèles que vous choisissez d'utiliser, il est important de commencer par créer une stratégie pour le partage des données entre les divers systèmes du paysage de votre organisation. Cette stratégie doit inclure les objectifs de votre organisation concernant ses données, la façon dont les données peuvent être partagées et les modèles utilisés, ainsi que les sources de données, les cibles, les structures, et les exigences de propriété et d'accès.

- **Prise en charge des systèmes hérités&nbsp;:** Votre organisation peut avoir des systèmes hérités qui ne prennent tout simplement pas en charge les modèles d'architecture pilotée par l'événement. Bien qu'il soit possible d'élaborer des contournements (par exemple, avec un processus qui agit comme une transmission en s'abonnant à des événements, puis en envoyant la sortie au système cible via un autre moyen de transfert de données), vous pouvez envisager d'autres méthodes d'intégration dans ce cas.

- **Modifications structurelles des messages&nbsp;:** Une fois la structure initiale des messages définie et acceptée entre les éditeurs et les abonnés, il peut être difficile de la modifier, en particulier si les abonnés sont externes. Il existe plusieurs façons de résoudre ce problème. Vous pouvez utiliser des points de terminaison versionnés, mais assurez-vous de définir et de communiquer un cycle de vie clair pour chaque version afin d'éviter à vos développeurs de gérer un trop grand nombre de versions simultanément. Si Apache Kafka on Heroku fait partie de votre paysage, vous pouvez également envisager un registre de schéma ou un outil similaire, mais assurez-vous que les autres systèmes de votre paysage le prennent en charge (et l'utilisent également).

- **Manque de visibilité entre les éditeurs et les abonnés :** Dans la plupart des modèles d'architecture pilotée par l'événement, les éditeurs ne connaissent pas le statut de leurs abonnés. Par conséquent, si un éditeur envoie un message critique alors que tous les abonnés sont hors ligne, le message peut ne jamais être remis. Vous pouvez résoudre ce problème en utilisant la fonctionnalité de relecture ou en ajoutant des abonnés redondants exécutés sur des serveurs séparés pour tous les messages critiques.

- **Goulots d'étranglement des performances&nbsp;:** À mesure qu'une architecture pilotée par l'événement évolue, le bus d'événement peut devenir un goulot d'étranglement pour la remise de messages s'il est submergé par un trop grand nombre d'éditeurs qui tentent d'envoyer simultanément des messages à un trop grand nombre d'abonnés. Vous pouvez y remédier en augmentant la mémoire et les ressources de traitement allouées au bus d'événement ou en utilisant plusieurs bus d'événement pour traiter différents types de message en parallèle.

## Pratiques exemplaires associées

En plus des conseils déjà fournis, tenez compte des pratiques exemplaires ci-dessous.

### Implémentation d'architectures pilotées par les événements

Avant d'implémenter une architecture pilotée par l'événement, déterminez si vous devez vraiment l'utiliser. La section précédente décrit des scénarios métiers courants adaptés à chaque modèle d'architecture pilotée par l'événement. Vous pouvez également en savoir plus dans [Bien architecté - Fiabilité](/docs/architect/fr-fr/well-architected/guide/reliability.html). Examinez les défis à prendre en compte lors de l'implémentation d'architectures pilotées par l'événement afin de déterminer si les modèles que vous envisagez conviennent le mieux à vos cas d'utilisation spécifiques.

Notez que bien que la majorité des scénarios présentés dans ce guide impliquent des intégrations, les architectures pilotées par l'événement peuvent également être utilisées pour envoyer des messages dans une seule organisation Salesforce en utilisant par exemple des événements de plate-forme. Assurez-vous de tenir compte des [limites en allocations](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) d'événements applicables lors de la conception de processus qui utilisent des événements de plate-forme en tant que système de messagerie interne.

### Éviter les anti-modèles

Souvent, les anti-modèles autour des architectures pilotées par l'événement proviennent de l'utilisation d'événements comme contournement pour les communications internes dans une organisation Salesforce. Les anti-modèles courants comprennent :

- **La publication d'événements à partir de déclencheurs Apex associés au même objet événement:** Cela entraînera une boucle de déclenchement infinie.

- **La publication d'événements à partir d'Apex avant la fin d'une transaction DML&nbsp;:** Si une transaction échoue et est annulée, tous les événements publiés qui ont le comportement Publier immédiatement ne sont pas inclus dans le comportement d'annulation.

- **Publication d'événements dans Flux pour orchestrer une automatisation ultérieure :** La meilleure façon de coordonner la logique entre plusieurs automatisations consiste à utiliser des [sous-flux](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) ou [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm).

- **Création de dépendances d'exécution&nbsp;:** Ne publiez pas d'événements pour faciliter la communication entre les packages sans prendre les [mesures](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8) appropriées pour éliminer les dépendances à l'exécution.

- **Charges utiles inutilement importantes&nbsp;:** Lors de requêtes, il est préférable d'envoyer et de recevoir le plus petit volume de données possible dans la charge utile. Chaque action d'un utilisateur peut potentiellement générer plusieurs requêtes, et il est important que celles-ci soient traitées efficacement. L'envoi d'un plus grand nombre de données que nécessaire peut ralentir le transport et augmenter le temps de traitement.

- **Traitement non sélectif des événements d'application&nbsp;:** Lorsque plusieurs composants écoutent un événement d'application, les développeurs doivent s'assurer que le gestionnaire d'événements est exécuté uniquement lorsque cela est réellement souhaité et utile. Par exemple, dans Lightning Console, les composants contenus dans des onglets qui ne sont pas au point peuvent toujours être en écoute même s'ils ne sont pas visibles. Un développeur peut utiliser diverses techniques, par exemple utiliser un élément utilitaire en arrière-plan comme seul auditeur, ou appeler getEnclosingTabId() pour déterminer si cette instance du composant est incluse dans l'onglet ciblé afin de s'assurer que chaque événement est géré uniquement lorsqu'il est prévu.

- **Utilisation incorrecte du comportement de publication des événements de plate-forme&nbsp;:** Les événements de plate-forme ont deux comportements de publication : Publier immédiatement et Publier après validation. Il peut être utile d'utiliser des événements de plate-forme en temps réel pour des cas d'utilisation tels que la consignation, dans lesquels vous souhaitez publier l'événement de consignation, que la transaction réussisse ou non et qu'elle s'engage. Cependant, utilisez 'Publier immédiatement' avec précaution pour les événements de plate-forme en temps réel. Les événements peuvent être consommés par les abonnés dans la même transaction et entraîner des verrouillages de ligne ou d'autres conditions de course.

### Conception d'événements efficaces

Lors de l'implémentation d'une architecture pilotée par l'événement, l'une des clés du succès est de définir des normes pour la conception des événements eux-mêmes. Les détails varient selon les cas d'utilisation de votre organisation, mais voici quelques consignes générales :

- **Déterminez la structure optimale pour vos charges de travail d'événements.** Bien que les tailles de message plus petites réduisent les temps de traitement, bombarder les abonnés avec des volumes massifs de messages peut entraîner des blocages dans les performances. Il peut être nécessaire d'itérer sur vos tailles et structures de charge utile pour trouver le bon équilibre. MuleSoft et les outils ESB similaires permettent de concevoir des charges de travail personnalisées dans les messages associés à vos événements, ce qui peut vous aider à visualiser les structures de données pour améliorer les performances côté abonné. (Pour plus d'informations, consultez [Bien archivé - Fiabilité](/docs/architect/fr-fr/well-architected/guide/reliability.html)).

- **Pensez à vos processus de bout en bout.** Assurez-vous de ne pas créer de scénarios de « boucle sans fin », qui peuvent être difficiles à retrouver une fois les intégrations déployées. Par exemple, deux systèmes publient des événements lorsque les enregistrements sont mis à jour, tout en écoutant les événements de l'autre, qui déclenchent des événements publiés supplémentaires lorsqu'ils sont traités.

  Vous pouvez corriger ce type d'anti-modèle en ajoutant une logique aux deux systèmes qui garantit que les modifications effectuées suite à un événement consommé n'entraînent pas la publication d'un nouvel événement. Assurez-vous également de documenter tous vos événements, leurs déclencheurs associés et les systèmes en aval qui peuvent être affectés. Utilisez cette documentation comme référence pendant les sessions de conception pour identifier le plus tôt possible des boucles interminables et des scénarios similaires. (Pour plus d'informations, consultez [Bien archivé - Excellence opérationnelle](/docs/architect/fr-fr/well-architected/guide/operational-excellence.html)).

- **Utilisez des conventions de nommage communes à travers les systèmes.** Des conventions de nommage cohérentes sont une meilleure pratique pour tous les développements de logiciels, y compris les architectures pilotées par les événements. Prenez le temps de documenter une série de normes pour les noms d'événements, les structures, les objets associés et les processus de traitement des erreurs afin de garantir la cohérence entre les systèmes. (Pour plus d'informations, consultez [Bien archivé - Excellence opérationnelle](/docs/architect/fr-fr/well-architected/guide/operational-excellence.html)).

## Ressources

<table style="width:100%">
<thead>
<tr><th scope="col">Modèle</th><th scope="col">Ressources</th></tr>
</thead>
<tbody>
<tr><td>Publier / S'abonner</td><td><a href="/docs/architect/fr-fr/well-architected/guide/reliability.html">Salesforce bien architecturée - Fiabilité</a><br><a href="/docs/architect/fr-fr/well-architected/guide/operational-excellence.html">Salesforce bien architecturée - Excellence opérationnelle</a><br><a href="https://medium.com/salesforce-architects/achieve-architectural-efficiency-with-event-relays-c8d4ec7f07af">Article de blog : Atteignez l'efficacité architecturale grâce aux relais d'événements</a><br><a href="https://medium.com/salesforce-architects/announcing-pub-sub-api-generally-available-3980c9eaf0b7">Article de blog : Annonce de l'API Pub/Sub désormais en accès général</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/moving-from-restful-to-eventful/">Article de blog : Passage de RESTful à EVENTful</a><br><a href="https://blogs.mulesoft.com/dev-guides/event-driven-architectures-asyncapi/">Article de blog : Architectures pilotées par les événements et la spécification AsyncAPI</a><br><a href="https://youtu.be/0WJjmmw1ryM">Vidéo : Procédure pas à pas du schéma Publier / S'abonner</a></td></tr>
<tr><td>Fanout</td><td><a href="https://developer.salesforce.com/blogs/2021/08/how-to-work-within-platform-events-delivery-limits">Article de blog: Comment respecter les limites de livraison des événements de plate-forme</a><br><a href="https://youtu.be/zSncRUcucEU">Vidéo : Procédure pas à pas du schéma Fanout</a></td></tr>
<tr><td>Messages transmis</td><td><a href="https://youtu.be/U87nErhMuqw">Vidéo : Procédure pas à pas du schéma des messages transmis</a></td></tr>
<tr><td>Streaming</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Article de blog: Conception d'écritures à haut volume dans Salesforce</a><br><a href="https://youtu.be/-_1CDUI40fY">Vidéo : Procédure pas à pas du schéma de streaming</a><br><a href="https://docs.mulesoft.com/mule-runtime/4.3/streaming-about">Documentation : Diffusion en continu dans des applications Mule</a></td></tr>
<tr><td>Mise en file d'attente</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Article de blog: Conception d'écritures à haut volume dans Salesforce</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/event-payment-apis/">Article de blog: Comment concevoir des architectures de paiement avec des API Evented</a><br><a href="https://youtu.be/jQvSKbMRbh0">Vidéo : Procédure pas à pas du schéma de mise en file d'attente</a></td></tr>
</tbody>
</table>

<!-- document id=180de98b2d4e49c3bc9586d2e5010741ba3a7039714c3d3a0d72248cd6546501 url=/architect/current/fr-fr/decision-guides/guides/record-triggered.md -->

# Automatisation déclenchée par un enregistrement

Salesforce Platform a continuellement amélioré son architecture d'automatisation pour répondre aux exigences des processus métiers complexes. Les générations précédentes – Règles de workflow et Générateur de processus – ont fourni les premières étapes de la logique pilotée par l'événement, en élargissant les capacités d'automatisation de la logique pilotée par l'événement et en élargissant la portée à un plus grand nombre de générateurs.

Cette évolution a abouti à une architecture consolidée et performante centrée sur deux piliers complémentaires : Flux déclenché par un enregistrement et déclencheurs Apex.

## Présentation du guide

Ce document fournit le cadre et les consignes nécessaires pour prendre des décisions informées lors de la conception d'automatisations de déclencheur. Il établit un équilibre entre les exigences des cas d'utilisation et trois points de décision majeurs qui vous guideront à choisir l'approche appropriée pour l'automatisation déclenchée par les modifications apportées aux enregistrements Salesforce.

## Produits concernés

<table style="border:none">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Flux</td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Salesforce Flow</a> est un puissant outil d'automatisation par pointer-cliquer qui permet aux utilisateurs d'élaborer visuellement des processus métiers, des écrans et une logique complexes en utilisant Flow Builder, sans écrire de code. Il automatise des tâches telles que la mise à jour des données, l'envoi d'e-mails et le guidage des utilisateurs, offrant ainsi de la flexibilité à travers des types tels que Flux d'écran (interaction utilisateur) et Flux déclenchés (enregistrement/événements planifiés).</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Apex</td> 
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a> est un langage de programmation propriétaire et orienté objet pour la plate-forme Salesforce, similaire à Java, utilisé pour élaborer une logique métier personnalisée, automatiser les processus et étendre les fonctionnalités CRM de base au-delà des outils déclaratifs.</td>
    </tr>
  </tbody>
</table>

## Points à retenir

L'élaboration d'une automatisation déclenchée par un enregistrement évolutive, maintenable et performante sur la plate-forme Salesforce nécessite une approche disciplinée et pilotée par l'architecture. Le choix entre Flux et Apex, et l'implémentation de chacun, est guidé par une série de principes clairs. Ces points résument ces principes et servent de règles de base pour la conception moderne de l'automatisation.

- **Choisissez l'outil adapté à votre tâche en fonction de la densité d'automatisation des objets Salesforce.**

  - Utilisez Flux déclenché par un enregistrement pour des objets Salesforce pour des automatisations de **faible densité**.

  - Renforcez la logique du flux déclenché par un enregistrement avec Apex invocable pour des automatisations de **densité moyenne**.

  - Utilisez des déclencheurs Apex pour des objets Salesforce pour des automatisations **à haute densité**.

- **Faites preuve de prudence en déclenchant des processus asynchrones.**  
  Cette règle s'applique que vous invoquiez des processus asynchrones dans un flux déclenché par un enregistrement ou mettiez en file d'attente une tâche depuis Apex. Bien que ce schéma puisse être tentant pour le délestage du travail, il peut introduire des scénarios complexes de traitement des erreurs et augmenter le risque d'atteindre les limites du gouverneur.

- **Utilisez un point d'entrée par objet Salesforce.**  
  Pour un objet Salesforce donné, utilisez un mécanisme comme point d'entrée dans l'automatisation. Essayez d'éviter de mélanger des déclencheurs Flux et Apex comme points d'entrée d'un même Objet.

## Points de décision

Trois points de décision principaux doivent être pris en considération :

- Implémentation déclarative par rapport à programmatique
- Densité d'automatisation
- Matrice de sélection de la densité

### Implémentation déclarative par rapport à programmatique

Flux et Apex partagent un ensemble commun de capacités fondamentales. Chaque outil peut interroger des enregistrements, exécuter une logique conditionnelle, attribuer des variables et exécuter des opérations DML telles que la création, la mise à jour et la suppression d'enregistrements, séquencés pour être exécutés dans un ordre spécifié.

Cependant, ce chevauchement fonctionnel n'implique pas que les outils soient interchangeables. Le choix architectural ne concerne pas _si_ une tâche peut être réalisée, mais _comment_ elle est réalisée et quelles sont les implications à long terme pour les performances, l'évolutivité et la maintenabilité. Le flux excelle dans la clarté déclarative et la rapidité d'implémentation pour des processus simples, tandis qu'Apex fournit le contrôle granulaire et la puissance brute nécessaires pour des solutions complexes.

### Densité d'automatisation

La **densité d'automatisation** est la charge imposée à un objet Salesforce spécifique. Il sert d'heuristique pour déterminer l'implémentation optimale de l'objet. À mesure que la densité de l'automatisation augmente, la probabilité d'infraction aux limites transactionnelles augmente.

Calculez la densité d'automatisation en inspectant trois dimensions spécifiques de volume et de complexité :

- **Quantité d'automatisation :** Le nombre brut d'entrées de métadonnées d'automatisation uniques (flux, actions de déclencheur, etc.) exécutées pendant un événement DML (Data Manipulation Language) unique.

- **Volume d'enregistrement :** Les enregistrements par transaction traités via des chargements d'API ou un traitement par lot lourd, où les performances deviennent critiques.

- **Prolifération des dépendances :** Une mesure des opérations DML en aval déclenchées par l'opération CRUD initiale. Il quantifie la profondeur du graphique où une mise à jour est mise à jour en cascade dans des objets associés (par exemple, requête → compte → contact → cumul personnalisé).

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/automation-density.png" alt="Dimensions de densité d&apos;automatisation">

À mesure que l'étendue et la complexité de votre application Salesforce augmentent, adoptez un point d'entrée principal unique, soit le flux déclenché par un enregistrement, soit les déclencheurs Apex. Évitez de partitionner les automatisations entre plusieurs mécanismes dans un seul objet Salesforce, car cela entraîne une mauvaise maintenabilité et une gouvernance fragmentée.

### Matrice de sélection de la densité

Utilisez cette matrice afin de déterminer la norme architecturale requise pour votre objet Salesforce.

- **Flux déclenché par un enregistrement** est la solution préférée pour une faible densité d'automatisation. Il offre un équilibre de puissance et d'accessibilité idéal pour des automatisations simples et indépendantes les unes des autres.

- **Le schéma hybride (flux déclenché par un enregistrement avec Apex invocable)** est un choix puissant et maintenable pour les automatisations à densité moyenne avec une complexité croissante. Ce schéma permet aux équipes de maintenir une chorégraphie ordonnée dans Flux déclaratif tout en déléguant des opérations lourdes en calcul à Apex, en équilibrant l'accessibilité avec les performances.

- Les **déclencheurs Apex** fournissent les blocs de construction nécessaires à une fondation architecturale solide pour soutenir les automatisations à haute densité. Les performances, le contrôle granulaire, ainsi que l'abstraction orientée objet et le polymorphisme d'Apex sont mieux adaptés pour gérer la complexité et l'échelle de ces scénarios.

<table>
  <thead>
    <tr>
      <th scope="col" style="width:8%">Niveau de densité</th>
      <th scope="col" style="width:18%">Quantité d'automatisation</th>
      <th scope="col">Volume de données (taille du lot)</th>
      <th scope="col">Prolifération des dépendances</th>
      <th scope="col">Norme architecturale</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Faible</b></td>
      <td><b>&lt; 15</b><br>
        Automatisations</td>
      <td><b>Standard</b><br>
        Interactions de l'interface utilisateur pilotées par l'utilisateur ou petites charges d'API (1 à 200 enregistrements)</td>
      <td><b>Discret</b><br>
        Logique autonome. 0 à 1 opérations DML en aval sur le même objet ou un objet associé.</td>
      <td><b>Flux déclenché par un enregistrement</b></td>
    </tr>
    <tr>
      <td><b>Moyen</b></td>
      <td><b>15–30</b><br>
        Automatisations</td>
      <td><b>Modéré</b><br>
        Traitement par lot standard (avec une logique nécessitant un traitement en masse minutieux)</td>
      <td><b>Couplé</b><br>
        Les mises à jour parent/enfant entraînent 2 à 4 opérations DML en aval. Risque de récursion</td>
      <td><b>Modèle hybride</b><br>
        Flux + Apex invocable</td>
    </tr>
    <tr>
      <td><b>Élevée</b></td>
      <td><b>> 30</b><br>
        Automatisations</td>
      <td><b>Élevée</b><br>
        Volumes de données importants avec des chargements d'API en masse (2 000 à plus de 10 000 enregistrements)</td>
      <td><b>Complexe et récursif</b><br>
        Graphe de dépendance profond : 5 opérations DML en aval ou plus. Risque de boucles de récursion triangulaires</td>
      <td><b>Cadre de métadonnées des déclencheurs Apex</b></td>
    </tr>
  </tbody>
</table>
Les décisions architecturales réelles nécessitent de peser collectivement toutes les dimensions de la densité de l'automatisation. Tenez compte de l'étendue future potentielle en sélectionnant un mécanisme d'automatisation pour un objet Salesforce donné.

Tenez également compte du nombre total d'opérations DML quotidiennes, car Salesforce applique automatiquement la gestion des ressources partagées dans un environnement multilocataire et les [limites du gouverneur](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm) afin d'empêcher les automatisations galopantes de monopoliser les ressources partagées. Les objets Salesforce avec un volume DML quotidien élevé nécessitent une sélection rigoureuse de l'automatisation. Par exemple, les limites en temps processeur (60 000 ms) et en taille de tas (12 Mo) sont supérieures aux limites synchrones. De plus, la limite en exécutions asynchrones sur 24 heures à l'échelle de l'organisation (calculée à 250 000, soit 200 fois vos licences utilisateur) nécessite de prendre en compte le DML total quotidien dans votre conception architecturale afin d'éviter les exceptions à l'exécution.

## Comparaison des produits

Le flux déclenché par un enregistrement est le principal outil déclaratif de la plateforme pour l'automatisation des enregistrements. La facilité d'utilisation de Flow et les garanties de plate-forme intégrées permettent aux équipes d'élaborer aisément des solutions évolutives et fiables. C'est le choix idéal pour la plupart des équipes qui élaborent des solutions sur Salesforce Platform.

Apex est le langage de programmation propriétaire, fortement typé et orienté objet de la plateforme. Utilisez Apex pour les objets Salesforce à forte densité d'automatisation, et pour les cas d'utilisation qui nécessitent des performances élevées, une logique sophistiquée ou un contrôle granulaire des transactions.

Pour faciliter le processus de prise de décision, cette matrice fournit une comparaison directe de Flux et Apex entre les capacités architecturales clés.

<table>
  <thead>
    <tr>
      <th scope="col">Capacité</th>
      <th scope="col">Flux déclenché par un enregistrement</th>
      <th scope="col">Déclencheur Apex</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Rapidité de livraison et d'entretien</b></td>
      <td><b>Recommandé</b><br>
        L'interface utilisateur visuelle de Flow Builder permet aux administrateurs et autres générateurs déclaratifs de créer et de modifier des automatisations plus rapidement que l'écriture, le test et le déploiement d'un code Apex. Cette interface permet à un plus grand nombre de membres de l'équipe d'offrir de la valeur métier et réduit la dépendance aux ressources spécialisées pour les développeurs pour de simples tâches.</td>
      <td><b>Expertise requise</b><br>
        Apex nécessite des développeurs de logiciels correctement qualifiés pour implémenter, tester et maintenir le code.</td>
    </tr>
    <tr>
      <td><b>Modularité</b></td>
      <td><b>Disponible</b><br>
        Les flux déclenchés par un enregistrement sont modulaires par défaut. Au lieu d'une logique monolithique, les équipes élaborent des flux discrets pour des exigences spécifiques et les chorégraphient ensemble en utilisant l'Explorateur de déclencheur de flux. Cette modularité permet une modification isolée et une extension simple, réduisant considérablement le coût à long terme de propriété.</td>
      <td><b>Disponible</b><br>
        Apex est divisé en modules fonctionnels dès la conception. Chaque classe Apex est destinée à implémenter un seul module de fonctionnalité.</td>
    </tr>
    <tr>
      <td><b>Visibilité et gouvernance</b></td>
      <td><b>Recommandé</b><br>
        La nature visuelle de Flux offre une représentation intuitive de la logique métier. L'Explorateur de déclencheur de flux fournit une vue consolidée de tous les flux d'un objet, ce qui facilite la compréhension, la gouvernance et le dépannage des architectes et des administrateurs sans lire de code.</td>
      <td><b>Expertise requise</b><br>
        L'utilisation d'une infrastructure de métadonnées pour organiser les déclencheurs est avantageuse, mais Apex nécessite une équipe de développement disciplinée pour garder le code organisé et maintenable.</td>
    </tr>
    <tr>
      <td><b>Traitement en masse des données haute performance</b></td>
      <td><b>Non recommandé</b><br>
        Le risque d'atteindre les limites du gouverneur est élevé lorsqu'il s'agit d'une logique complexe ou de volumes de données importants.</td>
      <td><b>Recommandé</b><br>
        Le code Apex exécute au plus près des services de base de la plate-forme et offre aux développeurs un contrôle renforcé sur l'optimisation des requêtes, le traitement des données et l'efficacité algorithmique. Cela améliore les performances et l'échelle, en particulier dans les scénarios complexes impliquant des volumes de données importants.</td>
    </tr>
    <tr>
      <td><b>Logique robuste et structures de données</b></td>
      <td><b>Disponible</b><br>
        L'<a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">élément Transformation de flux</a> peut faciliter certaines tâches de traitement complexes. Cependant, Flow n'a pas de structures de données Map et Set natives, ce qui rend le traitement des données complexes lourd et inefficace sur le plan informatique.</td>
      <td><b>Recommandé</b><br>
        Apex fournit un accès complet aux structures Map et Set, ainsi qu'aux boucles programmatiques, pour une manipulation des données hautement efficace et sécurisée en masse. En tant que langage de programmation complet, Apex permet également d'accéder à des constructions logiques complexes, des structures de données et des modèles de conception qui peuvent aider à résoudre des problèmes métiers complexes de manière maintenable et efficace. Apex inclut une riche bibliothèque standard de fonctions avancées (par exemple, BusinessHours, Crypto) qui n'est pas disponible actuellement dans les outils déclaratifs.</td>
    </tr>
    <tr>
      <td><b>Contrôle des transactions</b></td>
      <td><b>Non disponible</b><br>
        Le flux ne fournit aucun accès à `Database.savepoint`, `Database.rollback` ou aux opérations DML partiellement réussies pour des validations de transaction partielles ou des annulations.</td>
      <td><b>Disponible</b><br>
        Apex fournit un contrôle complet et précis de l'intégrité des transactions et des scénarios complexes de reprise après erreur.</td>
    </tr>
    <tr>
      <td><b>Distribution des e-mails</b></td>
      <td><b>Recommandé</b><br>
        L'envoi d'alertes par e-mail préconfigurées à partir d'un flux déclenché par un enregistrement est facile et évolutif. Des alertes par e-mail personnalisées peuvent être élaborées et distribuées à l'exécution. Les e-mails personnalisés sont soumis aux <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">limites quotidiennes d'envoi</a>.</td>
      <td><b>Disponible</b><br>
        Apex peut générer et envoyer des e-mails personnalisés. Tous les e-mails envoyés depuis Apex sont soumis aux <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">limites quotidiennes d'envoi</a>.</td>
    </tr>
    <tr>
      <td><b>Application des garanties de la plate-forme</b></td>
      <td><b>Recommandé</b><br>
        Le flux inclut des protections intégrées, telles que la mise en masse automatique et les réessais automatiques. Ces mesures augmentent la vitesse de valorisation et évitent les problèmes de performance qui nécessitent un codage manuel complexe.</td>
      <td><b>Application manuelle requise</b><br>
        Les mesures de protection telles que le traitement en masse doivent être explicitement codées (par exemple, gérer les collections et éviter le SOQL dans les boucles). Les tentatives automatiques ne sont pas natives de déclencheurs et nécessitent une logique personnalisée complexe à implémenter.</td>
    </tr>
    <tr>
      <td><b>Traitement asynchrone</b></td>
      <td><b>Disponible</b><br>
        Le flux offre des mécanismes faciles pour les automatisations qui nécessitent une transaction séparée dans un parcours asynchrone. Ces automatisations sont soumises à des limitations quotidiennes.</td>
      <td><b>Disponible</b><br>
        Apex permet un contrôle total via la Capture des données de modification et les événements qui peuvent être mis en file d'attente et qui sont gérés par un abonné au déclencheur découplé.</td>
    </tr>
    <tr>
      <td><b>Traitement planifié</b></td>
      <td><b>Recommandé</b><br>
        Les parcours planifiés du flux offrent une capacité de planification unique et puissante (par exemple, « déclencher 3 jours avant la date de fermeture »). Cette capacité inclut l'annulation et la replanification automatiques si les données de l'enregistrement changent. Ces automatisations sont soumises à des limitations quotidiennes.</td>
      <td><b>Non disponible</b><br>
        Un déclencheur Apex ne peut pas planifier nativement un événement temporel, spécifique à un enregistrement, avec une annulation automatique. Apex planifié existe, mais il s'agit d'un mécanisme fondamentalement différent qui est exécuté à une heure spécifique et qui n'est pas planifié pendant le traitement d'un enregistrement individuel dans le cadre d'un déclencheur.</td>
    </tr>
    <tr>
      <td><b>Ordonnancement et chorégraphie</b></td>
      <td><b>Disponible</b><br>
        L'Explorateur de déclencheur de flux permet aux administrateurs de définir un ordre d'exécution relatif pour plusieurs flux dans le même objet.</td>
      <td><b>Disponible</b><br>
        Une infrastructure de déclencheur permet de contrôler avec précision l'ordre exact des automatisations.</td>
    </tr>
    <tr>
      <td><b>Mises à jour de champs sur le même enregistrement</b></td>
      <td><b>Disponible (avant la sauvegarde)</b><br>
        Le flux déclenché par un enregistrement est l'option déclarative la plus performante pour mettre à jour l'enregistrement déclenchant avant l'engagement DML initial.</td>
      <td><b>Disponible (avant la sauvegarde)</b><br>
        Apex offre les meilleures performances avec un minimum de frais généraux.</td>
    </tr>
    <tr>
      <td><b>CRUD inter-objets</b></td>
      <td><b>Disponible (après la sauvegarde)</b><br>
        Le flux convient aux opérations DML inter-objets simples et peu complexes.</td>
      <td><b>Disponible (après la sauvegarde)</b><br>
        Apex offre un contrôle supérieur de la déduplication, du traitement des erreurs et des performances pour les opérations DML inter-objets.</td>
    </tr>
    <tr>
      <td><b>Déduplication du calcul coûteux</b></td>
      <td><b>Disponible</b><br>
        Flow excelle dans l'élimination des requêtes redondantes et des instructions DML via le traitement en masse automatique. Cependant, l'état ne peut pas être mis en cache ou partagé entre différents déclencheurs de flux ou entre plusieurs invocations du même flux dans une seule transaction. Cette limitation peut devenir importante dans des scénarios de performance extrême.</td>
      <td><b>Recommandé</b><br>
        Apex offre des mécanismes de déduplication pour les opérations coûteuses. Les développeurs peuvent exploiter la mise en cache transactionnelle en utilisant des propriétés et des variables statiques, et la mise en cache au niveau de la plate-forme en utilisant Cache de la plate-forme, pour stocker et réutiliser des données. Ces techniques sont importantes pour réduire la consommation des limites du gouverneur transactionnel, telles que les requêtes SOQL, et garantir des performances et une évolutivité élevées.</td>
    </tr>
    <tr>
      <td><b>Gestion des erreurs personnalisées</b></td>
      <td><b>Disponible</b><br>
        L'élément CustomError peut bloquer une opération d'enregistrement et afficher un message pour l'utilisateur.</td>
      <td><b>Recommandé</b><br>
        La méthode <code>addError()</code> fournit un message d'erreur flexible au niveau du champ et conditionnel.</td>
    </tr>
  </tbody>
</table>

## Cas d'utilisation

Pour mieux mettre en évidence comment utiliser les points de décision pour guider vos décisions, tenez compte des cas d'utilisation ci-dessous et des points d'analyse associés.

### Recommandations les plus adaptées

Le tableau ci-dessous présente des recommandations générales « les plus adaptées » pour les cas d'utilisation généraux, en fonction des capacités présentées. En fin de compte, vous prendrez en compte d'autres considérations afin d'arriver à la meilleure adéquation à vos scénarios particuliers, par exemple ceux inclus dans la section _Meilleures pratiques connexes_ du présent document. Vous y apprendrez quand une combinaison particulière de flux et Apex fournit la meilleure approche.

<table>
  <thead>
    <tr>
      <th scope="col">Cas d'utilisation</th>
      <th scope="col">Description</th>
      <th scope="col" style="width:16%">Best-Fit</th>
      <th scope="col" style="width:38%">Justification</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Traitement par lot hautement performant</b></td>
      <td>Toute automatisation qui doit traiter efficacement des milliers d'enregistrements</td>
      <td>Apex</td>
      <td>Apex fournit des API riches pour l'interface avec la plate-forme et pour la vitesse brute.</td>
    </tr>
    <tr>
      <td><b>Traitement complexe des données</b></td>
      <td>Scénarios qui nécessitent une manipulation avancée des données</td>
      <td>Apex</td>
      <td>Apex fournit des structures de données, telles que Map et Set, qui ne sont pas disponibles en natif dans Flow, et peuvent être critiques pour écrire un code performant et sécurisé en masse.</td>
    </tr>
    <tr>
      <td><b>Contrôle transactionnel</b></td>
      <td>Mécanismes de contrôle tels que les points de sauvegarde, les annulations et les validations partielles</td>
      <td>Apex</td>
      <td>Apex permet d'accéder à des mécanismes tels que Database.savepoint et Database.rollback, et a la possibilité de traiter les opérations DML partiellement réussies.</td>
    </tr>
    <tr>
      <td><b>Validation personnalisée sophistiquée</b></td>
      <td>Validation des données dans plusieurs champs d'un enregistrement</td>
      <td>Apex</td>
      <td>Bien que Flux puisse empêcher l'enregistrement avec l'élément `CustomError`, il n'est pas disponible dans tous les types de flux, y compris les flux secondaires. La méthode Apex <code>addError()</code> fournit plusieurs messages d'erreur spécifiques à un champ qui peuvent être ajoutés à un enregistrement à tout moment pendant le traitement du déclencheur.</td>
    </tr>
    <tr>
      <td><b>Logique moyennement complexe dans un processus simple</b></td>
      <td>Logique et manipulation de données de complexité modérée, simplifiée par une bibliothèque standard de fonctions avancées, survenant dans le cadre d'un processus simple</td>
      <td>Flux + Apex</td>
      <td>Le flux déclenché par un enregistrement agit en tant que couche d'orchestration, tandis que les opérations hautement complexes sont encapsulées dans Apex invocable.</td>
    </tr>
    <tr>
      <td><b>Logique simple à moyennement complexe</b></td>
      <td>Manipulation de données de complexité faible à modérée, avec des mises à jour de déclencheur pour les objets de données principaux et associés</td>
      <td>Flux</td>
      <td>Le flux est généralement l'option incontournable, car il est basé sur un modèle déclaratif qui le rend accessible aux administrateurs et aux développeurs.</td>
    </tr>
    <tr>
      <td><b>Notifications et messages sortants</b></td>
      <td>Envoi d'e-mails et de messages sortants</td>
      <td>Flux</td>
      <td>Le flux facilite et adapte considérablement l'envoi d'alertes par e-mail et de messages sortants lors de modifications d'enregistrement.</td>
    </tr>
    <tr>
      <td><b>Traitement planifié</b></td>
      <td>Automatisation à une date future et dynamique (par exemple, 3 jours avant une date de fermeture)</td>
      <td>Flux</td>
      <td>Les parcours planifiés offrent une force unique à Flux, car la plate-forme gère automatiquement la planification, l'annulation et la replanification de ces parcours si les données de l'enregistrement changent.</td>
    </tr>
  </tbody>
</table>

### Traitement évolutif : Cas d'utilisation asynchrones en profondeur

L'évolutivité est une considération essentielle lors de la conception de votre implémentation. Lorsque la logique métier d'une automatisation déclenchée par un enregistrement devient complexe, longue ou implique des volumes de données importants, les limites du gouverneur principal de Salesforce Platform deviennent une contrainte architecturale. Des opérations telles que des mises à jour de données en masse, des appels d'API complexes ou des calculs lourds augmentent le risque de dépassement des limites, par exemple le temps processeur total ou le nombre d'instructions DML dans une seule transaction de base de données. Un échec d'un déclencheur synchrone dû à une exception de limite entraîne l'annulation de la transaction d'enregistrement complète de l'utilisateur, ce qui entraîne une mauvaise expérience utilisateur et une perte potentielle de données. Ce risque inhérent exige un modèle architectural pour décharger des travaux complexes.

L'automatisation asynchrone devient dans ce cas indispensable. En utilisant des mécanismes asynchrones, les architectes peuvent efficacement dissocier le travail de longue durée ou à haut volume de la transaction principale et synchrone d'enregistrement. Les enregistrements sont effectués rapidement et de façon fiable, tandis que le traitement lourd est délégué à une transaction séparée gérée par la plate-forme qui est exécutée plus tard. Le découplage améliore la stabilité, évite les échecs de transaction et est essentiel pour élaborer des applications d'entreprise évolutives. La plate-forme offre plusieurs outils spécialisés pour cela, chacun avec des avantages et des compromis distincts en termes de fiabilité, de volume et de complexité.

### Chemin asynchrone du flux

Le parcours Exécuter de façon asynchrone dans un flux déclenché par un enregistrement fournit le mécanisme le plus simple pour la logique asynchrone « feu et oubli ». Ce chemin est exécuté dans une transaction séparée lorsque la transaction d'enregistrement d'origine a été engagée avec succès dans la base de données.

- **Cas d'utilisation idéal**: Il convient parfaitement aux tâches qui ne nécessitent pas d'exécution immédiate ou de traitement personnalisé des erreurs. Par exemple, envoyer une notification par e-mail, créer une tâche de suivi ou passer un simple appel externe à un système externe.

- **Limites**: Ce mécanisme partage les mêmes limites du gouverneur quotidiennes que les autres exécutions de flux asynchrones. Il n'est pas conçu pour le traitement à très haut volume.

### Capture des données de modification (CDC)

La Capture des données de modification (CDC) est un modèle à haut débit, évolutif et résilient qui permet de gérer une logique asynchrone déclenchée par un changement d'enregistrement dans des scénarios à haut volume. Dans ce modèle, la seule responsabilité du déclencheur est d'enregistrer l'enregistrement de façon synchrone. La plate-forme publie ensuite un message d'événement détaillé qui contient les modifications apportées à l'enregistrement dans un bus d'événement à haut volume. Un déclencheur Apex séparé et dédié s'abonne à cet événement de modification. Il effectue des tâches complexes, longues ou asynchrones.

- **Avantage**: Ce schéma découple le processus asynchrone de la transaction utilisateur initiale. Un échec du traitement asynchrone n'entraîne pas l'annulation de l'enregistrement de l'utilisateur. Le modèle fournit également un flux d'événements durable que plusieurs abonnés internes ou systèmes externes peuvent consommer, et les événements peuvent être rejoués pendant 72 heures, offrant une forte résilience.

- **Limites**: Les messages d'événement du CDC ne contiennent pas l'état antérieur de l'enregistrement - l'équivalent d'un `Trigger.oldMap` Apex. La charge de travail de l'événement inclut les nouvelles valeurs de champ, mais pas les valeurs à partir desquelles elles ont changé. Il est donc difficile d'implémenter une logique basée sur une transition d'état spécifique (par exemple, exécutée uniquement si la `Status__c` change de « En attente » à « Approuvé »). Vous pouvez atténuer ce problème en interrogeant l'historique des champs de l'objet dans l'abonné à l'événement, mais cela ajoute de la complexité au processus, et le suivi de l'historique des champs peut ne pas être disponible pour le champ d'intérêt spécifique. Cela peut limiter les types d'automatisation que vous pouvez décharger vers le CDC.

Par défaut, le CDC peut être activé dans cinq objets Salesforce maximum. Les organisations qui en ont besoin peuvent acheter une licence complémentaire qui retire cette limite et augmente les allocations de livraison d'événements.

### Apex Queueable à partir d'un déclencheur

La mise en file d'attente d'une tâche Apex Queueable directement à partir d'un déclencheur doit être considérée comme un schéma risqué, utilisé uniquement lorsque le contrôle fourni par Apex est nécessaire (par exemple, pour une logique complexe ou des mécanismes de nouvelle tentative personnalisés), et CDC n'est pas une option viable.

Si Apex Queueable est requis, l'implémentation doit inclure les garanties appropriées.

- **Vérification des limites**: Le code doit vérifier le nombre de tâches déjà mises en file d'attente dans la transaction avant de tenter d'en ajouter une autre.

  ```
  if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... }
  ```

- **Connaissance du contexte**: Le code doit détecter s'il est exécuté dans un contexte asynchrone, par exemple une tâche par lot (`System.isBatch()`), et modifier son comportement pour respecter la limite plus stricte d'une tâche par transaction dans ce contexte.

### Considérations relatives aux limites pour Apex asynchrone déclenché

Invoquer Apex asynchrone à partir d'un déclencheur synchrone introduit des risques de stabilité. Pour éviter l'impact au niveau de l'organisation (par exemple, dépassement des limites), ce schéma nécessite une conception et des tests rigoureux.

- La limite quotidienne en exécutions Apex asynchrones (`Batch`, `Queueable`, `@Future`) est partagée entre l'organisation (généralement 250 000 ou un calcul basé sur les licences utilisateur). Un chargement de données en masse de 20 000 enregistrements entraînera l'exécution d'un déclencheur par segments de 200, entraînant 100 invocations de déclencheur séparées - encore plus si la taille du lot en masse est inférieure à 200 enregistrements. Si chaque invocation met en file d'attente une tâche asynchrone, une partie importante de la limite quotidienne d'un chargement de données unique peut être consommée. Cette consommation peut potentiellement affamer d'autres processus métiers critiques des ressources asynchrones.

- Les limites du gouverneur pour la mise en file d'attente des tâches sont radicalement différentes selon le contexte. Depuis un déclencheur déclenché par une action utilisateur dans l'interface utilisateur (une transaction _synchrone_), jusqu'à 50 tâches pouvant être mises en file d'attente peuvent être mises en file d'attente. Cependant, à partir d'un déclencheur déclenché par la méthode `execute` d'une classe Apex par lot - une transaction _asynchrone_ - une seule tâche pouvant être mise en file d'attente peut être mise en file d'attente. Ne pas tenir compte de cette différence est un point d'échec commun et critique, qui entraîne des erreurs de `LimitException` lors d'opérations de données volumineuses.

- Appeler Apex planifiable (`System.schedule`) ou Apex par lot (`Database.executeBatch`) directement à partir d'un contexte de déclencheur constitue un anti-pattern. Ces méthodes ne sont pas conçues pour être invoquées à partir du contexte du déclencheur. Cela entraînera une consommation rapide de votre allocation Apex asynchrone, entraînant des exceptions de limite.

### Choix du modèle asynchrone approprié

Chaque mécanisme asynchrone a des compromis spécifiques en termes de performance, de limites du gouverneur et de fiabilité. Utilisez cet arbre de décision comme guide pour vous aider à parcourir ces options et à choisir le mécanisme adapté à votre cas d'utilisation.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/async-pattern.png" alt="Arbre de décision du modèle asynchrone">

### L'alternative de la tâche planifiée

Comme l'indique le diagramme, lorsque vous êtes confronté à des opérations DML à haut volume, mais que vous ne pouvez pas utiliser la Capture des données de modification (peut-être en raison des limitations des objets), le meilleur choix architectural est souvent d'éviter entièrement un processus invoqué par le déclencheur.

Vous pouvez à la place utiliser un processus planifié. Cela peut être soit un flux planifié, soit Apex planifié. Les étapes requises sont :

1. Effectuez une mise à jour simple et économique dans le déclencheur synchrone. Par exemple, définissez un champ de `Status__c` sur « traitement en attente » ou insérez un enregistrement associé peu coûteux, par exemple une publication Chatter, pour indiquer que l'enregistrement doit être traité.

2. Créez une tâche planifiée, soit un flux planifié ou Apex planifié, qui est exécutée périodiquement, par exemple toutes les 15 minutes ou toutes les heures.

3. Définissez la requête de tâche planifiée pour tous les enregistrements à l'état en attente, exécutez la logique complexe dans un contexte contrôlé à haut volume, puis mettez à jour les enregistrements tels qu'ils sont traités.

Ce schéma découple totalement le traitement lourd de l'enregistrement synchrone de l'utilisateur, n'est pas soumis à la limite d'une tâche par transaction d'un lot déclenché par un déclencheur, et offre une solution hautement évolutive et gouvernable pour les exigences en temps réel.

Si la latence d'une tâche planifiée n'est pas acceptable pour les exigences métiers, et que vous êtes toujours contraint d'utiliser CDC ou une file d'attente déclenchée par un déclencheur, cela indique un décalage architectural important. À ce stade, différents mécanismes doivent être envisagés. La réévaluation de la conception de l'application principale peut conduire à certaines conclusions, notamment :

- Achat du complément pour retirer les limites en objets CDC.

- Défiant fondamentalement l'exigence métier de déterminer si le traitement en temps quasi réel est vraiment un « must-have » ou si la latence d'une tâche planifiée est un compromis acceptable pour la stabilité de la plate-forme.

## Considérations non fonctionnelles

En plus des points de décision, vous devrez prendre en compte des considérations non fonctionnelles telles que la complexité et les normes.

### Complexité

Le niveau de complexité d'une implémentation fait partie du coût total de possession d'une solution, ainsi que de sa capacité à s'adapter aux exigences métiers changeantes. La complexité peut impacter n'importe quelle implémentation si les meilleures pratiques ne sont pas respectées. La section _Meilleures pratiques connexes_ de ce document contient des recommandations pour réduire la complexité de votre solution, notamment les modèles suivants :

- Modèle hybride : Apex invocable pour une logique complexe dans un flux

- Utilisation d'une infrastructure de métadonnées pour les déclencheurs Apex

- Méga-flux et flux multiples

### Processus et normes

La documentation est aussi importante que l'automatisation elle-même. Il garantit non seulement la maintenabilité, mais il est également essentiel pour l'IA et les outils basés sur l'agent. La documentation vous aide à comprendre et à gérer vos processus métiers.

**Dans Flow**

- Établissez une convention de nommage cohérente pour tous les éléments et variables.

- Utilisez le champ Description du flux pour expliquer son objet global, les critères de déclenchement et le résultat escompté.

- Utilisez le champ Description de chaque élément individuel (par exemple, `Get Records`, `Action`, `Transform`). Cette pratique est la meilleure façon de transmettre l'intention. Elle est particulièrement importante pour les actions invocables et les flux secondaires, où la description est l'emplacement principal pour expliquer la logique complexe exécutée par l'action.

**Dans Apex**

- Commentez clairement votre code pour expliquer le _pourquoi_ de votre logique, pas seulement le _quoi_.

- Si vous utilisez une infrastructure pilotée par les métadonnées, assurez-vous que vos enregistrements de métadonnées contiennent et remplissent un champ Description lisible par l'utilisateur pour expliquer ce que fait chaque classe gestionnaire et quand elle doit être exécutée.

Le DevOps et le contrôle du code source font partie d'un cycle de vie de développement mature. Utilisez toujours un outil de contrôle de code source tel que Git pour des projets Salesforce. Les classes Apex et les flux Salesforce sont des métadonnées qui définissent votre logique métier, et ils doivent être contrôlés et gérés par version.

Dans le contexte de la gestion des automatisations déclenchées par un enregistrement, un pipeline DevOps moderne offre des avantages essentiels.

- **Contrôles de qualité automatisés :** Des outils tels que [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) peuvent être configurés pour être exécutés automatiquement dans votre pipeline. L ' analyse statique peut détecter des modèles problématiques dans les deux outils d ' automatisation avant qu ' ils ne soient promus, en signalant des problèmes tels que des éléments de `Get Records` inefficaces dans une boucle de flux ou des requêtes `SOQL` dans une boucle Apex for, qui sont des causes courantes de dégradation des performances.

- **Prévention de la régression :** À mesure que votre densité d'automatisation augmente, un changement vers une classe Flux ou Apex peut avoir des conséquences involontaires sur d'autres automatisations dans le même objet. Une stratégie de test DevOps robuste, dans laquelle des tests Apex automatisés sont exécutés contre toute modification proposée, est la méthode la plus fiable pour s'assurer qu'une nouvelle version de flux ne rompe pas la logique Apex existante (et inversement).

- **Collaboration et visibilité :** Le contrôle de la source est la « source unique de vérité ». Il permet aux administrateurs et aux développeurs de travailler en parallèle sur l'automatisation d'un même objet. Il fournit également un parcours d'audit inestimable : Lorsqu'un processus de production se rompt, vous pouvez déterminer instantanément _qui_ a modifié l'automatisation, _quand_ ils l'ont modifiée et, via des messages d'engagement, _pourquoi_ ils l'ont modifiée.

[DevanOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) fournit une interface unifiée qui facilite la chorégraphie de toutes ces étapes pour permettre à tous les membres de l ' équipe d ' accéder à un processus de développement évolutif, basé sur le contrôle des sources.

Cette discipline combinée de documentation et de DevOps garantit la santé et la maintenance à long terme de votre organisation, ce qui profitera à chaque architecte et administrateur qui vous suit.

## Meilleures pratiques associées

Le guide de décision ci-dessus est préférable avant de planifier votre implémentation. Il vise à vous aider à choisir le meilleur produit pour vos cas d'utilisation. Après la sélection du produit, il est important de comprendre les meilleures pratiques existantes pour votre implémentation.

### Exploitez le modèle hybride : Apex invocable pour une logique complexe dans un flux

Le principe _Un outil par objet_ est essentiel pour gérer l'automatisation à haute densité, mais ne l'interprètez pas comme un choix binaire entre une pile purement déclarative ou purement programmatique. Un modèle architectural plus efficace et plus facile à maintenir exploite un modèle hybride : positionner Flux déclenché par un enregistrement en tant que couche d'orchestration, tout en encapsulant les opérations hautement complexes au sein d'Apex invocable.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/hybrid-pattern.png" alt="Diagramme du modèle hybride">

#### La couche d’orchestration : Flux

Le Flow déclenché par un enregistrement sert de couche d’orchestration au processus métier. Il est propriétaire des critères d'entrée et du contexte d'exécution (le _quoi_ et _quand_). En conservant la logique de décision et l'acheminement au sein de cette couche, la topologie des processus de l'architecture reste transparente et gérable via l'Explorateur de déclencheur de flux, ce qui évite que la logique métier critique soit masquée dans le code.

#### Le composant complexe : Apex invocable

Un exemple courant de composant complexe est l'implémentation de calculs d'accord de niveau de service (SLA) pour des enregistrements Requête. Comme l'objet BusinessHours et sa logique associée — critique pour des calculs précis qui excluent les heures non travaillées et les congés — n'est pas accessible en natif dans Flux, une classe Apex dédiée est utilisée. Cette classe, souvent appelée `ServiceLevelAgreementCalculator`, est conçue avec une méthode statique unique, annotée avec `@InvocableMethod`, pour calculer les heures ouvrables écoulées, déterminer si l'accord de niveau de service est « Dans les limites de l'objectif » ou « Atteint », et renvoyer une sortie structurée. Cette approche encapsule la logique complexe et performante dans Apex tout en permettant son exécution transparente et son intégration dans la couche d'orchestration déclarative d'un flux déclenché par un enregistrement.

Une fois la classe `ServiceLevelAgreementCalculator` Apex définie, elle peut être utilisée dans un flux déclenché par un enregistrement :

Ce schéma démontre une stricte séparation des préoccupations. La couche déclarative est utilisée pour gérer le cycle de vie et l'orchestration des transactions, tandis que le code est utilisé pour l'exécution complexe. En traitant le code comme un utilitaire fonctionnel plutôt que comme la fondation, nous équilibrons les performances et la maintenabilité.

#### Principaux gains avec le schéma hybride

**Modularité**: La décision s'éloigne de l'utilisation exclusive d'Apex ou Flow pour l'ensemble du processus. À la place, l'architecture encapsule une logique complexe dans des unités discrètes, sûres en masse et testables indépendamment. Ces unités fonctionnent comme des composants réutilisables consommés par la couche déclarative, assurant les échelles d'automatisation sans compliquer la conception architecturale.

**Réutilisabilité**: La logique est découplée de l'événement déclencheur. Une unité de code bien conçue (telle qu'une `InvocableMethod`) est écrite une seule fois, mais exploitée à travers plusieurs points d'entrée : Flux déclenchés par un enregistrement, flux d'écran ou intégrations externes. Cette réutilisation de code élimine les développements redondants.

**Maintenabilité**: La logique de flux de processus reste visible et gérable dans le flux déclaratif. Cette centralisation réduit considérablement les frais de débogage et garantit que l'ordre d'exécution du système est déterministe et transparent.

#### Limitations et compromis du modèle hybride

Bien que le modèle hybride d'utilisation d'Apex invocable à partir d'un flux soit puissant, il ne s'agit pas d'une approche unique. Les architectes doivent être conscients des limitations et des compromis spécifiques avant de s'engager dans une solution hybride.

- **Aucun support avant la sauvegarde**: C'est la limite la plus critique. Les actions invocables sont disponibles uniquement dans le contexte après la sauvegarde (flux d'actions et d'enregistrements associés). Ils ne peuvent pas être utilisés dans le contexte très performant avant la sauvegarde (flux de mises à jour de champ rapides). Par conséquent, ce modèle ne peut pas être utilisé pour déléguer les mises à jour de champ du même enregistrement. Exécutez ce travail très performant en utilisant des éléments Flux natifs dans un flux avant la sauvegarde ou dans un déclencheur Apex avant le contexte.

- **Aucun support after-undelete :** Actuellement, le flux déclenché par un enregistrement ne prend pas en charge le contexte after-undelete. Si un Objet Salesforce a une exigence métier pour exécuter une automatisation lorsqu'un enregistrement est restauré depuis la corbeille, un déclencheur Apex est la seule solution.

- **Surcharge de performance dans les scénarios à haut volume :** Le passage de l'exécution du flux à l'exécution Apex n'est pas une opération à coût nul. Bien que généralement rapide, l'action de tomber dans une Action invocable à partir de l'exécution de Flux n'est pas aussi rapide en calcul que l'exécution native qui reste entièrement dans un déclencheur Apex. Pour la plupart des automatisations à densité moyenne, ce micro-coût est un compromis négligeable et intéressant pour l'accessibilité accrue. Cependant, pour des scénarios extrêmement performants et à haut volume, une infrastructure Apex uniquement pure aura un avantage de vitesse de calcul brute.

### Stratégies pour l'automatisation héritée

Bien que l'heuristique de densité de l'automatisation fournisse des orientations définitives pour une architecture nouvelle, la réalité des environnements Salesforce d'entreprise est souvent plus nuancée. Dans les organisations matures, il est courant de trouver des flux déclenchés par un enregistrement et des déclencheurs Apex fonctionnant sur le même Objet Salesforce. Ce scénario se distingue du schéma hybride expliqué précédemment : Ici, les flux et les déclencheurs Apex ne sont ni couplés, ni conçus pour fonctionner ensemble.

Cette coexistence est souvent le résultat de l'évolution des capacités de la plate-forme ou de la dette technique héritée. Bien que cet état opérationnel soit toléré, les architectes doivent le traiter comme un compromis calculé plutôt que comme un état final.

L'orchestration fragmentée entraîne des coûts de gouvernance et de maintenance importants, ce qui rend les activités de développement, de test et de gestion des incidents difficiles et complexes. Cela entraîne une augmentation du délai de résolution (TTR) et de la complexité opérationnelle.

- Pour les nouveaux objets Salesforce, suivez le principe de densité d'automatisation comme guide principal.

- Pour les objets Salesforce existants présentant une empreinte hybride, avec à la fois un déclencheur Apex et un flux déclenché par un enregistrement, évaluez la densité, puis concevez l'architecture afin de refactoriser vers un état hybride maintenable.

  - Pour une faible densité, refactorisez Apex déclenche des flux déclenchés par un enregistrement, et spécifiez l'ordre d'exécution, en les amenant à un point d'entrée d'automatisation unique.

  - Pour une densité moyenne, refactorisez les méga-flux complexes dans un sous-ensemble de flux, avec le bon ordre d'exécution. Introduisez des déclencheurs Apex uniquement lorsque cela est absolument nécessaire, par exemple pour prendre en charge le contexte after undelete.

  - Pour une densité élevée, privilégiez l'implémentation de déclencheurs Apex.

### Utilisation d'une infrastructure de métadonnées pour les déclencheurs Apex

À mesure que les processus métier d'une organisation sur la plateforme Salesforce mûrissent, le volume et la complexité de l'automatisation déclenchée par l'enregistrement augmentent inévitablement. Une meilleure pratique fondamentale consiste à maintenir _un déclencheur Apex par objet Salesforce_. Cette règle est critique, car la plate-forme ne garantit pas l'ordre d'exécution de plusieurs déclencheurs sur le même objet pour le même événement. Cette limitation peut entraîner un comportement non déterministe, des conditions de course et des problèmes difficiles à déboguer.

Cependant, l'adhésion au principe d'_un déclencheur_ introduit un défi architectural : comment gérer et orchestrer de manière maintenable et évolutive toute la logique métier invoquée à partir de ce point d'entrée unique.

#### Limitations des gestionnaires Classic Trigger Handler

La première évolution de cette architecture a été le modèle Classic Trigger Handler. Dans cette approche, le déclencheur Apex unique délègue toute sa logique à une classe gestionnaire correspondante (par exemple, `OpportunityTriggerHandler`). Cette méthode sépare la logique du fichier déclencheur et fournit aux développeurs un contrôle déterministe sur l'ordre d'exécution dans les méthodes de la classe gestionnaire (par exemple, `afterInsert()`).

Bien qu'il s'agisse d'une amélioration, ce modèle conduit souvent à des classes de gestionnaire monolithiques. Au fil du temps, à mesure que les exigences métiers augmentent, la classe devient grande, difficile à gérer et difficile à tester isolément. L'ordre d'exécution de tous les processus individuels est codé en dur dans une seule méthode, ce qui rend la classe sujette aux conflits de fusion, augmentant considérablement les coûts de gouvernance et de maintenance dans un environnement de grande entreprise.

#### La solution : Une infrastructure de déclencheurs pilotée par les métadonnées

Pour résoudre les problèmes fondamentaux de modularité et d'orchestration, les architectes adoptent une **infrastructure de déclencheurs** pilotée par les métadonnées. Il s'agit d'un saut architectural important qui dissocie la logique d'automatisation elle-même de la configuration de _son_ exécution et _de sa date_ d'exécution.

Cette infrastructure repose sur trois avantages clés :

- **Partitionnement :** Au lieu d ' une seule classe gestionnaire, la logique métier de base est divisée en petites classes Apex atomiques (par exemple, une classe `RecalculateAccountValues` ou une classe `NotifySalesLeads`), chaque classe adhérant au _principe de responsabilité_ unique. Cette modularité facilite le test, le débogage et la compréhension isolés de la logique.

- **Ordre et chorégraphie :** L'ordre d'exécution n'est plus codé en dur dans Apex. À la place, il est défini par déclaration par des enregistrements de configuration, généralement stockés dans un type de métadonnées personnalisées (par exemple, `TriggerAction__mdt`). Cela permet aux administrateurs de réorganiser, d'ajouter ou de retirer des actions d'automatisation simplement en modifiant un enregistrement de métadonnées, ce qui ne nécessite pas de déploiement ni de changement de code.

- **Fonctionnalité de contournement :** L'infrastructure fournit une fonctionnalité de contournement standardisée et granulaire. Chaque action d'automatisation peut être configurée via son enregistrement de métadonnées pour être désactivée globalement, ou contournée pour des utilisateurs administratifs spécifiques en référençant une autorisation personnalisée.

Le déclencheur Apex unique de l'objet sert alors uniquement de répartiteur dynamique. Il ne contient aucune logique métier, mais instancie à la place une classe `MetadataTriggerHandler` centrale. Ce gestionnaire interroge les enregistrements de métadonnées personnalisées pour déterminer dynamiquement la séquence d'exécution et invoquer les classes Apex atomiques correctes dans l'ordre prescrit. L'automatisation est unifiée sous une couche unique, transparente et gouvernable.

### La déduplication des opérations coûteuses dans la transaction

Un avantage important de l'utilisation Apex dans une infrastructure robuste est la possibilité de gérer l'état transactionnel et d'optimiser les performances en éliminant le travail redondant. À mesure que la logique s'accumule, il est fréquent que différentes automatisations dans l'ordre d'enregistrement exécutent indépendamment les mêmes opérations coûteuses, ce qui consomme les limites du gouverneur et augmente le temps d'exécution des opérations DML.

Le cadre est conçu pour répondre à ce besoin avec deux stratégies principales :

- **Gestion d'état partagée :** Dans le cadre d'une transaction Apex unique, les propriétés et les variables statiques sont exploitées pour mettre en cache les données. Ainsi, une opération coûteuse, par exemple une requête `SOQL` pour un paramètre de configuration, n'est exécutée qu'une seule fois, même si la logique d'automatisation est invoquée plusieurs fois dans différents enregistrements ou phases du déclencheur. La consommation de limites transactionnelles est considérablement réduite.

- **Utilisation du cache de la plateforme :** Pour aller au-delà de la simple mise en cache intra-transaction, utilisez le cache de la plate-forme afin d'éviter d'interroger certaines données dans la base de données complète. Ce cache géré en mémoire est idéal pour récupérer des données non primitives, lues fréquemment dans la base de code et immuables tout au long d'une transaction (par exemple, profils, rôles, heures ouvrables). En utilisant l'interface `Cache.CacheBuilder`, le système vérifie d'abord le cache et exécute la requête de base de données uniquement si les données sont absentes, ce qui optimise les performances et l'évolutivité.

### Utilisation de Before-Save pour les mises à jour du même enregistrement

Utilisez toujours une mise à jour avant la sauvegarde lorsque votre automatisation doit modifier uniquement les valeurs de champ dans l'enregistrement qui démarre la transaction. Cela s'applique aussi bien aux mises à jour de champ rapide dans Flux (qui s'exécutent avant la sauvegarde) qu'à la logique avant le contexte dans Déclencheurs Apex (avant l'insertion, avant la mise à jour).

Ce schéma est performant, quel que soit l'outil utilisé, car il évite une deuxième opération DML et un cycle d'enregistrement récursif. Les modifications sont apportées à l'enregistrement en mémoire _avant_ son engagement dans la base de données et sont enregistrées dans le cadre de la transaction d'origine. Les frais généraux d'une deuxième sauvegarde, qui autrement réexécuterait l'ordre de sauvegarde complet et déclencherait de nouveau toute l'automatisation, sont éliminés.

### Prévention de la récursion incontrôlée

La récursion non contrôlée est un piège courant dans les déclencheurs après mise à jour, où la logique d'un déclencheur effectue une mise à jour DML qui entraîne à son tour le déclenchement du même déclencheur. Cela crée une boucle infinie qui se termine par une exception de limite du gouverneur. Bien que des indicateurs booléens statiques ou des collections d'ID d'enregistrement traités aient toujours été utilisés pour empêcher une telle récursion, un modèle plus précis et plus robuste consiste à lier la logique en comparant les valeurs de champ entre la nouvelle et l'ancienne version de l'enregistrement lui-même.

Exécutez la logique uniquement si un champ d'intérêt spécifique a changé. Cela empêche le déclencheur d'exécuter sa logique sur les opérations DML suivantes dans la même transaction où les données critiques restent inchangées.

#### Contrôle de la récursion dans un flux déclenché par un enregistrement

Dans un flux déclenché par un enregistrement, empêchez la récursion incontrôlée en définissant l'exécution du flux uniquement lorsque l'enregistrement est mis à jour pour remplir les conditions requises :

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/recursion-flow.png" alt="Contrôle de la récursion dans un flux déclenché par un enregistrement">

Si vous choisissez d'utiliser une formule de critères d'entrée dans votre flux, vous pouvez empêcher une récursion galopante en comparant la variable globale `$Record` (représentant les nouvelles valeurs) à la variable globale `$RecordPrior` (représentant les valeurs d'origine avant l'enregistrement). Par exemple, pour vous assurer qu'un flux est exécuté uniquement si le champ Montant d'une opportunité a changé, utilisez-le dans les critères d'entrée :

```
$Record.Amount != $Record__Prior.Amount
```

#### Contrôle de la récursion dans Apex

Comparez les valeurs de champ de la nouvelle version de l'enregistrement, `Trigger.new`, aux valeurs de champ de l'ancienne version de l'enregistrement, `Trigger.oldMap`, pour déterminer si la modification spécifique que vous recherchez s'est produite. Cette approche garantit que l'automatisation est idempotente et exécutée uniquement lorsque nécessaire, ce qui rend le système plus efficace et évite les boucles récursives catastrophiques.

### Contournement de l'automatisation

Une organisation Salesforce bien architecturée nécessite un mécanisme cohérent et fiable pour contourner l'automatisation. Il ne s'agit pas d'une fonctionnalité facultative, mais d'une exigence opérationnelle essentielle pour préserver l'intégrité des données et activer les tâches administratives.

Un cadre de contournement est essentiel pour certains scénarios :

- Lors du chargement de volumes de données importants, le déclenchement de déclencheurs pour chaque enregistrement peut ralentir considérablement le processus, entraîner des exceptions de limite et créer des enregistrements et des notifications associés erronés. Un contournement permet d'insérer les données proprement et efficacement.

- Un utilisateur de l'intégration peut avoir besoin de synchroniser des données à partir d'un système d'enregistrement externe. L'automatisation normalement déclenchée pour une modification initiée par l'utilisateur (par exemple, envoyer un e-mail, créer une tâche) peut être indésirable ou redondante lorsque la modification provient d'un autre système.

- Les administrateurs ou le personnel de support peuvent avoir à effectuer des mises à jour correctives sur les enregistrements. Un mécanisme de contournement leur permet d'effectuer ces modifications sans déclencher l'automatisation métier standard, ce qui pourrait avoir des conséquences inattendues.

**Autorisations personnalisées**: La norme moderne et évolutive pour l'implémentation d'une logique de contournement est celle des autorisations personnalisées. Elles sont supérieures aux anciennes méthodes pour plusieurs raisons :

- **Flexibilité :** Des autorisations personnalisées peuvent être attribuées à des utilisateurs via des ensembles d'autorisations. Cette pratique s'aligne sur le modèle moderne de sécurité et d'accès de Salesforce, ce qui permet une attribution granulaire et flexible. Un contournement peut être accordé à un utilisateur spécifique, ou même temporairement avec une date/heure d'expiration spécifique.

- **Maintenabilité :** L'utilisation d'autorisations personnalisées évite de coder en dur des profils ou des utilisateurs dans une logique d'automatisation. Si le rôle d'un utilisateur change ou si un nouveau profil doit contourner l'accès, la modification est une simple attribution d'ensemble d'autorisations, pas une modification de code ou de flux qui nécessite un déploiement.

- **Évolutivité :** Les autorisations personnalisées offrent une infrastructure évolutive pour gérer les exceptions dans une base d'utilisateurs complexe. Ils peuvent être attribués à des utilisateurs via un ensemble d'autorisations, des groupes d'ensembles d'autorisations ou des profils. Leur association à un ensemble d'autorisations ou à un profil peut également être représentée dans les métadonnées sources.

**Schémas d'implémentation**: Appliquez un modèle de contournement cohérent à toutes les automatisations déclenchées par un enregistrement dans l'organisation.

**Contournement d'un flux déclenché par un enregistrement**: La méthode la plus efficace pour contourner un flux est d'empêcher son exécution. Pour ce faire, ajoutez une condition aux critères d'entrée du flux.

- Dans l'élément Démarrer du flux déclenché par l'enregistrement, définissez les exigences de condition sur « La formule est vraie ».

  - Dans le générateur de formule, incorporez une vérification de l'autorisation personnalisée en utilisant la variable globale `$Permission`. Combinez la vérification à vos critères d'entrée existants.

    - Modèle de formule :

    ```
    ( ) && NOT($Permission.Bypass_This_Flow)
    ```

  - Ce modèle garantit que le flux est exécuté uniquement si l'utilisateur _n'_a pas l'autorisation personnalisée spécifiée attribuée. Ce contrôle est effectué avant même la création de l'interview de flux, ce qui en fait l'approche la plus performante.

**Contournement d'une infrastructure de déclencheurs Apex**: Dans Apex, intégrez la logique de contournement directement à l'infrastructure de déclencheur pilotée par les métadonnées, ce qui permet un contrôle granulaire.

- Le type de métadonnées personnalisées `TriggerAction__mdt` doit inclure un champ de texte, par exemple `BypassPermission__c`.

  - Dans la classe `MetadataTriggerHandler`, avant d'exécuter dynamiquement une action, le code doit lire la valeur de ce champ.

  - Si le champ est rempli, le gestionnaire utilise la méthode `FeatureManagement.checkPermission()` pour déterminer si l'utilisateur actif actuel dispose de l'autorisation personnalisée spécifiée.

  - Si `checkPermission()` renvoie true, le gestionnaire ignore cette action spécifique et passe à la suivante dans la séquence.

  - Ce modèle est puissant, car il permet à la fois un contournement global (si tous les enregistrements `TriggerAction__mdt` référencent la même autorisation) et un contournement granulaire par action (si différents enregistrements référencent différentes autorisations, ou si certains n'ont aucune autorisation de contournement du tout).

### Méga-flux et flux multiples

C'est un anti-pattern de consolider toute l'automatisation d'un objet en un seul méga-flux massif. La consolidation en un seul flux par opposition à la séparation d'une logique en plusieurs flux bien conditionnés n'a pas d'impact majeur sur les performances. Les gains de performance les plus importants proviennent des éléments suivants :

- Utilisation de flux avant la sauvegarde pour les mises à jour de champ du même enregistrement.

- Écriture de conditions d'entrée précises afin d'empêcher l'exécution de flux avec des modifications qui n'impactent pas leur cas d'utilisation spécifique.

[L'Explorateur de déclencheur](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer) de flux permet d'attribuer une valeur d'ordre à chaque flux d'un objet, garantissant ainsi un ordre d'exécution séquentiel.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/trigger-explorer.png" alt="Explorateur de déclencheur de flux">

## Ressources

<table>
  <thead>
    <tr>
      <th scope="col">Apex</th>
      <th scope="col">Flux</th>
      <th scope="col">Opérations</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Qu'est-ce qu'Apex ?</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_integration_intro.htm">Apex Utilities</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">À propos de l'automatisation avec Salesforce Flow</a></li>
          <li><a href="https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer">Découvrez l’Explorateur des déclencheurs de flux</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Élément de transformation de flux</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html">Salesforce Code Analyzer</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5">DevOps Center</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

<!-- document id=d1e466b722b62b809d6ef607b655dad78d80d434d79b17744ee4781c7d99f510 url=/architect/current/fr-fr/decision-guides/guides/build-forms.md -->

# Création de formulaires

Il existe plusieurs options pour élaborer des formulaires sur Agentforce 360 Platform, et elles couvrent un continuum allant des approches low-code aux approches pro-code. À une extrémité du continuum, les Formulaires dynamiques dans le Générateur d'applications Lightning et les flux d'écran dans Flow Builder peuvent être utilisés pour des solutions à faible code. D'autre part, l'infrastructure Lightning Web Component (LWC) est utilisée pour les solutions pro-code. Dans le continuum, les outils peuvent être fusionnés de plusieurs façons en utilisant des flux d'écran étendus par des composants Web Lightning et des formulaires destinés aux clients élaborés en utilisant Omnistudio.

## Présentation du guide

Ce guide présente un cadre de décision et des conseils sur l'élaboration de formulaires pour des solutions d'interface utilisateur. Plus précisément, il utilise une douzaine de points d'exécution et de décision non fonctionnels afin de sélectionner correctement la meilleure technologie pour un cas d'utilisation donné.

## Points à retenir

- **Lorsque vous élaborez des présentations Créer/Modifier/Afficher pour des pages Lightning, utilisez des Formulaires dynamiques.** À l ' avenir, nous recommandons d ' utiliser des _formulaires dynamiques_ dans _le Générateur d_ ' applications Lightning pour configurer des pages de détail d ' enregistrement.

- **Si vous devez élaborer, créer ou modifier un formulaire pour un seul objet, utilisez _des pages Lightning_ et _des formulaires dynamiques_.** C'est la méthode la plus simple pour élaborer des formulaires sur la plateforme Agentforce 360. Il fournit également des fonctionnalités supplémentaires (par exemple, le contrôle de la visibilité des champs).

- **Si vous élaborez un formulaire de plusieurs pages ou un assistant et que vous n'avez pas d'exigences strictes en matière d'utilisation de l'image de marque, utilisez un flux d'écran.** Les flux d'écran fournissent une infrastructure de navigation linéaire pour l'orchestration de plusieurs formulaires. Vous pouvez utiliser des composants Web Lightning pour construire votre propre infrastructure de navigation entre les formulaires, mais nous recommandons de laisser Flow faire le travail afin de vous concentrer sur les formulaires eux-mêmes plutôt que sur l'état du formulaire.

- **Si vous avez besoin d'une logique ou d'actions supplémentaires pour prendre en charge le formulaire, utilisez un flux d'écran, Omnistudio ou des composants Web Lightning.** Chacun de ces outils offre différentes façons d'améliorer votre solution en l'élargissant au-delà de la création ou de la modification d'un seul enregistrement. Dans le cas présent, le terme _plus_ peut désigner une logique avancée (par exemple branchement ou itération), ou des actions telles que l'intégration à des systèmes externes, l'envoi d'e-mails ou la transmission automatique de notifications à l'application mobile d'un utilisateur.

- **Si vous avez des exigences UX sophistiquées ou si vous devez gérer dynamiquement plus que la visibilité de l'interface utilisateur, utilisez LWC ou Omniscript.** Pour les exigences qui peuvent être satisfaites en utilisant des présentations basées sur des thèmes et des colonnes, vous pouvez élaborer vos formulaires directement dans un outil de création low-code. Cependant, un contrôle précis du style de votre formulaire nécessite la flexibilité de LWC. Si vous êtes un client de Industries (et que vous avez besoin d'une marque parfaite ou que vous avez des données hiérarchiques complexes), utilisez Omnistudio, qui permet d'élaborer des formulaires de niveau consommateur capables de gérer une logique métier complexe et des transformations de données.

- **Si vous devez déployer une automatisation test, utilisez LWC.** Vous pouvez écrire des tests unitaires pour n'importe quel Composant Web Lightning, quel que soit son emplacement d'incorporation. Cela permet de créer une stratégie de test plus robuste, qui peut inclure des tests en masse avec plusieurs enregistrements, ainsi que des tests négatifs.

- **Vous n'êtes pas limité à des décisions « soit/ou ».** Vous pouvez combiner plusieurs options pour trouver la meilleure solution pour vos cas d'utilisation (par exemple, si vous avez besoin du système de navigation intégré de Flow et de la flexibilité de style totale offerte par LWC, vous pouvez les utiliser ensemble).

## Outils dans Étendue

Les outils suivants sont fréquemment utilisés pour implémenter et étendre les expériences de formulaire.

### Descriptions des outils

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Formulaires dynamiques</th>
<th colspan="1" rowspan="1">Les <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_migrate.htm&language=en_US&type=5">formulaires dynamiques</a> du <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Générateur d'applications</a> Salesforce Lightning divisent les composants Détail d'enregistrement monolithiques en champs et sections individuels et configurables. Cette fonctionnalité permet aux administrateurs de créer des pages flexibles et performantes en plaçant des champs n'importe où et en utilisant des règles de visibilité pour afficher ou masquer des composants basés sur le profil utilisateur, l'appareil ou les données, ce qui réduit l'encombrement des pages.</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Un <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">flux d'écran</a> Salesforce est un outil d'automatisation interactif dans <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Flow Builder</a> qui nécessite l'entrée de l'utilisateur pour progresser à travers des processus métiers personnalisés, étape par étape. Contrairement aux flux d'arrière-plan automatisés, les flux d'écran offrent une interface utilisateur semblable à un assistant qui permet de collecter des données, d'afficher des informations, ou d'exécuter des actions via <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_page_overview.htm&type=5">des pages Lightning</a>, des boutons ou des applications personnalisées sans écrire de code.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Salesforce <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omnistudio_standard.htm&type=5">Omnistudio</a> est une suite d'outils à faible code conçue pour élaborer rapidement des expériences numériques guidées et spécifiques au secteur d'activité, et des processus métiers complexes. Il permet aux développeurs de créer des interfaces utilisateur parfaites en pixels (par exemple, des workflows guidés et des tableaux de bord dynamiques) en utilisant des composants glisser-déposer tels que <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_flexcardsbasics_8118.htm&type=5">des Flexcards</a> et <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">des Omniscripts</a>. Avec Omnistudio, vous pouvez créer de manière déclarative des LWC (Lightning Web Components).</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Composants Web Lightning</strong></td>
<td colspan="1" rowspan="1">Les <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">composants Web Lightning</a> Salesforce sont des éléments HTML personnalisés légers, élaborés en utilisant HTML, CSS et JavaScript moderne, et conçus pour être exécutés en natif dans les navigateurs afin d'améliorer les performances de l'interface utilisateur de Salesforce. Ils permettent aux développeurs de créer des interfaces utilisateur personnalisées qui coexistent avec des composants <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Aura</a>, ce qui augmente le développement grâce aux normes de l'industrie et à un écosystème de composants détaillé.</td></tr></table>

### Ensembles de compétences d'outil et exigences de licence

Le tableau ci-dessous présente les outils disponibles pour élaborer des formulaires via Salesforce, ainsi que leurs compétences requises et les considérations relatives aux licences.

**Note :** Nous approfondirons les fonctionnalités spécifiques prises en charge pour chaque outil, comment choisir entre les outils basés sur le clic et les outils basés sur le code, et quand les combiner dans une section ultérieure.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Configuration</th>
<th colspan="1" rowspan="1">Exigences de licence supplémentaires</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Code faible</td>
<td colspan="1" rowspan="1">Aucun</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Code faible</td>
<td colspan="1" rowspan="1">Aucun</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Low Code + Pro Code</td>
<td colspan="1" rowspan="1">Industries Package</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran plus composants Web Lightning</strong></td>
<td colspan="1" rowspan="1">Low Code + Pro Code</td>
<td colspan="1" rowspan="1">Aucun</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Composants Web Lightning</strong></td>
<td colspan="1" rowspan="1">Code Pro</td>
<td colspan="1" rowspan="1">Aucun</td></tr></table>

## Points de décision

Il y a plusieurs points de décision à prendre en compte lors de la sélection de produits et d'outils. Le tableau ci-dessous présente divers points de décision et fournit des orientations générales.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Point de décision</th>
<th colspan="1" rowspan="1">Guide</th></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Catégories de cas d'utilisation à l'exécution</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Étendue du formulaire et navigation</strong></td>
<td colspan="1" rowspan="1">Déterminez si tous les champs de votre formulaire s'adapteront logiquement à un seul écran ou si les utilisateurs doivent pouvoir naviguer entre plusieurs écrans.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Emplacement</strong></td>
<td colspan="1" rowspan="1">Identifiez le ou les emplacements où vous souhaitez incorporer le formulaire, qui peuvent aller d'une application Salesforce à une application mobile en passant par un site Web externe.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Contrôleur</strong></td>
<td colspan="1" rowspan="1">Identifiez les actions ou la logique qui doivent être exécutées en arrière-plan lorsque les utilisateurs interagissent avec votre formulaire, y compris les transformations de données et les intégrations à des systèmes externes.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Validation</strong></td>
<td colspan="1" rowspan="1">Déterminez si vous avez des exigences de validation d'entrée supplémentaires qui vont au-delà de la validation au niveau système standard fournie par Salesforce.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Conception de l’interaction</strong></td>
<td colspan="1" rowspan="1">Identifiez les types d'interaction ou de condition qui doivent déclencher des réponses dynamiques dans votre formulaire.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Style</strong></td>
<td colspan="1" rowspan="1">Déterminez le niveau de sophistication nécessaire pour votre style et vos exigences CSS.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Présentation</strong></td>
<td colspan="1" rowspan="1">Identifiez les exigences de présentation de votre formulaire (par exemple, le nombre requis de colonnes, d'onglets et d'accordéons) et la possibilité d'afficher des blocs de données récurrents.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Traduction</strong></td>
<td colspan="1" rowspan="1">Déterminez si votre formulaire doit être traduit dans d'autres langues.</td></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Considérations non fonctionnelles</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Sécurité</strong></td>
<td colspan="1" rowspan="1">Déterminez si votre formulaire doit vérifier l'accès de l'utilisateur avant d'effectuer certaines opérations, si vous souhaitez contrôler qui peut accéder au formulaire et si vous souhaitez contrôler l'emplacement où le formulaire peut être incorporé.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Impact sur l'objet</strong></td>
<td colspan="1" rowspan="1">Déterminez si votre formulaire fonctionne avec un seul objet ou avec plusieurs objets.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Automatisation des tests d'interface utilisateur</strong></td>
<td colspan="1" rowspan="1">Déterminez si vos processus DevOps nécessitent que votre formulaire soit soumis à des tests unitaires automatisés ou à des tests de bout en bout automatisés.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Métriques</strong></td>
<td colspan="1" rowspan="1">Identifiez comment vous souhaitez suivre l'utilisation de votre formulaire, notamment les vues de page, le temps consacré au formulaire, les taux de réalisation et les taux de réussite.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Empaquetage et déploiement</strong></td>
<td colspan="1" rowspan="1">Déterminez comment vous souhaitez distribuer ou déployer votre formulaire une fois élaboré.</td></tr></table>

**Note :** Dans les tableaux de comparaison de décision suivants, quelques valeurs sont associées à une paire outil-fonctionnalité :

- **Disponible&nbsp;:** L'outil/la fonctionnalité fonctionne avec des considérations de base.

- **Non disponible&nbsp;:** Il n'est pas prévu d'ajouter un support dans les douze prochains mois.

- **Pas idéal&nbsp;:** Cet outil/cette fonctionnalité peut fonctionner, mais ce n'est pas l'outil optimal.

- **Non applicable&nbsp;:** L'outil ne s'applique pas au cas d'utilisation particulier.

## Cas d'utilisation

Utilisez ces scénarios pour comparer les choix d'outillage basés sur la portée, l'expérience utilisateur et les besoins opérationnels.

### Étendue et navigation du formulaire

Si vous pouvez obtenir toutes vos entrées utilisateur à partir d'un formulaire à écran unique, commencez par les Formulaires dynamiques. Notez que les formulaires dynamiques dans les pages d'enregistrement peuvent utiliser la fonctionnalité Parcours pour prendre en charge les processus métiers intermédiaires.

#### Questions à poser

- Avez-vous besoin d'un seul écran ou l'utilisateur doit-il naviguer entre plusieurs écrans pour réaliser une tâche ?

- Voulez-vous que vos utilisateurs affichent une représentation visuelle de leur progression dans le processus en remplissant votre formulaire ? Vos utilisateurs devront-ils remplir les informations de chaque écran dans un ordre spécifique ou pourront-ils passer d'un écran à l'autre si nécessaire ?

Si vous avez besoin de fonctionnalités supplémentaires que celles offertes par les formulaires dynamiques, choisir entre Flux, Omnistudio et Composant Web Lightning dépend de quelques questions supplémentaires :

- Vous pouvez afficher une barre de navigation en bas de votre formulaire ? Si l'expérience de navigation Flux d'écran et Omniscript fournit une expérience utilisateur indésirable, penchez-vous vers LWC.

- Que doit-il se passer derrière le formulaire ? Si vous souhaitez que le comportement soit configurable par un administrateur, utilisez un flux. Pour des relations complexes et multi-objets, utilisez _Omniscript_ ou _LWC_.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Écran unique</th>
<th colspan="1" rowspan="1">Formulaire à écrans multiples</th>
<th colspan="1" rowspan="1">Indicateurs de progression</th>
<th colspan="1" rowspan="1">Navigation entre les étapes/écrans</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Pas idéal</td>
<td colspan="1" rowspan="1">Pas idéal</td>
<td colspan="1" rowspan="1">Pas idéal</td></tr></table>

Si vous choisissez Flow ou Omnistudio, il peut également être nécessaire d'élaborer un LWC pour obtenir l'expérience utilisateur appropriée. Si vous élaborez déjà un composant Web Lightning pour appliquer un style correct à votre formulaire, déterminez si l'[incorporation de ce composant à un flux](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow) est nécessaire.

**Navigation de style assistant**

Par contre, si votre solution ressemble à un assistant (où l'utilisateur navigue entre plusieurs écrans), pensez à Flux ou Omnistudio. Les flux et Omnistudio contiennent un modèle de navigation intégré, il n'est pas nécessaire d'élaborer et de gérer des composants Web Lightning enchaînés. La navigation est linéaire, avec des actions pour avancer, des actions pour reculer et un mécanisme de sauvegarde du formulaire pour plus tard. Vous pouvez également élaborer un formulaire avec une navigation non linéaire si cela vous convient.

Omnistudio offre un avantage de navigation clé en fournissant des indicateurs de progression de la navigation standard qui exposent les étapes dans le formulaire. La vue de l'étape affiche automatiquement l'emplacement d'un utilisateur dans un formulaire à plusieurs étapes. Contrairement à Flux, il permet aux utilisateurs de passer d'un écran à l'autre en cliquant sur diverses étapes du formulaire.

Que vous élaboriez des formulaires à écran unique ou à écrans multiples, il est important de rationaliser vos formulaires afin de faciliter leur navigation pour vos utilisateurs.

### Facteur de forme

Si vous incorporez un formulaire à une page d'enregistrement Lightning standard, tous les outils que nous comparons fonctionnent. Cependant, les Formulaires dynamiques ne sont actuellement disponibles que sur ordinateur de bureau. Si vous souhaitez offrir une expérience permettant aux utilisateurs d'accéder aux formulaires à partir d'autres emplacements, il peut être nécessaire d'envisager d'autres options.

#### Questions à poser

- Les utilisateurs doivent-ils accéder au formulaire par ordinateur de bureau, appareil mobile ou les deux ?

- Les utilisateurs doivent-ils pouvoir accéder au formulaire n'importe où dans votre application via une barre d'utilitaires ?

- Voulez-vous activer des actions rapides pour permettre aux utilisateurs de remplir votre formulaire sans quitter la page où ils se trouvent actuellement ?

- Votre formulaire doit-il être disponible sur un site Web externe ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Page d'enregistrement Lightning</th>
<th colspan="1" rowspan="1">Page d'accueil Lightning ou page d'application</th>
<th colspan="1" rowspan="1">Sites Experience Cloud Aura</th>
<th colspan="1" rowspan="1">Sites Experience Cloud LWR</th>
<th colspan="1" rowspan="1">Snap-ins intégrés</th>
<th colspan="1" rowspan="1">Barre d'utilitaires</th>
<th colspan="1" rowspan="1">Action spécifique à un objet</th>
<th colspan="1" rowspan="1">Action globale</th>
<th colspan="1" rowspan="1">Application mobile Salesforce*</th>
<th colspan="1" rowspan="1">Field Service Mobile</th>
<th colspan="1" rowspan="1">Mobile SDK</th>
<th colspan="1" rowspan="1">Sites et applications externes</th>
<th colspan="1" rowspan="1">Composant Web Lightning personnalisé</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible**</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Pas idéal</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="14" rowspan="1" style="border-right: 1px solid #d8dde6;">*Les flux et les composants Web Lightning sont pris en charge dans l'application mobile Salesforce, mais ils ne prennent pas en charge toutes les méthodes d'incorporation de flux et de composants Web Lightning (par exemple, les actions spécifiques à un objet sont prises en charge dans l'application mobile, mais pas les éléments de la barre d'utilitaires).<br><br>**L'application mobile Salesforce Field Service inclut Capture de données, une solution de formulaires hors ligne élaborée sur le moteur de flux avec une exécution hors ligne dédiée, prenant en charge les toutes dernières fonctionnalités de Flux. L'application inclut également les flux mobiles Field Service hérités, qui fonctionnent sur un ancien moteur hors ligne personnalisé, et ne prennent pas en charge la plupart des dernières fonctionnalités de flux.</td></tr></table>

Comme elle nécessite un contexte d'enregistrement, la fonctionnalité Formulaires dynamiques n'est prise en charge que dans les pages d'enregistrement Lightning. Cependant, les formulaires dynamiques ne sont pas pris en charge dans les pages Experience Cloud.

Vous pouvez élaborer des flux qui nécessitent un contexte d'enregistrement ou des flux qui fonctionnent globalement. En d'autres termes, vous pouvez incorporer des flux à divers emplacements. Pour des flux contextuels d'enregistrement, les emplacements peuvent inclure : Pages d'enregistrement Lightning, pages d'enregistrement Experience Cloud, actions spécifiques à un objet ou déploiements Actions et recommandations. Pour des flux globaux, les emplacements peuvent inclure : la barre d'utilitaires, d'autres pages Lightning ou Experience Builder, des snap-ins ou des applications externes. Actuellement, les flux ne sont pas pris en charge en tant qu'actions globales, mais vous pouvez insérer _les flux_ dans un composant _Aura_ pour contourner la situation.

Omnistudio permet d'élaborer des FlexCards et des Omniscripts composables que vous pouvez placer _presque_ partout où vous pouvez placer un Flow, mais bien qu'ils soient composables, ils ne sont pas packagés.

LWC offre un haut degré de réutilisation pour créer des composants qui peuvent être associés à des cibles via des métadonnées dans Salesforce, des communautés et des projets open-source. Les composants LWC peuvent également être incorporés à votre propre site Web en utilisant [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-locationnoheader.png" alt="Lightning Out on External Sites" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Les composants LWC peuvent également lancer des flux avec le composant [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation).

Omnistudio excelle dans l'exposition de contenus à des sites externes via la fonctionnalité OmniOut. Avec Omnistudio et OmniOut, vous pouvez compiler vos formulaires Omniscript et composants FlexCard dans des composants standard, puis les exécuter hors plate-forme dans des sites ou des applications tiers.

Actuellement, aucune des technologies de formulaire présentées dans ce guide n'est officiellement prise en charge dans les modèles Mobile SDK. Si Mobile SDK est essentiel à votre cas d'utilisation, nous recommandons d'élaborer votre formulaire en natif dans votre application mobile ou de construire une page Visualforce, tout en gardant le facteur de forme à l'esprit.

### Logique

Les formulaires dynamiques sont parfaits si vous devez utiliser les valeurs de votre formulaire pour créer ou mettre à jour un enregistrement. Vous devez exploiter Flow, Omnistudio ou LWC pour des capacités extérieures à ce périmètre, notamment la création de couches de décision ou d'itération, ou la génération de publications ou d'e-mails Slack en utilisant les entrées du formulaire.

#### Questions à poser

- Quelles actions ou logiques doivent être exécutées en arrière-plan ?

- Avez-vous besoin d'utiliser les valeurs d'un enregistrement associé ?

- Votre formulaire devra-t-il effectuer ses opérations dans une seule transaction ou dans plusieurs transactions ?

- Avez-vous besoin d'intégrer des systèmes externes ?

- Quelles sont vos exigences en matière de réutilisabilité et de modularité ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Journal et actions</th>
<th colspan="1" rowspan="1">Gestion des données hiérarchiques</th>
<th colspan="1" rowspan="1">Opérer dans une seule transaction</th>
<th colspan="1" rowspan="1">Opérer sur plusieurs transactions</th>
<th colspan="1" rowspan="1">Intégration</th>
<th colspan="1" rowspan="1">Conception modulaire et réutilisation</th>
<th colspan="1" rowspan="1">Emballage</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr></table>

Flow offre des actions standard pour publier dans Slack, envoyer des e-mails et interagir avec des documents Quip, et vous n'avez pas à écrire de code pour l'une de ces opérations. LWC offre des interactions enrichies avec des enregistrements uniques et des objets associés via des adaptateurs wire qui interagissent avec l'[API Interface utilisateur](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm). LWC peut également interagir avec plusieurs enregistrements en utilisant le wire pour [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-controllernoheader.png" alt="LWC Interaction via Wire Adapters" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio utilise des procédures d'intégration et Data Mapper pour obtenir et transformer des données (externes et internes à Salesforce). Grâce à de nombreuses fonctions sans code, il excelle dans l'aplatissement et l'expansion des jeux de données avec divers niveaux de relations.

Flow, Omnistudio et LWC s'intègrent tous à Apex. Vous pouvez ainsi combler aisément les écarts au sein de la solution que vous choisissez (par exemple, si vous avez besoin de filtrer les enregistrements d'un LWC, vous pouvez utiliser l'adaptateur wire pour Apex afin de créer des requêtes SOQL complexes. Si vous êtes influencé par les récits basés sur le clic, pensez à utiliser Flow ou Omnistudio comme alternative viable à un contrôleur Apex pour vos besoins côté serveur.

Vous devez également déterminer si vous souhaitez engager immédiatement des actions ou les reporter à une partie particulière de votre formulaire. Cela est particulièrement important si vous utilisez un formulaire de plusieurs pages. Le flux permet de combiner aisément les entrées de plusieurs formulaires (écrans de flux) et de les utiliser ultérieurement dans l'assistant (flux) pour effectuer certaines opérations. C'est exactement comme cela que nous recommandons de concevoir des flux. Exécuter des actions à la fin (au cas où les utilisateurs rebondissent entre les écrans pour changer leurs réponses).

#### Contrôle des opérations

Les transactions et les [limites du gouverneur](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) font partie intégrante de la plate-forme Agentforce 360. Si votre cas d'utilisation est assez simple, il peut ne pas être aussi important de contrôler la transaction où une opération particulière se produit. Cependant, il existe quelques cas d'utilisation dans lesquels vous pouvez combiner plusieurs opérations dans une seule [transaction](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#transactions) plutôt que de les exécuter dans plusieurs transactions.

Voici quelques exemples :

- **Rollback :** Supposons que votre formulaire crée plusieurs enregistrements en arrière-plan. Si la création d'un troisième enregistrement échoue, les deux premiers enregistrements doivent-ils être annulés ? Si chacune de vos actions est indépendante les unes des autres, vous pouvez les exécuter en tant que transactions séparées. Cependant, s'ils sont dépendants les uns des autres (et que vous souhaitez que l'échec de l'un annule également les autres), vous devez les implémenter en tant que transaction unique. Si votre formulaire est dans Flux, vous pouvez utiliser l'élément Restaurer dans le chemin Défaut pour annuler votre transaction et garantir l'intégrité des données.

- **Impact en aval sur les limites du gouverneur :** Lorsque votre formulaire crée ou met à jour un enregistrement, il est important de prendre en compte les implications en aval de cette opération :

  - Quels processus, règles de workflow, déclencheurs de flux, déclencheurs Apex ou autres éléments de l'ordre d'enregistrement peuvent se déclencher en fonction des modifications d'enregistrement proposées ?

  - Quel est l'impact de ces changements collectifs sur les limites du gouverneur consommées dans le cadre de cette transaction ?

  - Si une modification d'enregistrement particulière peut entraîner de nombreuses modifications en aval qui impactent vos limites, il peut être préférable d'isoler cette modification d'enregistrement dans sa propre transaction.

- **Traitement par lot :** Il peut être nécessaire de regrouper plusieurs mises à jour par lot (même dans un contexte d'interface utilisateur). Supposons que votre formulaire à écrans multiples itère sur un grand nombre d'enregistrements. Au lieu de valider une mise à jour d'enregistrement après chaque écran, attendez d'avoir collecté les mises à jour de tous les enregistrements, puis soumettez une requête de mise à jour de tous les enregistrements.

Lorsque vous utilisez des Formulaires dynamiques pour créer ou modifier un enregistrement, vous n'exécutez qu'une seule opération, qui est toujours le début d'une nouvelle transaction nette.

Lorsque vous élaborez un flux d'écran, vous avez un contrôle important sur ce qui se passe dans une transaction donnée. Les écrans et les actions locales agissent comme des frontières entre les transactions. Voici un résumé général de la gestion des transactions dans l'architecture de flux d'écran.

1. L'utilisateur interagit avec un écran, puis clique sur **Suivant**.

2. Le client publie une requête d'entrée dans l'API.

3. L'API reçoit la requête et ouvre une connexion de transaction et de base de données. L'API appelle ensuite le moteur de flux pour invoquer la requête.

4. Le moteur de flux prend le relais et suit le chemin approprié dans la définition du flux, jusqu'à ce qu'il atteigne un nœud d'écran ou d'action locale. Le moteur renvoie ensuite des informations sur ce nœud à l'API.

5. L'API crée un objet de réponse qui contient les détails de l'écran suivant à restituer, puis renvoie cet objet au client. À ce stade, les modifications de la base de données sont validées (selon l'[ordre d'enregistrement](/docs/architect/fr-fr/fundamentals/guide/architecture-basics#manipulation-de-la-base-de-données)), et la connexion à la base de données et la transaction sont fermées.

6. Le client utilise la réponse d'API pour restituer l'écran suivant avec lequel l'utilisateur interagit.

7. Commencez depuis l'étape 1 et répétez le processus.

En d'autres termes, les écrans _interrompent_ les transactions. Dans ce cas, toutes les actions en attente ou opérations DML sont validées, la transaction précédente est fermée et une nouvelle transaction commence.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow1.png" alt="multi-screen flow" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Notez que les éléments de conception spécifiques (opérations que vous regroupez dans une transaction donnée) vous appartiennent.

Voici quelques exemples :
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow2.png" alt="screen flow with separate transactions" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

- Au début, un flux collecte les entrées sur plusieurs écrans, puis exécute plusieurs actions dans une seule transaction.
- Le flux suivant effectue chaque opération dans une transaction séparée.
- Les flux peuvent également utiliser Restaurer les enregistrements pour vous permettre d'annuler une transaction complète si une seule opération échoue dans une série d'opérations de base de données.
  <image src="https://architect.salesforce.com/ns-assets/guide-forms-flow3.png" alt="Screen Flow with multiple create records" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
  Supposons que vous avez un flux qui crée des enregistrements, met à jour des enregistrements, puis crée des enregistrements supplémentaires (illustré dans le flux suivant).

Dans ce scénario, si les deux premiers éléments réussissent et que le dernier échoue, les deux premières opérations DML créent et mettent à jour les enregistrements appropriés, mais pas le troisième.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow4.png" alt="Screen Flow with Rollback" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
En utilisant l'élément Restaurer les enregistrements, vous pouvez vous assurer que la transaction complète est annulée si les trois opérations doivent être exécutées collectivement (comme indiqué dans le flux final).

**Note :** Pour plus d'informations, consultez [Flux dans les transactions](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) et [Traitement en masse des flux dans les transactions](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm).

Votre capacité à contrôler la transaction depuis un Composant Web Lightning est basée sur les services sous-jacents que le Composant Web Lightning utilise pour exécuter ses opérations. Si vous utilisez le composant de base Lightning, l'opération sous-jacente (création ou mise à jour de l'enregistrement) se produit dans une transaction autonome lors de la soumission du formulaire.

En général, les règles suivantes s'appliquent :

- Chaque appel d'API d'interface utilisateur est isolé dans sa propre transaction.

- Si vous devez effectuer plusieurs opérations dans une seule transaction, envoyez les entrées à une technologie côté serveur (par exemple, un contrôleur Apex ou un flux). Notez que les règles de transaction habituelles de cette technologie restent applicables.

#### Intégrations externes

Flow, Omnistudio et LWC prennent tous en charge les événements de plate-forme (pour l'[architecture pilotée par événement](/docs/architect/fr-fr/decision-guides/guide/event-driven)) et les intégrations d'API. En plus du code Apex personnalisé, Flow et Omnistudio ont des mécanismes de support déclaratif qui peuvent également s'intégrer à des API.

Si vous devez vous connecter à une API MuleSoft ou à un robot RPA, utilisez les Services MuleSoft, car ils génèrent un Service externe.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-mulesoftnoheader.png" alt="External integrations via MuleSoft" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Si l'API a un schéma OpenAPI, créez un Service externe.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-openapi-noheader.png" alt="External Integrations via OpenAPI" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Pour toutes les autres instances, utilisez la fonctionnalité **Appel externe HTTP** (propulsé par les Services externes) dans Flux ou l'**action HTTP** dans Omnistudio.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-callouts-noheader.png" alt="External integrations via HTTP" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio offre un riche ensemble de capacités d'intégration qui peuvent appeler des systèmes externes en utilisant des procédures d'intégration pour transformer les données via Data Mapper.

Que vous utilisiez un code Apex personnalisé ou un service externe pour l'implémentation, un **appel** reste un appel externe.

Voici ce que vous devez savoir.

- Le traitement d'un appel externe peut prendre beaucoup de temps.

- Lorsqu'un appel externe est exécuté de façon synchrone, il est exécuté alors qu'une transaction de base de données est ouverte.

- Salesforce ne permet pas de garder une transaction de base de données ouverte si vous avez des opérations de base de données en attente.

Notez que la principale limitation est le danger de laisser les données dans un état incohérent, qui se produit lorsque vous effectuez une opération **de création**, **de mise** à jour ou **de suppression**, puis exécutez un **appel externe** dans la même transaction. Ce schéma n'est pas autorisé en raison de la troisième considération mentionnée ci-dessus, qui existe pour les deux premières considérations.

Dans Flux, vous pouvez contourner cette limitation en rompant la transaction. Pour rappel, les écrans et les actions locales réintroduisent le contexte du navigateur. Vous pouvez utiliser des écrans et des actions locales lorsque vous travaillez avec des appels externes, mais nous recommandons d'activer le **Contrôle des transactions** dans les paramètres avancés invocables. Le Contrôle des transactions permet de terminer automatiquement la transaction avant qu'un appel externe soit passé. Pour activer le Contrôle des transactions, sélectionnez « **Toujours démarrer une nouvelle transaction** » dans la section **Avancé** de l'action invoquée.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow5.png" alt="External Integrations via Callouts" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
LWC simplifie l'impact des appels sur la transaction. En d'autres termes, effectuez vos opérations sur les données en utilisant le Lightning Data Service (LDS), puis utilisez un contrôleur Apex pour passer l'appel externe. Comme l'appel LDS est isolé dans sa propre transaction (distincte de l'appel externe Apex), cela vous protège contre l'incohérence des données qui en résulte.

#### Réutilisabilité et modularité

Les formulaires dynamiques ne prennent pas en charge la réutilisation. Chacune est liée à une page d'enregistrement Lightning spécifique pour un objet spécifique. Vous pouvez toutefois attribuer cette page d'enregistrement Lightning à plusieurs applications, profils, etc.

De la même façon que vous pouvez écrire des bibliothèques, des utilitaires et des composants qui peuvent être utilisés à travers plusieurs composants, vous pouvez également appliquer des modèles de conception similaires lorsque vous créez des flux en exploitant la puissance des **flux secondaires**. Pour cela, enregistrez vos flux dans des compartiments modulaires plus petits, puis appelez-les à partir d'autres flux en utilisant l'élément **Subflow**. Si votre conception l'exige, vous pouvez créer un flux qui soit utile à la fois de manière autonome et en tant que sous-flux.

Omnistudio est intrinsèquement construit pour la modularité. Les mappeurs de données, les Omniscripts, les FlexCards et les procédures d'intégration sont tous élaborés indépendamment, mais ils peuvent également fonctionner de façon interchangeable. Les FlexCards peuvent également être élaborées en tant que composants LWC qui peuvent être incorporés à d'autres composants LWC, Omniscripts, pages d'enregistrement et sites Experience Cloud.

Les flux d'écran, les Omniscripts et les Composants Web Lightning peuvent tous être conçus pour être réutilisés et incorporés à divers emplacements, y compris des sites externes et des applications Lightning Out. Lorsque vous concevez vos solutions pour qu'elles soient composables, vous bénéficiez également de capacités d'adaptation et de stabilité.

### Validation

Toutes les technologies utilisées pour créer ou mettre à jour des enregistrements doivent respecter la validation au niveau du système, qu'il s'agisse de règles de validation classiques ou de validations personnalisées intégrées à un déclencheur Apex. Quelle que soit la technologie utilisée pour effectuer des modifications d'enregistrement, chaque modification doit passer par l'ordre d'enregistrement. Cela signifie qu'en plus des règles de validation, les modifications d'enregistrement sont également traitées par un certain nombre de flux avant ou après la sauvegarde, avant ou après les déclencheurs, règles d'escalade, règles d'attribution, etc.

**Note :** Si ce n'est déjà fait, consultez et ajoutez [l’ordre d’exécution Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) aux favoris.

#### Questions à poser

- Votre formulaire a-t-il d'autres exigences que la validation au niveau système ?

- Vous devez définir dynamiquement des champs obligatoires ou en lecture seule dans le formulaire ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Respecter la validation au niveau système</th>
<th colspan="1" rowspan="1">Validation personnalisée au niveau du champ spécifique à ce formulaire</th>
<th colspan="1" rowspan="1">Validation personnalisée au niveau du champ</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr></table>

Généralement, les entrées d'un écran de flux ou d'une étape Omniscript ne sont pas liées. Par conséquent, le formulaire lui-même n'adhère pas nativement à la validation au niveau système associée à un objet particulier. Cependant, les valeurs que vous utilisez pour créer ou mettre à jour des enregistrements sont traitées dans l'ordre d'enregistrement, ce qui signifie qu'elles passent par la validation au niveau système de l'objet.

**Note :** Les composants Flux d'écran ne prennent pas tous en charge la validation des entrées.

De la même façon que les présentations de page, les Formulaires dynamiques permettent de définir l'état **obligatoire** et **en lecture seule** au niveau de la page. Notez que vous ne pouvez pas remplacer les paramètres au niveau système.

Le flux offre la flexibilité nécessaire pour personnaliser la validation de l'entrée de formulaire. Plusieurs contrôles sont effectués au niveau du client (par exemple, le marquage des champs obligatoires manquants et les contrôles de type de données, ainsi que les formules compatibles dans les règles de validation d'entrée). Comme niveau de sécurité supplémentaire, la validation de l'entrée est également évaluée sur le serveur. Lorsqu'un utilisateur clique sur **Suivant**, Flux envoie de nouveau les entrées au serveur pour validation. Si des entrées non valides sont renvoyées, la navigation est bloquée et l'erreur appropriée est affichée.

Le serveur valide les entrées en cochant :

- Le paramètre d'**exigence** de l'entrée, ou si la valeur saisie est compatible avec le type de données sous-jacent.

- La validation personnalisée de l'entrée. Vous devez fournir une expression de formule _booléenne_ et un message d'erreur à afficher lorsque l'expression de formule n'est pas remplie.

- La validation personnalisée du composant sous-jacent. Si vous élaborez un composant Web Lightning personnalisé pour un flux, vous devez ajouter votre propre code de validation à la méthode validate().

Vous pouvez également fournir des alertes utilisateur accessibles via le composant **Message** dans des flux d'écran, mais cela n'empêche pas un utilisateur d'accéder à d'autres pages ou de passer à l'étape suivante dans un flux guidé. L'état _Erreur_ dans le composant **Message** est préférable sur les écrans d'erreur dédiés qui sont déclenchés via un chemin de défaut lorsque la navigation est désactivée.

Omnistudio offre un traitement robuste des erreurs et des validations via l'action [Définir l'erreur](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) combinée à des [vues conditionnelles](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) et au composant [Messagerie](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5).

Pour LWC, la plupart des composants de base effectuent leurs propres validations côté client (par exemple, lightning-record-form respecte le caractère obligatoire au niveau système, mais pas au niveau de la page). Pour vos composants personnalisés, vous pouvez créer vos propres mécanismes de validation.

Notez que les champs qui nécessitent la saisie de données par les utilisateurs doivent être affichés au début de vos formulaires. Validez les entrées des utilisateurs côté client avant la soumission des formulaires (si possible).

### Conception des interactions

Les formulaires statiques sont obsolètes. Aujourd'hui, l'attention s'est déplacée vers la mise à jour dynamique des formulaires avec les propriétés et les valeurs appropriées pour un utilisateur _spécifique_, à un moment _spécifique_, à un endroit _spécifique_. Examinons de plus près les possibilités offertes par les outils de création de formulaires Salesforce.

#### Questions à poser

- Quels types d'interaction ou de condition doivent déclencher des réponses dynamiques dans votre formulaire ?

- Vous devez exécuter des opérations hors écran (en arrière-plan) pendant que votre formulaire est rempli ?

- Avez-vous besoin de définir des champs comme **visibles**, **obligatoires**, **en lecture seule** ou **désactivés**, ou de changer la mise en forme en fonction des entrées de formulaire ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Exécution d'opérations de données hors écran</th>
<th colspan="1" rowspan="1">Valeurs conditionnelles et calculs</th>
<th colspan="1" rowspan="1">Visibilité conditionnelle</th>
<th colspan="1" rowspan="1">Exigence conditionnelle</th>
<th colspan="1" rowspan="1">Mise en forme conditionnelle</th>
<th colspan="1" rowspan="1">État Lecture seule conditionnelle</th>
<th colspan="1" rowspan="1">État désactivé conditionnel</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="8" rowspan="1" style="border-right: 1px solid #d8dde6;">*Limité aux composants qui utilisent un sélecteur de ressource et non une case à cocher statique</td></tr></table>

Les **écrans réactifs** activent l'interactivité des flux d'écran. La réactivité permet aux composants individuels d'un écran de flux de communiquer entre eux, ce qui augmente la puissance des flux d'écran.

**Exécution d'opérations de données hors écran**

Les flux d'écran fournissent une approche déclarative pour récupérer des données sur le même écran via des **actions d'écran**. Les Actions d'écran permettent de déclencher des flux lancés automatiquement lors d'une modification à l'écran ou lorsqu'un utilisateur clique sur un composant **Bouton d'action**. Vous pouvez mapper les résultats de flux lancés automatiquement avec le même écran, ce qui évite aux utilisateurs d'accéder à un autre écran.

LWC fournit une gamme complète d'adaptateurs wire qui permettent d'accéder aux données Salesforce pour remplir dynamiquement les données dans des composants de formulaire, ce qui permet aux développeurs de mettre à **jour**, **de supprimer** et **de créer** des enregistrements via des contrôleurs Apex.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-offscreendataoperations-noheader.png" alt="Lightning Web Components Off-Screen Data Operations" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

**Visibilité**

La visibilité peut être contrôlée dynamiquement dans tous les outils de création de formulaires. Les formulaires dynamiques, Flow Builder et Omnistudio répondent à ce problème en utilisant les fonctionnalités de visibilité des composants. Vous pouvez **afficher** ou **masquer** par déclaration des champs basés sur d'autres valeurs du formulaire, ou si l'utilisateur remplit le formulaire sur un appareil mobile.

- Les formulaires dynamiques contrôlent la visibilité en fonction des valeurs de champ d'enregistrement, des champs de référence et du facteur de forme.

- Avec Flux, vous pouvez baser une règle de visibilité sur d'autres entrées d'écran, ainsi que sur d'autres ressources remplies plus tôt dans le flux (par exemple, des formules ou des valeurs d'autres enregistrements).

  - **Règles basées sur l'appareil&nbsp;:** Ce n'est peut-être pas évident dès le départ, mais vous pouvez utiliser une formule pour **afficher** ou **masquer** un champ particulier lorsque l'utilisateur est sur un appareil mobile. Écrivez une formule de flux qui vérifie la valeur de la variable globale **$User.UIThemeDisplayed**. Si la valeur est **Theme4t**, l'utilisateur remplit le formulaire en utilisant l'application mobile Salesforce.

  - **Évaluer les autres ressources&nbsp;:** Les références manuelles de variables et de formules sont évaluées uniquement sur le serveur. Cela signifie que la valeur de cette ressource lors de la restitution initiale de l'écran est celle qu'elle aura jusqu'à ce que vous accédiez à un autre écran. Pendant la navigation, l'exécution du flux soumet une requête au moteur de flux (le serveur) et renvoie les toutes dernières valeurs manuelles de variable et de formule. Si vous souhaitez que votre règle de visibilité soit mise à jour lorsque l'utilisateur traverse un seul écran (par exemple, onblur), assurez-vous de référencer uniquement les valeurs des autres composants de l'écran.

- Avec Omnistudio, vous pouvez **afficher** ou **masquer** des composants sous certaines conditions en configurant une propriété **Vue conditionnelle**. Cependant, vous ne pouvez pas ajouter plusieurs propriétés Vue conditionnelle pour une entrée.

**États d'entrée conditionnels**

Si vous devez contrôler dynamiquement d'autres propriétés (par exemple, si un champ est **obligatoire**, **désactivé** ou **en lecture seule**), vous avez plusieurs options. LWC fournit un contrôle complet et réactif de votre état d'entrée. Avec les composants Flux d'écran réactif, vous pouvez contrôler dynamiquement les attributs de composants (par exemple, **lecture seule**, **désactivé** et **obligatoire**) pour les composants standard qui le prennent en charge, tandis qu'Omnistudio prend en charge tout le spectre des attributs spécifiques au composant. Si vos exigences exigent un flux et que le composant ne prend pas en charge un état d'attribut spécifique, vous pouvez créer un composant Web Lightning incorporable pour obtenir un état d'entrée dynamique.

Si vous devez contrôler dynamiquement d'autres propriétés (par exemple, si un champ est **obligatoire** ou en **lecture seule**), utilisez LWC à court terme, car vous avez le contrôle total. Cela est particulièrement vrai si vous avez des exigences sur mesure pour gérer onblur ou onclick.

**LWC réactifs dans les flux d'écran**

Si vous élaborez des composants Web Lightning capables de réagir et de modifier d'autres composants dans un flux d'écran, consultez le guide [LWC Best Practices for Screen Flows](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) pour vous assurer que vos composants s'intègrent au moteur d'exécution du flux et fonctionnent comme prévu.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Traitement des événements standard (onblur, onfocus)</th>
<th colspan="1" rowspan="1">Traitement des événements personnalisés</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*L'exécution Omnistudio Standard ne prend pas en charge Pub/Sub, mais prend en charge Windows postMessage</td></tr></table>

Pour des événements personnalisés, si certaines de vos entrées (ou le formulaire complet) doivent communiquer avec un autre élément de la page, LWC est votre seule option.

- Pour communiquer dans la même arborescence DOM, utilisez l'[interface CustomEvent](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events).

- Pour communiquer à travers le DOM, utilisez le [service Lightning Messaging](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel).

- Si le service de messagerie Lightning [n'est pas pris](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) en charge pour votre conteneur cible, utilisez le module pub/sub.

#### Ressources supplémentaires pour la conception d'interactions

- Pour des informations plus détaillées, consultez [Communiquer avec des événements](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) et [Communiquer à travers le DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub) dans le _Lightning Web Components Dev Guide_.

- Pour Omnistudio, consultez [Communiquer avec Omniscript à partir d'un composant Web Lightning.](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5)

### Style

Pour offrir la meilleure expérience utilisateur, il est important de s'assurer que le style de votre formulaire est cohérent avec le reste de l'application ou du site dans lequel il est incorporé. Cela peut impliquer d'utiliser des modèles standard fournis par Salesforce ou de créer une feuille de style CSS personnalisée qui utilise chaque pixel de la conception pour améliorer la présentation.

#### Remplacements de style de flux d'écran

Les administrateurs peuvent configurer un ensemble limité de remplacements de style d'écran et de composant (par exemple, couleurs, bordures et apparences de bouton), pour le conteneur d'écran ou pour des composants individuels. Ces remplacements sont appliqués après les thèmes et la personnalisation de la marque, ce qui permet aux concepteurs d'ajuster visuellement les paramètres sans impacter le reste de l'application.

Les remplacements de style sont conçus pour des exceptions visuelles localisées (par exemple, mettre en évidence un écran de confirmation ou souligner un appel à l'action (CTA) spécifique) ; ils ne sont pas un système de style complet. Ils ne fournissent pas de contrôle au niveau CSS et ne sont pas conçus pour être réutilisés à travers les écrans ou les flux.

D'un point de vue architectural, le style devrait suivre cet ordre de priorité :

1. **Thèmes et marque :** Thèmes Lightning, ensembles de marque Experience Builder ou thématisation de site LWR

2. **Remplacements de style de flux :** Ajustements ciblés de l'écran ou du composant

3. **Composants personnalisés (LWC) :** lorsqu'il est nécessaire d'avoir un contrôle pixel-perfect ou des modèles de conception réutilisables

L'utilisation de thèmes et de systèmes de conception permet de garantir un style cohérent, évolutif et facile à gérer au fil du temps.

#### Questions à poser

- Quel est le niveau de sophistication de votre style et CSS ?

- Avez-vous besoin d'un style personnalisé, parfait en pixels ou de thèmes standard ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Style direct</th>
<th colspan="1" rowspan="1">Thèmes d'organisation et d'Experience Builder</th>
<th colspan="1" rowspan="1">Style pixel-perfect</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">* FlexCards uniquement<br><br>**Certains attributs de style peuvent être configurés pour des composants d'écran, mais pas pour des remplacements CSS.</td></tr></table>

FlexCards est le seul produit de ce guide qui permet de contrôler par déclaration le style et la présentation de l'interface utilisateur que vous élaborez dans l'outil (par exemple, marges et remplissage, typographie, couleurs, etc.).

Les formulaires et les flux dynamiques respectent les fonctionnalités de thème déclaratif. Si vous avez besoin d'un contrôle supplémentaire (au-delà de ce que prennent en charge les [Thèmes Salesforce](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), les [Ensembles de personnalisations](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm) Générateur d'expérience ou [les Sites Experience Cloud](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm) LWR), envisagez une solution par programmation.

Les équipes qui maîtrisent CSS ont plusieurs options :

- Les flux et les composants Web Lightning héritent de [jetons de conception standard](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm).

- Les Omniscripts et les FlexCards prennent en charge le système de conception personnalisable via [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5).

- Avec LWC, vous pouvez écrire vos propres composants et contrôler entièrement leur HTML et CSS.

Dans la mesure du possible, nous recommandons d'utiliser des thèmes et des systèmes de conception pour garantir une présentation cohérente de tous vos contenus.

**Note :** Vous pouvez incorporer des composants Lightning dans des flux. Si vous avez besoin d'un contrôle parfait de la présentation de votre formulaire, mais que vous souhaitez également utiliser les autres avantages des flux (par exemple, le modèle de navigation), vous pouvez avoir le meilleur des deux mondes ! Le même principe s'applique aux Omniscripts et aux FlexCards.

### Présentation

Le choix d'une bonne présentation est crucial pour concevoir des formulaires rationalisés qui permettent une saisie rapide et efficace des données et augmentent leur intégrité.

#### Questions à poser

- Comment structurer les présentations de formulaire pour optimiser l'expérience utilisateur ?

- Comment présenter aux utilisateurs des données existantes qui facilitent la saisie de nouvelles données dans vos formulaires ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">2 colonnes</th>
<th colspan="1" rowspan="1">4 colonnes</th>
<th colspan="1" rowspan="1">Au-delà de 4 colonnes</th>
<th colspan="1" rowspan="1">Répéter des blocs de données</th>
<th colspan="1" rowspan="1">Conteneurs d'onglets</th>
<th colspan="1" rowspan="1">Conteneurs en accordéon</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="7" rowspan="1" style="border-right: 1px solid #d8dde6;">*Les onglets peuvent être utilisés en incorporant des données à une FlexCard dans un Omniscript</td></tr></table>

Les formulaires dynamiques prennent en charge les présentations à deux colonnes qui peuvent être divisées en sections individuelles dans les champs. Ces sections peuvent être placées dans des composants (par exemple, des onglets et des accordéons) pour créer des présentations organisées et faciles à utiliser.

Les flux peuvent également être restitués en utilisant le composant **Section**. Vous pouvez ajouter jusqu'à quatre colonnes et un nombre illimité de sections à l'écran de flux. Le composant Sections est également réactif à la largeur de l'écran. Par conséquent, il fonctionne également sur les écrans plus petits. Il permet d'appliquer une visibilité conditionnelle à l'ensemble de la section, ce qui facilite l'application en masse de la visibilité à plusieurs champs de la section. Les **sections de flux** prennent également en charge les en-têtes de colonne et offrent une expérience en accordéon dans laquelle les utilisateurs peuvent réduire la section complète en cliquant sur l'étiquette.

Les Omniscripts offrent diverses options de présentation pour l'affichage des champs et des données. Vous pouvez créer des sections de données contenant jusqu'à 12 colonnes, y compris des accordéons réductibles sous certaines conditions.

Avec LWC, vous pouvez utiliser lightning-record-\[edit\|view]-form et le champ lightning-\[input\|output]-field associé pour contrôler la présentation. Les seules restrictions de présentation proviennent de HTML et CSS. Le composant **Lightning-record-form** respecte la configuration de la section dans la présentation de page associée (par exemple, si une section est à deux colonnes dans la présentation de page, elle est également à deux colonnes dans le composant).

### Translation

Si votre formulaire doit être accessible par des utilisateurs de différentes régions ou qui parlent différentes langues, vous devez vous assurer que l'outil que vous utilisez pour l'élaborer répond à vos exigences de traduction.

**Note :** Pour les formulaires en particulier, les exigences de localisation impliquent généralement la traduction d'éléments de texte dans d'autres langues.

#### Questions à poser

- Votre formulaire sera-t-il utilisé dans plusieurs pays ou régions ?

- Le texte de votre formulaire doit-il être traduit dans d'autres langues ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Étiquettes saisies dans le Générateur</th>
<th colspan="1" rowspan="1">Étiquettes dans le code</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Sans objet</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*En-têtes de section de champ uniquement</td></tr></table>

Si vous localisez des champs personnalisés, les Formulaires dynamiques respectent les étiquettes traduites. Les formulaires dynamiques respectent également les [étiquettes personnalisées attribuées](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) aux étiquettes et aux attributs des composants dans le Générateur d'applications Lightning.

Flux prend en charge la traduction des étiquettes accessibles aux utilisateurs pour tous les composants d'écran standard et personnalisés via le Workbench de traduction.

Vous pouvez localiser des étiquettes, un texte d'aide et des messages d'erreur dans les composants d'écran suivants :

- Texte
- Zone de texte longue
- Numéro
- Devise
- Case à cocher
- Cases d'option
- Liste de sélection
- Liste à sélection multiple
- Mot de passe du groupe de cases à cocher
- Date
- Date/heure

Il n'y a pas de prise en charge de la traduction intégrée pour les actions prêtes à l'emploi (par exemple, Envoyer un e-mail ou Publier dans Chatter), mais il existe une solution de contournement. Si vous utilisez une [étiquette personnalisée](https://help.salesforce.com/articleView?id=cl_about.htm) pour définir les étiquettes traduites, vous pouvez référencer cette étiquette personnalisée dans l'action ou le composant en la configurant dans Flow Builder. Pour cela, vous devez créer une formule de flux qui référence l'étiquette personnalisée, puis référencer cette formule aux emplacements appropriés de votre flux.

Les Omniscripts utilisent des étiquettes personnalisées pour les traductions. Pour plus d'informations, consultez [ce document d'aide](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm) pour vous assurer que vos Omniscripts sont prêts pour le multilinguisme.

Pour LWC, certains composants de base héritent automatiquement des traductions des champs, du texte d'aide et des messages de validation de l'objet associé s'ils sont configurés dans le Workbench de traduction (par exemple, lightning-record-form).

Si vous devez introduire de nouvelles étiquettes traduisibles dans votre code, les étiquettes personnalisées sont la solution idéale. Déclarez l'étiquette personnalisée dont vous avez besoin, puis importez-la dans votre composant depuis le module d'étendue `@salesforce/label`.

## Considérations non fonctionnelles

Utilisez cette section pour évaluer les contraintes de sécurité, de qualité et opérationnelles avant l'implémentation.

### Sécurité

La sécurité est un sujet complexe, et quand il s'agit d'élaborer des formulaires, il y a un certain nombre de considérations qui ne sont peut-être pas évidentes. Au niveau fondamental, vous devez vous assurer que le formulaire est exécuté dans le contexte approprié et que les utilisateurs disposent des autorisations requises pour utiliser ses données sous-jacentes. Au-delà de cela, vous pouvez également prendre des mesures supplémentaires pour retirer les codes ou URL potentiellement malveillants des champs de texte enrichi, empêcher certains utilisateurs d'accéder au formulaire ou limiter les types d'emplacement où les administrateurs peuvent incorporer le formulaire à l'avenir.

Assurez-vous de bien documenter vos exigences de sécurité avant de choisir un outil. Pour plus d'informations sur ce type de documentation, consultez le [modèle de politique de sécurité Well-Architected de Salesforce](/docs/architect/fr-fr/resources/guide/security-policy-template).

#### Questions à poser

- Le formulaire doit-il vérifier l'accès de l'utilisateur avant d'effectuer certaines opérations ?

- Devriez-vous désinfecter les entrées des utilisateurs ?

- Voulez-vous contrôler qui peut accéder au formulaire ?

- Voulez-vous contrôler l'emplacement où le formulaire peut être incorporé ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Augmentation des autorisations utilisateur</th>
<th colspan="1" rowspan="1">Contrôle des utilisateurs qui ont accès</th>
<th colspan="1" rowspan="1">Restriction des emplacements autorisés</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">* Nécessite Apex<br><br>**Les Omniscripts ne peuvent pas avoir un ensemble d'emplacements cibles spécifié, mais les FlexCards peuvent.</td></tr></table>

#### Augmentation des autorisations utilisateur

Lorsqu'un programme est exécuté dans le **contexte utilisateur**, Salesforce applique une série de contrôles d'accès, qui comprennent la vérification de la sécurité au niveau du champ, des autorisations CRUD et de l'accès aux enregistrements en fonction des règles de partage de votre organisation (par exemple, les utilisateurs peuvent exécuter un formulaire de mise à jour de requête uniquement s'ils ont la possibilité de mettre à jour les requêtes, la sécurité au niveau du champ appropriée et l'accès à l'enregistrement en question).

Que se passe-t-il si vous souhaitez que les utilisateurs puissent exécuter une opération particulière en utilisant votre formulaire, mais pas via un autre formulaire ou une autre interaction ? C'est là que le **Contexte système** intervient !

**Contexte système** permet d'augmenter les autorisations d'un utilisateur pendant la durée de la session (par exemple, l'utilisateur n'a pas besoin de mettre à jour l'accès à l'objet Requête pour remplir votre formulaire de mise à jour de requête). Ceci est particulièrement utile pour les communautés non authentifiées. Au lieu d'accorder aux utilisateurs invités des capacités potentiellement dangereuses, définissez l'exécution de votre formulaire dans le contexte système.

Le Contexte système doit être utilisé uniquement lorsque cela est absolument nécessaire. Lorsqu'un formulaire est exécuté dans le contexte système, chaque opération CRUD contourne les composants de sécurité et de partage au niveau de l'objet et du champ. De plus, le contexte système n'a aucune incidence sur la personne que Salesforce considère comme l'_acteur_ (le nom affiché dans le champ **Dernière modification par**). Pour chaque opération que votre formulaire effectue (par exemple, une mise à jour de requête), l'_acteur_ est l'utilisateur actuel (même si le formulaire est exécuté dans un contexte différent).

**Note :** Les formulaires dynamiques, les Omniscripts et les composants Web Lightning sont toujours exécutés dans le contexte de l'utilisateur, et il n'est pas possible de remplacer ce comportement.

Les flux d'écran sont exécutés par défaut dans le contexte de l'utilisateur, mais vous pouvez les définir pour les exécuter dans le contexte système. Vous pouvez décider si le flux doit accorder l'accès à toutes les données ou s'il doit appliquer l'accès au niveau de l'enregistrement.

- Si vous incorporez un composant Lightning à un flux exécuté dans le contexte système, le flux ne remplace pas le contexte du composant. Si vous devez contourner les contrôles d'accès utilisateur, utilisez le flux pour effectuer ces opérations et transmettre les données appropriées dans ou hors du composant Lightning. Certains composants prêts à l'emploi (par exemple, Référence) ne peuvent pas fonctionner dans le contexte système.

- Si votre flux appelle des actions Apex, d'autres nuances sont impliquées.

  - Si la classe Apex est définie sur le _partage hérité_, elle sera exécutée dans le contexte système avec partage, quelle que soit la méthode utilisée pour définir le flux.

  - Si la classe n'a pas de déclaration de partage explicite, elle est exécutée dans le contexte système sans partage, quelle que soit la configuration du flux.

  - Si la classe est définie sur _avec partage ou_ sans partage, elle remplace le contexte du flux.

**Interrogation d'enregistrements dans le contexte système avec des sites Experience Cloud**

Si vous exécutez un flux dans le contexte système sur un site Experience Cloud (en particulier s'il n'est pas authentifié), stockez uniquement des champs spécifiques dans vos éléments **Obtenir des enregistrements**. Lorsque vous travaillez avec Flow et transmettez les résultats d'un élément **Obtenir des enregistrements** dans un flux secondaire, une action invocable ou un composant Lightning, tous les champs de cet objet peuvent être inspectés par les outils de développement du navigateur. Malgré vos intentions, les champs peuvent être disponibles pour les utilisateurs d'Experience Cloud. Pour vous assurer que seuls les champs corrects sont exposés lorsque le Contexte système est activé, spécifiez ces champs spécifiques dans vos éléments **Obtenir des enregistrements**.

**Note :** La logique Omniscript est exécutée côté client, ce qui permet aux assaillants de modifier l'exécution attendue d'un Omniscript et d'afficher les réponses aux Procédures d'intégration, aux Mappeurs de données et aux appels de méthode Apex via les outils pour développeur du navigateur. Lorsque vous utilisez Omniscript, il est important d'exécuter une logique métier côté serveur (dans la mesure du possible), et d'implémenter des règles de validation d'entrée pour toutes les méthodes Apex exposées via une [annotation @InvocableMethod](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5).

**Assainir les entrées**

Pour protéger votre organisation contre les mauvais acteurs, utilisez la désinfection des entrées. Supposons que vous avez une entrée dans un formulaire accessible au public qui peut être mappé avec un champ **Texte enrichi** au sein de votre organisation. Vous pouvez activer l'automatisation qui supprime tout code HTML susceptible de masquer des URL malveillantes.

Il n'est pas idéal d'implémenter la désinfection au niveau du formulaire, car vous pouvez avoir n'importe quel nombre de sources qui écrivent dans ces champs. Pour lutter contre ce problème, créez un **flux de mise** à jour rapide des champs (avant l'enregistrement) ou utilisez un **déclencheur Apex** existant pour retirer ou modifier tout code HTML éventuellement saisi dans le formulaire.

#### Meilleures pratiques

- Autorisez l'exécution des flux dans leur contexte par défaut (sauf si vous devez élever l'accès de l'utilisateur actuel à une opération spécifique).

- Évitez d'exécuter des flux dans le contexte système pour les utilisateurs invités. Créez des ensembles d'autorisations avec un accès limité aux champs et attribuez-les au profil de l'utilisateur invité Experience Cloud.

- Lors de l'interrogation d'enregistrements dans des flux Exécuter le contexte système sur des sites Experience Cloud, stockez uniquement les champs dont vous avez besoin dans l'élément **Obtenir des enregistrements** ou **des actions invocables**.

- Si un flux exécute diverses opérations, qui ne nécessitent pas d'accès élevé, utilisez des flux secondaires pour isoler les opérations qui doivent être exécutées dans le contexte système.

- Si vous incorporez un formulaire à une page Web externe, il peut être nécessaire de le mapper avec des champs de **texte enrichi** afin d'éviter les attaques potentielles par hameçonnage. Pour ce faire, désinfectez les entrées des utilisateurs afin de retirer le code HTML en utilisant un **flux de mise** à jour de champ rapide ou un **déclencheur Apex**.

#### Notes complémentaires

- Les Omniscripts, les FlexCards et les Composants Web Lightning sont exécutés par défaut dans le contexte de l'utilisateur.

- Les composants Web Lightning sont exécutés par défaut dans le contexte de l'utilisateur.

- Les flux sont exécutés dans le contexte de l'utilisateur, mais vous pouvez le remplacer en utilisant un contrôleur Apex.

- Les opérations exécutées dans l'API UI sont exécutées dans le contexte de l'utilisateur.

- Les opérations exécutées avec un contrôleur Apex dépendent de la classe spécifique. Pour exécuter ces opérations en mode système, définissez la **classe Apex** sur avec partage ou sans partage.

#### Contrôle d'accès

Si vous devez contrôler qui peut accéder à un formulaire, vérifiez le conteneur dans lequel le formulaire est incorporé (vous pouvez par exemple attribuer des pages Lightning pour qu'elles soient disponibles pour des applications, des types d'enregistrement ou des profils particuliers). Si certaines entrées sont confidentielles, utilisez des règles de visibilité pour mieux contrôler les éléments affichés pour qui. Cette fonctionnalité s'applique aux formulaires dynamiques et aux flux d'écran.

Vous pouvez [limiter un flux](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) à des profils ou des ensembles d'autorisations particuliers (de la même façon qu'une classe Apex ou des pages Visualforce). Les flux ne sont pas restreints par défaut, ce qui signifie que tout utilisateur disposant de l'autorisation utilisateur **Exécuter des flux** peut y accéder.

Si vous utilisez Omnistudio, vous pouvez configurer un [vérificateur d'autorisations](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) de classe Apex qui exige que les utilisateurs aient explicitement accès à la classe Apex qui administre les actions distantes depuis Omniscript, Flexcard, Classic Card, ou les API REST.

**Note :** Les contrôles d'autorisation de classe Apex s'appliquent uniquement aux classes Apex. Il est également conseillé de définir des autorisations au niveau du profil pour les [Procédures d'intégration et](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5) les Mappeurs de données.

#### Meilleures pratiques de contrôle d'accès

- Si vous exposez un flux à des utilisateurs invités, vous devez accorder uniquement l'accès au profil utilisateur invité aux flux dont ils ont absolument besoin. Il est possible d'ajouter **Exécuter des flux** à des profils utilisateur invité, mais cette pratique peut s'avérer risquée.

- Soyez prudent en utilisant des flux qui fonctionnent dans le contexte système. Vous devez limiter ces flux à un groupe particulier d'utilisateurs, car ils ont moins de freins et de contrepoids en place pour protéger vos données.

- Assurez-vous que tout Omniscript qui exécute Apex dans une communauté d'utilisateurs invités a **avec partage** répertorié dans la définition de classe Apex.

- Pour les profils utilisateur invité, attribuez uniquement les classes Apex que vous souhaitez autoriser les utilisateurs invités à appeler. En suivant cette pratique, il permet d'éviter d'exposer involontairement une logique métier supplémentaire aux utilisateurs invités.

Pour les composants Web Lightning, vous pouvez vérifier les attributions d'autorisations de l'utilisateur actuel afin de vérifier s'il dispose d'une autorisation standard ou personnalisée particulière. Vous pouvez importer des autorisations Salesforce à partir des modules d'étendue `@salesforce/userPermission` et `@salesforce/customPermission` directement dans **JavaScript**. Vous pouvez également utiliser Apex pour vérifier les autorisations.

#### Contrôles incorporés

Les composants Web Lightning ne sont disponibles à un emplacement donné qu'après avoir été ajoutés en tant que [cible](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) valide (par exemple, vous pouvez rendre un composant disponible dans les pages d'enregistrement et non disponible en tant qu'élément de la barre d'utilitaires).

Une fois activé, un flux d'écran est disponible à tous les emplacements pris en charge par les flux d'écran. Flow Builder prend en charge plusieurs types de flux qui ont des écrans. Le type le plus important est **Flux d'écran**, mais il existe d'autres types spécialisés limités à des emplacements spécifiques (par exemple, l'**application mobile Field Service** prend en charge uniquement les **flux Field Service Mobile)**. Cela est similaire aux **flux de demandes de contact**, qui sont pris en charge uniquement dans Experience Cloud.

Quel que soit le type de flux, la personne qui crée le flux n'a aucun contrôle sur l'emplacement d'incorporation du flux. Les flux sont disponibles à chaque emplacement où ce type de flux spécifique est pris en charge.

Si vous utilisez Salesforce Industries, une légère mise en garde s'applique à Omniscript.Vous ne pouvez pas spécifier une cible pour un Omniscript, mais vous pouvez spécifier une cible pour les FlexCards que vous souhaitez incorporer.

### Automatisation des tests d'interface utilisateur

Salesforce offre plusieurs outils d'automatisation des tests de bout en bout (par exemple, consultez [Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)) qui permettent de simuler l'interaction d'un utilisateur avec vos formulaires. Vous pouvez écrire des tests pour n'importe quelle interface utilisateur standard ou personnalisée, y compris les pages Lightning et les flux d'écran.

**Note :** Ces types de test ne peuvent pas vérifier les sorties des méthodes exécutées. Gardez cela à l'esprit lorsque vous configurez vos exigences d'automatisation des tests d'interface utilisateur.

#### Questions à poser

- Avez-vous besoin de tests automatisés pour vos formulaires ?

- Quels types de test envisagez-vous d'effectuer ?

- Quel niveau de granularité est nécessaire pour les automatisations de test ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Tests unitaires</th>
<th colspan="1" rowspan="1">Automatisation de bout en bout</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Disponible*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + LWC</strong></td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*Nécessite un code</td></tr></table>

**Considérer les exigences d'automatisation des tests d'interface utilisateur**

Les **tests unitaires** fournissent une automatisation et une validation précises qui s'alignent sur les systèmes et les outils CI/CD standard de l'industrie, qui testent la logique métier, les contrôles JavaScript et les sorties de composants spécifiques. Si vous choisissez une approche low-code, vous ne pourrez pas créer vous-même des tests. Cependant, Salesforce teste rigoureusement toutes les offres de bout en bout.

Si les méthodes de votre composant sont complexes, vous pouvez les envoyer par SMS individuellement en les plaçant dans des fichiers JavaScript dédiés. Cela permet de les importer dans un LWC, puis dans un **test Jest (par exemple,** import { sort } from 'c/utils';).

Vous pouvez utiliser une solution sans code d'un éditeur de logiciels, élaborer une solution de test-automatisation personnalisée ou utiliser une infrastructure de test open-source (par exemple, Selenium WebDriver ou WebdriverIO) pour l'automatisation de bout en bout. Ces solutions sont valables pour toutes les interactions de l'interface utilisateur de Salesforce (par exemple, un Formulaire dynamique dans une page Lightning, un Flux d'écran dans une barre d'utilitaires ou un Composant Web Lightning dans un flux d'action rapide).

### Métriques

Après avoir déployé votre formulaire dans un environnement de production, vous devez vous assurer qu'il est utilisé efficacement. Selon votre cas d'utilisation, cela peut signifier suivre le nombre de fois que votre formulaire a été rempli jusqu'au temps que l'utilisateur moyen passe à remplir le formulaire avant de soumettre ses informations. Il est important d'identifier vos indicateurs de performance clés à suivre avant de choisir un outil.

#### Questions à poser

- Avez-vous besoin de suivre l'utilisation du formulaire ?

- Quels indicateurs de performance clés peuvent déterminer si le formulaire est utilisé efficacement ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Vues de page</th>
<th colspan="1" rowspan="1">Temps passé sur le formulaire</th>
<th colspan="1" rowspan="1">Suivre l'achèvement du formulaire</th>
<th colspan="1" rowspan="1">Suivre le taux de réussite</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Disponible**</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + Composant Web Lightning</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible**</td>
<td colspan="1" rowspan="1">Disponible*</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="5" rowspan="1" style="border-right: 1px solid #d8dde6;">*Disponible lorsque Exécution Omnistudio basée sur un package est activée** Disponible en suivant l'utilisation de la page Lightning parente</td></tr></table>

Si vous devez suivre l'utilisation et l'adoption générales du formulaire, utilisez des outils à faible code. Les formulaires dynamiques et les flux d'écran sont suivis via des rapports personnalisés prêts à l'emploi. Cependant, les rapports de suivi de flux d'écran offrent une précision supplémentaire. Si vous devez suivre l'utilisation des composants Web Lightning, la disponibilité prête à l'emploi dépend de l'emplacement où vous utilisez les composants Web Lightning. S'il se trouve dans une page Lightning, tous les éléments de suivi de l'utilisation des pages Lightning disponibles s'appliquent également à votre Composant Web Lightning. Cela est également vrai pour les composants Web Lightning incorporés à des flux.

Les formulaires dynamiques ne peuvent pas être suivis prêts à l'emploi. Cependant, vous pouvez suivre l'utilisation de la page Lightning parente via des [objets Lightning](https://help.salesforce.com/articleView?id=lex_usage_reports.htm) Pour suivre les pages Lightning standard, utilisez le rapport personnalisé **Users with Lightning Usage by Page Metrics** (Utilisation de Lightning par métriques de page). Pour les pages Lightning personnalisées, utilisez le rapport personnalisé **Users with Lightning Usage by FlexiPage Metrics**.

Les flux peuvent vous aider à suivre l'adoption de formulaires spécifiques. Utilisez l'**exemple de rapport de flux : Flux d'écran** pour répondre à ces types de questions :

- Quel est le taux de complétion de ce formulaire ? Est-il bien adopté actuellement ?

- Combien de temps faut-il aux utilisateurs pour remplir ce formulaire ?

- Sur quel écran les utilisateurs passent-ils le plus de temps à compléter ?

- À quelle fréquence les utilisateurs accèdent-ils aux écrans précédents ?

- À quelle fréquence les erreurs se produisent-elles ?

Si le rapport standard ne répond pas à vos besoins, vous pouvez le cloner et apporter des modifications ou Build Your Own rapport à partir de zéro en utilisant le rapport **Screen Flows**.

Si vous utilisez l'exécution Omniscript basée sur un package, vous pouvez également utiliser le [Omnistudio for Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5). Ce service suit tous les types d'événement (vous pouvez par exemple suivre le temps nécessaire pour suivre les étapes dans un Omniscript, ce qui aide à identifier les améliorations du processus).

**Note :** Il n'existe pas d'option prête à l'emploi pour suivre un Composant Web Lightning qui n'est pas incorporé à un flux d'écran, un Omniscript ou une page Lightning, mais vous pouvez élaborer une solution personnalisée en utilisant Apex.

### Empaquetage et déploiement

Vous connaissez peut-être l'utilisation d'ensembles de modifications ou du **DevanOps Center** pour déployer votre solution dans des environnements de test ou en production. Ces options de déploiement prennent entièrement en charge les formulaires dynamiques, les flux et les LWC. Cependant, Omnistudio nécessite un outil séparé, le [IDX Workbench](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5).

#### Questions à poser

- Comment comptez-vous déployer le formulaire ?

- Le formulaire doit-il être distribué à plusieurs organisations Salesforce ?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Packages gérés de première génération (1GP)</th>
<th colspan="1" rowspan="1">Packages gérés de deuxième génération (2GP)</th>
<th colspan="1" rowspan="1">Packages déverrouillés</th>
<th colspan="1" rowspan="1">Ensembles de modifications</th>
<th colspan="1" rowspan="1">DevOps Center</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible</td>
<td colspan="1" rowspan="1">Non disponible*</td>
<td colspan="1" rowspan="1">Non disponible*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran + Composant Web Lightning</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td>
<td colspan="1" rowspan="1">Disponible</td></tr>
<tr><td colspan="6" rowspan="1" style="border-right: 1px solid #d8dde6;">* Utilisez le Workbench IDX pour déployer les solutions Omnistudio dans d'autres organisations.</td></tr></table>

Si vous êtes un éditeur de logiciels ou un partenaire qui envisage d'empaqueter votre solution pour la distribuer sur AppExchange, consultez Formulaires dynamiques, flux et composants Web Lightning. Notez qu'Omnistudio ne prend pas en charge l'empaquetage.

### Naviguez dans le continuum du low-code au pro-code

Ce guide a pour but de vous montrer les fonctionnalités et les niveaux de personnalisation disponibles via les formulaires dynamiques, les flux d'écran, Omnistudio et LWC.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-lowcode-continuum.png" alt="Low-Code to Pro-Code Continuum" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Voici une vue d'ensemble.

- En ce qui concerne la création de formulaires, LWC est l'option la plus robuste et personnalisable, mais il offre le moins de garde-fous. C'est pourquoi il est crucial d'élaborer vos composants en gardant à l'esprit la [sécurité](/docs/architect/fr-fr/well-architected/guide/trust.html) et l'[évolutivité](/docs/architect/fr-fr/well-architected/guide/reliability.html#scalability-and-capacity-planning).

- Les formulaires dynamiques sont l'option la moins flexible, mais les possibilités de faux pas sont beaucoup moins nombreuses.

- Flow et Omnistudio tombent légèrement au milieu. Ils sont plus puissants que les formulaires dynamiques, mais ils ne sont pas tout à fait au niveau LWC. Cependant, ils ont moins de garde-fous que les Formulaires dynamiques et sont plus difficiles à briser qu'un code personnalisé.

Plusieurs outils peuvent répondre à vos besoins. Dans ce cas, la décision dépend de l'outil le plus adapté à votre équipe. Pour plus d'informations sur les aspects supplémentaires à prendre en compte, consultez les [Architect Decision Guides](/docs/architect/fr-fr/decision-guides) ci-dessous.

#### Questions à poser

- Lorsque vous comparez des outils, il est important d'évaluer l'expertise de votre équipe par rapport à chaque outil ?
- Combien de vos développeurs maîtrisent LWC ou JavaScript ?
- Votre équipe compte-t-elle des développeurs experts en Flow Builder ou qui ont exprimé leur intérêt pour en savoir plus ?

Nous n’entrerons pas dans les détails spécifiques, mais voici un peu plus d’informations sur le lien entre ces outils spécifiques et les évaluations que nous avons couvertes jusqu’à présent.

**Délégation de livraison**

Notez que même si certaines de vos exigences nécessitent LWC, il n'est pas nécessaire d'élaborer la solution complète en utilisant LWC. Il est important de déterminer comment élaborer votre solution de façon modulaire. Pour ce faire, vous devez identifier les pièces qui nécessitent un Composant Web Lightning codé et celles qui n'en nécessitent pas. Les parties qui ne nécessitent pas de LWC doivent être construites en utilisant une solution à faible code.

En ce qui concerne Flux et Composants Web Lightning, divers composants (par exemple, Composants d'écran réactifs et Flux d'écran) peuvent être synchronisés sur le même écran afin de libérer de nouveaux outils pour les architectes, les administrateurs et les développeurs. Les développeurs peuvent désormais créer des composants modulaires et utiles qui peuvent être réutilisés dans l'ensemble de l'organisation, ce qui augmente la productivité de l'équipe. Cela permet aux développeurs de gagner du temps en utilisant une combinaison de composants Flux standard et personnalisés pour obtenir un dynamisme de forme, ce qui leur donne plus de temps pour se concentrer sur la résolution de nouveaux défis. Avec l'introduction des composants réactifs dans Flux, il n'a jamais été aussi opportun de mélanger Flux et Composants Web Lightning lors de l'élaboration de formulaires.

**Propriété et maintenance à long terme**

Si vous créez un formulaire à plusieurs étapes, commencez par Flow ou une combinaison de Flow et de LWC. Si l'équipe qui gère le formulaire est une équipe à faible code, assurez-vous que la solution est aussi configurable et extensible que possible pour votre audience cible. Pour améliorer la stabilité et la maintenabilité, il est important d'organiser votre solution en unités [composables](/docs/architect/fr-fr/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity), quel que soit l'outil choisi.

### Performances

Les considérations relatives aux performances liées aux formulaires dynamiques, aux flux d'écran, à Omnistudio ou aux composants Web Lightning sont basées sur l'infrastructure dans laquelle les technologies sont hébergées. Les technologies basées sur LWC ont tendance à dépasser celles basées sur Aura. Grâce à plusieurs fonctionnalités principales implémentées nativement dans les moteurs Web (plutôt qu'en JavaScript via des abstractions d'infrastructure), le LWC offre des performances améliorées.

Comment exploiter ces avantages en termes de performance pour nos technologies de formulaire chez Salesforce ? Examinons de plus près.

- Les formulaires dynamiques (intégrés dans les métadonnées de page Lightning) reposent sur une base LWC, ce qui nous permet de mettre en œuvre plusieurs fonctionnalités tant attendues. Pour plus de performance, les formulaires dynamiques utilisent le rendu progressif, qui accélère le chargement des pages contenant un grand nombre de champs.

- Les flux d'écran reposent sur LWC. La plupart des composants individuels prêts à l'emploi ont été convertis en Composants Web Lightning, à l'exception des composants **Chargement de fichier** et **Image**. L'équipe de Flow a converti le client d'exécution de flux en Composants Web Lightning (et la plupart de ses composants), mais les clients doivent encore convertir leurs composants d'écran Aura en Composants Web Lightning. Notez que Salesforce prend en charge uniquement les composants LWC au sein du framework **Composant réactif** dans les flux d'écran. Pour plus d'informations, consultez le module Trailhead [Lightning Web Components for Aura Developer](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers). Si vous envisagez d'élaborer un composant personnalisé pour un flux d'écran (ou tout autre conteneur), choisissez LWC !

- Il existe plusieurs versions d'Omnistudio disponibles. Si vous êtes un client de longue date, vous utilisez peut-être **Angular**. Nous encourageons tous les nouveaux clients à utiliser des Omniscripts et des FlexCards basés sur LWC. Nous encourageons également les clients existants à migrer hors d'Angular.

- LWC est construit sur LWC.

## Ressources

<table><tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulaires dynamiques</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_overview.htm&language=en_US&type=5">Division des détails de vos enregistrements avec des formulaires dynamiques</a><br>- <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Obtenir de l'aide pour Lightning App Builder</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Flux d'écran</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">Utiliser les flux d'écran pour interagir avec les utilisateurs</a><br>- <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Automatisez les tâches avec les flux</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1"><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_omnistudio.htm&release=236&type=5">Omnistudio</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">Omniscripts</a><br>- <a href="https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5">Application IDX Workbench Desktop</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Système de conception Newport</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Personnalisation des Omniscripts et Flexcards avec le Newport Design System</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">- <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Composants Web Lightning</a><br>- <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Guide du développeur de composants Lightning Aura</a><br>- <a href="https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers">Composants Web Lightning pour développeurs Aura</a></td></tr></table>

<!-- document id=f5f0afa1aeeae973f66e84acdf2217d5d46848f7bb5ce67826ae83d582f12ac2 url=/architect/current/fr-fr/decision-guides/guides/determining-agentic-vs-traditional-workflow-automation.md -->

# Détermination de l'automatisation des workflows agentiques et traditionnels

Avec Agentforce, les entreprises peuvent désormais ouvrir de nouveaux paradigmes pour le travail automatisé qui ne peuvent pas être facilement réduits à des règles. Ces nouvelles capacités comprennent la résolution des intentions des clients à partir de conversations non structurées, la coordination des processus multi-parties entre les systèmes et la réponse aux conditions opérationnelles en temps réel. Les workflows agentiques utilisent une automatisation conçue pour raisonner en vue d'obtenir des résultats plutôt que d'exécuter des étapes prédéfinies. Pour répondre à cette demande, il faut une plateforme qui fonctionne dans tout le spectre de la complexité de l'automatisation, et un cadre montrant où chaque capacité trouve sa place.

Agentforce combine l'Einstein Trust Layer, le Reasoning Engine, Agent Script, Flow, Apex et Data 360 dans une plateforme unique et unifiée. Cette combinaison gère tout, depuis la simple automatisation du déclencheur d'enregistrement jusqu'à l'orchestration multi-agents complexe à travers la voix, la vision, les documents et la télémétrie en temps réel. MuleSoft étend cette plate-forme avec le tissu MuleSoft, la gouvernance et l'orchestration inter-systèmes nécessaires pour connecter des workflows agents à travers une entreprise. Agentforce Operations (auparavant Agentforce Supply Chain) applique ces capacités aux demandes spécifiques des processus opérationnels et de fabrication.

## Présentation du guide

Ce guide présente le cadre Densité d'orchestration et des lignes directrices pour prendre des décisions éclairées dans ce paysage de produits. L'infrastructure offre aux architectes une approche répétitive pour sélectionner les outils et les modèles appropriés en utilisant des niveaux de densité pour des cas d'utilisation d'automatisation intelligente sur Salesforce Platform.

## Produits concernés

| Produit               | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Agentforce            | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5) est la plate-forme de Salesforce pour élaborer et déployer des agents IA. Il utilise le moteur Atlas pour déclencher des actions ancrées dynamiquement en temps réel via Apex, et Data 360.                                                                                                                                                                                                                                                                                                                           |
| Script Agent          | [Script Agent](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html) est un langage déclaratif spécifique au domaine (DSL) utilisé dans Agentforce Builder pour définir des workflows, des règles métiers et une logique conversationnelle pour les agents                                                                                                                                                                                                                                                                                                                                         |
| Grille Agentforce       | [Agentforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) est une interface native de l ' IA, sans feuille de calcul de code, qui permet de concevoir et de mettre en œuvre rapidement des workflows d ' IA à grande échelle.                                                                                                                                                                                                                                                                                                                                                                     |
| Agentforce Operations | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5) (anciennement Agentforce Supply Chain) est une plate-forme d ' orchestration de la gestion des workflows collaboratifs pilotée par l ' IA, conçue pour rationaliser et automatiser les processus métiers d ' appui.                                                                                                                                                                                                                                                                           |
| MuleSoft              | [MuleSoft](/docs/architect/fr-fr/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) est une plate-forme complète, unifiée et ouverte pour l'intégration des entreprises et la gouvernance des agents. Grâce à la connectivité pilotée par l'API et à MuleSoft Agent Fabric et Agent Broker, il sert de tissu d'intégration, de couche de gouvernance et de fondation d'orchestration inter-systèmes pour connecter des workflows agents à travers l'entreprise                                                                                                                                                         |
| Flux et Apex        | [Salesforce Flow](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5) est un puissant outil d'automatisation par pointer-cliquer qui permet d'élaborer visuellement des processus métiers complexes sans code. [Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) est un langage de programmation propriétaire et orienté objet pour la plate-forme Salesforce, similaire à Java. Il est utilisé pour élaborer une logique métier personnalisée, automatiser les processus et étendre les fonctionnalités CRM de base au-delà des outils déclaratifs. |

## Points à retenir

Agentforce représente un changement fondamental dans la façon dont le travail est effectué sur Salesforce Platform, de l'automatisation basée sur des règles aux workflows basés sur le raisonnement. Pour libérer son potentiel, les architectes doivent prendre des décisions délibérées et informées sur la place des agents, leur composition et ce qu'ils orchestrent. Les principes suivants fournissent une ligne directrice reproductible pour les décisions des agents.

- **Utilisez l'outil approprié pour la tâche appropriée.** Utilisez la densité d'orchestration basée sur le parcours d'exécution, le mix de modalités et la complexité des objectifs pour déterminer la meilleure solution.

  - Utiliser l'**automatisation traditionnelle** avec des flux et Apex pour un travail déterministe basé sur des règles, où le résultat peut être entièrement défini et défini par un ensemble de règles. L'automatisation traditionnelle entraîne un parcours d'exécution statique, qui garantit des résultats prévisibles et reproductibles, et est crucial pour l'auditabilité. Choisissez l'automatisation traditionnelle pour les tâches qui nécessitent une stricte conformité et une adhésion légale.

  - Utilisez **Agentforce Grid** pour les cas d'utilisation d'inférence en masse avec une complexité d'orchestration faible à moyenne. Ce schéma utilise le raisonnement génératif à tour de rôle pour classer, calculer le score ou résumer les données dans un volume élevé d'enregistrements CRM, garantissant une exécution à haut débit avec une auditabilité immédiate.

  - Utilisez **Agentforce with Agent Script** pour les tâches qui ont des objectifs illimités et dont le résultat souhaité est connu, mais dont le chemin d'exécution exact ne peut pas être spécifié lors de la conception. Appliquez ce schéma aux exigences qui nécessitent un raisonnement par déterminisme guidé, afin de garantir des résultats prévisibles et traçables.

  - Utiliser **Agentforce Operations** pour rationaliser et automatiser les processus métiers collaboratifs grâce à la gestion pilotée par l ' IA des workflows de la chaîne d ' approvisionnement.

- **Évitez d'appliquer des workflows agents à des cas d'utilisation à faible densité d'orchestration**. Évaluez les compromis entre l'automatisation traditionnelle et l'automatisation agentique pour les exigences fonctionnelles et non fonctionnelles. L'automatisation traditionnelle peut offrir l'échelle, la fiabilité et les performances requises pour votre cas d'utilisation.

- **Adopter une approche hybride** d'automatisation des agents, qui combine Agentforce et l'automatisation traditionnelle avec des flux et Apex, lorsque cette synergie offre une valeur supérieure à l'utilisation isolée de l'automatisation agentique ou traditionnelle.

## Points de décision

Le sObject Salesforce est traditionnellement le point d'entrée principal de l'automatisation des enregistrements. Le système exécute une logique basée sur des règles, en commençant immédiatement après un événement DML (Data Manipulation Language) tel que insert, update ou delete. Pour choisir entre des outils efficaces d'[automatisation déclenchée par](/docs/architect/fr-fr/decision-guides/guide/record-triggered.html) un enregistrement, nous avons introduit la [densité d'automatisation](/docs/architect/fr-fr/decision-guides/guide/record-triggered#automation-density.html) comme moyen de mesurer la complexité du système, en prenant en compte la quantité d'automatisation, le volume d'enregistrements et l'étalement des dépendances. L'automatisation traditionnelle est limitée par les nombreux travaux préalables nécessaires pour intégrer les données dans une construction structurée, conforme au schéma et basée sur des règles.

L'automatisation agentique met à niveau l'automatisation traditionnelle en utilisant l'intention de l'utilisateur ou des données non structurées comme entrée dans laquelle le raisonnement peut être appliqué pour atteindre le résultat souhaité. Les architectes doivent décider quand exploiter le raisonnement probabiliste pour les données non structurées multimodales et quand appliquer des workflows guidés et déterministes afin de limiter le risque de résultats imprévisibles.

Lorsque l'exigence passe de l'exécution d'étapes basées sur des règles à un raisonnement axé sur les résultats, les architectes ont besoin d'un cadre normalisé pour évaluer la profondeur de raisonnement et la complexité des objectifs de la solution proposée.

### Densité d'orchestration

La densité d'orchestration est la mesure de la complexité dans un workflow agentique. Trois facteurs déterminent la densité d'orchestration : parcours d'exécution, complexité des objectifs et mix de modalités. Alors que la densité de l'automatisation mesure la complexité physique des règles et du volume du système, la densité de l'orchestration mesure la complexité du raisonnement du parcours de l'agent vers un objectif. Utilisez la densité d'orchestration composite pour évaluer vos exigences de conception et mapper avec la norme architecturale.

- **Parcours d'exécution**: La mesure dans laquelle le workflow peut être entièrement délimité et spécifié au moment de la conception. Un workflow entièrement spécifié signifie qu'il définit chaque branche et chaque résultat, ce qui aboutit à un chemin d'exécution prédéterminé. Un workflow non spécifié a un parcours qui peut émerger à l'exécution en raisonnant avec des données contextuelles et des instructions.
- **Complexité des objectifs**: Le nombre de résultats, de points de décision et de variations de parcours distincts que le workflow doit résoudre à l'exécution. Un workflow à faible complexité gère une seule tâche contenue avec un résultat prédéterminé, tandis qu'un objectif à forte complexité couvre plusieurs étapes avec des objectifs concurrents ou en conflit, assortis de cas particuliers qui ne peuvent pas être anticipés au moment de la conception.
- **Mix de modalités**: La plage de types d'entrée qu'un workflow doit traiter et les formulaires de sortie qu'il doit produire. Un faible mélange de modalités lit les champs CRM standard et produit des mises à jour d'enregistrement. Une modalité moyenne consomme une combinaison de champs CRM structurés et de données statiques non structurées, telles que des corps d'e-mail ou des transcriptions de requête, pour produire des mises à jour d'enregistrement. Un mix de modalité élevé consomme des flux dynamiques en temps réel, tels que le son en direct ou la télémétrie, et produit des sorties multimodales à travers plusieurs systèmes externes.

![Diagramme du cadre de densité d'orchestration montrant le parcours d'exécution, la complexité des objectifs et les axes du mix de modalités](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png)

### Séquençage des facteurs

La détermination du niveau de densité d'orchestration approprié nécessite d'évaluer de façon séquentielle le parcours d'exécution, la complexité de l'objectif et le mix de modalités. Inspectez d'abord le chemin d'exécution. Si un parcours est entièrement spécifiable, commencez par l'automatisation traditionnelle. L'utilisation d'une solution Agentic juste pour orchestrer et exécuter un parcours déterministe sans aucune exigence de raisonnement est un anti-schéma. Elle entraîne un étalement des agents (prolifération excessive et non gérée d’agents IA) et une perte de productivité des agents (production générée par l’IA de mauvaise qualité et inutile), entraînant des rendements de faible valeur.

Pour des parcours partiels ou non spécifiés, continuez à évaluer la complexité des objectifs. Si la complexité de l'objectif est bien définie, mais que certains nœuds du parcours nécessitent des évaluations probabilistes, pensez à appeler des agents depuis Flux ou Apex pour répondre au besoin localisé spécifique. À la place, si les étapes du parcours d'exécution nécessitent une ou plusieurs exigences pilotées par l'IA dans un grand nombre d'enregistrements, pensez à Agentforce Grid. La grille prend en charge les workflows basés sur une feuille à plusieurs étapes à travers plusieurs colonnes d'IA ou d'agent. Il est plus adapté à l'exécution en masse et orientée ligne. Cette approche garantit que le workflow reste hautement performant et auditable, en invoquant le raisonnement probabiliste uniquement lorsque le parcours ne peut pas être prédéfini.

À mesure que la complexité des objectifs augmente avec des dimensions concurrentes (par exemple, la détermination d'un versement de réclamation d'assurance ainsi que la détection des fraudes, la conformité aux polices et la satisfaction client) et des parcours d'exécution non spécifiables, pensez à Agentforce with Agent Script pour un déterminisme guidé dans votre automatisation. Pour les cas d'utilisation inter-entreprises qui impliquent Salesforce et des systèmes tiers, utilisez MuleSoft Fabric et Agent Broker.

Enfin, évaluez le mix de modalités afin d'identifier les capacités techniques nécessaires, par exemple la connexion multimodale ou l'intégration spécialisée. Le mix de modalité fonctionne comme un sélecteur de capacité, pas comme un calculateur de densité. Il permet de déterminer l'infrastructure requise pour gérer la forme d'entrée et de sortie de la solution, sans altérer sa logique d'orchestration fondamentale.

### Matrice de sélection de la densité

Utilisez cette matrice pour déterminer la norme architecturale de votre automatisation agentique. Équilibrez l'automatisation traditionnelle et l'automatisation agentique en sélectionnant l'approche qui résout votre problème d'automatisation.

- **Automatisation traditionnelle (faible densité d'orchestration) :** Utilisez l'automatisation traditionnelle lorsque le processus est déclenché par un changement d'enregistrement, que les données sont structurées, que la logique est basée sur des règles et prédéterminée, et que le résultat doit être prévisible (par exemple, calculs de prix standard ou création de tâches automatiques).
- **Agentforce Grid (densité d'orchestration faible à moyenne):** Utilisez Agentforce Grid lorsque des tâches d'IA en masse à travers des enregistrements existants doivent être traitées (par exemple, synthétisez les 50 dernières requêtes pour chaque Compte de cette liste, calculez le score de sentiment et persistez le score dans le champ de requête).
- **Orchestration hybride (automatisation augmentée d'ordre supérieur) :** Utilisez l'orchestration hybride lors de l'automatisation d'un processus métier complexe de bout en bout (par exemple, traitement des réclamations ou intégration) qui nécessite les capacités de planification de l'IA mais l'intégrité des transactions de Flux et Apex.
- **Script Agentforce Agent (complexité d'intention élevée) :** Utilisez le Script de l'agent lorsque le point d'entrée n'est pas structuré (par exemple chat, e-mail et voix) et que la résolution nécessite une conversation ou la capacité de gérer les demandes ambiguës des utilisateurs.

| Niveau de densité     | Parcours d'exécution                                                                                                     | Complexité de l'objectif                                                                               | Mixité des modalités                                                                                                                | Norme architecturale                                                                                                                                          |
| :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Faible**           | Entièrement spécifiable                                                                                                  | **Faible :** Tâche unique contenant des résultats prédéfinis.                                     | **Modalité unique :** Lit et écrit des enregistrements Objet Salesforce structurés.                                                 | Automatisation déclenchée par un enregistrement. Si le cas d'utilisation contient au moins une tâche de raisonnement, utilisez Actions Agentiques dans le workflow.                                              |
| **Faible à Moyen** | Entièrement ou partiellement spécifiable                                                                                     | **Faible :** Série d'étapes avec des résultats prédéfinis.                                           | **Modalités mixtes :** L'entrée ou la sortie peut combiner des données structurées et non structurées.                                   | Utilisez les Inférences par lot de grille Agentforce pour les tâches en masse dans les enregistrements existants avec une action agentique.                                                                |
| **Moyen**        | Entièrement ou partiellement spécifiable. Le chemin d'exécution est prédéfini, mais les étapes intermédiaires nécessitent un raisonnement.           | **Moyen :** Série d'étapes basées sur Apex ou Flux avec des résultats variables.                        | **Modalités mixtes :** L'entrée ou la sortie peut combiner des données structurées et non structurées à faible volume.                        | Hybride (Agentforce + Apex/Flux) : Utilisez Agentforce pour le raisonnement et la planification à haute densité, Agent Script pour le déterminisme guidé et Apex/Flow pour l'orchestration. |
| **Élevée**          | Partiellement ou non spécifiable. L'objectif est prédéfini, mais les étapes intermédiaires nécessitent un contexte d'exécution et une intention de l'utilisateur. | **Élevée :** Plusieurs objectifs concurrents avec des besoins de raisonnement lourds nécessitent des résultats déterministes. | **Modalités mixtes :** L'entrée ou la sortie peut combiner d'importants volumes de données structurées et non structurées arrivant en temps réel. | Utilisez le script Agent pour équilibrer le contrôle déterministe et le raisonnement. Utilisez MuleSoft Agent Fabric pour des MCP tiers ou A2A pour une collaboration multi-agents complexe.  |

## Comparaison des produits

| Capacité                     | Automatisation traditionnelle (Flux/Apex)                                                                                        | Grille Agentforce                                                                                                                               | Agentforce                                                                                                                             | Agentforce avec Agent Script                                                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Type logique et déterminisme**   | **Déterministe :** Utilise une logique if-then-else fixe. Le chemin d'exécution est 100 % prévisible en fonction de l'état de l'enregistrement.           | **Mixte :** Déterministe via des étapes structurées alors que les étapes IA individuelles peuvent être probabilistes.                                                 | **Probabiliste :** Utilise le raisonnement à plusieurs tours pour déterminer le meilleur chemin vers un objectif.                                                 | **Déterminisme guidé :** Utilise le raisonnement pour planifier le parcours et autorise l'exécution sur des parcours de nœud déterministes.                                              |
| **Rapidité de livraison**          | **Recommandé (Flux) :** Les outils visuels permettent d'élaborer rapidement une logique déclenchée par un enregistrement sans code.                         | **Recommandé pour l'automatisation IA répétitive :** La méthode la plus rapide pour appliquer une logique IA à travers des ensembles d'enregistrements existants sans élaborer de nouveaux flux.           | **Recommandé :** Pour la configuration de Sous-agents (auparavant Rubriques), Instructions et Mappage des compétences pour un domaine ou un problème spécifique. | **Recommandé :** Pour le mappage avancé des graphiques basés sur l'état et de la logique des bords.                                                                            |
| **Modalité d'entrée**             | **Recommandé pour structuré uniquement&nbsp;:** Limité aux champs CRM et aux collections d'enregistrements associées.                                | **Recommandé pour semi-structuré&nbsp;:** Traite le texte en masse (descriptions, transcriptions) des champs d'enregistrement.                                      | **Recommandé pour le multimodal :** Traite le langage naturel, la voix et la vision (données non structurées).                                    | **Recommandé pour la haute densité&nbsp;:** Synthétise les entrées multimodales avec des données d'état système en temps réel.                                                     |
| **Profondeur de raisonnement (planification)** | **Non disponible :** La logique est impérative; elle ne peut pas "penser" ou planifier dynamiquement des étapes. Cependant, les données peuvent être envoyées aux agents. | **Faible :** Inférence à une étape appliquée à travers un ensemble d'enregistrements (IA par lot).                                                                        | **Moyen/Élevé :** Utilise des boucles de raisonnement (Reason-Act-Observe) pour résoudre une intention complexe.                                                  | **Régie :** Le raisonnement est limité à la navigation dans un graphique prédéfini des états métiers.                                                            |
| **Modularité et réutilisation**   | **Recommandé :** Modulaire par défaut via des flux secondaires et des classes Apex.                                                        | **Limité :** La logique est généralement liée à la ligne de grille spécifique. Les configurations de colonne et les workflows basés sur un modèle peuvent être réutilisés dans l'ensemble de lignes complet. | **Disponible&nbsp;:** Les compétences (Flux/Apex) sont réutilisées à travers différents Sous-agents (auparavant Rubriques) et agents connectés.                     | **Recommandé&nbsp;:** Les nœuds du Graphique de l'agent sont des unités fonctionnelles discrètes et réutilisables.                                                                     |
| **Contrôle des transactions et DML**  | **Recommandé (Apex)&nbsp;:** Contrôle total des points d'enregistrement, des annulations et du traitement en masse.                                       | **Disponible :** Chaque ligne est traitée indépendamment. Par conséquent, l'étendue d'exécution est définie par enregistrement.                                                         | **Limité :** Les actions sont exécutées en tant qu'étapes individuelles et découplées dans une session.                                                         | **Recommandé :** Utilise des nœuds Flow/Apex pour servir d'ancrages déterministes à tous les DML. La prise en charge du contrôle des transactions distribué entre les agents est limitée. |
| **Traitement des ambiguïtés**         | **Non disponible :** Nécessite des parcours prédéfinis. Une entrée inattendue entraîne un échec ou des erreurs statiques.                        | **Limité :** La qualité de sortie dépend de l'ancrage du prompt. Le workflow ne peut pas demander de clarification interactive.                             | **Recommandé&nbsp;:** Gère les états « inconnus » en posant des questions ou en sélectionnant des compétences alternatives.                                           | **Disponible&nbsp;:** Utilise les « nœuds de repli » pour gérer les échecs de raisonnement ou les expirations de traitement.                                                                 |
| **Visibilité et gouvernance**    | **Recommandé :** L'Explorateur de déclencheur de flux fournit une carte visuelle de toute logique déclenchée par un enregistrement.                               | **Disponible&nbsp;:** L'interface utilisateur basée sur la grille offre une visibilité claire sur les résultats au niveau de la ligne et prend en charge l'auditabilité des résultats.                           | **Disponible&nbsp;:** Les journaux de surveillance indiquent clairement comment l'agent a pris des décisions.                                                 | **Expertise requise&nbsp;:** Nécessite de surveiller les journaux d'inférence de traversée de graphique et de LLM.                                                           |
| **Performances et échelle**        | **Recommandé** Optimisé pour le traitement d'enregistrements synchrones à haut volume.                                                  | **Recommandé** Traite efficacement les tâches d’IA en masse à travers des volumes de données importants.                                                                | **Latence sensible** Dépend du temps d'inférence; ne convient pas aux mises à jour en masse à haute densité.                                           | **Modéré** Convient pour les tâches complexes à long terme, mais a des frais généraux plus élevés.                                                                         |

## Cas d'utilisation

Le tableau ci-dessous présente des recommandations générales sur la meilleure adéquation pour divers cas d'utilisation.

| Cas d'utilisation                                                    | Description                                                                                                                                                                                                                                | Le plus adapté                                                                                                                                                                                                                           | Justification                                                                                                                                                                                                                                                                                                                                                                                           |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Traitement des enregistrements**                                       | Automatisation déclenchée par un événement DML dans un objet Salesforce structuré où chaque branche et résultat peut être entièrement défini lors de la conception.                                                                                                  | Utilisez le flux déclenché par un enregistrement. Il s'agit d'une automatisation traditionnelle à faible densité.                                                                                                                                                           | Faible densité d'orchestration. Une seule modalité (champs CRM structurés) et un seul objectif contenu avec un chemin d'exécution prévisible et auditable.                                                                                                                                                                                                                                                        |
| **Contrôle transactionnel avec une logique complexe**                | Automatisation nécessitant des points de sauvegarde, des annulations, des validations partielles ou une manipulation de données sécurisée en masse pour des volumes d'enregistrements élevés.                                                                                                                    | Utilisez Apex pour l'automatisation déterministe traditionnelle à faible densité.                                                                                                                                                                    | Faible densité d'orchestration. Apex fournit un contrôle total sur l'intégrité des transactions, la déduplication du calcul coûteux et la mise en cache au niveau de la plate-forme - des capacités qui ne sont pas disponibles dans Flux.                                                                                                                                                                                                         |
| **Logique moyennement complexe dans un processus structuré**    | L'automatisation dans laquelle le processus global est basé sur des règles, mais les étapes individuelles nécessitent un calcul ou une manipulation des données qui dépasse la capacité déclarative.                                                                                            | Utilisez Flux avec Apex invocable pour une logique déterministe à faible densité.                                                                                                                                                                  | Faible densité d'orchestration. Flow agit comme la couche d'orchestration ; Apex invocable encapsule les opérations hautement complexes en tant que composants réutilisables et sûrs pour le traitement en masse.                                                                                                                                                                                                                                          |
| **Traitement planifié et temporel**                       | Automatisation qui doit être exécutée à une date future calculée dynamiquement par rapport à un événement d'enregistrement.                                                                                                                                           | Utilisez l'automatisation traditionnelle (flux déclenchés par un enregistrement) pour le traitement déterministe à faible densité.                                                                                                                                      | Faible densité d'orchestration. Les [chemins planifiés](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5) permettent de planifier, d ' annuler et de reprogrammer automatiquement si les données d ' enregistrement changent − ce qui n ' est pas le cas dans les déclencheurs Apex.                                                                                                            |
| **Inférence d'enregistrement en masse**                                   | Appliquer uniformément une étape de raisonnement IA unique à un grand nombre d'enregistrements existants pour générer une classification, un résumé ou un score.                                                                                                      | Utilisez Agentforce Grid pour l'inférence par lot et pour utiliser les capacités agentiques répétitives à l'échelle.                                                                                                                                       | Densité d'orchestration moyenne. Inférence par lot avec une seule modalité à l'échelle&nbsp;: l'agent lit les champs d'enregistrement structurés et renvoie une sortie uniforme dans chaque enregistrement. Faible complexité des objectifs avec un modèle d'inférence répétitif.                                                                                                                                                                   |
| **Résolution d'entrée non structurée**                           | Automatisation où le point d'entrée est une requête, un e-mail ou une conversation en langage naturel qui doit être interprété, classé et résolu par le raisonnement.                                                                               | Utilisez Agentforce pour une résolution d'entrée non structurée, pilotée par les intentions et de densité moyenne.                                                                                                                                                   | Densité d'orchestration moyenne. Modalité mixte : l'agent consomme une entrée conversationnelle non structurée, puis produit des réponses textuelles ou des mises à jour d'enregistrement structurées. L'objectif nécessite de résoudre l'intention des utilisateurs à travers un ensemble limité de résultats.                                                                                                                                                            |
| **Logique moyennement complexe dans un processus probabiliste** | Automatisation où le processus global est basé sur des règles, mais où des étapes individuelles nécessitent des capacités IA telles que la récupération résumée ou RAG.                                                                                                            | Utilisez Flux avec Apex invocable et Modèles d'invite pour des processus déterministes à faible densité nécessitant des capacités IA.                                                                                                               | Densité d'orchestration moyenne. Le flux agit comme la couche d'orchestration tandis que [Modèles d'invite](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api), [Agentforce Service agent](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5) et Agentforce Employee agent sont exposés en tant qu'actions invocables. |
| **Orchestration de processus guidée**                            | Automatisation couvrant les workflows à plusieurs étapes dans lesquels la réalisation d'une action déclenche des actions supplémentaires                                                                                                                                  | Utilisez [Script Agent avec Actions](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining) pour des parcours d'exécution à haute densité non spécifiés qui nécessitent une orchestration guidée des processus. | Densité d'orchestration élevée - modalité mixte entre les entrées et les sorties. Résultats concurrents et requêtes périphériques qui ne peuvent pas être entièrement anticipés au moment de la conception. Le script Agent fournit un déterminisme guidé.                                                                                                                                                                                                  |
| **Orchestration de processus intersystèmes**                      | Automatisation coordonnant un processus métier à plusieurs étapes entre plusieurs systèmes back-end dans lesquels aucun système ne possède le flux de bout en bout                                                                                                      | Utilisez l'API Process MuleSoft avec Agent Broker pour l'orchestration de processus inter-systèmes de densité moyenne à élevée.                                                                                                                          | Haute densité d'orchestration : les API de processus encapsulent une logique métier complexe à plusieurs étapes afin d'éviter aux agents de comprendre l'orchestration derrière des opérations telles que le traitement des commandes ou les contrôles d'inventaire. [Agent Broker](https://www.mulesoft.com/ai/agent-broker) séquence et invoque dynamiquement les agents et les outils requis à partir d'un seul objectif en langage naturel.                               |
| **Abstraction du système back-end**                              | Orchestration où les agents doivent interfacer avec des systèmes hérités, des bases de données ou des plates-formes SaaS tierces dépourvues de connectivité Agentforce native.                                                                                            | Utilisez MuleSoft avec le connecteur MCP pour envelopper les systèmes hérités et fournir le contexte du modèle.                                                                                                                                              | Densité d'orchestration moyenne. Les API système offrent une interface sécurisée et abstraite aux systèmes d'enregistrement, ce qui permet de dissocier les workflows agents de la complexité back-end. Le connecteur MCP transforme les applications MuleSoft en serveurs conformes MCP pour une découverte et une invocation immédiates.                                                                                                  |
| **Traitement des documents à haut volume et gestion des exceptions**  | Automatisation qui lit, interprète et rapproche les documents structurés et semi-structurés entrants des enregistrements existants à l'échelle - traitement des écarts, des correspondances partielles et des exceptions avec une intervention manuelle appropriée.          | Utilisez Agentforce Operations pour le traitement de documents à volume élevé de moyenne densité piloté par les intentions.                                                                                                                                       | Densité d'orchestration moyenne avec une modalité d'entrée semi-structurée. Complexité des objectifs pilotée par les règles de correspondance, les chemins d'exception et les seuils d'approbation par document. Nécessite un raisonnement par enregistrement, pas une inférence à un tour uniforme.                                                                                                                                                                |
| **Orchestration multi-agents entre fournisseurs**                | L'automatisation nécessite une collaboration entre des agents spécialisés élaborés sur différentes plates-formes ou fournisseurs.                                                                                                                                      | Utilisez MuleSoft avec le connecteur A2A et le tissu Agent pour l'orchestration multi-agents à travers différents systèmes.                                                                                                                           | Densité d'orchestration moyenne à élevée. Le connecteur A2A permet des workflows multi-agents pair à pair avec une gouvernance et une fiabilité de niveau entreprise, quel que soit l'emplacement où chaque agent est élaboré ou hébergé.                                                                                                                                                                                             |
| **Conversion de document non structuré en workflow**            | Automatisation dans laquelle les processus opérationnels définis dans des sources non structurées (SOP, documents de règles fournisseur ou diagrammes de processus) doivent être convertis en workflows agentsiques exécutables sans codage manuel.                                     | Utilisez Agentforce Operations pour convertir des documents non structurés émergents à haute densité en workflows.                                                                                                                                | Haute densité avec un mélange élevé de modalités en entrée. Ingère des fichiers PDF, des documents Word et des diagrammes basés sur des images. Complexité de l'objectif déterminée par la portée et la branchement du processus ingéré. Le chemin d'exécution ne peut pas être spécifié lors de la conception.                                                                                                                                                           |
| **Orchestration multipartie**                               | Automatisation couvrant l'intégration coordonnée de parties externes - collecte des données requises, vérification de la conformité, gestion des approbations et mise à jour des systèmes d'enregistrement à travers de nombreuses pistes d'intégration simultanées.                         | Utilisez Agentforce Operations pour une orchestration multipartite de densité moyenne à élevée, pilotée par l'intention et émergente.                                                                                                                         | Plusieurs étapes de vérification et d'approbation interdépendantes doivent être résolues de façon séquentielle avant la fin de l'intégration. La combinaison de modalités comprend des enregistrements structurés, des documents non structurés et des communications externes.                                                                                                                                                                                 |
| **Intervention prédictive sur les actifs**                           | Automatisation dans laquelle un moteur prédictif ingère des télémesures en temps réel pour identifier les conditions de défaillance imminentes et déclencher une réponse back-office coordonnée à plusieurs étapes.                                                                      | Utilisez Agentforce Operations et Agentforce pour Manufacturing pour une intervention prédictive sur les actifs à haute densité.                                                                                                                         | Data Cloud gère la télémétrie Internet des objets à haute modalité et la détection des anomalies. Agentforce Operations orchestre ensuite le workflow back-office de modalité moyenne (gestion des enregistrements d'assistance sur site, des données d'inventaire et des communications avec les clients) pour résoudre le processus de bout en bout.                                                                                                                                |
| **Gestion de la communication fournisseur à grande échelle**           | Automatisation gérant les communications structurées et semi-structurées continues à travers une large base de fournisseurs, y compris les accusés de réception de commande, les changements de date de livraison et les notifications d'exception.                                            | Utilisez Agentforce Operations for Batch Inferences pour une gestion des communications fournisseur de densité moyenne.                                                                                                                              | Lorsque les communications sont uniformes entre les fournisseurs, utilisez Agentforce Grid pour le traitement par lot. Lorsque les réponses nécessitent un raisonnement contextuel par relation fournisseur, escaladez vers une densité moyenne avec Agentforce Operations.                                                                                                                                                                         |
| **Gestion des pistes (acheminement intelligent et haute vitesse)**       | Automatisation qui ingère des réponses marketing en temps réel, utilise le score IA et l'enrichissement de Data Cloud pour la qualification, et utilise des flux pour l'attribution intelligente en moins d'une minute et l'acheminement des pistes de grande qualité vers l'équipe commerciale appropriée. | Utilisez l'automatisation traditionnelle (Flux) + Data Cloud et IA pour l'acheminement intelligent des pistes, combinant une densité moyenne et une haute vitesse.                                                                                                                     | Nécessite un acheminement rapide (vitesse vers piste < 1 min) et complexe, piloté par les données, basé sur le score des pistes IA, le niveau de travail et l'historique des activités. Utilise Flows pour une logique d'attribution rapide et déterministe, augmentée par l'IA probabiliste et Data Cloud pour la qualification et l'enrichissement des pistes.                                                                                                                   |
| **Maturation des pistes**                                          | Entretient les pistes à faible score jusqu'à ce qu'elles soient prêtes pour une conversation commerciale.                                                                                                                                                                    | Utilisez Lead Nurturing Agent pour cibler et améliorer les pistes de faible qualité pour une automatisation de densité moyenne à élevée.                                                                                                                      | Envoie des e-mails personnalisés, multi-touch, basés sur les données des pistes et les réussites clients. Il gère les réponses par e-mail et utilise les Flows pour la transmission.                                                                                                                                                                                                                                                  |
| **Qualification des pistes entrantes**                              | Qualifie et entretient de façon autonome les pistes entrantes à score élevé.                                                                                                                                                                            | Utilisez Lead Nurturing Agent pour qualifier et engager des pistes.                                                                                                                                                                              | Exécute les e-mails sortants multi-touch, la prise de rendez-vous, les questions et réponses sur les produits et le traitement des objections. Il peut fonctionner en mode « Envoyer en tant que vendeur », en envoyant des e-mails via le propriétaire de la piste attribué.                                                                                                                                                                                                              |

## Mappage de cas d'utilisation

![Diagramme de mappage de cas d'utilisation montrant divers scénarios d'automatisation à travers les niveaux de densité d'orchestration](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png)

## Considérations non fonctionnelles

**Latence**

Les flux déclenchés par un enregistrement synchrones sont exécutés dans la transaction de plate-forme et terminés en millisecondes. Le temps d'inférence Agentforce dépend du Moteur de raisonnement Atlas et évolue avec la profondeur de raisonnement et la complexité des modalités. Agentforce est inadapté au traitement d'enregistrements synchrones à haut volume où la latence est une contrainte principale.

**Coût**

Le coût de raisonnement d'un workflow agentique doit être justifié par rapport à la valeur métier du résultat. Pour les tâches à haut volume et à faible densité d'orchestration où un parcours déterministe existe, l'automatisation traditionnelle ou Agentforce Grid peut être plus économique qu'un workflow agentique de bout en bout. Assurez-vous que la conception tient compte du modèle de nouvelle tentative approprié avec des limites de tentatives explicites et des interrupteurs. Ce garde-fou limite le risque de dépassement de coût aggravé associé au traitement en masse.

**Limites du gouverneur**

Évaluez les workflows agents à haut volume par rapport aux limites quotidiennes de la plate-forme pour l'exécution asynchrone. Les opérations par lot Agentforce Grid respectent les limites en transactions de plate-forme standard. Pour une automatisation impliquant des objets Salesforce, tenez compte du nombre total d'opérations DML quotidiennes, car Salesforce applique automatiquement la gestion des ressources partagées dans un environnement multilocataire, et les [limites du gouverneur](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150) afin d'éviter que des automatisations galopantes monopolisent les ressources partagées.

**Auditabilité et conformité**

L'automatisation traditionnelle produit des parcours d'exécution entièrement auditables via l'Explorateur de déclencheur de flux et les journaux Apex. Les schémas de bout en bout ou hybrides basés sur Agentforce produisent des journaux de raisonnement qui offrent une transparence dans la prise de décision des agents, mais dont l'interprétation nécessite une expertise. Le déterminisme guidé via le script Agent est le schéma recommandé pour les secteurs réglementés dans lesquels l'auditabilité complète de l'exécution est une exigence de conformité.

**Escalade**

Les workflows des agents fonctionnant à haute densité doivent inclure une approbation humaine explicite ou des portes d'escalade pour les actions ayant des conséquences irréversibles, telles que les transactions financières, les soumissions réglementaires ou les engagements des fournisseurs. Les contrôles conditionnels Script de l'agent fournissent le mécanisme d'application déterministe de ces portes dans un workflow autrement agentique.

## Meilleures pratiques associées

**Privilégiez la simplicité dans votre conception d'orchestration**. Commencez au niveau d'orchestration minimal qui peut atteindre l'objectif, validez-le en charge réelle, puis itérez. Chaque agent, transfert ou dépendance supplémentaire dans votre chaîne introduit une nouvelle surface qui peut produire un comportement incohérent.

Dans votre chemin d'exécution spécifié, commencez à incorporer un agent aux nœuds où le raisonnement est requis. Suivez les meilleures pratiques de création d'agents dans Agentforce. Évitez d'empaqueter de nombreux sous-agents (auparavant des « rubriques ») et ne gonflez jamais les instructions. Les agents déployés dans des cas d'automatisation peuvent se permettre d'être « lean », car ils ne sont pas la seule interface. Choisissez la primitive appropriée pour l'enchaînement. Un schéma d'orchestration (délégation) contrôle plus étroitement la séquence d'exécution et peut déléguer des tâches secondaires à des spécialistes. Évitez les schémas chorégraphiés (handoff). Si vous devez implémenter une conception de transfert, fournissez à l'agent destinataire l'objectif, le contexte et l'état afin qu'il puisse optimiser les objectifs globaux plutôt que locaux.

**Évitez la prolifération des actions ou des outils**. Les actions sont l'endroit où le raisonnement de l'agent est réalisé, et leur conception détermine si elles produisent des résultats fiables ou des échecs. Chaque action doit renvoyer une réponse structurée et observable que l'agent IA peut utiliser pour planifier la prochaine tournure de la conversation.

Avoir plusieurs actions (et différentes constructions de sortie) pour effectuer la même tâche diminue la capacité de l'agent à raisonner ou à choisir l'outil approprié pour le travail. Cela peut faire manquer des nuances à l'agent. Le chevauchement des définitions d'action risque d'entraîner une classification incorrecte. Assurez-vous que votre bibliothèque d'actions est auditée, mise en version et conforme à l'étendue Sous-agent (auparavant Rubrique).

**Définissez des objectifs observables.** Définissez l'objectif comme un résultat observable, pas seulement une procédure. Un objectif vague invite à la dérive des agents. Augmentez avec un chemin d'exécution spécifique. Utilisez Graphique de l'agent avec un raisonnement hybride pour modéliser l'objectif en tant que nœud de graphique avec un état explicite. L'exécution suit la position actuelle de l'agent dans le workflow et le restaure après des entrées tangentielles. Il ne perd pas l'objectif lorsqu'il reçoit des informations supplémentaires dans la fenêtre contextuelle.

**Testez et évaluez**. Implémentez un cadre de test et d'évaluation robuste pour valider le raisonnement des nœuds probabilistes et la sortie des automatisations agentiques. Vérifiez les parcours d'exécution par rapport à un parcours de résultat attendu pour vous assurer que le modèle arrive au résultat correct. Empêchez les échecs silencieux lorsqu'un agent signale faussement une réussite ou entre dans une boucle infinie ou irrécupérable en affirmant les résultats aux étapes d'exécution. Utilisez le [traçage des sessions](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5) pour inspecter les interactions tour par tour, les exécutions du moteur de raisonnement, les actions, les entrées/sorties d'invites et de passerelles, les messages d'erreur et les réponses finales.

## Ressources

<table>
  <thead>
    <tr>
      <th scope="col">Agentforce</th>
      <th scope="col">Automatisation traditionnelle</th>
      <th scope="col">Intégration</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5">Agentforce</a></li>
          <li><a href="https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html">Script d'agent</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5">Agentforce Grid</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5">Opérations Agentforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5">Agent de service Agentforce et Agent Employé Agentforce</a></li>
          <li><a href="https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining">Script d'agent avec actions</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5">Flux Salesforce</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Apex Salesforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5">Parcours de flux planifiés</a></li>
          <li><a href="https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api">Modèles d'invite</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="/docs/architect/fr-fr/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html">MuleSoft</a></li>
          <li><a href="https://www.mulesoft.com/ai/agent-broker">Agent Broker</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

**À propos de l'auteur**

Arvind Palaniswamy est architecte en génie logiciel au Bureau de l'architecte en chef, équipe Well-Architected. Il aime encadrer les systèmes complexes dans leurs formes les plus simples en utilisant des principes premiers. Il comprend l'ingénierie, les opérations et les affaires à travers des décennies d'expérience et de formation MS/MBA (Kellogg).

<!-- document id=988e2cecbcc42bfa8c9749079c6c822b2d56b799f35614d6f9a2923e9f61255a url=/architect/current/fr-fr/decision-guides/guides/data-integration.md -->

# Intégration de données avec Salesforce

Il existe une multitude de méthodes pour accéder à, synchroniser et partager des données entre Salesforce et des systèmes externes. Cependant, tous les outils ne sont pas adaptés à votre projet particulier. Ce guide présente le paysage des outils d'intégration de données disponibles dans Salesforce. Il propose également des recommandations sur les outils (ou combinaisons d'outils) les plus appropriés compte tenu d'un cas d'utilisation particulier, ainsi que des conseils sur les outils à éviter pour des scénarios spécifiques.

## Présentation du guide

Ce guide de décision se concentre sur les intégrations au niveau des données impliquant Salesforce. Plus précisément, il couvre les cas d'utilisation d'intégration de données suivants :

- Salesforce vers des systèmes externes
- Systèmes externes à Salesforce
- Organisation Salesforce vers organisation Salesforce

Il ne s'agit que d'un sous-ensemble des défis auxquels Salesforce Architects est confrontée. Par conséquent, nous envisageons d'ajouter d'autres guides de décision axés sur l'intégration pilotée par l'événement, l'élaboration de workflows efficaces pour les clients ou les employés en utilisant l'intégration de processus, etc. Enfin, il est important de noter que de nombreux outils et approches décrits ici peuvent être utilisés pour résoudre des défis d'intégration dans l'ensemble de l'entreprise, mais ces utilisations dépassent la portée de ce guide.

## Points à retenir

- **Évitez la réplication inutile des données.** Sauf si les données doivent absolument résider dans Salesforce, pensez à la place à la virtualisation des données avec Salesforce Connect. Au final, un plus grand nombre de données dans votre organisation entraîne des volumes de données plus importants, ce qui peut affecter [les performances](/docs/architect/fr-fr/well-architected/guide/reliability.html#scalability-and-capacity-planning) et augmenter la dette technique. Si vos données résident déjà dans Salesforce et que vous en avez besoin dans un système externe, évitez de les copier dans un système externe, sauf en cas de nécessité absolue. À la place, demandez au système externe d'accéder aux données via les API Salesforce.
- **Utilisez MuleSoft ou d'autres solutions Enterprise Service Bus (ESB) ou Extraire-Transformer-Load (ETL), si elles sont disponibles et font partie de votre paysage existant.** Ces outils sont conçus pour prendre en charge la migration et la transformation des données. Par conséquent, ils sont souvent dotés de puissantes capacités qui permettent de réutiliser les intégrations dans l'entreprise, de renforcer la gouvernance et de centraliser la gestion des intégrations. Dans ce guide, partout où MuleSoft Anypoint est recommandé, déterminez si votre solution ESB/ETL existante suffit.
- **Harmonisez les données de différentes sources avec Data 360 et Data Cloud One.** Grâce au modèle de données Customer 360, à la résolution de l'identité, à la fédération des données et à d'autres fonctionnalités, Data 360 consolide les données de Salesforce et d'autres systèmes externes dans une vue unifiée de votre client. Avec [Data Cloud One](/docs/architect/fr-fr/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one), les utilisateurs d'autres organisations Salesforce peuvent accéder en toute sécurité aux données partagées virtuellement depuis Data 360 via des espaces de données.
- Déplacez des données entre les organisations en utilisant des **actions et des activations Data 360.** Une fois les données ingérées depuis différentes organisations dans Data 360, les [actions et activations](/docs/architect/fr-fr/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound) de données peuvent synchroniser les données vers une autre organisation. Cette approche peut s'avérer très utile pour les intégrations à des organisations Marketing Cloud.
- Extrayez et déplacez des données en utilisant **MuleSoft Anypoint.** MuleSoft Anypoint peut être utilisé pour extraire des données de Data 360 en utilisant l'API Connect et l'API Data Graph et les déplacer vers une autre organisation Salesforce. Sans Data 360, MuleSoft Anypoint peut également être utilisé lorsque les données doivent être déplacées entre les organisations sans être répliquées dans Data 360.
- **Faites preuve de prudence si vous choisissez d'utiliser la messagerie sortante.** Salesforce continuera de prendre en charge Messagerie sortante dans les limites des capacités fonctionnelles actuelles, mais n'envisage pas d'autres investissements dans cette technologie.
- **Une licence utilisateur d'intégration avec le profil « API uniquement » est toujours recommandée pour toutes les intégrations.** Salesforce recommande également d'utiliser des applications clientes externes (en faveur des applications connectées ou de la connexion SOAP) en tant que modèles AuthN et AuthZ correctement autorisés pour toutes les intégrations.

## Considérations courantes relatives au choix d'outils d'intégration de données

Avant d'explorer les outils d'intégration de données disponibles, il est important de tenir compte de quelques considérations courantes lors du choix d'un outil. Comme c'est le cas avec l'architecture, il n'y a pas de réponse prescriptive à chaque défi métier. Si vous avez prononcé les mots « ça dépend » en faisant des choix d'intégration, vous êtes au bon endroit.

<table>
    <thead>
        <tr>
            <th>Domaine à considérer</th>
            <th>Questions courantes</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Outils et paysage existants</td>
            <td>Existe-t-il une solution ESB ou ETL existante ? Les données concernées ont-elles des exigences réglementaires ou de conformité ? Où se situent les systèmes que vous essayez d'intégrer (dans le cloud ou sur site) ?</td>
        </tr>
        <tr>
            <td>Flux de données (Temps, Expérience utilisateur attendue, Directionnalité)</td>
            <td>Les données doivent-elles être déplacées de façon synchrone, asynchrone ou peuvent-elles être regroupées par lot ou planifiées ? La réplication des données est-elle requise ? Quel système doit être la source de la vérité ? Quelle est la source de données ? Quelle est la destination cible ? Une interaction utilisateur est-elle requise ? L'utilisateur doit-il afficher le résultat de l'intégration ? Quels sont les besoins liés au traitement des exceptions (réessayer, notifier, échouer) ? Quel est le degré de couplage des systèmes ?</td>
        </tr>
        <tr>
            <td>Implémentation</td>
            <td>Quel est le niveau d'effort pour les systèmes non-Salesforce ? Quelles sont les équipes responsables de la livraison des intégrations ? Quels outils préfèrent-ils utiliser ?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/fr-fr/well-architected/guide/resource-and-cost-optimization.html#code-organization">Maintenabilité</a></td>
            <td>Quelles équipes devront maintenir l'intégration ? Quelles sont leurs compétences actuelles ? De quelles compétences auront-ils besoin à l'avenir? Quel est le coût total de possession au fil du temps ? Quelle est l'importance de pouvoir tester, déboguer, dépanner avec des outils à code faible ou pro ?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/fr-fr/well-architected/guide/reliability.html#scalability-and-capacity-planning">Volume de données</a></td>
            <td>Quel volume de données est impliqué dans l'intégration ? Travaillerez-vous avec des <a href="https://trailhead.salesforce.com/content/learn/modules/large-data-volumes">Large Data Volumes</a> (LDV) ? À quelle fréquence les changements se produiront-ils en masse ? Quel impact les mises à jour singleton auront-elles ? À quelle fréquence se produiront-elles?</td>
        </tr>
        <tr>
            <td>Limites</td>
            <td>Les données devront-elles subir une transformation complexe ? Les données doivent-elles être combinées à partir de plusieurs systèmes sources ? À quelle fréquence une intégration sera-t-elle effectuée par utilisateur ? Combien d'utilisateurs au total ? Avez-vous planifié à l'avance des chargements de données en masse (exemple : chargement initial des données pour une nouvelle instance) ?</td>
        </tr>
    </tbody>
</table>

## Comparaison des produits

Voici une vue d'ensemble des outils disponibles pour l'intégration de données et quelques considérations pour commencer à évaluer chaque option. Les sections suivantes présentent des cas d'utilisation détaillés et des détails sur les capacités de ces outils.

<table>
    <thead>
        <tr>
            <th></th>
            <th>De Salesforce au système externe</th>
            <th>Du système externe à Salesforce</th>
            <th>Exécution</th>
            <th>Licence supplémentaire requise</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Actions Apex</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Non</td>
        </tr>
        <tr>
            <td><strong>Change Data Capture</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-no">Non disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Non*</td>
        </tr>
        <tr>
            <td><strong>Apex personnalisé (services Web REST et SOAP)</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Non</td>
        </tr>
        <tr>
            <td><strong>Services externes</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-no">Non disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Non</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Oui</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Oui</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Oui</td>
        </tr>
        <tr>
            <td><strong>API natives Salesforce</strong></td>
            <td class="guide-table-no">Non disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Non</td>
        </tr>
        <tr>
            <td><strong>Omniscript</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-no">Côté client***</td>
            <td>Oui</td>
        </tr>
        <tr>
            <td><strong>Procédure d'intégration OmniStudio</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Oui</td>
        </tr>
        <tr>
            <td><strong>Messagerie sortante</strong></td>
            <td>Pas idéal</td>
            <td class="guide-table-no">Non disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Non</td>
        </tr>
        <tr>
            <td><strong>Événements de plate-forme</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Non**</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objets externes</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Côté serveur</td>
            <td>Oui</td>
        </tr>
    </tbody>
</table>

[\*Complément requis pour les cas d'utilisation d'événements de capture de données à haut volume](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm)

[\*\*Complément requis pour les cas d'utilisation d'événements de plate-forme à haut volume](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)

\*\*\*Convient dans les situations où la logique métier peut être exécutée dans le navigateur Web.

Légende de colonne :

- **Disponible**: fonctionne bien pour la plupart des cas d'utilisation
- **Pas idéal**: possible mais envisager un outil alternatif
- **Non disponible**: aucun projet de prise en charge dans les douze prochains mois

### Autres outils pour déplacer des données vers et depuis Salesforce

D'autres outils peuvent prendre en charge certains aspects d'une intégration de couche de données, mais ne doivent pas être considérés comme un moyen principal de résoudre les problèmes d'intégration. Examinons maintenant rapidement ces outils.

Les **composants Web Lightning** sont généralement utilisés pour l ' intégration de processus, mais ils peuvent passer des appels externes en utilisant la fonctionnalité JavaScript.

**Salesforce Flow** peut être utilisé pour orchestrer des appels externes avec des Services externes ou des Actions Apex. Salesforce Flow en soi n'est pas considéré comme un outil d'intégration de données autonome.

**Data Import Wizard et Data Loader** peuvent être utilisés pour synchroniser, importer et migrer des données. Les commandes Data Loader peuvent également être scriptées pour automatiser l'importation et l'exportation de données, mais l'[interface de ligne](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm) de commande est uniquement pour Windows et aucun de ces outils n'est recommandé pour une stratégie d'intégration de données. Utilisez-les à la place pour compléter votre stratégie de gestion et de maintenance des données.

Les commandes de données [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) peuvent être utilisées pour manipuler des enregistrements dans votre organisation. Des commandes sont disponibles pour vous aider à importer et à exporter des données avec l'API de transfert en masse et l'API d'enregistrement d'arborescence SObject, et à exécuter de simples opérations CRUD sur des enregistrements individuels avec l'API REST. La Salesforce CLI en soi n'est pas considérée comme un outil d'intégration de données autonome.

**OmniStudio Data Mapper** peut être utilisé comme outil ETL déclaratif pour déplacer des données entre des objets Salesforce et des structures de données JSON. Bien qu'une interface REST soit automatiquement créée pour chaque interface Data Mapper, ce qui fournit une méthode déclarative pour déplacer des données depuis des systèmes externes vers des objets Salesforce, Data Mapper autonome n'est pas une base recommandée pour une stratégie d'intégration de données. Les actions Data Mapper sont disponibles dans Procédures d'intégration OmniStudio.

[**Dataloader.io**](http://dataloader.io/) est un autre outil de chargement de données pour Salesforce propulsé par Anypoint Platform de MuleSoft qui permet d'importer, d'exporter et de supprimer rapidement et en toute sécurité des quantités illimitées de données pour votre entreprise. Dataloader.io n'est pas une base recommandée pour une stratégie d'intégration de données.

## Salesforce vers des systèmes externes (intégration sortante)

Pour les intégrations sortantes depuis Salesforce, vous pouvez envisager différents types d'outils : low-code, pro-code ou un hybride. Les sections suivantes fournissent des conseils pour chaque type d'outil et offrent des exemples de solutions.

- [Outils low-code pour les intégrations sortantes](#outils-low-code-pour-les-intégrations-sortantes-depuis-salesforce)
- [Outils hybrides pour les intégrations sortantes](#outils-hybrides-pour-les-intégrations-sortantes-depuis-salesforce)
- [Outils pro-code pour les intégrations sortantes](#outils-pro-code-pour-les-intégrations-sortantes-depuis-salesforce)

### Outils low-code pour les intégrations sortantes depuis Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guide</th>
            <th>Licence</th>
            <th>Calendrier</th>
            <th>Volume et échelle</th>
            <th></th>
            <th>Livraison et maintenance</th>
            <th></th>
            <th></th>
            <th>Confidentialité et sécurité</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quand utiliser</strong></th>
            <th><strong>Licence supplémentaire</strong></th>
            <th><strong>Synchronisation (demande/réponse) ou asynchrone (lancer/ignorer)</strong></th>
            <th><strong>Support multi-objets</strong></th>
            <th><strong>LDV/En masse</strong></th>
            <th><strong>Test et déploiement**</strong></th>
            <th><strong>Débogage</strong></th>
            <th><strong>Gestion intégrée des erreurs/comportement de réessai</strong></th>
            <th><strong>Peut être utilisé avec des données cryptées au repos</strong></th>
            <th><strong>Protocole d'authentification</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Capture des modifications de données</strong></td>
            <td>Lorsque vous devez publier des modifications au niveau de l'enregistrement effectuées dans Salesforce sur un système externe et que vous n'avez pas besoin d'une charge de travail personnalisée.</td>
            <td>Obligatoire</td>
            <td>Asynchrone</td>
            <td>Non</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Services externes</strong></td>
            <td>Lorsque vous orchestrez un processus en utilisant Flow, Apex, Robots Einstein ou OmniStudio et que les API système externes sont décrites en utilisant les spécifications OpenAPI.</td>
            <td>Non requis</td>
            <td>Synchronisation</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td>S.O.</td>
            <td>Identifiants nommés</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Lorsque vous souhaitez étendre vos données avec la synchronisation bidirectionnelle pour activer les applications mobiles et autres dans Heroku, et que vous souhaitez également répliquer les données dans Salesforce.</td>
            <td>Obligatoire</td>
            <td>Asynchrone</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui, via Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procédure d'intégration OmniStudio</strong></td>
            <td>Lorsque vous devez transformer des données sans interaction de l'utilisateur et améliorer les performances en traitant sur le serveur au lieu du navigateur.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Support déclaratif</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Identifiants nommés</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objets externes</strong></td>
            <td>Lorsque vous souhaitez afficher des données dans l'interface utilisateur de Salesforce, mais que les données sont stockées dans un système externe. Les données ne sont pas répliquées dans Salesforce.</td>
            <td>Obligatoire</td>
            <td>Synchronisation</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui*</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code et un traceur déclaratif</td>
            <td>Non</td>
            <td>S.O.</td>
            <td>Identifiants nommés</td>
        </tr>
        <tr>
            <td colspan="11">*Les adaptateurs Odata antérieurs à la version 4.01 sont soumis à des limitations en appels externes. Voir <a href="https://help.salesforce.com/s/articleView?id=platform.odata_general_limits.htm&type=5">Considérations relatives à la limite en taux d'appels externes OData</a> pour plus de détails. ** Test et déploiement désigne la possibilité d'élaborer dans un environnement inférieur et de déployer en production via l'<a href="https://developer.salesforce.com/docs/metadata-coverage/">API de métadonnées</a>, des packages ou des ensembles de modifications.</td>
        </tr>
    </tbody>
</table>

### Cas d'utilisation : Intégration sortante en utilisant des outils low-code

> Lorsque des opportunités sont gagnées, une commande pour les produits associés doit être créée dans le système ERP ou le système de gestion des commandes de l'entreprise.

**Capture des données** modifiées À mesure que les enregistrements Opportunité sont mis à jour, la Capture des données modifiées publie les événements de modification qui contiennent les mises à jour des objets. Les événements de modification sont consommés du côté du client via une connexion CometD (ou via un connecteur MuleSoft) et utilisés pour mettre à jour le système ERP ou de gestion des commandes du client. Les événements de modification peuvent être enrichis pour inclure toujours des ID d'enregistrement externes ou d'autres données de l'objet (telles que la région) nécessaires à l'intégration. Les flux d'événements de modification de plusieurs objets peuvent être combinés dans _des canaux_ pour simplifier le traitement des abonnements et des flux (vous pouvez ainsi vous abonner à et traiter un seul flux au lieu de plusieurs).

**Services externes** Si vous avez un service Web qui prend en charge la spécification OpenAPI 2.0 ou 3.0, vous pouvez exposer les opérations et les services en tant que Service externe dans Salesforce. Les opérations d'API (par exemple créer un ordre) peuvent être appelées en tant qu'Action invocable dans un flux élaboré avec Flow Builder lorsque l'étape de l'opportunité change en « Gagné ».

**Heroku Connect** Heroku Connect est généralement utilisé pour synchroniser une base de données Heroku Postgres et Salesforce. Si le client utilise Heroku Postgres comme magasin transactionnel source de vérité, vous pouvez synchroniser les enregistrements et les modifications depuis Salesforce vers Heroku Postgres en utilisant Heroku Connect. Vous pouvez ensuite utiliser les connecteurs Heroku Streaming pour publier ces modifications dans Apache Kafka et les envoyer sous forme d'événements à des applications en aval, notamment le système ERP ou de gestion des commandes.

**Procédure d'intégration** OmniStudio Lorsqu'une commande est soumise, l'Omniscript orchestrant le processus peut publier les détails de la commande dans un connecteur ERP ou MuleSoft. La publication peut être exécutée directement par l'Omniscript (côté client) ou indirectement via une Procédure d'intégration (côté serveur). Si le système ERP renvoie une erreur de validation, l'interface utilisateur Omniscript doit notifier l'utilisateur et, si nécessaire, traduire et contextualiser l'erreur pour l'utilisateur.

**Salesforce Connect/Objets externes** Vous pouvez créer dans Salesforce un flux déclenché par un enregistrement qui insère un enregistrement dans le ou les objets externes associés lorsque l'étape de l'opportunité change en "Gagné". Comme il s'agit d'une [transaction mixte](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1), pour éviter les erreurs, ajoutez un élément Interrompre pendant zéro seconde entre la mise à jour de l'opportunité et l'insertion d'objets externes associés afin de fermer un contexte de transaction avant d'en démarrer un autre.

### Outils hybrides pour les intégrations sortantes depuis Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guide</th>
            <th>Licence</th>
            <th>Calendrier</th>
            <th>Volume et échelle</th>
            <th></th>
            <th>Livraison et maintenance</th>
            <th></th>
            <th></th>
            <th>Confidentialité et sécurité</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quand utiliser</strong></th>
            <th><strong>Licence supplémentaire</strong></th>
            <th><strong>Synchronisation (demande/réponse) ou asynchrone (lancer/ignorer)</strong></th>
            <th><strong>Support multi-objets</strong></th>
            <th><strong>LDV/En masse</strong></th>
            <th><strong>Test et déploiement**</strong></th>
            <th><strong>Débogage</strong></th>
            <th><strong>Gestion intégrée des erreurs/comportement de réessai</strong></th>
            <th><strong>Peut être utilisé avec des données cryptées au repos</strong></th>
            <th><strong>Protocole d'authentification</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Actions Apex</strong></td>
            <td>Lorsque vous souhaitez automatiser les appels externes vers un autre système via Salesforce Flow. Un développeur peut écrire une classe Apex qu'un flux peut invoquer, ou vous pouvez télécharger depuis AppExchange une solution prédéfinie.</td>
            <td>Non requis</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>Relais d'événements</strong></td>
            <td>Lorsque vous devez envoyer des événements de plate-forme et des événements de capture des données de modification à Amazon EventBridge depuis Salesforce. Les relais d'événements se connectent uniquement à AWS Eventbridge</td>
            <td>Non</td>
            <td>Asynchrone</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>HTTP/1.1 avec TLS</td>
        </tr>
        <tr>
            <td><strong>Messagerie sortante</strong></td>
            <td>Lorsque vous devez envoyer des messages SOAP sur HTTP(S) à un point de terminaison désigné avec une réception garantie lorsqu'il est déclenché par une règle de workflow.</td>
            <td>Non requis</td>
            <td>Asynchrone</td>
            <td>Non</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Support déclaratif</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>TLS bidirectionnel</td>
        </tr>
        <tr>
            <td><strong>Événements de plate-forme</strong></td>
            <td>Lorsque vous avez besoin d'une charge de travail structurée et définie sur mesure pour des modifications en temps quasi réel dans Salesforce ou un système externe.</td>
            <td>Non requis*</td>
            <td>Asynchrone</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objets externes (avec adaptateurs Apex personnalisés)</strong></td>
            <td>Lorsque vous souhaitez afficher des données dans l'interface utilisateur de Salesforce, mais que vous souhaitez que les données soient stockées dans un système externe qui ne peut pas utiliser des protocoles standard comme Odata ou GraphQL.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td>S.O.</td>
            <td>Multiple</td>
        </tr>
         <tr>
            <td><strong>Data 360</strong></td>
            <td>Lorsque vous souhaitez harmoniser les données de différentes sources dans un magasin de données, ou répliquer vos données dans d'autres organisations Salesforce ou dans d'autres systèmes externes.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

[\*Complément](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) requis pour les cas d'utilisation à haut volume.

\*\* Test et déploiement désigne la possibilité d'élaborer dans un environnement inférieur et de déployer via l'[API de métadonnées](https://developer.salesforce.com/docs/metadata-coverage/), des packages ou des ensembles de modifications en production.

### Cas d'utilisation : Intégration sortante en utilisant des outils hybrides

> Lorsque des opportunités sont gagnées, une commande pour les produits associés doit être créée dans le système ERP ou de gestion des commandes de l'entreprise.

**Actions Apex** Un flux déclenché par un enregistrement basé sur l'état de l'opportunité peut être automatiquement déclenché lorsqu'une opportunité est gagnée. Le flux exécute une action invocable qui utilise un appel externe pour soumettre la commande au système de gestion des commandes ou à la solution ERP. Les soumissions à haut volume et les commandes multisites sont gérées par des mécanismes par lot et file d'attente Apex.

**Messagerie sortante** Après avoir [configuré la messagerie sortante](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm), vous pouvez définir une règle de workflow déclenchée par la mise à jour de l'opportunité pour envoyer un message SOAP sur HTTP(S) à une URL de point de terminaison spécifiée qui héberge l'écouteur. Le message contiendra les champs spécifiés lors de la création du message sortant. Si les informations de l'objet changent après la mise en file d'attente de la notification, mais avant son envoi, seules les informations mises à jour sont livrées et les messages restent dans la file d'attente jusqu'à ce qu'ils soient envoyés avec succès ou jusqu'à ce qu'ils aient 24 heures. Après 24 heures, les messages sont retirés de la file d'attente. Si le système ERP nécessite des données supplémentaires, vous pouvez transmettre le sessionId dans des messages sortants afin que le système externe puisse effectuer une requête de rappel.

**Événements de plate-forme** Vous pouvez définir un événement de plate-forme qui inclut la charge de travail personnalisée avec les données requises pour créer les enregistrements dans le système externe. Les événements de plate-forme ne sont pas automatiquement publiés lors d'un changement d'enregistrement. Par conséquent, vous devez publier l'événement via Apex, Salesforce Flow ou Process Builder lorsque l'étape de l'opportunité change en « Gagné ». Un service externe écoute le canal d'événement de plate-forme en utilisant CometD (ou un connecteur MuleSoft) et crée les enregistrements appropriés dans le système externe.

**Salesforce Connect/External Objects (avec adaptateurs Apex personnalisés)** Une solution basée sur Salesforce Connect/External Objects n'est pas parfaitement adaptée à un cas d'utilisation qui nécessite uniquement la synchronisation des données. Cependant, cette solution peut s'appliquer lorsque les utilisateurs de Salesforce doivent afficher et potentiellement interagir avec des données du système externe, et que les données ne peuvent pas être répliquées dans Salesforce. Si le système ERP ou de gestion des commandes ne prend pas en charge les protocoles Odata ou GraphQL, l'équipe de développement peut utiliser l'[infrastructure du connecteur Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) pour écrire des classes Apex qui gèrent la communication avec le système externe via un protocole pris en charge.

**Data 360** Une solution basée sur Data 360 est parfaitement adaptée aux cas d'utilisation où nous avons besoin de données harmonisées provenant de différentes sources dans un seul magasin de données. Il peut également être utilisé lorsque nous devons répliquer des données d'une organisation Salesforce à plusieurs organisations Salesforce ou à d'autres systèmes externes en utilisant Data 360 comme plate-forme de données. Lorsqu'une opportunité est gagnée et mise à jour dans l'organisation source, les données de l'opportunité sont synchronisées vers Data 360, où elles peuvent être répliquées dans d'autres systèmes, y compris dans des organisations Salesforce, en utilisant différents mécanismes tels que des actions, des activations et des API. De la même façon, une opportunité peut être référencée sans répliquer les données dans d'autres organisations Salesforce en utilisant Data Cloud One. Cependant, Data Cloud One ne prend pas en charge les plates-formes non-Salesforce.

### Outils pro-code pour les intégrations sortantes depuis Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guide</th>
            <th>Licence</th>
            <th>Calendrier</th>
            <th>Volume et échelle</th>
            <th></th>
            <th>Livraison et maintenance</th>
            <th></th>
            <th></th>
            <th>Confidentialité et sécurité</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quand utiliser</strong></th>
            <th><strong>Licence supplémentaire</strong></th>
            <th><strong>Synchronisation (demande/réponse) ou asynchrone (émission/oubli)</strong></th>
            <th><strong>Prise en charge multi-objets</strong></th>
            <th><strong>LDV/En masse</strong></th>
            <th><strong>Test et déploiement**</strong></th>
            <th><strong>Débogage</strong></th>
            <th><strong>Gestion intégrée des erreurs et comportement de réessai</strong></th>
            <th><strong>Peut être utilisé avec des données chiffrées au repos</strong></th>
            <th><strong>Protocole d'authentification</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex personnalisé</strong></td>
            <td>Lorsque vous avez besoin de fonctionnalités supérieures à celles disponibles dans les outils à faible code.</td>
            <td>Non requis</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui*</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>Services externes</strong></td>
            <td>L'intégration à partir de code avec des API système externes est décrite en utilisant les spécifications OpenAPI.</td>
            <td>Non requis</td>
            <td>Synchronisation</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td>S.O.</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Lorsque vous avez besoin d'une solution unique unifiée de niveau entreprise pour élaborer, orchestrer et gérer vos intégrations, lorsque vous devez remplacer une architecture point à point héritée ou lorsque vous avez besoin d'un support de gestion d'API.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui*</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\*L'activation de Shield Platform Encryption modifie certains comportements, voir [Considérations générales sur Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) pour plus de détails.

\*\* Test et déploiement désigne la possibilité d'élaborer dans un environnement inférieur et de déployer via l'[API de métadonnées](https://developer.salesforce.com/docs/metadata-coverage/), des packages ou des ensembles de modifications en production.

### Cas d'utilisation : Intégration sortante en utilisant des outils pro-code

> Lorsque des opportunités sont gagnées, une commande pour les produits associés doit être créée dans le système ERP ou de gestion des commandes de l'entreprise.

**Apex personnalisé** Vous pouvez créer un déclencheur Apex et un ou plusieurs gestionnaires de déclencheur dans l'opportunité qui passent un appel au système ERP ou de gestion des commandes lorsque l'étape de l'opportunité change en «Gagné». Notez que si vous passez des appels externes à partir d'un déclencheur ou après avoir exécuté une opération DML, vous devez utiliser une méthode annotée comme future ou pouvant être mise en file d'attente. Un appel externe dans un déclencheur maintient la connexion à la base de données ouverte pendant la durée de vie de l'appel externe. Tout code Apex est soumis aux [limites Apex Governor et API](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm), qui sont régulièrement révisées.

**Services externes** Si le système ERP externe ou de gestion des commandes de l'entreprise est défini via une spécification OpenAPI, les appels externes aux services exécutés dans la future méthode ou tâche en file d'attente peuvent être simplifiés. Les services externes enregistrés peuvent être appelés directement depuis Apex sans avoir besoin d'écrire un code standard. Dans l'exemple, l'appel externe pour créer la commande peut être géré par le service externe.

**MuleSoft Anypoint** MuleSoft Anypoint fournit une gestion d'API de niveau entreprise. MuleSoft Anypoint peut créer des API pour activer l'accès en lecture (et/ou en écriture) aux données pour Salesforce et de nombreux autres systèmes d'entreprise. De [nombreux connecteurs prédéfinis](https://www.mulesoft.com/platform/cloud-connectors) simplifient l'implémentation, et les entreprises peuvent également créer et publier leurs propres connecteurs. Ces API peuvent être déployées dans Anypoint avec des stratégies de sécurité flexibles, qui prennent en charge la gestion et la gouvernance centralisées. Le volume de transactions n'est soumis à aucune restriction, à condition que l'API ait été correctement dimensionnée pour son utilisation maximale (mesurée en vCores).

## Données système externes vers Salesforce (intégration entrante)

Pour les intégrations entrantes à Salesforce, vous pouvez envisager différents types d'outils : low-code, pro-code ou hybride. Les sections suivantes fournissent des conseils pour chaque type d'outil et offrent des exemples de solutions.

- [Outils low-code pour les intégrations entrantes](#outils-low-code-pour-les-intégrations-entrantes-à-salesforce)
- [Outils hybrides pour les intégrations entrantes](#outils-hybrides-pour-les-intégrations-entrantes-à-salesforce)
- [Outils pro-code pour les intégrations entrantes](#outils-pro-code-pour-les-intégrations-entrantes-à-salesforce)

### Outils low-code pour les intégrations entrantes à Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guide</th>
            <th>Licence</th>
            <th>Calendrier</th>
            <th>Volume et échelle</th>
            <th></th>
            <th>Livraison et maintenance</th>
            <th></th>
            <th></th>
            <th>Confidentialité et sécurité</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quand utiliser</th>
            <th>Licence supplémentaire</th>
            <th>Synchronisation (demande/réponse) ou asynchrone (déclenchement/oubli)</th>
            <th>Prise en charge multi-objets</th>
            <th>LDV/En masse</th>
            <th>Test et déploiement*</th>
            <th>Débogage</th>
            <th>Gestion intégrée des erreurs et comportement de réessai</th>
            <th>Peut être utilisé avec des données cryptées au repos</th>
            <th>Protocole d'authentification</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Lorsque vous souhaitez étendre vos données avec la synchronisation bidirectionnelle pour activer les applications mobiles et autres dans Heroku, et que vous souhaitez également répliquer les données dans Salesforce.</td>
            <td>Obligatoire</td>
            <td>Asynchrone</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui, via Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procédure d'intégration OmniStudio</strong></td>
            <td>Lorsque vous devez importer et transformer des données à partir de sources tierces sans interaction de l'utilisateur.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Prise en charge déclarative</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Identifiants nommés</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objets externes</strong></td>
            <td>Lorsque vous souhaitez afficher des données dans l'interface utilisateur de Salesforce, mais que vous souhaitez que les données soient stockées dans un système externe qui peut utiliser des protocoles standard comme Odata ou GraphQL.</td>
            <td>Obligatoire</td>
            <td>Synchronisation</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td>S.O.</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\* Test et déploiement désigne la possibilité d'élaborer dans un environnement inférieur et de déployer via l'[API de métadonnées](https://developer.salesforce.com/docs/metadata-coverage/), des packages ou des ensembles de modifications en production.

### Cas d'utilisation : Intégration entrante en utilisant des outils low-code

> Un contact est mis à jour dans le système ERP de l'organisation. Les informations de contact doivent être mises à jour dans Salesforce.

**Heroku Connect** Heroku Connect est généralement utilisé pour synchroniser une base de données Heroku Postgres et Salesforce. Si le système ERP n'utilise pas Heroku Postgres comme magasin de transactions, ce cas d'utilisation n'est pas possible. S'il utilise Heroku Postgres, les modifications apportées aux tableaux Postgres peuvent être synchronisées avec des objets Salesforce en utilisant Heroku Connect.

**Procédure d'intégration** OmniStudio Lorsque le système ERP a mis à jour l'enregistrement du contact, une procédure d'intégration OmniStudio avec une action de chargement de Data Mapper et une action de réponse peut être appelée via l'API REST générée par Data Mapper. Pour commencer, une action Chargement du mappeur de données envoie une charge utile JSON ou XML, qui est utilisée pour mettre à jour/insérer les enregistrements de contact en fonction d'un champ ID externe ou via une [clé Mettre à](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio) jour/insérer. Si une simple réponse en JSON suffit, une Action de réponse peut renvoyer toutes les informations pertinentes des actions précédentes pour indiquer la réussite ou l'échec. Si le système ERP attend une réponse spécifique, une Transformation Data Mapper ou une Action d'extraction peut être utilisée pour générer une réponse JSON ou XML avec des fonctionnalités supplémentaires pour inclure par déclaration les données générées dans les déclencheurs par la mise à jour de l'enregistrement de contact. Le principal défi de ce scénario est la concurrence : Plusieurs appels pour mettre à jour simultanément le même enregistrement de contact entraînent des problèmes, car l'API existe directement dans Salesforce.

**Salesforce Connect / Objets externes** Salesforce Connect et les objets externes ne sont pas recommandés pour ce cas d'utilisation, car le scénario nécessite spécifiquement la réplication des données dans Salesforce. Si vous avez une intégration Salesforce Connect préexistante élaborée à l'ERP, vous pouvez configurer le connecteur OData 4.0 pour prendre en charge la capture des données de modification externes si l'ERP peut prendre en charge la capture des données de modification. De plus, vous devez configurer dans Salesforce pour vous abonner au flux de modification depuis l'ERP, en utilisant l'API Pub/Sub.

### Outils hybrides pour les intégrations entrantes à Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guide</th>
            <th>Licence</th>
            <th>Calendrier</th>
            <th>Volume et échelle</th>
            <th></th>
            <th>Livraison et maintenance</th>
            <th></th>
            <th></th>
            <th>Confidentialité et sécurité</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quand utiliser</th>
            <th>Licence supplémentaire</th>
            <th>Synchronisation (demande/réponse) ou asynchrone (déclenchement/oubli)</th>
            <th>Prise en charge multi-objets</th>
            <th>LDV/En masse</th>
            <th>Test et déploiement**</th>
            <th>Débogage</th>
            <th>Gestion intégrée des erreurs et comportement de réessai</th>
            <th>Peut être utilisé avec des données cryptées au repos</th>
            <th>Protocole d'authentification</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Événements de plate-forme</strong></td>
            <td>Lorsque vous avez besoin d'une charge de travail structurée et définie sur mesure pour des modifications en temps quasi réel dans Salesforce ou un système externe.</td>
            <td>Non requis*</td>
            <td>Asynchrone</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objets externes (avec adaptateurs Apex personnalisés)</strong></td>
            <td>Lorsque vous souhaitez afficher des données dans l'interface utilisateur de Salesforce, mais que les données sont stockées dans un système externe qui ne peut pas utiliser les protocoles Odata 2.0/4.0.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td>S.O.</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>Lorsque vous souhaitez harmoniser les données de différentes sources dans un magasin de données, ou répliquer vos données d'autres organisations Salesforce ou d'autres systèmes externes. Data 360 prend également en charge la virtualisation pour certaines plates-formes.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\*[Complément](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) requis pour les cas d'utilisation à haut volume.

\*\* Test et déploiement désigne la possibilité d'élaborer dans un environnement inférieur et de déployer via l'[API de métadonnées](https://developer.salesforce.com/docs/metadata-coverage/), des packages ou des ensembles de modifications en production.

### Cas d'utilisation : Intégration entrante en utilisant des outils hybrides

> Un contact est mis à jour dans le système ERP de l'organisation. Les informations de contact doivent être mises à jour dans Salesforce.

**Événements de plate-forme** Un code personnalisé dans un système externe publie un Événement de plate-forme lorsque l'enregistrement du contact est mis à jour dans le système ERP. Un déclencheur, un processus ou un flux dans Salesforce peut s'abonner à l'événement de plate-forme et mettre à jour le ou les objets Salesforce correspondants lorsqu'un événement est traité. L'événement de plate-forme peut fonctionner simplement comme un signal indiquant qu'une modification s'est produite dans le système ERP du client sans contenir de données, ou contenir les données réelles nécessaires pour mettre à jour l'objet Salesforce.

**Salesforce Connect/Objets externes (avec adaptateurs Apex personnalisés)** Cette solution n'est pas applicable dans un cas d'utilisation qui nécessite une réplication des données. Cette solution est applicable si vous avez besoin d'utilisateurs dans Salesforce pour afficher les informations d'un système externe qui ne doit pas ou ne peut pas être répliqué dans Salesforce, et le système externe ne peut pas prendre en charge les protocoles standard comme Odata ou GraphQL. Consultez [Cas d'utilisation : Intégration sortante en utilisant des outils hybrides](#cas-dutilisation--intégration-sortante-en-utilisant-des-outils-hybrides) comme exemple de cas d'utilisation d'un adaptateur personnalisé Apex

**Data 360** Lorsqu'un contact est mis à jour dans des systèmes externes tels que ERP, les mises à jour de contact peuvent être synchronisées vers Data 360 en utilisant des connecteurs prêts à l'emploi ou en utilisant des API et des outils pro-code tels que MuleSoft. Le contact peut également être référencé dans Data 360 en utilisant le mécanisme de copie zéro (disponible sur certaines plates-formes). Une fois les données disponibles dans Data 360, différents mécanismes d'intégration prêts à l'emploi peuvent être utilisés pour synchroniser les données avec d'autres organisations Salesforce. Les données sont accessibles par référence en utilisant Data Cloud One. Les données peuvent également être répliquées en utilisant des activations et d'autres API en utilisant des connecteurs prêts à l'emploi ou avec l'aide d'outils pro-code tels que MuleSoft Anypoint Platform.

### Outils pro-code pour les intégrations entrantes à Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guide</th>
            <th>Licence</th>
            <th>Calendrier</th>
            <th>Volume et échelle</th>
            <th></th>
            <th>Livraison et maintenance</th>
            <th></th>
            <th></th>
            <th>Confidentialité et sécurité</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quand utiliser</th>
            <th>Licence supplémentaire</th>
            <th>Synchronisation (demande/réponse) ou asynchrone (exécution sans attente de réponse)</th>
            <th>Prise en charge multi-objets</th>
            <th>LDV/En masse</th>
            <th>Test et déploiement****</th>
            <th>Débogage</th>
            <th>Gestion intégrée des erreurs et comportement de réessai</th>
            <th>Peut être utilisé avec des données cryptées au repos</th>
            <th>Protocole d'authentification</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Services Web Apex REST &amp; SOAP personnalisés</strong></td>
            <td>Lorsque vous avez besoin de fonctionnalités supplémentaires que celles fournies par les points de terminaison d'API natifs, par exemple le traitement inter-objets ou d'autres logiques complexes.</td>
            <td>Non requis</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui***</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Lorsque vous avez besoin d'une solution unique unifiée de niveau entreprise pour élaborer, orchestrer et gérer vos intégrations, lorsque vous devez remplacer une architecture point à point héritée ou lorsque vous avez besoin d'un support de gestion d'API.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui***</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>APIs natives de Salesforce</strong></td>
            <td>Lorsque vous avez besoin de davantage de contrôle ou si vous avez un ensemble de compétences pro-code pour élaborer des intégrations via l'API REST, l'API SOAP, l'API de transfert en masse, ou les API GraphQL, ou gRPC.</td>
            <td>Non requis*</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui*****</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui**</td>
            <td class="guide-table-ok">Oui***</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\*[Limites et allocations de requêtes d'API](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm) s'appliquent.

\*\*Les API de transfert en masse ont des aspects de comportement de nouvelle tentative et un certain nombre d'API offrent une protection _contre l'annulation_ via le paramètre allOrNone (par exemple, consultez [Paramètres allOrNone dans Requêtes](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm) composées et Collections)

\*\*\*L'activation de Shield Platform Encryption modifie certains comportements ; voir [Considérations générales sur Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) pour plus de détails.

\*\*\*\*Test et déploiement désigne la possibilité d'élaborer dans un environnement inférieur et de déployer via l'[API de métadonnées](https://developer.salesforce.com/docs/metadata-coverage/), des packages ou des ensembles de modifications en production.

\*\*\*\*\*Les API composées ont la prise en charge multi-objets.

### Cas d'utilisation : Intégration entrante en utilisant les outils pro-code

> Un contact est mis à jour dans le système ERP de l'organisation. Ces coordonnées doivent être mises à jour dans Salesforce.

**Services Web Apex REST et SOAP** personnalisés Vous pouvez créer un service Web en utilisant un code Apex qui pourrait exécuter des opérations CRUD (créer, lire, mettre à jour, supprimer) sur l'objet Contact. Ce service sera invoqué via SOAP ou REST depuis le système externe (l'ERP).

**MuleSoft Anypoint** L'intention de MuleSoft Anypoint est de fournir une gestion d'API de niveau entreprise. MuleSoft Anypoint offre un [grand nombre de connecteurs](https://www.mulesoft.com/platform/cloud-connectors) prédéfinis que vous pouvez utiliser pour intégrer à de nombreux systèmes ERP, notamment SAP, Oracle EBS, Oracle ERP et NetSuite. Vous pouvez créer un flux pour écouter les événements dans ces systèmes ERP (dans le cas présent, lors de la création d'un contact). Lorsque le flux est démarré, il utilise le connecteur Salesforce pour créer un enregistrement Contact (ou le mettre à jour si le contact existe déjà). En outre, il est possible d'intégrer à d'autres systèmes si la transaction de réplication implique la syndication du contact dans d'autres systèmes. Si nécessaire, vous pouvez utiliser le langage de mappage et de transformation (DataWeave) pour exécuter une logique et des calculs complexes sous forme de flux d'informations à travers plusieurs systèmes disparates. L'authentification à ces systèmes peut être effectuée via de nombreux mécanismes d'authentification différents tels que l'authentification de base et OAuth, entre autres. Le volume de transactions n'est soumis à aucune restriction tant que le flux a été correctement dimensionné pour son utilisation maximale (mesurée en vCores).

**API Salesforce natives** Une fois la transaction de mise à jour terminée dans le système ERP, vous pouvez effectuer une opération de mise à jour/insertion sur l'objet Contact via l'API SOAP ou effectuer un [PATCH](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) sur l'API REST Contact sObjects dans l'organisation Salesforce.

## Intégrations Salesforce à Salesforce

Le produit Salesforce to Salesforce est arrivé en fin de vie. Salesforce to Salesforce a facilité la vente et le support de clients communs pour les partenaires qui travaillent ensemble, mais Salesforce investira dans l'innovation d'autres outils. À l'avenir, les approches suivantes sont recommandées pour le partage de données entre les organisations Salesforce.

### Outils d'intégration de données entre les organisations Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guide</th>
            <th>Coût</th>
            <th>Calendrier</th>
            <th>Volume et échelle</th>
            <th></th>
            <th></th>
            <th>Livraison et maintenance</th>
            <th></th>
            <th>Confidentialité et sécurité</th>
            <th></th>
            <th>Outils à implémenter</th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quand utiliser</strong></th>
            <th><strong>Licence supplémentaire</strong></th>
            <th><strong>Synchronisation (demande/réponse) ou asynchrone (déclenchement/oubli)</strong></th>
            <th><strong>Support multi-objets</strong></th>
            <th><strong>LDV/En masse</strong></th>
            <th><strong>Test et déploiement*</strong></th>
            <th><strong>Débogage</strong></th>
            <th><strong>Gestion intégrée des erreurs/comportement de réessai</strong></th>
            <th><strong>Peut être utilisé avec des données chiffrées au repos</strong></th>
            <th><strong>Protocole d'authentification</strong></th>
            <th><strong>Low Code → Pro Code</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Lorsque vous souhaitez étendre vos données avec la synchronisation bidirectionnelle entre les organisations Salesforce et également activer l'accès aux données à partir d'applications mobiles et autres exécutées sur Heroku</td>
            <td>Obligatoire</td>
            <td>Asynchrone</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Non</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui, via Shield Connect</td>
            <td>OAuth</td>
            <td>Code faible</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Lorsque vous avez besoin d'une solution unique unifiée de niveau entreprise pour élaborer, orchestrer et gérer vos intégrations, lorsque vous devez remplacer une architecture point à point héritée ou lorsque vous avez besoin d'un support de gestion d'API</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui**</td>
            <td>Multiple</td>
            <td>Code Pro</td>
        </tr>
        <tr>
            <td><strong>APIs natives de Salesforce</strong></td>
            <td>Lorsque Salesforce ou Heroku Connect ne sont pas une option ou si vous avez besoin d'un traitement plus complexe</td>
            <td>Non requis</td>
            <td>Les deux</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui**</td>
            <td>Multiple</td>
            <td>Code Pro</td>
        </tr>
        <tr>
            <td><strong>Capture des modifications de données</strong></td>
            <td>Lorsque vous devez publier des modifications au niveau de l'enregistrement effectuées dans Salesforce sur un système externe et que vous n'avez pas besoin d'une charge de travail personnalisée.</td>
            <td>Obligatoire</td>
            <td>Asynchrone</td>
            <td>Non</td>
            <td>Non</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>OAuth</td>
            <td></td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect avec un adaptateur inter-organisations</strong></td>
            <td>Lorsque vous souhaitez que les utilisateurs d'une organisation puissent afficher ou modifier des enregistrements dans une autre organisation sans réplication des données</td>
            <td>Obligatoire</td>
            <td>Asynchrone</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td>S.O.</td>
            <td>S.O.</td>
            <td>Multiple</td>
            <td>Code faible</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>Lorsque vous souhaitez que les utilisateurs d'une organisation affichent ou modifient des enregistrements dans une autre organisation avec des données répliquées dans Data 360.</td>
            <td>Obligatoire</td>
            <td>Les deux</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Avec des outils pro-code</td>
            <td class="guide-table-ok">Oui</td>
            <td class="guide-table-ok">Oui</td>
            <td>Multiple</td>
            <td>Hybride</td>
        </tr>
    </tbody>
</table>

\* Test et déploiement désigne la possibilité d'élaborer dans un environnement inférieur et de déployer via l'[API de métadonnées](https://developer.salesforce.com/docs/metadata-coverage/), des packages ou des ensembles de modifications en production

\*\*L'activation Shield Platform Encryption modifie certains comportements, voir [General Shield Platform Encryption Considérations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) pour plus de détails.

Les événements _de plate-forme ne sont pas optimaux pour intégrer des données d'une organisation Salesforce à une autre, car ils ne peuvent pas « écouter » entre les organisations pour le même événement. Apex personnalisé n'est pas non plus une approche recommandée pour ce type d'intégration._

### Cas d'utilisation : Connexion de plusieurs organisations Salesforce

> Une grande entreprise opère à travers plusieurs unités commerciales (BU). Chaque unité commerciale a sa propre organisation Salesforce. Un seul client traite avec plusieurs unités commerciales de l'entreprise et dispose ainsi de données de compte et d'opportunité dans plusieurs organisations. L'entreprise doit accéder à une vue agrégée de toutes les données de compte et d'opportunité dans toutes les unités commerciales, le tout dans une seule organisation.

_Note : Toutes les solutions ci-dessous sont conçues pour réduire au maximum la réplication des données, conformément à [la recommandation n° 1](#points-à-retenir)._

**Data 360** Les données de comptes et d'opportunités de différentes organisations Salesforce peuvent être ingérées dans Data 360 en utilisant des connecteurs Salesforce prêts à l'emploi. Ils peuvent également être agrégés et harmonisés (si nécessaire). Une fois les données agrégées dans Data 360, elles sont accessibles dans d'autres organisations Salesforce en utilisant Data Cloud One sans réplication des données.

**Heroku Connect** Pour chaque organisation commerciale, vous pouvez utiliser Heroku Connect afin de synchroniser les modifications depuis Salesforce vers une base de données Heroku Postgres unique. Dans ce scénario, la synchronisation bidirectionnelle n'est pas activée, mais uniquement depuis Salesforce vers Postgres. Ensuite, dans Heroku Connect, vous pouvez activer le fournisseur OData et sélectionner les tableaux que vous souhaitez exposer en tant qu'objets externes dans l'organisation Salesforce où vous souhaitez une vue agrégée. Depuis Salesforce, vous définissez une source de données externe pointant vers le fournisseur Odata dans Heroku.

**MuleSoft Anypoint** MuleSoft Anypoint fournit une gestion d'API de niveau entreprise. Une API MuleSoft Anypoint peut être configurée pour lire les informations de plusieurs organisations Salesforce associées en utilisant le connecteur Salesforce avec plusieurs connexions aux organisations. Le flux MuleSoft peut interroger les différentes organisations Salesforce et renvoyer une structure spécifique améliorée ou enrichie avec d'autres informations tierces si nécessaire. Lorsque l'API est invoquée, elle effectue tous les appels externes appropriés à l'organisation Salesforce (dans cet exemple, elle interroge les informations sur les comptes et les opportunités) afin de permettre au consommateur de traiter les données (probablement une interface utilisateur). L'authentification à ces systèmes peut être effectuée via divers mécanismes d'authentification, notamment l'authentification de base et OAuth. Le volume de transactions n'est soumis à aucune restriction, à condition que le flux ait été correctement dimensionné pour son utilisation maximale (mesurée en vCores ou Cores).

**API Salesforce natives** Des opérations de requête peuvent être émises pour chaque organisation d'intérêt, notamment via l'API de transfert en masse Salesforce 2.0, qui est bien adaptée pour extraire efficacement des milliers d'enregistrements. Vous pouvez récupérer les résultats de requête de chaque organisation individuellement et les agréger avec une application personnalisée ou un middleware selon les besoins du client.

**Salesforce Connect avec adaptateur inter-organisations** L'adaptateur inter-organisations Salesforce Connect ne convient pas très bien dans ce scénario, car les comptes ou les opportunités d'organisations distantes apparaîtront tous dans l'organisation centrale sous forme d'objets _différents_. Par exemple, il n'est pas possible d'additionner le total général des montants de toutes les opportunités dans toutes les organisations.

**Scénario inter-organisations : Mises à jour sélectives** Un commercial qui utilise l'organisation Salesforce A doit afficher et mettre à jour les données des requêtes de l'organisation Salesforce B et ajouter des commentaires à la requête parente dans l'organisation Salesforce B en travaillant dans l'organisation A. Les données ne doivent pas être répliquées à l'organisation A.

**Heroku Connect** Vous pouvez utiliser la même approche décrite dans le _scénario d'agrégation_ de données ci-dessus. Vous devez toutefois activer CRUD sur l'objet externe via le connecteur Odata et réécrire les modifications dans Heroku Postgres.

**MuleSoft Anypoint** MuleSoft Anypoint fournit une gestion d'API de niveau entreprise. Vous pouvez utiliser la même approche décrite dans le _Scénario d’agrégation de données_ ci-dessus.

Les **API Salesforce natives** utilisent des identifiants nommés et invoquent les API Salesforce natives pour lire et mettre à jour les données dans l'organisation Salesforce associée. Un composant doit être conçu pour afficher les données.

**Salesforce Connect with Cross-Org Adapter** L ' [adaptateur Salesforce cross-Org](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5) permet d ' afficher les données d ' un objet externe (et de les modifier si CRUD est activé dans l ' objet externe). Les relations sont également prises en charge entre les objets externes. Par conséquent, vous pouvez lier à la requête parente dans l'objet externe. Cependant, la création de relations est aujourd'hui un processus manuel dans lequel vous convertissez un type de données existant en type de données de relation. De plus, les optimisations effectuées dans Service Cloud pour travailler plus efficacement avec les requêtes ne sont pas transmises en cascade à l'organisation distante. Salesforce recommande vivement de tester l'adaptateur inter-organisations et d'évaluer les compromis entre l'utilisation d'objets externes et d'objets standard pour votre cas d'utilisation.

**Synchronisation des données inter-organisations**: Lorsqu'un compte d'un client est mis à jour dans l'une des organisations Salesforce de l'unité commerciale de l'organisation, les autres objets Compte de l'organisation Salesforce doivent être mis à jour pour conserver des informations cohérentes sur le compte.

**Data 360** Data 360 peut être utilisé pour la réplication de données d'une organisation à une autre Salesforce. Les données de compte d'une organisation Salesforce peuvent être ingérées dans Data 360 en utilisant des connecteurs Salesforce prêts à l'emploi. Nous pouvons également utiliser des mécanismes d'activation de données tels que l'activation par lot, des actions de données en temps quasi réel ou des activations basées sur l'API pour déplacer les données depuis Data 360 vers l'organisation Salesforce.

**Heroku Connect** Vous pouvez utiliser la même approche décrite dans le _scénario d'agrégation_ de données ci-dessus. Cependant, vous devez activer la synchronisation bidirectionnelle, et il n'est plus nécessaire d'activer Salesforce Connect car la synchronisation bidirectionnelle tiendra toutes les organisations à jour lorsque des modifications seront apportées au tableau Postgres.

**MuleSoft Anypoint** MuleSoft Anypoint fournit une gestion d'API de niveau entreprise. Vous pouvez [configurer une application](https://docs.mulesoft.com/design-center/about-designing-a-mule-application) Mule avec Flow Designer dans MuleSoft Anypoint afin d'écouter les événements d'objet standard et personnalisé qui déclenchent un flux lancé automatiquement dans Salesforce. Lorsque l'application Mule est déclenchée, elle peut invoquer le connecteur Anypoint pour Salesforce afin de communiquer avec n'importe quelle organisation Salesforce. Dans ce cas d'utilisation, lorsqu'un enregistrement Compte est mis à jour dans une organisation Salesforce, l'application Mule peut mettre à jour les enregistrements Compte dans les organisations Salesforce associées. Chaque organisation Salesforce associée aurait une étape de mise à jour unique intégrée au flux d'application global dans MuleSoft. L'authentification à ces systèmes peut être effectuée via divers mécanismes d'authentification, notamment l'authentification de base et OAuth. Le volume de transactions n'est soumis à aucune restriction tant que le flux a été correctement dimensionné pour son utilisation maximale (mesurée en vCores ou Cores).

**API Salesforce natives** L'[API Replication](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (opérations getUpdated, getDeleted) peut être utilisée pour synchroniser les données entre les organisations, mais cette approche n'est pas recommandée.

**Salesforce Connect avec adaptateur inter-organisations** Vous pouvez utiliser des flux déclenchés par un enregistrement et des objets externes pour garder certaines données synchronisées entre les organisations Salesforce. Par exemple, la mise à jour d'un enregistrement de compte dans l'organisation A déclenche un flux qui met ensuite à jour l'enregistrement correspondant dans l'objet externe Compte, ce qui écrit ces mises à jour dans l'enregistrement de compte dans l'organisation B. Cela nécessite l'utilisation correcte de la sémantique de flux pour éviter les [transactions DML mixtes](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1). Notez également que les règles de validation et les flux dans l'organisation B sont déclenchés de la même façon que lorsque des modifications sont effectuées par nos API REST/SOAP.

## Remarques finales

Tenez compte de ce guide et consultez-le lorsque vous planifiez une nouvelle intégration de données impliquant Salesforce. Il est toujours recommandé de comprendre l'éventail complet des options qui s'offrent à vous et leur adéquation à votre cas d'utilisation spécifique.

### Dites-nous ce que vous pensez

Aidez-nous à publier les informations les plus pertinentes pour vous. [Répondez à notre sondage](https://sfdc.co/J0cWb) pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous aimeriez voir ensuite.

<!-- document id=965d98812e87d31d0bdcfbd8d37041c407a1fafee2be1751c78a89f182e67c9a url=/architect/current/fr-fr/decision-guides/guides/data-360-interoperability.md -->

# Interopérabilité de Data 360

Les entreprises stockent souvent des données dans Salesforce et d'autres lacs de données externes (par exemple, _Snowflake_, _Google BigQuery_, _Databricks_, _Redshift_ ou le stockage d'objets tel que _Amazon S3_). Le cloisonnement des données à travers plusieurs systèmes crée un défi pour les entreprises qui souhaitent exploiter toute la valeur de leurs données afin d’optimiser les expériences pilotées par l’IA. Salesforce _Data 360_ est la couche d'intelligence fondamentale que chaque agent IA Agentforce utilise pour accéder au contexte approprié au moment opportun.

Les architectes qui travaillent pour regrouper des données à travers plusieurs lacs de données doivent prendre des décisions architecturales importantes sur la meilleure façon d'intégrer ces données. _Data 360_ fournit plusieurs options d'intégration de données, chacune offrant divers avantages et inconvénients.

## Présentation du guide

Ce guide fournit un cadre qui permet d'évaluer le modèle le plus adapté à vos exigences en matière de latence, de coût, d'évolutivité, de gouvernance et de complexité lors de l'intégration de données, en vous aidant à choisir quand utiliser l'ingestion de données, la fédération de données Zero Copy ou une approche hybride. Le guide vous aidera également à sélectionner entre différentes méthodes d'ingestion de données et de fédération de données, chacune répondant à un besoin différent.

L'intégration de maisons de lac de données externes à _Data 360_ nécessite d'examiner attentivement les compromis entre l'actualisation des données, la gouvernance et l'efficacité du pipeline. Par exemple, l'utilisation de requêtes live de fédération de données Zero Copy optimise l'actualisation des données, mais peut réduire l'efficacité du pipeline à mesure que de nouvelles données circulent sur le réseau. Pour la plupart des implémentations réelles, la combinaison de l'ingestion et de la fédération dans un écosystème de maison de lac multi-cloud est la voie optimale. Cette approche hybride garantit une architecture évolutive, régie et interopérable qui prend en charge les charges de travail opérationnelles à faible latence (par exemple, la personnalisation en temps réel et la détection des fraudes) et analytiques (par exemple, les rapports réglementaires et l'analyse des tendances historiques). Ce guide vous aide à déterminer comment naviguer ces compromis en utilisant une stratégie appropriée.

## Principaux points à retenir

- **L'ingestion de données** copie les données dans Salesforce _Data 360_ et crée des modèles de données gouvernés et canoniques. C'est idéal lorsque vous devez :
  - **Élaborez un Customer 360 complet** qui permet d'unifier et de transformer des sources différentes en un profil unique et fiable.
  - **Satisfaire à la conformité réglementaire stricte.** Vous pouvez ainsi créer une copie auditable et centralisée afin de contrôler étroitement l'accès aux données et le lignage.
- **Zero Copy Federation** interroge les sources externes en temps réel sans duplication, ce qui permet la personnalisation en temps réel, des tableaux de bord live et une intégration rapide des sources. Cette approche offre deux options principales, mais il y a des compromis qui doivent être équilibrés&nbsp;:
  - **Live Query&nbsp;:** Utilisez-le pour des analyses interactives et des tableaux de bord de données en temps réel qui vivent sur des plates-formes de données externes (par exemple, _Snowflake_, _BigQuery_, _Redshift_ ou _Databricks_). Cela permet d'éviter les duplications de données lentes et coûteuses en envoyant automatiquement le traitement des requêtes au système source et en renvoyant uniquement les résultats nécessaires. Cette approche est optimisée pour les requêtes peu fréquentes ou ponctuelles dans lesquelles la fraîcheur est essentielle. Il est adapté aux charges de travail à faibles _requêtes par seconde (QPS)_&nbsp; (les coûts de requête peuvent augmenter considérablement lorsque le QPS est élevé).
  - **Mise en cache (requête accélérée)&nbsp;:** Utilisez-le pour les requêtes de données fréquentes qui ne changent pas souvent. Les requêtes accélérées conservent un cache local qui est mis à jour à intervalles configurables (15 minutes à 7 jours), ce qui réduit les accès sources répétés. Cette approche équilibre les performances et les coûts des tableaux de bord, la segmentation et les charges de travail BI lorsque des résultats légèrement obsolètes sont acceptables. Ce n'est pas adapté à la prise de décision en moins d'une seconde.
  - **Fédération de fichiers&nbsp;:** Utilisez-le pour le traitement par lot à grande échelle et l'entraînement au modèle IA des données du lac de données de votre cloud (par exemple, _S3_ ou _ADLS_). Cette approche évite l'ingestion lente et coûteuse en interrogeant directement les fichiers sous des formats de tableau ouvert, ce qui déverrouille les jeux de données ETL massifs et les charges de travail de science des données.
- Les **modèles hybrides** combinent l'ingestion pour les _profils unifiés_ et la fédération pour la fraîcheur, qui prend en charge l'engagement multicanal, les actions pilotées par Agentforce et la formation IA/ML.

### Considérations importantes

- **Employez une architecture hybride.** La combinaison de l'ingestion et de la fédération des données est souvent nécessaire.
  - Utilisez _l'Ingestion de données_ sur des données critiques pour des modèles de données canoniques et la gouvernance de base.
  - Utilisez _Zero Copy_ pour toutes les autres fédérations de données afin de préserver l'actualité et de réduire les coûts opérationnels liés à l'élaboration et à la maintenance de pipelines d'ingestion de données.
- **La fréquence d'ingestion de données compte.** Choisissez la fréquence en fonction de la valeur métier, des besoins en latence et de la complexité opérationnelle.
  - Utilisez le _temps réel_ pour les workflows urgents (par exemple, personnalisation, tableaux de bord live et actions Agentforce).
  - Utilisez le _temps quasi réel_ pour des processus modérément urgents (par exemple, campagnes et rapports opérationnels).
  - Utilisez le traitement par lot pour des jeux de données historiques ou à faible vitesse.
- **Associez les modèles de fédération aux exigences de latence et de performance.** Choisissez l'option la plus adaptée à vos modèles d'accès et exigences en matière de fraîcheur, de performance et de coût.
  - Utilisez _Live Query_ pour les tableaux de bord opérationnels et la personnalisation en temps réel lorsque la faible latence est critique.
  - Utilisez la _mise en cache (requête accélérée)_ lorsque les requêtes sont fréquentes et que les résultats légèrement périmés sont acceptables, ce qui permet d'équilibrer les performances et les coûts.
  - Utiliser _la Fédération de fichiers_ pour des analytiques ou des charges de travail par lot à grande échelle et lourdes en débit, ce qui est idéal pour des jeux de données historiques ou moins urgents.
- **Alignez la gouvernance sur les exigences de résidence des données.**
  - Utilisez l'_ingestion_ lorsque la gouvernance centralisée est essentielle.
  - Utiliser la _fédération_ lorsque la gouvernance décentralisée est acceptable, tout en appliquant une gouvernance stricte à la source externe.
  - Utilisez _Zero Copy_ en ce qui concerne les stratégies au niveau source (par exemple, _sécurité au niveau ligne_ et masquage des données).
- **Donnez la priorité à l'ingestion pour les workflows à forte valeur ajoutée.** Appliquez l'ingestion de façon sélective à des processus critiques (par exemple, résolution de l'identité, rapports réglementaires et activation opérationnelle).
- **Le coût et la complexité déterminent les décisions.** L'ingestion en temps réel peut être coûteuse et complexe. Par conséquent, il est important pour les architectes de comparer le coût d'intégration, de stockage et de transformation des données au coût d'interrogation directe via _Zero Copy_.

Le choix du modèle d'intégration approprié (_Ingestion de données_, _Zéro copie_ ou approche _hybride_) impacte directement la latence, la gouvernance, l'efficacité opérationnelle et le coût sur les plates-formes multicloud. Cette décision détermine comment les connaissances en temps réel, l'activation pilotée par l'IA et l'engagement personnalisé sont fournis de façon fiable et à grande échelle.

## Comparaison des produits

Le tableau ci-dessous compare les modèles _Ingestion de données_ et _Zéro copie_ dans Salesforce _Data 360_, en se concentrant sur les capacités, les compromis et les avantages, ainsi que sur les cas d'utilisation et les résultats de l'entreprise. Utilisez-le comme référence pour concevoir des plates-formes de données hybrides et multicloud qui concilient performance, coût et conformité.

<table>
  <thead>
    <tr>
      <th align="left" valign="top"><strong>Type de modèle</strong></th>
      <th align="left" valign="top"><strong>Mode/Outil</strong></th>
      <th align="left" valign="top"><strong>Prestations</strong></th>
      <th align="left" valign="top"><strong>Considérations</strong></th>
      <th align="left" valign="top"><strong>Résultats</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="left" valign="top"><strong>Ingestion de données</strong></td>
      <td align="left" valign="top">
        <strong>En temps réel :</strong>
        <ul>
          <li>Ingestion à latence inférieure à une seconde via des API d'ingestion prenant en charge le CDC.</li>
          <li>Pipelines en continu.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Fournit des informations immédiates.</li>
          <li>Prend en charge les cas d'utilisation opérationnels et de personnalisation à faible latence.</li>
          <li>Prend en charge les workflows pilotés par des événements.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Coût élevé</li>
          <li>Architecture complexe</li>
          <li>Exigences du système source à faible latence.</li>
          <li>Les sources à haut volume peuvent entraîner une diffusion excessive, ce qui entraîne la saturation des pipelines</li>
          <li>E/S intensives</li>
          <li>Les champs sélectifs et le filtrage peuvent aider à réduire les frais généraux</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce :</strong>
        <ul>
          <li>Alertes de fraude en temps réel, personnalisation de la vente au détail et alertes opérationnelles</li>
        </ul>
        <strong>Analytics&amp;nbsp;:</strong>
        <ul>
          <li>Tableaux de bord actualisés en moins d'une seconde et surveillance des indicateurs de performance clés.</li>
        </ul>
        <strong>Conformité&amp;nbsp;:</strong>
        <ul>
          <li>Mises à jour continues des enregistrements clients pour les workflows réglementés.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Streaming&amp;nbsp;:</strong>
        <ul>
          <li>Ingestion par microbatch toutes les 1 à 3 minutes via des connecteurs natifs</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Équilibre coût et fraîcheur</li>
          <li>Présente une architecture plus simple que celle du temps réel.</li>
          <li>Prend en charge les mises à jour incrémentielles</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Légère latence</li>
          <li>Peut ne pas convenir pour des décisions critiques en moins d'une seconde</li>
          <li>La taille du lot a un impact sur la mémoire et le calcul.</li>
          <li>Modérer les E/S</li>
          <li>Convient pour des modèles de mise à jour prévisibles et répétitifs</li>
          <li>L'agrégation fenêtrée peut aider à réduire la charge de traitement</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce :</strong>
        <ul>
          <li>Déclencheurs de campagne au moment opportun et engagement en direct.</li>
        </ul>
        <strong>Analytics&amp;nbsp;:</strong>
        <ul>
          <li>Moteurs de recommandation et tableaux de bord en direct</li>
        </ul>
        <strong>Conformité&amp;nbsp;:</strong>
        <ul>
          <li>Mises à jour fréquentes avec auditabilité</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Lot :</strong>
        <ul>
          <li>Fournit des chargements planifiés à grand volume via des connecteurs ou des API.</li>
          <li>Prend en charge le stockage d'objets et les pipelines ETL/ELT.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Permet d'optimiser les coûts pour les jeux de données massifs.</li>
          <li>Implémentation aisée.</li>
          <li>Assure une fiabilité pour les analyses historiques.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Latence des données</li>
          <li>Inadapté aux opérations sensibles au temps.</li>
          <li>E/S intensives pendant les fenêtres de chargement</li>
          <li>Le débit réseau peut devenir un goulot d'étranglement pour les fichiers volumineux</li>
          <li>Convient aux workflows d'agrégation historique ou de rapports réglementés.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce :</strong>
        <ul>
          <li>Tickets de support informatique (Jira/ServiceNow) et workflows agrégés.</li>
        </ul>
        <strong>Analytics&amp;nbsp;:</strong>
        <ul>
          <li>Analyse historique et évaluation des tendances</li>
        </ul>
        <strong>Conformité :</strong>
        <ul>
          <li>Rapports réglementaires et agrégation des données patients/réclamations.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"><strong>Zéro copie</strong></td>
      <td align="left" valign="top">
        <strong>Live Query&amp;nbsp;:</strong>
        <ul>
          <li>Fournit des requêtes directes sur des systèmes externes et un schéma en lecture seule sans duplication des données</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Fournit une fraîcheur maximale</li>
          <li>Offre une surcharge de stockage minimale.</li>
          <li>Prend en charge les informations opérationnelles en temps réel.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Selon les performances de la source</li>
          <li>Un volume de requête élevé peut affecter la latence</li>
          <li>Convient pour les requêtes avec pushdown de prédicats et agrégation afin de minimiser les E/S.</li>
          <li>Éviter d'utiliser des requêtes non filtrées dans des jeux de données massifs</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce :</strong>
        <ul>
          <li>Workflows dynamiques qui s'adaptent à l'activité en direct</li>
        </ul>
        <strong>Analytics :</strong>
        <ul>
          <li>Tableaux de bord opérationnels et rapports en direct</li>
        </ul>
        <strong>Conformité :</strong>
        <ul>
          <li>Respecte la sécurité au niveau de la ligne et le masquage à la source.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Requête accélérée (mise en cache)&amp;nbsp;:</strong>
        <ul>
          <li>Fournit des copies locales mises en cache pour les requêtes fédérées qui peuvent être configurées de 15 min à 7 jours.</li>
          <li>Fournit une exécution de requête optimisée</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Réduit la latence</li>
          <li>Coûte moins cher que les requêtes en direct répétitives</li>
          <li>Améliore les performances des modèles d'accès fréquents</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Gestion du cache requise</li>
          <li>L'immobilité dépend des intervalles de cache</li>
          <li>Convient aux requêtes à haute fréquence</li>
          <li>Ne convient pas à la prise de décision sub-seconde.</li>
          <li>L'actualisation incrémentielle prend en charge uniquement les mises à jour/insertions. Les enregistrements supprimés ne sont pas retirés du cache.</li>
          <li>Nécessite périodiquement une actualisation complète manuelle pour garder le cache synchronisé avec la source</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce :</strong>
        <ul>
          <li>Métriques d'engagement préagrégées pour une prise de décision rapide</li>
        </ul>
        <strong>Analytics :</strong>
        <ul>
          <li>Tableaux de bord BI, segmentation et rapports analytiques</li>
        </ul>
        <strong>Conformité :</strong>
        <ul>
          <li>Tableaux de bord réglementés de façon cohérente avec des journaux d'audit.</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Fédération de fichiers :</strong>
        <ul>
          <li>Permet d'accéder directement à des jeux de données historiques volumineux dans des magasins d'objets ou des lacs (par exemple, <em>S3</em>, <em>Iceberg</em>, <em>Google BigQuery</em> et <em>Redshift</em>).</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Traite les jeux de données à grande échelle.</li>
          <li>Nécessite un stockage minimal dans <em>Data 360</em></li>
          <li>Prend en charge les charges de travail IA/ML.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Lecture seule</li>
          <li>Les performances des requêtes dépendent du débit système externe</li>
          <li>Convient pour les tâches lourdes en lots et exigeantes en débit.</li>
          <li>Ne convient pas aux tableaux de bord en temps réel</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce :</strong>
        <ul>
          <li>Pas typique (traitement par lots intensif)</li>
        </ul>
        <strong>Analytics&amp;nbsp;:</strong>
        <ul>
          <li>Entraînement ML/IA, analytiques historiques et rapports à l'échelle du pétaoctet</li>
        </ul>
        <strong>Conformité&amp;nbsp;:</strong>
        <ul>
          <li>Gouverne l'accès aux jeux de données externes sans duplication</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Modèles d'intégration Data 360

Il existe trois principaux modèles d'intégration pour Data 360 : l'ingestion de données, la fédération de données zéro copie et une approche hybride.

### Ingestion de données

Avec l'_Ingestion de données_, les données sont physiquement copiées dans _Data 360_ et entièrement régies, contrairement à _Zero Copy_ où les données restent à la source. En d'autres termes, le calcul des transformations est effectué dans _Data 360_, qui fournit une gouvernance et un audit centralisés.

#### Cas d'utilisation d'ingestion de données

Utilisez l'_Ingestion de données_ pour stocker des jeux de données canoniques et gouvernés dans Salesforce _Data 360_ à des fins de conformité et de contrôle opérationnel. Utilisez l'ingestion lorsqu'un contrôle total, un audit et une traçabilité sont requis. L'ingestion de données est idéale pour les workflows réglementés ou à valeur élevée dans lesquels le calcul centralisé et la gouvernance sont essentiels.

L'ingestion est adaptée à l'élaboration d'une base de confiance pour la résolution de l'identité, les rapports réglementaires, et les workflows critiques pilotés par l'IA et l'engagement des clients.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360  Ingestion.png" alt="Vue d&apos;ensemble de l&apos;ingestion de données" />

#### Méthodes d'ingestion de données

Les méthodes d'_ingestion de données_ peuvent varier selon le connecteur que vous utilisez pour ingérer vos données. Certains connecteurs offrent diverses méthodes d'ingestion, tandis que d'autres fonctionnent uniquement en mode par lot ou streaming. Pour consulter la liste complète des connecteurs _Data 360_ et des méthodes disponibles, consultez [Data 360: Integrations and Connectors](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5).

- **En temps réel&nbsp;:**
  - Fournit une ingestion en moins d'une seconde à l'aide de la _Capture de données de modification (CDC)_
  - Convient aux workflows sensibles au temps (par exemple, détection de fraude, personnalisation et tableaux de bord opérationnels).
  - Fonctionne avec des transformations push et des agrégations dans _Data 360_, ce qui permet de réduire les entrées/sorties en aval et d'optimiser l'utilisation du calcul
  - Prend en charge l'utilisation du CDC incrémentiel pour minimiser le mélange de données
- **Streaming&nbsp;:**
  - Ingestion toutes les 1 à 3 minutes par petits incréments
  - Équilibre fraîcheur et coût
  - Convient pour l'orchestration de campagnes, l'engagement en direct et les rapports opérationnels
  - Prend en charge l'utilisation de microbatchs pour contrôler les pics d'E/S
  - Agrége les données à la source (si possible) pour réduire les volumes de transfert et optimiser le stockage
- **Lot (chargements planifiés)&nbsp;:**
  - Fournit une ingestion périodique de jeux de données volumineux (par exemple, horaire, quotidien et hebdomadaire)
  - Offre une rentabilité et une fiabilité pour les jeux de données historiques, les rapports réglementaires et les cas d'utilisation de conformité
  - Garantit que la localisation du calcul se situe dans la même région que le stockage source pour améliorer les performances et optimiser les coûts

#### Architect Playbook

- **Cas d'utilisation d'ingestion de données&nbsp;:**
  - **Générer des profils unifiés Customer 360.** Élaborer une source de vérité unique pour les identités et les attributs des clients.
  - **Maintenir les jeux de données de conformité réglementaire.** Appliquer la gouvernance, la filiation et l'auditabilité des données confidentielles.
  - **Centraliser l'orchestration des campagnes.** Assurer que le marketing, les ventes et le service fonctionnent tous à partir de jeux de données cohérents et fiables.
- **Pratiques de conception&nbsp;:**
  - Adaptez l'ingestion par lot aux besoins historiques ou tolérants à une faible latence (par exemple, rapports d'archives ou clichés instantanés périodiques).
  - Utilisez des API CDC ou streaming pour actualiser les workflows opérationnels et de personnalisation afin de garantir des mises à jour en temps quasi réel.
  - Contrôlez le stockage et calculez la croissance en appliquant des charges incrémentielles pour optimiser le coût et l'efficacité (au lieu de recharger des jeux de données complets).
  - Alignez les pipelines d'ingestion avec la localisation du calcul et le traitement incrémentiel afin de réduire les entrées/sorties réseau.
  - Appliquez des transformations dans _Data 360_ pour éviter de déplacer inutilement des données brutes.
- **Considérations relatives aux coûts&nbsp;:**
  - L ' **ingestion en temps** réel entraîne les coûts de calcul et de pipeline les plus élevés, ce qui peut se justifier pour des workflows importants et urgents (par exemple, personnalisation, tableaux de bord opérationnels ou actions pilotées par Agentforce).
  - **L'ingestion en continu** entraîne des coûts de calcul et de stockage modérés, qui peuvent convenir pour des mises à jour fréquentes tolérant de légers retards (par exemple, orchestration de campagne ou rapports opérationnels).
  - L'**ingestion par lot** offre des coûts de calcul réduits et un stockage prévisible, qui convient aux jeux de données historiques ou aux mises à jour à basse fréquence. L'ingestion de données par lot à partir d'organisations Salesforce en utilisant certains connecteurs est gratuite.
  - **Mode d'actualisation** Permet de sélectionner le mode d'_actualisation incrémentielle_, ce qui réduit les coûts totaux d'ingestion et de calcul. Chez Salesforce, nous recommandons d'utiliser l'_actualisation incrémentielle_ dans la mesure du possible afin d'optimiser l'efficacité dans tous les types d'ingestion.
  - **Le coût** est également impacté par le volume d'E/S depuis la source vers _Data 360_. L'optimisation de la taille des lots, des partitions et de l'alignement régional réduit les coûts de transfert et améliore les performances.
- **Scénarios de l'industrie&nbsp;:**
  - **Finance:** Les jeux de données d'ingestion sont requis pour _connaître votre client (KYC)_, _Anti Money Laundering (AML)_ et la détection des fraudes lorsque l'auditabilité et la conformité ne sont pas négociables.
  - **Santé&nbsp;:** Utilisez l'ingestion pour la résolution de l'identité des patients et les enregistrements conformes HIPAA, qui permettent des vues sécurisées et unifiées.
  - **Retail:** Consolidez les données des _points de vente_, du commerce électronique et du programme de fidélité dans des profils unifiés pour la segmentation et la personnalisation.
  - **Telecom:** Soutenez la prévention du churn et l'analyse de l'utilisation grâce à des données d'abonnés canoniques et gouvernées.

#### Critères de décision de la méthode d'ingestion de données

| Fonctionnalité                              | Ingestion en temps réel                                                                                                                                                                         | Ingestion en continu                                                                                                                                           | Ingestion par lot                                                                                                                                                                            |
| :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Latence et fraîcheur**            | Ingestion de latence inférieure à la seconde via des API Ingestion avec prise en charge de la _Capture des données_ modifiées. Fournit des pipelines en continu. Convient aux cas d'utilisation opérationnels à faible latence. | Ingestion par microbatch toutes les 1 à 3 minutes via des connecteurs natifs. Prend en charge les mises à jour incrémentielles. Une légère latence est attendue.                             | Une latence des données est attendue. Autorise les chargements planifiés à grand volume. Ingestion périodique (horaire, quotidienne et hebdomadaire). Ne convient pas aux opérations temporelles.                        |
| **Cas d'utilisation principaux**                | Idéal pour les cas d'utilisation opérationnels et de personnalisation à faible latence. Utilisé pour des workflows sensibles au temps. Prend en charge les workflows pilotés par l'événement. Utilisé pour les alertes de fraude et les alertes opérationnelles en temps réel.  | Convient aux processus modérément urgents. Utilisé pour l'orchestration de campagnes, l'engagement en direct et les rapports opérationnels. Utilisé pour déclencher des campagnes au moment opportun.  | Rentable pour des jeux de données massifs. Fiable pour les analytiques historiques. Utilisé pour les workflows d'agrégation historique ou de rapports réglementés. Convient aux jeux de données historiques ou à faible vitesse. |
| **Complexité architecturale et E/S** | Inclut un coût élevé et une architecture complexe. Nécessite des systèmes sources à faible latence. E/S intensives. Les sources à haut volume peuvent entraîner la saturation des pipelines.                                         | Présente une architecture plus simple que celle du temps réel. Le volume des E/S est modéré. Convient pour des modèles de mise à jour prévisibles et répétés. La taille du lot impacte la mémoire et le calcul. | Facile à implémenter. Des E/S intensives pendant les fenêtres de chargement. Le débit réseau peut devenir un goulot d'étranglement pour les lots volumineux.                                                                        |
| **Considérations relatives aux coûts**              | Inclut les coûts de calcul et de pipeline les plus élevés. Justifiable uniquement pour les workflows de grande valeur et sensibles au temps.                                                                                 | Inclut des coûts de calcul et de stockage modérés. Fournit une approche coût/fraîcheur équilibrée. Convient pour les mises à jour fréquentes qui peuvent tolérer de légers retards.   | Présente des coûts de calcul réduits et un stockage prévisible. Recommandé pour les jeux de données historiques ou les mises à jour à basse fréquence. L'ingestion via des pipelines internes Salesforce est gratuite.                   |
| **Pratiques de conception**                 | Utilisez le CDC incrémentiel pour limiter le mélange de données. Filtrez et utilisez des champs sélectifs pour réduire les frais généraux.                                                                                         | Utilisez des micro-batchs pour contrôler les pics d'E/S. Envisagez l'agrégation fenêtrée pour réduire la charge de traitement.                                                             | Utilisé pour les rapports d'archives ou les clichés instantanés périodiques. Assurez-vous que la localisation du calcul est dans la même région que le stockage source pour optimiser les coûts.                                              |

### Fédération de données Zero Copy

#### Cas d'utilisation Zero Copy

Utilisez _Zero Copy_ pour interroger en temps réel des systèmes externes sans duplication des données afin de permettre l'agilité, la fraîcheur et l'accès évolutif à des jeux de données volumineux ou transitoires. Il convient aux tableaux de bord live, aux analytiques exploratoires, à l'entraînement au modèle IA/ML et à l'engagement client en temps réel directement via Salesforce _Data 360_.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360 Zero Copy.png" alt="Vue d&apos;ensemble de la fédération de données Zero Copy" />

#### Méthodes Zero Copy

En utilisant _Zero Copy_, les architectes doivent choisir entre trois méthodes de fédération de données disponibles, chacune offrant ses propres compromis entre fraîcheur, performance et coût.

- **Requête en direct**
  - Exécute des requêtes directement sur des systèmes externes (par exemple, _Snowflake_, _Google BigQuery_, _Redshift_, _Databricks_, etc.) sans duplication de données.
  - Réduit les mouvements de données sur le réseau et les entrées/sorties dans le calcul Salesforce _Data 360_, ce qui est optimal lorsque les prédicats et les agrégations peuvent être déplacés vers le bas.
  - Convient pour les connaissances en temps réel et les tableaux de bord opérationnels à faible latence.
  - Selon les performances du système externe.
- **Mise en cache (requête accélérée)**
  - Stocke temporairement des copies mises en cache de données fédérées dans Salesforce _Data 360_.
  - Réduit les coûts des requêtes répétées et la latence des jeux de données fréquemment accédés avec une durée configurable (minutes à jours).
  - Les données ne sont pas copiées en permanence ni entièrement régies. Par conséquent, l'actualisation planifiée à partir de la source permet de gérer l'actualisation.
  - L'_actualisation incrémentielle_ prend en charge uniquement les mises à jour/insertions. Les enregistrements supprimés ne sont pas retirés du cache.
  - Effectuez périodiquement une actualisation complète pour vous assurer que le cache reste synchronisé avec la source.
  - **Note :** Le connecteur _Snowflake_ prend en charge la fonction _Unload_, qui améliore les taux d'accélération en utilisant un compartiment intermédiaire initié par Snowflake. Elle est activée par défaut, mais peut être désactivée en modifiant la connexion.
- **Fédération de fichiers**
  - Fournit un accès direct en lecture seule aux jeux de données à grande échelle dans les magasins d'objets (par exemple, _S3_ et _GCS_ avec _Iceberg_).
  - Convient aux charges de travail IA/ML, aux analytiques historiques et aux rapports à l'échelle du pétaoctet sans déplacer les données.
  - Les performances des requêtes dépendent fortement du format des objets, du partitionnement et des entrées/sorties réseau. Les analyses volumineuses peuvent générer des entrées/sorties importantes si elles ne sont pas optimisées.

#### Guide pour architectes

- **Cas d'utilisation**
  - La **personnalisation en temps réel et les workflows adaptatifs** offrent des offres dynamiques, des recommandations et des actions Next Best à mesure que les comportements des clients changent.
  - Les **tableaux de bord live et les analytiques opérationnelles** pilotent les tableaux de bord et les indicateurs de performance clés critiques de l'entreprise directement depuis des entrepôts externes.
  - **L ' entraînement aux modèles IA/ML avec de grands jeux de données externes** exploite les données à l ' échelle du pétaoctet des lacs de données et des entrepôts sans les déplacer par fédération de fichiers.
- **Scénarios sectoriels**
  - **Retail/Media&nbsp;:** Activez des recommandations personnalisées et l'engagement client en temps réel en fédérant les données de flux de clics ou d'interaction de contenus.
  - **Finance&nbsp;:** Exécutez la détection des fraudes et le score de risque en temps quasi réel en interrogeant des entrepôts externes sans dupliquer les données confidentielles.
  - **Tech/Entreprise&nbsp;:** Prenez en charge les rapports inter-clouds, les tableaux de bord de service TI et les analytiques opérationnelles lorsque les jeux de données résident dans plusieurs systèmes.
- **Pratiques de conception**
  - **Requête en direct**
    - Utilisez pour les requêtes à QPS élevé et à faible latence lorsque la fraîcheur est critique.
    - Envoyez automatiquement des prédicats et des agrégations au système externe afin de réduire le transfert de données sur le réseau.
    - Évitez les requêtes qui analysent inutilement des volumes de données importants.
    - Envisagez plutôt l'élagage des partitions et les filtres.
  - **Fédération de fichiers**
    - Accédez aux jeux de données à l'échelle du pétaoctet dans les magasins d'objets sans ingestion.
    - Réduisez les coûts de latence et de sortie en gardant le stockage d'objets dans la même région Cloud que le calcul Salesforce.
    - Utilisez des formats partitionnés et colonnaires (Parquet/ORC) et des filtres pushdown pour réduire les entrées/sorties et le transfert réseau.
    - Exploitez le pushdown des requêtes et des prédicats pour filtrer et agréger les données à la source, ce qui réduit le mouvement des données.
    - Évitez l'accès aux données inter-régions, sauf si c'est absolument nécessaire, car cela augmente les entrées/sorties, la latence et les coûts.
  - **Caching (Accelerated Query)**
    - Mettez en cache les jeux de données fréquemment accédés pour équilibrer les coûts et les performances.
    - Configurez des intervalles d'actualisation pour équilibrer la fraîcheur et le coût des requêtes.
  - **Conformité&nbsp;:** Appliquez la gouvernance à la source en exploitant la _sécurité au niveau ligne_ et en masquant les politiques directement dans les systèmes fédérés.
    - Voici quelques pratiques recommandées pour uniformiser le RLS et le masquage entre les plates-formes :
      - **Utilisez un ID d'entreprise centralisé.** Mappez des utilisateurs et des entités dans Salesforce _Data 360_ avec un identifiant d'entreprise unique et centralisé qui correspond aux identités dans des systèmes externes.
      - **Alignez les stratégies de sécurité.** Assurez-vous que les stratégies RLS et de masquage dans les systèmes fédérés sont appliquées en fonction de l'identité mappée. Cela préserve la conformité lors de l'interrogation de données externes.
      - **Standardisez les schémas d'identité.** Maintenez des attributs d'identité cohérents (e-mail, ID d'utilisateur, ID de client, etc.) entre toutes les sources de données afin d'éviter les incohérences et les violations d'accès.
- **Considérations relatives aux coûts**
  - **Live Query&nbsp;:** Dans le modèle de paiement par requête, les coûts augmentent pour le calcul externe du lakehouse, ce qui peut entraîner des pics avec un QPS élevé. Cela convient aux cas d'utilisation critiques pour la fraîcheur où la valeur est supérieure à la variabilité du coût.
  - **Requête accélérée (mise en cache)&nbsp;:** Cette méthode réduit le coût des requêtes (par rapport à _Live Query)_ en réduisant les accès au système source. Cependant, elle augmente les coûts d'ingestion de données par lot pour remplir et actualiser le cache. Convient aux jeux de données fréquemment accédés.
  - **Fédération de fichiers :** Cette option de stockage est la moins chère en tant que données dans Object Store. Cependant, les coûts de requête dépendent de la taille du fichier, du partitionnement et de l'élagage. Convient pour les données historiques ou en masse à l'échelle du pétaoctet.

#### Critères de décision de la méthode Zero Copy

| Point de décision           | Live Query                                                                                                                                                                                                                    | Mise en cache (requête accélérée)                                                                                                                                | Fédération de fichiers                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Emplacement de la source de données** | Maisons de lac de données externes (par exemple, _Snowflake_, _Google BigQuery_, _Redshift_ et _Databricks_)                                                                                                                         | Maisons de lac de données externes (par exemple, _Snowflake_, _Google BigQuery_, _Redshift_ et _Databricks_)                                                      | Les magasins d'objets ou les lacs de données Cloud (par exemple, _S3_, _ADLS_ et _GCS_), qui utilisent souvent des formats de tableau ouverts tels que _Iceberg_.                                                                                                                                                                                                                                                                                                                                                     |
| **Objectif/cas d'utilisation**     | Convient pour l'analyse interactive et les tableaux de bord en temps réel. Convient pour la personnalisation en temps réel et les workflows dynamiques.                                                                                                     | Convient lorsque les requêtes sont fréquentes, mais que les résultats légèrement périmés sont acceptables. Convient pour les tableaux de bord BI et la segmentation.                            | Convient pour le traitement par lot à grande échelle et l'entraînement au modèle IA/ML. Convient pour les analytiques historiques et les rapports à l'échelle des pétaoctets.                                                                                                                                                                                                                                                                                                                                              |
| **Fraîcheur/Latence**    | Fournit une fraîcheur maximale en exécutant les requêtes directement en temps réel. Prend en charge la prise de décision en moins d'une seconde lorsque le système source est optimisé pour les requêtes à faible latence avec un pushdown des prédicats efficace.                                 | Utiliser lorsque les résultats légèrement périmés sont acceptables. La fraîcheur dépend de l'intervalle de mise en cache, qui peut être configuré de 15 minutes à 7 jours.                  | Convient pour les tâches lourdes en lots et exigeantes en débit. Ne convient pas aux tableaux de bord en temps réel.                                                                                                                                                                                                                                                                                                                                                                                    |
| **Modèle d'accès**       | Convient aux requêtes peu fréquentes ou ponctuelles où la fraîcheur est critique et le volume de requête faible. Les coûts augmentent considérablement lorsque le QPS est élevé. Par conséquent, il est important d'évaluer la mise en cache (requête accélérée) lorsque la fréquence des requêtes est élevée. | Convient aux scénarios de lecture à haute fréquence. Améliore les performances des modèles d'accès fréquents.                                                             | Fournit un accès *en lecture seule*. Convient aux jeux de données à l'échelle du pétaoctet sans ingestion.                                                                                                                                                                                                                                                                                                                                                                                             |
| **Facteurs de performance**  | Très dépendant des performances du système source externe. Convient lorsque les prédicats et les agrégations peuvent être poussés vers la source.                                                                                     | Réduit la latence par rapport aux requêtes live répétées. Les performances dépendent de la gestion du cache et des intervalles.                                             | Les performances dépendent fortement du format de l'objet, du partitionnement et du débit système externe. Utilisez des formats partitionnés et colonnaires (Parquet/ORC).                                                                                                                                                                                                                                                                                                                                     |
| **Incidences sur les coûts**    | Il s'agit d'un modèle de paiement par requête. Par conséquent, les coûts s'accumulent dans les calculs lakehouse externes. Il est économique pour les requêtes peu fréquentes, mais les dépenses peuvent augmenter avec un volume de QPS élevé.                                                  | Le coût est inférieur aux requêtes en direct répétées. Il réduit la nécessité d'interroger régulièrement la source externe, mais ajoute un espace de stockage cache et une actualisation supplémentaire. | Cette option de stockage est la moins chère. Pour des configurations AWS de même région et de même cloud (par exemple, _S3_ dans US-East-1 avec un locataire _Data Cloud_ également dans US-East-1), les crédits ne sont pas consommés pour les lignes accédées. Les configurations inter-régions ou inter-clouds (par exemple, _Azure_, _GCS_ ou différentes régions _AWS_) entraînent une consommation de crédit pour les lignes accédées. Les coûts de requête dépendent également de la taille du fichier, du partitionnement et de l'optimisation pushdown des prédicats. |
| **Considération clé**    | Évitez les requêtes non filtrées qui analysent inutilement des volumes de données importants.                                                                                                                                                        | Cette approche nécessite la gestion du cache. Non adapté à la prise de décision en moins d'une seconde.                                                                          | Les performances des requêtes dépendent fortement de l'optimisation via le partitionnement et la pushdown des prédicats.                                                                                                                                                                                                                                                                                                                                                                                        |

### Approche hybride

Les architectures hybrides permettent aux architectes d'ancrer des jeux de données critiques dans _Data 360_ pour une gouvernance centralisée, tout en exploitant les requêtes fédérées pour l'actualisation, la réduction des duplications et l'accès évolutif à des jeux de données externes volumineux. Cette approche concilie les exigences d'E/S, de localisation du calcul, de coût et de conformité.

#### Cas d'utilisation hybrides

Utilisez une approche hybride pour une gouvernance équilibrée, la fraîcheur et l'efficacité opérationnelle en combinant l'ingestion de données et la copie zéro pour fournir des connaissances en temps réel et actionnables. Utilisez l'ingestion pour des jeux de données réglementés de grande valeur où la traçabilité, le RLS et le masquage sont requis, et la fédération pour des jeux de données éphémères ou à haut volume où la fraîcheur et les performances sont essentielles.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Copy of Hybrid.png" alt="Vue d&apos;ensemble de l&apos;approche hybride" />

#### Guide de l'architecte

- **Cas d'utilisation**
  - **Engagement omnicanal :** Combinez les données clients historiques avec un comportement en temps réel pour offrir des expériences cohérentes et sensibles au contexte.
  - **Pipelines IA/ML :** Entraînez les modèles sur des jeux de données organisés et canoniques tout en les enrichissant avec des signaux bruts ou en temps réel provenant de sources externes.
  - **Besoins mixtes de conformité et d'agilité :** Appliquez une gouvernance stricte pour les données confidentielles et une fédération pour l'agilité opérationnelle.
- **Scénarios de secteur d'activité**
  - **Commerce de détail :** Utilisez l'_ingestion_ pour la résolution de l'identité et l'unification des profils, et _la fédération_ pour les offres en temps réel et la personnalisation.
  - **Soins de santé :** Gérez les enregistrements de patient dorés via _l'ingestion_ tout en utilisant _la fédération sur_ les flux d'appareils Internet des objets et les données des capteurs pour un contexte immédiat.
  - **Services financiers :** Ingérez des données réglementées dans un lac régi par la conformité en utilisant _la fédération_ pour des requêtes externes de détection des fraudes et de surveillance des risques.
- **Pratiques de conception**
  - **Ancrage de la gouvernance avec l'ingestion :** Ingérez des données de grande valeur ou réglementées dans des modèles canoniques pour garantir Trust et conformité.
  - **Utilisez la fédération pour la fraîcheur :** Permet aux maisons de lac externes de fournir un accès aux données en temps réel ou à grande échelle sans duplication.
  - **Équilibrer le coût et la performance :** Profilez les charges de travail afin de déterminer quand utiliser l'_ingestion_ par rapport à _la fédération_, ce qui réduit les coûts inutiles de stockage et de requête.
  - **Appliquer la gouvernance en couches :** Appliquer la gouvernance centralisée pour les données ingérées tout en tirant parti des contrôles de sécurité des systèmes fédérés (par exemple, RLS et masquage).
  - **Note :** Lorsque vous concevez des pipelines hybrides, il est important d'assurer l'ingestion incrémentielle pour les jeux de données historiques et d'envoyer automatiquement des agrégations ou des filtres à des sources fédérées afin d'optimiser les entrées/sorties et de calculer l'utilisation.
- **Considérations relatives aux coûts**
  - Évaluez le coût total par rapport aux performances en combinant l'_ingestion_ pour la conformité ou des données critiques avec _la fédération_ lorsque la fraîcheur est nécessaire.
  - Tenez compte de la répartition des E/S et du calcul lors du mélange de l'_ingestion_ et de la _fédération_. Pour réduire les coûts de calcul des requêtes répétées par rapport aux systèmes sources, utilisez la mise en cache (requête accélérée) pour les jeux de données fédérés fréquemment accédés et très lus.
  - Utilisez cette règle pour guider la décision d'ingestion par rapport à la fédération : Lorsque les données sont accédées fréquemment, mais changent rarement, la _requête accélérée_ est généralement plus économique. Cependant, lorsque les données changent fréquemment (par rapport à la fréquence d'accès), _Live Query_ ou _ingestion_ est plus approprié. Voici quelques exemples de coûts :
    - **L'accélération l'emporte :** Un tableau de bord élaboré à partir de 1 million d'enregistrements et mis à jour quotidiennement avec environ 10 000 modifications est visualisé 20 fois par jour. Les coûts d'_accélération_ s'élèvent à environ 600 crédits par mois, contre environ 4 200 crédits par mois pour _Live Queries_.
    - **Live Query l'emporte :** Segments publiés 20 fois par jour en utilisant des données qui changent toutes les 30 minutes. Les _requêtes live_ coûtent environ 4 200 crédits par mois contre 28 800 crédits par mois pour l'_accélération_ à cette fréquence d'actualisation.

## Guide de décision des cas d'utilisation

Examinons de plus près quelques archétypes courants qui illustrent comment appliquer cette logique.

- **L'archétype « Source unique de vérité » : Centraliser et gouverner**
  - **Scénario :** Vous devez élaborer des profils _Client 360_ conformes et unifiés pour l'ensemble de votre entreprise mondiale. Les données proviennent d’une douzaine de systèmes différents, elles doivent respecter des réglementations strictes _RGPD_ et _CCPA_, et elles serviront de source de vérité pour toutes les interactions marketing et de service.
  - **Schéma recommandé :** **Ingestion de données.** La priorité ici est la gouvernance, la confiance et le contrôle. L'ingestion des données dans _Data 360_ est le seul moyen de créer un profil canonique entièrement auditable, isolé des systèmes sources.
- **L'archétype « Connaissances en temps réel » : Analyser sans déplacer**
  - **Scénario :** Votre équipe de science des données doit exécuter des requêtes exploratoires sur un tableau de transactions massif et constamment mis à jour dans _Snowflake_. En même temps, votre équipe de direction souhaite un tableau de bord _BI_ live piloté par ces mêmes données. Le déplacement quotidien de pétaoctets de données est lent et coûteux.
  - **Modèle recommandé :** **Zero Copy Federation.** La priorité ici est la rapidité, l'agilité et la rentabilité à l'échelle. _Zero Copy_ vous permet de tirer parti de la puissance de votre entrepôt de données existant pour les requêtes en temps réel, sans surcharge ni latence de la duplication des données.
- **L'archétype « Intelligence hybride » : Gouverner le cœur, fédérer la périphérie**
  - **Scénario :** Vous souhaitez enrichir vos profils clients gouvernés et ingérés avec des signaux comportementaux en temps réel (par exemple, des clics sur un site Web) à partir d'un lac de données. Vous avez besoin de la stabilité du profil principal, mais de l'immédiateté des données live pour piloter la personnalisation instantanée.
  - **Modèle recommandé :** **A Hybrid Approach.** Utilisez l'_Ingestion de données_ afin de créer un noyau stable et gouverné pour vos données clients. Utilisez _Zero Copy_ pour fédérer les données « edge » volatiles en temps réel, puis joignez-les au moment de la requête pour une vue complète et actualisée.

## La voie à suivre

La stratégie de données d'entreprise ne se concentre plus sur le choix d'un modèle d'intégration unique, mais sur l'architecture d'une flexibilité contrôlée dans un écosystème de données interopérable. L'approche correcte associe chaque système source au modèle le plus adapté à ses exigences en matière de fraîcheur, de gouvernance, de coût et d'accès :

- Ingérez des jeux de données réglementés critiques dans Salesforce _Data Cloud_ pour la conformité, la résolution de l'identité et les workflows opérationnels.
- Fédérez des données via _Zero Copy_ pour des analytiques live, exploratoires et pilotées par l’IA sans dupliquer le stockage.
- Appliquer la _mise en cache (requête accélérée)_ pour réduire la charge du système source et la consommation de crédits lorsque la fréquence de requête est élevée et la fréquence de modification des données faible

Salesforce _Data 360_ sur _Hyperforce_ offre une résilience et une évolutivité multi-régions. Ses portes ouvertes avec des tables _Iceberg_ permettent la séparation des calculs et l'interopérabilité avec des plates-formes telles que _Snowflake_, _Databricks_ et _S3 Iceberg, qui_ forment l'épine dorsale d'un écosystème de données multicloud véritablement interopérable.

À mesure que les écosystèmes de données évoluent, nous devons constamment équilibrer fraîcheur, coût, performance et conformité pour maintenir l'agilité architecturale. Par conséquent, il est important de pérenniser votre plate-forme en unifiant les données ingérées et régies avec un accès fédéré. Cela permet l'intelligence en temps réel, l'activation de l'IA et la personnalisation à l'échelle de l'entreprise à travers les Clouds, les régions et les domaines métiers.

Notez que les solutions universelles ne conviennent pas à la plupart des entreprises. La stratégie optimale associe le modèle correct au levier métier approprié.

## À propos des auteurs

**Yugandhar Bora** est architecte en génie logiciel chez Salesforce, spécialiste de l'architecture de données sur la plate-forme Data and Intelligence Applications. Il dirige les initiatives du comité d’examen de l’architecture d’_entreprise (EARB)_ qui se concentrent sur la gouvernance des données et les modèles de données unifiés tout en contribuant à des solutions de provisionnement de plate-forme automatisées.

**Jan Fernando**, architecte principal au _bureau de l’architecte_ en chef (OCA) chez Salesforce, a rejoint Salesforce en 2012 et apporte une riche expérience de son expérience dans l’écosystème des startups. Avant de se joindre à l’OCA, il a passé plus d’une décennie au sein de l’organisation _Plate-forme_, où il a dirigé plusieurs transformations technologiques clés.

<!-- document id=22b365865cdb58a6eb7f68215aa70bb0b00f8591082f43e26c8b8f13f28eaeb9 url=/architect/current/fr-fr/decision-guides/guides/get-started-integration-decision-guides.md -->

# Premiers pas avec les guides de décision d'intégration

Cette section fournit des conseils pratiques pour choisir les outils et les approches d'intégration de données appropriés pour Salesforce. Il couvre les intégrations sortantes, les intégrations entrantes et les scénarios inter-organisations, aidant les architectes à concevoir et à implémenter des intégrations de couche de données qui équilibrent performances, maintenabilité et coût.

---

## Intégration de données avec Salesforce

L'[intégration de données](/docs/architect/fr-fr/decision-guides/guide/data-integration) à Salesforce présente une vue d'ensemble complète des outils et des meilleures pratiques d'intégration de données Salesforce :

- **Paysage des outils d'intégration**: Vue d'ensemble des outils d'intégration de données Salesforce, notamment les options low-code, hybrides et pro-code, avec des conseils pour sélectionner l'outil approprié à des cas d'utilisation spécifiques.
- **Intégrations sortantes**: Méthodes d'envoi de données depuis Salesforce vers des systèmes externes, notamment Capture des données de modification, Services externes, Heroku Connect, Procédures d'intégration OmniStudio, Salesforce Connect, MuleSoft Anypoint et solutions Apex personnalisées.
- **Intégrations entrantes**: Approches d'intégration de données externes dans Salesforce, avec des conseils sur la réplication des données par rapport à la virtualisation et quand utiliser chaque outil.
- **Intégrations inter-organisations**: Méthodes recommandées pour le partage de données entre les organisations Salesforce, notamment MuleSoft Anypoint, Heroku Connect, les API Salesforce natives, Capture des données de modification et Salesforce Connect avec l'adaptateur inter-organisations, y compris un guide pour remplacer les implémentations Salesforce vers Salesforce héritées.
- **Cadre de décision**: Considérations clés relatives à la sélection d'outils d'intégration, notamment les outils et le paysage existants, les exigences en flux de données (calendrier, directionnalité, expérience utilisateur attendue), la complexité de l'implémentation, la maintenabilité, le volume de données et les limites de la plate-forme.

Permet aux architectes de choisir les outils et les modèles d'intégration appropriés pour chaque scénario, en réduisant les réplications de données inutiles, en exploitant les solutions ESB/ETL existantes et en garantissant des intégrations évolutives et maintenables qui respectent les principes de l'architecture d'entreprise.

<!-- document id=b42f10c6cda3ddbb5c5170f4889327811ed8cf4c20229d463bc7a4e2dae351f8 url=/architect/current/fr-fr/decision-guides/guides/get-started-data-360-decision-guides.md -->

# Premiers pas avec les guides de décision Data 360

Cette section fournit des conseils pratiques pour prendre des décisions architecturales critiques concernant Salesforce Data 360, notamment des stratégies de provisionnement, la connectivité multi-organisations et des modèles d'intégration. Utilisez ces guides pour concevoir et implémenter des architectures de données efficaces qui unifient les données des clients et activent des fonctionnalités pilotées par l’IA.

---

## Provisionnement de Data 360

[Le provisionnement Data 360](/docs/architect/fr-fr/decision-guides/guide/data-360-provisioning) couvre les décisions fondamentales lors du provisionnement de Salesforce Data 360 :

- **Sélection de l'organisation d'accueil**: Déterminez s'il faut provisionner Data 360 dans une organisation de production existante ou créer une organisation dédiée, en tenant compte de la gouvernance, de la conformité et de la rapidité de mise en œuvre.
- **Stratégie multi-organisations**: Choisissez entre plusieurs instances Data 360 indépendantes ou utilisez Data Cloud One pour unifier plusieurs organisations Salesforce, en équilibrant autonomie, conformité et coût.
- **Architecture Data Cloud One**: Activez plusieurs organisations compagnes pour partager une instance Data 360 unique avec la gouvernance centralisée, le partage de métadonnées et la parité des fonctionnalités entre les organisations.
- **Partage de données entre des organisations Data 360**: Utilisez le partage de données sans copie entre des instances indépendantes pour la conformité régionale, la collaboration des unités commerciales ou des tableaux de bord exécutifs fédérés.
- **Considérations relatives au provisionnement**: Tenez compte de la résidence des données, des modèles de gouvernance, de la latence, de la complexité de l'intégration, du coût et de la préparation de l'IA aux déploiements à l'échelle de l'entreprise.

Aide les architectes à concevoir des stratégies de provisionnement qui garantissent la simplicité, la cohérence de l'entreprise, la conformité et l'évolutivité pour Customer 360, l'IA et l'innovation multi-plate-forme.

---

## Interopérabilité de Data 360

[L'interopérabilité Data 360](/docs/architect/fr-fr/decision-guides/guide/data-360-interoperability) fournit un cadre pour l'intégration de Data 360 à des plates-formes externes et des lacs de données :

- **Modèles d'ingestion de données**: Ingestion en temps réel, en continu et par lot pour créer des jeux de données canoniques régis idéaux pour Customer 360, la conformité et la gouvernance centralisée.
- **Zero-Copy Data Federation**: Méthodes de requête live, de requête accélérée (mise en cache) et de fédération de fichiers pour accéder en temps réel à des systèmes externes sans duplication, ce qui permet la personnalisation, les tableaux de bord et les charges de travail IA/ML.
- **Approche hybride**: Combinez l'ingestion régie pour les jeux de données de base avec une fédération sans copie pour la fraîcheur et l’évolutivité, en prenant en charge l’engagement omni-canal, les actions pilotées par Agentforce et les analytiques d'entreprise.
- **Cadre de décision**: Évaluez les compromis en termes de latence, de coût, d'évolutivité, de gouvernance et de complexité afin de sélectionner le modèle d'intégration approprié par source de données.
- **Guides pour architectes**: Guides spécifiques au secteur d'activité, pratiques de conception et considérations sur les coûts pour les scénarios de finance, de santé, de vente au détail et de télécommunications.

Guide les architectes dans l'équilibre entre l'actualisation des données, la gouvernance et l'efficacité du pipeline pour élaborer des architectures de données évolutives, interopérables et prêtes pour l'IA qui prennent en charge les charges de travail opérationnelles et analytiques.

<!-- document id=26b91359be805c63ffc1137c465a0d2ea68cfb954de6420a00620c20823460d1 url=/architect/current/fr-fr/decision-guides/guides/get-started-platform-decision-guides.md -->

# Premiers pas avec les guides de décision de la Plateforme

Cette section fournit des conseils pratiques pour prendre des décisions architecturales critiques sur les capacités de Salesforce Platform. Il couvre le traitement asynchrone, les événements déclenchés par un enregistrement, l'élaboration de formulaires, l'automatisation des workflows agentsiques et traditionnels, l'architecture pilotée par les événements et les infrastructures asynchrones basées sur des étapes afin d'aider les architectes à concevoir des solutions de plate-forme évolutives, maintenables et performantes.

---

## Traitement asynchrone

[Traitement asynchrone](/docs/architect/fr-fr/decision-guides/guide/async-processing) fournit des conseils sur les outils et les approches pour les opérations asynchrones dans Salesforce :

- **Outils de traitement asynchrone**: Comparaison entre Apex Queueable, Apex planifié, Déclencheurs d'événements de plate-forme, Capture des données de modification, Parcours planifié (après validation des flux) et Parcours asynchrone (flux déclenchés par un enregistrement), avec des conseils sur les cas d'utilisation appropriés.
- **Traitement asynchrone côté serveur**: Modèles pour les opérations de base de données de longue durée, les appels externes et le traitement d'enregistrements volumineux.
- **Traitement asynchrone côté client**: Des techniques comme les Appels externes de continuation Apex et le traitement asynchrone côté client qui peuvent être exécutés dans des navigateurs ou des applications mobiles.
- **Cadre de décision**: Tenez compte de la validation des cas d'utilisation, de l'évolutivité, de la compréhension des transactions réellement asynchrones, de la surveillance et de la gestion des événements de charge extrêmes.
- **Meilleures pratiques et anti-modèles**: Guide pour une bonne utilisation, y compris les intégrations sortantes, la surveillance et l'évitement des pièges courants.

Permet aux architectes d'implémenter des modèles asynchrones évolutifs, fiables et maintenables, en évitant les pièges qui compromettent les performances.

---

## Création de formulaires

[Création de formulaires](/docs/architect/fr-fr/decision-guides/guide/build-forms) guide les architectes sur les options de création de formulaires Salesforce :

- **Outils de création de formulaires**: Comparaison des formulaires dynamiques, des flux d'écran, d'OmniStudio, des flux d'écran avec les Composants Web Lightning (LWC) et des Composants Web Lightning, y compris les compétences et les considérations relatives aux licences.
- **Cadre de décision**: Tenez compte de l'impact des objets, de l'étendue du formulaire, de la navigation, de la localisation (application, mobile, Web), de l'expérience utilisateur et de l'automatisation des tests.
- **Guide de sélection**: Recommandations allant de simples présentations d'enregistrement à des assistants multipages et des formulaires de marque destinés aux clients.
- **Modèles de combinaison**: Guide pour combiner des outils, par exemple la navigation dans les flux d'écran avec le style Composant Web Lightning.
- **Fonctionnalités avancées**: Exploration approfondie des capacités et des limites pour éclairer le choix de l'outil.

Aide les architectes à sélectionner l'approche de création de formulaire adaptée à leurs exigences spécifiques en matière d'expérience utilisateur (UX), fonctionnelles et d'intégration.

---

## Détermination de l'automatisation des workflows agentsiques et traditionnels

La [détermination de l'automatisation des workflows](/docs/architect/fr-fr/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html) Agentic et Traditionnels fournit un cadre permettant de choisir entre l'automatisation traditionnelle et Agentforce utilisant le cadre de densité d'orchestration:

- **Cadre de densité d'orchestration**: Évalue la complexité de l'automatisation en fonction du parcours d'exécution (entièrement spécifiable et non spécifiable), de la complexité des objectifs (tâche unique et objectifs concurrents) et du mix de modalités (entrées structurées et multimodales).
- **Paysage de produit**: Comparaison des flux, Apex, Agentforce, Agent Script, Agentforce Grid, Agentforce Operations et MuleSoft pour différents scénarios d'automatisation.
- **Matrice de sélection de densité**: Mappez les niveaux de densité d'orchestration (faible, moyen, élevé) avec les normes architecturales, depuis l'automatisation déclenchée par un enregistrement jusqu'à l'orchestration hybride en passant par le déterminisme guidé avec Agent Script.
- **Cadre de décision**: Processus d'évaluation séquentiel (d'abord inspecter le parcours d'exécution, puis la complexité de l'objectif, puis le mix de modalités) pour déterminer l'outil approprié.
- **Guide de cas d'utilisation**: Des recommandations spécifiques pour l'automatisation traditionnelle (basée sur des règles, déterministe), Agentforce Grid (tâches d'IA en masse), l'orchestration hybride (processus complexes de bout en bout) et Agent Script (points d'entrée non structurés avec des besoins de raisonnement).

Permet aux architectes de prendre des décisions informées à travers le spectre de l'automatisation, en équilibrant les capacités de raisonnement avec un contrôle déterministe pour des solutions évolutives, auditables et maintenables.

---

## Architecture pilotée par les événements

[Architecture pilotée par les événements](/docs/architect/fr-fr/decision-guides/guide/event-driven) fournit un guide complet sur les outils et les modèles des événements Salesforce :

- **Outils d'événements**: Vue d'ensemble des événements de plate-forme, Capture des données de modification, API Pub/Sub, MuleSoft Anypoint, API Streaming, et considérations relatives à l'intégration.
- **Modèles pilotés par les événements**: Inclut des modèles de publication/inscription, fanout, messages transmis, streaming et mise en file d'attente pour divers cas d'utilisation pilotés par l'événement.
- **Intégration avec MuleSoft**: Utilisation des connecteurs Anypoint (Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) pour les architectures d'entreprise.
- **Événements de Plate-forme et Capture de données de changements**: Guide sur les mécanismes préférés de publication des modifications des enregistrements et des champs, avec la migration depuis PushTopic/Generic Events.
- **Schémas d'implémentation**: Meilleures pratiques pour l'évolutivité, la cohérence, le traitement des erreurs et la surveillance.

Permet aux architectes de concevoir des systèmes pilotés par des événements évolutifs en temps quasi réel qui connectent efficacement plusieurs systèmes.

---

## Framework asynchrone basé sur les étapes

[Framework asynchrone basé sur les étapes](/docs/architect/fr-fr/decision-guides/guide/step-based-async-framework) fournit un cadre pour le traitement modulaire et évolutif des tâches asynchrones :

- **Architecture du framework**: Les composants comprennent Queueable Apex, Finalizers, Scheduled Flow, Apex Cursors, Actions invocables et intégrations Slack.
- **Traitement basé sur les étapes**: Brise le travail en étapes indépendantes qui peuvent être exécutées, réessayées et redémarrées avec une gouvernance partagée et une visibilité opérationnelle.
- **Instructions de mise en œuvre**: Modèles pour l'interface Étape, le processeur Étape, la couche Invocable Apex, le traitement des délais et les notifications.
- **Meilleures pratiques**: Recommandé lorsque la plupart des informations se trouvent dans le CRM, pour les charges de travail à haut volume et le traitement hiérarchique ou arborescent des enregistrements, ainsi que des indications sur quand ne pas l'utiliser.
- **Fonctionnalités de niveau entreprise**: Gouvernance, conformité, état distribué, suivi de la progression, surveillance des accords de niveau de service, diagnostics d'échec et consignation au niveau de l'audit.

Fournit aux architectes une alternative évolutive aux tâches par lot monolithiques et aux appels asynchrones enchaînés, prenant en charge les charges de travail Salesforce à haut volume avec une transparence opérationnelle totale.

---

## Automatisation déclenchée par des enregistrements

[Automatisation déclenchée par des enregistrements](/docs/architect/fr-fr/decision-guides/guide/record-triggered) fournit le cadre permettant de concevoir l'automatisation déclenchée par des enregistrements sur la plateforme Salesforce :

- **Sélection des outils**: Quand utiliser les déclencheurs Flux déclenché par un enregistrement par rapport aux déclencheurs Apex, guidés par la densité d'automatisation (faible, moyenne, élevée) et la matrice de sélection de densité.
- **Densité d'automatisation**: Comment évaluer la quantité d'automatisation, le volume d'enregistrements et l'étalement des dépendances pour choisir des déclencheurs Flux, hybrides (Flux avec Apex invocable) ou Apex.
- **Points d'entrée et gouvernance**: Un point d'entrée par objet Salesforce ; guide sur les conditions d'entrée, le contrôle de la récursivité et l'exécution ordonnée.
- **Invocation asynchrone**: Quand et comment invoquer des processus asynchrones à partir de flux déclenchés par un enregistrement ou Apex, avec précaution quant au traitement des erreurs et aux limites du gouverneur.
- **Meilleures pratiques**: Modèles de traitement par lots, conception hybride Flow–Apex et évitement des pièges courants dans l'automatisation des déclencheurs.

Permet aux architectes de concevoir une automatisation déclenchée par un enregistrement évolutive, maintenable et performante, conforme aux normes de la plateforme.

<!-- document id=c26ba8d0156d1d0b7a071bf0c6ee64616ce5126af27052336de5114f46f2d3d0 url=/architect/current/fr-fr/decision-guides/guides/data-360-provisioning.md -->

# Provisionnement Data 360

Salesforce Data 360 est une plate-forme de données basée sur [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) qui unifie Salesforce et les données externes dans une vue complète, claire et fiable de chaque client ou compte.

Les entreprises exploitent souvent plusieurs organisations Salesforce en raison de fusions et d'acquisitions, d'opérations régionales, d'une séparation fonctionnelle ou pour des raisons historiques. Les architectes doivent prendre plusieurs décisions concernant Data 360, qui impactent la gouvernance, la conformité, le coût, la latence et la capacité de l'organisation à adapter les fonctionnalités de l'IA et de la plate-forme inter-organisations.

## Présentation du guide

Ce guide fournit un cadre pour prendre des décisions de provisionnement avec Data 360\. Ces décisions comprennent :

- Sélection d'une seule organisation d'origine par rapport à une configuration multi-organisations

- Provisionnement de plusieurs instances Data 360 indépendantes

  - Utiliser Data Cloud One pour unifier les organisations sous une instance unique

  - Collaboration entre des instances Data 360 indépendantes qui utilisent le partage de données entre des organisations Data 360

Data 360 est automatiquement provisionnée dans toute organisation de production qui reçoit une licence Data 360. Data Cloud One est l'architecture de connectivité multi-organisations de Salesforce qui permet à une seule organisation domestique d'héberger l'instance Data 360, tandis que d'autres organisations Salesforce se connectent en tant qu'organisations compagnes. Le choix de l'organisation détentrice de la licence Data 360, qui devient ainsi une organisation domestique Data 360, est une décision architecturale critique avec des conséquences à long terme.

Le provisionnement de Salesforce Data 360 est une décision architecturale fondamentale. Il détermine comment l'entreprise unifie les données des clients, applique la gouvernance et active les fonctionnalités critiques de la plate-forme, en particulier l'IA, Agentforce et les analytiques dans l'ensemble de l'organisation. L'ancrage d'un cluster d'organisations à une Data 360 unique fournit un modèle de données unifié, une gouvernance centralisée et permet de préparer l'entreprise à l'IA. Les organisations compagnes peuvent accéder aux métadonnées et fonctionnalités partagées comme si les données étaient locales. Par contre, plusieurs instances Data 360 indépendantes sont appropriées lorsque les exigences réglementaires, de conformité ou d'autonomie empêchent la centralisation. Le partage de données entre les organisations Data 360 permet une collaboration sélective et sans copie entre ces instances.

Cette décision influence qui contrôle la gouvernance des données, où résident les données, comment les fonctionnalités de la plate-forme sont activées et comment les futures intégrations et initiatives IA peuvent évoluer en douceur. Même pour les organisations qui n'ont pas encore Data 360, il peut être important de pérenniser leur architecture en développant une stratégie pour ajouter l'accès Data 360 à l'avenir. De plus en plus, les fonctionnalités de Salesforce dans Sales, Service, Marketing, Commerce, Industries et Agentforce sont élaborées sur Data 360\. Les organisations qui souhaitent utiliser ces fonctionnalités de plate-forme doivent provisionner leur propre Data 360 ou se connecter à une Data 360 partagée en tant qu'organisations compagnes.

Ce guide aide les architectes à concevoir une stratégie de provisionnement qui concilie simplicité, cohérence à l'échelle de l'entreprise, conformité et évolutivité, afin de s'assurer que l'organisation peut exploiter en toute confiance Data 360 pour Customer 360, l'IA et l'innovation multi-plate-forme. Utilisez ce guide pour déterminer quelles organisations nécessitent Data 360, et si vous souhaitez utiliser Data Cloud One ou le partage de données entre des organisations Data 360. Cette stratégie établit une base solide pour un avenir centré sur Data 360.

## Produits concernés

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/data360-logo.png" alt="Logo de Salesforce Platform"></td>
      <td>Salesforce Data 360 est la plate-forme de données hyperscale en temps réel de Salesforce qui harmonise et unifie les données de n'importe quelle source (CRM, Web, mobile ou lacs de données externes) dans un profil client unique et actionnable. Composant essentiel de la plate-forme <a href="https://www.salesforce.com/products/what-is-customer-360/">Client 360</a>, elle pilote l’IA, les analytiques et les expériences personnalisées dans les domaines des ventes, du service et du marketing.</td>
    </tr>
  </tbody>
</table>

## Points à retenir

- **Chaque organisation doit planifier l'accès à une instance Data 360.** Chaque organisation doit héberger une organisation domestique Data 360 ou être une organisation associée connectée via Data Cloud One.

- **Pensez à l'échelle de l'entreprise, pas organisation par organisation.** Évitez les décisions unilatérales et métiers prises de façon isolée. Idéalement, une architecture d'entreprise ou un conseil de gouvernance des données devrait décider collectivement de la stratégie de provisionnement. Anticipez toujours les besoins futurs en IA et en analytiques, qui dépendent de jeux de données larges et unifiés.

- **Planifiez la gouvernance et la propriété dès le départ.** Déterminez si Data 360 est gérée de façon centralisée (modèle Centre d'excellence) ou déléguée à des secteurs d'activité. Définissez les rôles des administrateurs, des équipes de sécurité et des pistes de conformité. Évitez toute ambiguïté, car une propriété imprécise peut être problématique.

- **Rappelez-vous que le provisionnement est lié à la licence.** L'organisation dans laquelle la licence Data 360 est achetée détermine où Data 360 est provisionnée et l'emplacement de cette organisation détermine la région.

- **Comprenez les considérations relatives au support de la source de données.** Faites très attention aux régions prises en charge pour divers clouds publics et sources de données sans copie. Déterminez également si Private Connect est requis pour votre dispositif de sécurité afin de vous connecter à ces sources de données et si les connexions dans la région ou entre les régions sont prises en charge.

- **Provisionnez selon que vous disposez d'une organisation unique ou de plusieurs organisations.** Pour les clients mono-organisation, provisionnez Data 360 dans votre organisation de production existante pour une mise en valeur rapide. Pour les clients multi-organisations, réduisez la complexité en créant le moins d'instances Data 360 possible, idéalement en utilisant la configuration Data Cloud One.

- **Utilisez** **plusieurs instances Data 360 uniquement si nécessaire.** Plusieurs instances doivent être utilisées uniquement lorsque la conformité, la résidence ou l'autonomie organisationnelle l'exige. Dans ce cas, utilisez le [partage de données](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5) entre les organisations Data 360 pour activer la collaboration sécurisée.

- **Configurez le partage de données entre les organisations Data 360 pour la collaboration, pas pour des pipelines ETL personnalisés.** Partagez des objets spécifiques (DMO, analyses calculées, segments) par le biais de partages de données. Pour rappel, les balises ne sont pas partagées et la consommation est facturée à l'organisation source.

- **Évitez les raccourcis à court terme.** Ne créez pas plusieurs organisations Data 360 pour des preuves de concept (POC) sans plan à long terme. Alignez les pilotes et les déploiements anticipés sur votre stratégie de provisionnement à l'échelle de l'entreprise.

## Points de décision

Évaluez chaque choix de provisionnement (choisir entre Data Cloud One, le partage de données entre des organisations Data 360 ou la désignation d'une organisation d'origine) par rapport à ces considérations transversales.

<table>
  <tr>
    <th>Considération</th>
    <th>Pourquoi c'est important</th>
    <th>Exemples de scénarios</th>
  </tr>
  <tr>
    <td>Résidence et conformité des données</td>
    <td>Détermine où les données sont stockées et traitées. Les règles réglementaires peuvent exiger des régions spécifiques ou plusieurs instances.</td>
    <td>Une banque mondiale provisionne un locataire Data 360 dans une organisation Salesforce géolocalisée à Francfort pour la conformité au RGPD. Ils provisionnent un autre locataire dans une organisation en Virginie pour sa division américaine.</td>
  </tr>
  <tr>
    <td>Gouvernance et sécurité</td>
    <td>Identifier un administrateur et la propriété de Data 360, y compris les stratégies de gestion des politiques et de délégation.</td>
    <td>Une multinationale dotée d'une solide informatique centrale crée une organisation domestique dédiée gérée par un Centre d'excellence.</td>
  </tr>
  <tr>
    <td>Autonomie et centralisation</td>
    <td>Différents dirigeants peuvent souhaiter une propriété séparée des données. L'autonomie favorise plusieurs organisations Data 360. La centralisation favorise Data Cloud One.</td>
    <td>Une holding avec des filiales indépendantes permet à chaque unité commerciale de gérer sa propre Data 360.</td>
  </tr>
  <tr>
    <td>Latence et performance</td>
    <td>Influe sur la vitesse et l'expérience des requêtes, en particulier pour les organisations associées connectées à un locataire Data 360 à travers les régions.</td>
    <td>Une équipe commerciale de Londres qui interroge les données d'un locataire Data 360 aux États-Unis peut rencontrer une latence plus élevée.</td>
  </tr>
  <tr>
    <td>Complexité de l'intégration</td>
    <td>Plus de locataires Data 360 = plus de pipelines, d'API et de middleware. La consolidation simplifie l'intégration.</td>
    <td>Un détaillant évite d’élaborer 10 pipelines ETL en les regroupant dans une configuration Data Cloud One.</td>
  </tr>
  <tr>
    <td>Zone source de données Zéro copie</td>
    <td>Les exigences d'accès inter-régions de certains connecteurs peuvent limiter la région ou l'emplacement de votre organisation Data 360.</td>
    <td>Une entreprise a une instance Snowflake dans la région AWS eu-west-1. Ils peuvent utiliser Zero Copy pour fédérer des données dans une Data 360 de leur région, mais ne peuvent pas utiliser Zero Copy pour fédérer dans une Data 360 aux États-Unis.</td>
  </tr>
  <tr>
    <td>Compatibilité inter-régions Private Connect</td>
    <td>Parfois, la prise en charge de Private Connect dépend de la localisation de la source de données dans la même région que le locataire Data 360.</td>
    <td>Une entreprise a une instance Snowflake dans la région aws-east-1 qu'elle souhaite connecter à Data 360 via zéro copie. Ils peuvent établir une connexion réseau Private Connect uniquement si l'organisation d'origine Data 360 réside dans la même région.</td>
  </tr>
  <tr>
    <td>Coût et licence</td>
    <td>Chaque locataire Data 360 ajoute un coût. La consolidation en moins d'instances optimise les dépenses.</td>
    <td>Un prestataire de soins réduit les coûts de licence en adoptant Data Cloud One au lieu de plusieurs instances Data 360 indépendantes.</td>
  </tr>
  <tr>
    <td>Évolutivité future</td>
    <td>Les choix de provisionnement posent aujourd'hui les bases de la croissance.</td>
    <td>Une entreprise SaaS commence avec une instance Data 360 unique, mais envisage de se développer vers Data Cloud One en acquérant des filiales avec des organisations Salesforce.</td>
  </tr>
  <tr>
    <td>Préparation à l’IA à l’échelle de l’entreprise</td>
    <td>Les fonctionnalités IA et Agentforce nécessitent un locataire Data 360 connecté dans chaque organisation. Les décisions de provisionnement affectent l'entraînement et l'activation des modèles IA dans l'entreprise.</td>
    <td>Une société de services financiers unifie les données dans Data Cloud One afin que ses modèles IA Einstein aient accès aux données clients de l'entreprise.</td>
  </tr>
</table>

## Cas d'utilisation

Trois cas d'utilisation majeurs nécessitent des décisions pour le provisionnement de Data 360 :

- Choisir l'organisation d'accueil
- Application d'une stratégie multi-organisations
- Partage de données entre des organisations Data 360

### Choisir l'organisation d'accueil

Lorsque vous achetez une licence Data 360, l'instance Data 360 est provisionnée dans l'organisation Salesforce associée à cette licence. Cette organisation est appelée organisation d'accueil Data 360. L'organisation d'accueil est l'ancrage de votre instance Data 360. Cela comprend :

- Gestion du stockage et du calcul Data 360 (dans la région sélectionnée lors du provisionnement).

- Application des politiques d'administration, de gouvernance et de sécurité

- Performances d'ingestion, harmonisation, résolution de l'identité, segmentation et activation des données

Dans les scénarios multi-organisations, l'organisation d'origine gère l'instance centrale Data 360 pour les autres organisations «compagnons» Salesforce.

**L'organisation d'accueil :**

- Détermine l'emplacement géographique de votre instance Data 360.

- Détermine qui est propriétaire et administrateur de votre instance Data 360. Les administrateurs de votre organisation d'origine Data 360 peuvent accéder à toutes les données ingérées dans Data 360.

- Contrôle les connexions d'organisations compagnes dans une configuration Data Cloud One.

- Définit les fondations de votre stratégie de données d'entreprise. La modifier ultérieurement est difficile et perturbatrice.

Pour plus d'informations sur les organisations d'accueil Data 360, consultez [Schémas et pratiques](/docs/architect/fr-fr/fundamentals/guide/data360_integration_patterns_and_practices) d'intégration Data 360.

#### Décision : Organisation existante ou Nouvelle organisation en tant qu'organisation d'accueil ?

La première décision importante est de provisionner Data 360 dans une organisation de production existante ou de créer une organisation dédiée pour agir en tant qu'organisation d'origine.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Existing_Org_vs_New_Dedicated_Org.png" alt="Diagramme de décision montrant l&apos;organisation existante par rapport à la nouvelle organisation en tant qu&apos;organisation d&apos;accueil" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Option A : Provisionnement de Data 360 dans une organisation existante**

**Convient mieux pour :** Les clients d'une seule organisation Salesforce ou les clients de plusieurs organisations qui ont déjà une organisation centralisée majeure dans laquelle la plupart des processus métiers sont exécutés.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_an_existing.png" alt="Diagramme montrant le provisionnement Data 360 dans une organisation existante" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Avantages :**

  - Chemin le plus simple : Data 360 est provisionnée là où vivent vos données CRM.

  - Accès immédiat aux données commerciales, de service et marketing locales.

  - Aucune intégration supplémentaire n'est requise.

  - Moins de licences et d'environnements à gérer.

  - Accélére l'adoption précoce, les pilotes et les cas d'utilisation en production.

- **Inconvénients :**

  - Peut hériter de la gouvernance ou de la dette technique d'une organisation existante.

  - Si aucune « organisation principale » n'existe, sa sélection peut créer des débats sur la propriété.

  - La performance liée à l'emplacement de l'organisation peut ne pas correspondre aux besoins de résidence de l'entreprise.

  - Si plusieurs unités commerciales utilisent différentes organisations, le provisionnement local peut entraîner une fragmentation s'il n'est pas associé à Data Cloud One.

**Exemple :**

Une entreprise SaaS avec une organisation Salesforce provisionne Data 360 dans cette organisation pour unifier les données d'abonnement et de support des clients.

**Option B : Provisionnement de Data 360 dans une nouvelle organisation dédiée**

**Convient mieux pour :** Les clients de plusieurs organisations Salesforce qui ne peuvent pas s'aligner sur une seule organisation majeure, ou les entreprises qui ont un modèle Centre d'excellence (CoE) solide.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_new_dedicated_org.png" alt="Diagramme montrant le provisionnement de Data 360 dans une nouvelle organisation dédiée" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Avantages :**

  - Permet d'établir une gouvernance sur une base entièrement nouvelle, sans les complexités héritées d'une organisation existante.

  - Contrôle centralisé dans plusieurs secteurs d'activité.

  - Flexibilité pour choisir une région en fonction des besoins de conformité.

  - Agit en tant qu'organisation neutre de « service partagé », pas liée à une seule unité commerciale.

  - Configurez pour la future architecture Data Cloud One (organisation d'accueil avec plusieurs organisations compagnes).

- **Inconvénients :**

  - Les clients doivent licencier une nouvelle organisation Salesforce sur laquelle provisionner Data 360.

  - Intégration supplémentaire requise pour connecter l'organisation à Data 360 via une connexion complémentaire Data Cloud One.

  - Peut ajouter une charge administrative (gestion des utilisateurs, sécurité, identité).

  - Délai de valorisation plus long que le provisionnement dans une organisation de production existante.

**Exemple :**

Une multinationale de services financiers crée une organisation d'accueil dédiée pour provisionner Data 360\. Toutes les organisations d'unité commerciale (Retail, Wealth, Commercial Banking) se connectent en tant qu'organisations partenaires via Data Cloud One.

**Critères de décision**

<table>
  <tr>
    <th>Considérations</th>
    <th>Organisation existante en tant qu'organisation d'accueil (préférée par défaut)</th>
    <th>Nouvelle organisation en tant qu'organisation d'accueil (alternative)</th>
  </tr>
  <tr>
    <td>Simplicité</td>
    <td>S'appuie sur l'utilisateur existant et la structure de données pour accélérer la configuration.<br> Data 360 est intégrée par défaut à l'organisation d'accueil .</td>
    <td>Nécessite une licence et la configuration d'une nouvelle organisation Salesforce, ainsi que des frais administratifs supplémentaires pour la gérer</td>
  </tr>
  <tr>
    <td>Temps de mise en valeur</td>
    <td>Utilisation immédiate des données CRM locales</td>
    <td>Le déploiement et l'intégration sont plus lents.</td>
  </tr>
  <tr>
    <td>Gouvernance</td>
    <td>Hérite du modèle de gouvernance de base de l'organisation existante : utilisateurs et ensembles d'autorisations existants (peut être acceptable si l'organisation est déjà centrale ).</td>
    <td>Table rase en matière de gouvernance. Idéal pour les modèles pilotés par COE.</td>
  </tr>
  <tr>
    <td>Conformité</td>
    <td>Résidence liée à la région de l'organisation existante</td>
    <td>Flexibilité de sélection d'une région indépendante des organisations existantes</td>
  </tr>
  <tr>
    <td>Performances</td>
    <td>Meilleures performances pour les requêtes CRM locales</td>
    <td>Selon la connectivité de l'organisation partenaire, qu'elle soit de même région ou inter-régions avec les autres organisations</td>
  </tr>
  <tr>
    <td>Évolutivité future</td>
    <td>Fonctionne bien s'il est associé à Data Cloud One. Plus difficile de basculer plus tard si l'organisation incorrecte est choisie</td>
    <td>S'adapte facilement avec Data Cloud One. Conçu pour la neutralité.</td>
  </tr>
  <tr>
    <td>Coût</td>
    <td>Coût différentiel inférieur</td>
    <td>Augmentation des frais généraux liés à des environnements supplémentaires</td>
  </tr>
</table>

#### Recommandations

En règle générale, utilisez une organisation majeure existante comme organisation d'origine afin de limiter les efforts initiaux et d'accélérer l'adoption. Créez une organisation d'accueil dédiée uniquement si votre stratégie de gouvernance ou de conformité à long terme l'exige. La création d'une nouvelle organisation d'accueil dédiée est un choix courant pour les grandes entreprises disposant d'un Centre d'excellence (COE).

**Environnement d'organisation unique**

Provisionnez Data 360 dans votre organisation de production existante. Cela maximise la simplicité et la valeur immédiate. Il évite les coûts d'intégration inutiles.

**Environnement d'organisation multiple**

Préférez sélectionner l'une de vos principales organisations, généralement celle où la plupart de vos activités sont gérées, ou l'organisation qui sert de CRM centralisé, pour agir en tant qu'organisation d'origine. Cela réduit la complexité, réduit les tâches de configuration et permet de prendre rapidement conscience de la valeur de Data 360. L'utilisation d'une organisation majeure existante évite également les coûts et les efforts d'intégration liés à la gestion d'un nouvel environnement.

**Quand envisager une nouvelle organisation d'accueil dédiée**

La création d'une organisation d'accueil offre flexibilité et neutralité, mais avec un délai de réalisation de la valeur plus long dans ces cas.

- Si votre organisation a un solide Centre d'excellence (COE) et souhaite une gouvernance séparée des organisations des unités commerciales.
- Si aucune organisation existante ne convient en raison de contraintes de conformité ou d'organisation.

### Application d'une stratégie multi-organisations

#### Le défi multi-organisations

Les entreprises exploitent souvent plusieurs organisations Salesforce, et ce n'est pas un cas exceptionnel, mais la norme. En février 2024, environ 19 000 clients Salesforce exécutaient déjà plusieurs organisations Salesforce.

Pourquoi ça arrive ?

- **Acquisitions et fusions :** Les nouvelles sociétés acquises apportent leurs propres instances Salesforce.
- **Opérations régionales :** Organisations distinctes pour l'UE, l'Amérique du Nord, l'Asie-Pacifique, etc., souvent pour satisfaire aux lois sur la résidence des données.
- **Séparation fonctionnelle :** Différentes unités commerciales (par exemple, Banque de détail, Gestion de patrimoine, Assurance) maintiennent leurs propres organisations pour garantir leur autonomie.
- **Isolement réglementaire ou de sécurité :** Certains secteurs d'activité exigent des organisations logiquement distinctes pour des raisons de conformité.
- **Pour des raisons historiques ou techniques :** Au fil du temps, les clients accumulent organiquement plusieurs organisations.

Chaque raison est logique individuellement, mais ensemble, elles créent une fragmentation des données. Sans couche unificatrice, chaque organisation n'a qu'une vue partielle du client.

Le défi architectural : Comment unifier les données entre les organisations en une seule source de vérité tout en respectant les exigences de conformité, de gouvernance et d'autonomie ?

---

#### Data Cloud One

Data Cloud One est l'architecture de connectivité multi-organisations de Salesforce qui permet à plusieurs organisations Salesforce de partager une seule instance Data 360. Ce modèle est recommandé pour les entreprises qui ont plusieurs organisations Salesforce.

Dans n'importe quel cluster Data Cloud One, une organisation Salesforce est désignée comme organisation d'accueil, qui héberge l'instance Data 360. D'autres organisations Salesforce se connectent en tant qu'organisations compagnes, consommant les données et métadonnées unifiées de Data 360 de l'organisation d'origine.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies Data 360 DC One.png" alt="Diagramme montrant l&apos;architecture Data Cloud One" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Comment fonctionne Data Cloud One**

- **Ingestion et unification des données (organisation d'accueil)**

  - Toutes les configurations d'ingestion de données (Salesforce CRM, sources externes, streaming, batch) sont effectuées uniquement depuis l'organisation d'origine.

  - Le locataire Data 360 lié à l'organisation d'origine effectue la résolution de l'identité, harmonisation, modélisation et unification dans des profils clients de confiance.

  - L'administration de Data 360, les stratégies de gouvernance, le balisage et le masquage sont appliqués de façon centralisée depuis l'organisation d'origine.

- **Architecture d'espace de données**

  - Depuis l'organisation d'origine, les données sont organisées en espaces de données, qui agissent comme des conteneurs logiques pour les données, les métadonnées et les processus.

  - Les entreprises peuvent créer des espaces de données pour des marques, des régions ou des secteurs d'activité.

  - Partage d'espace de données : Depuis l'organisation d'origine, des espaces de données spécifiques sont partagés de façon sélective avec des organisations partenaires. Ainsi, seules les données pertinentes (et les métadonnées associées) sont transmises aux organisations appropriées.

- **Partage de métadonnées**

  Les organisations d'accompagnement reçoivent des définitions de métadonnées de l'organisation d'origine, notamment des objets modèle de données (DMO), un schéma de profil unifié, des connaissances calculées, des segments [et davantage](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5). Ils sont affichés nativement dans l'organisation associée comme s'ils étaient des actifs locaux, mais ils sont liés à l'organisation d'origine.

- **Capacités dans l’organisation d’accueil par rapport aux organisations compagnes**
  L'accès aux fonctionnalités diffère entre les organisations d'accueil et les organisations compagnes. Les organisations compagnes ne peuvent pas ingérer ou unifier des données, et dépendent de l'organisation d'origine pour l'ingestion, la modélisation et l'unification. Les organisations compagnes peuvent accéder aux données Data 360 pour piloter les fonctionnalités de plate-forme pilotées par Data 360, et créer des connaissances, des segments et des flux locaux en plus des données partagées et approuvées. Dans la vision future, ils peuvent également accéder aux fonctionnalités d'activation.

<table>
  <tr>
    <th>Capacité</th>
    <th>Organisation d'accueil</th>
    <th>Organisation compagne</th>
  </tr>
  <tr>
    <td>Connect Configurer des connecteurs, créer des flux de données, ingérer ou fédérer des données</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Harmoniser et unifier Élaborer et exécuter des transformations de données et la résolution de l'identité</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Sécurisez les données avec un espace de données et des autorisations</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Segmenter et prédire : créer des segments, obtenir des analyses et créer des modèles Einstein Studio</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Activer des activations Partout, des actions de données</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Fonctionnalités de la plate-forme : Générateur de répliques, flux, rapports, enrichissement, [et plus](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&amp;type=5)</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Fonctionnalités pilotées par Data 360 : Centre de prospection, fonctionnalités Sales et Service Cloud, Agentforce, et plus encore</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
</table>

- **Parité des fonctionnalités de plate-forme**
  Du point de vue des utilisateurs et des concepteurs, une fois les métadonnées partagées, il existe quelques différences fonctionnelles entre les organisations domestiques et les organisations partenaires en ce qui concerne l'utilisation des fonctionnalités de Salesforce Platform. La liste des fonctionnalités prises en charge est disponible dans Fonctionnalités [Data 360 dans](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) les organisations Companion.

  - Les fonctionnalités de la plate-forme Salesforce, telles que les flux, les rapports, le Générateur de répliques, les tableaux de bord et d'autres outils natifs de la plate-forme, fonctionnent dans les organisations d'origine et les organisations associées une fois les métadonnées disponibles.

  - Les fonctionnalités pilotées par Data 360, telles que Agentforce, Prospecting Center, Sales Cloud Einstein et Service Cloud AI, fonctionnent également de façon transparente dans l’organisation d’accueil et les organisations compagnes. Certaines fonctionnalités sont peut-être sur la voie de la compatibilité complète, mais l'objectif global est d'obtenir une parité de fonctionnalités entre les organisations domestiques et les organisations partenaires pour toutes les fonctionnalités inter-clouds qui dépendent de Data 360.

- **Modèle de consommation**
  Toutes les activités de l'organisation d'accompagnement (requêtes, exécutions de segments, flux déclenchés par Data 360, utilisation de l'IA, consignation Einstein Trust Layer, etc.) consomment des crédits Data 360 depuis l'organisation d'origine. Les flux de consommation sont unidirectionnels : les crédits sont centralisés, facturés et suivis par rapport à l'allocation de crédit de l'organisation d'origine. Vous pouvez toutefois examiner en détail le nombre de crédits utilisés par chaque organisation dans Digital Wallet.
- **Principe de conception : Construction horizontale**
  La construction horizontale dans Data 360 est un principe de conception de base, principalement implémenté via Data Cloud One, qui permet à une instance Data Cloud unique de couvrir plusieurs organisations Salesforce CRM distinctes. L'objectif est que chaque nouvelle fonctionnalité publiée fonctionne dans les organisations d'accueil et d'accompagnement sans configuration supplémentaire. Cette fonctionnalité garantit que Data Cloud One n'est pas seulement un choix d'architecture de données, mais un élément fondamental de la plate-forme Salesforce à l'avenir.

---

#### Décision : Organisations de données multiples vs. Data 360 partagée (Data Cloud One)

Les entreprises qui ont plusieurs organisations doivent choisir comment et où localiser Data 360 dans leur écosystème. Vous souhaitez provisionner des organisations Data 360 indépendantes dans chaque organisation ou utiliser Data Cloud One pour unifier les organisations sous une seule organisation d'origine ?

**Option A : Multiples organisations Data 360 indépendantes**

Chaque organisation Salesforce provisionne sa propre instance Data 360.

**Avantages :**

- **Autonomie :** Chaque unité commerciale ou région contrôle sa propre Data 360.

- **Simplicité dans chaque organisation :** La gouvernance, la sécurité et les personnalisations sont localisées.

- **Conformité réglementaire :** Utile lorsqu'une séparation réglementaire stricte est requise (par exemple, les données ne doivent pas traverser les frontières).

**Inconvénients :**

- **Silos de données :** Les profils unifiés ne peuvent pas être obtenus entre les organisations.

- **Coût plus élevé :** Chaque instance nécessite une licence, une administration et une intégration. Les clients finissent par ingérer plusieurs fois les mêmes données sources dans plusieurs organisations différentes.

- **Travail en double :** La résolution, la segmentation et l'enrichissement de l'identité doivent être répétés dans chaque instance Data 360.

**Option B : Une Data 360 partagée (cluster Data Cloud One)**

Une Data 360 unique est provisionnée dans une organisation d’accueil, avec d'autres organisations Salesforce connectées en tant qu'organisations compagnes.

**Avantages :**

- **Source unique de vérité (SSOT) :** Toutes les organisations partagent un modèle de données unifié.

- **Rentabilité :** Gérez une seule licence et infrastructure Data 360.

- **Gouvernance unifiée :** Politiques appliquées au niveau central, sécurité et contrôles de conformité.

- **Enrichissement inter-organisations :** Accédez à des profils, des insights et des segments harmonisés entre les organisations compagnes.

- **Préparation IA :** Un jeu de données d'entreprise permet d'améliorer l'entraînement et l'activation des modèles IA.

- **Pérennité :** L'ajout de nouvelles organisations compagnes est simple, car il n'est pas nécessaire de créer de nouvelles organisations Data 360.

**Inconvénients :**

- **Préparation supplémentaire :** Une Data 360 partagée nécessite de planifier la connectivité entre chaque org et l’organisation d’accueil.

- **Considérations relatives à la latence :** Les organisations compagnes de différentes régions peuvent afficher des requêtes plus lentes.

- **Gouvernance complexe :** Si chaque organisation a des besoins de personnalisation différents, une gouvernance précise peut s'avérer complexe.

**Option C : Multiples clusters Data Cloud One**

**Parfois**, la gouvernance, la conformité ou d'autres exigences métiers peuvent rendre difficile le regroupement de chaque organisation. Cela peut entraîner la nécessité d'implémenter une solution hybride dans laquelle l'entreprise exploite plusieurs organisations Data 360, chacune étant l'organisation d'origine d'un cluster d'organisations compagnes différent.

**Exemple :**

Une multinationale a des organisations Salesforce dans diverses régions, notamment en Europe, aux États-Unis et en Asie. Pour respecter les réglementations régionales sur la résidence des données, ils provisionnent une Data 360 pour chaque région séparée.

**Critères de décision**

<table>
  <tr>
    <th>Considérations</th>
    <th>Plusieurs organisations Data 360 indépendantes</th>
    <th>Un Data 360 partagé (Data Cloud One)</th>
  </tr>
  <tr>
    <td>Autonomie</td>
    <td>Grande autonomie pour chaque organisation ou unité commerciale</td>
    <td>Gouvernance centralisée, moins d'autonomie par organisation</td>
  </tr>
  <tr>
    <td>Conformité</td>
    <td>Utile lorsqu'une séparation stricte est requise (par exemple, lois régionales)</td>
    <td>Fonctionne mieux lorsque la résidence permet la centralisation</td>
  </tr>
  <tr>
    <td>Coût</td>
    <td>Augmentation des coûts de licence et d'administration</td>
    <td>Plus économique, une licence pour de nombreuses organisations</td>
  </tr>
  <tr>
    <td>Gouvernance</td>
    <td>Fragmenté ; les politiques diffèrent selon l'organisation</td>
    <td>Stratégies centralisées et cohérentes entre les organisations</td>
  </tr>
  <tr>
    <td>Silos de données</td>
    <td>Chaque organisation avec sa propre vue Aucune entreprise 360</td>
    <td>Jeu de données unifié, pas de duplication</td>
  </tr>
  <tr>
    <td>IA/Analytics</td>
    <td>Limité aux données de chaque organisation</td>
    <td>Modèles d'entreprise avec une meilleure précision</td>
  </tr>
  <tr>
    <td>Complexité</td>
    <td>Plus d'instances à gérer, plus d'intégrations</td>
    <td>Architecture plus simple, moins de pièces mobiles</td>
  </tr>
  <tr>
    <td>Performances</td>
    <td>Idéal pour les cas d'utilisation intra-organisation</td>
    <td>Augmentation potentielle de la latence avec l'accès à l'organisation partenaire</td>
  </tr>
</table>

---

#### Recommandations

**Modèle préféré : Data Cloud One**

Pour simplifier la gouvernance et optimiser les coûts entre les entreprises multi-organisations, utilisez une seule organisation domestique avec des organisations partenaires connectées.

**Quand utiliser plusieurs organisations Data 360 :** Utilisez plusieurs organisations Data 360 uniquement si la conformité, la résidence ou l'autonomie organisationnelle l'exige strictement (par exemple, si les opérations européennes doivent rester totalement séparées des opérations américaines en raison de la réglementation).

**Comment choisir l'organisation d'accueil dans Data Cloud One :** Commencez par prendre en compte l'une de vos principales organisations, généralement où la plupart des affaires sont gérées. Le provisionnement de Data 360 peut réduire la complexité et optimiser la valeur initiale.

Vous pouvez créer une organisation d'accueil dédiée gérée par une équipe Centre d’Excellence (COE), uniquement si aucune organisation existante ne convient.

**Principe général :**

Dans les environnements multi-organisations, limitez le nombre d'organisations Data 360. Favorisez Data Cloud One comme modèle par défaut pour réduire les doublons, activer la préparation à l’IA et simplifier la gouvernance.

### Partage de données entre des organisations Data 360

#### Nécessité du partage de données

Bien que Data Cloud One soit l'approche recommandée pour la plupart des entreprises, il existe des scénarios dans lesquels les clients doivent provisionner plusieurs instances Data 360, notamment :

- **Conformité régionale.** Un distributeur multinational provisionne un Data 360 dans l’UE et un autre aux États-Unis. Le partage de données entre instances Data 360 permet à l'entreprise de créer des connaissances à partir de données locales tout en partageant ces informations avec le siège social américain.
- **Collaboration d'unités commerciales.** Un conglomérat gère des organisations Data 360 distinctes pour le commerce de détail et l'assurance. Le partage de données entre les organisations Data 360 permet aux utilisateurs d'accéder à une source de données unique et faisant autorité sans déplacer ni copier. Avec le partage de données entre les organisations Data 360, l'organisation Assurance reçoit le segment « High-Value Customer » du commerce de détail pour des campagnes de vente croisée ciblées.
- **Fusions et acquisitions.** Une entreprise mère acquiert une filiale avec sa propre Data 360\. Avec deux instances à gérer, la conservation des silos de données à court terme préserve la sécurité des données et l'intégrité SSOT. Simultanément, le partage de données entre deux instances Data 360 permet une collaboration nécessaire pendant la transition.
- **Tableaux de bord exécutifs fédérés.** Une multinationale répartie sur plusieurs continents provisionne des organisations Data 360 individuelles par région. Les dirigeants souhaitent une vue de performance trimestrielle fédérée. Chaque Data 360 régionale partage des connaissances calculées agrégées avec une « organisation exécutive », qui permet la génération de rapports à l'échelle de l'entreprise.

#### Fonctionnement du partage de données

Lorsque plusieurs organisations Data 360 existent, l'unification entre elles n'est pas automatique. Le partage de données Data 360 vers Data 360 permet aux clients de partager des objets spécifiques entre des instances Data 360 sans duplication ni pipeline personnalisé. C'est un mécanisme de partage de métadonnées sans copie conçu pour la collaboration entre les organisations Data 360.

- Chaque Data 360 est provisionnée dans sa propre organisation d'accueil.

- Les administrateurs peuvent créer un partage de données, un regroupement d'objets spécifiques qu'ils souhaitent partager.

- L'accès aux données sélectionnées est partagé avec Data 360 d'une organisation cible, où les objets apparaissent comme définis localement. Seul l'accès est partagé, les données sous-jacentes restent dans la source Data 360.

- Les balises ne sont pas partagées. Seuls les objets bruts sont disponibles. L'organisation cible doit réappliquer les balises de gouvernance, opérationnelles ou IA si nécessaire.

#### Principales différences par rapport à Data Cloud One :

- Dans Data Cloud One, plusieurs organisations partenaires partagent une seule instance Data 360. Pour plus de cohérence, les fonctionnalités de la plate-forme, telles que Agentforce, Centre de prospection et Tableau Next, sont exécutées sur les mêmes données sous-jacentes.

- Lors de l'utilisation du partage de données entre les organisations Data 360, chaque organisation possède sa propre Data 360\. Des fonctionnalités comme Agentforce dans l'organisation A et l'organisation B fonctionnent chacune indépendamment sur leur instance locale. Aucun partage n'est automatiquement effectué. Des partages de données délibérés doivent être créés pour collaborer uniquement sur des objets spécifiques.

#### Avantages et inconvénients du partage de données entre des organisations Data 360

<table>
  <tr>
    <th>Facteur</th>
    <th>Avantages</th>
    <th>Points négatifs</th>
  </tr>
  <tr>
    <td>Résidence des données</td>
    <td>Prend en charge la séparation régionale tout en permettant la collaboration.</td>
    <td>Ne supprime pas la nécessité de gérer plusieurs Data 360 orgs.</td>
  </tr>
  <tr>
    <td>Duplication des données</td>
    <td>Zéro copie ; pas de duplication d'objets.</td>
    <td>Nécessite une sélection délibérée d'objets à inclure dans chaque partage de données.</td>
  </tr>
  <tr>
    <td>Gouvernance</td>
    <td>Le partage est explicite et délibéré (au niveau de l'objet).</td>
    <td>Aucun flux de balises ou de politiques ; l'organisation cible doit réappliquer la gouvernance.</td>
  </tr>
  <tr>
    <td>Complexité</td>
    <td>Permet la collaboration sélective sans centralisation.</td>
    <td>Nécessite la gestion de plusieurs organisations Data 360 et partages de données.</td>
  </tr>
  <tr>
    <td>**IA/Analytics**</td>
    <td>IA/analytics régionales possibles ; les insights peuvent être partagés entre les orgs.</td>
    <td>Aucune IA d'entreprise, sauf si les données sont délibérément partagées.</td>
  </tr>
  <tr>
    <td>**Fonctionnalités de la plate-forme**</td>
    <td>Les fonctionnalités alimentées par Data 360 de chaque org fonctionnent indépendamment.</td>
    <td>Aucun partage automatique. Risque de duplication s'il n'est pas soigneusement conçu.</td>
  </tr>
  <tr>
    <td>Coût</td>
    <td>Peut réduire le besoin de pipelines ETL.</td>
    <td>Engendre toujours le coût de plusieurs Data 360 orgs. Consomme des crédits pour les requêtes de données et le partage de données.</td>
  </tr>
</table>

#### Critères de décision

<table>
  <tr>
    <th>Considérations</th>
    <th>Data Cloud One (préféré pour les multi-orgs)</th>
    <th>Partage de données entre des organisations Data 360</th>
  </tr>
  <tr>
    <td>Source unique de vérité</td>
    <td>Oui : toutes les organisations partagent un modèle de données.</td>
    <td>Non : chaque Data 360 a son propre modèle de données.</td>
  </tr>
  <tr>
    <td>Conformité</td>
    <td>Fonctionne uniquement lorsque la résidence permet la centralisation.</td>
    <td>Nécessaire lorsque les lois sur la résidence empêchent la centralisation.</td>
  </tr>
  <tr>
    <td>Gouvernance</td>
    <td>Centralisé, cohérent.</td>
    <td>Fédéré ; partages délibérés au niveau de l'objet.</td>
  </tr>
  <tr>
    <td>Complexité</td>
    <td>Moins de pièces mobiles, plus simple.</td>
    <td>Plus complexe : nécessite des partages de données de configuration et plusieurs organisations Data.</td>
  </tr>
  <tr>
    <td>IA/Analytics</td>
    <td>Modèles d'IA d'entreprise.</td>
    <td>IA régionale. Partager sélectivement des insights.</td>
  </tr>
  <tr>
    <td>Fonctionnalités de la plate-forme</td>
    <td>Un Data 360 partagé signifie que toutes les fonctionnalités fonctionnent de façon cohérente entre l'organisation d'accueil et les organisations partenaires.</td>
    <td>Les fonctionnalités sont exécutées indépendamment dans chaque Data 360. Le partage doit être explicite.</td>
  </tr>
</table>

#### Recommandations

**Si votre entreprise possède plusieurs organisations Data 360**

- Utilisez le partage de données entre les organisations Data 360 pour collaborer entre elles plutôt que d'élaborer des pipelines personnalisés ou de dupliquer des données.

- Partagez des objets spécifiques (DMO, connaissances calculées, segments) en créant des partages de données et en les accordant à des organisations cibles.

- Les balises ne sont pas partagées, l'organisation destinataire doit réappliquer les balises, pour la gouvernance, la classification ou l'enrichissement IA.

**Utilisation du partage de données entre les organisations Data 360**

- Pour satisfaire aux exigences réglementaires qui empêchent la centralisation.

- Pour maintenir l'autonomie des unités commerciales tout en permettant une collaboration sélective.

- Pour fournir des tableaux de bord exécutifs fédérés à travers plusieurs régions.

- Pour rapprocher les scénarios de fusions-acquisitions dans lesquels la consolidation n'est pas immédiatement possible.

**Concevez avec soin**

Traitez le partage de données Data 360 vers Data 360 comme une stratégie de fédération, pas comme un remplacement de Data Cloud One.

- Utilisez le partage spécifique à un objet.
- Évitez le partage excessif.
- Adaptez les partages de données aux besoins métiers et de conformité.

#### Mémoriser

La planification de votre stratégie de données pour le provisionnement Data 360 est une décision architecturale critique à long terme qui doit être abordée à l'échelle de l'entreprise, pas organisation par organisation. Ce choix stratégique précoce détermine comment les données des clients sont unifiées, comment la gouvernance est appliquée et comment les fonctionnalités essentielles de la plate-forme, en particulier l'IA et les analytiques, évoluent dans l'ensemble de l'organisation. Planifiez à l'avance des modèles de gouvernance et d'appropriation et évitez les raccourcis à court terme qui entraînent une fragmentation et une complexité accrues.

## Ressources

[Qu'est-ce que Customer 360 ?](https://www.salesforce.com/products/what-is-customer-360/)

[Schémas et pratiques d'intégration Data 360](/docs/architect/fr-fr/fundamentals/guide/data360_integration_patterns_and_practices)

[Architecture Data 360](/docs/architect/fr-fr/fundamentals/guide/data-360-architecture)

[Architecture de sécurité Data 360](/docs/architect/fr-fr/fundamentals/guide/data360_security_architecture)

**À propos des auteurs**

Kunal Goyal est directeur de la gestion des produits chez Salesforce. Il s’attache à faire progresser l’architecture multi-organisations et l’évolutivité dans Data 360\. Depuis 2017, il dirige de multiples initiatives et produits axés sur la collaboration inter-organisations et la conception de systèmes multi-locataires. Kunal est l'un des responsables de l'architecture des meilleures pratiques Data 360 et le product owner de Data Cloud One, en charge des expériences de configuration, de provisionnement et d'administration.

Erin Wagner Tidwell est une rédactrice technique principale et conceptrice de contenu pour Data 360\. Elle travaille chez Salesforce depuis 2013\. Elle s’attache à faciliter la compréhension et l’utilisation de Data 360 grâce à une documentation technique claire, cohérente et précise et à la communication dans l’application.

Yugandhar Bora est architecte en génie logiciel chez Salesforce, spécialisé dans l'architecture de données sur la plate-forme Data and Intelligence Applications. Il dirige les initiatives du comité d'examen de l'architecture d'entreprise (EARB) axées sur la gouvernance des données et les modèles de données unifiés, tout en contribuant aux solutions de provisionnement de plate-forme automatisé.

Samarpan Jain est architecte principal chez Salesforce spécialisé dans Commerce Cloud, l'intégration de plate-forme et l'architecture inter-organisations. L'un des employés les plus anciens de Salesforce, il dirige des initiatives clés, notamment la conformité de la résidence des données pour les clients gouvernementaux et les systèmes d'attribution d'utilisation Data 360.

<!-- document id=5cf779efa1eee9bf24e83b976d7c17c88d9b7f6d5de6a5b0ea03e7c7cab4834c url=/architect/current/fr-fr/decision-guides/guides/async-processing.md -->

# Traitement asynchrone

Utilisez ce guide pour choisir l'approche de traitement asynchrone Salesforce adaptée à chaque cas d'utilisation.

## Présentation du guide

Ce guide vous aidera à évaluer l'approche adaptée à vos besoins en traitement asynchrone sur Salesforce Platform. Il explique chaque approche, en détaillant les forces et les limitations de chacune. La plupart des approches sont alignées sur une fonctionnalité produit, mais certaines utilisent plusieurs fonctionnalités en coordination. Le guide inclut des cas d'utilisation pour souligner quand utiliser chaque approche.

Le traitement asynchrone offre deux avantages majeurs pour votre architecture. Premièrement, il augmente l'évolutivité, car les processus asynchrones ont des limites de gouverneur plus élevées. Deuxièmement, les requêtes asynchrones sont exécutées dans leurs propres threads afin de permettre aux utilisateurs d'effectuer d'autres tâches pendant que les tâches asynchrones sont exécutées en arrière-plan.

Notez que ce guide se concentre exclusivement sur le choix d'une technologie de traitement asynchrone dans Salesforce Platform. La [section Ressources](#ressources) répertorie d'autres ressources qui facilitent votre processus de décision.

## Produits visés par ce guide

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Lightning Platform</a> est une plate-forme complète pilotée par l'IA qui unifie les employés, les agents IA autonomes, les données de l'entreprise et les applications dans un système unique et de confiance afin d'améliorer la productivité et l'expérience client. Il permet la création d'une "entreprise agentique" en connectant les applications Customer 360, Data Cloud, et Slack pour une automatisation de bout en bout.</td>
    </tr>
  </tbody>
</table>

Ce document ne couvre pas les technologies d'autres écosystèmes tels que MuleSoft, Informatica, Commerce Cloud, Tableau et Marketing Cloud.

## Points à retenir

- **Avant d'utiliser le traitement asynchrone, assurez-vous que vos cas d'utilisation correspondent au modèle.** Les modèles asynchrones n'ont pas de contrat de niveau de service, sont soumis à plusieurs mécanismes de gouverneur, peuvent avoir des limites de capacité définies en fonction de la licence et peuvent entraîner des retards de traitement en raison de la nature limitée des ressources allouées à l'infrastructure asynchrone dans Salesforce Platform. Tenez compte des limitations ci-dessous lors de l'utilisation d'un traitement asynchrone dans des scénarios où un utilisateur demande une réponse du système avant de pouvoir poursuivre son travail.
- **Le traitement asynchrone avec Salesforce n'est pas une solution pour des besoins d'évolutivité illimités.** La plateforme Salesforce ne s'étend pas à l'infini, et les modèles asynchrones sont soumis à des limitations. Le traitement asynchrone utilise des threads, qui contiennent les informations contextuelles dont un processeur a besoin pour exécuter un flux d'instructions. Les threads peuvent être exécutés en parallèle. Le nombre de threads disponibles dans un processeur est limité. Par conséquent, la plate-forme a mis en place des mécanismes pour utiliser ses threads disponibles aussi efficacement que possible. Le [mécanisme de contrôle](/docs/architect/fr-fr/fundamentals/guide/async-fundamentals#contrôle-de-flux) de flux de la plate-forme empêche les organisations de consommer trop de threads et d'affecter négativement les autres organisations. L'[algorithme d'utilisation équitable](/docs/architect/fr-fr/fundamentals/guide/async-fundamentals#utilisation-équitable) de la plate-forme contrôle également le nombre de threads disponibles pour chaque type de message.
- **Compte tenu des événements qui peuvent entraîner des charges extrêmes.** Lorsque vous concevez des processus asynchrones, assurez-vous qu'ils peuvent gérer de façon prévisible les pics de charge de travail et les accalmies. Examinez comment votre implémentation gère les événements inattendus, tels que les pannes de courant, et concevez des mesures de protection qui atténuent la perte de données ou la perte de fonctionnalité.

## Comparaison des produits

Le tableau ci-dessous présente les outils disponibles pour le traitement asynchrone avec Salesforce. Consultez ce tableau pour examiner les principales caractéristiques de chaque outil pendant votre processus de prise de décision. Consultez [Cas d'utilisation](#cas-dutilisation) et [Points de décision](#points-de-décision) pour choisir les outils adaptés à votre architecture.

<table style="border-color:white;overflow-x:scroll;">
  <thead>
    <tr>
      <th>Approche</th>
      <th>Description</th>
      <th>Compétences requises</th>
      <th>Licences et limites</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Queueable Apex</b></td>
      <td>Utilisé pour les processus qui impliquent de longues opérations de base de données ou des appels externes de service Web. Apex Queueable offre des fonctionnalités telles que les ID de tâche, la prise en charge des types non primitifs et l'enchaînement des tâches.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Le nombre de licences peut augmenter les limites.</a></td>
    </tr>
    <tr>
      <td><b>Batch Apex</b></td>
      <td>Élaborez des processus complexes et longs qui impliquent des millions d'enregistrements en divisant votre ensemble d'enregistrements et en le traitant en segments gérables.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Le nombre de licences peut augmenter les limites.</a></td>
    </tr>
    <tr>
      <td><b>Apex planifié</b></td>
      <td>Exécutez Apex à une heure planifiée définie par une expression cron. Bien que l'action de planifier Apex via l'expression cron soit un processus asynchrone, le code sous-jacent est exécuté de façon synchrone au démarrage de la tâche.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">Le nombre de licences peut augmenter les limites.</a></td>
    </tr>
    <tr>
      <td><b>Apex Continuation Callouts</b></td>
      <td>Exécutez des appels externes à partir de méthodes Apex exécutées dans un contexte de transaction synchrone.</td>
      <td>Pro-code</td>
      <td>Non</td>
    </tr>
    <tr>
      <td><b>Chemin asynchrone (flux déclenchés par un enregistrement)</b></td>
      <td>Exécutez une opération que vous souhaitez lancer en différé. Évitez les erreurs DML mixtes qui se produisent lorsque vous mettez à jour une valeur dans un enregistrement associé qui ne fait pas partie de l'enregistrement ayant déclenché un flux.</td>
      <td>Code faible</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Le nombre et le type de licences peuvent augmenter les limitations.</a></td>
    </tr>
    <tr>
      <td><b>Parcours planifié (Flux après commit)</b></td>
      <td>Exécutez à une heure planifiée dynamiquement après un événement déclenchant, par exemple lors de la création, de la mise à jour ou de la suppression d'un enregistrement.</td>
      <td>Code faible</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Le nombre et le type de licences peuvent augmenter les limitations.</a></td>
    </tr>
    <tr>
      <td><b>Flux planifiés</b></td>
      <td>Exécutez un flux en arrière-plan à une heure spécifiée et à une fréquence répétée (quotidienne, hebdomadaire ou unique) pour exécuter des actions sur un lot d'enregistrements.</td>
      <td>Code faible</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">Le nombre et le type de licences peuvent augmenter les limitations.</a></td>
    </tr>
    <tr>
      <td><b>Déclencheurs d'événements de plate-forme</b></td>
      <td>Couplez librement Salesforce à des systèmes externes et communiquez entre des composants asynchrones dans Salesforce Platform.</td>
      <td>Low-code + Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm">Une licence complémentaire est requise pour les cas d'utilisation d'événements de plate-forme à haut volume</a></td>
    </tr>
    <tr>
      <td><b>Capture des modifications de données</b></td>
      <td>Capturez et traitez les événements de modification de façon asynchrone une fois la transaction de base de données engagée.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm">Une licence complémentaire est requise pour dépasser l'allocation de référence.</a></td>
    </tr>
    <tr>
      <td><b>API Bulk</b></td>
      <td>Insérez, mettez à jour, effectuez un upsert, interrogez ou supprimez de nombreux enregistrements de façon asynchrone, puis traitez les résultats ultérieurement.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.260.0.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_bulkapi.htm">Il y a des limites.</a></td>
    </tr>
    <tr>
      <td><b>Actions Lightning</b></td>
      <td>Autorisez les pages Lightning à interagir avec le serveur sans forcer les utilisateurs à actualiser entièrement la page.</td>
      <td>Code faible</td>
      <td>Non</td>
    </tr>
  </tbody>
</table>

## Points de décision

Le tableau ci-dessous présente une vue d'ensemble des points à prendre en compte lorsque vous choisissez l'outil asynchrone à utiliser.

<table>
  <tbody>
    <tr>
      <td><b>Compétences requises</b></td>
      <td>Certains outils décrits dans ce guide nécessitent un code, tandis que d'autres peuvent être configurés par déclaration. En examinant vos options, tenez compte des compétences des membres de votre équipe. Notez que même si des développeurs sont disponibles pour votre implémentation initiale (par l'intermédiaire d'un partenaire d'implémentation, par exemple), il peut être nécessaire de modifier vos solutions à l'avenir. Si votre équipe de maintenance n'a pas de développeur, une option Low-code peut être plus adaptée.</td>
    </tr>
    <tr>
      <td><b>Type de limites de plate-forme appliquées</b></td>
      <td>Déterminez le type de <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">limite</a> qui s'applique à l'exécution. En concevant vos solutions, réfléchissez attentivement à la façon dont le volume et la fréquence des transactions seront pris en compte dans les limites du gouverneur pour l'approche choisie chaque jour. Calculez le nombre d'exécutions qui auront lieu chaque jour. Assurez-vous que les valeurs calculées respectent les limites associées aux outils que vous avez sélectionnés.</td>
    </tr>
    <tr>
      <td><b>Latence</b></td>
      <td>Déterminez la vitesse à laquelle les résultats du traitement seront disponibles sur la plate-forme. Pour certaines approches, les changements seront presque immédiats, alors que pour d'autres, ils peuvent prendre quelques minutes ou quelques heures.</td>
    </tr>
  </tbody>
</table>

## Cas d'utilisation

Lorsque vous sélectionnez un outil pour le traitement asynchrone, commencez par évaluer les besoins de votre organisation et les ressources disponibles. Votre objectif est de sélectionner le ou les outils qui réduisent les coûts d'implémentation et de maintenance, tout en garantissant l'évolutivité et en limitant la probabilité d'infractions aux limites. Cet objectif dépend des considérations techniques exposées précédemment, ainsi que de la composition de votre équipe.

Prenons l'exemple d'un processus de commande asynchrone dans Salesforce. Lorsqu'une commande est enregistrée, elle déclenche un message à un système de gestion d'entrepôt externe avec des instructions spéciales pour emballer et expédier un article. L'utilisateur qui passe la commande n'a pas besoin d'une réponse immédiate du système de gestion de l'entrepôt. Par conséquent, la demande peut être envoyée de façon asynchrone. Le traitement asynchrone permet à l'utilisateur de poursuivre son travail sans attendre une réponse.

Pour ce cas d'utilisation, vous pouvez envisager d'implémenter avec Apex . Cette approche ne fonctionnera que si vous avez dans votre équipe des développeurs Apex capables de maintenir votre solution pro-code. Sinon, une approche déclarative est plus logique. Notez également que différents ensembles de [limites](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) s'appliquent à différents outils.

Le tableau ci-dessous répertorie les cas d'utilisation courants dans la colonne la plus à gauche, suivis d'une description. La colonne _Premier choix_ fournit l'approche la plus typique utilisée pour satisfaire un tel cas d'utilisation, ainsi que la justification de l'approche Premier choix. Utilisez-le comme point de départ de votre analyse. L'approche Premier choix peut avoir des limitations qui ne fonctionneront pas pour votre cas d'utilisation.

<table>
  <thead>
    <tr>
      <th>Cas d'utilisation</th>
      <th>Description</th>
      <th>Approche de premier choix</th>
      <th>Justification</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Traitement par lot hautement performant</b></td>
      <td>Toute automatisation qui doit traiter efficacement des milliers ou des millions d'enregistrements</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex fournit des API riches pour interfacer avec la plate-forme et pour la vitesse brute.</td>
    </tr>
    <tr>
      <td><b>Tâche de nettoyage des données</b></td>
      <td>Une tâche exécutée régulièrement, ou à la demande, qui nettoie les données. Par exemple, la déduplication, la vérification de l'adresse ou la consolidation des données.</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex fournit des API riches pour interfacer avec la plate-forme et pour la vitesse brute.</td>
    </tr>
    <tr>
      <td><b>Tâche de cumul nocturne</b></td>
      <td>Tâche qui calcule les données de cumul à la fin d'un jour ouvrable.</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex fournit des API riches pour interfacer avec la plate-forme et pour la vitesse brute.</td>
    </tr>
    <tr>
      <td><b>Logique déclenchée par un enregistrement</b></td>
      <td>Exécutez une logique en réponse à une mise à jour d'enregistrement.</td>
      <td><i>Varie</i></td>
      <td>Consultez notre guide de décision complémentaire, <a href="/docs/architect/fr-fr/decision-guides/guide/record-triggered">Automatisation des événements déclenchés par un enregistrement</a>. Il inclut un arbre de décision pour les cas d'utilisation asynchrones, notamment Queueable Apex, Batch Apex, Scheduled Apex, Flux planifié, Flux de chemin asynchrone et Change Data Capture.</td>
    </tr>
    <tr>
      <td><b>Mises à jour en cascade via un graphe d'objets</b></td>
      <td>Permet d'exécuter rapidement l'action d'enregistrement d'un utilisateur, en reportant l'exécution asynchrone des mises à jour en cascade d'autres objets.</td>
      <td>Queueable <b>Apex</b></td>
      <td>Apex Queueable dispose de puissantes fonctionnalités d'enchaînement qui permettent à la logique de diviser une chaîne de mises à jour en une série de transactions asynchrones.</td>
    </tr>
    <tr>
      <td><b>Traitement planifié spécifique à l'enregistrement</b></td>
      <td>Automatisation à une date future et dynamique spécifique à l'enregistrement (par exemple, 3 jours avant une date de fermeture).</td>
      <td><b>Flux</b> avec un parcours planifié</td>
      <td>Les parcours planifiés offrent une force unique à Flux, car la plate-forme gère automatiquement la planification, l'annulation et la replanification de ces parcours si les données de l'enregistrement changent.</td>
    </tr>
    <tr>
      <td><b>Invocation parallèle de plusieurs services externes lents</b></td>
      <td>Lors d'une exécution synchrone, plusieurs services externes sont invoqués en parallèle pour optimiser le temps d'exécution global.</td>
      <td><b>Apex</b> Continuation Callouts</td>
      <td>L'autorisation d'exécution simultanée de plusieurs appels externes lents réduit le temps total nécessaire pour réaliser le travail.</td>
    </tr>
    <tr>
      <td><b>Migration des données d'enregistrements à partir d'un système externe</b></td>
      <td>Déplacez de grandes quantités d'enregistrements vers Salesforce Platform à partir d'un système externe. Un processus unique ou planifié régulièrement.</td>
      <td><b>Bulk</b> <b>API</b></td>
      <td>Il s'agit de l'approche la plus efficace et la plus conviviale pour la migration des données.</td>
    </tr>
    <tr>
      <td><b>Exécution d'une logique supplémentaire sur un système externe</b></td>
      <td>Modèle de notification par oubli d'un système externe d'un événement sur la plate-forme, puis permettant à ce système de traiter l'événement de façon asynchrone.</td>
      <td><b>Événements de plateforme</b> ou <b>Change Data Capture</b></td>
      <td>Un modèle pub-sub fonctionne mieux ici et permet au système externe de traiter l'événement lorsqu'il est prêt. Pour plus d'informations sur ce schéma, consultez <a href="/docs/architect/fr-fr/decision-guides/guide/event-driven">Architecture pilotée par les événements</a>.</td>
    </tr>
  </tbody>
</table>

Le tableau Cas d'utilisation indique l'approche la plus adaptée à chaque cas d'utilisation. Cependant, vous devez vérifier si la technologie First Choice répond aux besoins spécifiques de votre cas d'utilisation. Déterminez notamment si l'approche choisie peut respecter les limites de gouvernance de votre org.

Lorsque vous avez identifié une approche candidate pour votre cas d'utilisation, le [guide Asynchronous Processing Basics Guide](/docs/architect/fr-fr/fundamentals/guide/async-fundamentals) peut vous aider à vérifier entièrement la solution.

## Ressources

Les ressources supplémentaires suivantes peuvent vous aider à prendre des décisions :

- Explorez en profondeur chacune des technologies asynchrones de la plate-forme : [Notions fondamentales du traitement asynchrone](/docs/architect/fr-fr/fundamentals/guide/async-fundamentals)
- Choisir entre Apex et Flow pour les déclencheurs d'enregistrement : [Automatisation des événements déclenchés par un enregistrement](/docs/architect/fr-fr/decision-guides/guide/record-triggered)
- Informations sur les modèles d'intégration asynchrone : [Architecture pilotée par les événements](/docs/architect/fr-fr/decision-guides/guide/event-driven)