GitHub Actions maison pour Salesforce : que se passe-t-il quand son auteur part ?

Réponse courte : pendant une quinzaine de jours, rien. Puis une release Salesforce change une version d'API, un certificat expire, une image de runner abandonne une dépendance, et le déploiement échoue sur une erreur dont personne n'a laissé la trace. Un pipeline Salesforce fait maison est rarement une infrastructure. C'est un projet personnel avec un bus factor de un, et la facture arrive vers dix-huit mois.

Pourquoi un pipeline maison paraît-il gratuit au départ ?

Parce que la construction est réellement bon marché. Les tutoriels publics sont bons : authentification JWT vers une connected app, secrets dans le dépôt, un fichier de workflow par branche, sfdx-git-delta pour ne déployer que le delta, une exécution de tests avec seuil de couverture (Salesforce Ben propose un parcours solide). Un bon ingénieur met cela en route en deux semaines, et la première année, cela fonctionne.

Ce que les tutoriels ne traitent pas, c'est qui en est propriétaire ensuite. Lisez les commentaires sous n'importe lequel d'entre eux et vous trouverez la vraie histoire : commandes obsolètes, authentification expirée, une version de Java disparue. Ces commentaires sont la facture de maintenance en miniature.

Pourquoi le pipeline casse-t-il vers dix-huit mois ?

Parce que tout ce qui est en dessous bouge, et pas le YAML.

• Trois releases Salesforce par an. Les versions d'API avancent, les formes de métadonnées changent, et les versions figées dans le workflow prennent du retard sans bruit.
• La CLI bouge. Des commandes sont renommées puis retirées. Les scripts écrits sur les anciens noms marchent jusqu'au jour où ils ne marchent plus.
• Certificats et secrets expirent. Le certificat auto-signé derrière la connected app JWT a une date d'expiration que personne n'a mise dans un agenda.
• Les images de runner changent. Les runners hébergés mettent à jour système, Node et Java selon leur calendrier, pas le vôtre.
• Les actions tierces dérivent. L'outil de delta, le scanner et les actions communautaires épinglées à un tag ont chacun leur cycle de release et leurs ruptures.
• L'org grandit. Le pipeline visait deux sandboxes et quatre contributeurs. Il sert désormais cinq environnements, un package, et des gens qui n'ont jamais ouvert un terminal.

Aucun de ces points n'est difficile isolément. Ils sont difficiles parce qu'ils tombent un mardi après-midi, en fenêtre de release, dans un dépôt dont l'auteur est parti en mars.

Combien coûte réellement la maintenance ?

La réponse honnête : c'est un mi-temps permanent et non budgété. La littérature des éditeurs s'accorde sur la forme même si les chiffres viennent d'endroits différents : Gearset, citant la Harvard Business Review, situe à 70% les dépassements sur les projets logiciels développés en interne (build or buy), et Copado indique que les éditeurs DevOps établis consacrent 10 à 15% de leur capacité de développement au seul suivi des évolutions de la plateforme Salesforce (the hidden costs of building your own). Lus ensemble, le constat est inconfortable mais simple : un éditeur spécialisé traite la compatibilité plateforme comme un programme d'ingénierie à temps plein. Votre pipeline, lui, hérite de ce qui reste du vendredi d'une personne.

Les coûts qui n'entrent jamais dans un business case :

• La release bloquée pendant que quelqu'un décortique un fichier de workflow qu'il n'a pas écrit.
• L'admin qui a cessé de demander des déploiements parce que le pipeline l'intimide, et qui est revenu aux change sets.
• Le deuxième pipeline, construit à côté du premier, parce que personne n'osait toucher à l'original.
• Le coût d'intégration de chaque nouvel ingénieur qui doit apprendre un système sur mesure inexistant ailleurs.

Comment tester votre propre bus factor ?

Cinq questions. Répondez-y honnêtement cette semaine, pas pendant une démission.

1. Si le pipeline échouait maintenant, combien de personnes sauraient lire le log et nommer la cause ?
2. Où est le runbook, et quand était-il exact pour la dernière fois ?
3. Qui fait tourner les identifiants, et quelle est la date d'expiration du certificat actuel ?
4. Une personne non développeuse peut-elle lancer un déploiement et comprendre le résultat ?
5. S'il fallait confier cela à un prestataire demain, combien de temps avant qu'il soit productif ?

Si quatre de ces réponses sont le nom d'une seule personne, vous n'avez pas un pipeline. Vous avez une dépendance.

Quand construire soi-même reste-t-il le bon choix ?

Quand le pipeline est traité comme un produit et non comme un service rendu. Cela suppose un propriétaire nommé qui n'est pas le seul, une deuxième personne qui l'a réellement réparé, une documentation testée par quelqu'un qui la suit, des dépendances figées et revues, et une ligne dans un budget. Beaucoup d'équipes atteignent ce niveau, surtout avec une vraie fonction de platform engineering et des exigences qu'aucun éditeur ne couvre. Avec une capacité DevOps interne solide et la volonté de la financer, le maison se défend.

Ce qui ne marche pas, c'est l'entre-deux : un système sur mesure sans propriétaire, dans une équipe dont le vrai travail est de livrer des fonctionnalités Salesforce.

Que faire la semaine où la personne démissionne ?

1. Asseyez-vous avec elle et cassez le pipeline volontairement dans une sandbox. Observez son diagnostic et enregistrez-le.
2. Inventoriez chaque secret, certificat et compte de service, avec sa date d'expiration.
3. Faites exécuter un déploiement complet par une deuxième personne, sans aide, pendant que l'auteur regarde sans toucher au clavier.
4. Notez les trois pannes les plus fréquentes et le correctif de chacune.
5. Décidez délibérément de garder ou de remplacer. C'est de glisser vers la décision qui coûte cher.

C'est exactement là qu'une plateforme supportée gagne sa place. Serpent existe pour qu'un pipeline Salesforce ne soit pas le projet parallèle d'une personne : les déploiements passent par des tickets avec Git en dessous, si bien que les admins et consultants demandent et suivent leurs releases sans CLI, et la compatibilité plateforme devient notre problème plutôt que celui de votre partant. Serpent n'installe rien dans votre org et se connecte via des API standard, la tarification est forfaitaire par entreprise avec des utilisateurs illimités, et un plan Essentials gratuit permet de l'essayer sur votre propre org. La mise en route prend moins de 15 minutes et notre équipe anime la session d'onboarding avec vous.

FAQ

GitHub Actions est-il un mauvais choix pour le CI/CD Salesforce ?

Non. C'est un système d'intégration continue solide et beaucoup d'équipes tournent très bien dessus. Le risque n'est pas l'outil, c'est un pipeline sur mesure avec un seul propriétaire et aucun budget de maintenance.

Combien de temps dure un pipeline Salesforce fait maison ?

Il fonctionne en général bien la première année, puis commence à coûter du temps réel à mesure que s'accumulent releases Salesforce, changements de CLI, identifiants expirés et mises à jour de runners.

Qu'est-ce qui casse en premier quand l'auteur part ?

L'authentification, le plus souvent. Certificats expirés et secrets renouvelés échouent bruyamment, et précisément dans la partie configurée une seule fois et jamais documentée.

Comment réduire le bus factor sans remplacer le pipeline ?

Nommez un propriétaire et un suppléant, mettez un runbook testé dans le dépôt, calendarisez chaque expiration d'identifiant, et faites exécuter un vrai déploiement en autonomie par une deuxième personne au moins une fois par mois.

Acheter est-il toujours moins cher que construire ?

Pas toujours. Construire se défend avec une vraie capacité de platform engineering et un propriétaire financé. Cela devient coûteux quand le pipeline est un service rendu par quelqu'un dont le métier est de livrer des fonctionnalités.