Authentification Salesforce : 3 échéances pour vos intégrations

De nombreuses organisations Salesforce utilisent encore au moins une intégration basée sur un identifiant et un mot de passe classiques : un traitement ETL, un outil de sauvegarde, un connecteur de middleware ou un vieux script dont tout le monde a oublié l'existence. L'authentification Salesforce des intégrations évolue en trois étapes d'ici l'été 2027 (Summer '27), et chacune d'elles peut rompre l'une de ces connexions en toute discrétion. Ce guide détaille les changements, les personnes impactées, le calendrier et la méthode exacte pour réussir votre migration sans interruption de service le lundi matin.

Authentification Salesforce : ce qui change pour les intégrations

Salesforce supprime progressivement les deux méthodes d'authentification par mot de passe utilisées depuis des années par les intégrations.

1. Le login() de l'API SOAP requiert désormais une autorisation spécifique (Winter '27). La documentation développeur de l'appel login() (en anglais) explique que login() peut être restreint aux utilisateurs disposant de l'autorisation Use Any API Auth. Lorsque cette restriction s'applique, toute tentative de connexion via login() par un utilisateur sans cette autorisation échoue avec une erreur INSUFFICIENT_ACCESS. La même page indique que login() reste disponible jusqu'à la version 64.0 de l'API et est désactivé par défaut dans les nouvelles orgs. Avec la version Winter '27, ce contrôle s'est déployé instance par instance lors des vagues de mise à jour entre fin août et mi-octobre 2026.

2. Le flux OAuth 2.0 username-password cesse de fonctionner pour les applications connectées (20 février 2027). La note de version Salesforce Retirement of OAuth 2.0 Username-Password Flow for Connected Apps (en anglais), initialement prévue pour Winter '27, a vu son application reportée au 20 février 2027. À compter de cette date, les intégrations envoyant grant_type=password au point de terminaison de jeton (token endpoint) seront refusées.

3. Le login() SOAP est définitivement retiré (Summer '27). La politique officielle SOAP API End-of-Life Policy (en anglais) prévoit le retrait de login() pour Summer '27. Cette même politique marque les versions 31.0 à 40.0 de l'API SOAP comme obsolètes et non supportées dès Summer '27, avec un retrait définitif prévu pour Summer '28.

Ce qui ne change pas : les opérations de données SOAP telles que query, create, update et delete continuent de fonctionner. Seule la méthode d'ouverture de session basée sur un mot de passe disparaît.

Qui est concerné

L'impact dépend moins de votre édition Salesforce que de la façon dont vos intégrations ont été développées.

• Administrateurs : l'inventaire vous incombe. Tout utilisateur d'intégration qui dépend d'un mot de passe et ne dispose pas de l'autorisation Use Any API Auth est déjà exposé depuis Winter '27.
• Équipes Intégration et DSI : les scripts personnalisés, les traitements Python ou Java et les flux de middleware qui appellent login() ou envoient un identifiant et un mot de passe au point de terminaison OAuth doivent être réécrits.
• Responsables métier d'outils tiers : les outils de sauvegarde, de chargement de données, de BI, de téléphonie ou de marketing peuvent encore utiliser l'authentification par mot de passe. Consultez les notes de migration des éditeurs ; plusieurs d'entre eux les ont déjà publiées.
• Responsables Ventes et Service Client : vous ne touchez pas au code, mais vous êtes les premiers à remarquer un arrêt de la synchronisation des leads ou le blocage d'un tableau de bord. Demandez dès maintenant un état des lieux à votre administrateur.

Un détail qui piège de nombreuses équipes : Use Any API Auth est une autorisation différente de Use Any API Client. Attribuer la mauvaise ne résoudra pas l'erreur.

Comment identifier les intégrations basées sur mot de passe dans votre org

Impossible de migrer ce que vous n'avez pas répertorié. L'objectif est d'établir la liste exacte de chaque utilisateur d'intégration, du système sous-jacent et de la méthode d'authentification utilisée.

1. Consultez les Mises à jour de version. Dans la Configuration (Setup), ouvrez Mises à jour de version (Release Updates) et recherchez la mise à jour relative au retrait du flux OAuth 2.0 username-password pour les applications connectées. Lisez les instructions de test relatives à votre organisation.
2. Filtrez l'Historique des connexions. Dans la Configuration, ouvrez Historique des connexions (Login History) et créez une vue filtrée sur Sous-type de connexion égal à OAuth Username-Password. La colonne Application indique l'application connectée concernée. Répétez l'opération pour les connexions API SOAP afin de repérer les appels à login().
3. Pensez à la rétention des données. L'Historique des connexions ne conserve les données que sur une période limitée : un traitement trimestriel ou annuel risque donc de ne pas y figurer. Interrogez les équipes métier sur les tâches ponctuelles, comme les exports de fin d'année.
4. Ne vous fiez pas uniquement à l'utilisation OAuth des applications connectées. Cette page ne liste pas les intégrations utilisant le flux username-password, même lorsqu'elles sont actives.
5. Analysez le code et les configurations. Recherchez dans vos middleware, scripts et référentiels de code les termes grant_type=password, « password grant » ou les appels à login().
6. Testez la désactivation dans une sandbox. Dans la Configuration, sous Paramètres OAuth et OpenID Connect, l'option Allow OAuth Username-Password Flows peut être désactivée. Le faire d'abord en sandbox permet de repérer les intégrations qui échouent avec une erreur invalid_grant avant que la production ne soit impactée.

Quel flux OAuth utiliser en remplacement ?

Salesforce documente plusieurs alternatives dans OAuth Authorization Flows (en anglais). Choisir la bonne option revient essentiellement à se demander : « pour le compte de qui l'intégration agit-elle ? ».

• Client credentials flow : idéal pour les échanges serveur à serveur et les middleware. L'application s'authentifie à l'aide d'une clé consommateur (consumer key) et d'un secret, puis s'exécute en tant qu'utilisateur d'intégration dédié : aucun mot de passe n'est ainsi stocké.
• JWT bearer flow : également adapté au serveur à serveur, signé au moyen d'un certificat importé dans l'application. Très robuste, mais requiert d'anticiper la rotation des certificats.
• Web server flow avec PKCE : pour les outils agissant pour le compte d'une personne qui se connecte de manière interactive.
• Named Credentials : pour les appels sortants depuis Salesforce, ils permettent de sortir les points de terminaison et les secrets du code Apex.

Ne migrez pas vers le flux username-password comme « solution rapide » au retrait de login() SOAP : ce flux a sa propre échéance fixée à février 2027. De plus, Salesforce positionne les applications clientes externes (External Client Apps) comme successeurs des applications connectées ; la création de nouvelles intégrations est donc l'occasion idéale de les adopter.

Que faire dès maintenant : un plan en 6 étapes

1. Dressez l'inventaire ce mois-ci. Une ligne par intégration : système, propriétaire, utilisateur d'intégration, méthode d'authentification actuelle, niveau de criticité.
2. Traitez en priorité les risques liés à Winter '27. Si une intégration s'appuyant sur login() doit continuer de fonctionner pendant votre migration, vérifiez si son utilisateur requiert l'autorisation Use Any API Auth et si sa licence la prend en charge.
3. Créez des utilisateurs d'intégration au privilège minimum. Chaque application OAuth doit s'exécuter avec un utilisateur dédié doté d'un ensemble d'autorisations (permission set) strictement limité aux objets et champs nécessaires, et non en tant qu'administrateur.
4. Migrez les flux critiques avant le 20 février 2027. Commencez par les intégrations qui traitent des données stratégiques : capture de leads, synchronisation des commandes, facturation.
5. Retirez login() avant Summer '27. Remplacez les connexions SOAP restantes par OAuth et mettez à niveau toute intégration rattachée aux versions 31.0 à 40.0 de l'API SOAP.
6. Désactivez l'option héritée et surveillez. Une fois la migration terminée, désactivez l'option Allow OAuth Username-Password Flows en production et surveillez l'Historique des connexions pour repérer d'éventuelles tentatives échouées.

En résumé, avant / après :

• Avant : un compte administrateur partagé, un mot de passe stocké dans un script, un jeton de sécurité à réinitialiser à chaque changement de mot de passe.
• Après : une application par intégration, des jetons OAuth, un utilisateur dédié au privilège minimum et un propriétaire identifié pour chaque connexion.

Ce chantier est aussi l'occasion d'un contrôle de sécurité salutaire. Notre guide étape par étape pour vérifier si votre org Salesforce a été attaquée couvre les vérifications relatives aux applications connectées et aux accès, tandis que notre guide pratique pour éviter la dette technique CRM explique comment documenter vos intégrations sur la durée une fois l'assainissement effectué.

Conclusion

Ces mises à jour ne sont pas optionnelles et ne peuvent être reportées : chaque échéance transformera une intégration basée sur mot de passe en échec de synchronisation. La bonne nouvelle : le parcours de migration est bien maîtrisé. Établissez votre inventaire, choisissez le bon flux OAuth, testez en sandbox, puis désactivez l'ancienne méthode. Si vous souhaitez être accompagné pour cartographier vos intégrations ou les reconstruire sur une authentification moderne, notre équipe migration et intégration CRM ainsi que nos consultants Salesforce Sales Cloud peuvent réaliser l'audit et piloter la migration aux côtés de votre DSI.