Révisé le 2026-07-12 · Public : agences
Un snapshot poussé un vendredi à 16 h sur douze comptes clients, sans test préalable, c'est la façon la plus rapide de passer votre fin de semaine à éteindre des incendies. Un workflow renommé casse les déclencheurs, un champ supprimé vide des filtres, et personne ne sait quel compte a reçu quelle version.
Ce guide pose une gouvernance simple pour vos instantanés (Snapshots) : nommage, version, compte lab, checklist avant push, et communication client.
Ce que vous allez mettre en place
- Une convention de nommage avec version et date.
- Un compte lab pour tester chaque snapshot avant production.
- Une checklist pre-push et un déploiement pilote.
- Un registre de version active par client.
Avant de commencer
- Accès agence avec permission de créer et pousser des Snapshots.
- Un sous-compte lab dédié aux tests, jamais un compte client actif.
- Une convention de nommage écrite (ex.
renovation-v2.3-2026-07).
Étape 1 : Définir la convention de nommage
Écrivez la règle : niche + version + date. Exemple : dentiste-v1.4-2026-07. Un snapshot nommé « final-v2-FINAL » ne protège personne six mois plus tard.
Étape 2 : Tenir un changelog court
À chaque nouvelle version, notez trois lignes : ce qui a changé, pourquoi, et quels workflows ou champs sont touchés. Le changelog vit à côté du snapshot dans votre dossier ops.
Étape 3 : Configurer le compte lab
Le lab reçoit chaque snapshot avant la production. C'est un sous-compte vide ou reset régulièrement, séparé des comptes clients. Vous y testez pipeline, workflows publiés, champs personnalisés et intégrations.
Étape 4 : Lister les workflows critiques à vérifier
Notez les workflows qui ne doivent jamais casser : nouveau lead, confirmation rendez-vous, relance pipeline. Après chaque import lab, déclenchez un scénario test pour chacun.
Étape 5 : Tester le snapshot sur le lab
Importez le snapshot sur le lab. Vérifiez que les workflows sont « Published » (publiés), que les tags référencés existent, et que les intégrations custom du client ne sont pas écrasées par erreur dans votre template.
Étape 6 : Pousser sur un compte pilote
Choisissez un client pilote tolérant ou un compte interne. Poussez la nouvelle version. Attendez 24 h. Observez les workflows et les retours avant le déploiement massif.
Étape 7 : Communiquer avant un push majeur
Prévenez le client : fenêtre de mise à jour, impact attendu, contact d'urgence. Exemple : « demain entre 9 h et 11 h, mise à jour des automatisations, réponse sous 2 h si anomalie ».
Étape 8 : Documenter la version active par client
Dans le dossier de chaque client, notez quelle version tourne aujourd'hui et quand elle a été poussée. Voir Auditer un sous-compte existant pour croiser avec l'état réel du compte.
Pièges fréquents
- Push direct sur tous les comptes sans test lab.
- Pas de version dans le nom : impossible de savoir ce qui tourne où.
- Snapshot qui écrase des intégrations custom du client.
- Push vendredi soir sans personne de garde.
- Suppression d'anciennes versions encore référencées dans la doc client.
Vous avez réussi si…
- Chaque snapshot a un nom versionné et un changelog.
- Le lab a validé la dernière version avant tout push production.
- Chaque client a sa version documentée dans le dossier ops.
- Un push majeur a suivi le schéma pilote, 24 h, puis déploiement.