Suivre chaque fichier de la découverte à la migration

• Une ligne par fichier
• Comment chaque fichier est identifié : son ID unique
• Ce qu'enregistre chaque exécution d'analyse
• Comment évolue le statut d'un fichier
• Un fichier migré qui change à la source
• Le statut est suivi à la destination du fichier
• Les phases de travail : analyser, décider, migrer
• Suivre l'avancement de la migration
• Trouver les fichiers non migrés
• Où est passé ce fichier
• Du rapport à l'exécution dans l'application

Une ligne par fichier

Chaque exécution qui traite un fichier l'enregistre dans les tables BI, où chaque fichier possède une seule ligne. Une exécution ultérieure n'ajoute pas de deuxième ligne : elle met à jour la ligne du fichier, c'est-à-dire son Statut du fichier, sa destination, son résultat et l'exécution qui l'a traité en dernier.

Rapport d'analyse

Trouvé par une exécution Analyse, sans être déplacé. C'est l'inventaire que vous analysez pour décider de ce qu'il faut migrer.

Migration de test

Traité par une exécution Migration de test : testé par rapport à sa destination, qui est enregistrée, mais sans être déplacé.

Migration

Déplacé par une exécution Migration, avec son emplacement d'arrivée et son résultat.

Comme chaque fichier n'est compté qu'une fois, les totaux s'additionnent : les fichiers de chaque statut sont les parties d'un même ensemble, et jamais le même fichier deux fois. Le filtre Statut du fichier en haut de la page permet de choisir un ou plusieurs statuts, et chaque fichier porte également son Résultat — Ok, Warning ou Error — avec le Message de la dernière exécution qui l'a traité.

Le rapport montre chaque fichier tel qu'il était lors de la dernière actualisation

SMART BI.pbix est le relevé du statut de chaque fichier au moment de la dernière actualisation du rapport. Les exécutions qui se terminent ensuite apparaissent dès qu'il est de nouveau actualisé : actualisez-le après chaque vague et conservez-en une copie à chaque fois pour suivre l'avancement du projet dans le temps.

En savoir plus : Analyse · Visite guidée du rapport SMART BI · Actualiser, téléverser et partager SMART BI.pbix

Comment chaque fichier est identifié : son ID unique

Chaque ligne des tables BI a pour clé l'ID unique du fichier : c'est ainsi qu'une exécution ultérieure retrouve la ligne propre au fichier et la met à jour au lieu d'en ajouter une seconde. L'origine de l'ID dépend de la source.

Source	L'ID unique du fichier
SharePoint, SharePoint Online, bibliothèques Teams et OneDrive	L'ID unique que SharePoint attribue à chaque fichier. Il reste attaché au fichier lorsque celui-ci est renommé ou déplacé dans sa bibliothèque.
Partages de fichiers	Un fichier sur un partage n'a pas d'ID propre ; SMART Migration en crée donc un : un hachage MD5 du nom et du chemin du fichier.

Sur un partage de fichiers, un fichier renommé ou déplacé est un nouveau fichier

L'ID d'un fichier sur un partage est construit à partir de son nom et de son chemin ; un fichier renommé ou déplacé sur ce partage reçoit donc un nouvel ID : l'exécution suivante l'enregistre comme un nouveau fichier, à côté de la ligne qu'il avait sous son ancien nom ou dans son ancien dossier. Planifiez les renommages et réorganisations d'un partage avant son analyse, ou après sa migration — et réinitialisez ensuite la From Date de la tâche pour une analyse complète.

En savoir plus : Partages de fichiers vers Nextcloud · Exécutions incrémentielles

Ce qu'enregistre chaque exécution d'analyse

La première exécution Analyse d'une source attribue une ligne dans les tables BI à chaque fichier trouvé. Chaque exécution suivante — incrémentielle ou complète, de la même tâche ou d'une autre — n'enregistre que ce qui est nouveau pour les données BI : les fichiers qu'aucune exécution n'a encore trouvés, et les fichiers modifiés depuis l'écriture de leur ligne. Un fichier inchangé n'est pas réécrit.

Chaque exécution d'analyse laisse également son rapport, un classeur Excel (.xlsx), dans le dossier de l'exécution dans Fichiers Nextcloud. Le rapport liste chaque fichier trouvé par l'exécution, qu'il soit nouveau ou non pour les tables BI, et sa colonne StatusInBI indique comment chacun se compare à celles-ci :

StatusInBI	Le fichier	Dans les tables BI
New	Trouvé pour la première fois — lors de la première exécution, chaque fichier	Une nouvelle ligne
Modified	Déjà trouvé, et modifié depuis	Sa ligne est mise à jour
Unchanged	Déjà trouvé, et non modifié depuis	Sa ligne reste telle quelle

Une exécution d'analyse répond donc aussi à la question qu'est-ce qui a changé depuis la dernière exécution : filtrez la colonne StatusInBI du rapport sur New et Modified. Une exécution incrémentielle ne lit que les fichiers créés ou modifiés depuis la dernière exécution réussie ; son rapport ne liste donc que ceux-ci. Une exécution complète liste tous les fichiers, y compris les fichiers inchangés.

Les fichiers modifiés apparaissent en jaune dans le rapport Power BI

Dans le rapport Power BI, le nom d'un fichier modifié depuis sa première analyse s'affiche en jaune — les fichiers qui ont changé au cours du projet ressortent ainsi dans le tableau File details.

En savoir plus : Analyse · Rapports et dossiers d'exécution dans Fichiers Nextcloud · Visite guidée du rapport SMART BI

Comment évolue le statut d'un fichier

Le statut d'un fichier suit le mode de la dernière exécution qui l'a traité. L'ordre habituel est : découvert, migré en test, migré. Aucune étape n'exige toutefois la précédente.

Exécution	Le File status du fichier	Ce qui est enregistré
Analyse	Discovery Report	Le fichier tel qu'il se trouve dans la source : son emplacement, sa taille avec les versions, ses dates et ses métadonnées.
Migration de test	Test Migration	La destination sur laquelle il a été testé, s'il y serait ajouté comme nouveau fichier ou s'il écraserait un fichier existant, et le résultat.
Migration de test avec Restaurer activé	Test Restore	Le fait qu'il a été comparé à sa source, ce qu'une restauration lui ferait, et le résultat. Rien n'est recopié ; voir Restaurer.
Migration	Migration	L'endroit où il a abouti, c'est-à-dire son Destination Path, et le résultat.
Migration avec Restaurer activé	Restore	Le fait qu'il a été recopié de Nextcloud vers sa source, et le résultat ; voir Restaurer.

• Aucune analyse préalable n'est nécessaire. Une tâche Migration de test ou Migration enregistre elle-même les fichiers qu'elle traite. Un fichier qu'elle rencontre et qu'aucune analyse n'a trouvé obtient immédiatement sa ligne, avec le statut Test Migration ou Migration. Sans analyse, le rapport ne connaît cependant que les fichiers traités, et non ceux qui restent à migrer.
• Retour à Discovery Report en cas de modification. Un fichier au statut Migration, ou Test Migration, repasse à Discovery Report lorsqu'une exécution Analyse ultérieure le retrouve et qu'il a effectivement été modifié depuis sa migration : la copie à la destination n'est alors plus la plus récente. Un fichier qui n'a pas changé conserve son statut.
• La destination est conservée pour référence. Un fichier qui repasse à Discovery Report conserve la Destination vers laquelle il a été migré ou migré en test. Vous voyez ainsi toujours où se trouve la copie précédente, et la migration suivante la met à jour à cet endroit.

Relancez l'analyse avant l'exécution finale

Relancez les tâches Analyse de la vague juste avant la Migration finale. Avec Incrémentiel, elles ne lisent que ce qui a changé. Chaque fichier modifié par les utilisateurs après sa migration réapparaît comme Discovery Report, et la migration incrémentielle reprend exactement ces fichiers.

En savoir plus : Exécutions incrémentielles · Règles d'ajout et d'écrasement des fichiers

Un fichier migré qui change à la source

Les utilisateurs continuent de travailler dans la source pendant le projet ; un fichier au statut Migration y est donc souvent modifié par la suite.

1. Une analyse détecte la modification

   Une exécution Analyse qui trouve le fichier modifié remet son File status à Discovery Report. Sa Destination est conservée : le rapport indique donc toujours qu'il a été migré, et vers quel emplacement.

2. La migration le reprend

   Par défaut, l'exécution Migration suivante de la tâche migre à nouveau le fichier modifié : la règle Ajouter les nouveaux, écraser les existants si plus récents écrase la copie à la destination par la version plus récente, et le fichier repasse à Migration.

Pour traiter autrement les fichiers modifiés, ouvrez la tâche, activez Paramètres avancés et choisissez une autre règle sous Rules for adding and overwriting files, à l'étape Destination — Ajouter uniquement les nouveaux, par exemple, importe les nouveaux fichiers et laisse tels quels les fichiers déjà migrés, même si la copie source a changé. Il existe cinq règles, et les autres options avancées limitent les fichiers qu'une exécution prend en compte.

En savoir plus : Règles d'ajout et d'écrasement des fichiers · Options avancées de l'analyse et de la migration

Le statut est suivi à la destination du fichier

Le rapport suit chaque fichier jusqu'à sa destination. Lorsqu'un même fichier est migré vers plusieurs destinations — deux tâches portant sur la même bibliothèque vers deux dossiers d'équipe, ou une tâche dont la destination a été modifiée entre deux exécutions —, seule la dernière destination est enregistrée : la ligne indique le dernier emplacement vers lequel le fichier a été migré ou migré en test, et les copies antérieures ne figurent pas dans le rapport. Leurs exécutions et leurs journaux restent dans l'Historique d'exécution.

Une destination par fichier garantit l'exactitude du rapport

Attribuez une seule destination à chaque source. Un fichier migré deux fois vers des emplacements différents n'est compté qu'une fois, au dernier d'entre eux : le rapport ne montre alors pas l'autre copie, bien qu'elle existe dans Nextcloud.

En savoir plus : Destinations · Historique d'exécution

Les phases de travail : analyser, décider, migrer

Le rapport est conçu pour être utilisé phase par phase, et la même tâche traverse toutes les phases — seul son Mode change :

1. Analyser

   Lancez des tâches Analyse sur les sources. Chaque fichier figure dans le rapport en tant que Discovery Report.

2. Décider dans Power BI

   Analysez les fichiers de manière interactive dans le rapport — par site, propriétaire, ancienneté, type de fichier, taille et versions — et décidez de ce qu'il faut migrer et de ce qu'il faut laisser de côté. Ajustez les filtres des tâches en conséquence, ou exportez une liste contenant exactement les fichiers à reprendre.

3. Tester

   Passez les tâches en Migration de test et lancez-les : les fichiers passent à Test Migration, avec la destination vers laquelle chacun irait et l'indication s'il serait ajouté ou s'il écraserait un fichier existant.

4. Migrer

   Passez les mêmes tâches en Migration — pour toute une vague à la fois avec Modifier les tâches sélectionnées … — et libérez-les. Les fichiers passent à Migration ; ceux laissés de côté volontairement restent Discovery Report, ce qui constitue le relevé de ce qui n'a pas été repris.

5. Réanalyser et rattraper

   Relancez l'Analyse avant la bascule : les fichiers modifiés depuis leur migration repassent à Discovery Report, et une dernière Migration incrémentielle les reprend.

L'étape Action de la boîte de dialogue de la tâche — Action par défaut pour un Import de tâches — résume cela sous Mode, pour les trois modes.

En savoir plus : Planifier et mener une migration, vague par vague · Modifier plusieurs tâches à la fois · Exporter une liste de fichiers depuis Power BI

Suivre l'avancement de la migration

Comme chaque fichier est compté une fois, le rapport montre l'avancement de l'ensemble du projet plutôt que celui d'une seule exécution. Choisissez un Job group, c'est-à-dire une vague de migration. Le filtre File status indique alors combien de ses fichiers, et quelle part de son volume, sont au statut Migration, combien sont au statut Test Migration, et quelle part reste au statut Discovery Report. Choisissez un site, un OneDrive ou un partage dans Job path pour obtenir les mêmes chiffres pour une seule source.

Actualisez le rapport après chaque vague et conservez-en une copie. En comparant ces copies, vous voyez l'avancement du projet dans le temps.

Le Tableau de bord présente le même décompte en un coup d'œil. Sous Fichiers, tâches et exécutions, ses indicateurs Découverts, Migrés en test et Migrés correspondent aux fichiers des données BI dans chaque File status, tels que SMART Migration les a signalés en dernier, chaque fichier étant compté une fois. Migrés en test regroupe Test Migration et Test Restore, et Migrés regroupe Migration et Restore, chacun étant détaillé séparément sur sa carte.

En savoir plus : Actualiser, téléverser et partager SMART BI.pbix · Tableau de bord

Trouver les fichiers non migrés

Choisissez Discovery Report dans Statut du fichier : la page n'affiche que les fichiers trouvés et non migrés — ou migrés puis modifiés depuis, qui affichent toujours leur Destination précédente. Combinez ce filtre avec n'importe quel autre pour en connaître la raison : ils sont antérieurs à la date limite, d'un type de fichier exclu, ou dans une bibliothèque qu'aucune tâche n'a encore reprise.

• Laissés de côté volontairement. Les fichiers exclus par les filtres d'une tâche restent Discovery Report. C'est le relevé de ce qui n'a pas été repris, et pourquoi, pour la validation finale.
• Encore à traiter. Restreignez le tableau à ces fichiers, exportez-le, et une tâche dont le type de source est File List CSV migre exactement ces fichiers.
• En échec. Choisissez Error ou Warning dans Résultat pour afficher les fichiers qu'une exécution n'a pas pu traiter correctement, avec le Message de l'exécution.

En savoir plus : Exporter une liste de fichiers depuis Power BI · Problèmes de fichiers

Où est passé ce fichier

Saisissez une partie du nom d'un fichier dans Nom de fichier, ou de son ancien dossier dans Chemin : le tableau Détails du fichier indique la provenance du fichier et, pour un fichier migré, son Chemin de destination dans Nextcloud — le plus récent, s'il a été migré vers plusieurs destinations. Cela fonctionne aussi dans l'autre sens : saisissez un dossier Nextcloud dans Chemin de destination pour voir tous les fichiers qui y sont arrivés et la provenance de chacun.

C'est la question que l'on pose des années après une migration, et une copie enregistrée du rapport y répond sans le serveur, la base de données ni l'application.

Supprimer une exécution retire ses fichiers du rapport

Les tables BI sont alimentées à partir de l'Historique d'exécution. Lorsqu'une ligne de l'Historique d'exécution est supprimée dans l'application, SMART Migration retire de la base de données de reporting les fichiers enregistrés par cette exécution, et ceux-ci disparaissent du rapport Power BI lors de son actualisation suivante. Ne supprimez que les exécutions de test et les erreurs ; archivez les autres pour les retirer de la vue courante — une exécution archivée reste dans le rapport.

Important : les chiffres du Tableau de bord ne changent qu'une fois que SMART Migration a purgé les exécutions. Actualisez le rapport lorsque l'en-tête Power BI du Tableau de bord affiche un À jour vert au lieu d'une marque rouge.

En savoir plus : Historique d'exécution · Tableau de bord

Du rapport à l'exécution dans l'application

Chaque ligne du tableau Détails du fichier comporte un Lien de la tâche. Un clic dessus ouvre l'application SMART Migration dans Nextcloud sur cette exécution — l'onglet Historique d'exécution, avec les détails de l'exécution —, de sorte que le rapport mène directement au journal de l'exécution, à ses fichiers de rapport et à ses problèmes de fichiers. Si vous n'êtes pas connecté, Nextcloud vous demande d'abord de vous connecter, et l'exécution s'ouvre pour un administrateur Nextcloud.

En savoir plus : Historique d'exécution · Détails de l'exécution et journal de session

Voir aussi

• Informatique décisionnelle avec Power BI
• Visite guidée du rapport SMART BI
• Partages de fichiers vers Nextcloud