Note de la rédaction : Au cours des deux dernières décennies, l'avantage concurrentiel des SaaS a été largement fondé sur l'interface utilisateur. Les tableaux de bord, les champs, les flux d'approbation et les habitudes des utilisateurs ne sont pas seulement des interfaces d'opération ; ils ont également façonné la manière dont les organisations travaillent et organisent leurs données. Lorsque l'IA peut directement lire les données, appeler des outils et exécuter des processus, la fidélité créée par la mémoire musculaire humaine commence à diminuer, et l'interface utilisateur n'est plus nécessairement l'interface centrale des logiciels d'entreprise.
Cela ne signifie pas que les systèmes d'enregistrement perdent leur valeur, mais que leur défense se déplace : de l'interface utilisateur et des habitudes d'utilisation vers les modèles de données, les systèmes de permissions, les responsabilités de conformité, la logique métier, les boucles d'exécution et les réseaux de collaboration multipartite. Les logiciels véritablement protégés à l'avenir ne seront peut-être plus simplement des bases de données enregistrant le travail humain, mais des systèmes d'action capables de capturer le contexte, d'initier des tâches, de coordonner des agents et de générer continuellement de nouvelles données pendant l'exécution.
Lorsque les logiciels deviennent headless, la question centrale des logiciels d'entreprise change également : la valeur ne réside plus seulement dans qui possède les données, mais dans qui peut organiser des actions autour des données.
The following is the original text:
Le mois dernier, Salesforce a annoncé l'ouverture de son API et le lancement d'un produit headless. En substance, cela signifie que Salesforce mise sur le fait que, à l'ère des agents, sa valeur fondamentale ne provient plus principalement de l'interface utilisateur, mais de la couche données. Il s'agit d'une repositionnement assez astucieux.
Cependant, il faut souligner que, sur le plan technique, cette publication ne semble pas apporter de changements substantiels. Les API que Salesforce répertorie désormais sous le nom de « produits headless » existent en grande partie depuis plusieurs années. Autrement dit, il s'agit davantage d'une campagne de marketing typique de Salesforce.
L'idée centrale de ce nouveau produit est que l'Agent peut accéder directement aux données du système d'enregistrement, sans avoir à interagir via une interface conçue pour les humains. L'interface traditionnelle servait à aider les utilisateurs humains à suivre les processus, gérer les tâches et faire avancer les flux de travail ; mais une fois que l'Agent intervient, la nécessité de cette couche d'interface diminue.
Ce qui mérite vraiment d’être discuté dans cette publication, ce n’est pas seulement ce que Salesforce a lancé comme nouveau produit, mais la question plus fondamentale qu’il soulève : si l’on retire l’interface utilisateur et que l’on ouvre uniquement la base de données sous-jacente, qu’est-ce qui reste d’un système d’enregistrement ? Quelle est la différence réelle entre cela et une base de données Postgres, un schéma de données bien conçu, et un ensemble d’API ?
En outre, les facteurs classiques qui ont autrefois conféré au système d'enregistrement une défense à long terme sont-ils toujours valables ? Ou de nouveaux critères de concurrence sont-ils apparus ?
À l'ère du SaaS, les systèmes de registre possèdent un avantage concurrentiel parce que les utilisateurs humains vivent longtemps dans leur interface. L'interface incarne les habitudes d'opération, les processus organisationnels et le stockage des données, ce qui crée un coût de migration élevé. Mais à l'ère des agents, cet avantage est en train de s'affaiblir. Les niveaux véritablement défensifs se déplacent d'une part vers les modèles de données, les systèmes de permissions, la logique des flux de travail et les capacités de conformité ; d'autre part vers les effets de réseau, la capacité à générer des données propriétaires et les capacités d'exécution dans le monde réel.
Lorsque les logiciels deviennent headless, où se déplace donc le fossé compétitif ?
L'interface utilisateur était autrefois le produit lui-même
Un système de référence (System of Record, SoR) désigne la source autorisée des données commerciales. C’est l’endroit où se trouve la version officielle des données relatives aux clients, aux employés ou aux transactions financières, et c’est également le système central à partir duquel d’autres outils lisent et écrivent des données. Le CRM est le système de référence pour les données liées aux revenus, le HRIS pour les données liées au personnel, et l’ERP pour les données financières et de trésorerie.
La force de ces systèmes ne réside pas seulement dans le fait qu'ils stockent des données, mais dans le fait qu'ils deviennent finalement la « version de la réalité » sur laquelle l'ensemble de l'organisation s'appuie pour fonctionner.
Au cours des deux dernières décennies, Salesforce a vendu à ses clients un ensemble de méthodes permettant aux responsables des ventes de gérer leurs équipes. Les tableaux de bord, les vues de pipeline de vente, les outils de prévision et les flux d'informations dynamiques constituent véritablement les produits achetés. Son modèle économique repose sur la vente de licences aux utilisateurs, qui offrent en réalité un accès à ces fonctionnalités. La base de données sous-jacente est bien sûr essentielle, mais elle ressemble davantage à une infrastructure implicite dans l'expérience produit.
Autrement dit, ce qui motive réellement la fidélisation des utilisateurs, c'est l'interface utilisateur.
L'interface utilisateur impose des normes de données et forge un langage commun : pistes, opportunités, comptes clients. Elle permet à des dizaines de milliers de représentants commerciaux de saisir continuellement des données qu'ils n'auraient peut-être pas saisies autrement. Autrefois, l'interface utilisateur était précisément le mécanisme assurant la cohérence et la disponibilité des données. Salesforce possède une telle fidélité que de nombreux responsables des ventes continuent de l'apporter avec eux dans leur nouvelle entreprise après un changement de poste, non pas parce que son interface est particulièrement remarquable, mais parce qu'elle est devenue une mémoire musculaire.
Mais les agents commencent à bouleverser ce modèle. Ils n'ont plus besoin d'interagir avec les logiciels via une interface utilisateur ; ils peuvent lire et écrire directement les données sous-jacentes. Cela a également donné naissance à une série de nouveaux outils et alternatives qui contournent les interfaces traditionnelles. Salesforce n'est pas le seul exemple : nous avons récemment discuté du fait qu'un écosystème entier, plus adapté aux appels AI, est en train de se développer autour de SAP.
En parallèle, les agents capables d'opérer un ordinateur rendront progressivement moins importants les facteurs humains traditionnels tels que les préférences, la formation et le contexte non documenté. Autrement dit, les conditions nécessaires pour devenir un système d'enregistrement persistant sont en train de changer.
Les critères d'évaluation précédents
Avant d'aborder les changements qui se produiront dans l'ère des agents, il est nécessaire de revenir plus précisément à une question : qu'est-ce qui rendait auparavant les systèmes de registre si persistants ?
Les premiers facteurs sont principalement liés à la manière dont les humains utilisent le logiciel et à leurs préférences personnelles. La difficulté à remplacer un logiciel dépend en grande partie de l'interface utilisateur, des habitudes d'utilisation, des flux de travail humains et des dispositions institutionnelles déjà intégrées dans les processus organisationnels.
First, how often is it accessed?
Le CRM est utilisé quotidiennement par l'équipe GTM et de nombreux autres départements. C'est cette utilisation fréquente qui en fait une infrastructure critique. La couche humaine construite dessus — par exemple, les réunions d'équipe, les habitudes opérationnelles, le rythme de gestion — ces habitudes organisationnelles développées au fil des ans — est souvent la partie la plus difficile à migrer. La raison en est qu'elle n'est même pas toujours reconnue comme « quelque chose qui doit être migré ».
Deuxièmement, est-ce uniquement en écriture, ou bien en lecture et en écriture ?
Un système de suivi véritablement efficace est généralement un système en lecture et écriture bidirectionnel. Prenez un CRM par exemple : il ne s'agit pas seulement d'un système d'écriture destiné à l'archivage, mais aussi d'un système constamment lu. Chaque enregistrement d'appel, chaque mise à jour de phase, chaque création de tâche est entré par un utilisateur, et cet utilisateur s'intéresse généralement à la manière dont ces données seront utilisées par la suite.
Ce flux bidirectionnel signifie que tout substitut doit être capable de prendre en charge les données opérationnelles en temps réel, et non seulement d'exporter un historique des données. Il existe presque aucun moment absolument sûr pour effectuer la transition. Par conséquent, une fois que l'entreprise est en ligne, elle reste souvent à long terme au sein du système du fournisseur d'origine.
En revanche, les systèmes de suivi des candidats (ATS) sont généralement plus proches d'un système « écriture uniquement ». Une fois que les candidats ont été embauchés ou rejetés, les entreprises ont relativement peu de raisons de revenir sur ces données.
Troisièmement, combien de SOP non documentés y a-t-il ?
Le contexte métier essentiel n'est souvent pas écrit sur aucun wiki, mais s'est accumulé dans les règles de flux de travail établies par les administrateurs et les intégrateurs de systèmes au fil des ans.
Par exemple, dans un système de vente, ces contextes non documentés peuvent inclure : les transactions entreprises dépassant 100 000 dollars nécessitent l'approbation du VP ; les transactions de la région EMEA doivent passer par un examen de confidentialité ; les remises pour clients stratégiques ne peuvent contourner l'approbation financière qu'à la fin du trimestre.
Ces contextes déterminent souvent si une action peut être avancée en temps voulu ou achevée sans violer les processus clés. Migrer un système signifie devoir décomposer à nouveau chaque règle automatisée ; sinon, l'entreprise risque de perdre directement une partie de sa mémoire organisationnelle.
Quatrièmement, quelle est la complexité des dépendances internes ou externes ?
La question centrale est la suivante : combien de systèmes internes, de processus d'équipe ou de parties prenantes externes dépendent de ce système d'enregistrement ?
La connectivité interne fait référence au nombre de logiciels ou de flux de travail en aval qui dépendent de celle-ci. La connectivité externe désigne si des entités externes, telles que des auditeurs, des comptables ou des organismes de régulation, doivent accéder directement aux données qu'elle contient. L'ERP en est un exemple typique.
Que ce soit en interne ou en externe, plus la connectivité est élevée, plus les relations à décomposer et à reconstruire lors de la migration sont complexes.
Cinquièmement, du point de vue de la conformité, à quel point les données sont-elles cruciales ?
The core issue here is simple: Is this system compliance-critical?
Les systèmes critiques pour la conformité, tels que les systèmes de paie, ERP et données des ressources humaines, doivent fournir une source de vérité juridiquement valable et disposer d'un contrôle strict des autorisations d'administrateur. Toute migration pourrait nécessiter l'intervention directe des auditeurs et des organismes de régulation. Cela rend leur niveau de fidélité nettement plus élevé.
Les données de vente et les outils de support client comme Zendesk se situent à l'autre extrémité. Les entreprises accordent bien sûr de l'importance à la continuité et au contexte, mais en cas de migration des données ou d'obtention d'un accès, cela ne déclenche généralement pas immédiatement de risques réglementaires.
Tous les systèmes de gestion de données n'ont pas le même niveau de coût de transition. Comparer CRM et ATS dans la même dimension révèle des écarts nets.
ATS est un outil de workflow dédié à des processus limités, centré sur le recrutement. Une fois qu'un candidat est embauché ou rejeté, les enregistrements associés deviennent principalement des données écrites une seule fois. Son périmètre d'intégration est plus restreint, et sa communauté d'utilisateurs est plus petite et plus ciblée.
ERP se trouve à l'autre extrême. Le grand livre est lui-même une trace d'audit, et les comptables, les auditeurs et les organismes de régulation deviendront des parties prenantes directes du processus de migration.
Remplacer ATS est douloureux, mais encore supportable. Remplacer CRM, c’est comme faire une thoracotomie. Remplacer ERP, c’est comme faire une thoracotomie à un patient qui court un marathon.
Traditionnellement, les systèmes de registre n’ont pas véritablement exploité des sources de avantages concurrentiels telles que les données propriétaires ou les effets de réseau ; en général, le flux de travail lui-même suffisait déjà à créer des barrières à l’entrée. D’une certaine manière, il s’agit davantage des activités grand public de combiner les outils et le réseau ; les SoR historiques n’ont pas emprunté cette voie.
Données propriétaires. Bien que de nombreux systèmes de gestion des données aient accumulé d'importantes quantités de données clients, ils n'ont pas véritablement exploité ces données en profondeur, et dans de nombreux cas, les clauses contractuelles ne les autorisent même pas à le faire. Ainsi, bien que les systèmes CRM disposent de jeux de données riches et pourraient théoriquement regrouper les données de différents clients pour générer des insights transversaux, ils n'ont jamais accompli cela de manière véritablement significative. Bien sûr, des produits comme Einstein de Salesforce ont effectué quelques tentatives.
Effet de réseau. La meilleure barrière pour un système d'enregistrement devrait être l'effet de réseau : par exemple, un CRM devient plus précieux lorsque les vendeurs de logiciels peuvent y trouver des acheteurs. Mais, comme les données, les effets de réseau des systèmes d'enregistrement ont historiquement été faibles, voire presque inexistants.
Si l'interface utilisateur disparaît, qu'est-ce qui reste du logiciel après l'arrivée de l'agent ?
L'agent n'a pas besoin de navigateur. Il a besoin d'une API, d'un contexte, d'instructions et de la capacité à exécuter des actions. Deux éléments permettent de rendre tout cela évolutif : d'une part, les LLM possèdent désormais une capacité de raisonnement suffisamment puissante pour que les agents puissent lire le contexte, établir un plan, choisir des outils, exécuter des actions et analyser les résultats, sans nécessiter d'intervention humaine dans la plupart des tâches ; d'autre part, le MCP standardise l'accès aux outils en offrant une interface universelle pour que les agents appellent des capacités externes.
Un agent avec accès à MCP peut effectuer à l'échelle massive, en quelques millisecondes, les opérations que les utilisateurs humains effectuaient auparavant sur la plateforme, sans nécessiter de navigateur. Dans un contexte suffisamment riche, un agent capable d'opérer sur un ordinateur peut même utiliser directement les interfaces logicielles existantes, sans nécessairement recourir à une API.
Sur un plan simple, les acheteurs de logiciels ont désormais trois options :
Premièrement, continuez à utiliser le système existant et ajoutez-y un Agent.
Utilisez-les via l'CLI et l'API du système existant, en utilisant à la fois les produits d'agent natifs des fournisseurs, tels que Agentforce de Salesforce ou Joule de SAP, ou en construisant vos propres agents dessus. Bien sûr, nous supposons ici que les API sont complètes et disponibles, et nous ignorons temporairement la complexité que l'« headlessification » pourrait apporter dans une opération réelle.
Deuxièmement, un système d'enregistrement entièrement auto-hébergé.
Les entreprises peuvent construire dès le départ leur propre modèle de données, logique opérationnelle, système de permissions, traçabilité des audits et intégration système, ainsi que leur propre pile d'agents. Ce parcours utilisera probablement des outils de développement d'agents et des outils de base de données tiers.
Troisièmement, achetez des alternatives natives à l'IA.
Les entreprises peuvent également acheter de nouveaux logiciels conçus dès le départ pour l'ère des Agents. Ces produits mettent l'accent sur la lisibilité machine, traitant l'orchestration des Agents comme une fonctionnalité de première classe, et non comme une fonction AI ajoutée de manière patchée à des systèmes anciens. Ces produits peuvent également être headless.
Quels éléments de l’ancien système d’évaluation seront conservés ?
Les facteurs guidés par le comportement et les préférences humaines, tels que la fréquence de visite, les attributs lecture-écriture et d'autres indicateurs liés à la mémoire musculaire humaine, s'affaibliront progressivement. Les agents pourraient atténuer la valeur de la « mémoire musculaire » en tant que fossé compétitif, mais ils n'élimineront pas les fossés compétitifs liés à la logique opérationnelle et au contexte métier. D'une certaine manière, ils rendront même ces logiques plus importantes, car les agents doivent s'appuyer sur des règles, des autorisations et des définitions de processus clairs pour exécuter leurs tâches en toute sécurité.
Les SOP non documentés restent importants à court terme.
La logique institutionnelle intégrée dans les règles de flux de travail au sein de l'organisation est précisément ce dont l'Agent a besoin pour exécuter correctement les tâches en votre nom. C'est également la partie la plus difficile à reconstituer. Du moins pour l'instant, elle ne peut pas être exportée proprement, surtout lorsque certaines étapes du processus nécessitent encore une intervention humaine. Toutefois, capturer le contexte devient de plus en plus facile ; à mesure que l'Agent remplace davantage de tâches humaines, l'importance de ce facteur diminuera progressivement.
La connectivité reste difficile à décomposer et s'étendra plus profondément.
La signification de la connectivité évolue. Elle ne vise plus seulement à soutenir le travail humain, mais à maintenir la connexion entre des fonctions et des logiciels qui étaient traditionnellement séparés.
Un agent CRM doit relier les données et le contexte de différents processus tels que les ventes, les facturations et le succès client. Si votre plateforme devient également un nœud pour des transactions entre plusieurs organisations externes — par exemple, si les acheteurs, les vendeurs et les partenaires effectuent tous leurs interactions via celle-ci — les dépendances s'approfondiront encore.
Lorsqu'on superpose des agents à des systèmes existants, il peut être difficile d'assurer une collaboration fluide entre les objets et logiques de base des logiciels sous-jacents ; les entreprises ne reposant que sur une base de données interne et un ensemble d'agents rencontrent également des problèmes similaires.
Les données clés de conformité restent importantes.
Les données impliquant des organismes de régulation, des risques de réglementation ou des risques juridiques nécessitent toujours une source unique et fiable de faits. Si les clients font déjà confiance aux produits existants, leur probabilité de changer de système est plus faible.
À titre d'exemple, avec les données de rémunération et de comptabilité, l'agent pourrait effectivement avoir besoin d'accéder à ces données, mais les entreprises sont généralement peu susceptibles de choisir de construire et de maintenir à long terme de tels systèmes en interne.
Dans un monde entièrement agentisé, l’un des problèmes les plus difficiles à résoudre est : quels agents sont autorisés à faire quoi ? Qui représentent-ils ? Comment ces actions sont-elles auditées ? Si un système d’enregistrement peut devenir la couche d’identité et de permissions pour les interactions entre agents, il acquiert un rôle structurel véritablement difficile à remplacer. Les barrières ne résident pas seulement dans les données qu’il détient, mais dans l’architecture de confiance qu’il exécute.
En regardant vers l'avenir, pour les startups natives AI, un nouvel ensemble de facteurs deviendra de plus en plus important et déterminera leur capacité à établir une défense.
Premièrement, à quel point est-il difficile de reconstruire ce système d'enregistrement ?
Les données deviendront encore plus importantes à plusieurs niveaux.
D'abord, à court terme, il est essentiel de déterminer la facilité avec laquelle les données sous-jacentes du système d'enregistrement peuvent être extraites et reconstituées. L'IA rend cette tâche plus facile, et une série d'outils aide les utilisateurs à effectuer ce type de migration et de reconstitution.
À court terme, les fabricants existants peuvent et sont susceptibles de rendre cela plus difficile : ils peuvent rendre les API difficiles à utiliser, les limiter, les rendre incomplètes ou économiquement peu rentables, voire ne pas les fournir du tout. Mais à mesure que les outils d'extraction s'améliorent, en particulier grâce aux capacités accrues des agents capables d'opérer sur un ordinateur, la reconstruction des données deviendra de plus en plus facile.
En parallèle, la nouvelle entreprise reconstruit un ensemble de données plus riche à partir d’e-mails, d’appels téléphoniques, d’agents vocaux et de documents internes. L’IA réduit les coûts de reconstruction d’un système de gestion de 80 % au départ. Ce qui distingue réellement une entrée utile d’un remplaçant véritable, ce sont les 20 % restants : les anomalies, les processus d’approbation, les exigences de conformité et les flux de travail dans les scénarios limites.
Deuxièmement, possède-t-on des données propriétaires véritablement significatives ?
Ensuite, les données elles-mêmes deviendront plus précieuses.
Les données véritablement défensives ne sont pas celles que vous importez, mais celles que votre produit génère de manière unique. Nous parlons souvent de « jardins clos de données » : ces données sont soit propriétaires, soit soumises à des contraintes réglementaires, soit nécessitent des mises à jour continues. Un fournisseur de logiciels qui investit massivement dans la collecte de données autorisées et complètes possède un avantage évident par rapport aux fournisseurs génériques ou aux concurrents dépourvus de telles données.
Les données ont une autre direction importante : elles dépendent-elles des actions générées à l'intérieur du produit ?
Les meilleures entreprises ne se contentent pas de stocker des données saisies ailleurs. Elles génèrent continuellement de nouvelles traces de données en raison de leur position au sein des processus, telles que les comportements observés, les taux de réponse, les modèles temporels, les résultats de processus, les références industrielles, les modèles anormaux et les traces d'exécution des agents.
L'essentiel est que les données constituent désormais le contexte.
Troisièmement, maîtrisez-vous le niveau d'action ?
Dans l'ancien monde, stocker les enregistrements suffisait. Mais dans le nouveau monde, les agents agiront directement ; la défense pourra se tourner vers les produits capables de boucler le processus : agir, capturer les résultats, puis exploiter les retours pour optimiser les décisions futures.
Pour ERP, cela peut inclure l'approbation des dépenses, le déclenchement de la paie, la vérification des factures, l'envoi de notifications, etc. Les produits capables de boucler le processus sont plus défensifs, car ils intègrent l'exécution et ne se limitent pas à l'observation. Ils génèrent des données uniques qui s'améliorent continuellement avec l'utilisation et deviennent plus difficiles à remplacer, car leur suppression perturberait le flux de travail.
Of course, as more context is accumulated and edge cases are handled more thoroughly, the value here will continue to increase.
Quatrièmement, contient-il des étapes d'exécution dans le monde réel ?
Certains modèles économiques sont connectés à des opérations du monde réel qui ne sont pas entièrement automatisées. L'exemple le plus évident est celui des entreprises possédant un réseau opérationnel, comme DoorDash. Elles n'ont historiquement pas fait partie des systèmes de registre, mais elles sont très éclairantes ici.
Plus largement, toute entreprise capable d'étendre la boucle logicielle aux services, à l'exécution, à la logistique, aux opérations sur site ou aux paiements possède une défense différente de celle des entreprises purement SaaS. Ces entreprises ne se contentent pas de stocker des enregistrements ou de recommander des actions ; elles envoient du personnel, déplacent des marchandises ou accomplissent des services concrets.
Pour les entrepreneurs, cela signifie que des opportunités peuvent émerger dans des marchés où les logiciels deviennent de plus en plus capables de prendre des décisions et où les agents sont de plus en plus capables de coordonner les processus, mais où la dernière mile nécessite toujours une exécution dans le monde réel. Par exemple, les logiciels verticaux liés aux services sur site constituent une direction typique.
Cinquièmement, existe-t-il un effet de réseau ?
Historiquement, la plupart des systèmes de registre avaient un faible effet de réseau, car ils étaient principalement des logiciels internes. Mais à l’ère des agents, si un système intègre des flux de travail multipartites, l’effet de réseau pourrait devenir beaucoup plus important.
Si un système est chargé de faciliter des interactions répétées entre plusieurs parties, telles que les acheteurs et les vendeurs, les employeurs et les employés, les entreprises et les auditeurs, les fournisseurs et les clients, les payeurs et les prestataires de services, alors chaque nouvelle partie ajoutée peut rendre ce réseau plus précieux pour la prochaine partie à rejoindre.
L'une des façons consiste en la collaboration sur les flux de travail : le produit devient l'endroit où les deux parties du processus effectuent des transactions, échangent des contextes et gèrent les anomalies.
Une autre approche consiste en la référence et l’intelligence : le système peut présenter, sur la base des modèles observés dans le réseau, les normes de l’industrie, les anomalies et les recommandations d’action, ce qui renforce à son tour la valeur des données mentionnée précédemment.
Troisième approche : la confiance et la standardisation : une fois que les contreparties commencent à compter sur le même ensemble de processus pour accomplir l'approbation, la transmission, la conformité ou le paiement, ce produit n'est plus simplement une base de données, mais une infrastructure collaborative du marché, rendant ainsi sa substitution plus difficile.
Sixièmement, quelle est la capacité technique des acheteurs ?
Dans un monde où théoriquement tout le monde peut construire son propre Agent, les capacités réelles de construction des différents acheteurs varient encore considérablement. En particulier dans les secteurs verticaux et parmi les acheteurs fonctionnels qui n’ont pas disposé par le passé de ressources techniques internes solides, la probabilité qu’ils construisent, maintiennent et améliorent continuellement leur base de données, leur logique de workflow, leur pile d’Agents et leur couche de gouvernance reste faible.
Le coût est tout aussi important ici. Le DIY réduit théoriquement les frais de licence logicielle, mais déplace souvent les dépenses vers la mise en œuvre, la maintenance et la complexité interne.
Cela signifie qu'il existe toujours des opportunités réelles dans les catégories qui sont complexes à exploiter mais dont l'offre technologique est insuffisante, comme la fabrication, l'arrière-plan de la construction, les processus industriels, les flux de travail de service sur site, et la comptabilité.
D'autres facteurs sont tout aussi importants et deviendront progressivement une exigence de base pour les logiciels.
Par exemple, l'ontologie doit évoluer. De nombreuses idées de « bases de données internes » sous-estiment la valeur portée par le modèle d'objets lui-même. Les logiciels existants ont été conçus pour les tableaux de bord, les rapports et les utilisateurs humains ; ils capturent les objets du flux de travail, tels que les opportunités commerciales, les tickets et les candidats.
Mais le schéma de l'ère Agent doit capturer le raisonnement, les actions, le suivi d'état, la gestion des anomalies, la délégation de tâches et la collaboration inter-systèmes. Les modèles d'objets natifs ne seront plus nécessairement des opportunités, des tickets ou des candidats, mais des tâches, des intentions, des threads, des stratégies ou des résultats.
De même, le système de permissions doit être mis à jour. Il ne s'agit plus seulement de gérer les utilisateurs humains, mais aussi les agents. Cela inclut : qui peut faire quoi, via quel agent, selon quelle stratégie, quelles approbations sont nécessaires, quelles traces d'audit doivent être conservées, et comment effectuer un rollback et gérer les anomalies.
Bien sûr, tout cela dépend des coûts, par exemple le coût de la mise en place et de la maintenance des agents et des bases de données, ainsi que le coût d'accès aux API. Cela ramène à plusieurs questions fondamentales : à quel point la reconstruction des données est-elle difficile, combien de dépendances existent-elles, et à quel point le système est-il profondément intégré.
Alors, quelle est la conclusion ?
Alors que les éditeurs de logiciels existants adoptent une approche headless, ils effectuent en réalité un pari implicite : la couche données restera la source principale de valeur. Dans certains segments, notamment ceux soumis à de fortes contraintes de conformité comme les services financiers, ce pari pourrait encore être valable pendant un certain temps, et le processus de headless pourrait s'effectuer plus lentement.
Mais pour les entrepreneurs logiciels, à mesure que les fabricants établis commencent à supprimer les interfaces, la manière de les concurrencer et de construire des logiciels dotés d'une défense à long terme évolue.
Les systèmes d'enregistrement de la prochaine génération commencent à prendre des formes différentes : ils ne sont plus simplement des entrepôts de données pour enregistrer le travail humain, mais possèdent des attributs d'agent — capables de capturer le contexte, d'initier activement des tâches et d'enregistrer les traces de données générées pendant l'exécution.
Plus loin, les entreprises les plus intéressantes s'étendront jusqu'au niveau d'exécution du monde réel : elles coordonneront des équipes sur site, des fournisseurs de logistique, des équipes de service et des actifs physiques, ou agiront comme couche intermédiaire entre plusieurs parties prenantes.
Ces entreprises combineront plusieurs modèles économiques du monde ancien. Toutefois, le cœur des systèmes de registre traditionnels — les données — reculera progressivement en arrière-plan pour devenir l'infrastructure fondamentale soutenant le fonctionnement de l'ensemble du système.
Cliquez pour en savoir plus sur les postes disponibles chez BlockBeats
Rejoignez la communauté officielle de律动 BlockBeats :
Groupe Telegram abonné : https://t.me/theblockbeats
Groupe Telegram : https://t.me/BlockBeats_App
Compte officiel Twitter : https://twitter.com/BlockBeatsAsia