Transferts

Les adresses signées d’un LOT de fichiers (1 à 100), pour une personne du transfert : c’est ce que l’application de bureau demande pour reconstruire l’envoi sur le disque.

Crée un transfert de fichiers (métadonnées seules) avec le premier lot de son manifeste, et réserve son quota. Projet facultatif : sans projet, seuls son auteur et les administrateurs le voient.

Ajoute un lot d’entrées (≤ 1 000) au manifeste d’un transfert ; `complet` le ferme.

Les transferts visibles, du plus récent au plus ancien.

L’état du stockage objet de Transfert : configuré ou non. Jamais un repli — sans stockage, les envois sont refusés (503 STOCKAGE_INDISPONIBLE, raison NON_CONFIGURE).

Lot 15 — les stockages PROPRES de l’entreprise (ses buckets S3) : fournisseur et région du catalogue, bucket, préfixe de clé, état (`A_VERIFIER`, `CONFORME`, `NON_CONFORME`, `EN_RETRAIT`, `RETIRE`, `REVOQUE`), dernier rapport de vérification et ce qui manque, transferts qui y vivent ; et où vont les nouveaux transferts.

Connecte un bucket de l’entreprise : un fournisseur et une région du CATALOGUE (jamais une adresse libre), le bucket, sa clé, et une clé d’analyse en lecture seule facultative. Nexus le vérifie pour de vrai (privé, écriture, lecture signée, par plage, en pièce jointe, CORS, cycle de vie, droits de la clé d’analyse) et range le rapport. Rien n’est activé.

Revérifie le bucket pour de vrai et range le nouveau rapport (CONFORME ou NON_CONFORME).

Pose la règle CORS (les origines de la page de Nexus) et le cycle de vie (envois abandonnés, filet de purge) sur le bucket, puis le vérifie.

Les NOUVEAUX transferts de l’entreprise iront dans ce bucket. Un transfert garde à vie le stockage où il est né : rien ne bouge.

Revient au stockage de Nexus pour les nouveaux transferts. Aucun transfert ne bouge.

Change les clés (rotation) : les nouvelles sont VÉRIFIÉES sur le bucket avant d’être posées ; si elles échouent, les anciennes restent et le rapport dit pourquoi. Les transferts en cours continuent.

Retire un stockage : plus aucun nouveau transfert ; ceux qui y vivent restent lisibles jusqu’à leur purge, puis le tour efface ses clés (`EN_RETRAIT` → `RETIRE`). Sans transfert vivant, c’est immédiat.

Révoque un stockage (une clé fuitée) : ses clés s’effacent sur-le-champ. Ses transferts ne se lisent plus depuis Nexus (503 `STOCKAGE_INDISPONIBLE` raison `RETIRE`) ; leurs objets restent chez le fournisseur, que le cycle de vie du bucket finit d’effacer.

L’état de l’analyse antivirale : les workers (état, moteur, âge des signatures, dernier battement), la file de l’entreprise (en attente, en cours, en échec, l’attente la plus ancienne) et les mesures des dernières 24 h (analyses, octets relus, temps de moteur, verdicts).

Le détail d’un transfert, sans aucune URL.

Les entrées du manifeste, par pages (un transfert peut en porter 100 000).

Ouvre (ou reprend) l’envoi d’un fichier du manifeste chez le stockage objet. Rend la géométrie : taille, taille de partie, nombre de parties.

Signe un lot de parties (≤ 100) : une URL par partie, valable pour CET envoi et la taille EXACTE de la partie.

Les parties que le STOCKAGE a déjà reçues pour l’envoi en cours (numéro, taille). C’est lui qui fait foi à la reprise, jamais le client.

Assemble l’objet à partir des parties que le stockage LISTE, puis le RELIT : le fichier n’est finalisé qu’après relecture de sa taille. Le dernier fichier d’un manifeste complet fait passer le transfert en vérification (jamais directement « prêt »).

Lot 17 — ouvre et signe un LOT de dépôts DIRECTS pour des petits fichiers (≤ 4 Mio, ≤ 100 par appel) : une URL de PUT par fichier, sa taille signée. Un appel pour cent fichiers, au lieu de deux par fichier. Chaque fichier est jugé seul ; un refus le renvoie au chemin multipart.

Lot 17 — finalise un LOT de dépôts directs : chaque objet est RELU au stockage (HEAD) et comparé au manifeste, comme un fichier unique. Le dernier fichier d’un manifeste complet fait passer le transfert en vérification.

Lot 18 — le direct entre postes : le niveau ouvert par le serveur (déclaré, effectif), la coupure par l’entreprise, le consentement pour les tiers.

Lot 18 — un administrateur COUPE le direct pour son entreprise, ou CONSENT à servir les tiers en direct (leur navigateur voit des adresses réseau du poste).

Lot 18 — un membre, sur son poste, demande le DIRECT pour un fichier qu’il voit (réception sur le poste).

Lot 18 — un message de la négociation, d’un poste (émetteur ou destinataire) vers l’autre bout de SA session.

Lot 18 — le poste destinataire déclare l’issue (voie, octets, durées, type de candidat) ; la session se ferme.

Annule l’envoi en cours d’un fichier : les parties reçues sont abandonnées chez le stockage, le fichier redevient ATTENDU.

Une URL signée de 5 minutes pour lire UN fichier d’un transfert qu’on voit — le téléchargement d’une personne de l’entreprise.

L’APERÇU d’un fichier d’un transfert qu’on voit (lot 19) — le même que celui du tiers : demandé, suivi, puis ses adresses signées.

Crée un lien externe : ouvert (`LIEN`) ou réservé à des adresses confirmées par code (`VERIFIE`). L’adresse `…/t#<jeton>` n’est rendue QU’ICI ; la base n’en garde que l’empreinte.

Demande des fichiers à des tiers sans compte (lot 10) : crée la DEMANDE (un transfert de genre `DEMANDE`, avec ses règles) ET son premier lien de dépôt, d’un seul geste. Le lien n’est rendu QU’ICI.

Ferme la collecte d’une demande : plus aucun dépôt, par aucun lien ; les fichiers pas encore arrivés en entier sont RETIRÉS (place rendue, envoi coupé) ; la demande passe en analyse puis se publie.

Les déposants d’une demande : référence, nom DÉCLARÉ (jamais vérifié), adresse VÉRIFIÉE (code d’un lien vérifié) — deux identités qui ne se confondent pas —, dossier, fichiers annoncés et reçus, dernier geste.

Retire un fichier DÉPOSÉ d’une demande ouverte (ou échue) : effacé du stockage, sa place rendue, son analyse annulée.

Les liens d’un transfert (200 plus récents) avec leur statut CALCULÉ (actif, expiré, révoqué, épuisé), le même que la page du tiers.

Révoque un lien : la page et toute nouvelle autorisation le refusent aussitôt. Ne supprime AUCUN fichier.

Le journal d’un transfert (200 derniers faits) ; lisible après la suppression par son auteur et les administrateurs, pour constater la purge.

Le SUIVI d’un transfert (lot 20) : ses destinataires et le niveau de PREUVE atteint par chacun (page ouverte, téléchargement commencé, réception confirmée — jamais une lecture), l’historique REGROUPÉ (un dossier de mille fichiers fait une ligne), les notifications émises et l’état de leur courriel.

Règle QUAND prévenir l’auteur qu’un transfert a été récupéré (lot 20) : par destinataire (défaut), à la première récupération, ou jamais.

LE FLUX DE RATTRAPAGE (lot 20) : les faits des transferts qu’on voit, après un curseur, dans l’ordre — ce qu’un script ou un poste relit à sa reconnexion.

Supprime un transfert (logiquement) et pose sa purge physique.

Tire une DÉLÉGATION : un jeton `nxt_…` pour un script ou un agent hors de Nexus, qui agit sous VOTRE identité, dans UN projet (ou vos transferts sans projet), ou un seul transfert, pour des actions et une durée choisies. Le jeton n’est rendu QU’ICI.

Vos délégations (un administrateur : celles de l’entreprise), vivantes, échues ou révoquées : préfixe, portée, actions, consommation, dernier emploi.

Révoque une délégation : son jeton est refusé aussitôt (401). Rejouable.

La délégation qui appelle : ses actions, sa portée, son échéance, ce qu’il lui reste — c’est la première question de la commande `nexus-transfert`.

La délégation qui appelle se révoque elle-même : un script qui a fini rend son jeton.

Pose une ADRESSE PRÉVENUE : Nexus y envoie, signés (HMAC-SHA-256), les faits des transferts de l’entreprise — identifiants et mesures, jamais un nom de fichier. Le secret de signature n’est rendu QU’ICI.

Les adresses prévenues de l’entreprise : indice d’adresse (jamais l’adresse entière), faits écoutés, état, dernière livraison.

Désactive ou réactive une adresse prévenue (une adresse suspendue se réactive ainsi).

Retire une adresse prévenue et ses livraisons en attente. Les faits restent au journal des transferts.

Envoie à l’adresse une livraison d’ESSAI, signée comme les autres (genre `ESSAI`), et rend sa réponse.

Les livraisons d’une adresse (les plus récentes, conservées 30 jours) : statut, essais, dernier code, prochain essai.

Remet une livraison en attente, avec le MÊME identifiant : le consommateur la reconnaît s’il l’avait déjà traitée.

Le tableau d’exploitation de Transfert : quota (plafond, réservé, palier), stocké et dérivés, flux sur 24 h et 30 jours (envoyé MESURÉ, sortie ESTIMÉE), qui réserve l’espace, travaux et workers, compteurs du processus, coût mensuel ESTIMÉ sur la grille du fournisseur datée, dernier rapprochement, réglages.

Relit le stockage de l’entreprise et le compare à ce que la base dit finalisé : objets relus, attendus, orphelins (un objet sans ligne), manquants (une ligne sans objet).

Remet en attente les purges en ÉCHEC de l’entreprise (essais remis à zéro) ; le tour d’entretien les reprend dans la minute.