Une intégration Salesforce n’échoue presque jamais sur le protocole. S’authentifier est un problème résolu, et écrire un enregistrement aussi. Ce qui tue les projets, c’est le quota d’appels quotidien et la forme du modèle de données, découverts en général trois semaines après la mise en production, quand le traitement de nuit renvoie des erreurs et que personne ne sait dire pourquoi cela passait en recette.
Le schéma est assez régulier pour être prévu. Un développeur construit contre une org Developer Edition, tout passe, le client valide. Le code rencontre ensuite une org de production qui contient déjà un connecteur marketing, une extraction vers l’entrepôt de données et un déclencheur Apex de 2019, et le budget d’appels qui semblait généreux devient un pot commun que d’autres dépensent déjà.
Cet article met les surprises en avant : quelle API utiliser, comment le quota est calculé, ce qui arrive quand votre écriture déclenche du code que vous n’avez pas écrit, comment l’authentification a changé, et les décisions de modèle de données coûteuses à défaire.
Qu’est-ce qui décide de la réussite d’une intégration Salesforce ? Le quota et le modèle de données, pas le protocole. Le quota quotidien d’appels API vaut pour l’org entière et découle de l’édition et du nombre de licences, si bien qu’une intégration bien élevée peut être affamée par une autre, mal écrite, dans la même org. Prévoyez le traitement par lots dès la première ligne de code, fixez les external IDs et l’upsert avant toute écriture, et partez du principe que chaque enregistrement envoyé déclenchera l’Apex de quelqu’un d’autre.
Ce qu’une intégration Salesforce doit réussir
Il y a quatre choses, et elles ne pèsent pas le même poids.
La première est le quota. Chaque appel synchrone de votre code est prélevé sur un quota quotidien unique, valable pour l’org entière et partagé avec tous ses autres consommateurs.
La deuxième est la plateforme en dessous. Salesforce n’est pas une base de données munie d’une interface HTTP. C’est une plateforme applicative, et vos écritures exécutent des déclencheurs, des flux, des règles de validation, des règles de doublon et des récapitulatifs configurés par des administrateurs qui n’ont jamais entendu parler de votre projet.
La troisième est le modèle de données. Lead, Contact, Account et Opportunity ne sont pas interchangeables, la conversion entre eux ne va que dans un sens et produit des effets de bord, et un mauvais choix impose une migration de données plutôt qu’un changement de code.
La quatrième est l’identité : comment votre système et Salesforce s’accordent sur l’enregistrement dont il s’agit. Manquez cela et vous créez des doublons à la vitesse de la machine. Tout le reste découle de l’un de ces quatre points.
Le paysage des API, et celle dont vous avez besoin
Salesforce publie une grande famille d’API. L’index des API Salesforce fait autorité, et les noms ci-dessous en viennent plutôt que de la mémoire.
REST API et SOAP API
La REST API est le choix par défaut pour tout ce qui a la forme d’un enregistrement : créer, lire, mettre à jour, supprimer, interroger, décrire. C’est le bon choix pour un formulaire web qui écrit un Lead, pour un portail qui lit les Cases ouverts d’un client, et pour tout chemin interactif à faible volume.
La SOAP API fait le même travail via un WSDL et survit parce que beaucoup d’intergiciels d’entreprise la parlent nativement et parce qu’elle offre un contrat fortement typé dont on génère un client. L’erreur courante consiste à croire SOAP dépassée et REST moderne. Les deux sont actuelles, et les appels SOAP create() et update() acceptent jusqu’à 200 enregistrements chacun, ce qui compte davantage que le format de transport.
Bulk API 2.0
La Bulk API 2.0 est la voie asynchrone, par jobs, pour le volume. Vous téléversez un CSV, Salesforce le découpe et le traite en arrière-plan, et vous interrogez les résultats. Les limites de la Bulk API autorisent jusqu’à 15 000 lots par tranche glissante de 24 heures et jusqu’à 150 millions d’enregistrements ingérés dans la même fenêtre, avec un plafond de 150 Mo par fichier de job.
L’erreur courante consiste à traiter Bulk comme un réglage pour plus tard. C’est un modèle de programmation différent : les résultats reviennent de façon asynchrone, enregistrement par enregistrement, et votre code doit les consommer ainsi dès le départ.
Composite et sObject Collections
Ces deux mécanismes sont la partie la plus utile et la moins employée de la REST API. Une requête composite porte jusqu’à 25 sous-requêtes en un seul appel, dont 5 au plus peuvent être des requêtes ou des opérations sObject Collections, et les sous-requêtes suivantes peuvent référencer les identifiants renvoyés par les précédentes. sObject Collections traite jusqu’à 200 enregistrements du même objet en une requête. Les deux comptent pour un seul appel sur votre quota quotidien, et c’est tout l’intérêt.
L’erreur courante consiste à ignorer leur existence. Créer un Account, puis un Contact, puis une Opportunity en trois appels successifs coûte trois fois le quota d’une requête composite, et trois fois la latence.
Streaming, Change Data Capture et Pub/Sub
La Streaming API est le canal d’abonnement fondé sur CometD pour les événements PushTopic, génériques, Platform et Change. Change Data Capture publie des notifications quasi temps réel quand des enregistrements sont créés, modifiés, supprimés ou restaurés, si bien qu’un magasin externe peut suivre Salesforce sans interrogation périodique. Les Platform Events sont vos propres définitions d’événements.
La Pub/Sub API est l’interface plus récente en gRPC et HTTP/2 qui réunit publication, abonnement, récupération de schéma et découverte de sujets dans une seule API, avec des charges utiles en Avro plutôt qu’en JSON. Pour une construction événementielle neuve, commencez là.
L’erreur courante consiste à traiter les événements comme un flux garanti. Ils ne remplacent pas le rapprochement, pour la raison exposée dans la section suivante.
Les limites d’appels API sont la vraie contrainte
C’est la section qui décide de votre architecture, et c’est celle qu’on lit le plus souvent une fois la conception terminée.
Comment le quota quotidien est calculé
La documentation des limites d’appels API fixe le quota selon l’édition et le nombre de licences, pas selon l’utilisateur ni l’application. Les éditions Enterprise et Professional avec accès API reçoivent 100 000 appels plus 1 000 par licence Salesforce ou Salesforce Platform. Les éditions Unlimited et Performance reçoivent 100 000 plus 5 000 par licence. La Developer Edition reçoit un forfait de 15 000, et une sandbox Full 5 000 000.
Deux conséquences. Une org Enterprise de soixante utilisateurs dispose d’environ 160 000 appels par jour, pas d’une réserve infinie. Et comme le quota dérive des licences, les seuls moyens de l’augmenter sont d’ajouter des licences utilisateur ou d’acheter des appels API supplémentaires, les deux via l’application Your Account de Salesforce.
Ce qui compte, et ce qui arrive une fois le quota épuisé
Le quota se mesure sur l’agrégat de tous les appels reçus par l’org sur une période de 24 heures, et couvre ensemble la REST API, la SOAP API, la Bulk API, la Bulk API 2.0 et la plupart des appels Connect REST API. Les appels de certaines applications connectées de Salesforce, comme l’application mobile, en sont exclus.
C’est cette agrégation qui piège les équipes. Votre intégration n’a pas de budget propre. Elle le partage avec le connecteur de reporting, la plateforme marketing et toute autre intégration de l’org, et un seul consommateur mal écrit qui interroge toutes les trente secondes peut le vider et affamer du code qui se comporte parfaitement.
Quand l’org dépasse son quota, les requêtes échouent avec un 403 et REQUEST_LIMIT_EXCEEDED. Salesforce tolère un dépassement aux orgs de production payantes avant d’appliquer la limite strictement, mais les orgs d’essai et Developer Edition n’ont droit à aucune indulgence. Concevez comme s’il n’y en avait pas.
Mesurez avant d’arrêter une conception
Demandez à l’administrateur le quota de l’org et sa consommation quotidienne actuelle avant d’écrire du code ; la REST API expose une ressource de limites de l’org pour cela. Si les consommateurs existants en utilisent déjà 70 pour cent, une intégration synchrone enregistrement par enregistrement n’est pas viable, et aucun réglage ne la rendra viable.
Le traitement par lots est une décision de conception, pas une optimisation
Dès que vous acceptez que le quota est fini et partagé, la conception se déduit d’elle-même.
Ne bouclez jamais sur un appel unitaire. Un traitement qui crée 5 000 Contacts un par un dépense 5 000 appels. Les mêmes 5 000 via sObject Collections, à 200 par requête, en dépensent 25. Ce facteur 200 sépare une intégration qui tient dans le quota d’une org moyenne d’une intégration qui n’y tient pas.
Utilisez Composite quand le travail est un graphe plutôt qu’une liste. Créer un parent et ses enfants en une requête supprime à la fois les allers-retours et l’état intermédiaire que votre code devrait sinon garder en attendant un identifiant.
Utilisez la Bulk API 2.0 pour tout ce qui ressemble à un chargement ou à un export plutôt qu’à une transaction. Elle est mauvaise pour les chemins interactifs, étant asynchrone par nature et ne rendant aucune réponse synchrone à l’utilisateur.
Mettez en cache les données de référence. Les valeurs de listes de sélection, les identifiants de types d’enregistrement et les résultats de describe changent rarement et sont pourtant récupérés à chaque exécution sans raison. Ce seul changement retire souvent un quart du volume d’appels d’une intégration naïve.
Governor limits : votre écriture exécute le code d’un autre
Salesforce exécute l’Apex écrit par les clients dans des plafonds stricts par transaction. Les governor limits Apex qui comptent pour une intégration sont 100 requêtes SOQL par transaction synchrone, 50 000 enregistrements récupérés par SOQL, 150 instructions DML, 10 000 enregistrements traités par DML, 10 secondes de temps processeur synchrone et 6 Mo de tas.
Ce n’est pas vous qui écrivez cet Apex. Vous atteignez quand même ces plafonds, parce que votre écriture entrante ouvre une transaction qui exécute tous les déclencheurs présents sur l’objet.
La bulkification, sans écrire d’Apex
L’idée mérite d’être comprise même si vous n’ouvrez jamais un fichier Apex.
Salesforce remet au déclencheur une collection d’enregistrements, pas un seul. Un déclencheur écrit correctement traite toute la collection avec une requête et une mise à jour. Un déclencheur écrit comme s’il recevait toujours un enregistrement unique lance une requête et une mise à jour par enregistrement.
Ce second déclencheur fonctionne parfaitement pendant des années, parce que les utilisateurs enregistrent un élément à la fois dans l’interface. Puis votre intégration envoie 200 enregistrements en une requête, le déclencheur lance sa requête 200 fois, franchit le plafond de 100 requêtes, et le lot entier échoue.
La Bulk API 2.0 traite les données d’ingestion par blocs de 200 enregistrements, chacun dans une transaction distincte, donc le cas n’a rien de théorique. C’est la forme habituelle d’un premier chargement en masse dans une org qui a une histoire.
Que faire
Auditez les déclencheurs et les flux de chaque objet où vous allez écrire, avant d’accepter une date de livraison. Si un déclencheur n’est pas bulkifié, quelqu’un doit le corriger, et ce quelqu’un a besoin de compétences Apex et d’une fenêtre de déploiement. Budgétez cela comme une ligne à part.
Là où la correction sort du périmètre, réduisez la taille des lots. Deux cents par requête est un maximum, pas une obligation, et descendre à cinquante achète parfois assez d’air pour livrer pendant que le travail sur le déclencheur est planifié. Cela coûte du quota, traitez-le donc comme une mesure provisoire.
Une authentification qui fonctionnera encore l’an prochain
Ce domaine a nettement changé et beaucoup de guides publiés sont désormais faux.
Le flux OAuth 2.0 nom d’utilisateur et mot de passe est celui à éviter. Il expose les identifiants directement dans la requête, Salesforce le bloque par défaut dans les orgs récentes, et son retrait pour les connected apps est programmé. Toute intégration qui l’utilise encore a besoin d’un plan de migration daté.
Pour le travail de serveur à serveur sans humain dans la boucle, les deux réponses actuelles sont le flux JWT bearer, qui signe une assertion avec un certificat, et le flux client credentials, qui échange une clé et un secret de consommateur contre un jeton. Le guide de Salesforce sur l’appel des API REST avec l’utilisateur d’intégration et les client credentials précise que ce flux n’émet aucun jeton de rafraîchissement, le client demande donc un nouveau jeton d’accès à l’expiration de l’ancien.
Connected apps et external client apps
Le conteneur de tout cela était autrefois la connected app. C’est désormais l’external client app. Salesforce indique clairement que la création de connected apps est restreinte depuis Spring ‘26 et recommande les external client apps, présentées comme la nouvelle génération conçue pour améliorer la sécurité et résoudre les problèmes d’empaquetage.
Si votre documentation d’intégration dit “créez une connected app”, elle décrit un chemin que les orgs récentes n’offrent peut-être pas. Vérifiez ce qui s’applique à l’org cible avant de chiffrer le travail.
Tournez sous un utilisateur d’intégration dédié, et prévoyez la rotation
Donnez à l’intégration son propre utilisateur, avec un profil à accès minimal et limité à l’API. Ne la faites pas tourner sous le compte d’un salarié nommé. Quand ce salarié part et que son compte est désactivé, l’intégration s’arrête, au pire moment possible et avec une erreur qui ne mène nulle part.
Les certificats expirent et les secrets sont renouvelés. Les deux restent silencieux jusqu’au jour où ils ne le sont plus, et les deux coupent une intégration complètement plutôt que partiellement. Mettez les dates d’expiration dans un calendrier dont une personne est responsable, rangez les identifiants dans un gestionnaire de secrets, et testez la rotation en sandbox avant d’en avoir besoin dans l’urgence.
Les pièges du modèle de données
Ce sont ceux qui coûtent trois semaines, parce que revenir en arrière signifie déplacer des données plutôt que changer du code.
Lead, Contact, Account et Person Account
Un Lead est un prospect non qualifié, pas encore rattaché à un enregistrement d’entreprise. Un Contact est une personne rattachée à un Account. Un Account est une organisation. La conversion transforme un Lead en un Account et un Contact, éventuellement avec une Opportunity, et l’appel SOAP convertLead précise que seuls les champs vides de la cible sont écrasés, vos champs de Lead soigneusement remplis n’atterrissent donc pas forcément là où vous l’attendez.
Les Person Accounts compliquent cela. Les orgs orientées grand public les activent pour représenter un particulier comme un Account et un Contact combinés, et une intégration écrite pour un modèle d’Account d’entreprise ne fonctionnera pas sans modification contre une org qui les utilise. On le découvre tard avec une régularité décourageante.
Décidez avec le métier, par écrit, quel objet devient un enregistrement entrant donné. Ce n’est pas une décision technique.
External IDs et upsert
C’est le seul mécanisme d’idempotence sain que Salesforce vous donne, et il devrait être non négociable. Créez sur l’objet un champ personnalisé marqué comme External ID et stockez-y la clé primaire de votre propre système. Vous pouvez alors utiliser l’opération upsert, un PATCH sur /sobjects/{Object}/{ExternalIdField}/{Value}, qui crée l’enregistrement quand rien ne correspond et le met à jour quand exactement un correspond. Zéro correspondance renvoie 201, une correspondance renvoie 200, et plusieurs correspondances échouent avec un 300 au lieu de deviner.
La conséquence mérite d’être dite clairement. Avec l’upsert, réessayer une requête échouée est sûr. Sans lui, chaque nouvel essai est un doublon potentiel, et une coupure réseau pendant un traitement de nuit devient un nettoyage qui se mesure en jours.
Les règles qui se déclenchent sur vos écritures
Les règles de doublon peuvent bloquer ou signaler les enregistrements que votre intégration crée. Les règles de validation rejettent les enregistrements qui échouent à des conditions posées par un administrateur. Des champs obligatoires peuvent être ajoutés des mois après votre livraison, et une intégration qui marchait se met alors à échouer sur chaque enregistrement.
Rien de tout cela n’est un bogue ; l’org fonctionne comme elle est configurée. L’erreur est de traiter une écriture rejetée comme une panne de transport et de réessayer indéfiniment, alors que la bonne réponse est de la remonter à un humain avec le motif au niveau du champ. Notre guide des modes de panne des intégrations d’API tierces couvre la même catégorie ailleurs.
Gestion des erreurs, idempotence et rejeu
Une intégration sans mécanisme de rejeu devient une réparation manuelle de données. Ce n’est pas une prédiction, c’est ce qui arrive.
Le succès partiel est le cas normal. sObject Collections met allOrNone à false par défaut, une requête de 200 enregistrements peut donc renvoyer 187 succès et 13 échecs avec des motifs individuels, et la Bulk API 2.0 renvoie des résultats par enregistrement de la même façon. Un code qui ne vérifie que le statut HTTP extérieur annoncera un succès tout en perdant des enregistrements en silence.
Classez les échecs avant de réessayer. Les conditions passagères comme les verrous de ligne, les délais dépassés et l’épuisement du quota méritent un délai exponentiel. Les échecs déterministes comme les erreurs de validation et les champs obligatoires manquants échoueront toujours de la même manière, et les réessayer brûle un quota dont vous ne disposez pas.
Chaque enregistrement irrécupérable part vers un magasin de rebut avec sa charge utile et son erreur, pour qu’une personne l’examine et le resoumette. Comme vos écritures sont clefées sur un external ID, la resoumission est sûre. Journalisez la correspondance entre votre identifiant et l’identifiant Salesforce des deux côtés ; dans six mois, ce journal sera la seule chose capable d’expliquer pourquoi la fiche d’un client est fausse.
Et rapprochez. Les événements Platform et Change restent 72 heures dans le bus d’événements, et les allocations d’événements Platform plafonnent la livraison quotidienne à 25 000 événements en Enterprise et 50 000 en Unlimited et Performance. Une comparaison planifiée des volumes et des dates de modification rattrape ce que le flux a perdu.
Intergiciel ou liaison directe
Le point à point est correct plus souvent que les éditeurs de plateformes ne l’admettent. Une source, une cible, un sens, un volume modeste, un contrat stable : construisez directement et faites l’économie de la licence.
L’intergiciel mérite son coût quand la topologie cesse d’être une ligne. Plusieurs systèmes qui échangent des données, des transformations que les utilisateurs métier doivent modifier sans déploiement, une orchestration entre systèmes qui tombent indépendamment, un vrai besoin de supervision et de reprise centralisées.
La remarque honnête est que l’intergiciel déplace le coût plutôt qu’il ne le supprime. Vous payez toujours la correspondance des champs, la gestion des erreurs et la connaissance opérationnelle, et vous ajoutez une licence, un second pipeline et un second savoir-faire à recruter. Le quota d’API ne change pas, parce que l’intergiciel appelle les mêmes API que votre code aurait appelées.
Choisissez-le parce que votre topologie l’exige, pas parce qu’il semble réduire le code. Notre guide de la décision construire ou acheter déroule le même arbitrage pour les systèmes sous-jacents, et le guide de l’intégration CRM et ERP couvre le cas multi-systèmes. Si vous voulez que cela soit évalué plutôt que débattu, c’est là que commencent nos missions de développement logiciel.
Sandbox, déploiement et versions d’API
Construisez en sandbox. Jamais contre la production, et jamais contre une org Developer Edition qui ne partage pas la configuration de production, parce que c’est la configuration qui vous cassera.
Comprenez ce que fait un rafraîchissement. Il remplace la sandbox par une copie neuve de la production, donc toute donnée de test qui n’existait que là disparaît. Ce qui doit survivre à un rafraîchissement doit être scripté et rejouable. Les équipes l’apprennent en perdant une semaine de jeux d’essai.
Épinglez explicitement votre version d’API dans chaque chemin de requête et connaissez la politique de retrait. La politique de fin de vie des API de Salesforce s’engage à prendre en charge chaque version au moins trois ans et à prévenir les clients au moins un an avant la fin du support. Les versions 21.0 à 30.0 ont été retirées en Summer ‘25, et les requêtes vers une version retirée renvoient 410 Gone.
C’est un arrêt net, pas une dégradation, et c’est pourquoi l’épinglage de version appartient à votre plan de maintenance. La même discipline vaut pour toute API que vous publiez vous-même, comme le décrit notre article sur le versionnage d’API.
Protection des données au Royaume-Uni et données CRM
Un CRM est presque entièrement fait de données personnelles : noms, employeurs, numéros de téléphone, adresses électroniques, notes de conversation. Les déplacer entre systèmes constitue un traitement au sens du UK GDPR.
La première question est de savoir qui est responsable de traitement. Les orientations de l’ICO sur les responsables et sous-traitants définissent le responsable comme la partie qui détermine les finalités et les moyens du traitement, et le sous-traitant comme celui qui traite pour son compte. Quand une agence construit et exploite une intégration pour vous, cette agence est en général sous-traitante, et un contrat écrit satisfaisant aux exigences de l’article 28 est obligatoire et non facultatif.
La seconde est le transfert international. Les orgs Salesforce et tout intergiciel peuvent se trouver hors du Royaume-Uni, et les orientations de l’ICO sur les transferts internationaux exposent les mécanismes disponibles et les cas où une évaluation du risque de transfert s’impose. Établissez où les données atterrissent avant de signer.
Trois conséquences en découlent. Ne copiez pas les champs dont vous n’avez pas besoin, car la minimisation est à la fois une obligation légale et moins de travail de correspondance. Ne mettez pas de données personnelles de production en sandbox sans une décision réfléchie. Et assurez-vous que la suppression se propage, car un contact effacé dans Salesforce et laissé intact dans votre entrepôt est un problème de conformité bien réel, et cela vaut aussi quand des agents IA atteignent ces enregistrements.
Ce que coûte une intégration Salesforce
Salesforce publie ses propres tarifs d’éditions et de licences sur ses pages de prix, et nous n’en citons aucun chiffre ici, parce que le nombre qui gouverne la conception d’une intégration est le quota d’API que ces licences produisent, pas le prix catalogue.
Les montants ci-dessous sont les estimations de services professionnels de Mecanik au Royaume-Uni, pas des tarifs éditeur, et supposent une org déjà en place avec un administrateur capable de répondre aux questions.
Une intégration simple à sens unique, un formulaire web qui crée un Lead avec un external ID et une gestion d’erreurs raisonnable, revient typiquement à GBP 3 000 à GBP 7 000. Une synchronisation bidirectionnelle d’un ou deux objets, avec résolution de conflits et travail de rapprochement, se situe en général entre GBP 15 000 et GBP 40 000. Une intégration événementielle sur Pub/Sub avec rejeu, gestion des rebuts et supervision atterrit généralement entre GBP 30 000 et GBP 80 000.
Ce que doit contenir la livraison
Un document de correspondance au niveau du champ, validé avec le métier et non déduit. Un external ID sur chaque objet synchronisé. Une gestion des erreurs avec magasin de rebut et procédure de resoumission documentée. Un traitement de rapprochement. Une supervision de la consommation d’API par rapport au quota de l’org, avec alerte bien en dessous du plafond. Des procédures écrites pour la rotation des jetons, l’expiration des certificats et le rejeu. Une configuration de sandbox scriptée pour survivre à un rafraîchissement. Une intégration sans cela est un prototype, quoi que dise la facture.
Coût récurrent
Prévoyez GBP 400 à GBP 1 500 par mois pour la supervision, les trois versions Salesforce annuelles, la rotation des identifiants et les changements de champs qu’un administrateur fera sans vous prévenir. Les orgs qui financent cela sont celles où les intégrations continuent de fonctionner.
Passer à la réalisation
Les modes de panne sont ici d’une constance ennuyeuse : quota découvert trop tard, un déclencheur que personne n’a audité, un Lead qui aurait dû être un Contact, aucun moyen de rejouer un lot échoué. Les quatre coûtent peu à éviter en conception et cher à réparer une fois que des enregistrements réels existent.
Mecanik construit et maintient des intégrations Salesforce dans le cadre de son travail de développement logiciel, en commençant par un audit du quota, des déclencheurs et du modèle de données de l’org avant d’écrire la moindre ligne. Pour un lot de travail d’intégration défini plutôt qu’une mission complète, vous pouvez directement recruter un développeur web.
Questions fréquentes
Combien d’appels API une intégration Salesforce obtient-elle par jour ? Cela dépend de l’édition et du nombre de licences, et le quota vaut pour l’org entière plutôt que par intégration. Les éditions Enterprise et Professional avec accès API reçoivent 100 000 appels plus 1 000 par licence Salesforce ou Salesforce Platform, Unlimited et Performance reçoivent 100 000 plus 5 000 par licence, et la Developer Edition reçoit un forfait de 15 000 sur une période glissante de 24 heures.
Faut-il utiliser la REST API ou la Bulk API pour Salesforce ? Utilisez la REST API pour le travail interactif, à faible volume, en forme d’enregistrement, et la Bulk API 2.0 pour les chargements et les exports où le volume est élevé et où une réponse asynchrone convient. Pour tout ce qui est entre les deux, sObject Collections à 200 enregistrements par requête et Composite à 25 sous-requêtes par requête comptent chacun pour un seul appel sur votre quota et retirent l’essentiel de la pression.
Quel flux OAuth une intégration Salesforce de serveur à serveur doit-elle utiliser ? Le flux JWT bearer ou le flux client credentials, exécuté sous un utilisateur d’intégration dédié limité à l’API. Le flux nom d’utilisateur et mot de passe est bloqué par défaut dans les orgs récentes et programmé pour retrait, il ne devrait donc pas servir à un nouveau projet. Notez aussi que la création de connected apps est restreinte depuis Spring ‘26 et que Salesforce recommande désormais les external client apps.
Pourquoi mon intégration Salesforce échoue-t-elle seulement sur les gros lots ? Presque toujours à cause d’un déclencheur Apex non bulkifié. Salesforce remet aux déclencheurs une collection d’enregistrements, et un déclencheur écrit comme s’il en recevait un à la fois lancera ses requêtes une fois par enregistrement, dépassant la limite de 100 requêtes SOQL à l’arrivée de votre lot. Il marche très bien pour les utilisateurs de l’interface qui enregistrent un élément à la fois, et c’est pourquoi il est resté invisible.
Ai-je besoin d’un intergiciel pour m’intégrer à Salesforce ? Pas pour une intégration à source unique, cible unique et sens unique, à volume modeste, où construire directement est moins cher et plus simple. L’intergiciel mérite son coût dès que plusieurs systèmes échangent des données, que les utilisateurs métier doivent modifier des correspondances sans déploiement, ou qu’une orchestration et une reprise centralisées sont nécessaires. Il déplace le coût plutôt qu’il ne le supprime, et il n’augmente pas votre quota d’API.
Commentaires