Lecons Salesforce DevOps du Web Summit Lisbonne 2025

Le Web Summit Lisbonne 2025 n'etait pas un evenement Salesforce, mais Salesforce est revenu dans presque toutes les conversations serieuses que j'ai eues avec des fondateurs et des responsables RevOps qui font tourner leur activite sur la plateforme. Le schema etait constant : les equipes deploient encore les metadonnees a la main, redoutent encore la release du vendredi, et n'ont toujours pas de vrai plan de rollback. C'est exactement l'ecart que Serpent existe pour combler.

Je n'etais pas la pour recracher un argumentaire de stand. J'ai parle avec des gens entre les conferences, dans le salon des investisseurs, et au Night Summit, et le DevOps Salesforce revenait sans cesse comme un probleme que personne n'avait proprement resolu.

Pourquoi la gestion des releases Salesforce est-elle revenue lors d'une conference tech generaliste ?

Le Web Summit couvre large : startups, investisseurs, fintech, IA. Mais un nombre surprenant de personnes que j'ai rencontrees dirigeaient des entreprises en croissance sur Salesforce, soit comme CRM de reference, soit comme colonne vertebrale d'un produit ISV partenaire. Des que la conversation depassait "que construisez-vous", la douleur des releases revenait presque a chaque fois, souvent sans meme que je la souleve.

Le fil conducteur : les admins et developpeurs Salesforce avaient depasse les change sets depuis des annees, mais assemblaient encore sandboxes, tableurs et fils Slack pour coordonner une release. Personne parmi mes interlocuteurs ne decrivait son processus de deploiement comme quelque chose en qui il avait confiance.

Quelle douleur de deploiement les fondateurs et les equipes decrivaient-ils ?

Quelques plaintes precises revenaient chez des entreprises sans lien entre elles :

• Aucun moyen fiable de voir ce qui differe reellement entre un sandbox et la production avant de deployer.
• Des conflits de fusion dans les metadonnees qui n'apparaissent qu'apres l'echec d'un deploiement, jamais avant.
• Des mises a jour manuelles de profils et de permission sets oubliees entre les environnements.
• Des fenetres de release qui dependent de la disponibilite d'une seule personne, parce qu'elle est la seule a comprendre l'ordre de deploiement.
• Des rollbacks qui signifient restaurer une sauvegarde plutot qu'annuler un seul changement.

Rien de tout cela n'est exotique. C'est la meme courte liste de problemes que l'outillage DevOps Salesforce grignote depuis une decennie. Ce qui frappait, c'est combien d'equipes, certaines bien apres leur Series A, resolvaient encore cela a coups de discipline et de savoir tribal plutot qu'avec une plateforme.

En quoi cela valide-t-il la direction de Serpent ?

Serpent a ete construit autour de l'idee que la gestion des releases Salesforce devrait ressembler a une livraison logicielle moderne : metadonnees versionnees, un diff d'environnement fiable, et un pipeline de deploiement qui intercepte les conflits avant qu'ils n'atteignent la production, pas apres. Chaque conversation a Lisbonne a confirme que c'est toujours l'ecart, pas un probleme resolu.

Ce qui a legerement change ma perspective, c'est combien de ces equipes n'etaient pas des boutiques Salesforce pures. Elles comparaient la discipline de release Salesforce au CI/CD qu'elles font deja tourner pour leur stack web, et trouvaient Salesforce largement en retard. C'est un cadrage utile quand on montre a quelqu'un ce que fait reellement Serpent, parce qu'on n'explique pas le DevOps depuis zero, on explique pourquoi Salesforce est en retard.

Quelques personnes ont directement demande en quoi Serpent differait des outils qu'elles connaissaient deja, Gearset en particulier. A lire, notre comparaison Serpent contre Gearset si c'est la que commence votre evaluation.

Que retenir si vous evaluez un outil DevOps Salesforce ?

Si l'un des points de douleur ci-dessus vous parle, la solution est rarement plus de processus. C'est de l'outillage qui supprime les etapes manuelles : diff automatise, un pipeline qui bloque les mauvaises fusions, et un chemin de rollback qui ne demande pas une restauration complete de sauvegarde. Les propres recommandations de gestion du cycle de vie applicatif de Salesforce disent la meme chose : l'ALM ne fonctionne que si l'outillage l'impose systematiquement.

Pour voir a quoi cela ressemble en pratique, notre page tarifs detaille ce qu'il faut pour sortir une equipe des deploiements manuels, et il y a plus de details sur la mise en place dans nos guides DevOps Salesforce.

FAQ

Pourquoi le DevOps Salesforce compte-t-il en dehors des evenements specifiquement Salesforce ?

Parce que la plupart des entreprises en croissance font tourner Salesforce aux cotes d'une stack logicielle moderne, et les fondateurs attendent de plus en plus la meme discipline de livraison des deux cotes.

Quelle est l'erreur de deploiement Salesforce la plus courante decrite par les fondateurs ?

Se reposer sur le savoir tribal d'une seule personne concernant l'ordre de deploiement plutot que sur un pipeline reproductible et versionne.

La gestion des releases Salesforce differe-t-elle du CI/CD general ?

Les principes sont les memes, mais les dependances de metadonnees Salesforce et la configuration propre a chaque org rendent les outils CI/CD generiques peu adaptes sans outillage conscient de Salesforce.

En quoi Serpent differe-t-il des change sets manuels ?

Serpent remplace l'assemblage manuel des change sets par un diff automatise, une detection de conflits, et un pipeline construit specifiquement pour les metadonnees Salesforce.