Salesforce et Google Cloud ont annoncé le 15 septembre 2026 une extension de leur partenariat portant sur Hyperforce, l’infrastructure cloud de Salesforce, le partage de données et les agents IA. Le communiqué rassemble des fonctions existantes, des préversions et des disponibilités futures. Pour une entreprise, l’enjeu n’est pas de reprendre toute l’annonce dans son architecture, mais de distinguer ce qui peut être testé maintenant de ce qui dépend encore d’un calendrier fournisseur.
Ce qui est disponible et ce qui est annoncé
Selon Salesforce, Hyperforce sur Google Cloud traite déjà du trafic de production. Une migration de certains clients américains doit commencer au quatrième trimestre 2026 et une disponibilité générale en Amérique du Nord est annoncée pour novembre. D’autres extensions régionales et fonctionnelles sont prévues ensuite. Le communiqué décrit aussi des liens entre Gemini Enterprise, Agentforce, Tableau et Data 360 ; leurs niveaux de disponibilité diffèrent selon la fonction.
Cette distinction compte : une démonstration, une bêta et une disponibilité générale n’engagent pas les mêmes conditions de support, de licence et de fonctionnement en production. Les dates annoncées peuvent évoluer.
Ce que cela change pour une entreprise
Pour une organisation qui utilise déjà Salesforce, la question principale est la circulation des données et des actions entre plateformes. Quels jeux de données un agent peut-il lire ? Quelle opération peut-il déclencher dans un processus de vente ou de service ? Où résident les données et qui audite les actions ? Un projet de preuve de concept devrait partir d’un usage mesurable, comme la préparation d’un dossier client, avant d’élargir les permissions.
- Vérifier la région, la licence et le statut réel de chaque intégration envisagée.
- Cartographier les identités, les données exposées et les contrôles d’accès.
- Mesurer le gain attendu et le coût d’exploitation, y compris les échanges entre services.
La décision à préparer
Un architecte cloud peut utiliser cette annonce comme un élément de veille, puis inscrire les fonctions pertinentes dans une feuille de route conditionnelle. Les prérequis techniques et contractuels doivent être confirmés avec les éditeurs avant toute promesse de déploiement. Les intégrations déjà utilisées méritent aussi une revue : l’existence d’une nouvelle option ne signifie pas qu’une migration apporte automatiquement de la valeur.
Le meilleur résultat d’une veille technologique est une décision argumentée sur le périmètre, le calendrier et les critères de validation — pas une liste de nouveautés ajoutées au projet.
À retenir
Une feuille de route cloud doit séparer les possibilités présentes, les préversions, les régions et les coûts d’intégration avant de décider.
