a16z : Lorsque l'interface utilisateur n'est plus le produit, qu'est-ce qui reste de la barrière concurrentielle du logiciel ?

Éditeur : Au cours des vingt dernières années, la barrière défensive du SaaS s’est largement construite sur l’interface utilisateur. Tableaux de bord, champs, flux d’approbation et habitudes des utilisateurs ne sont pas seulement des interfaces opérationnelles, mais façonnent aussi la manière dont les organisations travaillent et l’ordre des données. Lorsque l’IA peut lire directement les données, appeler des outils, exécuter des processus, la dépendance à la mémoire musculaire humaine, qui crée de la fidélité, commence à s’affaiblir, et l’UI n’est plus forcément 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 : du UI et des habitudes d’utilisation, vers les modèles de données, les systèmes d’autorisations, la conformité, la logique métier, la boucle d’exécution et les réseaux de collaboration multi-parties. À l’avenir, les logiciels véritablement protégés 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, de lancer des tâches, de coordonner des agents intelligents, et de générer en continu de nouvelles données lors de leur exécution.

Lorsque les logiciels deviennent headless (sans interface), la problématique centrale des logiciels d’entreprise change également : la valeur ne réside plus seulement dans la possession des données, mais dans la capacité à organiser des actions autour de ces données.

Voici le texte original :

Le mois dernier, Salesforce a annoncé l’ouverture de ses API et le lancement d’un produit headless (sans interface). Fondamentalement, cela signifie que Salesforce mise : à l’ère des Agents, sa valeur centrale ne provient plus principalement de l’UI, mais de la couche de données. C’est une repositionnement assez intelligent.

Cependant, il faut aussi noter que, d’un point de vue technique, cette annonce ne semble pas apporter de changements substantiels. Les API que Salesforce présente sous le nom de « produits headless » existent en grande partie depuis plusieurs années. En d’autres termes, cela ressemble davantage à 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 passer par une interface conçue pour l’humain. La fonction traditionnelle de l’UI était d’aider l’utilisateur humain à suivre les processus, gérer les tâches et faire avancer le flux de travail ; mais après l’intervention de l’Agent, la nécessité de cette couche d’interface diminue.

Ce qui mérite vraiment d’être discuté dans cette annonce, ce n’est pas seulement ce que Salesforce a lancé comme nouveau produit, mais une question plus fondamentale : si l’on retire l’UI et n’ouvre que la base de données sous-jacente, qu’est-ce qu’il reste d’un système d’enregistrement ? En quoi diffère-t-il d’une base de données Postgres, d’un schéma de données bien conçu, ou d’un ensemble d’API ?

Plus loin, ces facteurs classiques qui conféraient une défense à long terme aux systèmes d’enregistrement sont-ils toujours valides ? Ou bien de nouveaux standards de compétition ont-ils émergé ?

À l’ère SaaS, la barrière des systèmes d’enregistrement repose sur le fait que les utilisateurs vivent depuis longtemps dans leur interface. L’interface porte les habitudes d’opération, les processus organisationnels et la sédimentation des données, ce qui entraîne des coûts de migration élevés. Mais à l’ère des Agents, cet avantage s’amenuise. Les couches réellement défensives migrent d’une part vers les modèles de données, les systèmes d’autorisations, la logique de workflow et la conformité ; d’autre part, elles s’élèvent via les effets de réseau, la capacité à générer des données propriétaires, et la capacité à exécuter dans le monde réel.

Lorsque les logiciels deviennent headless, où la barrière va-t-elle alors se déplacer ?

L’UI a toujours été le produit lui-même

Ce qu’on appelle le système d’enregistrement (System of Record, SoR), désigne la source d’autorité pour un certain type de données commerciales. C’est là où résident la version officielle des relations clients, des dossiers employés ou des transactions financières, et c’est aussi le système central que d’autres outils lisent, modifient et mettent à jour. CRM est le système d’enregistrement des données liées aux revenus, HRIS pour les données du personnel, ERP pour les données financières et comptables.

La puissance de ces systèmes ne réside pas seulement dans leur capacité à stocker des données, mais dans leur rôle ultime de fournir la « version de la réalité » sur laquelle toute l’organisation repose.

Au cours des vingt dernières années, Salesforce a vendu aux clients une méthode pour aider les responsables commerciaux à gérer leurs équipes. Les tableaux de bord, la vue du pipeline, les outils de prévision, le flux d’informations dynamique, ce sont eux qui constituent le vrai produit acheté. Son modèle commercial repose sur la vente de sièges d’utilisateur, qui donnent accès à ces fonctionnalités. La base de données sous-jacente est essentielle, mais dans l’expérience produit, elle apparaît comme une infrastructure implicite.

En d’autres termes, ce qui motive réellement la fidélité des utilisateurs, c’est l’UI.

L’UI limite la norme des données, façonne un langage commun : leads, opportunités, comptes clients. Elle pousse des milliers de commerciaux à continuer d’entrer des données qu’ils ne souhaiteraient peut-être pas saisir. Autrefois, l’UI était le mécanisme qui assurait la cohérence et la disponibilité des données. La forte fidélité à Salesforce, qui pousse certains responsables à continuer à utiliser Salesforce dans leur nouvelle entreprise après un changement, ne vient pas d’une interface exceptionnelle, mais d’une mémoire musculaire.

Mais l’Agent commence à bouleverser ce modèle. Ils n’ont plus besoin d’interagir via l’UI, ils peuvent accéder directement aux données de base. Cela engendre une nouvelle vague d’outils et de solutions qui contournent l’interface traditionnelle. Salesforce n’est pas le seul exemple : récemment, nous avons aussi évoqué l’écosystème en croissance autour de SAP, plus adapté à l’appel d’IA.

Par ailleurs, la capacité des Agents à manipuler un ordinateur rend les facteurs humains traditionnels — préférences, formation, contexte non documenté — de moins en moins importants avec le temps. En d’autres termes, les conditions pour qu’un système d’enregistrement devienne durable évoluent.

Les anciens critères d’évaluation

Avant de discuter de ce qui changera à l’ère des Agents, il est utile de revenir à une question essentielle : qu’est-ce qui rendait un système d’enregistrement fidèle dans le passé ?

Les premiers facteurs sont principalement liés à la façon dont les humains utilisent le logiciel, et à leurs préférences. La difficulté à remplacer un système repose largement sur l’UI, les habitudes d’utilisation, le flux de travail humain, et les routines institutionnelles déjà intégrées dans l’organisation.

Premièrement, à quelle fréquence y accède-t-on ?

CRM est utilisé quotidiennement par l’équipe GTM et d’autres départements. Cette utilisation fréquente en fait une infrastructure critique. La couche humaine qui s’appuie dessus — réunions d’équipe, habitudes opérationnelles, rythmes de gestion — constitue souvent la partie la plus difficile à migrer, car elle n’est pas toujours perçue comme un élément à transférer.

Deuxièmement, s’agit-il d’un système en lecture seule ou en lecture-écriture ?

Un système d’enregistrement vraiment fidèle est généralement bidirectionnel. Prenons CRM : ce n’est pas seulement un système d’archivage, mais un système en lecture et écriture continue. Chaque appel, chaque mise à jour de phase, chaque création de tâche est saisie par un utilisateur, qui se soucie aussi de la façon dont ces données seront utilisées par la suite.

Ce flux bidirectionnel signifie que toute alternative doit pouvoir prendre en charge des données opérationnelles en temps réel, pas seulement exporter un historique. La migration ne peut pas attendre un moment parfait pour changer, ce qui fait que, une fois en production, on reste souvent longtemps chez le même fournisseur.

À l’inverse, un système de suivi des candidats (ATS) est souvent plus proche d’un système en écriture seule. Après l’embauche ou le rejet d’un candidat, l’entreprise a peu de raisons de revenir utiliser ces données.

Troisièmement, combien de SOP non documentés existent ?

Les contextes métier clés ne sont souvent pas écrits dans un wiki, mais encapsulés dans des règles de workflow élaborées par des administrateurs ou intégrateurs depuis des années.

Par exemple, dans un système de vente, ces contextes non documentés peuvent inclure : approbation VP pour transactions > 100 000 dollars ; conformité à la confidentialité pour la région EMEA ; remises pour clients stratégiques nécessitant une approbation financière en fin de trimestre.

Ces contextes déterminent souvent si une tâche peut être menée à bien rapidement ou si elle doit respecter des processus clés. La migration implique de redéfinir chaque règle d’automatisation, sinon une partie de la mémoire organisationnelle sera perdue.

Quatrièmement, à quel point la dépendance interne ou externe est-elle complexe ?

La question centrale est : combien de systèmes internes, de processus d’équipe ou de parties externes dépendent de ce système d’enregistrement ?

La connectivité interne concerne le nombre de logiciels ou flux en aval qui en dépendent. La connectivité externe concerne la nécessité pour des acteurs comme auditeurs, comptables ou régulateurs d’accéder directement aux données. ERP en est un exemple typique.

Plus la connectivité est élevée, plus la migration nécessite de défaire et de reconstruire des relations complexes.

Cinquièmement, du point de vue de la conformité, à quel point les données sont-elles critiques ?

La question est simple : ce système est-il une source de vérité essentielle pour la conformité ?

Les systèmes critiques comme la paie, l’ERP ou les données RH doivent fournir une source de faits légale et être soumis à un contrôle strict des accès. Toute migration peut nécessiter l’intervention d’auditeurs ou d’autorités réglementaires, ce qui renforce leur fidélité.

Les données de vente ou les outils de support client comme Zendesk sont à l’autre extrémité : la continuité et le contexte comptent, mais une migration ou un accès modifié ne provoquera pas forcément de risques réglementaires immédiats.

Tous les systèmes d’enregistrement ne présentent pas le même coût de changement. Comparés entre CRM et ATS, la différence est évidente.

L’ATS est un outil de workflow pour un processus limité, centré sur le recrutement. Une fois le candidat embauché ou rejeté, la majorité des données devient une saisie ponctuelle. Son périmètre d’intégration est plus restreint, son public plus petit et plus concentré.

L’ERP, en revanche, est à l’autre extrémité : le grand livre lui-même trace une piste d’audit, et comptables, auditeurs et régulateurs sont directement concernés par sa migration.

Remplacer un ATS est difficile mais faisable. Remplacer un CRM, c’est comme une chirurgie à cœur ouvert. Remplacer un ERP, c’est comme faire une chirurgie à cœur ouvert pendant qu’un patient court un marathon.

Historiquement, les systèmes d’enregistrement n’ont pas vraiment exploité la valeur des données propriétaires ou des effets de réseau ; en général, le flux de travail lui-même suffisait à créer une barrière. En quelque sorte, la combinaison d’outils et de réseau est plus une caractéristique du secteur grand public ; les SoR historiques n’ont pas emprunté cette voie.

Données propriétaires. Beaucoup de systèmes d’enregistrement accumulent des données clients riches, mais ne les exploitent pas en profondeur, souvent en raison de clauses contractuelles qui l’interdisent. Même si un CRM possède un ensemble de données riche, il ne l’a jamais vraiment utilisé pour générer des insights trans-clients, sauf dans des tentatives comme Salesforce Einstein.

Effets de réseau. Pour un système d’enregistrement, le meilleur avantage concurrentiel serait l’effet de réseau : par exemple, un CRM devient plus précieux si le vendeur peut y trouver des acheteurs. Mais, comme pour les données, l’effet de réseau dans ces systèmes a toujours été faible, voire inexistant.

Si l’UI disparaît, qu’est-ce qu’il reste après l’arrivée des Agents ?

Les Agents n’ont pas besoin de navigateur. Ils ont besoin d’API, de contexte, d’instructions, et de capacités d’exécution. Deux éléments permettent une mise à l’échelle : d’une part, les LLM ont désormais une capacité de raisonnement suffisante pour que l’Agent puisse lire le contexte, planifier, choisir des outils, exécuter des actions et faire un bilan, sans intervention humaine dans la plupart des tâches ; d’autre part, la norme MCP standardise l’accès aux outils, offrant une interface universelle pour l’appel de capacités externes.

Un Agent avec accès MCP peut réaliser en millisecondes, à grande échelle, des opérations que l’humain aurait effectuées sur la plateforme, sans navigateur. Avec un contexte riche, un Agent capable de manipuler un ordinateur peut même utiliser directement des interfaces logicielles existantes, sans API.

En résumé, les acheteurs de logiciels ont aujourd’hui trois options :

Premièrement, continuer à utiliser leurs systèmes existants, en y superposant un Agent.
En utilisant la CLI ou les API, ils peuvent exploiter les agents natifs du fournisseur, comme Salesforce Agentforce ou SAP Joule, ou construire leurs propres Agents. Ici, on suppose que l’API est complète et fonctionnelle, en ignorant pour l’instant la complexité que la « headlessisation » pourrait apporter en pratique.

Deuxièmement, construire un système d’enregistrement de zéro.
L’entreprise peut partir de zéro pour concevoir ses modèles de données, sa logique opérationnelle, ses systèmes d’autorisations, ses audits, ses intégrations, et sa pile d’Agents. Elle utilisera probablement des outils tiers pour le développement d’Agents et la gestion de bases de données.

Troisièmement, acheter des solutions de nouvelle génération conçues dès le départ pour l’ère des Agents.
Ces produits mettent l’accent sur la machine-lisible, en intégrant la gestion des Agents comme une capacité de premier ordre, plutôt que d’ajouter une fonction IA en patch sur un ancien système. Ces produits peuvent aussi être headless.

Alors, quels éléments des anciens critères d’évaluation seront conservés ?

Les facteurs liés au comportement et aux préférences humaines s’affaibliront progressivement, comme la fréquence d’accès ou la nature bidirectionnelle lecture-écriture, liés à la mémoire musculaire. Les Agents pourraient réduire la valeur de cette mémoire musculaire comme barrière, mais ils ne supprimeront pas la défense basée sur la logique opérationnelle et le contexte métier. Au contraire, ces logiques deviendront peut-être encore plus cruciales, car pour que l’Agent exécute en toute sécurité, il doit s’appuyer sur des règles, des autorisations et des processus clairement définis.

Les SOP non documentés, qui sont cruciaux, resteront importants à court terme.
Les règles de workflow encapsulent la logique institutionnelle que l’Agent doit respecter pour exécuter correctement ses tâches. C’est aussi la partie la plus difficile à reconstruire, car elle ne peut pas encore être exportée proprement, surtout si certains processus nécessitent encore une intervention humaine. Cependant, la capture du contexte devient de plus en plus facile ; à mesure que les Agents remplacent davantage de travail humain, cette importance diminuera.

La connectivité reste difficile à défaire, et tend à s’approfondir.
La signification de la connectivité évolue : elle ne concerne plus seulement la collaboration humaine, mais aussi la connexion entre fonctions et logiciels traditionnellement séparés.

Un CRM avec Agent doit relier les données et le contexte des ventes, de la facturation, du succès client, etc. Si votre plateforme devient un point de passage pour des échanges entre plusieurs organisations externes — acheteurs, vendeurs, partenaires — la dépendance s’intensifiera.

Lorsque des fournisseurs traditionnels ajoutent des Agents, il peut être difficile d’assurer une collaboration fluide entre différents objets et logiques sous-jacents. Si une entreprise construit son propre système de bases de données et ses Agents, elle rencontrera des défis similaires.

Les données critiques pour la conformité restent essentielles.
Les données soumises à la régulation ou à des risques légaux doivent disposer d’une source unique et fiable. Si les clients font confiance à leurs systèmes actuels, ils seront moins enclins à changer.

Prenons l’exemple des données de paie ou comptables : un Agent peut avoir besoin d’y accéder, mais il est peu probable que l’entreprise construise et maintienne en interne un tel système à long terme.

Dans un monde entièrement Agentisé, l’une des questions les plus difficiles à résoudre est : quels Agents sont autorisés à faire quoi ? Qui agit en leur nom ? Comment ces actions sont-elles auditées ? Si un système d’enregistrement peut devenir la couche d’identité et d’autorisation entre Agents, il acquiert un rôle structurel difficile à remplacer. La barrière ne réside pas seulement dans les données qu’il détient, mais dans la confiance qu’il incarne.

À l’avenir, pour les startups axées sur l’IA native, de nouveaux facteurs deviendront de plus en plus importants pour leur capacité à construire une défense.

Premièrement, à quel point est-il difficile de reconstruire ce système d’enregistrement ?

Les données deviendront plus importantes à plusieurs niveaux.

D’abord, à court terme, la difficulté réside dans l’extraction et la reconstruction des données fondamentales du système. L’IA facilite cette tâche, avec des outils qui aident à migrer et reconstruire.

À court terme, les fournisseurs existants peuvent, et probablement rendront cette tâche plus difficile : en limitant ou en rendant l’API difficile d’accès, ou en la rendant économiquement non rentable, voire en ne proposant pas d’API du tout. Mais avec l’amélioration continue des outils d’extraction, notamment la montée en puissance des Agents capables de manipuler un ordinateur, la reconstruction des données deviendra de plus en plus accessible.

Par ailleurs, de nouvelles entreprises reconstruisent des systèmes plus riches à partir de courriels, appels, voix, documents internes. L’IA réduit le coût de reconstruction d’environ 80 % d’un système d’enregistrement. La différence entre une bonne entrée et une véritable alternative réside dans les 20 % restants : gestion des cas exceptionnels, processus d’approbation, exigences de conformité, et flux de travail en situations extrêmes.

Deuxièmement, la possession de données propriétaires réellement significatives ?

Les données réellement défensives ne sont pas seulement celles que vous importez, mais celles que votre produit génère de manière unique. On parle souvent de « jardins clos de données » : ces données doivent être propriétaires, réglementées, ou nécessiter une mise à jour continue. Un fournisseur qui investit massivement dans la collecte de données autorisées et complètes aura un avantage évident sur ses concurrents, même s’il ne possède pas encore de plateforme intégrée.

Les données ont aussi une autre dimension : dépendent-elles d’actions internes au produit ?

Les meilleures entreprises ne se contentent pas de stocker des données importées. Elles génèrent en continu de nouvelles données en étant elles-mêmes dans le processus : comportements observés, taux de réponse, modèles temporels, résultats de processus, benchmarks sectoriels, anomalies, trajectoires d’Agents.

L’essentiel, c’est que : aujourd’hui, la donnée devient du contexte.

Troisièmement, la maîtrise du niveau d’action ?

Dans l’ancien monde, stocker des enregistrements suffisait. Dans le nouveau, les Agents prennent directement des actions, et la défense peut se déplacer vers des produits capables de boucler la boucle : agir, capturer le résultat, et utiliser le retour d’information pour optimiser.

Pour un ERP, cela peut inclure l’approbation des dépenses, le déclenchement de paiements, la vérification des factures, l’envoi de notifications. Les produits capables de boucler la boucle sont plus défensifs, car ils intègrent l’exécution, et pas seulement l’observation. Ils génèrent des données uniques, s’améliorent avec l’usage, et deviennent plus difficiles à remplacer, car leur suppression détruirait le workflow.

Naturellement, à mesure que le contexte s’accumule et que la gestion des cas extrêmes s’améliore, cette valeur augmentera encore.

Quatrièmement, la prise en compte de l’exécution dans le monde réel ?

Certains modèles commerciaux sont liés à l’opération dans le monde réel, et ces étapes ne seront pas entièrement automatisées. L’exemple le plus évident est celui des entreprises disposant d’un réseau opérationnel, comme DoorDash. Historiquement, elles ne sont pas des systèmes d’enregistrement, mais leur rôle est très instructif.

Plus généralement, toute entreprise capable d’étendre la boucle logicielle à des services, des livraisons, de la logistique, des opérations sur site ou des paiements possède une défense différente d’un SaaS pur. Elle ne se contente pas de stocker des enregistrements ou de recommander des actions, mais déploie du personnel, déplace des marchandises ou fournit des services concrets.

Pour les entrepreneurs, cela ouvre des opportunités dans des marchés où la prise de décision logicielle, la coordination par Agents, ne suffisent pas : la dernière étape, la plus concrète, doit encore être réalisée dans le monde physique. Par exemple, les logiciels verticalisés liés aux services sur site.

Cinquièmement, y a-t-il des effets de réseau ?

Historiquement, la plupart des systèmes d’enregistrement avaient peu d’effets de réseau, car ils étaient principalement internes. À l’ère des Agents, si un système intègre plusieurs flux de travail entre parties, l’effet de réseau peut devenir beaucoup plus important.

Si un système facilite la médiation entre plusieurs acteurs — acheteurs et vendeurs, employeurs et employés, entreprises et auditeurs, fournisseurs et clients, payeurs et prestataires — chaque nouveau participant augmente la valeur pour le suivant.

Une méthode consiste à partager des flux de travail collaboratifs : le produit devient un lieu d’échange, de transaction, de gestion des exceptions.

Une autre, basée sur la normalisation et l’intelligence, consiste à analyser les modèles observés dans le réseau, à présenter des tendances sectorielles, des anomalies, ou des recommandations d’action, renforçant ainsi la valeur des données évoquée plus tôt.

Une troisième, enfin, concerne la confiance et la standardisation : si les partenaires commencent à dépendre d’un même processus pour l’approbation, la conformité ou le paiement, le produit devient une infrastructure de coordination du marché, difficile à remplacer.

Sixièmement, quelle est la capacité technique des acheteurs ?

Dans un monde où tout le monde peut théoriquement construire ses Agents, la capacité réelle des acheteurs à le faire varie énormément. En particulier dans les secteurs verticaux ou pour des fonctions sans ressources internes fortes, la probabilité qu’ils construisent, maintiennent et améliorent en interne leur base de données, leur logique de workflow, leur pile d’Agents et leur gouvernance reste faible.

Le coût est aussi un facteur clé. Le DIY peut réduire les coûts de licence, mais transfère souvent ces coûts vers l’implémentation, la maintenance, la complexité interne.

Cela signifie que dans des secteurs à forte complexité opérationnelle mais à faible capacité technique, il existe encore de réelles opportunités. Par exemple, dans la fabrication, la gestion de back-office, les processus industriels, la logistique sur site, ou la comptabilité.

D’autres facteurs deviennent également cruciaux, et deviendront probablement des seuils fondamentaux pour les logiciels.

Par exemple, la ontologie doit évoluer. Beaucoup d’idées de « bases de données auto-construites » sous-estiment la valeur de l’objet modélisé. Les logiciels traditionnels sont conçus pour des tableaux de bord, des rapports, et des utilisateurs humains, et capturent des objets comme des opportunités, des tickets, des candidats.

Mais à l’ère des Agents, le schéma 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 objets natifs ne seront plus forcément des opportunités ou des tickets, mais des tâches, des intentions, des threads, des stratégies ou des résultats.

De même, le système d’autorisations doit évoluer. Il ne s’agit plus seulement de gérer des utilisateurs humains, mais aussi des Agents. Cela inclut : qui peut faire quoi, avec quel Agent, selon quelle stratégie, quelles approbations sont nécessaires, quelles traces d’audit, comment faire du rollback ou gérer les anomalies.

Naturellement, tout cela dépend aussi du coût : combien coûte la construction et la maintenance d’Agents et de bases de données, quel est le coût d’accès via API. Cela revient aux questions fondamentales : à quel point la reconstruction des données est difficile, combien de dépendances existent, et à quel point le système est profondément intégré.

Alors, quelle est la conclusion ?

À mesure que les fournisseurs traditionnels se tournent vers le headless, ils font en réalité une mise implicite : la couche de données restera la source de valeur principale. Dans certains secteurs, notamment la finance, fortement réglementés, cette hypothèse pourrait encore tenir un certain temps, et la transition headless pourrait être plus lente.

Mais pour les startups, à mesure que les acteurs établis se déconnectent de l’UI, la manière de leur faire face et de construire des logiciels à défense durable change.

Les systèmes d’enregistrement de nouvelle génération prennent déjà une forme différente : ils ne sont plus seulement des entrepôts de données pour enregistrer le travail humain, mais deviennent plus Agent, capables de capturer le contexte, d’initier des actions, et d’enregistrer les données générées lors de leur exécution.

Plus encore, les entreprises les plus innovantes s’étendront à la couche d’exécution dans le monde réel : elles coordonneront le personnel sur site, les logisticiens, les équipes de service, ou les actifs physiques, ou joueront un rôle d’intermédiaire entre plusieurs parties.

Ces entreprises combineront plusieurs modèles commerciaux du vieux monde. La valeur centrale des systèmes d’enregistrement — les données — reculera progressivement pour devenir la couche de support de tout le système.

[Lien vers l’article original]

Cliquez pour découvrir les opportunités chez BlockBeats dans nos offres d’emploi

Rejoignez la communauté officielle de BlockBeats :

Groupe Telegram : https://t.me/theblockbeats

Groupe Telegram dédié : https://t.me/BlockBeats_App

Compte officiel Twitter : https://twitter.com/BlockBeatsAsia