Le logiciel perd-il sa tête ?

• L’annonce par Salesforce de l’ouverture de ses API et du lancement de produits headless relance une question centrale : à l’ère des agents, où se situe encore le moat du SaaS, si la couche de données, et non l’UI, devient le centre de la valeur
• À l’ère du SaaS, le moat des systèmes d’enregistrement (System of Record) venait des habitudes d’usage façonnées par l’UI ; mais cet avantage s’affaiblit quand des agents lisent et écrivent directement dans la base de données
• Le moat se déplace, vers le bas, vers le modèle de données, les permissions, la logique de workflow et la conformité, et vers le haut, vers les réseaux, la génération de données propriétaires et la capacité d’exécution dans le monde réel
• La prochaine génération de systèmes d’enregistrement natifs IA devra répondre à de nouveaux critères : modèles de données adaptés aux agents, gestion des permissions au niveau des agents, et fermeture de la boucle d’exécution
• Les entreprises de nouvelle génération les plus prometteuses iront au-delà du simple stockage de données pour s’étendre à l’exécution dans le monde réel et à la coordination multipartite

---

La question soulevée par l’annonce headless de Salesforce

• Le mois dernier, Salesforce a annoncé l’ouverture de ses API et le lancement de produits headless, pariant qu’à l’ère des agents, la valeur réside dans la couche de données plutôt que dans l’UI
  • Sur le plan technique, presque rien n’a vraiment changé — les API aujourd’hui commercialisées comme des produits headless existent depuis des années, dans un lancement marketing très typique de Salesforce
  • L’idée clé est que les agents accèdent directement aux données du système d’enregistrement, sans passer par une UI conçue pour les humains
• Si l’on retire l’UI et qu’il ne reste que la base de données, une question fondamentale apparaît : qu’est-ce qui distingue alors cela de Postgres + un schéma bien conçu + une API ?
  • Il faut donc réexaminer si les éléments qui soutenaient les systèmes d’enregistrement restent valables tels quels, ou s’il faut de nouveaux critères

L’ère SaaS, où l’UI était le produit

• Un système d’enregistrement (System of Record) est la source de vérité faisant autorité pour un domaine donné
  • Le CRM est le système d’enregistrement du chiffre d’affaires, le HRIS celui des RH, l’ERP celui des finances
  • Sa vraie force ne réside pas seulement dans le stockage, mais dans le fait de fournir une réalité partagée à l’échelle de toute l’organisation
• Depuis vingt ans, ce que Salesforce vend, c’est la manière dont les responsables commerciaux pilotent leurs équipes
  • Les tableaux de bord, vues pipeline, outils de prévision et flux d’activité étaient le véritable produit vendu, avec un modèle économique fondé sur la vente de licences par utilisateur (seat)
  • La base de données sous-jacente était essentielle, mais secondaire
• C’est l’UI qui créait l’adhérence (stickiness)
  • Elle imposait l’hygiène des données, créait un vocabulaire commun (Lead, Opportunity, Account) et poussait les commerciaux à saisir des données qu’ils n’auraient sinon jamais entrées
  • Si tant de responsables commerciaux emportent Salesforce en changeant d’entreprise, ce n’est pas parce que l’UI est meilleure, mais à cause de l’habitude ancrée dans les gestes (muscle memory)
• Les agents commencent à inverser ce modèle
  • Ils peuvent lire et écrire directement dans les données, sans passer par l’UI
  • Un écosystème compatible IA se développe aussi rapidement autour de SAP
  • Avec le temps, les agents d’usage informatique neutralisent les facteurs humains — préférences, formation, contexte non documenté

Les anciens critères d’évaluation de l’adhérence des systèmes d’enregistrement

• Des facteurs fondés sur la manière dont les humains interagissent avec les logiciels et sur leurs préférences

• Fréquence d’usage

  • Le CRM est utilisé tous les jours par les équipes GTM → il devient une infrastructure critique
  • Les routines de travail, gestes devenus réflexes et cadences de management forgées pendant des années qui s’y accumulent sont les éléments les plus difficiles à migrer
  • Souvent, il n’est même pas perçu comme quelque chose qu’on pourrait migrer

• Write-only ou read-write ?

  • Les systèmes d’enregistrement vraiment adhérents sont de type read-write
  • Un CRM est consulté en permanence — chaque journal d’appel, mise à jour d’étape ou création de tâche alimente un flux bidirectionnel
  • Comme il gère des données opérationnelles vivantes, il n’existe pas de moment de bascule sans risque → une fois adopté, il devient difficile à quitter
  • À l’inverse, un ATS (applicant tracking system) est plus proche d’un système write-only — une fois le recrutement terminé, on reconsulte rarement les données

• Importance des SOP non documentées

  • Le contexte métier le plus critique est encodé dans des règles de workflow, pas dans un wiki
  • Exemple côté ventes : les deals enterprise au-dessus de 100 000 dollars exigent l’approbation d’un VP, les deals EMEA nécessitent une revue privacy, et les remises sur logos stratégiques ne peuvent contourner la finance qu’en fin de trimestre
  • Ce contexte fait la différence entre un traitement à temps et un oubli
  • Migrer signifie soit rétroconcevoir toutes les automatisations, soit perdre d’un coup toute la mémoire de l’organisation

• Taille des dépendances internes et externes

  • Besoin d’accès direct de systèmes internes en aval, mais aussi d’auditeurs, comptables et régulateurs externes
  • Plus la connectivité des deux côtés est forte, plus il y a de nœuds à défaire lors d’une migration

• Importance de la conformité

  • Les données de paie, d’ERP et de RH exigent une source de vérité unique juridiquement défendable, des contrôles d’accès administrateur stricts et une implication directe des auditeurs et régulateurs
  • Leur adhérence est donc très forte
  • Les données commerciales ou des outils de support client comme Zendesk sont à l’autre extrémité — la continuité et le contexte comptent, mais sans exposition réglementaire

• Comparaison des coûts de changement selon le type de système d’enregistrement

  • Un ATS est un outil de workflow aux frontières nettes, centré sur le recrutement, avec peu d’intégrations et peu d’utilisateurs
  • Un ERP est l’exact opposé — le grand livre est la piste d’audit elle-même, et comptables, auditeurs et régulateurs sont des parties prenantes directes
  • Remplacer un ATS est pénible mais supportable ; remplacer un CRM, c’est une chirurgie à cœur ouvert ; remplacer un ERP, c’est faire une chirurgie à cœur ouvert sur un patient en plein marathon

• Les éléments de moat historiquement faibles

  • Les données propriétaires — le CRM détenait des données riches, mais les tentatives pour en extraire des insights inter-clients sont restées limitées (avec seulement quelques essais comme Salesforce Einstein)
  • Les effets de réseau — longtemps considérés comme le Graal, mais historiquement faibles dans les systèmes d’enregistrement

Que reste-t-il quand l’UI disparaît et que les agents arrivent ?

• Les agents n’ont pas besoin de navigateur — il leur suffit d’une API, de contexte, d’instructions et d’une capacité d’action

• Deux évolutions rendent cela possible

  • L’amélioration des capacités de raisonnement des LLM : les agents peuvent lire le contexte, planifier, choisir des outils, exécuter et vérifier les résultats sans intervention humaine
  • La standardisation de l’accès aux outils via MCP : les agents peuvent appeler des fonctions externes à travers une interface commune
  • Les agents d’usage informatique peuvent aussi naviguer dans des interfaces logicielles existantes sans API, dès lors qu’ils disposent du bon contexte

• Les trois voies possibles pour les acheteurs de logiciels

  • Système existant + agents : utiliser les CLI/API des leaders SaaS en place, adopter des produits agents natifs (Salesforce Agentforce, SAP Joule) ou construire ses propres agents — à condition que l’API soit complète, exploitable et que le passage au headless soit simple sur le plan opérationnel
  • Construire son propre système d’enregistrement (DIY) : bâtir dès zéro son propre modèle de données, sa logique opérationnelle, ses permissions, son audit, ses intégrations et ses agents (avec éventuellement des outils tiers)
  • Acheter un remplaçant natif IA : une nouvelle génération de logiciels conçus d’emblée pour être lisibles par les machines, avec l’orchestration d’agents comme fonctionnalité de premier plan et une architecture headless

• Ce qui survit aux anciens critères d’évaluation

  • Les facteurs basés sur le comportement humain (fréquence d’usage, read vs read-write) disparaissent avec les habitudes d’usage
  • Les agents tuent le moat lié aux habitudes, mais pas celui lié à la logique opérationnelle et au contexte
  • Au contraire, ces éléments deviennent encore plus importants, car pour agir en sécurité, les agents ont besoin de règles, de permissions et de processus explicitement définis

• À court terme, les SOP non documentées restent importantes

  • La logique organisationnelle encodée dans les règles de workflow reste cruciale pour que les agents fonctionnent correctement
  • Elle ne s’exporte pas proprement (surtout quand des humains restent dans une partie du processus)
  • Mais à mesure que la capture du contexte devient plus simple et que les agents remplacent davantage de travail humain, son importance finira par diminuer

• La connectivité reste difficile, et elle prend encore plus d’ampleur

  • Plus que suivre les humains, l’enjeu central devient de maintenir les connexions entre fonctions et logiciels fragmentés
  • Un agent CRM doit recoller données et contexte entre ventes, facturation et customer success
  • S’il devient un nœud où interagissent des agents de plusieurs organisations externes, les dépendances deviennent encore plus profondes
  • Que l’on combine un acteur historique avec des agents, ou une base DIY avec des agents, traverser les multiples couches logicielles sous-jacentes reste difficile

• Les données de conformité restent essentielles

  • Les données exposées à des risques réglementaires et juridiques exigent toujours une source de données unique et fiable
  • Il est peu probable que les entreprises construisent et maintiennent elles-mêmes leurs systèmes de paie ou de comptabilité
  • Le problème non résolu le plus difficile dans un monde pleinement piloté par des agents : quel agent, au nom de qui, peut faire quoi, avec quel niveau d’auditabilité ?
  • Les systèmes d’enregistrement qui deviennent la couche d’identité et de permissions des interactions entre agents imposent une architecture de confiance, ce qui les rend structurellement difficiles à remplacer

Les nouveaux éléments de moat pour les startups natives IA

• Difficulté à reproduire un système d’enregistrement

  • À court terme, la facilité ou non d’extraire et de reconstituer les données d’un système d’enregistrement devient centrale
  • Les leaders SaaS établis rendent souvent leurs API pénibles à utiliser, limitées, incomplètes ou peu viables économiquement
  • Mais l’amélioration des outils d’extraction, en particulier des agents d’usage informatique, rend cette tâche progressivement plus simple
  • En parallèle, de nouvelles entreprises émergent pour reconstituer des données plus riches à partir des e-mails, appels, agents vocaux et documents internes
  • L’IA réduit le coût de reproduction des premiers 80 % d’un système d’enregistrement, mais les 20 % restants — gestion des exceptions, approbations, conformité et workflows edge cases — sont ce qui sépare les vrais remplaçants des simples wedges

• Posséder ou non des données propriétaires significatives

  • Les données défendables ne sont pas les données importées, mais les données que le produit génère de manière unique
  • Un jardin clos de données — des données propriétaires, réglementées ou nécessitant des mises à jour continues
  • Les fournisseurs de logiciels qui investissent dans des données autoritatives et complètes disposent d’un avantage face aux acteurs généralistes
  • Des données comportementales générées en interne : comportements observés, taux de réponse, schémas temporels, résultats de processus, benchmarks, motifs d’exception, suivi des performances des agents
  • Les données sont le contexte (data is the context)

• Posséder la couche d’action

  • Autrefois, stocker les enregistrements suffisait ; dans la nouvelle ère, les agents agissent
  • Le moat se déplace vers des produits à boucle fermée : action → capture du résultat → feedback → amélioration de la décision
  • Exemple côté ERP : approbation de dépenses, déclenchement de la paie, rapprochement de factures, envoi de notifications
  • Les produits qui ferment la boucle sont situés dans l’exécution plutôt que dans l’observation — ils génèrent des données propres, s’améliorent à l’usage et sont difficiles à retirer sans casser le workflow

• La composante d’exécution dans le monde réel

  • Les modèles économiques les plus solides sont reliés à des opérations physiques qui ne seront pas totalement automatisées
  • Les réseaux opérationnels comme DoorDash n’étaient pas historiquement des systèmes d’enregistrement, mais ils offrent un enseignement utile
  • Les logiciels qui ferment la boucle via des services, la fulfillment, la logistique, les opérations terrain ou les paiements ont un moat différent du pur SaaS
  • Ils ne se contentent pas de stocker des données ou de recommander : ils envoient des personnes, déplacent des biens et exécutent des services
  • Pour les builders, l’opportunité se situe de plus en plus dans les marchés où le logiciel décide davantage et les agents coordonnent, mais où le dernier kilomètre exige encore une exécution dans le monde réel — par exemple des logiciels verticaux couplés à des services terrain

• Les effets de réseau

  • Dans les anciens systèmes d’enregistrement, ils étaient faibles parce que le logiciel servait surtout un usage interne
  • Mais s’ils s’intègrent à des workflows multipartites, les effets de réseau peuvent devenir bien plus importants
  • Lorsqu’un système médie des interactions répétées entre acheteur-vendeur, employeur-employé, entreprise-auditeur, fournisseur-client, payeur-prestataire, l’augmentation du nombre de participants accroît la valeur du réseau
  • Formes possibles d’implémentation
    • Coordination de workflows partagés — le système devient le lieu où les deux parties réalisent une transaction, échangent du contexte et résolvent les exceptions
    • Benchmarking et intelligence — il fournit normes, anomalies et recommandations à partir des schémas observés dans le réseau
    • Confiance et standardisation — s’il devient le rail commun des approbations, handoffs, obligations de conformité et paiements, il cesse d’être une simple base de données pour devenir une partie de l’infrastructure de coordination du marché

• La capacité technique des acheteurs

  • Même dans un monde où tout le monde peut théoriquement construire des agents, les capacités réelles varient énormément
  • Dans les marchés verticaux de bout de chaîne et chez les acheteurs fonctionnels disposant de peu de ressources d’ingénierie interne, la probabilité de construire, maintenir et faire évoluer une base de données, une logique de workflow, une stack d’agents et une gouvernance reste faible
  • Le coût est aussi central — le DIY réduit peut-être les frais de licence, mais les remplace par des coûts d’implémentation, de maintenance et de complexité interne
  • Il existe donc une opportunité dans les catégories opérationnellement complexes mais technologiquement underserved — industrie manufacturière, back-office de la construction, workflows industriels et terrain, comptabilité

Les autres éléments indispensables (table stakes)

• Un nouveau modèle de données (ontologie)

  • La vision « DIY DB » tend à sous-estimer la valeur du modèle objet lui-même
  • Les logiciels existants ont été conçus pour capturer des tableaux de bord, des rapports et des workflows humains — Opportunity, Ticket, Candidate, etc.
  • Un schéma pour agents doit capturer le raisonnement, l’action, le suivi d’état, la gestion des exceptions, la délégation et la coordination inter-systèmes
  • Le modèle objet natif évolue donc vers des entités comme task, intent, thread, policy, outcome

• La gestion des permissions des agents

  • Il faut un système de permissions conçu non seulement pour les humains, mais aussi pour les agents
  • Il doit définir qui, via quel agent, sous quelle politique, avec quelles approbations, quelles pistes d’audit, quelles capacités de rollback et quelle gestion des exceptions, peut faire quoi

• Le contexte de coût

  • Coût de construction et de maintenance des agents et des bases de données, coût d’accès aux API, etc.
  • Un enjeu lié aussi à la difficulté de reconstituer les données et au nombre de dépendances

Conclusion — vers quoi évoluent les systèmes d’enregistrement

• Le passage au headless chez les leaders SaaS existants est un pari implicite : la couche de données reste la source de valeur
• Dans des catégories profondément imbriquées avec la conformité, comme les services financiers, ce pari devrait rester valable pendant un certain temps, et la transition vers le headless sera aussi plus lointaine
• Pour les builders, la structure d’opportunité change face à des acteurs établis qui passent au headless
• Les systèmes d’enregistrement de nouvelle génération ne seront pas de simples bases de stockage, mais des formes compatibles avec les agents, capables de capturer le contexte, d’initier des tâches et d’enregistrer le data exhaust
• Les entreprises les plus intéressantes seront celles qui s’étendent vers l’exécution dans le monde réel — en coordonnant du personnel terrain, des prestataires logistiques, des équipes de service ou des actifs physiques — ou qui se placent entre plusieurs parties
• Elles mélangeront le cœur des modèles économiques de l’ancien monde et celui des systèmes d’enregistrement traditionnels (les données), tout en reléguant les données à l’arrière-plan