En bref : Un clone copie votre base de production dans un environnement hors production — donc il copie aussi les paramètres qui relient cet environnement au monde extérieur : intégrations, routage, agents d'impression, supervision, branding, SSO. Sans précaution, votre environnement de TEST fraîchement cloné peut se mettre à dialoguer avec les systèmes tiers de production. La communauté maintient une liste de tables d'exclusion à exporter avant le clone et à réimporter après. Voici cette liste, la table qui fait encore débat, ce qu'IFS exclut de son côté, et les contrôles à passer une fois le clone livré.
Rafraîchir un environnement de test depuis la production a l'air d'une opération purement technique. Elle ne l'est pas. Un clone ramène toutes les lignes, y compris celles qui indiquent à l'environnement quelle imprimante utiliser, à quel partenaire EDI répondre, quel locataire SSO faire confiance et quel moteur de planification alimenter. C'est ainsi qu'un environnement de TEST se met à envoyer de vrais messages à de vrais partenaires.
La communauté IFS documente le sujet depuis trois ans, sur un fil devenu la référence de fait. Ce qui suit en est la synthèse, avec les désaccords laissés visibles plutôt que lissés.
Première question : qui peut cloner quoi
La réponse dépend de l'hébergement de votre environnement, et elle surprend beaucoup d'équipes.
Cloud managé par IFS. Vous n'avez pas accès à la base Oracle, donc vous ne pouvez rien cloner vous-même. Vous ouvrez un ticket, et IFS réalise le clone. Les praticiens rapportent un délai de plusieurs jours, des créneaux limités, et la nécessité de réserver l'opération environ deux semaines à l'avance. Des options de clonage automatisées ont depuis été mises à disposition via le portail de services.
Sur site (ou déploiement distant). Vous le faites vous-même, avec un DBA et un administrateur IFS, selon vos procédures habituelles de clonage et de rafraîchissement.
Du cloud vers le sur-site. C'est le cas difficile, et il n'existe pas de procédure officielle. Une équipe a documenté ce qu'il a fallu : trouver un canal capable de recevoir de gros transferts depuis le cloud (les canaux FTPS définis dans le COG semblaient gérer les transferts du client vers IFS, pas l'inverse), demander une sauvegarde de l'environnement source par ticket, et faire réassembler par un DBA une base livrée en morceaux. Prévoyez des frictions.
Le cœur du sujet : les tables d'exclusion
C'est ce qui a fait la réputation du fil, et cela vient de la réponse validée par la communauté.
Une série de tables ne doit pas être reprise de la PROD vers un environnement hors production, afin que vos systèmes hors production n'aillent pas se connecter à des systèmes tiers de production. La procédure est mécanique :
- Exporter ces tables depuis l'environnement cible avant le clone.
- Cloner la base.
- Réimporter les tables exportées dans l'environnement cible.
La liste d'origine a été obtenue auprès d'IFS pour Cloud 21R2, puis étendue par les praticiens version après version. Regroupée par ce qu'elle contrôle réellement :
Intégration et connectivité
connect_envelope_tab, connect_print_agent_task_tab, connect_queue_tab, connect_reader_tab, connect_sender_tab, connect_server_tab, connect_simple_routing_tab, connect_transformer_tab, custom_connector_library_tab, custom_reader_param_tab, custom_sender_param_tab, plsqlap_environment_tab
Routage et adressage
routing_address_tab, routing_address_runtime_tab, routing_rule_tab, routing_rule_address_tab, routing_rule_condition_tab
Documents et médias
edm_location_tab, edm_location_user_tab, media_archive_tab
Supervision, réglages, reporting
fnd_monitor_category_tab, fnd_monitor_entry_tab, fnd_setting_tab, report_plugin_settings_tab, brbase_property_tab, common_messages_tab, config_instance_tab, config_instance_param_tab
Branding (pour que les utilisateurs sachent dans quel environnement ils sont)
fnd_branding_tab, fnd_branding_property_tab, fnd_branding_resource_tab, fnd_branding_token_tab
Assistance à distance
remote_assistance_customer_tab, remote_assistance_group_tab, remote_assist_group_user_tab, remote_assistance_user_ab (orthographe telle que publiée dans le fil source, très probablement une coquille pour _tab : vérifiez le nom exact dans votre version)
Planification et Service Management (PSO)
scheduling_config_tab, scheduling_mapping_tab, svcsch_configuration_tab, tm_serve_parameters_tab
EDI
cust_addr_cross_reference — exclue pour éviter d'avoir à reparamétrer l'EDI
Et un schéma, pas une table : IFSIAMSYS. Les praticiens recommandent de le traiter exactement comme une table d'exclusion : exporter avant, importer après, pour conserver le SSO Azure et l'identité de l'environnement. Celui-là s'oublie facilement puisqu'il ne figure pas dans la liste des tables.
Deux réserves avant de recopier ceci dans un runbook. La liste a été assemblée par des utilisateurs au fil de plusieurs versions : vérifiez-la sur la vôtre. Et elle reflète les besoins de ces équipes : une intégration que vous utilisez et qu'elles n'utilisaient pas n'y figurera pas.
La table qui fait débat
scheduling_dataset_tab mérite sa section, parce que le fil contient les deux positions.
Une équipe l'a exclue lors de son premier clone après passage en production, en suivant la liste communautaire. Son environnement PSO de test a alors cessé de se mettre à jour. Le support IFS a enquêté et conclu que la cause était précisément cette exclusion : le champ Last_Change_Log_Id est mis à jour à chaque message de changement produit, et réimporter une version antérieure de la table a désynchronisé ce compteur du reste du système. Le support a donc conseillé de ne pas exporter cette table. Désactiver puis réactiver le dataset n'a pas corrigé le problème.
Plus tard, sur le même fil, un autre praticien cite scheduling_dataset_tab parmi les exclusions identifiées par tâtonnement.
Les deux témoignages viennent d'équipes qui exploitent PSO en production. Traitez donc ce point comme contesté : tranchez-le dans votre environnement, et prévoyez de devoir recréer ou resynchroniser le dataset après le clone dans les deux cas.
Ce qu'IFS exclut de son côté, et que vous ne maîtrisez pas forcément
La liste d'exclusion règle le problème dans un sens : ce que vous ne voulez pas voir copié. Il existe un second sens, moins documenté, où ce sont les règles de rafraîchissement d'IFS qui décident ce qui n'est pas rafraîchi — et vous faites avec.
Une équipe qui clonait la PROD vers la CFG via Clone Environment dans Environment Studio a constaté que les données de certains événements personnalisés subsistaient dans l'environnement cible au lieu d'être remplacées. Le support lui a répondu que les règles de rafraîchissement excluent FND_EVENT_ACTION, FND_EVENT, les tables d'extension personnalisées et les tables de configuration. Sa question de suivi, posée en juillet 2026, porte sur la façon de configurer ces règles pour que la cible soit identique à la source. Elle est toujours sans réponse.
Bon à savoir avant de promettre à qui que ce soit un environnement cible qui serait une copie exacte de la production : avec l'outillage standard, il ne le sera pas.
Après le clone : ce qu'il faut vérifier
La fin du clone n'est pas la fin de l'opération. Les contrôles qui reviennent chez les praticiens :
Rapports Crystal. Un classique : après un clone PROD vers hors-PROD, les rapports échouent sur une erreur de connexion (Database Vendor Code: 1017, paramètres de connexion incorrects). La correction validée consiste à vérifier les identifiants dans le fichier CrystalWebService_XXXX.zip et à les aligner dans le répertoire de l'instance web Crystal, puis à redémarrer le serveur web Crystal. Si cela ne suffit pas : reconfigurer via l'installeur IFS, récupérer ifs-crystal-config.xml depuis ifs_home/instance/<nom_instance>/CrystalWebService_XXXX.zip et le placer dans le répertoire de l'instance web Crystal pour disposer du mot de passe chiffré correct, vérifier l'entrée TNS, puis redémarrer.
SSO et identité. Si IFSIAMSYS n'a pas été préservé, attendez-vous à des problèmes d'authentification dans l'environnement rafraîchi.
Branding. Si les tables de branding n'ont pas été préservées, votre environnement de TEST ressemble désormais trait pour trait à la production. Les utilisateurs se comporteront en conséquence.
Planification et PSO. Désactiver le dataset, déconnecter la configuration, puis reconnecter et réactiver. Prévoyez une resynchronisation quelle que soit votre décision sur scheduling_dataset_tab.
Intégrations. Tout ce qui relève des familles connect et routing se vérifie avant l'ouverture de l'environnement aux utilisateurs, pas après.
Le clonage ralentit-il la production ?
La question revient dès qu'un clone est prévu pour durer dix heures dans une entreprise qui tourne en continu. La réponse des praticiens : un clone ne devrait pas affecter les performances de l'environnement source, et ce qu'il faut vérifier, c'est qu'aucun job de fond lourd ni fenêtre de maintenance ne tombe au même moment sur la source.
Sur les déploiements distants hébergés dans Azure, une équipe contourne complètement la question en prenant un instantané du disque de la VM de base de données, puis en démarrant une VM de clone séparée à partir de cet instantané. Les instantanés sont quasi instantanés, la source ne voit donc rien passer. Cette option dépend de votre modèle de déploiement.
Ce qu'il advient de votre paramétrage
Voici la partie que personne n'anticipe. Une fois le clone livré, l'environnement cible contient le paramétrage de production, et tout ce que l'équipe y avait mis en place a disparu : les paramètres réglés pour les tests, les permission sets construits pour les utilisateurs de test, les jobs en cours de validation. Vous obtenez une copie fidèle de la production, et vous perdez votre travail en cours.
Les jobs de migration passent par leur propre procédure, qui comporte le même piège d'écrasement : voir déplacer un job de migration entre environnements. Les permission sets construits pour vos utilisateurs de test sont eux aussi à reconstruire, sur un modèle de sécurité plus difficile à lire qu'il n'y paraît.
C'est un problème de promotion, pas un problème de clonage. Et c'est exactement le terrain d'ERP Control : promouvoir du paramétrage entre environnements (CFG, TRN, UAT, PROD) avec une comparaison avant écriture, une sélection au niveau de l'objet, et un journal de ce qui a été promu, par qui et quand. Un rafraîchissement devient alors une opération qui se prépare et se rejoue, plutôt qu'un événement dont on se remet à la main.
Découvrez comment ERP Control gère la promotion de paramétrage entre vos environnements IFS — voir le module de promotion de paramétrage.
Checklist de rafraîchissement d'environnement
Avant
- Confirmer qui réalise le clone (ticket IFS, automatisation du portail, ou votre DBA) et le délai.
- Exporter les tables d'exclusion depuis l'environnement cible, ainsi que le schéma
IFSIAMSYS. - Trancher votre position sur
scheduling_dataset_tabet la consigner pour la prochaine fois. - Lister le paramétrage cible que vous allez perdre, et la façon dont vous le restaurerez.
- Vérifier qu'aucun job lourd ni fenêtre de maintenance ne chevauche l'opération sur la source.
Après
- Réimporter les tables d'exclusion.
- Vérifier les rapports Crystal, le SSO, le branding, la planification, les intégrations.
- Re-promouvoir le paramétrage dont l'environnement cible a besoin pour faire son travail.
- Confirmer qu'aucun environnement hors production ne peut atteindre un système tiers de production.
Voir ERP Control sur votre propre cas
Le rafraîchissement d'un environnement est le moment où la promotion de paramétrage cesse d'être une question théorique. Dans un POC, nous prenons une promotion que vous devez réellement refaire après un rafraîchissement et nous la rejouons dans ERP Control, avec la comparaison et le journal.
La suite : un appel de 30 minutes pour cadrer le besoin, une démonstration sur vos données, puis vous décidez. Sans engagement.
FAQ
Puis-je cloner moi-même un environnement IFS en cloud managé ?
Non. Vous n'avez pas accès à la base, le clone passe donc par un ticket auprès d'IFS, ou par les options de clonage automatisées du portail de services. Anticipez le délai : les praticiens signalent des créneaux limités et une réservation environ deux semaines à l'avance.
Que sont les tables d'exclusion (refresh exclusion tables) ?
Les tables qui portent les paramètres reliant un environnement au monde extérieur (intégrations, routage, agents d'impression, emplacements EDM, supervision, branding, planification, SSO). On les exporte depuis la cible avant le clone et on les réimporte après, pour que l'environnement hors production n'aille pas se connecter à des systèmes tiers de production.
Faut-il exclure scheduling_dataset_tab ?
La communauté est partagée. Une équipe s'est vu conseiller par le support IFS de ne pas l'exporter, après que cette exclusion a cassé la mise à jour de son PSO de test via une désynchronisation de Last_Change_Log_Id ; un autre praticien la cite parmi ses exclusions. Tranchez dans votre environnement, et prévoyez de resynchroniser le dataset dans les deux cas.
Pourquoi mes rapports Crystal ne fonctionnent-ils plus après un clone ?
Parce que les identifiants de la configuration Crystal ne correspondent plus à la base clonée. Vérifiez-les avec le fichier CrystalWebService_XXXX.zip, alignez le répertoire de l'instance web Crystal, contrôlez l'entrée TNS et redémarrez le serveur web Crystal.
L'environnement cible sera-t-il une copie exacte de la production ?
Pas avec l'outillage standard. Les règles de rafraîchissement d'IFS laissent certaines données de côté, notamment autour des événements, des tables d'extension personnalisées et des tables de configuration. Une équipe a demandé en juillet 2026 comment configurer ces règles ; la question est toujours ouverte.
Sources
Cas réels issus de la communauté IFS (discussions avec réponse validée ou réponse d'expert) :
- Discussion IFS Community — cloner une base IFS Cloud et les tables d'exclusion (2022-2025)
- Discussion IFS Community — rapports Crystal en échec après un clone (2024)
- Discussion IFS Community — règles de rafraîchissement et données restées dans la cible (2026)
- Discussion IFS Community — impact d'un clone sur les performances de la source (2024)
Fait partie de notre guide pilier : Migration de données IFS Cloud, le guide complet 2026.