Named Credentials et External Services : sécuriser vos intégrations

Trop de projets Salesforce contiennent encore des appels HTTP en Apex avec une clé API codée en dur dans une Custom Setting ou pire, directement dans le code source. Les Named Credentials existent précisément pour éliminer ce risque : elles centralisent l'URL du point de terminaison et les identifiants d'authentification d'un service externe, séparément du code qui les consomme.

1. Pourquoi les Named Credentials changent la donne

Sans Named Credential, un développeur doit gérer manuellement dans son code Apex l'ajout des en-têtes d'authentification, le stockage du secret, et son renouvellement (rafraîchissement de token OAuth). Avec une Named Credential (Configuration > Sécurité > Named Credentials), Salesforce :

• Injecte automatiquement les en-têtes d'authentification dans chaque HttpRequest pointant vers cet endpoint.
• Gère le rafraîchissement des tokens OAuth 2.0 de façon transparente.
• Stocke le secret de manière chiffrée, jamais visible dans le code ni exportable via Metadata API en clair.
• Évite d'avoir à ajouter l'URL externe dans les Remote Site Settings séparément — la Named Credential gère l'autorisation réseau elle-même.

2. Legacy vs Named Credentials 2.0 (avec External Credentials)

Depuis les releases récentes, Salesforce recommande le modèle en deux parties :

1. External Credential : porte la définition du protocole d'authentification (OAuth 2.0, JWT, Basic, clé API personnalisée) et peut définir des Principals distincts — un "Named Principal" partagé par tous, ou des "Per-User Principals" où chaque utilisateur Salesforce s'authentifie avec sa propre identité côté système externe.
2. Named Credential (nouvelle génération) : ne porte plus que l'URL du endpoint et référence l'External Credential pour l'authentification.

Cette séparation permet de réutiliser un même External Credential pour plusieurs endpoints, et surtout de choisir un mode d'authentification "par utilisateur" quand le système cible doit appliquer ses propres droits d'accès individuels (traçabilité fine côté système tiers).

Un Named Principal (identifiant partagé) simplifie la configuration mais casse la traçabilité individuelle côté système externe : tous les appels Salesforce apparaîtront comme provenant d'un seul compte technique. Pour des intégrations à fort enjeu d'audit, privilégiez les Per-User Principals malgré la complexité de configuration supplémentaire (chaque utilisateur doit s'authentifier une fois).

3. Contrôler qui peut utiliser une Named Credential

L'accès à une Named Credential se distribue comme une permission classique via Profils ou Permission Sets (case "Named Credentials" accessibles). Un utilisateur ou un morceau de code Apex sans cette permission explicite ne peut pas l'invoquer, même s'il connaît le nom de la Named Credential dans le code. C'est un point de contrôle supplémentaire à auditer : vérifiez régulièrement quels profils ont accès aux Named Credentials sensibles (systèmes de paiement, RH, ERP).

4. External Services : exposer une API externe comme une action Apex/Flow

Une fois la Named Credential en place, External Services (Configuration > Intégrations > Services externes) permet d'importer une spécification OpenAPI/Swagger d'une API REST externe, et de générer automatiquement des classes Apex invocables et des actions utilisables directement dans Flow Builder. Cela permet à un admin/analyste de construire une intégration sortante depuis un Flow sans écrire de code, tout en réutilisant la couche de sécurité déjà posée par la Named Credential sous-jacente.

5. Bonnes pratiques d'implémentation

• Ne jamais construire manuellement une URL ou un token dans le corps du code Apex : toujours passer par callout:MaNamedCredential dans l'endpoint de la requête.
• Nommer les Named Credentials de façon explicite et documentée (système cible, environnement) pour éviter les confusions Sandbox/Production lors des déploiements.
• Auditer trimestriellement la liste des Named Credentials actives et leurs profils autorisés, en particulier après un départ d'équipe ou un changement de prestataire.
• Préférer OAuth 2.0 avec rotation automatique de token à une clé API statique dès que le système externe le permet.