La thèse d’Atlan : créer de la valeur avec l’IA grâce au contexte d’entreprise déplace l’attention au-delà des modèles

Atlan remet en cause l’approche privilégiant les modèles pour l’IA d’entreprise, estimant que même des systèmes performants ne disposent pas encore de la compréhension métier nécessaire pour accomplir un travail utile. Créer de la valeur avec l’IA grâce au contexte d’entreprise, sujet d’un article MIT Technology Review Insights du 28 octobre, soumet cette affirmation à l’examen. La question est de savoir si les organisations ont besoin d’une couche d’infrastructure supplémentaire, d’une meilleure gestion des connaissances existantes, ou des deux.

Cet argument s’inscrit lui-même dans un contexte commercial. L’article émane de la branche de contenu sur mesure de MIT Technology Review, et non de sa rédaction. Les documents de conférence d’Atlan indiquent que l’étude associée a été produite avec l’entreprise. Cette relation importe lorsqu’on évalue un diagnostic qui soutient également le positionnement produit du fournisseur.

Work IQ de Microsoft fournit une comparaison utile : un autre fournisseur organise lui aussi sa stratégie d’IA d’entreprise autour du contexte métier. La tension centrale dépasse la concurrence entre fournisseurs. Les organisations veulent une IA capable d’effectuer du travail, mais leurs définitions, autorisations et règles opérationnelles nécessitent souvent une interprétation humaine. Acheter l’accès à un modèle ne résout pas ces questions.

Créer de la valeur avec l’IA grâce au contexte d’entreprise dépasse le modèle

L’analyse du contexte d’entreprise du 28 octobre présente un problème de déploiement familier à travers le prisme privilégié par Atlan. Les outils d’IA peuvent répondre rapidement tout en mécomprenant l’entreprise qu’ils servent. Prukalpa Sankar, cofondatrice d’Atlan, soutient qu’une infrastructure de contexte peut contribuer à combler cet écart.

Une couche de contexte est une infrastructure qui fournit aux systèmes d’IA les définitions métier, relations, politiques et autres informations nécessaires pour interpréter les données de l’entreprise. Ce concept importe, car trouver une information et en comprendre la signification métier sont deux tâches différentes. Un document peut contenir une réponse sans établir que cette réponse reste faisant autorité.

Cette évolution constitue un argument commercial plus explicite sur l’origine de la valeur de l’IA d’entreprise, plutôt qu’une avancée technique nouvellement vérifiée.

Cette distinction permet de garder l’information dans de justes proportions. L’article n’établit pas qu’une infrastructure de contexte entraîne à elle seule de meilleurs rendements financiers. Il propose une explication aux déploiements décevants et une orientation pour y remédier. Les acheteurs devraient évaluer cette explication séparément de toute mise en œuvre particulière.

Prenons un flux de travail commercial illustratif. Un assistant trouve une fiche client, résume les échanges récents et rédige une recommandation de renouvellement. Chaque document récupéré peut être exact pris isolément. La recommandation peut néanmoins échouer si l’assistant confond l’entité de facturation avec sa société mère ou ignore une exception approuvée.

Un meilleur modèle pourrait reconnaître l’ambiguïté et poser une question utile. Une définition métier maintenue pourrait résoudre l’ambiguïté avant le début de la génération. Ces approches se complètent, mais elles traitent différentes parties de la défaillance. Considérer chaque erreur comme un problème de modèle masque cette distinction.

Créer de la valeur avec l’IA grâce au contexte d’entreprise modifie donc la conversation d’achat. Au lieu de demander uniquement quel système produit la réponse la plus convaincante, les acheteurs doivent se demander ce qui rend une réponse valide au sein de leur organisation. Cela inclut la question de savoir qui a approuvé la règle sous-jacente et à quel moment elle a changé pour la dernière fois.

La relation éditoriale mérite également attention. L’événement de recherche sur le contexte d’Atlan a promu un accès anticipé à une étude produite en association avec l’entreprise. Cela justifie de considérer l’argument comme une contribution au débat soutenue par un fournisseur. Cela ne justifie pas d’écarter le problème sous-jacent.

L’implication pratique est plus étroite que le vaste récit commercial. Le contexte est une source crédible d’échec pour l’IA d’entreprise, mais son importance doit être établie pour chaque flux de travail. Les organisations ont toujours besoin de preuves reliant l’intervention proposée à une amélioration mesurable. Sans ce lien, le contexte devient une autre explication difficile à tester.

Les responsables métier héritent du problème de fiabilité de l’IA

L’argument du contexte met sous pression les responsables métier autant que les équipes technologiques. Si un assistant comprend mal une politique approuvée, modifier le modèle peut aider. Si les départements ne s’accordent pas sur la politique elle-même, l’organisation doit résoudre ce désaccord avant qu’un logiciel puisse l’appliquer de manière cohérente.

L’IA d’entreprise fait de la responsabilité négligée des connaissances un enjeu opérationnel.

Un développeur IA peut connecter un référentiel de documents sans avoir l’autorité de décider quelle politique prévaut sur une autre. Une équipe de sécurité peut appliquer des restrictions d’accès sans décider comment la finance définit un client. Ces responsabilités se recoupent, mais n’appartiennent pas à la même personne.

Cela crée une charge de mise en œuvre différente de celle liée à l’installation d’une interface conversationnelle. Quelqu’un doit identifier les sources faisant autorité, désigner des responsables, documenter les exceptions et maintenir ces décisions. Ce travail peut révéler des désaccords que les employés géraient auparavant au moyen de conversations informelles. L’automatisation rend ces désaccords plus difficiles à laisser non résolus.

Pour les responsables financiers, la pression concerne la cohérence. Un assistant répondant à une question de revenus a besoin de la définition comptable appropriée, de la période de reporting et du périmètre organisationnel. Une explication fluide ne compense pas le choix de la mauvaise mesure. Le responsable métier doit rendre l’interprétation voulue disponible et révisable.

Pour les responsables de service, la pression concerne l’applicabilité. Un agent, c’est-à-dire un système d’IA qui sélectionne des étapes ou utilise des outils pour accomplir une tâche, a besoin des circonstances pertinentes du client. Une politique de remboursement valide peut varier selon le contrat ou la région. Récupérer la politique générale n’est qu’une partie de la décision.

Ces exemples sont illustratifs plutôt que des résultats clients rapportés. Ils montrent pourquoi la responsabilité du contexte devient déterminante lorsque les logiciels passent de la rédaction de texte à la recommandation d’actions. Un résumé erroné génère du travail de correction. Une action erronée peut également créer une obligation qu’une autre équipe doit annuler.

Les équipes achats font face à un défi connexe. Une plateforme de contexte peut promettre des définitions communes, mais le contrat ne peut garantir que les départements s’accorderont sur celles-ci. Les acheteurs doivent distinguer les responsabilités du fournisseur de celles de l’organisation. Dans le cas contraire, un achat d’infrastructure peut masquer une décision opérationnelle inachevée.

Les travailleurs du savoir rencontrent le même problème à une plus petite échelle. Une archive interrogeable aide les personnes à localiser des contenus, tandis qu’une base de connaissances faisant autorité établit quel contenu doit guider le travail. La distinction entre les connaissances personnelles et d’équipe devient pertinente lorsque les souvenirs individuels alimentent des décisions partagées.

La réponse à court terme devrait suivre la défaillance traitée. L’absence de sources appelle une meilleure couverture. Des définitions contradictoires appellent une responsabilité claire et une résolution. Un raisonnement incorrect appelle des changements du modèle ou de l’application. Regrouper ces catégories dans un seul score d’exactitude peut masquer l’endroit où une intervention est nécessaire.

Avec le temps, la pression se déplace vers la maintenance. Le contexte métier change lorsque les produits, contrats, équipes et politiques évoluent. Un déploiement performant au lancement peut devenir peu fiable sans aucune mise à jour du modèle. L’argument du contexte est donc aussi une affirmation concernant une responsabilité opérationnelle continue.

Microsoft montre pourquoi le contexte devient une question de plateforme

Microsoft fournit une comparaison concrète, car l’entreprise décrit elle aussi le contexte d’entreprise comme une infrastructure partagée. Dans son compte rendu du 11 juin sur l’utilisation interne de Work IQ, l’entreprise explique comment les informations organisationnelles permettent des réponses d’IA plus pertinentes. Elle présente le contexte comme une partie de l’environnement qui entoure les assistants.

Microsoft affirme que Work IQ s’appuie sur les signaux du lieu de travail et respecte les autorisations existantes. Ses exemples internes incluent la connexion d’informations de réunion avec les participants et l’application de circonstances propres aux employés à des recommandations. Il s’agit d’exemples rapportés par l’entreprise, et non de mesures indépendantes des retours métier. Ils montrent néanmoins qu’un fournisseur s’attaque au même problème général.

La question concurrentielle porte sur l’endroit où la compréhension métier doit résider et sur la manière dont elle peut être réutilisée à grande échelle.

L’approche de l’intelligence du lieu de travail de Microsoft décrit un contexte qui se développe dans son environnement de travail. L’argument d’Atlan se concentre sur la fourniture d’une compréhension métier à travers les systèmes. Ces positions soulèvent différentes questions pour les acheteurs, même lorsque les deux fournisseurs utilisent un langage similaire.

Pour une organisation concentrée dans un environnement logiciel particulier, le contexte intégré à cet environnement peut offrir un point de départ naturel. Les documents, identités et enregistrements de collaboration existants s’y trouvent déjà à proximité. L’acheteur doit toujours établir quelles sources sont couvertes et si l’interprétation qui en résulte s’applique au-delà de cet environnement.

Pour une organisation utilisant plusieurs systèmes métier, la réutilisation devient plus importante. Une définition maintenue pour un assistant financier ne devrait pas diverger silencieusement de la définition utilisée par un assistant opérationnel. Un contexte partagé promet de réduire cette duplication. Sa réussite dépend des détails d’intégration et de gouvernance.

Il ne s’agit pas d’un simple affrontement entre architecture centralisée et distribuée. Une architecture est l’organisation des composants et de leurs responsabilités. Un service central peut diffuser des définitions obsolètes, tandis qu’un contexte propre à une application peut rester exact dans un périmètre limité. L’emplacement seul ne détermine pas la qualité.

La comparaison la plus utile concerne le changement. Lorsqu’une définition évolue, quelles applications reçoivent la mise à jour ? Lorsqu’un accès est révoqué, quelles représentations stockées cessent d’exposer l’information ? Lorsqu’une réponse est contestée, les réviseurs peuvent-ils reconstituer la source et la règle utilisées ? Ces questions relient la conception de plateforme aux conséquences opérationnelles.

La portabilité mérite également attention. Les acheteurs devraient se demander si des définitions approuvées peuvent passer d’un outil à l’autre sans perdre leur responsabilité, leur historique des versions ou leurs restrictions d’accès. Exporter du texte est plus simple que préserver son autorité. Une migration qui conserve les mots mais perd l’applicabilité peut recréer le problème initial.

La comparaison entre fournisseurs soutient donc un jugement plus large sans démontrer la supériorité de l’approche de l’un ou l’autre. Le contexte devient une responsabilité de plateforme, car plusieurs applications ont besoin de la même compréhension métier. Cela crée une opportunité pour une infrastructure partagée, ainsi que le risque de rendre de nombreuses applications dépendantes d’une erreur commune.

Pour les acheteurs, la réponse utile consiste à examiner un flux de travail qui franchit une véritable frontière organisationnelle. Une démonstration limitée à une collection de documents bien ordonnée laisse la question centrale sans réponse. La preuve pertinente est de savoir si le contexte reste cohérent lorsque l’information circule entre départements, applications et responsables des décisions.

Les preuves de récupération étayent une affirmation plus limitée

La génération augmentée par récupération, ou RAG, récupère des informations pertinentes et les fournit à un modèle avant que celui-ci ne réponde. C’est une méthode établie pour relier les réponses générées à des connaissances externes. Ses limites contribuent à expliquer pourquoi l’argument du contexte d’entreprise attire l’attention.

Les recherches d’Anthropic de septembre 2024 offrent un exemple technique. Sa méthode Contextual Retrieval ajoute des informations explicatives aux fragments de documents avant leur indexation. L’objectif est de préserver un sens susceptible de disparaître lorsqu’un passage est séparé de son document d’origine.

Anthropic a rapporté une réduction de 49 % des échecs de récupération en combinant ses techniques contextuelles, et une réduction de 67 % en ajoutant un reranking. Le reranking est une seconde étape de sélection qui réordonne le matériel récupéré selon sa pertinence. Il s’agissait de résultats issus des évaluations de l’entreprise, et non de mesures de retours financiers pour les entreprises.

Une meilleure récupération soutient l’argument du contexte, mais elle ne démontre pas qu’une plateforme complète de contexte d’entreprise soit nécessaire.

La recherche sur la récupération contextuelle traite d’un échec précis : un système ne trouve pas une information pertinente parce qu’un fragment manque de sens environnant. C’est plus restreint que la résolution de politiques d’entreprise contradictoires. C’est également plus restreint que la détermination de l’autorité d’un utilisateur pour effectuer une action.

Cette distinction compte dans les décisions d’achat. Si un assistant de support manque des réponses parce que les fragments de documents ne comportent pas de détails d’identification, il convient d’étudier des changements de récupération. S’il trouve le bon passage mais l’applique incorrectement, l’échec se produit ailleurs. Une proposition d’infrastructure étendue devrait expliquer quel échec elle traite.

Un exemple de contrat illustre plus clairement cette séparation. Un passage indique qu’un client bénéficie d’une exception, mais le nom du client figure sur une page précédente. Préserver cette relation peut améliorer la récupération. Établir si l’exception reste active exige des informations supplémentaires sur les dates, les avenants et l’autorité.

Un système peut donc récupérer avec précision tout en produisant une recommandation commerciale erronée. À l’inverse, un flux de travail aux sources limitées et maintenues peut fonctionner correctement sans vaste service de contexte partagé. L’intervention appropriée dépend de la tâche réelle, de ses besoins en information et des conséquences de ses défaillances.

La création de valeur par l’IA grâce au contexte d’entreprise doit être évaluée à travers cette chaîne de dépendances. La couverture des sources affecte ce que le système peut trouver. L’interprétation des sources affecte ce qu’il comprend. Les règles de décision affectent ce qu’il recommande. Les contrôles d’action affectent ce qu’il peut exécuter. Une amélioration dans une partie n’établit pas automatiquement une amélioration de l’ensemble.

Ce raisonnement modifie également la façon de lire les démonstrations. Une réponse réussie prouve qu’une configuration donnée a traité une question donnée dans des conditions données. Elle n’établit pas une fiabilité générale entre les services. Les acheteurs ont besoin d’éléments probants incluant des entrées ambiguës, des politiques modifiées et des sources contradictoires.

L’argument technique le plus solide identifiera l’échec initial, l’intervention de contexte et la différence qui en résulte. Garder le modèle et la tâche comparables aide à isoler ce qui a changé. Présenter séparément le succès de la récupération et l’exactitude de la décision facilite l’interprétation du résultat et évite qu’un gain limité ne devienne une affirmation plus large.

Davantage de contexte peut diffuser plus loin la mauvaise réponse

La thèse sceptique part d’un problème simple : le contexte métier peut être erroné. Une définition partagée peut être obsolète, incomplète ou contestée. La fournir de façon cohérente peut rendre les résultats concordants tout en les laissant incorrects. La concordance constitue un indice utile de cohérence, mais une preuve insuffisante de vérité.

Une couche de contexte peut distribuer l’autorité sans établir que cette autorité est justifiée.

Cela importe lorsque les organisations transforment des connaissances informelles en règles maintenues. Des employés expérimentés savent parfois qu’un processus documenté ne convient pas à une situation. Encoder ce jugement exige de décider quelles exceptions sont légitimes. Extraire automatiquement une déclaration d’une conversation ne détermine pas si elle doit devenir une politique.

Un participant à une réunion peut décrire une solution de contournement temporaire. Un autre employé peut répéter une pratique obsolète. Un document de projet peut consigner une proposition abandonnée. Chaque source apporte des informations, mais chacune possède un degré d’autorité différent. Les traiter comme équivalentes crée un problème de gouvernance avant même que la génération ne commence.

Il existe également une limite au niveau du modèle. Le profil de risque de l’IA générative du NIST décrit la confabulation, c’est-à-dire du contenu faux ou erroné généré avec assurance, comme un risque caractéristique. Il note également que les explications et citations générées peuvent induire les utilisateurs en erreur. Un matériau source pertinent ne supprime pas la nécessité d’évaluer les résultats.

L’analyse du NIST soutient une interprétation prudente de la thèse du contexte. De meilleures informations peuvent pallier les connaissances manquantes sans garantir un raisonnement correct. Un système peut mal appliquer une règle valide ou présenter de façon excessive une inférence incertaine. La qualité du contexte et la fiabilité des résultats exigent un examen lié, mais distinct.

Les autorisations créent un autre point de pression. La capacité d’un employé à lire un document ne l’autorise pas nécessairement à permettre à un système automatisé d’agir sur son contenu. Un service de contexte doit entretenir une relation claire avec les contrôles régissant les actions en aval. Sinon, des informations exactes peuvent étayer une décision non autorisée.

Le dossier financier reste également incertain. Maintenir les définitions, résoudre les différends, vérifier les autorisations et examiner les échecs consomment tous du temps de personnel. Une partie de ce travail peut améliorer les processus existants au-delà de l’IA. Les acheteurs devraient néanmoins en tenir compte lorsqu’ils évaluent l’économie du déploiement.

Une organisation peut obtenir de meilleures réponses tout en augmentant le travail total nécessaire à leur production. Une autre peut réduire suffisamment l’effort de révision pour justifier une maintenance substantielle. La comparaison pertinente englobe l’ensemble du flux de travail, plutôt que la vitesse visible de génération. Il s’agit d’une exigence analytique, et non d’un résultat rapporté dans l’article source.

Créer de la valeur par l’IA grâce au contexte d’entreprise exige également d’accepter les limites. Lorsqu’un conflit de politique reste non résolu, un assistant utile devrait exposer le conflit. Lorsque l’autorité n’est pas claire, il devrait acheminer la décision de manière appropriée. Un système qui produit toujours une réponse assurée peut dissimuler l’incertitude organisationnelle même que l’infrastructure de contexte devrait révéler.

La position sceptique n’exige donc pas de rejeter l’investissement dans le contexte. Elle exige une affirmation plus précise sur ce que l’investissement modifie. Un fournisseur devrait identifier les erreurs qui deviennent moins fréquentes, les responsabilités qui demeurent du ressort du client et les modes de défaillance qui persistent. Cela rend la proposition testable.

Les prochaines preuves devraient relier le contexte au travail achevé

Au cours des prochains mois, les signaux les plus utiles concerneront les preuves de déploiement plutôt que le nouveau vocabulaire. La discussion d’octobre établit une proposition claire : la compréhension métier mérite davantage d’attention aux côtés de la capacité des modèles. L’étape suivante consiste à déterminer où cette proposition produit des bénéfices mesurables.

La thèse du contexte devient plus solide lorsque des connaissances métier maintenues améliorent le travail achevé dans des conditions changeantes.

Le premier signal est une comparaison documentée au sein d’un véritable flux de travail. Les acheteurs devraient rechercher des résultats montrant ce qui s’est passé avant et après une intervention de contexte définie. La comparaison devrait inclure les erreurs de source, les erreurs de décision, les corrections humaines et les tâches achevées. Un résultat qui isole l’amélioration renforcerait l’argument.

Une démonstration n’offrant que des réponses réussies sélectionnées laisserait intacte l’incertitude centrale. Il en serait de même d’une comparaison qui modifie simultanément le modèle, l’interface, la collection de sources et le processus de révision. Ces changements pourraient améliorer le produit, mais ils rendraient difficile d’isoler la contribution du contexte d’entreprise.

Le signal suivant est un comportement fiable après un changement métier. Une politique révisée, une autorisation révoquée ou un client renommé crée un point d’observation utile. Le système adopte-t-il le changement dans les applications concernées ? Conserve-t-il suffisamment d’historique pour expliquer les réponses antérieures ? Un comportement cohérent étayerait l’argument en faveur d’une infrastructure partagée.

Des contradictions persistantes affaibliraient cet argument. Si chaque application nécessite encore une réparation manuelle, la couche commune proposée n’a pas éliminé la maintenance dupliquée. Si des informations obsolètes subsistent dans des magasins dérivés, l’organisation doit comprendre comment les corrections se propagent. La qualité de la configuration initiale ne peut répondre à ces questions.

Le dernier signal est la charge opérationnelle totale. Les organisations devraient examiner si les réviseurs passent moins de temps à corriger les résultats après avoir pris en compte la maintenance du contexte. Elles devraient également suivre si les cas non résolus atteignent les bonnes personnes. Une réduction du travail de révision visible signifie peu si le travail de préparation caché augmente plus vite.

Ces signaux ne dépendent pas de la victoire d’un fournisseur particulier. Microsoft, Atlan et les développeurs d’applications peuvent apporter des éléments probants par des approches différentes. La distinction utile est celle entre les affirmations sur les capacités disponibles et les observations sur un usage durable. Les acheteurs ont besoin des deux, mais ne devraient pas les confondre.

Pour les travailleurs du savoir, la pertinence immédiate est pratique. Un assistant qui sait où se trouvent les informations peut éviter des recherches. Un assistant qui comprend quelles informations s’appliquent peut étayer une décision. La valeur de cette compréhension supplémentaire dépend de la capacité des utilisateurs à l’examiner, la contester et la maintenir.

Commencez par un flux de travail où une réponse incorrecte crée une reprise identifiable. Examinez les échecs avec les personnes responsables de la politique sous-jacente, plutôt que de traiter chaque correction comme un problème de prompt. Distinguez les informations manquantes des définitions contradictoires, des erreurs de raisonnement et des actions inappropriées. Examinez ensuite si l’investissement de contexte proposé traite ces défaillances précises. Pour le travail individuel, un système de connaissances personnelles maintenu peut aider à organiser le matériel pertinent, tandis que les décisions partagées exigent toujours une autorité partagée. Créer de la valeur par l’IA grâce au contexte d’entreprise devient une proposition crédible lorsque cette distinction résiste au déploiement. Demandez au prochain fournisseur de montrer comment son système traite une règle modifiée, une source contestée et une décision qu’il devrait laisser non résolue.