Trois mises à jour Apex de Spring ’26 qui valent une refactorisation

Par Nicolae Dragu, architecte système Salesforce chez Ateko

Salesforce livre des centaines de fonctionnalités à chaque version, et la plupart des développeurs n’ont pas le temps de lire chaque ligne des notes de version. C’est correct pour les mises à jour de Marketing Cloud ou de Sales Cloud, qu’on peut découvrir lorsqu’elles deviennent pertinentes. Ça l’est moins pour les changements Apex qui corrigent des problèmes que vous contournez depuis des années.

Spring ’26 en apporte trois de ce genre. Aucune n’est une fonctionnalité vedette, et aucune n’a fait la manchette lors du keynote. Mais chacune élimine une source de friction qui contribuait à la dette technique dans les organisations Salesforce de longue date. C’est le genre de friction difficile à voir dans un seul sprint, mais évident quand on regarde cinq ans de revues de code accumulées.

Comment obtenir les valeurs de liste de sélection pour un type d’enregistrement précis dans Apex?

Spring ’26 ajoute ConnectApi.RecordUi.getPicklistValuesByRecordType(objectApiName, recordTypeId), la première façon native d’obtenir des valeurs de liste de sélection limitées à un type d’enregistrement précis.

Avant cette mise à jour, Schema.DescribeFieldResult.getPicklistValues() retournait toutes les valeurs du champ, peu importe le type d’enregistrement. Filtrer pour obtenir le bon type d’enregistrement voulait dire soit coder des listes en dur dans Apex, soit faire un appel à l’UI API, deux approches qui ajoutent de la maintenance et qui brisent dès que quelqu’un ajoute un nouveau type d’enregistrement. Les listes de sélection dépendantes étaient encore pires : il n’existait aucune façon propre d’obtenir, à partir d’Apex, les dépendances limitées à un type d’enregistrement précis.

La nouvelle méthode change ça. Elle retourne les valeurs de liste de sélection pour tous les champs relevant du type d’enregistrement spécifié, y compris les dépendances, en un seul appel.

Ce que je recommande : refactoriser tout code qui encode des valeurs de liste de sélection en dur, qui construit des appels à l’UI API pour contourner cette limite, ou qui inspecte les types d’enregistrement pour filtrer les valeurs manuellement. C’est un nettoyage à faible risque. Le gain est plus important dans les organisations où des types d’enregistrement ont été ajoutés ou restructurés depuis la livraison du code original. Il y a toutefois quelques points à surveiller : chaque appel à getPicklistValuesByRecordType comptera dans les limites quotidiennes de requêtes API de la plateforme Salesforce, et la version API de la classe Apex devra être réglée à 66.0 ou plus récente.

Pourquoi Blob.toPdf() correspond-il maintenant à la sortie PDF de Visualforce?

Depuis Spring ’26, Blob.toPdf() utilise le même service de rendu que les PDF Visualforce, ce qui signifie que les deux méthodes produisent enfin des polices et des espacements cohérents.

Apex vous donne deux façons de générer un PDF : rendre une page Visualforce avec PageReference.getContentAsPDF(), ou appeler Blob.toPdf() directement sur une chaîne de texte. Jusqu’à Spring ’26, ces deux méthodes utilisaient des moteurs de rendu différents. Les polices, les espacements et la mise en page pouvaient varier subtilement selon la méthode choisie par le développeur.

C’était important lorsqu’une intégration de longue date avait alterné entre les deux méthodes au fil du temps, ou lorsqu’un développeur avait créé une fonctionnalité avec une approche et qu’un autre avait créé une fonctionnalité connexe avec l’autre. Les incohérences visuelles dans les PDF destinés aux clients sont le genre de problème signalé comme un bogue six mois après le lancement, et qui prend plus de temps à diagnostiquer qu’à corriger.

Ce que je recommande : si vous évitiez Blob.toPdf() parce que le résultat ne correspondait pas à vos PDF Visualforce existants, cette contrainte n’existe plus. Le nouveau code peut utiliser la méthode qui convient le mieux au cas d’utilisation. Blob.toPdf() est généralement plus simple pour une génération ponctuelle à partir d’une chaîne de texte, tandis que Visualforce reste le bon choix lorsque vous avez besoin d’une mise en page basée sur un gabarit.

Pourquoi ApexGuru dans VS Code change le flux de travail?

Spring ’26 intègre ApexGuru, l’outil de Salesforce alimenté par l’IA pour détecter les antipatrons, dans Salesforce Code Analyzer pour VS Code et Code Builder. Il s’exécute maintenant pendant que vous écrivez.

ApexGuru existe depuis le début de 2024, mais il vivait dans Setup. Il était donc utile pour les revues de code après coup, mais moins utile pendant que vous écriviez le code qui produit ces antipatrons. Son intégration à Code Analyzer change la boucle : vous analysez pendant que vous écrivez, pas après le déploiement.

Il détecte les mêmes patrons que ceux que j’ai couverts dans mon article précédent sur les problèmes Apex courants : DML ou SOQL dans des boucles, SOQL redondant, méthodes coûteuses, méthodes inutilisées, SOQL avec expressions négatives. La liste complète des éléments pris en charge se trouve dans la documentation de Salesforce.

Ce que je recommande : ajoutez-le à votre configuration VS Code. Repérer ces patrons au moment de l’écriture ne coûte rien. Les découvrir en production après l’expiration d’une tâche Apex lente coûte beaucoup plus cher, autant en temps qu’en confiance client.

Aucune de ces nouveautés ne se retrouvera probablement dans les faits saillants des notes de version. Chacune corrige quelque chose de petit. Mais les organisations avec lesquelles je travaille ne sont pas devenues fragiles à cause d’une seule grosse erreur. Elles se sont enchevêtrées à force de petites erreurs accumulées pendant des années, jusqu’à ce que le code devienne difficile à modifier sans tout casser. Spring ’26 retire trois de ces petites erreurs des dix prochaines années de développement Apex dans toute organisation que vous maintenez.

C’est le genre de changement qui vaut une refactorisation. Chez Ateko, nous travaillons avec des organisations où ce type de dette s’accumule depuis des années, et où un bon cycle de refactorisation peut faire la différence entre un système maintenable et un système fragile. Si vous voulez de l’aide pour vous attaquer aux pires morceaux, contactez-nous.