Tester REDA dans une sandbox Salesforce

Administrateurs 8 min de lecture Mis à jour en juillet 2026

Une sandbox est un environnement Salesforce de test séparé de la production. Elle reprend la configuration de l’organisation ; la copie des données dépend de son type et de son modèle de copie. Vous pouvez y préparer une modification, une règle de location ou une mise à niveau avant son passage en production. Les automatisations REDA restent applicables aux données de test : une petite modification peut entraîner plusieurs mises à jour. Ce guide présente les points propres à REDA : les paramètres à revérifier après création ou actualisation, les traitements nécessaires aux essais et les limites de réinitialisation et de suppression. Les types de sandbox et les mécanismes de copie sont documentés par Salesforce.

Pour y accéder. Les sandbox se créent dans la configuration Salesforce. Une fois connecté à l’environnement de test, ouvrez le Lanceur d’application → REDA ou REDA Admin.
Accès nécessaire. La création et l’actualisation nécessitent les droits Salesforce de gestion des sandbox. À l’intérieur, vérifiez les accès effectifs de chaque utilisateur après la copie. Dans la configuration Platform fournie, l’ensemble REDA - Master Data - Admin accorde l’accès à la console REDA ; ne supposez pas que toutes les licences et attributions de production sont identiques après une copie.

Ne supposez pas que les automatisations sont neutralisées. Les chargements et modifications de données déclenchent les automatisations REDA dont les conditions sont remplies, comme les opérations manuelles. Ce guide ne prévoit pas de contournement global des déclencheurs. Testez les effets dans une sandbox correctement isolée avant toute modification de production.

Pourquoi utiliser une sandbox

Deux types de changement nécessitent particulièrement une répétition préalable :

Modification d’une règle de location. La modification peut recopier ses paramètres sur les baux actifs concernés et remplacer des ajustements manuels. Vérifiez dans la sandbox quels champs sont modifiés et conservez un état de référence avant d’appliquer le changement en production.
Répétition d’une mise à niveau. Installez et testez la nouvelle version REDA dans une sandbox adaptée. Vérifiez les traitements, paramètres et intégrations avant la mise à niveau de production.

Testez aussi les changements de facturation : fenêtres des factures récurrentes, frais de retard, location au mois et désactivation éventuelle de processus. Isolez les données et connexions pour observer leurs effets sans affecter les opérations réelles.

Points à revérifier dans chaque sandbox

Plusieurs paramètres sont propres à l’organisation et leur état doit être vérifié après la création ou l’actualisation d’une sandbox. Certains peuvent être copiés, d’autres nécessitent une reconfiguration ; une valeur héritée de production peut aussi être inadaptée aux tests. Contrôlez les éléments suivants avant de tirer des conclusions d’un essai :

Vérification	Emplacement	Importance
Présence des traitements nécessaires au scénario	Console d'administration REDA → Tâches planifiées	Contrôlez les planifications effectives dans cette organisation ; ne présumez pas leur présence après la copie.
Paramètre de l’extension comptable	Console d'administration REDA → Paramètres globaux de l'application	Ne déduisez pas la synchronisation de la seule valeur d’un indicateur. Vérifiez les packages installés, la configuration d’intégration et sa destination réelle.
Paramètre multidevise	Paramètres globaux de l'application	Il contrôle le comportement de renseignement des devises par REDA.
Data Service désactivé ou doté de clés de test	Configuration Data Service, par l’administrateur	Les clés des formulaires web sont propres à l’organisation. Les formulaires de production ne doivent pas envoyer de données à la sandbox.
Adresses de base des portails et sites	Paramètres de l’application, propres à l’organisation	Les flux REDA utilisent ces adresses pour leurs liens. Des adresses de production conservées dans la sandbox peuvent rediriger les tests vers le mauvais environnement.
Packages de la suite présents	Configuration Salesforce → Packages installés	Une sandbox REDA seul ne se comporte pas comme une sandbox de la suite complète : la synchronisation vers les factures de vente requiert notamment l’extension Financials appropriée.
État de référence des journaux asynchrones	REDA Admin → Logs asynchrones REDA	Relevez l’état initial et l’heure de début du test pour identifier les nouveaux résultats, sans supprimer l’historique nécessaire.
Délivrabilité des e-mails	Configuration Salesforce	Vérifiez les réglages et les destinataires de test avant tout scénario susceptible d’envoyer des e-mails.

Onglet Scheduled Jobs de la console d’administration d’une sandbox sans traitement planifié, dans l’interface anglaise

L’onglet Tâches planifiées d’une sandbox, dans l’interface anglaise : les traitements de cette capture sont tous Not Scheduled. Les traitements récurrents concernés ne s’exécuteront pas automatiquement tant qu’ils ne seront pas planifiés.

Isoler les tests

Une sandbox est une organisation fonctionnelle : elle peut contacter de vrais destinataires ou des services externes si ses connexions le permettent. Avant un test d’envoi ou de synchronisation, vérifiez les destinations :

E-mails. Contrôlez la délivrabilité et utilisez des destinataires de test. Une sandbox fraîchement actualisée est normalement limitée aux e-mails système, mais vérifiez son réglage effectif avant tout essai de notification.
Formulaires web et liens des portails. Ne dirigez pas un formulaire de production vers une sandbox. Désactivez Data Service ou attribuez-lui des clés et adresses réservées aux tests.
Synchronisation comptable. Vérifiez la configuration d’intégration, les connexions et la destination des factures ; un indicateur d’extension ne suffit pas à prouver une synchronisation active. Activez uniquement la synchronisation voulue vers l’environnement comptable de test.

Tester la facturation de bout en bout

Une absence de factures récurrentes peut simplement venir de traitements en arrière-plan non planifiés. Cela ne signifie pas que toute création de facture est impossible : certaines actions manuelles ou automatisations peuvent aussi en produire. Pour votre scénario, configurez le traitement nécessaire et vérifiez les conditions d’éligibilité des charges :

Scénario	Traitement à prévoir	Point de calendrier
Facturation récurrente des loyers	Charges récurrentes, selon le cycle mensuel, quotidien ou hebdomadaire	Le traitement ordinaire sélectionne les charges dues à sa date de traitement, aujourd’hui par défaut. Alignez la prochaine date de facturation sur le jour de l’essai.
Politique de frais de retard	Frais de retard quotidiens et/ou mensuels	Le calcul tient compte des périodes dues selon ses critères ; vérifiez le résultat après l’exécution.
Frais de location au mois ou de maintien dans les lieux	Traitements correspondants, quotidiens et/ou mensuels	Le calcul reprend les périodes dues selon ses critères ; une planification manquée doit néanmoins être examinée.
Inflation et augmentation de loyer	Les deux traitements d’inflation, avec une règle et l’indice du mois concerné	Le calcul prend en compte les périodes dues. Un indice absent produit « Indice d'inflation non défini pour la période. » dans Platform.
Facturation liée à une sortie retardée	Traitement des charges récurrentes de sortie retardée	Sa date de traitement par défaut est la veille ; il sélectionne les sorties prévues ce jour-là dont la sortie effective n’est pas enregistrée, sous réserve des autres critères.
Échéanciers de loyer linéaire	Traitement des échéanciers ou action de calcul sur un bail	L’action sur la fiche permet de tester un bail sans planifier le traitement général.
Inspections récurrentes	Traitement des inspections récurrentes	Vérifiez explicitement sa planification : elle est souvent oubliée lors des tests.
Instantanés d’occupation	Traitement des instantanés ou action Créer instantané de rapprochement	L’action attend un mois : « Saisie invalide. Vous devez fournir une valeur au format AAAA-MM. Par exemple, pour janvier 2026, saisissez 2026-01. »

Le calendrier fait partie du scénario. Le traitement ordinaire des charges récurrentes sélectionne une date précise et ne constitue pas un rattrapage général des dates antérieures. Les traitements de frais de retard, de location au mois et d’inflation calculent les périodes dues selon leurs propres règles. Cette capacité de rattrapage ne garantit pas qu’une exécution réussira ni qu’une interruption de planification est sans conséquence : vérifiez les conditions, les données et les résultats attendus.

Utilisez les actions unitaires pour un contrôle ciblé. Calculer échéancier linéaire sur un bail, Créer instantané de rapprochement sur un bien et Exécuter manuellement sur une règle d’inflation permettent de lancer un calcul à la demande. Choisissez cette approche lorsque le test ne nécessite pas une exécution globale et vérifiez la portée exacte de l’action.

Répéter les changements sensibles

Trois scénarios couvrent les principaux besoins :

Modifier une règle de location et observer sa propagation. Modifiez un paramètre de règle, puis ouvrez les baux de test actifs concernés pour identifier les champs remplacés. Comparez l’état avant et après ; n’appliquez pas ce changement en production sans avoir évalué sa portée.

Modifier une politique de facturation. Ajustez une fenêtre de facturation récurrente ou un paramètre de frais de retard, lancez le traitement approprié dans la sandbox et suivez un bail de bout en bout avant toute application en production.

Évaluer les effets d’une désactivation de flux. Les flux de tickets sont généralement organisés par type de processus, mais leurs effets peuvent alimenter d’autres automatisations. Dans la sandbox, désactivez uniquement le composant visé par le test, observez les étapes qui ne se produisent plus et vérifiez les dépendances ; ne supposez pas que le reste du système est nécessairement inchangé.

Désactiver un flux modifie le processus. Les possibilités d’activation des flux gérés dépendent du composant et de la plateforme ; vous ne modifiez pas directement le flux du package. Si votre test consiste à désactiver un flux autorisé à l’être, documentez son état initial, ses dépendances et les effets observés. Toute décision de reproduire le changement en production doit tenir compte de ces résultats.

Repartir entre deux essais

Les protections de suppression s’appliquent aussi dans la sandbox. Une facture partiellement payée ou liée à un lot, une charge protégée par un dossier approuvé ou une ligne de rapprochement comptabilisée ne deviennent pas supprimables parce qu’il s’agit d’un test. Préparez des données dédiées et préservez les preuves des scénarios comptabilisés ou approuvés. Pour les baux éligibles, examinez l’action Réinitialiser location et ses effets destructifs avant de l’utiliser.

La réinitialisation supprime les charges, tickets et factures liés au bail, peut supprimer les lots de factures concernés et remet l’étape à Demande - Nouvelle (Application - New). L’avertissement Platform est « Lors de la réinitialisation, les frais, tickets et factures liés à l'opportunité seront supprimés et l'étape de l'opportunité sera définie sur “Nouvelle demande”. ». Les étapes autorisées dans le flux de référence sont Demande - Nouvelle (Application - New), Demande - Terminée (Application - Completed), Demande - Approuvée (Application - Approved), Contrat - En cours (Agreement - In Process) et Occupé - Emménagement en attente (Occupied - Pending Move In). Le simple critère « non occupé » ne suffit donc pas. Un bail hors de ces étapes est refusé avec « Le bail d'un espace occupé ne peut pas être réinitialisé. Veuillez contacter votre administrateur système. ». Les droits et autres validations restent applicables ; l’action ne garantit pas le contournement des protections de suppression. Sauvegardez les éléments nécessaires avant de confirmer.

Logs asynchrones REDA après un essai, avec des résultats réussis et des erreurs à examiner

Logs asynchrones REDA après un essai : comparez les nouveaux résultats à votre état initial. Tous les traitements ne créent pas nécessairement un journal en cas de succès.

Exemple : tester un changement de frais de retard

L’administrateur de Meridian souhaite modifier une politique de frais de retard. Il prépare le scénario suivant :

Choisissez ou actualisez une sandbox et effectuez les vérifications : paramètres de l’extension comptable, connexions de test et absence de clés Data Service de production.

Prévoyez uniquement les traitements de frais de retard nécessaires dans la sandbox. Lancez le calcul sur les données du scénario, puis vérifiez qu’il traite les périodes attendues.

Préparez un cas de test avec un bail et une facture échue, puis observez les frais générés lors de l’exécution.

Vérifiez avant d’appliquer. Comparez les frais obtenus au résultat attendu, conservez les preuves, puis appliquez le changement de production selon la procédure de validation de votre organisation.

Les mécanismes de sandbox relèvent de Salesforce. Pour les types, les délais d’actualisation, la copie des données et les vérifications après actualisation, consultez la documentation Salesforce sur les sandbox. Vérifiez également les versions réellement installées : une sandbox mise à niveau peut contenir des fonctions plus récentes que la base de connaissances consultée.

Pour poursuivre

Liste de contrôle avant mise en production — les traitements à vérifier d’abord dans la sandbox.
Planifier les traitements en arrière-plan — le catalogue des traitements utiles aux essais de facturation.
Règles de location — les paramètres propagés aux baux actifs.
Surveiller les journaux asynchrones — retrouver les résultats et erreurs des traitements.
Notes de version — préparer les essais de chaque mise à niveau.

Questions fréquentes

Pas nécessairement. Pour la facturation récurrente, vérifiez les traitements planifiés, la date de traitement, l’activation comptable du bail et l’éligibilité de la charge. Configurez le traitement adapté dans la sandbox, puis contrôlez son résultat et les erreurs éventuelles. Consultez la liste de contrôle avant mise en production.

Ne le supposez pas. Les imports et modifications déclenchent les automatisations dont les conditions sont remplies. Aucun contournement global n’est prévu dans cette procédure. Préparez le chargement dans un environnement isolé ; toute désactivation ciblée doit être testée avec ses dépendances.

Les protections de suppression s’appliquent aussi dans la sandbox. Préparez des jeux de données dédiés et conservez les résultats nécessaires. L’action Réinitialiser location est réservée aux étapes autorisées et supprime plusieurs enregistrements liés ; elle reste soumise aux droits et validations et ne constitue pas un effacement universel des données de test.

Lorsqu’un traitement similaire est encore en cours, REDA peut refuser un lancement concurrent avec « Une tâche similaire est en cours. Veuillez patienter jusqu'à la fin de la tâche en cours avant d'en lancer une nouvelle. Contactez votre administrateur système pour obtenir de l'aide. ». Attendez la fin de la première exécution, vérifiez son résultat, puis relancez si nécessaire.

Oui, si son étape fait partie des cinq étapes autorisées citées plus haut et si les autres validations et droits sont satisfaits. Réinitialiser location supprime les charges, tickets et factures liés et remet le bail à Demande - Nouvelle (Application - New) ; les lots concernés peuvent également être supprimés. Hors des étapes autorisées, le message est « Le bail d'un espace occupé ne peut pas être réinitialisé. Veuillez contacter votre administrateur système. ». Préservez les preuves et données nécessaires avant de confirmer cette suppression.

Cet article vous a-t-il été utile ?