--- schema_version: "1" id: 8f78be221c6d3bde881cf660cdbe4366f9cdc242f48d696fae4d70334adb5642 title: Data 360 Document AI collection: architect version: current locale: fr-fr portal_url: https://docs.salesforce.com/architect/current/fr-fr/fundamentals/guides/data360-document-ai.md canonical_url: https://architect.salesforce.com/docs/architect/fr-fr/fundamentals/guide/data360-document-ai.html source_site: architect.salesforce.com content_type: documentation content_hash: 8d993318618a81a441a041b462cad6fb710195a93377fbc6d90c67f531223013 products: - Fondamentaux - Architect Site Content Repo updated_at: 2026-07-01T00:00:00Z --- ## Vue d'ensemble Les entreprises gèrent un large éventail de types de document, notamment des factures, des bons de commande, des contrats juridiques et des manuels techniques. Le traitement manuel est lent, source d’erreurs et consomme de 15 à 25 % du temps des employés. Les approches d'automatisation antérieures (par exemple, l'_automatisation robotisée des processus_, la _reconnaissance optique des caractères_ et les outils de workflow) ont réduit une partie du fardeau, mais ont produit des pipelines rigides, des frais généraux de maintenance élevés et une adoption cloisonnée entre les équipes commerciales individuelles. Les documents contiennent un contexte structurel enrichi (par exemple, des hiérarchies de tableaux, des relations de champ spatial et des sections référencées) que le traitement de texte plat ne peut pas conserver. Le retrait d'un document en texte brut ignore le contexte métier qui rend l'extraction précise et utile, ce qui dégrade la qualité des analytiques en aval, de l'inférence en _intelligence artificielle (IA)_ et de l'automatisation des processus. Pour être efficaces, les systèmes de traitement _intelligent des documents_ doivent classer les documents par type, extraire des données structurées avec précision à partir de présentations de variables et livrer ces données sous une forme régie et interrogeable aux systèmes en aval. Les systèmes IDP doivent également gérer la variabilité des documents à grande échelle sans configuration par modèle pour chaque nouveau format de document, et ils doivent être centralisés et accessibles au sein des unités commerciales. À ce défi s'ajoute l'ampleur de la question clé : Les données non structurées représentent environ 80 % de toutes les données de l'entreprise, et la majorité s'accumule sous forme de document dans les systèmes de fichiers, le stockage Cloud et les référentiels de contenus qui sont hors de portée des systèmes _CRM (Customer Relationship Management)_, des agents IA et des plates-formes d'analyse. _Data 360 Document AI_ est la capacité de traitement des documents Salesforce dans _Data 360_, conçue pour combler cette lacune. Il extrait, classe et analyse les contenus de documents non structurés et semi-structurés en utilisant des _grands modèles de langage_, la _reconnaissance optique des caractères_, le _traitement du langage naturel_ et l'_apprentissage machine_. La sortie est composée de données structurées, régies et interrogeables qui s'intègrent dans le pipeline _Data 360_ où les agents _Agentforce_, les outils d'analyse et les workflows d'automatisation peuvent y accéder via des interfaces standard sans nécessiter de couches d'extraction ou de transformation personnalisées. ## Pourquoi Documenter l’IA est important ? Les plates-formes de données d'entreprise traitent des données structurées et tabulaires. Cependant, la majorité des données d'entreprise sont envoyées sous forme de documents et restent inaccessibles aux CRM, aux ERP, aux agents IA et aux pipelines d'analyse jusqu'à ce qu'une personne les extraie manuellement. Il s'agit d'une lacune architecturale, pas d'un problème de workflow. ### Limitations de l'extraction basée sur des règles Les approches antérieures combinaient la re-saisie manuelle, l'OCR basée sur des règles et les scripts RPA. Ces méthodes fonctionnaient à petite échelle, mais elles ne pouvaient pas gérer le volume, la variété et la rapidité des types de documents générés par les entreprises modernes. Les outils basés sur des règles nécessitent des modèles explicites par variante de présentation. Tout changement de format rompt l'extraction et nécessite un développeur, un nouveau modèle et un cycle de déploiement. À l'échelle, cela produit des solutions ponctuelles fragiles sans gouvernance centralisée, schéma partagé et chemin vers la préparation à l’IA. Les pipelines d'extraction incohérents se propagent en aval. En d’autres termes, les analytiques héritent d’incohérences dans les données, les modèles d’IA produisent des résultats peu fiables et les contenus réglementés tels que les _informations de santé_ et les _informations d’identification personnelle_ manquent de gouvernance systématique. ### Traitement des documents natif à l’IA Les LLM extraient les champs sans modèle explicite. Une configuration de schéma unique régit l'extraction à travers les variantes de présentation, les langues et les formats, qui s'adapte au document plutôt que d'exiger qu'il respecte une structure fixe. Le traitement des documents passe ainsi d'une opération cloisonnée lourde en maintenance à une capacité centralisée et gouvernée. ![Vue d'ensemble de Data 360 Document AI montrant comment les pipelines par lot et transactionnels transforment des documents non structurés en données gouvernées et interrogeables](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-overview.png) _Data 360 Document AI_ opérationnalise le traitement des documents sur la plate-forme _Data 360_ via deux pipelines. - L ' _oléoduc par lot_ achemine les données extraites par ingestion, résolution de l ' identité, connaissances calculées, activations, analytiques et activation Agentforce. - Le _pipeline de traitement_ des transactions expose une API REST qui renvoie _un JSON_ structuré de façon synchrone, ce qui permet aux architectes d'acheminer les données dérivées de documents vers des _SObjects_ Salesforce, le pipeline _Data 360 Data Lake Object_/_Data Model Object (DLO/DMO)_ ou des bases de données et des entrepôts externes sans configuration par lot. Dans les deux cas, les données extraites entrent dans un modèle gouverné piloté par le schéma plutôt que dans un ensemble fragmenté d'outils ponctuels. ## Produit concerné [Data 360 Document AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) est la capacité native de Salesforce _Intelligent Document Processing (IDP)_ au sein de la plate-forme _Data 360_. Il convertit les contenus de documents non structurés et semi-structurés en données régies et interrogeables qui participent pleinement au cycle de vie complet de _Data 360_. ## Qu'est-ce que l’IA documentaire Data 360 Document AI ? [Data 360 Document AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) est la capacité native de Salesforce _Intelligent Document Processing (IDP)_ dans _Data 360_. Il ingère des documents non structurés et semi-structurés, extrait des données structurées en utilisant une configuration de schéma déclaratif, et livre ces données au pipeline _Data 360_ pour harmonisation, résolution de l'identité, analytiques et activation Agentforce. Data 360 Document AI prend en charge deux modalités de traitement: - **Traitement par lots:** Traite les grands ensembles de documents définis dans les _objets modèle de données non structurés (UDMO)_ en fonction de l'événement. - **Traitement transactionnela:** Traite un document unique via l'API REST et renvoie une charge utile _JSON_ structurée de façon synchrone. Les architectes peuvent ensuite acheminer cette charge utile vers le pipeline d'objet lac de données/objet modèle de données _Data 360_, _les objets SObject_ Salesforce, ou des bases de données et des entrepôts externes via _MuleSoft_, des appels _Apex_ ou des pipelines _ETL (Einstein Trust Layer)_. Le niveau cible est une décision architecturale pilotée par les exigences de latence, de gouvernance et de résidence des données. Document AI prend actuellement en charge les fichiers PDF, les fichiers image (JPEG, PNG) et les documents manuscrits. ## Composants principaux _Data 360 Document AI_ assemble quatre technologies de traitement dans un pipeline régi unique. Chaque composant gère une étape distincte du cycle de vie de document à données : - **Reconnaissance optique des caractères (OCR):** Convertit les images scannées, les contenus manuscrits et les fichiers PDF basés sur l'image en texte lisible par machine avant le traitement LLM. Un minimum de 150 DPI est recommandé pour une extraction fiable. - **Grands modèles de langage (LLMs):** Acheminer l ' extraction via la passerelle _Einstein_ LLM en utilisant le modèle choisi par l ' utilisateur. Le LLM reçoit la sortie OCR avec la configuration du schéma _JSON_ et renvoie une charge utile d'extraction structurée. _Gemini_ et d ' autres modèles sont prévus pour une mise en œuvre ultérieure. - **Traitement du langage naturel (NLP) :** Effectue la compréhension contextuelle, la reconnaissance d'entités, l'analyse de dates et l'extraction de champs sémantiques directement dans le grand livre via l'ingénierie des invites structurées (l'invite définie par le schéma et la sortie OCR servent d'entrées uniques). Toutes les interactions LLM sont acheminées via l'ETL, qui applique une rétention de données nulle avec les fournisseurs de modèle et masque les _informations d'identification_ personnelle dans les entrées textuelles avant qu'elles atteignent le modèle. Aucun moteur NLP séparé n'est utilisé. - **Traitement multimodal :** Traite les images incorporées dans des fichiers PDF en tant qu'entrées d'extraction séparées, ce qui permet au grand livre d'extraire des données de diagrammes, de tableaux restitués par des images et de pages à contenu mixte que l'OCR seul ne peut pas analyser. En plus des quatre technologies de traitement, _l’IA Document_ gère également : - **Einstein Trust Layer :** Achemine toutes les interactions LLM via l'ETL, qui applique une rétention de données nulle avec les fournisseurs de modèle et masque les _PII_ avant que les entrées n'atteignent le LLM, à l'exception des données multimodales (par exemple, les documents joints qui sont traités via _l'IA Document_) où le masquage des PII n'est pas actuellement pris en charge et les données sont envoyées telles quelles à des modèles externes. L'ETL régit uniquement le chemin d'interaction LLM. Les données extraites qui sont écrites dans des _objets lac de données_ sont stockées en l'état. Le masquage au niveau du champ au repos doit être traité par des contrôles de gouvernance des données en aval. - **Limites de taille de fichier :** _Document AI_ traite les fichiers jusqu'à 10 Mo par requête. Les limites en longueur du contexte du grand livre peuvent limiter davantage le traitement des documents denses de plusieurs pages à l'intérieur de cette limite. ## Principes architecturaux clés Les architectes d'entreprise qui déploient _Data 360 Document AI_ doivent appliquer ces principes avant de s'engager dans une conception d'implémentation. - **Sélectionnez le pipeline avant de concevoir le schéma.** Les pipelines de traitement _par lot_ et _transactionnel_ diffèrent par le modèle d'ingestion, la liaison du schéma, la flexibilité de la cible et la latence. Il est important de confirmer le pipeline requis par chaque cas d'utilisation avant de définir le schéma, car la modernisation ajoute des travaux évitables. - **Concevoir des schémas au niveau du type de document.** L'utilisation d'un schéma unique et bien conçu par type de document est plus facile à gérer que l'utilisation de configurations par cas d'utilisation, et c'est également le plus grand levier de qualité d'extraction. Pour ce faire, vous devez utiliser une série de documents divers, y compris des requêtes de bord, plutôt que de concevoir à partir d'un seul exemple. Utilisez itérativement des invites au niveau du _champ_, _du tableau_ et _du schéma_ pour identifier les écarts, puis testez-les et affinez-les par rapport à plusieurs échantillons de documents avant de les finaliser. Notez qu'un schéma qui fonctionne bien sur un document peut être insuffisant sur d'autres. Par conséquent, l'étendue et l'itération sont essentielles. La flexibilité du schéma, notamment le retrait des colonnes qui ne sont pas extraites de façon fiable entre les types de document, est tout aussi importante. S'accrocher à des champs qui introduisent du bruit ou de l'incohérence nuit à la qualité générale de l'extraction. Par conséquent, il est important de traiter l'enlèvement des colonnes comme une décision de conception de premier ordre. - **Choisissez le niveau cible correct par groupe de champs.** Les champs qui pilotent des workflows CRM ou des approbations écrivent dans _SObjects_. Les champs qui enrichissent le profil unifié ou alimentent les analytiques appartiennent au pipeline _DLO/DMO_. Les champs qui servent des systèmes externes appartiennent au _RDBMS_. Notez qu'un schéma unique peut atteindre simultanément plusieurs niveaux. - **Appliquer la gouvernance avant de traiter les contenus réglementés.** Les données réglementées doivent être protégées à chaque couche. Par conséquent, il est important de configurer le masquage des _informations d'identification_ personnelle, les balises de classification des données et le contrôle d'accès _basé sur l'attribut_ (ABAC) une fois les données extraites stockées dans les _objets lac de données (DLO) de sortie._ Cela permet d'ajuster l'application de la loi et d'accéder au contexte en fonction de la classification des données, du rôle de l'utilisateur et du contexte organisationnel. La _gouvernance_ est divisée en deux voies : L'_ELT_ régit l'interaction LLM, tandis que les données extraites stockées dans des Data Lake Objects (DLOs) doivent être régies séparément (directement au niveau des Data Lake Objects (DLOs) et de la base de données) via des configurations _Data Space_, _Permission Sets_ et des stratégies _ABAC_. Ces contrôles doivent maintenir la cohérence au niveau du stockage, pas seulement au niveau de la couche application. Par conséquent, les restrictions d'accès restent inchangées, quel que soit le mode d'accès aux données après l'ingestion. Notez que les écarts dans n'importe quelle couche peuvent exposer des données réglementées en aval, même lorsque d'autres sont correctement configurées. - **Concevoir pour les modes de défaillance avant la production.** Répondez au traitement des champs nuls, aux seuils de qualité OCR, à la pré-validation de la taille du fichier, au dépassement du contexte LLM, à l'idempotence en écriture du SGBDR et aux limites du budget de crédit avant la première exécution de lot de production. Ce ne sont pas des cas de bord, ce sont des surfaces de défaillance prévisibles qui doivent être traitées explicitement dans la conception du pipeline, pas découvertes à l'exécution. - **Traitez les scores de confiance comme un signal d'acheminement de première classe, pas comme un diagnostic après coup.** Les résultats d'extraction contiennent des valeurs de confiance au niveau du champ dérivées des probabilités de consignation (logprobs) de la sortie du modèle sous-jacent. Pour chaque champ, tableau ou colonne extrait, le score reflète la certitude de la valeur extraite au niveau du jeton du modèle. Cela fait des scores de confiance un signal statistiquement ancré suffisamment fiable pour servir de porte principale aux seuils d'escalade _Human-in-the-Loop (HITL)_. Utilisez des scores de confiance pour identifier systématiquement les extractions de faible qualité et initier des points de contrôle HITL pour les valeurs de champ de faible confiance, les correspondances de schéma ambiguës ou les défaillances répétées du pipeline au lieu de vous appuyer sur des heuristiques ou des contrôles ponctuels manuels. Lorsque la récupération automatisée n'est pas possible, le score de confiance soutenu par HITL garantit que le jugement humain est appliqué exactement là où il est nécessaire. - **Concevez des parcours d'activation en parallèle avec la conception du schéma.** L'intérêt de _l'IA Document_ réside dans la possibilité d'activer des données extraites dans des workflows et des agents Salesforce. Il permet de concevoir _des actions_, _des flux_ et des _connaissances calculées_ Agentforce parallèlement à la conception d'un schéma d'extraction, pas après. ## Architecture : Pipeline Data 360 Document AI _Document AI_ fonctionne dans deux pipelines : - Un pipeline _par lot_ pour le traitement à haut volume soutenu par UDMO - Un pipeline _transactionnel_ _de traitement_ pour l'extraction pilotée par l'API en temps réel Les deux pipelines partagent le même contrat de configuration de schéma et la même gouvernance ETL, mais ils diffèrent dans la façon dont les documents entrent dans le système et l'emplacement d'arrivée des données extraites. Examinons de plus près chaque pipeline. ### Pipeline de traitement par lot Le pipeline _par lot_ traite les ensembles de documents récurrents définis par un UDMO. Il convient aux cas d ' utilisation planifiés ou pilotés par un événement, où des documents sont ingérés à partir d ' un espace de stockage d ' entreprise, puis extraits et livrés au pipeline d ' objets lac de données/objet modèle de données _Data 360_ pour harmonisation, résolution de l ' identité et activation. **Scénario réel** Chaque jour, un transporteur d'assurance reçoit des milliers de documents de réclamation médicale provenant de portails de prestataires, qui sont chargés sous forme de fichiers PDF dans _Amazon S3_. L'UDMO définit l'ensemble de documents dans le périmètre et envoie tous les fichiers PDF de réclamation au compartiment `/claims/incoming/` dans un délai de 24 heures. ![Projet de traitement par lot des déclarations médicales d'un transporteur d'assurance, depuis l'ingestion jusqu'à l'harmonisation, en passant par la résolution de l'identité et l'activation Agentforce](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-batch-processing.png) #### Étape 1: Ingestion Les documents sont ingérés dans _Data 360_ à partir de systèmes sources d'entreprise sans duplication physique. Les sources prises en charge comprennent _Amazon S3_, _Google Cloud Storage_, les objets fichiers Salesforce CRM, les pipelines _orchestrés par MuleSoft_ et les chargements d'API directs. Dans les déploiements _Headless 360_, les documents sont ingérés via des connecteurs de stockage Cloud ou l'_API Ingestion_, qui contourne la couche CRM. Le serveur _Model Context Protocol (MCP)_ expose l'ingestion en tant qu'outil appelable pour les agents IA externes et les clients LLM. Lors de l'ingestion, les documents bruts sont stockés sous forme d'obje _ts lac de données non structurés (UDLO), qu_i sont mappés avec l'emplacement physique et les métadonnées de chaque document sans déplacer ni transformer le fichier source. **Exemple :** Les fichiers PDF de réclamation sont ingérés depuis _S3_ dans _Data 360_ via le connecteur de stockage Cloud. Chaque document est stocké sous forme d'UDLO qui pointe vers l'objet _S3_. Aucune duplication physique ne se produit. #### Étape 2 : Extraction _L’IA du document_ traite chaque UDLO par rapport à une configuration de schéma qui définit les champs à extraire avec leurs types de données cibles. L'UDMO définit quels documents sont concernés. Le LLM (_GPT-4o_, _Gemini_ ou _Claude_) lit chaque document et renvoie une charge utile d'extraction structurée. **Exemple :** _L’IA du document_ traite chaque objet lac de données par rapport à un schéma de réclamation qui définit des champs tels que : ClaimID, PatientName, DiagnosisCode, BillingAmount et ServiceDate. Les LLM lisent ensuite chaque fichier PDF et renvoient une charge utile d'extraction structurée. #### Étape 3 : Persister Une fois extraites, les données sont conservées dans des objets lac de données, qui sont la couche de stockage brute de _Data 360_. Les objets lac de données conservent les champs extraits sans imposer de logique métier, ce qui préserve une représentation physique précise pour la transformation en aval et la traçabilité. L'UDLO conserve une référence au document source pour activer le lignage au niveau du champ à n'importe quel point du pipeline. **Exemple :** Tous les champs extraits se retrouvent dans un _Claims DLO_, qui conserve une représentation brute et précise de chaque réclamation avec une traçabilité complète jusqu'au PDF source. #### Étape 4 : Harmoniser Les champs d'objet lac de données sont mappés avec des objets modèle de données conformes au _modèle Customer 360_ standard. Il s'agit de la frontière dans laquelle les données dérivées de documents passent de champs bruts extraits à des entités importantes pour l'entreprise. L'_objet lac de_ données Facture est mappé avec un _objet modèle de_ données Facture, et des champs tels que _CustomerID_ et _BillingAmount_ deviennent des clés de jointure et des attributs de correspondance dans le modèle de données unifié. Les données harmonisées des documents participent à la segmentation, _aux connaissances calculées_ et à l'activation via les mêmes interfaces que celles utilisées par CRM et les données transactionnelles. **Exemple :** Le _Claims DLO_ est mappé à un _Claims DMO_. Les champs PatientID et PolicyNumber deviennent des clés de jointure qui lient les enregistrements de réclamation à des profils de patient unifiés. #### Étape 5: Unifier Les données d'objet modèle de données harmonisées participent à la résolution de l'identité. Les champs extraits (par exemple, les noms de clients, les adresses e-mail ou les numéros de compte) servent de clés de correspondance pour lier des enregistrements de document à des _Individus unifiés (enregistrements dorés)_, ce qui comble l'écart entre le document et le profil. **Exemple :** Les champs d'extraction (par exemple PatientName, DateOfBirth et PolicyNumber) servent de clés de correspondance pour la résolution de l'identité, qui associe les enregistrements de réclamation à l'_Individu unifié_ approprié. Cela se produit même si le même patient est affiché sous des orthographes de nom légèrement différentes dans les documents. #### Étape 6 : Tirer des enseignements Les architectes définissent les _Connaissances calculées_, qui sont des métriques agrégées calculées à partir de données de documents harmonisées (par exemple, les dépenses totales de divers éléments de ligne de facture, les scores de risque de renouvellement de contrat et les indices de sévérité des déclarations). **Exemple :** Les _Calculated Insights_ calculent TotalClaimsPerPatient, AverageClaimAmount et HighRiskClaimScore sur les données harmonisées de réclamations pour les requêtes Agentforce. #### Étape 7: Agir Les agents Agentforce, _Tableau_, les plates-formes marketing et les _SObjects_ Salesforce ont accès à des données harmonisées et résolues en fonction de l ' identité. Le niveau cible est une décision architecturale pilotée par les exigences de latence, de gouvernance et de résidence des données. **Exemple :** A _Clams Adjudication Agentforce Agent_ interroge les objets modèle de données et les indicateurs de performance _Data 360_ pour trouver les réclamations à haut risque à examiner en priorité. _Tableau_ affiche le volume des réclamations et les tendances en matière d'anomalies. Les enregistrements de réclamation approuvés retournent dans le _Claims SObject_ pour initier les workflows de paiement. Dans les architectures _Headless 360_, l'activation achemine directement vers des systèmes externes via l'_API Query_, l'_API Pub/Sub_ ou des cibles d'activation d'entrepôt de données Cloud. Ensuite, le serveur MCP recherche des données de document harmonisées et des _Connaissances calculées_ en tant qu'outils appelables pour les agents IA externes. ### Pipeline de traitement transactionnel Le pipeline de _traitement transactionnel_ gère l'extraction de documents uniques à l'exécution sans UDMO ou UDLO préingéré, ce qui convient aux cas d'utilisation pilotés par l'événement (par exemple, un client chargeant un formulaire, un agent recevant un fichier PDF ou un système externe initiant l'extraction dans un workflow de traitement transactionnel). La gouvernance ETL s'applique de façon identique aux deux pipelines. **Scénario réel** Lors d'une demande de prêt, un client de la banque charge un fichier PDF de sa facture de services publics via l'application mobile de la banque. L'événement initie l'extraction en temps réel, ce qui signifie qu'aucun UDLO ou UDMO pré-ingéré n'est impliqué. ![Pipeline de traitement transactionnel illustrant l'extraction en temps réel via une API REST synchrone pour la facture de services publics d'un demandeur de prêt](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-ad-hoc-processing.png) #### Étape 1 : Définir la configuration du schéma Avant d'invoquer l'API, les architectes doivent définir et stocker dans _Data 360_ un schéma qui spécifie les champs, les types de données et les instructions d'extraction sous le format _Schéma JSON_. Un _ID de schéma_ unique est attribué à chaque schéma. À l'exécution, l'application appelante référence l'ID de schéma pour garder la logique d'extraction centralisée dans _Data 360_ au lieu de l'incorporer dans le code de l'application. **Exemple :** L'équipe de la banque a un schéma de `ProofOfAddress` prédéfini dans _Data 360_, qui spécifie des champs tels que `CustomerName`, `AddressLine1`, `City`, `PostCode` et `DocumentDate`. Ces informations sont stockées dans une configuration de version qui peut être référencée par un _ID de schéma_. #### Étape 2 : Soumettre des documents L'application appelante soumet le document et l'ID de schéma dans une requête d'API REST unique en tant que charge utile ou référence de fichier codée en base64. Aucune ingestion UDLO n'est requise. _L’IA du document_ applique l’extraction du document et renvoie la sortie structurée basée sur le schéma fourni. **Exemple :** L'application mobile soumet la facture de service en tant que charge utile codée en base64 avec l'ID de schéma de `ProofOfAddress` dans un seul appel d'API REST. Ce processus ne nécessite pas d'étape d'ingestion UDLO. #### Étape 3 : Extraire Le LLM traite la sortie OCR par rapport au schéma et renvoie une charge utile JSON structurée de façon synchrone. Les champs introuvables dans le document sont renvoyés _nuls_. L'appelant est propriétaire de la réponse JSON complète et passe à l'acheminement. **Exemple :** _Document AI_ applique OCR au fichier PDF et le LLM renvoie une charge de travail JSON structurée avec des champs d'adresse extraits. Les champs introuvables (par exemple, si le `PostCode` est manquant dans la facture) sont renvoyés _null_. #### Étape 4 : Acheminement vers la cible (facultatif) Une fois extraite, la charge utile JSON peut être acheminée vers un ou plusieurs niveaux cibles selon le cas d'utilisation : - **Salesforce SObject:** Il correspond directement aux champs de _SObject_ via _Apex_ ou _Flow_ pour les workflows CRM et les processus d'approbation. - **Data 360 DLO/DMO Pipeline :** Achemine vers un Data Lake Object (DLO) pour harmonisation, résolution d'identité, _Calculated Insights_ et ancrage Agentforce. - **RDBMS externe ou entrepôt de données :** Achemine par _MuleSoft_, appel _Apex_, _événements de plateforme_ ou ETL pour des systèmes extérieurs à Salesforce. - **Intégration personnalisée :** Renvoie les charges utiles JSON structurées à l'application appelante pour stockage dans n'importe quel système externe ou magasin de données. - **Flux ou agent en aval :** Transmet la sortie JSON structurée directement à un flux ou un agent en aval sans aucune persistance dans un _SObject_. Ce schéma est courant pour les clients qui utilisent l'_IA de documents_ comme étape d'extraction en temps réel dans une automatisation plus large ou un workflow agent. Notez qu'un schéma unique peut atteindre simultanément plusieurs niveaux, différents groupes de champs acheminant vers différentes cibles à partir du même point d'extraction. **Exemple :** Une charge de travail `ProofOfAddress` peut atteindre trois niveaux à la fois (par exemple, `CustomerName` et `AddressLine1` écrivent dans le _SObject Contact_), ce qui initie un _flux_ de vérification de l'adresse. Ensuite, la charge utile complète est acheminée vers un objet lac de données pour harmonisation et évaluation des risques, et une copie est acheminée vers le système KYC de la banque via _MuleSoft_ pour consignation de la conformité réglementaire. #### Étape 5: agir Une fois écrites, les données extraites sont immédiatement activées dans le système cible. Pour des cibles _SObject_, les déclencheurs, les flux et les processus d'approbation sont activés dans l'enregistrement mis à jour. Pour les cibles _DLO/DMO_, les données entrent dans le pipeline d'_harmonisation et de résolution de l'identité_ et dans le contexte Agentforce. Pour des cibles _SGBD_ externes, les données sont disponibles pour les requêtes en aval dès que l'écriture est terminée. **Exemple :** Le _flux de vérification d'adresse_ est immédiatement activé dans l'enregistrement _Contact_ mis à jour, ce qui fait passer la demande de prêt à l'étape suivante. L'_agent de prêt Agentforce_ trouve l'adresse vérifiée dans _Data 360_, et le système KYC enregistre la soumission du document à des fins d'audit. ## Quand devez-vous utiliser Document AI ? _Document AI_ est plus adapté à des conditions architecturales spécifiques. Son application hors de ces conditions entraîne une complexité inutile et des coûts supplémentaires. En tant qu'architectes, il est important d'évaluer ces critères avant de s'engager dans _l'IA Document_ en tant que mécanisme d'extraction. **Utilisez Document AI lorsque :** - **Les documents sont la principale source de données.** Les informations requises existent uniquement sous forme de document et ne sont pas disponibles dans une API structurée ou une base de données (par exemple, contrats scannés, rapports de laboratoire, formulaires d'admission ou déclarations d'assurance). - **Les mises en page des documents varient selon les sources.** Le même type de document provient de plusieurs fournisseurs, partenaires ou régions avec des positions et des formats de champ différents. L'extraction LLM pilotée par le schéma s'adapte sans maintenance par mise en page. - **Les données extraites doivent alimenter Data 360 ou Agentforce.** L'extraction doit participer à la résolution de l'identité, _Calculated Insights_ ou à l'ancrage Agentforce. _Document AI_ est livré directement dans le pipeline _DLO/DMO_ sans couche ETL séparée. - **Le volume justifie l'automatisation gouvernée.** Le volume de documents dépasse ce que le traitement manuel peut traiter sans coût de main-d'œuvre mesurable ni risque de qualité des données. - **Les documents contiennent un contenu réglementé.** Les données _PHI_, _PII_ ou financières doivent transiter par une couche de rétention des données nulle et masquant les PII avant d'atteindre un grand livre. L'ETL le satisfait nativement. Les clients qui ne souhaitent pas que le contenu extrait soit conservé à tout moment doivent également prendre en compte le flux d'_API transactionnelle_, qui renvoie une sortie structurée directement à l'application appelante sans écrire dans un _SObject_ ou un magasin de données. - **Le cas d'utilisation est piloté par l'événement.** Un document arrive à l'exécution (par exemple, un chargement de client, une pièce jointe PDF d'agent ou un déclencheur système externe). Le pipeline de _traitement transactionnel_ gère l'extraction synchrone de documents uniques sans configuration par lot. **N'utilisez pas Document AI lorsque :** - **Les données sources sont déjà structurées.** Si le système en amont expose une API REST, un tableau de base de données ou un fichier structuré (par exemple, CSV, JSON ou XML), utilisez un connecteur _Data 360_ standard. L'exécution de données structurées à travers un pipeline d'extraction LLM ajoute des coûts de latence et de crédit sans avantages supplémentaires. - **Les documents sont générés par machine avec un schéma fixe.** Les fichiers PDF générés par le système à partir d'un système ERP connu ou d'une plate-forme de facturation avec une présentation stable conviennent mieux à un analyseur déterministe. L'extraction LLM est conçue pour la variabilité, et son application à des documents à schéma fixe entraîne des pertes de contexte et de crédits. - **Les exigences de précision dépassent les seuils de confiance en LLM.** _Document AI_ ne garantit pas une précision d'extraction de 100 %. Les cas d'utilisation où une valeur de champ manquée ou incorrecte comporte un risque financier, juridique ou clinique important nécessitent une étape de validation HITL. N'utilisez pas _Document AI_ comme couche d'extraction unique pour les décisions à fort enjeu sans flux de validation. - **Les documents dépassent les contraintes de la plate-forme.** La limite actuelle en taille de fichier de 10 Mo et les contraintes de longueur du contexte LLM rendent _l’IA des documents_ inadaptée aux documents volumineux ou denses sans prétraitement pour les séparer et les réassembler hors de la plate-forme. - **Note :** Chez Salesforce, nous améliorons activement ces garde-fous d'acceptation afin d'élargir les tailles de fichier, le nombre de pages et les extensions de fichier pris en charge. Les contraintes continueront d'évoluer à l'avenir. ## Cas d'utilisation : Révision des modèles dans la pratique ### Cas d'utilisation du pipeline par lot Examinons de plus près plusieurs scénarios qui utilisent le pipeline de _lots Document AI_ soutenu par un objet source UDMO. Dans ce cas, les données extraites transitent par le pipeline d ' objets lac de données/objet modèle de données _Data 360_ pour harmonisation, résolution de l ' identité, _connaissances calculées_ et activation Agentforce. Chaque cas d'utilisation est plus adapté au traitement de documents planifiés ou pilotés par un événement, à haut volume. **Agentforce Sales : Intelligence des contrats et des factures** Les PDFs _Contract_ sont ingérés depuis le stockage Cloud via le pipeline _batch_. Le schéma extrait ContractValue, RenewalDate, PaymentTerms et CounterpartyName, puis les mappe avec les objets modèle de données _Compte_ et _Contrat_. Les _Connaissances calculées_ dérivent des scores de risque de renouvellement. Agentforce alerte les chargés de compte avant la fermeture des fenêtres de renouvellement, ce qui élimine la révision manuelle des contrats et les renouvellements manqués. **Agentforce Service : Déviation de requête et ancrage des connaissances** Les fichiers PDF d'_enquête_ et les pièces jointes aux cas sont ingérés via le pipeline _batch_. Le schéma extrait les indicateurs de sentiment, les catégories de problèmes et les notes de résolution, puis les mappe avec les objets modèle de données _Case_ et _Knowledge Article_. Agentforce interroge la base de Knowledge harmonisée à l'ouverture de la requête et localise les étapes de dépannage appropriées, ce qui réduit les frais de recherche d'agents. **Agentforce Health : Traitement des documents cliniques** Les rapports de laboratoire, les fichiers PDF d'admission et les formulaires cliniques manuscrits sont ingérés via le pipeline _batch_. Le schéma extrait des champs, notamment _PatientID_, _DiagnosisCode_, _MedicationName_ et _TestResult_, puis les mappe avec les objets modèle de données _Health Cloud_, qui prennent en charge la coordination des soins et les workflows de recherche clinique conformes à la norme HIPAA. **Services financiers : Automatisation des documents de prêt et d'impôt** Les demandes de prêt, les déclarations de revenus et les comptes de résultat sont ingérés via le pipeline par lot. Le schéma extrait des champs, notamment AnnualIncome, TaxYear et EmployerName, puis les mappe avec les objets modèle de données _Compte financier_. Les _Connaissances calculées_ joignent les données de revenu dérivées de documents et les données CRM pour faciliter le score de risque de crédit automatisé. Agentforce repère les détails du prêt extraits directement au cours des interactions avec le service client. Ce modèle prend directement en charge le cas d'utilisation [Agent de présélection de prêt](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions), publié sur le centre des développeurs Salesforce _Agentic Enterprise Solutions_. **HR: Traitement des documents de la force de travail** Les documents d'intégration, les formulaires fiscaux et les fichiers PDF de certification sont ingérés via le pipeline _par lot_. Les champs extraits sont mappés avec les objets modèle de données _Enregistrement employé_, puis liés au profil _Employé unifié_. Des _flux_ spécifiques initient des tâches d'intégration et des contrôles de conformité basés sur les données extraites. Ce modèle prend directement en charge le cas d'utilisation [Agentic d'automatisation du traitement des CV](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions). L'_Document AI_ extrait les compétences, l'historique professionnel et les qualifications des CV au format PDF, qu'Agentforce utilise ensuite pour faire correspondre les candidats aux critères des postes ouverts et les acheminer vers des workflows de recrutement. **Services professionnels : Proposition et intelligence de la recherche** Les diaporamas de propositions et les rapports de recherche sont ingérés via le pipeline _par lot_. Les infrastructures, les points de repère et les résumés d'engagement extraits sont mappés avec des objets modèle de données personnalisés, puis indexés pour la recherche vectorielle. Agentforce récupère au moment de la requête des recommandations pertinentes au contexte, qui sont fondées sur le contenu extrait du document. Ce modèle étend le modèle [Ground Agentforce on Website Content](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions). Les documents sont indexés via _l'IA Document_ et remplissent la même fonction d'ancrage pour les réponses des agents que les contenus de site Web indexés via des connecteurs _Data 360_. **Statut de conformité HIPAA :** Les schémas _Health Cloud_ décrits dans le présent document appliquent des contrôles ETL (par exemple, zéro rétention des données et masquage PHI) pour les entrées de texte. Ces contrôles ne constituent pas à eux seuls une certification HIPAA. Les architectes qui conçoivent pour des environnements cliniques réglementés doivent confirmer le statut de certification HIPAA actuel auprès de l'équipe de conformité de Salesforce avant de s'engager dans une architecture basée sur l'intelligence artificielle _des documents_ dans ces contextes. ### Cas d'utilisation du pipeline de traitement transactionnel Examinons de plus près plusieurs scénarios qui invoquent l'API REST _Document AI_ avec un schéma qui n'est pas lié à un UDMO. Les charges utiles JSON extraites sont acheminées directement vers des systèmes externes de façon synchrone à l'exécution. **Chaîne d'approvisionnement : Traitement des factures fournisseurs vers ERP** Lorsqu’un fichier PDF de _facture fournisseur_ arrive dans un compartiment de stockage surveillé ou une passerelle de messagerie, un déclencheur d’événement appelle l’API REST _Document AI_ avec la facture et un ID de schéma prédéfini. Le schéma extrait VendorID, InvoiceNumber, LineItems, TotalAmount, TaxAmount et DueDate. La charge de travail JSON est acheminée via _MuleSoft_ vers le module _Comptes fournisseurs ERP_ avec une validation de champ _nulle_ et une logique de mise à jour/insertion idempotente, qui élimine la maintenance du modèle pour la variabilité du format fournisseur. **Opérations juridiques : Revue de contrat vers CLM** Lorsqu'un fichier PDF de _contrat_ est chargé dans le portail légal, le back-end appelle l'API REST _Document AI_ de façon synchrone. Le schéma extrait GoverningLaw, IndemnityCapAmount, TerminationNoticePeriod, AutoRenewalClause et CounterpartySignatory. La charge de travail JSON est acheminée par appel _Apex_ vers le système _CLM (Contract Lifecycle Management)_. Tous les champs introuvables sont renvoyés _null_ et le CLM applique les règles d'obligation par défaut aux valeurs manquantes. **Déclarations d'assurance : Premier avis de traitement de perte** Lorsqu’un assuré soumet un formulaire _First Notice of Loss (FNOL)_, le portail back-end appelle l’API REST _Document AI_ de façon synchrone. Le schéma extrait PolicyNumber, IncidentDate, IncidentLocation, DamageDescription, ClaimantName et ContactPhone. La charge de travail JSON est acheminée vers la base de données de _gestion des déclarations_ par appel _Apex_ ou ETL, ce qui crée un enregistrement de déclaration prérempli que les experts peuvent examiner avant l ' ouverture de la déclaration officielle. ## Considérations relatives à la conception et modes d'échec Avant de passer en production, vous devez créer des conceptions pour ces scénarios d'échec. - **Traitement des champs nuls :** Le LLM renvoie _null_ pour les champs qu'il ne peut pas localiser ou extraire en toute confiance. Validez la logique de traitement des valeurs nulles lors de la conception du schéma et implémentez une valeur par défaut ou une logique de rejet dans la couche d'intégration avant d'écrire dans des cibles avec des contraintes _NOT NULL_ ou des clés de correspondance requises. - **Dégradation de la qualité OCR :** La précision OCR se dégrade en dessous de 150 DPI, sur écriture irrégulière ou sur scans bruyants. Les erreurs de lecture se propagent dans l'extraction LLM sous forme d'entrée corrompue sans signaux d'erreur. Appliquer une qualité d'analyse minimale lors de l'ingestion et implémenter des contrôles de seuil de confiance dans les champs numériques et de date. - **Inadéquation de version du schéma :** La mise à jour d'une configuration de schéma après la planification d'une tâche par lot entraîne le traitement des documents en vol par rapport à la version précédente, ce qui produit des champs manquants ou renommés qui rompent le mappage en aval. Versionnez explicitement des schémas et coordonnez les mises à jour avec des planifications de tâches par lot. - **Limites de taille de fichier :** Les documents qui dépassent 10 Mo sont rejetés. Les échecs de pipeline par lot sont silencieux sans surveillance configurée, et les appelants transactionnels reçoivent une erreur _4xx_. Pré-validez la taille des fichiers lors de l'ingestion et implémentez un pré-traitement pour séparer ou compresser les documents qui approchent régulièrement de la limite. - **Dépassement du contexte LLM :** Les documents denses ou multi-pages peuvent dépasser la fenêtre de contexte LLM dans la limite de 10 Mo. Le LLM abandonne silencieusement les contenus qui dépassent le contexte. Implémentez une stratégie de segmentation qui divise les documents par plage de pages et remonte les champs extraits avant de les transférer vers la cible. - **Masquage du Trust Layer affectant l'extraction :** L'ETL fonctionne au niveau de l'invite, pas au niveau du document. Par conséquent, le masquage ne s'applique pas au contenu du document qui transite par _l'IA du document_. Les champs de schéma qui dépendent des valeurs _PII_ du document ne sont pas affectés par les stratégies de masquage ETL. - **Idempotence en écriture du SGBDR externe :** Le pipeline de _traitement transactionnel_ n'a pas d'idempotence intégrée pour les cibles _SGBDR_ externes. Les tentatives de _couche d'intégration_ créent des lignes dupliquées, sauf si la logique d'écriture gère explicitement la déduplication. Implémentez des mises à jour/insertions idempotentes en utilisant une empreinte de document ou un ID externe dans tous les chemins d'écriture externes. - **Épuisement du crédit à mi-exécution :** Les exécutions par lots importantes peuvent épuiser les crédits _Digital Wallet_ avant le traitement de tous les documents, ce qui produit des ensembles de données DLO incomplets que les étapes en aval considèrent comme complets. Définissez des alertes de consommation sur 75 % et 90 % des crédits disponibles, et limitez la taille des lots pour respecter le budget de crédit de chaque cycle. - **Limite de champs du schéma — Contrainte architecturale :** _L'IA du document_ applique une limite de 50 champs pour les champs de niveau racine dans une configuration de schéma. Il s'agit d'une contrainte de conception, pas d'une erreur d'exécution, et les architectes doivent en tenir compte lors de la conception du modèle de données et du schéma. - Pour les cas d'utilisation qui nécessitent une extraction plus large : - Priorisez sans pitié. Affinez le schéma aux champs qui déterminent la valeur d'automatisation, pas à la couverture exhaustive des documents. - Tirez parti des objets imbriqués (jusqu'à 3 niveaux ; mode par lot avec l'objet source uniquement) pour réduire le nombre de champs au niveau racine sans sacrifier la profondeur d'extraction. - Décomposez des documents complexes à travers plusieurs configurations _IA de documents_ qui ciblent des sections de documents distinctes, écrivez des résultats dans des objets lac de données séparés qui se joignent en aval dans _Data 360_. - **Limites de taux d'API :** _L’IA du document_ impose une limite de 50 appels d’API d’extraction par minute et par locataire. Le plafond théorique est de 300 appels par minute, qui est régi par la _passerelle Einstein LLM_. Les intégrations transactionnelles à haut volume doivent être conçues avec une temporisation exponentielle, une mise en file d'attente des requêtes et une gestion du débit par locataire. Ne supposez pas que la capacité de rafale est disponible dans les environnements de production multilocataires. - **Profil de latence d'API :** Les API d'extraction _Document AI_ sont entièrement synchrones. Les temps de réponse typiques vont de 5 à 15 secondes, et varient selon la taille du fichier et la complexité du schéma. - Cela a des implications directes pour l'architecture d'intégration : - Définissez les délais d'attente pour les appels à un minimum de 30 secondes. - N'invoquez pas _Document AI_ dans les flux avec des exigences de SLA inférieures à une seconde. - Tenez compte de la latence dans les calculs de débit par rapport au plafond de la limite tarifaire pour les pipelines de _traitement par lot_. - **Documents cryptés et protégés par mot de passe :** _Document AI_ ne traite pas les fichiers protégés par mot de passe (les mots de passe utilisateur sont requis pour ouvrir les fichiers) ni les fichiers PDF cryptés avec un mot de passe propriétaire/autorisations, y compris les fichiers qui s'ouvrent normalement, mais qui limitent la copie, l'impression ou la modification au niveau de la couche d'_autorisations PDF_. - Cette contrainte se situe à la limite d'ingestion : - Concevez des pipelines _de réception de_ documents pour détecter et acheminer les fichiers cryptés vers un chemin _de refus_ ou _de traitement manuel_ avant qu'ils n'atteignent _l'IA Document_. - Ne vous appuyez pas sur le traitement des erreurs d'exécution en tant que porte principale. ## Alignement Well-Architected _L’IA Data 360 Document_ s’aligne sur plusieurs piliers de l’_infrastructure bien architecturée_ de Salesforce. - **Trust :** L'ETL applique une rétention de données nulle avec les fournisseurs de LLM, masque les entrées _PII_ avant qu'elles atteignent le modèle et analyse les sorties pour détecter les contenus confidentiels. Les architectes doivent étendre cette posture aux données extraites au repos. Le masquage au niveau des champs dans les DLO n'est pas appliqué par l'ETL et nécessite des politiques en aval pour le _Espace de données_ et des _Permission Sets_. - **Fiabilité :** Chaque mode d'échec de la section _Considérations relatives à_ la conception (extraction de champ nul, lecture incorrecte de l'OCR, incohérence de version de schéma, violation de taille de fichier, dépassement du contexte du grand livre, interférence de masquage ETL, idempotence en écriture du SGBDR et épuisement du crédit) représente une classe d'échec distincte avec un signal de détection documenté et un chemin de résolution. - **Excellence opérationnelle (gestion du changement) :** Le modèle d'extraction piloté par le schéma dissocie la logique d'extraction de la présentation du document. Lorsqu'un fournisseur change un format de facture ou qu'un formulaire réglementaire est mis à jour, les architectes doivent mettre à jour une seule configuration de schéma plutôt que de modifier le code d'intégration. - **Excellence opérationnelle (maintenabilité) :** La centralisation des configurations de schéma dans _Data 360_ plutôt que l'incorporation d'une logique d'extraction dans un code d'application rend l'intention d'extraction explicite, contrôlée et auditable. Toutes les cibles en aval consomment le même contrat de schéma, quel que soit leur niveau cible. - **Excellence opérationnelle (réutilisation de l'intégration) :** _Document AI_ expose l'extraction à travers plusieurs surfaces d'intégration : API REST, _Apex_, _Flow_, _MuleSoft_, Agentforce _Actions_, et le serveur MCP. Une configuration de schéma unique s'étend simultanément à plusieurs niveaux cibles sans reconstruire la capacité d'extraction par consommateur. - **Optimisation des ressources et des coûts :** Le guide de sélection du pipeline, la limite de taille de fichier de 10 Mo et les contraintes de longueur du contexte du grand livre avant l'assemblage représentent des décisions de conception sensibles aux performances. La section _Quand utiliser_ formalise les conditions dans lesquelles _l'IA du document_ n'est pas l'outil approprié (par exemple, exigences de latence inférieure à la seconde, données sources entièrement structurées et documents générés par machine à schéma fixe). ## Guide de démarrage rapide pour les architectes Il s'agit d'un point de départ structuré pour configurer _Data 360 Document AI_ dans un environnement sandbox. Terminez toutes les phases dans l'environnement sandbox avant de passer en production. ### Avant de commencer Avant de commencer la configuration, vous devez confirmer : - **Taille du fichier :** Vérifiez que la taille des documents représentatifs est inférieure à 10 Mo. - **Pipeline :** Vérifiez si le cas d'utilisation nécessite le pipeline _par lot_ (soutenu par UDMO, haut volume) ou le pipeline _de traitement transactionnel_ (piloté par l'API, document unique). Ce choix conditionne toutes les configurations ultérieures. - **Niveau cible :** Vérifiez l'emplacement d'arrivée des données extraites : _SObject_ Salesforce, Objet lac de données/objet modèle de données _Data 360_, SGBDR externe ou une combinaison de ces éléments. - **Dépendance Agentforce :** Avant de déployer un traitement de document piloté par Agentforce, vérifiez qu'un [LLM](https://help.salesforce.com/s/articleView?id=ai.generative_ai_large_language_model_support.htm&type=5) pris en charge (par exemple, _GPT-4o_) est activé dans votre organisation via les paramètres ETL. Agentforce est un prérequis strict de la plateforme pour _Document AI_. Toute la surface de fonctionnalité _IA du document_, y compris toutes les API d'extraction, n'est pas disponible tant qu'Agentforce n'est pas actif dans l'organisation cible. Tenez compte de ces éléments dans les évaluations de la préparation de l'organisation et le séquençage du provisionnement. Prévoyez quelques minutes pour que la disponibilité de l'API se stabilise après l'activation. - **Impact de la désactivation d'Agentforce :** Si Agentforce est désactivé après la configuration et le déploiement de _Document AI_, tous les traitements d'extraction (interface utilisateur et API) seront immédiatement bloqués. Il en va de même pour la désactivation du modèle. La désactivation du modèle sous-jacent a un effet équivalent sur la disponibilité de _l’IA Document_. Dans les deux cas, les configurations de schéma existantes sont conservées et resteront visibles - aucune configuration ni perte de données ne se produira - mais la capacité est totalement inexploitable tant qu'Agentforce et le modèle ne sont pas réactivés. Concevez des runbooks opérationnels pour considérer la disponibilité d'Agentforce et l’activation du modèle comme des dépendances essentielles au bon fonctionnement de _Document AI_. - **Consommation de crédits / tarification :** Utilisez des crédits _Data 360_ ou des _crédits Flex_ pour des estimations de TCO dérivées de documents échantillons représentatifs. #### Phase 1: Configuration du schéma et du pipeline - **Créez la configuration du schéma.** Définissez des champs d'extraction, des types de données et des instructions sous le format _Schéma JSON_ dans la configuration de _Data 360 Document_ AI. Pour le pipeline _par lot_, liez-le à un UDMO. Pour le pipeline _de traitement transactionnel_, créez-le sans objet source. Enregistrez l'ID de schéma. - **Alignez les noms de champ sur le niveau cible.** Mappez les noms de champ avec des définitions de colonne d'objet lac de données, des noms d'API _SObject_ ou des noms de colonne SGBDR. Les noms mal alignés créent une surcharge de mappage dans la couche d'intégration. - **Configurez l'objet source UDMO (par lot uniquement).** Définissez des documents dans l'étendue et configurez la connectivité de la source d'ingestion (par exemple, _S3_, _Google Cloud Storage_, _Salesforce Files_ ou _MuleSoft)_. Vérifiez que le compte de service d'ingestion a l'étendue d'identifiant _IAM_ ou _OAuth_ requise. - **Appliquez les politiques de masquage des informations personnelles identifiables (PII).** Configurez des stratégies de _masquage des données_ dans les paramètres ETL avant de traiter tout contenu réglementé. Définissez les types de champ (_PHI_, _PII_ et identifiants financiers) masqués avant que les entrées atteignent le grand livre. **Ne le remettez pas à plus tard.** - **Attribuez l'étendue de l'Espace de données et les ensembles d'autorisations.** Étendez le traitement à l'_espace de données_ approprié et configurez des _ensembles d'autorisations_ pour contrôler la création de schémas, l'exécution de tâches par lot, l'invocation d'API REST et l'activation en aval. - **Configurez l'authentification API (en pipeline de traitement transactionnel uniquement).** Créez une _application connectée_ avec les étendues _OAuth_ cdp_ingest_api et api. Pour les appelants internes de l'organisation, utilisez un _identifiant nommé_ qui pointe vers un _identifiant externe_. Pour des appelants externes, configurez des identifiants client _OAuth 2.0_ ou un flux porteur JWT. Testez et validez l'extraction avant de continuer. #### Phase 2 : Intégration et configuration de la cible - **SObject write-back :** Implémentez un élément _Apex_ (@InvocableMethod) ou _Flow_ qui mappe les champs de réponse JSON avec des champs _SObject_ . Utilisez Database.upsert() avec un ID externe pour éviter les doublons. Appliquez la _sécurité au niveau du champ_ sur les champs _SObject_ cibles. - **Pipeline DLO/DMO Data 360 :** Faites correspondre les champs DLO extraits aux DMO alignés sur le _modèle de données Customer 360_. Configurez des règles de résolution de l'identité pour lier des enregistrements de document à des _Individus unifiés_. Définissez des _Insights calculés_ et ajoutez des DMO pour Agentforce. Pour le pipeline de traitement transactionnel, acheminez d'abord la charge de travail JSON vers un objet lac de données via l'API _Ingestion_. - **SGBDR externe ou entrepôt de données :** Sélectionnez le modèle d'intégration : _MuleSoft_ (tissu d'intégration existant), appel externe HTTP _Apex_ (léger, natif de l'organisation), _événements de plate-forme_ avec l'abonné _Pub/Sub_ (piloté par l'événement) ou ETL (lot haut volume). Implémentez des mises à jour/insertions idempotentes en utilisant une empreinte de document ou un ID externe dans tous les chemins d'écriture externes. - **Parcours d'activation :** Connectez des actions Agentforce à des configurations de schéma pour l'extraction interactive. Configurer des déclencheurs _de flux_ ou _Apex_ pour les workflows de traitement automatisés et établir les cibles d'activation pour chaque groupe de champs. - **Traitement des erreurs (oléoduc de traitement transactionnel uniquement).** Configurez la surface de réponse HTTP complète : **200** (_réussi_, y compris des réponses _null_ partielles), **400** (_requête malformée_ ou _ID de schéma introuvable_), **413** (fichier dépassant 10 Mo), **5xx** (erreur de service). Implémentez un backoff exponentiel pour les tentatives _5xx_ avec au maximum 3 tentatives. Consignez la réponse JSON brute et l'ID de schéma à chaque appel. #### Phase 3 : Valider et préparer pour la production - **Testez les schémas avec des exemples de documents.** Soumettez des exemples représentatifs via l'interface _IA du document_ ou l'API REST. Confirmez la précision de l'extraction, la couverture de champ et le traitement des valeurs nulles dans les variations de présentation. - **Validez le traitement des champs nuls.** Vérifiez que toutes les cibles en aval peuvent gérer les valeurs _nulles_ pour les _champs introuvables_ dans un document. Notez que les contraintes _NOT NULL_ échouent silencieusement sans traitement explicite des valeurs nulles. - **Prévérifiez les tailles de fichier.** Vérifiez que les documents de production restent inférieurs à 10 Mo. Implémentez un prétraitement pour séparer ou compresser les documents qui approchent régulièrement de la limite. - **Validez l'extraction de bout en bout.** Pour le pipeline _par lot_, initiez une exécution complète et vérifiez que les champs extraits atterrissent correctement dans chaque niveau cible. Pour le pipeline de _traitement transactionnel_, suivez la réponse JSON à travers la couche d'_intégration_ jusqu'à la cible. Vérifiez l'exécution du déclencheur et du flux pour les cibles _SObject_, la liaison de résolution de l'identité pour les cibles _DLO/DMO_ et l'idempotence pour les cibles _RDBMS_. - **Confirmez le comportement Trust Layer.** L'ETL n'applique pas le masquage des _PII_ au contenu du document. Par conséquent, le LLM renvoie les données _PII_ en l'état dans les champs extraits. Vérifiez que vos champs de schéma, l'acheminement des données et le stockage en aval sont conçus pour gérer correctement la sortie contenant des informations d'identification personnelle, et vérifiez que toutes les exigences de conformité ou de rétention sont satisfaites hors de la plate-forme. - **Définissez les alertes du portefeuille numérique.** Configurez des alertes de consommation à 75 % et 90 % des crédits disponibles. Établissez des limites en taille de lot et des estimations de taux ad hoc dans le budget de crédit de chaque cycle. - **Validez la surveillance des lots (pipeline par lots uniquement).** Examinez les taux de réussite de l'extraction, les taux de champ nul et la réalisation des tâches dans la console de surveillance _Data 360_. Confirmez la propagation de la balise de l'UDLO à travers le DLO jusqu'au DMO dans le lignage des données. - **Valider le traitement des erreurs d'API (en pipeline de traitement transactionnel uniquement).** Testez toutes les conditions d'erreur : **413** (documents de plus de 10 Mo), **400** (ID de schéma non valides), **200** (extractions valides avec des valeurs nulles partielles). Vérifiez que la logique de nouvelle tentative est activée dans les réponses **5xx** simulées sans créer d'écritures dupliquées. ## Conclusion Ce document met en évidence les fondements architecturaux de _Data 360 Document AI_: - Deux pipelines de traitement et quand les utiliser - Le modèle de configuration du schéma - Cadre de décision du niveau cible - Contraintes technologiques fondamentales - Modes d'échec - Alignement sur le _Well-Architected Framework_ Le [Guide de démarrage rapide pour architectes](/docs/architect/fr-fr/fundamentals/guide/data360-document-ai#guide-de-démarrage-rapide-pour-les-architectes) fournit la séquence de configuration d'une validation de concept sandbox. La posture architecturale principale prend en charge les données dérivées de documents qui sont régies par la couche _Schéma_, traitées via un pipeline LLM appliqué par ETL et livrées au même cycle de vie des données _Data 360_ qui régit toutes nos autres données d'entreprise. Les architectes qui appliquent ces principes (sélection du pipeline approprié, conception de schémas au niveau du type de document et conception pour des modes de défaillance avant la production) développent des capacités d'extraction qui évoluent et perdurent dans le cadre des exigences réglementaires de gouvernance de l'industrie. ### À 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_ Platform. Il dirige les initiatives du Conseil 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. **Ananth Anto** est directrice de la gestion des produits chez Salesforce _Data 360_ et dirige les initiatives d’IA de _documents et Data Graph_. Basé à Bangalore, il travaille avec des clients professionnels pour résoudre des défis réels de traitement de documents et d'intelligence des données. Il aime explorer les cas d’utilisation _d’entreprise_ pour l’_IA générative (IA générative)_. **Nishan Naseer** est architecte en génie logiciel chez Salesforce. Il travaille sur _le traitement non structuré_ des données, les pipelines _RAG_ et _l'intelligence documentaire_. Il est passionné par l'exploitation de la puissance de l'IA pour relever des défis réels et trouver des solutions créatives aux problèmes complexes des clients.