FAQ SMART Offload

SMART Offload — Foire aux questions

DÉCHARGEMENT DE SHAREPOINT VERS AZURE BLOB STORAGE

Réduisez la consommation de stockage SharePoint tout en conservant les proxys de documents, les métadonnées et la structure des bibliothèques visibles dans Teams et SharePoint. Ces questions expliquent la configuration, l'expérience utilisateur, les options de restauration et les licences.

Configuration et sélection du contenu

La source et la destination du déchargement doivent-elles être configurées par le service informatique ?

Oui. La configuration de l'environnement SharePoint source, du compte Azure Blob Storage de destination et des critères de sélection du contenu relève de l'administration informatique. Le service informatique gère l'infrastructure, définit les stratégies de déchargement et contrôle l'exécution. Les utilisateurs finaux n'ont pas besoin de configurer les tâches.

Pour un déchargement de fichiers complets, sélectionnez du contenu rarement consulté, comme les documents de projets terminés et les enregistrements inactifs éligibles au déchargement. Les fichiers fréquemment utilisés doivent généralement rester actifs dans SharePoint, car l'accès au contenu binaire déchargé nécessite une restauration.

Vous pouvez aussi conserver la version actuelle dans SharePoint et ne décharger que les versions historiques.

L'expérience de l'utilisateur final

Les utilisateurs continuent-ils à travailler via Teams et SharePoint ?

Oui. Les éléments déchargés restent visibles dans la bibliothèque de documents existante grâce à de petits proxys. Les utilisateurs peuvent parcourir les dossiers habituels et consulter les colonnes de métadonnées conservées dans Teams et SharePoint.

Pour un déchargement de fichiers complets, le contenu binaire d'origine est stocké dans Azure Blob Storage. Un document tel que myfile.docx est représenté par un proxy nommé myfile.docx.url. L'ouverture du proxy lance le processus de demande de restauration configuré, au lieu d'ouvrir directement le document d'origine.

L'espace de stockage SharePoint restant occupé dépend des métadonnées, du nombre de versions et de la conservation ou non du binaire actuel.

Les utilisateurs peuvent-ils encore retrouver les documents déchargés ?

Les utilisateurs conservent la structure des dossiers, les noms de proxys visibles et les métadonnées pour la navigation et le filtrage. La recherche peut exploiter les informations conservées lorsque les champs concernés sont indexés et interrogeables.

La recherche par métadonnées et la recherche en texte intégral dans le contenu sont deux choses différentes. Le contenu binaire conservé uniquement dans Azure Blob Storage n'est pas automatiquement disponible pour l'indexation du contenu par SharePoint. Si la version actuelle du document reste dans SharePoint, ce contenu actif reste disponible pour l'indexation normale.

Restauration des fichiers

L'utilisateur doit-il demander au service informatique de restaurer des fichiers ?

Dans la configuration standard, oui. Le service informatique exécute une tâche de restauration via SMART Migration, en sélectionnant le contenu et sa destination. Les fichiers peuvent être restaurés à leur emplacement d'origine, vers une autre destination SharePoint prise en charge ou vers un partage de fichiers.

La configuration de la restauration est simple. Le délai d'exécution dépend du volume, de l'infrastructure et du niveau de stockage Azure. Le contenu du niveau Archive doit être réhydraté avant de pouvoir être récupéré.

Une option de restauration en libre-service est-elle disponible ?

Oui. Le proxy .url peut pointer vers une Power App et lui transmettre des arguments qui préremplissent les informations nécessaires à la création d'une tâche de restauration.

myfile.docx → myfile.docx.url → Power App → Tâche de restauration

Le code source de la Power App est fourni afin que le client puisse adapter l'interface et le flux de travail à ses besoins. Il s'agit d'une approche configurable de demande de restauration ; ce n'est pas automatiquement une commande native « Restaurer le fichier » dans le menu des fichiers de SharePoint.

Le service informatique doit conserver le contrôle administratif des autorisations de restauration, du choix de la destination et de l'exécution. Les demandes des utilisateurs peuvent être intégrées au processus d'approbation de l'organisation.

Comment cette approche favorise l'adoption

Qu'est-ce qui change dans l'interface utilisateur ?

SMART Offload conserve des proxys de documents visibles et les métadonnées dans l'environnement Teams et SharePoint existant. Les utilisateurs peuvent localiser le contenu via les bibliothèques et dossiers habituels, au lieu de dépendre uniquement d'une interface d'archivage distincte.

Cette continuité peut réduire l'effort de conduite du changement. Les utilisateurs doivent néanmoins comprendre les fichiers proxy, le processus de demande de restauration et la différence entre la recherche par métadonnées et la recherche dans le contenu des documents déchargés.

Licences et accès au contenu stocké

Le client doit-il conserver indéfiniment un abonnement payant ?

Non. Une licence SMART Offload payante est nécessaire pour effectuer des opérations de déchargement. La fonction de restauration n'entraîne aucun frais de licence MigrateDMS, quels que soient le moment et la fréquence des restaurations.

Une licence payante continue est nécessaire si le client souhaite continuer à décharger les fichiers ou versions historiques nouvellement éligibles. Les frais Azure de stockage, de récupération, de transactions et de transfert de données restent distincts de la licence MigrateDMS.

Le contenu déchargé est-il enfermé dans un format propriétaire ?

L'organisation des données dans Azure Blob Storage est transparente et ne repose pas sur un format de stockage propriétaire opaque. Les développeurs du client ou un tiers peuvent créer un autre processus de récupération ou de restauration à partir du contenu stocké et des références associées.

La reconstitution complète de l'élément SharePoint, de ses métadonnées et de son historique des versions nécessite les informations de correspondance pertinentes et un flux de restauration correctement mis en œuvre.

Limitations importantes

Étiquettes de confidentialité, étiquettes de rétention et chiffrement Purview

Le workflow SMART Offload décrit ici ne prend pas en charge la conservation des étiquettes de confidentialité ni des étiquettes de rétention lors du déchargement. Forcer ces fichiers à passer par le processus peut entraîner la perte des étiquettes. Les fichiers chiffrés à l'aide de Microsoft Purview sont également hors du périmètre pris en charge par ce workflow.

Excluez le contenu concerné du déchargement et définissez son traitement avant l'exécution. Il s'agit de limitations du workflow SMART Offload décrit, et non d'une affirmation générale concernant Azure Blob Storage.

Gardez le contenu visible. Pilotez le déchargement de manière centralisée. Restaurez les fichiers lorsque vous en avez besoin.

Voir aussi