Pourquoi les change sets freinent votre equipe Salesforce

En bref : si les change sets sont encore la, ce n'est pas parce que l'outillage DevOps coute trop cher. C'est parce que le processus de release a ete construit autour d'eux, et que ce processus est justement ce que personne n'a le budget de changer. Le cout apparait en reprises de travail, jamais en ligne de facture, et c'est exactement pour cela qu'il n'est jamais remis en cause.

Pourquoi les change sets survivent-ils dans la plupart des orgs ?

Pas parce que les equipes ignorent les alternatives. Parce que le change set est porteur dans le processus qui l'entoure. Quelqu'un tient le tableur des composants. Quelqu'un d'autre a le profil qui permet de televerser. La validation UAT est une capture d'ecran dans un ticket. Le soir de mise en production est une invitation d'agenda, et cette invitation tient lieu de plan.

Changez d'outil et toutes ces habitudes cassent en meme temps. C'est une demande bien plus lourde qu'une licence, et c'est la vraie raison pour laquelle une equipe qui juge les change sets penibles livrera encore avec eux le trimestre prochain.

Que coutent reellement les change sets ?

Pas les vingt minutes de clics. Le cout, c'est la reprise, et elle s'accumule en cinq endroits.

• Reconstruire la liste. Un change set est un inventaire manuel de ce que vous croyez avoir modifie. Ce que vous oubliez fait echouer le deploiement ou, pire, le fait reussir a moitie.
• Pas de rollback. Il n'y a pas de bouton d'inversion, donc la version disciplinee consiste a preparer un second change set miroir pour chaque release : deux fois le travail pour un demi-filet.
• Des metadonnees intransportables. Certains types de composants ne sont tout simplement pas pris en charge, et chacun devient une etape manuelle post-deploiement logee dans la tete de quelqu'un (limites documentees).
• Les profils. Deployer un profil ecrase la cible, donc les permissions qui n'existaient qu'en aval disparaissent en silence.
• Pas de travail parallele. Deux personnes modifiant le meme objet dans deux sandboxes le decouvrent au deploiement, parce que rien ne compare quoi que ce soit.

Rien de cela n'apparait dans un budget. Cela se voit dans les releases qui glissent, dans le meme administrateur qui reste tard chaque mois, et dans la regle tacite qui interdit de deployer un vendredi.

DevOps Center n'est-il pas la reponse ?

C'est une vraie reponse a une partie du probleme, et c'est gratuit. Salesforce a mis DevOps Center en disponibilite generale en decembre 2022 (notes de version), remplacant la selection manuelle de composants par un suivi des changements et un pipeline d'elements de travail au-dessus de Git.

Le plafond, c'est ce qu'il ne fait pas : pas de rollback automatique, pas de sauvegarde ni de restauration, et un support de gestion de sources limite a quelques fournisseurs Git heberges. En juillet 2026, Salesforce Ben a presente DX Inspector, decrit comme un outil de deploiement Salesforce deplacant metadonnees et donnees d'enregistrement, capable de s'integrer a DevOps Center (article). La trajectoire est claire : meme Salesforce n'investit plus dans les change sets.

Pourquoi l'argument budgetaire ne tient-il plus ?

C'etait une objection legitime. Une equipe de cinq administrateurs ne pouvait pas justifier une tarification au siege qui grandit avec l'effectif, et un pipeline maison exige quelqu'un qui maitrise Git, precisement ce qui manque a cette equipe.

L'ecart s'est referme des deux cotes. DevOps Center est gratuit. L'offre Essentials de Serpent l'est aussi, avec utilisateurs illimites, rollback en un clic, revue de code par IA et workflows de packaging complets, et Serpent n'installe rien dans votre org. Gearset, Copado, Flosum et AutoRABIT publient chacun leurs longues listes de limites des change sets, ce qui constitue un signal en soi : personne sur ce marche ne conteste la douleur.

La question n'est donc plus combien coute un outil. Elle est de savoir si votre equipe accepte de changer la facon dont une release est approuvee.

Qu'est-ce qui change vraiment quand on abandonne l'habitude ?

La mecanique compte moins que le deplacement de qui peut livrer. Quand les elements de travail portent leurs propres modifications, un administrateur deploie sans demander une fusion a un developpeur, et le release manager cesse d'etre un goulot d'etranglement muni d'un tableur.

La plupart des equipes Salesforce sont composees d'administrateurs et de consultants qui n'ont jamais ouvert un terminal. Un processus qui exige la maitrise de Git pour etre sur ne sera tout simplement pas adopte, et l'equipe continuera de cliquer.

C'est ce qui decide de l'adoption. Tout outil qui transforme vos administrateurs en utilisateurs de Git contraints a deplace le goulot plutot que de le supprimer.

Comment quitter les change sets sans arreter la livraison ?

1. Choisissez un seul pipeline, en general une org de production et ses sandboxes, et laissez le reste tranquille.
2. Mettez l'etat actuel de cette org sous controle de source avant de toucher au processus, pour disposer d'une reference de comparaison.
3. Menez la prochaine release des deux facons pendant un cycle. Le nouveau pipeline construit le paquet, l'ancien processus reste le recours.
4. Deplacez les approbations dans l'element de travail, pas dans un tableur. C'est l'habitude qui doit reellement casser.
5. Activez seulement ensuite l'automatisation : validation sur pull request, execution des tests, rollback, detection de derive.

Les equipes qui tentent les cinq etapes en une seule release reviennent generalement aux change sets en semaine trois et concluent que l'outillage a echoue. Il n'a pas echoue. C'est le changement de processus qui a echoue, parce qu'il a ete tente d'un coup. Notre approche est visible chez Serpent, ou la mise en place prend moins de 15 minutes et l'accompagnement de toute l'equipe est inclus.

FAQ

Les change sets sont-ils obsoletes ?

Non. Ils fonctionnent toujours et Salesforce n'a annonce aucun retrait. Mais l'investissement de la plateforme est passe a DevOps Center et aux outils plus recents, donc fonder son processus de release sur les change sets revient a parier sur l'immobilisme.

Peut-on annuler un change set ?

Pas nativement. Le contournement habituel consiste a preparer un change set miroir qui redeploie la version precedente, ce qui n'aide que pour les composants deja existants.

DevOps Center suffit-il seul ?

Pour une petite equipe et un pipeline simple, souvent oui. Les equipes le depassent en general sur le rollback, la sauvegarde, les portes de test et le support de leur fournisseur Git.

Les administrateurs doivent-ils apprendre Git pour quitter les change sets ?

Ils ne devraient pas avoir a le faire. Choisissez une approche ou le controle de source tourne sous l'element de travail plutot que devant lui, sinon l'adoption calera chez ceux qui font le plus de modifications.