Réaffectation de corpus documentaire

Objectif

La fonction Réaffecter un corpus permet de déplacer en masse des documents déjà ingérés vers un autre emplacement logique Nexus :

source_app / workspace / project

Elle sert aux corrections de classement, aux changements de taxonomie et aux opérations de nettoyage après ingestion automatique.

Quand l'utiliser

Utiliser cette fonction lorsque plusieurs documents sont classés dans un mauvais service, workspace ou projet, mais que les fichiers et artefacts stockés restent valides.

Exemples :

• déplacer des articles arrivés dans Autre vers un projet thématique ;
• corriger un flux automatique après changement de configuration Atlas ;
• regrouper un corpus importé dans un workspace plus précis ;
• sortir des documents d'un projet obsolète sans réingestion.

Ne pas l'utiliser pour supprimer des documents, déplacer des objets physiques MinIO/S3 ou reconstruire un corpus depuis zéro.

Prérequis

• L'utilisateur doit avoir le droit d'écriture (can_write) sur le corpus cible.
• Le périmètre source doit être filtré depuis la liste Documents.
• Le workspace cible doit exister et être actif.
• Le projet cible est optionnel. Choisir Workspace seul pour déplacer les documents au niveau workspace sans projet.

Parcours UI

1. Ouvrir Documents.
2. Filtrer le périmètre source à déplacer : service, workspace, projet, application appelante, type de fichier, utilisateur ou recherche texte.
3. Cliquer sur Réaffecter un corpus.
4. Vérifier le bloc source affiché dans la modale.
5. Choisir explicitement le corpus cible, puis le workspace cible, puis le projet cible si nécessaire.
6. Cliquer sur Prévisualiser.
7. Vérifier le volume, le nombre de batchs, les ressources et l'échantillon.
8. Saisir le nombre de documents affiché pour confirmer.
9. Cliquer sur Réaffecter.

La confirmation par nombre de documents évite de lancer une mutation large sans avoir relu le volume réellement touché.

Exemple : flux GDELT

Pour reclasser des flux courts GDELT vers le projet dédié :

Corpus cible      : Sources Articles Auroramind
Workspace cible   : Actualités IA & innovations
Projet cible      : Flux d'actualités Gedelt

Le projet cible est le champ Nexus project. Il doit être choisi après le workspace, car les projets sont rattachés à un couple source_app / workspace.

Effets techniques

La réaffectation modifie l'emplacement logique des documents.

Postgres reste la source de vérité. Qdrant est un index dérivé et doit refléter les mêmes métadonnées de filtrage pour éviter un retrieval sur l'ancien scope.

Garde-fous

• La prévisualisation serveur est obligatoire avant l'exécution.
• Le token de prévisualisation lie le périmètre source et la cible.
• Le volume synchrone est borné pour éviter les mutations trop larges.
• Les droits sont vérifiés sur le source_app source en lecture et sur le source_app cible en écriture.
• Une erreur de synchronisation Qdrant est signalée comme avertissement : la mutation Postgres peut être faite alors que des payloads vectoriels restent à réparer.

Vérifications après opération

Après une réaffectation :

1. Rafraîchir la liste Documents.
2. Filtrer sur le nouvel emplacement et vérifier le volume attendu.
3. Filtrer sur l'ancien emplacement et vérifier que les documents déplacés n'y apparaissent plus.
4. Lancer une recherche RAG filtrée sur le nouveau scope si le corpus est utilisé en retrieval.
5. En cas d'avertissement de synchronisation, contrôler les logs API et prévoir une réparation Qdrant ciblée.

API associée

• POST /api/documents/bulk-relocation/preview
• POST /api/documents/bulk-relocation/execute

Voir aussi AURORA_NEXUS_API.md et 07_Reference-Tech/54-API-Reference.md.