La plateforme d’intelligence contractuelle d’Amazon s’attaque à l’angle mort de RAG sur les portefeuilles
Amazon a publié une architecture d’intelligence contractuelle articulée autour de huit champs extraits, créant une plateforme d’intelligence contractuelle Amazon capable de répondre aux questions que les conversations reposant uniquement sur RAG traitent mal.
Cette conception de référence cible un problème persistant pour les entreprises. Un chatbot peut souvent retrouver une clause de paiement dans un accord donné. Il devient peu fiable lorsqu’on lui demande d’additionner des valeurs, de comparer des dates ou de compter les documents non signés parmi des centaines de contrats.
La réponse d’Amazon n’est ni un prompt plus vaste ni une fenêtre de contexte plus longue. Elle sépare la compréhension des documents de l’analyse de portefeuille. Des agents IA extraient et vérifient les champs, une base de données effectue les calculs, et Amazon Quick offre aux utilisateurs une interface unique pour les deux flux de travail.
Cette distinction met sous pression les assistants contractuels fondés uniquement sur la récupération d’informations. Le système considère la génération augmentée par récupération, ou RAG, comme un composant parmi d’autres plutôt que comme la base de données de chaque question. Le résultat constitue un test utile pour déterminer où les agents d’entreprise ont leur place et où les systèmes de données conventionnels restent indispensables.
Ce qu’Amazon a réellement construit
La conception transforme chaque contrat téléversé à la fois en document interrogeable et en enregistrement structuré dans une base de données.
AWS a publié l’architecture d’intelligence contractuelle le 29 septembre 2026. Il s’agit d’une implémentation de référence, et non de l’annonce d’un service juridique autonome ou d’un déploiement client.
Une application React fournit l’interface utilisateur. Les PDF de contrats sont déposés dans un compartiment Amazon Simple Storage Service, ce qui déclenche un pipeline de traitement automatisé.
Le premier agent lit chaque PDF et en extrait huit champs. AWS indique que l’implémentation utilise Claude Sonnet 4.6 d’Anthropic et renvoie du JSON structuré avec un score de confiance pour chaque champ.
Un second agent lit indépendamment le même document. Selon AWS, ce vérificateur utilise Claude Haiku 4.5 et compare ses conclusions avec la sortie de l’extracteur.
Les deux agents s’exécutent via le SDK open source Strands Agents sur Amazon Bedrock AgentCore. AgentCore fournit l’environnement d’exécution géré où le code des agents s’exécute et passe à l’échelle.
Un désaccord ne signifie pas automatiquement que le vérificateur l’emporte. Pour le statut des signatures, le système appelle Amazon Textract comme arbitre visuel. L’enregistrement vérifié est ensuite placé dans Amazon Aurora PostgreSQL.
Le PDF original suit un autre chemin. Il reste accessible via une base de connaissances pour la récupération propre à chaque document, y compris les questions sur les modalités de paiement ou les clauses individuelles.
Amazon Quick se place au-dessus de ces deux sources. Sa capacité Quick Sight affiche des tableaux de bord construits à partir des enregistrements de la base de données. Son interface conversationnelle peut orienter les questions vers l’analytique structurée ou la récupération de documents.
Cette distinction importe parce que ces sources répondent à différents types de questions. La recherche d’une clause nécessite un texte pertinent. Un total de portefeuille exige tous les enregistrements applicables et un calcul fiable.
La conception diffuse également l’état du pipeline vers le navigateur via des connexions WebSocket. Les utilisateurs peuvent voir si un fichier est en cours d’extraction, de vérification, de contrôle ou de stockage.
Cette visibilité est plus qu’un simple raffinement d’interface. Un flux de travail d’entreprise devient plus facile à inspecter lorsque les utilisateurs peuvent identifier l’étape de traitement à l’origine d’un délai ou d’un désaccord.
AWS indique qu’un contrat peut traverser le pipeline en quelques secondes dans des conditions typiques. Cela reste une affirmation de conception, et les performances réelles dépendront de la longueur des documents, de la concurrence, de la disponibilité des modèles et de la configuration régionale.
Cette publication fait suite à une précédente conception AWS de gestion des contrats datant de janvier 2026. Cette version mettait l’accent sur plusieurs agents spécialisés pour les tâches juridiques, de risque, de conformité et de flux de travail.
La nouvelle architecture est plus ciblée et plus révélatrice. Elle se concentre sur la précision de l’extraction et l’analytique de portefeuille, qui exposent des faiblesses souvent dissimulées par les démonstrations conversationnelles.
Pourquoi RAG ne peut pas totaliser un portefeuille de contrats
RAG sélectionne des passages pertinents, tandis que l’analyse de portefeuille exige des enregistrements complets et des calculs maîtrisés.
La recherche originale sur RAG associait un modèle de langage à des connaissances externes récupérées. Ce modèle aide un système à répondre à des questions sans placer toute une collection de sources dans son prompt.
Un système typique divise les documents en fragments et crée des représentations vectorielles de ceux-ci. Lorsqu’un utilisateur soumet une question, la recherche sémantique récupère un ensemble limité de fragments étroitement liés.
Ce mécanisme fonctionne bien lorsque la réponse recherchée se trouve dans quelques passages. Une question sur les clauses de résiliation peut récupérer la clause pertinente sans relire chaque page.
Le mécanisme devient problématique lorsque la question couvre l’ensemble de la collection. Prenons le cas d’un responsable des achats qui demande la valeur totale engagée dans tous les accords actifs.
Le récupérateur sélectionne toujours les fragments qui semblent les plus pertinents. Il ne garantit pas que chaque accord actif apporte une valeur complète, correctement normalisée.
Augmenter le nombre de fragments récupérés ne résout pas entièrement le problème. Les contrats contiennent des libellés répétés, des avenants, des tableaux, des notes de bas de page et des dates contradictoires. Les passages pertinents peuvent aussi dépasser le contexte exploitable par le modèle.
La capacité manquante n’est pas la fluidité conversationnelle. C’est la couverture.
AWS illustre le problème avec un portefeuille hypothétique de 250 contrats. Avec 10 à 20 pages chacun, ce portefeuille peut contenir jusqu’à 5 000 pages.
Une personne peut finir par inspecter chaque document et tenir une feuille de calcul. Toutefois, chaque nouvel accord ou avenant peut rendre cette feuille obsolète.
Un assistant RAG peut répondre plus rapidement, tout en omettant des enregistrements situés hors de sa fenêtre de récupération. La réponse peut paraître complète même lorsque le calcul ne couvre qu’un sous-ensemble.
C’est l’enjeu central derrière la plateforme d’intelligence contractuelle d’Amazon : conversation reposant uniquement sur RAG contre extraction suivie de requêtes de base de données.
Dans l’approche par extraction, chaque contrat passe par le même schéma. Les valeurs, dates, contreparties, états de signature et autres champs sélectionnés deviennent des lignes et des colonnes.
Une base de données peut alors filtrer les enregistrements actifs, les regrouper par fournisseur et calculer les totaux. Elle peut également renvoyer les enregistrements à l’origine du résultat pour une inspection plus approfondie.
Cette architecture ne rend pas RAG obsolète. Elle lui attribue un rôle plus ciblé, correspondant à ses atouts.
La récupération de documents reste précieuse pour les questions qui résistent à la normalisation. Les clauses de paiement, les dispositions de responsabilité, les exceptions et les obligations inhabituelles nécessitent souvent leur contexte environnant.
L’analytique structurée répond à une autre couche de besoins. Elle prend en charge des questions telles que le nombre d’accords arrivés à expiration, les contrats non signés ayant la plus grande valeur ou les renouvellements approchant d’une date sélectionnée.
Les deux voies peuvent se compléter. Une requête structurée identifie les contrats nécessitant une attention, tandis que la récupération ramène les clauses justificatives.
Cette séparation produit également un modèle d’échec plus clair. Les erreurs de récupération affectent une réponse documentaire. Les erreurs d’extraction peuvent affecter les tableaux de bord et chaque agrégat construit à partir du champ stocké.
Le pipeline d’ingestion devient ainsi plus déterminant que l’interface de conversation. La couche conversationnelle n’est fiable qu’à la hauteur des enregistrements et des sources de récupération qui la sous-tendent.
Comment la plateforme d’intelligence contractuelle d’Amazon transforme le parcours des données
L’architecture déplace le travail le plus difficile du moment de la question vers celui de l’ingestion.
Un assistant reposant uniquement sur RAG reporte l’interprétation jusqu’à ce que quelqu’un pose une question. La plateforme d’intelligence contractuelle d’Amazon interprète certains champs contractuels lorsque chaque document entre dans le système.
Ce changement crée une couche analytique réutilisable. Une fois qu’une date de renouvellement a été extraite, vérifiée et stockée, plusieurs tableaux de bord et questions peuvent exploiter la même valeur normalisée.
La première étape est l’ingestion du document via Amazon S3. Un téléversement démarre le flux de traitement sans obliger un analyste à ouvrir manuellement le fichier.
L’agent d’extraction lit ensuite le PDF de manière native, selon AWS. Il produit les huit champs attendus et joint des scores de confiance que les composants en aval peuvent examiner.
Les scores de confiance sont des signaux, non des garanties. Ils peuvent aider à prioriser le travail de révision, mais ils n’établissent pas qu’une valeur extraite correspond au sens juridique d’une clause.
Le vérificateur indépendant introduit une seconde lecture. L’utilisation d’un autre membre de la famille de modèles vise à réduire les erreurs corrélées liées à la répétition du même processus d’extraction.
Cette idée rappelle une relecture par deux personnes, mais l’analogie a ses limites. Deux modèles du même fournisseur peuvent toujours partager des schémas d’entraînement, des angles morts et des faiblesses dans le traitement des documents.
AWS a évalué des combinaisons d’extracteurs et de vérificateurs sur 20 contrats. L’équipe a étiqueté manuellement huit champs dans chaque contrat, produisant 160 valeurs de référence.
Cette évaluation a laissé entendre que l’extracteur comptait davantage que le vérificateur. Selon les auteurs, un modèle d’extraction plus performant préservait les résultats lorsqu’il était associé à un vérificateur plus léger.
AWS indique également que des modèles plus puissants n’apportaient pas toujours une amélioration significative sur cet ensemble de données. L’entreprise recommande de tester les modèles disponibles par rapport aux contrats et aux critères d’acceptation de chaque organisation.
Cette réserve est importante. Vingt contrats constituent un test indicatif, non une preuve que la combinaison sélectionnée se généralisera à l’ensemble des secteurs, des langues ou des styles de rédaction.
Après vérification, la base de données devient le système de référence pour les questions agrégées. Amazon Quick se connecte à Aurora PostgreSQL et peut interroger des données en direct plutôt que d’attendre une exportation distincte.
Amazon Quick se connecte également à la base de connaissances contenant les documents sources. Son agent conversationnel peut donc prendre en charge les questions structurées et les recherches dans des documents individuels au sein d’une même interface.
Ce routage constitue le mécanisme architectural expliquant le fonctionnement de l’intelligence contractuelle d’Amazon. Le modèle n’effectue pas chaque calcul en lisant la prose contractuelle durant chaque conversation.
Pour une demande agrégée, la source structurée fournit des enregistrements filtrés et des calculs. Pour une demande propre à un document, la base de connaissances récupère le texte contractuel pertinent.
AWS présente des exemples de résultats fondés sur un portefeuille échantillon contenant 20 contrats. Ces exemples comprennent la valeur du portefeuille, les totaux des contrats expirés et les nombres d’accords signés et non signés.
Ces chiffres illustrent l’interface. Ils ne constituent pas des résultats opérationnels issus d’un portefeuille client divulgué et ne doivent pas être interprétés comme des preuves de performance.
Les tableaux de bord intégrés offrent une autre manière d’inspecter les mêmes données. Les utilisateurs peuvent consulter les totaux du portefeuille, le statut des signatures, les résultats d’extraction et les comparaisons de confiance sans quitter l’application.
Cette fondation partagée peut réduire les divergences entre les sorties du tableau de bord et celles de la conversation. Les deux interfaces peuvent s’appuyer sur les mêmes enregistrements vérifiés de la base de données pour les questions analytiques.
La conception préserve également l’accès au matériel source. Les analystes ne sont pas obligés de considérer une valeur de base de données comme le dernier mot lorsqu’une décision contractuelle exige la lecture de la clause.
Ce modèle hybride va au-delà des contrats. Les déclarations de sinistres, les dossiers de conformité, les baux et les dossiers d’intégration peuvent tous mêler des champs répétables à un langage propre à chaque document.
Il correspond également à un principe plus large de fusion des connaissances. Les faits structurés et le contexte source répondent à des objectifs différents, et les systèmes utiles nécessitent un pont gouverné entre les deux.
La vérification compte davantage qu’un appel de modèle supplémentaire
La partie la plus instructive de la conception est son refus de laisser les modèles de langage trancher chaque différend.
Lors des tests, AWS a constaté que le vérificateur qualifiait parfois de signés des blocs de signature vides. Dans certains cas de faux positifs, le niveau de confiance rapporté atteignait entre 95 et 100 %.
Le modèle reconnaissait des mots et une mise en page associés à la signature. Il considérait alors la présence d’un champ de signature comme la preuve que quelqu’un avait signé.
Cet échec met en lumière un problème récurrent de l’IA générative. Un score de confiance peut décrire la certitude interne du modèle sans prouver que la conclusion sous-jacente est correcte.
AWS a réagi en ajoutant Textract uniquement lorsque les deux modèles divergeaient sur le statut de la signature. Textract examine les caractéristiques visuelles afin de détecter des signatures manuscrites ou numériques.
Ce choix crée un contrôle en trois volets. Un modèle réalise l’extraction, un autre la vérifie, et un service spécialisé de vision par ordinateur résout une catégorie définie de désaccords.
Cette approche est plus adaptée que de demander à un troisième modèle de langage de voter. Un troisième modèle pourrait reproduire la même confusion sémantique entre une ligne de signature et une véritable signature.
Ce schéma limite également la vérification spécialisée aux cas contestés. Il préserve le flux de travail principal tout en appliquant une méthode technique différente là où les modèles manifestent une incertitude.
Cependant, Textract sert de départage pour la présence d’une signature, et non d’arbitre pour chaque champ. Les valeurs contractuelles, règles de renouvellement, dates et identités des parties peuvent créer d’autres ambiguïtés.
Un avenant peut remplacer une valeur antérieure. Une clause de renouvellement automatique peut nécessiter une interprétation contextuelle. Une signature peut exister alors que l’accord demeure incomplet pour une autre raison.
Ces cas exigent des règles d’escalade explicites. Le billet AWS indique que les désaccords non résolus doivent être transmis à un examinateur humain lorsque les services déterministes ne peuvent pas les trancher.
Cette voie humaine est au cœur d’une adoption responsable. Elle détermine si l’automatisation réduit le travail de routine ou masque simplement des dossiers incertains dans une base de données.
Le système doit conserver chaque valeur extraite, son emplacement source, les sorties des deux modèles et la résolution finale. Sans cela, les examinateurs ne peuvent pas reconstituer pourquoi un tableau de bord affiche un chiffre donné.
Les organisations ont également besoin de seuils spécifiques à chaque champ. Un nom de contact erroné et une date de résiliation erronée n’impliquent pas le même risque opérationnel.
Le cadre d’IA du NIST met l’accent sur les tests, l’évaluation, la vérification et la validation des systèmes d’IA. Les flux de travail contractuels ont besoin de ces pratiques au niveau des champs de données.
Les équipes devraient mesurer la précision, le rappel et les performances de correspondance exacte pour chaque champ. Elles devraient aussi suivre les taux de désaccord, les corrections apportées par les examinateurs et les erreurs découvertes après approbation.
La précision devrait être segmentée par type de document. Les PDF natifs, pages numérisées, tableaux, avenants, annotations manuscrites et accords multilingues peuvent se comporter différemment.
L’évaluation AWS sur 20 contrats offre une méthodologie de départ. Elle ne fournit pas une diversité suffisante pour établir la fiabilité en production pour le portefeuille d’une autre organisation.
Un pilote utile devrait échantillonner les documents qui créent le plus de risques. Cela inclut les modèles inhabituels et les fichiers de faible qualité, pas seulement les accords propres issus d’un formulaire standard.
La vérification à deux modèles de cette conception reste précieuse, car elle rend le désaccord observable. Elle crée un événement mesurable susceptible de déclencher des contrôles déterministes ou une revue humaine.
Pourtant, l’accord entre les modèles ne peut pas être traité comme une vérité terrain. Deux agents peuvent produire la même valeur erronée, surtout lorsque le texte source est ambigu.
Le contrôle essentiel est la traçabilité. Chaque valeur structurée doit permettre à un examinateur de remonter à la page, à la clause et à la décision d’extraction qui l’ont produite.
La précision, les accès et l’économie restent à démontrer
L’architecture de référence définit un mécanisme crédible, mais elle n’établit pas la préparation à la production pour chaque portefeuille de contrats.
La première incertitude concerne l’échelle d’évaluation. AWS a utilisé 20 contrats et 160 valeurs annotées pour comparer des combinaisons de modèles.
Cet échantillon peut révéler des différences évidentes entre les configurations. Il ne peut pas représenter l’ensemble des formats, rédactions, numérisations, langues et schémas d’avenants rencontrés dans les accords d’entreprise.
La deuxième incertitude porte sur la couverture du schéma. Huit champs peuvent alimenter des tableaux de bord utiles, mais les opérations contractuelles dépendent souvent d’obligations plus complexes et de dates conditionnelles.
Une date de renouvellement peut dépendre de délais de préavis. Une valeur peut combiner des frais engagés, des frais de consommation, des crédits ou des augmentations indexées.
Aplatir ces conditions dans un seul enregistrement peut créer une illusion de certitude. Le schéma doit préserver les réserves lorsqu’un champ ne peut pas être représenté sous la forme d’un simple nombre ou d’une date.
La troisième incertitude concerne l’évolution des modèles. AWS note que la disponibilité des modèles évolue et conseille aux développeurs de retester le système avant de s’appuyer sur de nouvelles options.
Un modèle de remplacement peut modifier le comportement d’extraction, même lorsque l’application environnante demeure inchangée. Les équipes de production ont donc besoin de jeux d’évaluation fixes et de contrôles de mise en production.
La quatrième incertitude concerne l’autorisation. Les contrats peuvent contenir des tarifs confidentiels, des informations sur les employés, des obligations de sécurité et des conditions stratégiques liées aux fournisseurs.
AWS indique qu’AgentCore prend en charge l’isolation des sessions, tandis que des contrôles de politiques peuvent être placés en dehors du code des agents. La documentation d’AgentCore décrit des environnements d’exécution distincts pour les sessions utilisateur.
Toutefois, l’isolation de l’infrastructure ne crée pas automatiquement des autorisations métier correctes. La documentation AWS précise que les backends clients doivent maintenir la relation entre les utilisateurs et les identifiants de session.
Les développeurs doivent également appliquer les accès aux niveaux du document, de la base de données, du tableau de bord et des outils de l’agent. Une interface de chat ne devrait pas révéler un enregistrement que le même utilisateur ne peut pas ouvrir ailleurs.
La cinquième incertitude est celle de l’économie opérationnelle. Le billet AWS fournit un modèle de coûts indicatif, mais les conditions commerciales évoluent et les charges de travail des portefeuilles diffèrent.
Les coûts de traitement dépendent du nombre de pages, des appels de modèles, des nouvelles tentatives, du stockage, de la capacité de la base de données, de la concurrence et de la fréquence des requêtes utilisateur. La revue humaine peut devenir la variable la plus importante.
Un dossier économique crédible devrait mesurer le coût par enregistrement accepté, et non le coût par invocation de modèle. Une extraction peu coûteuse qui génère un travail de revue considérable n’est pas économiquement bon marché.
Le paysage concurrentiel offre également plusieurs voies de mise en œuvre. Le modèle d’extraction de contrats de Microsoft renvoie des champs structurés issus de contrats via Document Intelligence.
Le Document AI de Google convertit lui aussi des documents non structurés en données structurées pour un traitement en aval.
Ces produits diffèrent par leurs schémas, leur personnalisation, leur orchestration, leurs analyses et leur intégration cloud. Les acheteurs devraient comparer la boucle de contrôle complète plutôt qu’un seul benchmark d’extraction.
La différenciation d’Amazon dans cette conception réside dans la connexion entre les agents, la vérification, une base de données relationnelle, l’analytique intégrée et les questions-réponses sur les documents.
Cette intégration peut séduire les organisations opérant déjà sur AWS. Elle peut également accroître l’engagement architectural à travers le stockage, les modèles, les bases de données, l’analytique et les contrôles d’identité.
Les équipes devraient tester la portabilité avant la production. Les enregistrements extraits et les données de provenance devraient utiliser des schémas documentés qui restent accessibles en dehors d’une interface conversationnelle unique.
Elles devraient également définir la responsabilité des échecs. Les équipes achats, opérations juridiques, ingénierie des données et sécurité peuvent chacune supposer qu’un autre groupe valide les résultats.
Un flux de travail a besoin d’un responsable clairement désigné pour les changements de schéma, les seuils d’évaluation, les files d’exceptions et les revues d’accès. Sans cette responsabilité, le système peut automatiser l’incohérence.
La leçon plus large est que l’intelligence contractuelle est un projet de gouvernance des données doté d’une couche d’ingestion par IA. La traiter comme un déploiement de chatbot sous-estime le travail nécessaire.
Ce que les acheteurs devraient surveiller ensuite
Trois signaux indiqueront si cette architecture devient un système d’exploitation fiable pour les données contractuelles ou reste une démonstration de référence convaincante.
Le premier signal est la disponibilité de preuves d’évaluation issues de jeux de contrats plus vastes et plus diversifiés. Les acheteurs ont besoin de résultats au niveau des champs couvrant les numérisations, avenants, tableaux, langues et schémas de rédaction peu fréquents.
La précision publiée ne suffira pas à elle seule. Des preuves utiles devraient divulguer la composition du jeu de données, les catégories d’erreurs, les politiques de revue et la fréquence à laquelle les deux modèles se sont accordés sur une valeur incorrecte.
De meilleures preuves renforceraient l’affirmation centrale d’Amazon selon laquelle une vérification indépendante améliore la fiabilité. Des erreurs corrélées persistantes affaibliraient l’argument en faveur de la conception à deux modèles.
Le deuxième signal est une gestion des exceptions de niveau production. La plateforme a besoin de files de revue configurables, de citations des sources, d’un historique des approbations et de voies claires pour les désaccords non résolus.
Amazon Quick comprend des capacités de supervision humaine, mais les organisations doivent montrer comment ces contrôles s’intègrent aux opérations contractuelles quotidiennes. Les examinateurs ont besoin de contexte, pas d’un autre score de confiance inexpliqué.
Un flux de travail mature devrait permettre à quelqu’un de corriger un champ, de documenter la raison et de mettre à jour l’analytique en aval sans perdre la sortie d’origine.
Les déploiements réussis distingueront également l’automatisation à faible risque des décisions à haut risque. Les décomptes de portefeuille peuvent tolérer des contrôles différents de ceux appliqués aux avis de résiliation ou aux engagements financiers.
Le troisième signal est l’adoption au-delà des charges de travail de démonstration. Surveillez les déploiements clients divulgués qui relient la qualité d’extraction à des résultats opérationnels mesurables.
Les indicateurs pertinents incluent le temps de revue, les taux de correction, la fréquence des enregistrements obsolètes et le pourcentage de contrats traités sans escalade. Ces mesures comptent davantage que la vitesse de réponse d’un chatbot.
La concurrence façonnera également l’adoption. Microsoft et Google prennent déjà en charge l’extraction structurée de documents, tandis que les plateformes de gestion du cycle de vie des contrats proposent des flux de travail spécialisés.
Amazon doit montrer que Quick et AgentCore réduisent le travail d’intégration sans limiter la flexibilité du schéma ni la gouvernance. Les concurrents doivent démontrer des parcours tout aussi cohérents, des documents jusqu’aux analyses de portefeuille vérifiées.
La plateforme d’intelligence contractuelle d’Amazon avance son argument le plus solide par son architecture, et non par la nouveauté de ses modèles. Elle reconnaît que la récupération, l’extraction, la vérification et le calcul sont des tâches distinctes.
Cette reconnaissance fournit aux équipes d’entreprise une règle de décision pratique. Conservez le RAG pour localiser et expliquer les passages sources. Utilisez des enregistrements structurés pour compter, trier, comparer et totaliser.
Placez ensuite les contrôles de revue là où une mauvaise réponse modifierait une décision juridique ou financière. Aucun score de confiance de modèle ne devrait contourner automatiquement ce jugement.
Pour les équipes qui évaluent l’IA contractuelle, l’étape suivante est un pilote représentatif. Sélectionnez des documents difficiles, annotez les champs requis, définissez des seuils d’acceptation et mesurez l’effort des examinateurs.
Demandez-vous si chaque réponse peut être retracée jusqu’à sa source. Testez les autorisations entre utilisateurs, contrats, tableaux de bord et sessions de chat. Recalculez les agrégats après les corrections et les avenants.
Surtout, comparez l’architecture hybride au processus qu’elle remplace. Produit-elle des données de portefeuille plus à jour, avec moins d’erreurs cachées et une piste d’audit défendable ?
C’est le test qui compte. Une plateforme d’intelligence contractuelle d’Amazon réussit lorsqu’elle rend l’ensemble du portefeuille interrogeable de manière fiable, et non simplement lorsqu’un contrat produit une réponse convaincante.
