Leçons Salesforce DevOps du Web Summit Lisbonne 2025

Le Web Summit Lisbonne 2025 n'était pas un événement Salesforce, mais Salesforce est revenu dans presque toutes les conversations sérieuses que j'ai eues avec des fondateurs et des responsables RevOps qui font tourner leur activité sur la plateforme. Le schéma était constant : les équipes déploient encore les métadonnées à la main, redoutent encore la release du vendredi, et n'ont toujours pas de vrai plan de rollback. C'est exactement l'écart que Serpent existe pour combler.

Je n'étais pas la pour recracher un argumentaire de stand. J'ai parlé avec des gens entre les conférences, dans le salon des investisseurs, et au Night Summit, et le DevOps Salesforce revenait sans cesse comme un problème que personne n'avait proprement résolu.

Pourquoi la gestion des releases Salesforce est-elle revenue lors d'une conférence tech généraliste ?

Le Web Summit couvre large : startups, investisseurs, fintech, IA. Mais un nombre surprenant de personnes que j'ai rencontrées dirigeaient des entreprises en croissance sur Salesforce, soit comme CRM de référence, soit comme colonne vertébrale d'un produit ISV partenaire. Dès que la conversation dépassait "que construisez-vous", la douleur des releases revenait presque à chaque fois, souvent sans même que je la soulève.

Le fil conducteur : les admins et développeurs Salesforce avaient dépassé les change sets depuis des années, mais assemblaient encore sandboxes, tableurs et fils Slack pour coordonner une release. Personne parmi mes interlocuteurs ne décrivait son processus de déploiement comme quelque chose en qui il avait confiance.

Quelle douleur de déploiement les fondateurs et les équipes décrivaient-ils ?

Quelques plaintes précises revenaient chez des entreprises sans lien entre elles :

• Aucun moyen fiable de voir ce qui diffère réellement entre un sandbox et la production avant de déployer.
• Des conflits de fusion dans les métadonnées qui n'apparaissent qu'après l'échec d'un déploiement, jamais avant.
• Des mises à jour manuelles de profils et de permission sets oubliées entre les environnements.
• Des fenêtres de release qui dépendent de la disponibilité d'une seule personne, parce qu'elle est la seule à comprendre l'ordre de déploiement.
• Des rollbacks qui signifient restaurer une sauvegarde plutôt qu'annuler un seul changement.

Rien de tout cela n'est exotique. C'est la même courte liste de problèmes que l'outillage DevOps Salesforce grignote depuis une décennie. Ce qui frappait, c'est combien d'équipes, certaines bien après leur Séries A, résolvaient encore cela à coups de discipline et de savoir tribal plutôt qu'avec une plateforme.

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

Serpent a été construit autour de l'idée que la gestion des releases Salesforce devrait ressembler à une livraison logicielle moderne : métadonnées versionnées, un diff d'environnement fiable, et un pipeline de déploiement qui intercepte les conflits avant qu'ils n'atteignent la production, pas après. Chaque conversation à Lisbonne a confirmé que c'est toujours l'écart, pas un problème résolu.

Ce qui a légèrement changé ma perspective, c'est combien de ces équipes n'étaient pas des boutiques Salesforce pures. Elles comparaient la discipline de release Salesforce au CI/CD qu'elles font déjà tourner pour leur stack web, et trouvaient Salesforce largement en retard. C'est un cadrage utile quand on montre à quelqu'un ce que fait réellement Serpent, parce qu'on n'explique pas le DevOps depuis zéro, on explique pourquoi Salesforce est en retard.

Quelques personnes ont directement demandé en quoi Serpent différait des outils qu'elles connaissaient déjà, Gearset en particulier. À lire, notre comparaison Serpent contre Gearset si c'est là que commence votre évaluation.

Que retenir si vous évaluez 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 étapes manuelles : diff automatisé, un pipeline qui bloque les mauvaises fusions, et un chemin de rollback qui ne demande pas une restauration complète de sauvegarde. Les propres recommandations de gestion du cycle de vie applicatif de Salesforce disent la même chose : l'ALM ne fonctionne que si l'outillage l'impose systématiquement.

Pour voir à quoi cela ressemble en pratique, notre page tarifs détaille ce qu'il faut pour sortir une équipe des déploiements manuels, et il y a plus de détails sur la mise en place dans nos guides DevOps Salesforce.

FAQ

Pourquoi le DevOps Salesforce compte-t-il en dehors des événements spécifiquement Salesforce ?

Parce que la plupart des entreprises en croissance font tourner Salesforce aux côtés d'une stack logicielle moderne, et les fondateurs attendent de plus en plus la même discipline de livraison des deux côtés.

Quelle est l'erreur de déploiement Salesforce la plus courante décrite par les fondateurs ?

Se reposer sur le savoir tribal d'une seule personne concernant l'ordre de déploiement plutôt que sur un pipeline reproductible et versionné.

La gestion des releases Salesforce diffère-t-elle du CI/CD général ?

Les principes sont les mêmes, mais les dépendances de métadonnées Salesforce et la configuration propre à chaque org rendent les outils CI/CD génériques peu adaptés sans outillage conscient de Salesforce.

En quoi Serpent diffère-t-il des change sets manuels ?

Serpent remplace l'assemblage manuel des change sets par un diff automatisé, une détection de conflits, et un pipeline construit spécifiquement pour les métadonnées Salesforce.