Des chatbots au work OS : comment les assistants IA avalent le SaaS d’entreprise

Il y a trois ans, le chatbot d’entreprise était un onglet gadget. Les salariés l’ouvraient pour rédiger un e-mail ou résumer un PDF, puis retournaient au vrai travail dans leur CRM, leur outil de tickets, leur portail RH et leurs tableurs. Fin 2026, le tableau change. La fenêtre de chat devient tranquillement l’endroit où le travail commence — et de plus en plus souvent où il se termine. L’assistant IA d’entreprise n’est plus une fonctionnalité vissée sur un logiciel ; il est en train de devenir le produit lui-même.

Ce basculement a un nom qui revient dans les présentations stratégiques : le work OS IA. L’idée est simple. Si un seul assistant peut lire vos fichiers, interroger vos systèmes métier, lancer des workflows multi-étapes à l’horaire et agir avec une piste d’approbation, il se comporte comme un système d’exploitation du travail de connaissance. Tout le reste — y compris une bonne part des plateformes SaaS IA payées depuis une décennie — risque de devenir la plomberie sous-jacente.

Cet article regarde comment les grandes plateformes d’assistants en sont arrivées là, ce que « work OS » veut dire concrètement, et ce que cela fait à l’économie du logiciel d’entreprise : tarification par siège, systems of record, et la couche d’interface que les éditeurs SaaS ont longtemps traitée comme leur avantage concurrentiel.

Du moteur de réponses au moteur d’actions

Phase 1 : la boîte de chat

La première génération d’assistants d’entreprise était pour l’essentiel une version sécurisée du chat grand public. Les arguments de vente : protection des données, contrôles admin, et la promesse que les prompts de l’entreprise ne serviraient pas à entraîner les modèles. Utile, mais contenu : l’assistant ne savait que ce que vous colliez dedans.

Phase 2 : connecteurs et contexte

La deuxième phase a porté sur le contexte. Les assistants ont appris à atteindre les endroits où vit réellement la connaissance d’entreprise. Les pages d’aide OpenAI décrivent désormais des plugins ChatGPT qui se connectent à des outils comme Slack, SharePoint, Airtable et Google Drive. Point crucial : l’assistant ne voit que ce que l’utilisateur peut déjà voir dans l’app connectée. Sur les plans Enterprise et Edu, ces intégrations sont désactivées par défaut, et les administrateurs décident lesquelles sont disponibles et pour qui.

Google a pris la même voie avec Gemini Enterprise, lancé le 9 octobre 2025. Dans le post de lancement, le CEO Google Cloud Thomas Kurian a dit que la plateforme se connecte aux données d’entreprise « wherever it lives », citant Google Workspace et Microsoft 365 ainsi que des applications métier comme Salesforce et SAP, le tout sous un cadre de gouvernance central. Reuters a décrit le produit comme une plateforme conversationnelle où les salariés chatent avec les données, documents et applications de leur entreprise.

Phase 3 : des agents qui font le travail

La troisième phase, en cours, porte sur l’action. Les workspace agents d’OpenAI, en research preview pour les plans ChatGPT Business, Enterprise, Edu et Teachers, permettent aux équipes de construire un agent une fois, de le partager dans un workspace, de le lancer à l’horaire, de l’utiliser dans Slack, ou de le déclencher via une API. Les propres exemples d’OpenAI sont éloquents : revoir des leads, résumer des demandes support, générer des rapports, mettre à jour des tickets, éditer des documents et envoyer des messages. C’est la liste des jobs que les gens faisaient en cliquant dans plusieurs interfaces SaaS.

En sous-couche se trouve le Model Context Protocol (MCP), un standard ouvert pour connecter les modèles IA aux outils. La documentation OpenAI indique qu’un support MCP complet, y compris les actions d’écriture et de modification, se déploie en bêta chez les clients Business, Enterprise et Edu. Ses exemples cités incluent le démarrage de workflows, la création de tâches de gestion de projet et la mise à jour du CRM, le tout depuis ChatGPT. Microsoft a annoncé un large support MCP en propre à Build 2025 sur GitHub, Copilot Studio, Dynamics 365, Azure AI Foundry et Windows 11, et a rejoint le steering committee MCP. Le lancement de Gemini Enterprise chez Google a nommé MCP aux côtés du protocole Agent2Agent (A2A) comme standards de communication entre agents.

Une fois l’accès en lecture et en écriture standardisé, l’assistant cesse d’être un spectateur et devient un contrôleur.

Les power players et leurs stratégies

Quatre sociétés définissent aujourd’hui le marché de l’assistant IA d’entreprise, chacune depuis un point de départ différent.

OpenAI : l’assistant comme destination

La stratégie d’OpenAI est de faire de ChatGPT la porte d’entrée. Sa page Enterprise décrit des modèles et agents, dont « ChatGPT Work » et l’agent de code Codex, qui utilisent « your approved tools, files, and team processes ». La direction est claire : les utilisateurs ne devraient plus avoir à quitter ChatGPT pour travailler. Apps, plugins, apps MCP sur mesure et workspace agents tirent les autres logiciels dans la conversation, pas l’inverse.

Microsoft : la suite incumbente, recentrée sur Copilot

Microsoft possède déjà la suite productivité, la couche identité et une bonne part de la stack développeur d’entreprise. Son mouvement : faire de Microsoft 365 Copilot la couche d’orchestration au-dessus de tout cela. À Build 2025, la société a présenté Copilot Tuning, qui permet aux clients d’utiliser leurs propres données et processus pour bâtir des agents métier en low code, et l’orchestration multi-agents dans Copilot Studio. Côté développeur, le Microsoft Agent Frameworks open source fusionne AutoGen et Semantic Kernel et prend en charge OpenAPI, A2A et MCP.

Microsoft est aussi notablement agnostique sur les modèles. Anthropic a annoncé que Claude Sonnet 4 et Claude Opus 4.1 sont devenus des modèles sélectionnables dans l’agent Researcher de Microsoft 365 Copilot et dans Copilot Studio. Pour les acheteurs, le message est que la plateforme compte plus que n’importe quel modèle unique — exactement ce qu’on attend d’une société qui se positionne comme work OS.

Google : Workspace plus une plateforme d’agents ouverte

L’argumentaire de Google avec Gemini Enterprise combine une intégration profonde aux apps Workspace et une promesse explicite d’ouverture, y compris le travail avec Microsoft 365 et SharePoint. Google a aussi replié ses outils développeur dans ce qu’il appelle désormais la Gemini Enterprise Agent Platform, positionnée comme le lieu pour bâtir, monter en charge, gouverner et optimiser une « agentic workforce ». Le pari : la plateforme d’agents, pas l’éditeur de documents, devient l’ancre de long terme.

Anthropic : le modèle dans le OS de tout le monde, et le sien

Anthropic joue des deux côtés. Claude se vend directement aux entreprises, et apparaît aussi dans les plateformes d’autres éditeurs, de Microsoft 365 Copilot à Salesforce. The Register a rapporté que AIforce de Salesforce, dévoilé à Dreamforce, expose les données, workflows et logique métier de la société via des interfaces dont Slack et Claude. Quand un géant du CRM livre un moyen de consommer sa logique depuis un assistant tiers, la direction du voyage est difficile à manquer.

Ce que « work OS IA » veut réellement dire

La formule est utilisée librement ; autant la définir. Un work OS IA a grosso modo cinq couches :

1. Un front end conversationnel et agentique unique : la fenêtre de chat, plus des agents qui tournent en arrière-plan.
2. Un fabric de connecteurs : plugins, serveurs MCP et API qui atteignent documents, e-mail, calendriers et systèmes métier.
3. Identité et permissions : accès basé sur les rôles, authentification utilisateur final vs compte de service, et contrôles d’action par outil. Les workspace agents d’OpenAI, par exemple, permettent à chaque connexion de tourner sur le compte de l’utilisateur ou sur un compte appartenant à l’agent, et recommandent des comptes de service à accès minimal.
4. Gouvernance et audit : logs des appels d’outils et fichiers consultés, et portes d’approbation avant les actions sensibles (envoyer un message, mettre à jour un enregistrement).
5. Une couche modèle : de plus en plus interchangeable, comme le montre l’adoption de Claude par Microsoft.

Regardez cette stack et remarquez ce qui manque : l’UI applicative. Dans un work OS, les écrans que les éditeurs SaaS ont mis des années à designer deviennent optionnels. L’agent appelle l’API, l’utilisateur revoit le résultat dans le chat, et le dashboard soigneusement construit de l’éditeur peut ne jamais se charger.

L’impact sur le SaaS d’entreprise

1. Le tarification par siège sous pression

Le licensing par siège suppose qu’un humain est assis devant le logiciel. Les agents cassent cette hypothèse. The Register l’a dit sans détour : quand des agents IA et des API font le travail à la place d’utilisateurs humains nommément assis sur des sièges, facturer par utilisateur devient un moins bon fit.

Salesforce est le cas d’école le plus clair, parce qu’il expérimente en public. Sa page de pricing Agentforce propose trois modèles côte à côte : licences par utilisateur, Flex Credits à 500 $ pour 100 000 crédits (une action standard coûtant 20 crédits et une action voix 30), et Conversations à 2 $ pièce. Salesforce Ben a rapporté une étape de plus : un pricing pay-per-resolution pour le nouvel Agentforce Help Agent, annoncé pour juillet 2026, où le client n’est facturé que lorsque l’agent résout un problème seul. Les propres mots de Salesforce : « If the customer asks for a human or walks away unhappy, there is no charge. »

Salesforce n’est pas seul. Channel Insider note qu’Intercom facture son agent Fin sur des outcomes définis comme des issues résolues, et que Zendesk étend un pricing outcome-based autour de résolutions vérifiées. Le même article range le marché en quatre modèles : abonnements traditionnels, consommation, action-based et outcome-based.

Pourtant le siège n’est pas mort. TechTarget a cité Marc Benioff disant que certains clients « still want pure user pricing ; it’s predictable », tandis que d’autres veulent du pricing agent, usage, consommation ou outcome. « We’ve had to throw away our price book, basically », a-t-il dit. Le pricing outcome a aussi un problème de mesure : acheteur et vendeur doivent s’accorder sur ce qui compte comme résultat facturable. Attendez-vous à des contrats hybrides, pas à un switch propre.

2. Systems of record : toujours essentiels, mais moins visibles

Si l’assistant devient le front end, que deviennent le CRM, l’ERP et la plateforme RH ? En bref : plus importants comme données et logique, moins importants comme destinations.

Les agents ont besoin d’une source de vérité digne de confiance pour lire et écrire. Tout assistant IA d’entreprise sérieux s’appuie sur des connecteurs vers exactement ces systèmes, comme le montre la liste Google de Salesforce et SAP. Les éditeurs qui possèdent des données propres, permissionnées et bien modélisées tiennent quelque chose qu’un assistant ne peut pas inventer seul.

Le risque, c’est la commoditisation. Si la valeur d’un éditeur n’est atteinte que via une API appelée par l’agent de quelqu’un d’autre, la relation client, l’habitude quotidienne et une bonne part du pouvoir de pricing montent dans la stack. C’est pourquoi les éditeurs de systems of record se précipitent pour livrer leurs propres agents (Agentforce en exemple évident) tout en ouvrant un accès « headless » aux assistants tiers. Ils se couvrent : posséder l’agent là où c’est possible, être le back-end indispensable là où ce n’est pas le cas.

3. La couche UI est le vrai champ de bataille

Pendant vingt ans, la différenciation SaaS a largement vécu dans l’interface : meilleurs workflows, dashboards plus jolis, moins de clics. Un work OS IA aplatit cet avantage. Quand l’instruction « mets à jour l’opportunité, journalise l’appel et rédige le follow-up » peut s’exécuter à travers trois outils depuis un seul prompt, l’élégance des écrans de chaque outil compte moins.

Cela crée trois profils de gagnants probables :

• Propriétaires de plateforme (Microsoft, Google, OpenAI, Anthropic) qui contrôlent le front end, l’identité et la gouvernance des agents.
• Propriétaires de données : systems of record avec des données profondes, propriétaires et bien gouvernées que tout agent doit toucher.
• Spécialistes de workflows durs et régulés, où la logique métier, la conformité et la responsabilité justifient encore un produit dédié.

Le milieu écrasé, c’est l’outil horizontal dont la valeur principale était une interface pratique sur des données qui vivent ailleurs.

Ce que les acheteurs d’entreprise doivent faire maintenant

Pour les DSI et les équipes achats, le basculement vers les plateformes SaaS IA et le travail piloté par assistant soulève des questions concrètes :

• Choisir un work OS primaire délibérément. La plupart des organisations ne feront pas tourner quatre assistants à égalité. Décidez lequel possède le front end, et traitez les autres comme fournisseurs de modèles ou de connecteurs.
• Auditer les permissions des connecteurs. L’accès en écriture via MCP est puissant. Utilisez les contrôles admin que ces plateformes fournissent : plugins off-by-default, accès par rôle, portes d’approbation et logs d’audit.
• Préférer les comptes de service au moindre privilège pour les agents qui tournent sans supervision, comme le recommande le propre guide d’OpenAI.
• Renégocier en pensant agents. Si des agents feront le travail que des sièges faisaient, demandez aux éditeurs des options consommation, action ou outcome, et modélisez le coût sous chacune.
• Garder votre system of record propre. Un assistant n’est aussi bon que les données qu’il peut atteindre. La qualité des données est désormais une stratégie IA.
• Exiger des standards ouverts. Le support MCP et A2A réduit le lock-in à un seul assistant.

Ce que les éditeurs SaaS doivent faire maintenant

Pour les éditeurs, le playbook est inconfortable mais clair :

• Être agent-ready d’abord. Publiez des API robustes et des serveurs MCP, avec permissions fines et sémantique d’action claire. Si votre produit ne peut pas être utilisé depuis l’assistant de quelqu’un d’autre, il sera remplacé par un qui le peut.
• Livrer votre propre agent là où vous avez un contexte unique. Données métier plus logique métier : c’est la combinaison défendable.
• Repenser le packaging. Offrez un pricing hybride avant que les clients ne l’exigent. L’approche à trois modèles de Salesforce montre à la fois l’opportunité et la complexité.
• Déplacer la valeur vers les outcomes et la confiance. Gouvernance, auditabilité et résultats mesurables sont les nouveaux différenciateurs, plus que les écrans.

En résumé

Le chatbot d’entreprise a grandi. Les connecteurs lui ont donné du contexte, MCP lui a donné des mains, et les workspace agents lui ont donné un horaire et une fiche de poste. Le résultat est un work OS IA émergent où l’assistant est le produit et où de nombreuses applications SaaS deviennent des services qu’il appelle.

Cela ne signifie pas que le SaaS d’entreprise disparaît. Systems of record, workflows spécialisés et données de confiance valent plus que jamais. Mais l’économie bascule : des sièges vers les actions et outcomes, des interfaces vers les API, et de la possession de l’attention de l’utilisateur vers une place méritée dans la boîte à outils de l’assistant. Les éditeurs qui l’acceptent tôt seront ceux que les agents continueront d’appeler.

À lire aussi

• Trois champs de bataille des interfaces IA : chat, copilotes in-app et agents autonomes
• Les agents computer-use entrent en production : ce qui fonctionne réellement en entreprise
• Modèles open-weight de frontière vs API fermées : le compromis de souveraineté

< !– Schema.org NewsArticle (CF_SEO) –>

Images : illustrations originales créées pour AndBeyond.Tech ; aucun logo ni aucune personne réelle n’y figurent.