Analyse des risques avant rafraîchissement
Utilisez cette compétence lorsqu'un rafraîchissement de sandbox approche et que quelqu'un doit savoir ce qui sera perdu. L'analyse est en lecture seule. Le jugement réside dans les questions, la révision et la note qui sera envoyée.
Étape 1 : demander avant d'agir
Posez ces questions en un seul message et attendez les réponses. N'exécutez pas l'analyse d'abord.
- Quelle organisation, et quel est son alias CLI ? Confirmez qu'il s'agit d'un sandbox, pas de la Production. La Production n'est jamais analysée par cette compétence.
- Quand aura lieu le rafraîchissement et de quel type (Full, Partial, Developer Pro, Developer) ? Full et Partial remplacent les données. Developer et Developer Pro n'en conservent aucune.
- Existe-t-il un projet de contrôle de source pour cette organisation ? Si oui, où se trouve-t-il sur le disque ? L'analyse peut comparer l'organisation avec lui.
- Qui possède les intégrations ? La checklist attribue des propriétaires, donc les noms (uniquement les personnes internes) aident.
- Y a-t-il quoi que ce soit dans ce sandbox qui n'existe nulle part ailleurs ? Données de test construites manuellement, un interrupteur de fonctionnalité, une configuration de démonstration.
Étape 2 : exécuter l'analyse
node scan.js --org <alias> --out ./out [--project <chemin vers le projet sfdx>] [--days 90]
Le script écrit out/refresh-risk-checklist.md et out/refresh-risk.json. Si une vérification échoue (une permission manquante pour l'utilisateur courant, un objet que l'organisation ne possède pas), il l'indique dans la checklist et continue. Ne réessayez pas avec plus de permissions sans demander.
Étape 3 : réviser, ne pas simplement transférer
Lisez la checklist et appliquez le jugement que le script ne peut pas :
- Quels éléments sont hors de notre périmètre mais toujours à risque ? Signalez-les quand même. Le client préfère les entendre deux fois plutôt que pas du tout.
- Quels éléments sont du bruit ? Une application connectée que personne n'utilise peut être supprimée intentionnellement. Dites-le au lieu de la lister comme un travail.
- Quels éléments vont se casser silencieusement ? Les utilisateurs d'intégration et les jetons OAuth arrivent en premier dans la note.
- Existe-t-il un script post-copie ? Si non, recommandez-en un. Il transforme la plupart de cette liste en code.
Modifiez la checklist : barrez le bruit, ajoutez les propriétaires, ajoutez tout ce que les réponses de l'Étape 1 ont révélé.
Étape 4 : rédiger la note
Rédigez la note client en termes simples, d'une longueur d'un écran :
- La date et le type de rafraîchissement, dans la première ligne.
- Ce qui sera perdu ou réinitialisé, regroupé : données, identifiants et intégrations, tâches planifiées, configuration propre au sandbox.
- Ce dont nous avons besoin de leur part, avec une date : propriétaires pour les éléments hors de notre périmètre, confirmation pour tout ce que nous prévoyons de supprimer.
- Ce que nous ferons, avec une date : exportations avant, ressaisie et replanification après, un test de fumée le premier jour.
Joignez la checklist. N'envoyez rien sans que le responsable de l'engagement ne l'ait lu d'abord.
Règles
- Lecture seule. Le script ne fait que requêter et lister. N'ajoutez jamais d'écriture.
- Sandboxes uniquement. Si l'alias résout en Production, arrêtez-vous et dites-le.
- Ne collez jamais de secrets dans la checklist. Les noms d'identifiants nommés, oui. Les valeurs, jamais.
- Pas de noms de clients dans rien qui quitte le dossier de l'engagement.