Quand des modèles arrivent sur SageMaker plusieurs semaines voire plusieurs mois après leur lancement sur Bedrock, cela peut donner envie de migrer d’un service à l’autre.

Mi-2024, Slack avait fait la bascule… en partie sur ce fondement. En toile de fond, l’intégration recénte de fonctionnalités de recherche et de résumé portées par des LLM.

SageMaker et les « travaux de plomberie »

L’architecture initiale déployée sur SageMaker impliquait un VPC d’entiercement. Les LLM s’y exécutaient, Slack pouvant par là même garantir aux utilisateurs que leurs données « [restaient] en interne ».

Pour maximiser la disponibilité, ces conteneurs furent déployés sur plusieurs régions AWS. Cela ne résolvait toutefois pas la latence de mise à l’échelle. Ni la disponibilité intermittente des GPU A100 et H100, ainsi que la nécessité de surprovisionner pour respecter les SLA.

Slack avait éliminé le problème de scaling avec de la planification cron. Et celui du surprovisionnement en passant par de la réservation de capacité à la demande.
À la coordination manuelle et aux « travaux de plomberie », il a cependant fini par privilégier une gestion automatisée de la capacité. Bedrock la lui a apportée… en plus, donc, d’un accès plus rapide aux derniers modèles.

Malgré Bedrock, de la capacité restait sous-utilisée

Mi-2024, Bedrock satisfaisait les attentes de Slack en matière de sécurité et de conformité (il avait obtenu la certification FedRAMP, niveau intermédiaire). Au-delà de l’aspect managé (plus besoin de gérer individuellement des instances GPU), il a permis d’adapter le compute aux charges de travail. En jouant, en l’occurrence, entre le débit provisionné et la capacité à la demande.

La première option fut utilisée pour les fonctionnalités interactives sensibles à la latence, comme le résumé de canal.

La seconde le fut pour les workloads prévisibles à fort pic de charge, tel le récapitulatif quotidien.

Cette association a contribué à réduire les ressources inutilisées. Il a néanmoins fallu, pour assurer une bonne expérience sur certaines fonctionnalités, se caler sur un pic de trafic, quand bien même il n’était atteint que dans une région géographique. Ce fut le cas pour le brief quotidien, dit « vue Aujourd’hui ». L’usage était plus important aux États-Unis qu’en Europe et en Asie, engendrant une sous-utilisation de capacité.

Un effet de verrouillage avec le débit provisionné

Le débit provisionné présentait un autre écueil : la nécessité de s’engager sur 1 à 6 mois. Dans l’univers des LLM, où les progrès sont rapides, cela réduit l’aptitude à suivre la cadence. Slack choisissait effectivement souvent d’attendre que ses engagements arrivent à expiration pour changer de modèle.

Dans ce contexte, tout a progressivement migré vers de l’infra à la demande, moyennant une étape intermédiaire basée sur un système de débordement. Bedrock s’est révélé efficace pour faire du routage multirégion en fonction de la disponibilité. Mais le modèle de ressources partagées a engendré des niveaux de service variables – un problème qui ne se posait pas avec le débit provisionné. Et soulevé un risque de concentration, autrement dit d’exposition aux pannes sur l’infrastructure globale.

Slack a donc construit une forme de résilience. Il a établi, pour chaque fonctionnalité IA, une hiérarchie de modèles. Un basculement s’orchestrait en cas de dégradation de certains indicateurs (délai pour le premier token, plafonnement du débit de requête, niveau de satisfaction client…).

Du multicloud… moyennant normalisation

Ce mécanisme ne protégeait pas contre l’exposition aux pannes globales. Slack avait par ailleurs constaté que les catalogues de modèles différaient entre clouders. Deux aspects qui ont motivé le passage au multicloud.

Début 2026, Slack AI s’étendait officiellement à Google Cloud. Il affirme qu’ajouter le catalogue de Vertex AI à celui de Bedrock lui a permis d’améliorer d’environ 10 % ses indicateurs de qualité sur les « tâches de raisonnement complexe ». Et de réduire de 67 % la latence sur les « petits » workloads (peu gourmands en tokens).

Le multicloud lui a aussi permis d’implémenter davantage de stratégies de routage du trafic, à base de divers circuit breakers et d’A/B testing. Pour résoudre le problème des démarrages à froid, il a implémenté une authentification sans secrets et une couche de normalisation API. Il a aussi fallu développer une stack unifiée pour le monitoring, les dashboards natifs de l’un et de l’autre laissant des zones d’ombre. S’est également posé le défi du suivi des coûts, plus délicat lorsque des workloads basculent dynamiquement entre clouds. Quant aux ingés, ils ont dû se former sur les deux écosystèmes…

Illustration principale générée par IA

The post D’AWS à GCP, comment l’IA de Slack est devenue multicloud appeared first on Silicon.fr.

Salesforce veut faire de Slack bien plus qu’un outil de messagerie : un véritable “hub” de coordination pour les agents IA, les applications métier et les workflows de l’entreprise. L’objectif affiché est de transformer Slack en “système d’exploitation du travail”, où l’IA se déploie dans les usages réels, au cœur des conversations et des décisions.

Derrière cette promesse de simplicité, se dessine un pari stratégique nettement plus lourd : faire de Slack la porte d’entrée principale de l’écosystème Salesforce en général, et de ses agents IA en particulier.

Slackbot, coéquipier agentique

Le moteur de cette transformation porte un nom : Slackbot, désormais présenté comme un “membre numérique” de l’équipe, capable de résumer, rechercher, rédiger, transcrire des réunions, lancer des workflows et router des requêtes vers Agentforce ou d’autres applications via le Model Context Protocol (MCP).

Salesforce annonce plus de 30 nouvelles fonctionnalités, dont :
> La transcription et la prise de notes en réunion, avec actions automatiquement mises à jour dans le CRM ;
> Une présence étendue de Slackbot dans l’environnement de travail, qui peut interagir avec les apps métiers sans installation supplémentaire ;
> Des “AI Skills” réutilisables, permettant de définir une tâche une fois et de l’exécuter automatiquement à chaque occurrence ;
> Le routage intelligent des demandes vers Agentforce ou n’importe quelle application tierce connectée à Slack.

Sur le papier, Slackbot devient un orchestrateur plutôt qu’un simple assistant : il ne se contente pas d’agir sur demande, mais de détecter opportunément les requêtes qui correspondent à une compétence déjà définie et de réagir automatiquement.

Une interface unique pour orchestrer agents et CRM

Pour Salesforce, la vraie valeur ajoutée n’est pas dans les fonctionnalités isolées, mais dans leur assemblage : Slack devient l’interface conversationnelle de Customer 360.

Les équipes commerciales ou service client pourront, en théorie, mettre à jour des opportunités, interroger des comptes, gérer des cas ou déclencher des workflows sans ouvrir une seule application Salesforce, en passant uniquement par des conversations.

Du côté de l’écosystème, Slackbot s’appuie sur :

> Le Slack Marketplace (plus de 2 600 applications) ;

> AppExchange (plus de 6 000 solutions Salesforce) ;

> Le nouveau client MCP, qui permet de router des requêtes vers n’importe quel agent ou application connectée.

Pour les analystes, c’est cohérent avec la montée des systèmes multi‑agents, où l’enjeu devient moins l’IA isolée que l’orchestration entre agents, humains et données.

Un verrouillage technologique “friendly” mais bien réel

Derrière la logique d’orchestration, les analystes soulignent une conséquence structurelle : Salesforce renforce son emprise sur l’environnement de travail numérique.

Plusieurs observateurs rappellent que Slack a déjà restreint l’accès de tiers à la recherche et au stockage des messages, ce qui alimente les inquiétudes autour du contrôle des données et du verrouillage plateforme.

Dans ce contexte, l’intégration toujours plus poussée entre Slack, Salesforce et Agentforce peut être perçue comme une simplification pour l’utilisateur, mais aussi comme une dépendance accrue pour l’entreprise.

Du côté des DSI, la question devient donc double :

> Jusqu’où accepte‑t‑on de concentrer la couche d’orchestration IA dans un seul écosystème ?

> Comment sécuriser la gouvernance, la qualité des données et la traçabilité des décisions automatiques, alors que Slack devient l’interface par défaut de l’IA métier ?

PME : un accès doux au CRM…avec un couloir vers Salesforce

Pour les petites entreprises, la nouvelle offre de Slack offre un parcours “CRM‑lite” directement dans la messagerie. Slackbot analyse les échanges, identifie les prospects, met à jour les opportunités et les comptes rendus d’appel, puis synchronise le tout avec Salesforce, sans migration.

Cette approche est séduisante pour les PME qui cherchent à démarrer simplement avec l’IA tout en restant dans un environnement de messagerie déjà familier.

Elle constitue aussi, de fait, un couloir d’upsell vers Salesforce, rendant la montée en puissance vers un CRM complet à la fois logique et technique.

Le pari de la productivité, mais son coût réel reste à prouver
Salesforce met en avant des gains de productivité impressionnants : jusqu’à 90 minutes d’économie par jour pour certains utilisateurs, et jusqu’à 20 heures par semaine pour certaines équipes internes, soit l’équivalent de plusieurs millions de dollars de gains de productivité.

Ces chiffres, issus de cas clients et d’un usage interne, sont probants comme signaux d’adoption et de satisfaction.

Mais ils restent des indicateurs de performance individuelle, pas de ROI global. Pour les analystes, la véritable valeur se mesurera à la manière dont les entreprises réaffecteront ces gains de temps à des tâches à forte valeur ajoutée, et non seulement à une réduction de charge de travail.

Vers un “OS du travail” ou un hub d’IA verrouillé ?

Au fond, Salesforce ne se contente pas de moderniser Slack : il en redéfinit le rôle dans l’entreprise. Slack devient une couche d’orchestration des agents IA, avec une promesse claire de simplicité, de productivité et d’intégration CRM.

Mais cette évolution s’accompagne d’un renforcement de la dépendance à son écosystème Salesforce, ce qui nourrit les critiques sur la concentration des données et la difficile reprise de la main en cas de changement de fournisseur.

Si l’exécution suit, Slack pourrait devenir un point d’entrée de l’IA en entreprise. S’il déçoit, Salesforce aura surtout démontré qu’un excellent outil de collaboration peut être un excellent outil de verrouillage technologique.

Image : © DR

The post Salesforce repense Slack comme interface centrale des agents IA appeared first on Silicon.fr.