Au-delà d'Agentforce et Copilot Studio : quand choisir un runtime ouvert auto-hébergé

En bref : Les suites fermées l’emportent au sein de leur propre écosystème — si tout votre univers vit entre les murs d’un seul fournisseur. Quand les données sont réparties entre plusieurs systèmes, qu’elles doivent rester les vôtres et que vous voulez le choix du modèle, un runtime ouvert et auto-hébergé (ou l’usage des deux) est la réponse.

Une entreprise fait son choix d’agent IA, et sa liste restreinte est toute naturelle : Agentforce, Copilot Studio, ServiceNow AI Agents. Les trois sont solides, les trois sont recommandés par quelqu’un.

Elle a failli signer Agentforce — c’est lui qui faisait la plus belle démo sur les scénarios CRM. Juste avant de conclure, un architecte a posé une question : « Les problèmes clients que nous voulons faire traiter par l’agent : la moitié exige de consulter les opportunités dans Salesforce, l’autre moitié la livraison et les tickets dans nos systèmes maison. Comment Agentforce atteint-il cette moitié hors les murs ? »

La réponse du commercial : « On peut faire une intégration. » Ils ont donc passé six semaines à monter un PoC d’intégration. La conclusion était claire : on peut connecter, mais chaque système hors les murs ajouté exige de réécrire une synchronisation, d’aligner une fois de plus les définitions, de maintenir un pipeline qui finira par casser — et ils avaient sept ou huit systèmes hors les murs. C’est à cet instant que l’équipe a compris : le problème n’est pas qu’Agentforce ne soit pas assez bon, mais qu’il pose, comme les deux autres, une prémisse qui ne tient pas pour cette entreprise.

Six semaines et un PoC pour acheter une leçon que l’on aurait pu tirer dès le départ.

La prémisse non dite : tout votre monde tient dans les murs d’un seul

La force de ces suites, c’est essentiellement « le meilleur dans l’écosystème ». Agentforce suppose que vos clients, vos processus, vos objets sont déjà dans Salesforce ; Copilot Studio suppose que votre collaboration, vos documents, vos identités sont dans 365 ; ServiceNow suppose que vos processus sont sur lui. Quand la prémisse tient, elles vous facilitent effectivement la vie — données déjà là, permissions déjà là, intégration déjà là, l’agent se branche presque sans effort.

Mais cette prémisse ne tient pas pour la plupart des entreprises. La véritable entreprise ressemble à ceci : un CRM chez l’un, un ERP chez l’autre, les tickets chez un troisième, plus une pile de systèmes maison et de tableurs ; elle veut conserver son libre choix de modèle, car les modèles changent d’année en année ; elle est soumise à des contraintes réglementaires, ses données ne peuvent pas sortir du territoire n’importe comment. Pour une telle entreprise, « le meilleur dans l’écosystème » devient au contraire une contrainte — car son monde ne tient dans les murs d’aucun. Devoir réécrire un pipeline à chaque système hors les murs raccordé, c’est précisément le mur sur lequel cette entreprise a buté dans son PoC.

Étalons la comparaison : non pas qui est meilleur, mais à qui chacun convient

Dimension	Suite fermée (Agentforce / Copilot / ServiceNow)	Runtime ouvert auto-hébergé (ObjectStack / ObjectOS)
Convient le mieux à	Activité déjà fortement concentrée dans cet écosystème	Données dispersées sur plusieurs systèmes, multi-pile, à détenir soi-même
Emplacement des données	Cloud du fournisseur	Votre propre infrastructure
Choix du modèle	Penche pour le modèle maison ou imposé	Libre de changer, le modèle dehors, le runtime dedans
Propriété de la définition métier	Pousse dans la plateforme	Métadonnée sous protocole ouvert dans votre dépôt (Apache 2.0)
Facturation	À l’action / au siège	Selon le runtime et l’infrastructure, découplée de l’usage
Posture de départ	D’abord déménager l’activité dans l’écosystème	Étendre les systèmes existants, sans exiger de migration préalable

Ce tableau n’a pas de colonne « tout juste ».

D’abord deux douches froides : bien souvent, vous devez choisir la suite

Disons-le d’emblée, pour que cet article ne devienne pas une publicité à sens unique. L’ouvert auto-hébergé n’est pas un choix plus noble ; c’est un choix préparé pour une situation particulière — et bien des entreprises sont, justement, en situation de convenir à la suite.

Premièrement, si votre monde tient réellement, pour l’essentiel, dans les murs d’un seul. 90 % de votre activité est dans Salesforce, la sortie de territoire des données vous est indifférente, vous ne comptez pas changer de modèle — alors Agentforce est probablement l’optimum. Assumer une charge de migration et d’exploitation bien réelle et immédiate pour parer un risque de « verrouillage » qui n’est pas encore survenu n’est pas rentable.

Deuxièmement, si vous n’avez pas d’équipe plateforme. C’est le classique « construire ou acheter ». L’ouvert, l’auto-hébergé, signifie que vous devez l’exploiter vous-même — appliquer les correctifs, garantir la disponibilité, gérer les montées de version. L’expérience managée des suites, « prêt à l’emploi, quelqu’un décroche en cas de pépin, un SLA qui couvre », vaut souvent plus, pour une entreprise sans équipe plateforme dédiée, et soulage davantage que le « contrôle total ». Le contrôle a un coût d’exploitation, et un contrôle que personne ne peut assumer est un fardeau.

Mais « acheter la suite » épargne moins de travail que vous ne le croyez

Cela dit, du côté « acheter », il y a une facture souvent oubliée du calcul : la taxe d’intégration.

Le devis de la suite affiche le prix des sièges ou des actions ; ce qu’il n’affiche pas, c’est que chacun de vos sept ou huit systèmes hors les murs exige un pipeline d’intégration : aligner les définitions à la construction, maintenir ensuite en continu au gré des montées de version des deux côtés, et dès qu’une extrémité change un champ, le pipeline peut casser en silence. Les six semaines de PoC de l’entreprise du début mesuraient l’acompte de cette taxe. Ainsi, « acheter la suite + un tas d’intégrations fragiles », c’est en apparence acheter, mais au fond vous construisez encore — et vous construisez la partie la moins précieuse et la plus fragile.

En intégrant cette taxe d’intégration au TCO, la conclusion « acheter soulage davantage » ne tient que si vos systèmes hors les murs sont peu nombreux, ou s’ils n’ont de toute façon pas besoin d’être atteints par l’agent. Plus les systèmes sont dispersés, plus cette taxe est lourde, et plus l’avantage « tranquillité » de la suite est grignoté.

En fait, vous pouvez utiliser les deux : l’hybride n’est pas s’asseoir entre deux chaises

Cela amène une option longtemps négligée dans les débats de choix d’outil : ce n’est pas forcément un choix unique.

L’architecture la plus pragmatique est souvent hybride : dans l’écosystème que vous utilisez réellement de façon intensive, continuez d’employer sa suite — l’agent commercial dans Salesforce, laissez-le à Agentforce, c’est ce qu’il fait de mieux ; mais sur la couche transversale, qui exige une définition unifiée et une donnée détenue en propre, utilisez un runtime ouvert et auto-hébergé comme tissu de connexion. Ce dernier ne remplace pas la suite ; il fait ce que la suite, structurellement, fait mal : rassembler une activité dispersée entre plusieurs murs en une définition unifiée que vous détenez vous-même, dotée de permissions et d’audit.

Autrement dit, le runtime ouvert peut être le tissu de connexion au-dessus de vos multiples systèmes (y compris ces suites), et non un mur de plus dans lequel il faut déménager. Reconnaître cela transforme le choix de « sur quel acteur miser » en « quelle partie à la suite, quelle partie à l’ouvert » — et c’est ainsi que la plupart des entreprises réelles finissent par atterrir.

L’ouvert auto-hébergé, qu’apporte-t-il au juste

Si vous appartenez à la colonne de droite, ou si ce que vous devez faire est précisément cette couche de connexion transversale, alors « ouvert + auto-hébergé » apporte non pas un idéal romantique, mais des capacités concrètes. Le plus parlant, c’est sa posture vis-à-vis des systèmes existants — précisément l’endroit où l’entreprise du début s’est retrouvée bloquée.

La suite veut que votre monde déménage dans ses murs ; le runtime ouvert suppose que votre monde est, par nature, dispersé, et son travail est de faire que les systèmes existants prennent nativement en charge l’IA, sans migration préalable. Les données clients de cette entreprise étaient pour moitié dans Salesforce, pour moitié dans un système maison. Sur ObjectOS, elle peut brancher chaque système comme source de données, les modéliser en objets, puis les aligner en un seul « client » gouverné grâce à une clé partagée — le numéro fiscal :

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Client',
  fields: {
    name: Field.text({ label: 'Nom du client', required: true }),
    tax_id: Field.text({ label: 'N° SIREN' }), // une clé partagée pour aligner « le même client » entre les systèmes
  },
});

La différence se concrétise jusqu’à une question. « Ce client vaut-il la peine qu’on investisse des ressources pour le conserver ? » —

• Avant : l’agent branché sur Salesforce voit des opportunités actives et répond « oui » ; il ignore totalement que, dans le système maison, la livraison de ce client accuse des retards chroniques et que les tickets s’accumulent.
• Après : l’agent fait face à un seul client unifié, regarde ensemble opportunités, livraison et tickets, et répond « les opportunités sont bonnes, mais le risque de livraison est élevé : réglez d’abord l’exécution avant de parler d’extension de compte ».

Même modèle, même question ; simplement parce que le « client » sous ses pieds n’est plus découpé par les murs, la conclusion passe du partiel au global. Et tout cela sans avoir à réécrire un pipeline de synchronisation par système hors les murs — la définition métier est une métadonnée diffable et migrable dans votre dépôt ; le runtime tourne sur votre propre infrastructure, impose les permissions, enregistre l’audit ; le modèle peut venir de n’importe quel fournisseur externe. Vous n’avez confié « la définition de votre propre métier » à la garde de personne.

Un choix honnête

Ce n’est donc pas « qui doit être éliminé », mais « quelle partie confier à qui ». Posez-vous trois questions :

1. Mon activité est-elle pour l’essentiel dans un seul écosystème, ou dispersée sur plusieurs systèmes ?
2. Puis-je accepter que mes données affluent en continu vers le cloud du fournisseur ? Puis-je le signer en conformité ?
3. Ai-je une équipe pour exploiter un runtime auto-hébergé ?

Si les deux premières réponses penchent vers « dispersée, non » et la troisième vers « oui » — alors ce que vous cherchez n’est pas, dès le départ, une énième suite fermée plus puissante, du moins pas sur cette couche transversale. Si les trois réponses penchent de l’autre côté, alors employez la suite sans complexe, elles sont effectivement efficaces. Se situer honnêtement, voire mélanger généreusement les deux, importe bien plus que de courir après la dernière fonctionnalité de tel ou tel acteur — et coûte bien moins cher que de le comprendre après six semaines de PoC.

Conclusion

Ce que gagne la suite fermée, c’est « le meilleur dans l’écosystème », un avantage très réel quand sa prémisse tient, qu’il ne faut pas nier. Ce que gagne le runtime ouvert auto-hébergé, c’est « tenir encore quand la prémisse ne tient pas » — quand votre monde est dispersé, que les données doivent être détenues en propre, que le modèle doit rester libre, que la définition doit être tenue entre vos mains, et que vous pouvez assumer la responsabilité de l’exploiter vous-même.

Savoir quelle partie doit aller à la suite, quelle partie à l’ouvert, et quel prix payer pour chacune — voilà ce qui importe, bien plus que la liste de fonctionnalités de quiconque. Si l’entreprise du début avait posé ces trois questions plus tôt, elle aurait économisé six semaines et un PoC.

npm i -g @objectstack/cli && os start

Sans migration, sans entrer dans les murs de qui que ce soit, faites tourner en cinq minutes, dans votre propre environnement, un objet unifié à cheval sur deux systèmes — puis jugez si cette voie ressemble davantage à ce que vous cherchez.