Stratégie d'environnements
Cartographie des sandbox, scratch orgs et recette alignée sur le rythme réel.
CI/CD et DevOps Salesforce
Une mise en production cesse d'être un événement stressant lorsqu'elle a un processus.
Nous construisons une chaîne de livraison maîtrisée pour Salesforce : une source de vérité unique dans Git, des environnements définis, des tests automatisés, des portes qualité et un chemin de retour arrière — pour que chaque changement atteigne la production de façon prévisible et tracée.
Chaîne de livraison
Le trajet d'un changement, du développement à la production
Le schéma présente la chaîne complète, de l'environnement où le changement est écrit jusqu'aux contrôles qui suivent la mise en ligne.
Governed Release Pipeline
Source
Où naît le changement
- Scratch org / sandboxDéveloppement isolé
- Métadonnées dans GitSource de vérité unique
- Branche par tâcheTraçable au besoin
Intégration
Ce qui s'exécute seul
- Pull requestRevue obligatoire
- Analyse statiquePMD et standards
- Tests ApexCouverture et qualité
Portes qualité
Ce qui bloque la promotion
- Couverture minimaleSeuil convenu
- Suite de régressionScénarios critiques
- Validation métierRecette documentée
Livraison
Comment on atteint la production
- Déploiement automatiséMême artefact
- Données d'environnementEnvironnements cohérents
- Fenêtre de livraisonPlanifiée et annoncée
Contrôle
Ce qui suit la mise en ligne
- Rollback planifiéChemin de retour connu
- Supervision et alertesSeuils définis
- Notes de versionDocumentées à chaque livraison
Contexte
Ce qui détermine réellement le résultat
Dans la plupart des organisations, les incidents de livraison ne viennent pas d'un mauvais code mais de l'absence de processus. Les changements sont faits directement dans un environnement, personne ne sait exactement ce qui a été déployé et il n'existe aucun retour arrière ordonné.
Le CI/CD Salesforce n'est pas qu'un outillage. C'est un accord sur ce qui constitue un changement approuvé, sur qui l'approuve, sur les vérifications obligatoires et sur ce qui se passe en cas d'échec.
Le bon résultat n'est pas plus d'automatisation pour elle-même, mais une cadence plus élevée avec moins de surprises — et chaque version explicable, reproductible et réversible.
Domaines d'intervention
Ce que nous faisons concrètement
Métadonnées dans Git
Structure du dépôt, branches et politique de fusion tenable pour l'équipe.
Chaîne automatisée
Build, tests et déploiement via GitHub Actions, Azure DevOps ou Gearset.
Portes qualité
Couverture, analyse statique et validation métier comme conditions de promotion.
Données d'environnement
Jeux de test cohérents sans copier de données sensibles de production.
Livraison et rollback
Fenêtres de livraison, notes de version et retour arrière défini à l'avance.
Modèle de maturité
Où se situe l'organisation aujourd'hui
La plupart des organisations se situent entre le niveau 1 et le niveau 3. Le saut le plus déterminant est l'adoption de Git comme source de vérité.
| Niveau | À quoi cela ressemble | Risque principal | Étape suivante |
|---|---|---|---|
| 1 — Manuel | Change sets et modifications directes en production | Aucune trace, aucun retour possible | Placer les métadonnées dans Git |
| 2 — Partiellement maîtrisé | Git existe mais le déploiement est manuel | Écarts entre environnements | Automatiser le déploiement |
| 3 — Automatisé | Une chaîne s'exécute à chaque pull request | Des tests faibles qui valident tout | Définir de vraies portes qualité |
| 4 — Maîtrisé | Les portes qualité bloquent la promotion | Livraisons ralenties par un processus lourd | Cibler la suite de régression |
| 5 — Continu | Livraisons fréquentes avec rollback connu | Relâchement opérationnel | Supervision et revues périodiques |
1 — Manuel
- À quoi cela ressemble
- Change sets et modifications directes en production
- Risque principal
- Aucune trace, aucun retour possible
- Étape suivante
- Placer les métadonnées dans Git
2 — Partiellement maîtrisé
- À quoi cela ressemble
- Git existe mais le déploiement est manuel
- Risque principal
- Écarts entre environnements
- Étape suivante
- Automatiser le déploiement
3 — Automatisé
- À quoi cela ressemble
- Une chaîne s'exécute à chaque pull request
- Risque principal
- Des tests faibles qui valident tout
- Étape suivante
- Définir de vraies portes qualité
4 — Maîtrisé
- À quoi cela ressemble
- Les portes qualité bloquent la promotion
- Risque principal
- Livraisons ralenties par un processus lourd
- Étape suivante
- Cibler la suite de régression
5 — Continu
- À quoi cela ressemble
- Livraisons fréquentes avec rollback connu
- Risque principal
- Relâchement opérationnel
- Étape suivante
- Supervision et revues périodiques
Notre méthode
Étapes de mise en œuvre
- 01
État des lieux
Environnements, outils, cadence et points de défaillance réels.
- 02
Conception de la chaîne
Branches, environnements et portes qualité adaptés à l'équipe.
- 03
Mise en place technique
Dépôt, automatisation et premières vérifications en environnement de test.
- 04
Exécution en parallèle
La nouvelle chaîne cohabite avec le processus actuel jusqu'à stabilisation.
- 05
Transition de l'équipe
Procédures, habilitations et formation par rôle.
- 06
Contrôle continu
Mesure de la cadence, des échecs et du temps de rétablissement.
Continuer à partir d'ici
Services et guides associés
Questions fréquentes
Questions courantes
Faut-il une grande équipe de développement pour justifier le CI/CD ?
Non. Une équipe de deux ou trois personnes en tire déjà bénéfice, car la valeur première est la prévisibilité et la traçabilité, pas le volume. Une petite équipe reçoit simplement une chaîne plus simple.
Nous travaillons surtout avec Flow et le paramétrage. Est-ce pertinent ?
Tout à fait. Les changements de paramétrage et d'automatisation sont des métadonnées comme les autres et figurent parmi les causes les plus fréquentes d'incidents. Les gérer dans Git apporte une visibilité complète.
Quels outils utilisez-vous ?
Le choix dépend de l'organisation. GitHub Actions ou Azure DevOps conviennent aux équipes techniques, tandis que Gearset ou Copado s'imposent lorsque le paramétrage domine.
Combien de temps faut-il pour la mise en place ?
Une chaîne de base est opérationnelle en quelques semaines. L'extension aux portes qualité complètes et à la régression se fait progressivement, sans bloquer le développement courant.
Prochaine étape
Construire le processus de livraison
Nous analysons le fonctionnement actuel de vos environnements et livraisons, puis définissons la chaîne adaptée à votre rythme.
Prochaine étape
Construire le processus de livraison
Nous analysons le fonctionnement actuel de vos environnements et livraisons, puis définissons la chaîne adaptée à votre rythme.