FR 3063361 A1 20180831 FR 1751471 A 20170224 1 PROCEDE, EQUIPEMENT ET SYSTEME DE GESTION DU SYSTEME DE FICHIERS Domaine de l'invention La présente invention concerne le domaine du 5 stockage de données hybride mettant en oeuvre une ressource de stockage locale de capacité limitée présentant un faible temps d'accès aux données, et une ressource distante présentant une plus grande capacité mais un temps d'accès plus élevé, par exemple une ressource nuagique (« cloud en anglais ») ou une 10 ressource sur un serveur distant auquel l'équipement client est relié par un réseau informatique ou encore un périphérique de stockage connecté. L'équipement principal, par exemple un ordinateur, une tablette ou un téléphone (« smartphone » en anglais) est 15 équipé de ressources de stockage telles qu'une ou plusieurs mémoires flash ou disques durs. Les capacités de stockage local sont utilisées pour l'enregistrement de fichiers auquel l'utilisateur souhaite pouvoir accéder pour les lire ou les modifier, ainsi que des 20 fichiers temporaires, par exemple des fichiers de cache évitant d'avoir à transférer de manière répétée des fichiers distants, ou encore des fichiers de travail transitoire. Lorsque la mémoire locale est saturée, certaines applications peuvent présenter de graves disfonctionnements 25 conduisant à la perte définitive de données de travail. Il est donc usuel que le système de gestion de fichiers d'un équipement informatique gère la répartition des ressources de stockage local et distant afin d'optimiser le fonctionnements des applications exécutées sur un équipement 30 informatique. 3063361 2 Il est alors nécessaire de prévoir un processus d'allocation des différentes ressources de stockage et d'accès aux données enregistrées sur différentes ressources, de manière souvent transparente pour l'utilisateur. A titre d'exemple, la solution « FUSION DRIVE » (marque commerciale de la société APPLE) commande la répartition des données entre une ressource de type SSD de 128 Go et un disque dur dont la capacité peut dépasser le téraoctet. La gestion de ces deux ressources consiste à enregistrer par défaut les applications sur la mémoire SSD ainsi que les fichiers temporaires correspondant à ces applications, à réserver un espace libre de quelques gigaoctets sur la mémoire SSD pour l'enregistrement de fichiers cache. Lorsque le cache est plein, il « déborde » sur le disque dur, le système d'exploitation commandant l'enregistrement non plus sur la mémoire SSD mais sur le disque dur de plus grande capacité mais plus lent. Par ailleurs, le système d'exploitation décide du déplacement de certains fichiers et de certaines données et applications du disque dur vers la mémoire SSD et inversement, en prévoyant que les données les plus fréquemment utilisées se retrouveront sur le SSD et les données les moins fréquemment utilisées restent sur le disque dur. Le fichier original n'est toutefois pas supprimé tant que la copie d'une ressource à l'autre n'est pas terminée, par mesure de sécurité. Une fois que cette opération est effectuée, le fichier original est supprimé. Ces solutions apparaissent toutefois relativement simplistes et ne permettent pas une gestion optimale de 30 l'allocation des ressources de stockage et ne permettent pas la gestion de ressources distantes. 3063361 3 Etat de la technique On a proposé dans l'état de la technique d'améliorer ces principes pour une gestion optimisée de 5 ressources distantes « nuagiques ». A titre d'exemple, le brevet US9223795 décrit une solution comprenant une interface avec au moins une application utilisateur pour une vue transparente par un module de système de gestion de fichiers et par un module 10 client de stockage utilisateur mis en oeuvre dans un système de fichiers au niveau utilisateur, pour accéder et synchroniser au moins une ressource stockée dans un dispositif de support de stockage. Ce procédé prévoit de traiter une demande depuis 15 l'application de l'utilisateur, pour accéder à la ressource de système de fichiers par une succession de traitements : - une requête pour accéder à la vue transparente comprend une pluralité d'opérations servant à manipuler les ressources stockées dans les dispositifs de support de 20 stockage ; - la réception, par le module client de stockage, d'une demande d'accès à la ressource à partir de l'application de l'utilisateur pour la vue transparente; - la récupération, par un service de prédiction de 25 stockage, de la demande d'accès à la ressource, dans lequel la requête comprend en outre des métadonnées associées à la demande de l'application de l'utilisateur, la récupération comprenant en outre le traitement de métadonnées associées à la demande utilisée pour identifier la ressource stockée dans le dispositif de support de stockage ; 3063361 4 - l'identification d'une demande supplémentaire pour accéder à une ressource supplémentaire stockée dans un dispositif de support de stockage supplémentaire; - la réception, par un service de stockage en 5 réseau, de la demande d'accès à la ressource comprenant en outre des métadonnées associées à la demande du service de prédiction de stockage utilisé pour monter le dispositif de support d'enregistrement; - la fourniture d'un accès à l'application 10 utilisateur, d'une vue transparente comprenant en outre l'accès aux ressources additionnelles stockées dans les dispositifs supplémentaires multimédias stockés. Un autre exemple de solution connue est décrite dans le brevet US9323695 concernant un procédé de remplacement 15 de cache prédictif pour déterminer quelles données doivent être supprimées d'une mémoire de cache d'accès à partir d'une arborescence des données construite dynamiquement. Une autre solution est décrite dans le brevet US5305389 concernant un sous-système de mémoire cache géré à 20 partir de prédictions basées sur des modèles d'accès stockés par un contexte. Un modèle d'accès est généré à partir des accès antérieurs d'un traitement du système de traitement de données dans un contexte similaire. Au cours d'une séquence d'apprentissage, une trace 25 d'accès à la mémoire est traitée pour déterminer des prédictions futures. Inconvénients de l'art antérieur Les solutions de l'art antérieur prennent généralement en compte le traitement en cours pour déterminer 30 lors d'une requête d'accès à une donnée ou un fichier enregistré en mémoire le chemin d'accès, mais ne permettent 3063361 5 pas d'anticiper un tel besoin d'accès à une donnée ou à un fichier pour permettre de redéfinir l'allocation entre les différentes ressources de stockage de sorte à assurer la disponibilité des fichiers sur la mémoire rapide locale au 5 moment où une application a besoin de procéder à sa lecture ou à sa modification. Il en résulte des temps d'accès longs lorsque la donnée ou le fichier n'est pas disponible localement, une consommation de bande passante élevée et parfois un 10 disfonctionnement majeur, lorsque le réseau n'est pas disponible pour assurer le transfert d'une donnée ou d'un fichier nécessaire à la poursuite de l'exécution d'une application. Solution apportée par l'invention 15 Pour remédier à ces inconvénients, l'invention concerne selon son acception la plus générale un procédé de gestion du système de fichiers d'un terminal informatique disposant d'une mémoire locale, connecté à un réseau comprenant au moins un équipement de stockage distant, 20 comportant des étapes de calcul périodique de l'adressage local ou distant d'un fichier numérique à enregistrer, à lire ou à modifier en fonction d'une loi recalculée périodiquement caractérisé en ce que - Ladite étape de calcul de l'adressage est fonction de 25 métadonnées présentes dans ledit fichier numérique à traiter, de l'historique d'accès dudit fichier à traiter et de l'arborescence locale des fichiers, déterminée à en - Ladite loi est référence, recalculée 30 traitements fonction des commander la recopie d'un locale avant la requête partir d'une loi de tâche de fond, par des usages de l'utilisateur, pour fichier distant sur la mémoire d'accès audit fichier, et à 3063361 6 effacer les fichiers locaux dont ladite loi détermine un indicateur d'utilisation inférieur à une valeur seuil, - Ladite loi de commande étant déterminée pour minimiser la volume des données transférées entre la mémoire locale et 5 la mémoire distante et à minimiser le défaut de cache local, - Et en ce que ledit procédé comporte des étapes exécutées en tâche de fond de recopie des fichiers enregistrés locaux sur l'équipement de stockage distant, 10 - Et en ce que les commandes de modification d'un fichier distant entraînent le téléchargement de la partie dudit fichier à modifier sur la mémoire locale, à déverrouiller la partie du fichier à modifier sur la mémoire locale, à modifier localement ladite partie du fichier à modifier, 15 à verrouiller ladite partie du fichier et à resynchroniser le fichier distant avec le fichier local. Avantageusement, ladite loi de commande en fonction des usages de l'utilisateur prend en compte un critère relatif à l'accessibilité dudit fichier hors connexion. 20 De préférence, l'arborescence des fichiers locaux et distants et la table d'indexation de la totalité des fichiers locaux et distants sont enregistrées dans la mémoire locale et en ce que le système d'exploitation comporte des moyens de visualisation transparent de l'arborescence. 25 Selon une variante, le procédé comporte des prétraitements en tâche de fond du fichier de log pour regrouper les informations de log selon un critère de proximité (vector embedding). Selon une autre variante, le procédé comporte des 30 prétraitements en tâche de fond de regroupement de fichiers sur un même espace de stockage en fonction d'un indicateur de distance vectorielle entre lesdits fichiers. 3063361 7 Avantageusement, lesdits prétraitements sont réalisés au moment du log, entraînement d'un réseau de neurone sur ces logs, et à partir d'un réseau pré-entraîné pour calculer un indicateur numérique correspondant à la 5 probabilité d'utilisation future pour chacun des fichiers. Selon une variante, l'adressage d'un fichier est déterminé par application d'un algorithme d'optimisation combinatoire appliqué audit indicateur numérique de probabilité d'utilisation et des caractéristiques de la 10 mémoire locale et de la communication réseau. L'invention concerne aussi un équipement informatique comprenant un processeur et une ou plusieurs mémoires locales, par exemple une mémoire flash ou un disque dur, associé à un circuit réseau (13), ainsi qu'une mémoire 15 pour l'enregistrement d'un code commandant la gestion du système de fichiers conformément au procédé susvisé. L'invention concerne encore un système constitué par au moins un serveur et au moins un équipement informatique comprenant un processeur et une ou plusieurs mémoires locales, 20 par exemple une mémoire flash ou un disque dur, associé à un circuit réseau (13), ainsi qu'une mémoire pour l'enregistrement d'un code commandant la gestion du système de fichiers conformément au procédé susvisé. Description détaillée d'un exemple non limitatif de 25 l'invention La présente invention sera mieux comprise à la lecture de la description qui suit, concernant un exemple non limitatif de réalisation, et se référant aux dessins annexés où : 30 - la figure 1 représente une vue schématique de l'architecture matérielle d'un système selon l'invention 3063361 8 - la figure 2 représente une vue schématique de l'architecture fonctionnelle d'un système selon l'invention - les figures 3 à 11 présentent des exemples de processus de traitement 5 Contexte de l'invention L'invention concerne un système de stockage mixte (cloud/physique) transparent pour l'utilisateur. Le but est de proposer une solution complète permettant de stocker et de garder accessible une grande 10 quantité de donnée, quantité excédant la capacité de stockage physique de l'équipement informatique utilisé, par exemple un téléphone cellulaire (« smartphone » en anglais) ou une clé USB. L'invention repose sur les principes suivants : 15 - la virtualisation du système de fichier pour gérer de manière transparente les fichiers - l'utilisation de la connexion réseau (par exemple internet) de l'équipement informatique local pour le stockage distant 20 - l'analyse des habitudes de l'utilisateur et des applications exécutées sur l'équipement informatique local afin de déterminer une priorité pour le fichier à stocker en local - l'utilisation du stockage local comme cache 25 d'accélération pour une rapidité équivalente à un système de de gestion de fichiers classique - la conservation des métadonnées de tous les fichiers associés pour émuler leur présence aussi bien lorsque 3063361 9 l'équipement informatique est connecté à internet que lorsque l'accès au réseau est impossible. - l'optimisation des transferts pour diminuer les coûts de bande passante. 5 Du point de vue de l'utilisateur, la capacité de stockage est infinie. Si l'équipement informatique est connecté à internet, tous les documents sont accessibles. Si l'équipement informatique n'est pas connecté à Internet, seuls les documents identifiés comme importants sont accessibles, 10 les autres ne peuvent pas être ouverts. Lorsque l'équipement informatique n'est pas connecté à Internet, tout ajout de document est géré localement. S'il reste suffisamment de place sur l'espace de 15 stockage propre, le document est simplement ajouté et taqué en vue de sa synchronisation ultérieure. Sinon, l'espace de stockage local est libéré par la suppression des documents les moins souvent utilisés par l'utilisateur et les nouveaux documents sont ajoutés et taqués 20 en vue de leur synchronisation ultérieure. L'utilisateur peut également taquer ses propres documents. Il peut ainsi forcer des documents à rester sur la ressource de stockage local, s'il sait qu'il va en avoir besoin. Les transferts de données entre l'équipement informatique et le nuage (« cloud ») son 25 cryptés et le stockage dans le nuage est crypté et peut être verrouillé par mot de passe. Emulation du système de gestion de fichiers Le stockage mixte est mis en place grâce à un logiciel lancé sur l'ordinateur hôte qui émule un système de 30 fichiers (filesystem). Pour ce faire, le driver générique FUSE est utilisé. 3063361 10 Le système de fichiers (« filesystem ») est constitué de trois composantes : 1. Un métacache constitué par un fichier dans le stockage physique de l'équipement informatique, qui contient 5 les métadonnées liées à chaque fichier. Le métacache est implémenté en base SQL. 2. Un accès à un nuage ou une ressource de stockage distante dans lequel sont stockés l'ensemble des fichiers du système de fichiers (« filesystem »). 10 3. Un cache local se trouvant dans le stockage physique de la clé, où sont stockés les fichiers que l'utilisateur voudra le plus probablement utiliser prochainement. Lorsque l'équipement informatique est en ligne, 15 tous les fichiers du système de fichiers (« filesystem ») sont accessibles. Si le fichier se trouve dans le cache local, il est accédé en priorité afin d'améliorer les performances. Lorsque l'équipement informatique est hors-ligne, seuls les fichiers se trouvant dans le cache local sont 20 disponibles. Architecture matérielle d'un système selon l'invention - La figure 1 représente une vue schématique de l'architecture matérielle du système - La figure 2 représente une vue schématique de 25 l'architecture fonctionnelle du système. - Les figures 3 à 11 présentent des exemples de processus de traitement (thread) Description de l'architecture matérielle du système 3063361 11 Il est constitué d'un équipement informatique (10), par exemple une tablette, un ordinateur,_ connecté via un réseau, par exemple internet, à un serveur (20). L'équipement informatique (10) comprend un 5 processeur (11) et une ou plusieurs mémoires locales (12), par exemple une mémoire flash ou un disque dur, associé à un circuit réseau (13), par exemple une carte réseau WIFI ou Ethernet. Le serveur (20) comprend également un processeur 10 (21) et une ou plusieurs mémoires locales (23 à 27), par exemple une mémoire flash ou un disque dur, associé à un circuit réseau (22), par exemple une carte réseau WIFI ou Ethernet. Algorithme de traitement de données 15 Le but de cette section est d'expliciter les traitements de donnée effectués pour servir au mieux l'usage utilisateur. Ces traitements ont deux buts : - Déterminer les motifs d'utilisation de fichiers pour pouvoir prédire avec la plus grande précision les 20 fichiers à stocker sur le cache local (dans le contexte d'utilisation hors ligne, mais aussi pour accélérer la responsivité du système) - Arriver à déterminer des "groupes" de fichiers afin de proposer à l'utilisateur des classifications de 25 fichier adaptées à son usage, mais aussi pour faire du prefetching de fichier pour améliorer les performances. Ces traitements doivent s'effectuer avec un certain nombre de contraintes liées à l'application spécifique à savoir : 3063361 12 - Le besoin d'effectuer le traitement sur des données en continu (stream) - La limitation de la quantité de données stockée concernant chaque fichier 5 - Un espace en changement continu (ajout/retrait de fichiers...) - La limitation de puissance de calcul lié à ce processus Ce processus repose sur des algorithmes de deep 10 learning, en partant d'un modèle pré-entrainé qui va s'adapter aux usages spécifiques de l'utilisateur pour offrir une expérience optimale. Cet algorithme repose d'une part sur la notion de clustering, utilisant les métadata pour arriver à créer des 15 groupes d'usage signifiants mais aussi sur l'idée d'apprentissage supervisé dans lequel l'algorithme apprend en permanence sur la base des événements récents. La classification utilise aussi bien des méthodes de régressions linéaires / classification "classique" (KNN, 20 SVM, Markov process) que des réseaux neuronaux récurrents alliés à du "vector embedding" pour arriver à une sélection optimale. Mise en oeuvre de l'invention L'utilisateur va utiliser son équipement 25 informatique de manière transparente. La figure 2 représente une vue schématique de l'architecture fonctionnelle de l'invention. De manière connue, le processeur d'un équipement informatique possède au moins deux modes de fonctionnement, 30 dont un mode dit superviseur ou mode noyau (30) qui n'impose 3063361 13 pas de restrictions sur les instructions exécutées, et un mode dit utilisateur (40) qui limite ce que peuvent faire les instructions, et quand le système d'exploitation (31) met en oeuvre cette distinction en faisant fonctionner les autres 5 programmes en mode utilisateur et en se réservant le mode superviseur, on dit que les programmes ainsi restreints font partie de l'espace utilisateur (40) (en anglais, userspace). L'application va de manière classique envoyer au noyau de système d'exploitation (30) (« Kernel ») un appel 10 système relatif à la gestion du système de fichiers (« filesystem ») (par exemple: read, write, open, make dir..). Dans la solution proposée par l'invention, on utilise la librairie FUSE/Dokany (35) pour "ramener" ces appels dans l'application USERSPACE (40) et donc utiliser un 15 programme (41) pour y répondre. L'USERSPACE (40) ou « système de fichiers en espace utilisateur» est un espace permettant à un utilisateur (42) sans privilèges particuliers d'accéder à un système de fichiers (43) sans qu'il soit nécessaire de modifier les 20 sources du noyau, via une application désignée usuellement par le nom FUSE. Fuse a pour effet de relayer ces appels et de renvoyer les réponses. Une bibliothèque "binding" est utilisée pour communiquer avec un programme écrit en RUST pour 25 l'exécution du code informatique destiné à la mise en oeuvre de l'invention. Le programme principal a pour action de prendre ces appels et d'exécuter des actions pour y répondre. Pour cela il dispose de deux zones de mémoires. 30 a) Un cache (44), qui permet de stocker les fichiers en eux- mêmes. 3063361 14 b) Un "metacache" (45) qui stocke à la fois les meta-data des fichiers, leurs liens physiques (cloud (46)/stockage local (47)), leur statut de synchronisation, leur historique, leur note d'importance, sous la forme d'une 5 base de données SQLite. Pour chaque appel, le processus principal va donc effectuer une action dans ces zones de stockages puis renvoyer une réponse à FUSE (35). Il est à noter que cette réponse peut être sujette à un "signal" renvoyé par un processus léger 10 (« thread ») de traitement (48 à 51). La seconde partie du programme s'exécute en arrière-plan (52) (programme de type "daemon") pour effectuer une série de taches asynchrones, soit en réaction à une action du VFS qui peut lui envoyer des signaux via un channel, soit 15 de manière périodique. Cette organisation permet de répondre à deux problématiques: a) Eviter d'être "bloquant" vis à vis de l'interface utilisateur lors de taches longues à effectuer (ex: upload) en effectuant ces taches dans un processus léger 20 (thread) b) Mettre en place une série de taches périodiques. C'est par exemple dans un processus léger (thread) du daemon que se fait la notation des fichiers par l'algorithme et la suppression / téléchargement automatique des fichiers prédits. 25 Il est à noter que ce programme « daemon » (52) va aussi pouvoir modifier les fichiers du cache (44) (par exemple lors de téléchargement) et du metacache (45) (par exemple pour changer le statut de synchronisation d'un fichier). Si ces files d'exécution (48 à 52 (« threads ») 30 demandent un accès au nuage (46) (« cloud »), une connection HTTPS est mise en place, que ce soit pour des taches de 3063361 15 chargement « upload » ou « download ». Les identifiants spécifiques à l'utilisateur sont stockés par le programme ce qui permet d'utiliser les routes d'api HTTPS pour envoyer des requêtes au fournisseur de cloud (BackBlaze). Ces taches sont 5 divisées en deux threadpools, une à usage général et une autre dédié aux téléchargements d'urgence, dans le cas de "cache miss". ALGORITHME DE PREDICTION L'algorithme de prédiction est constitué de trois 10 briques techniques principales. - Pré-Traitement Le but des étapes de pré-traitement est de formater des données afin de pouvoir y appliquer des méthodes de « deep-learning ». Un certain nombre des données sont nommées 15 "continues" car elles évoluent dans un espace continu ou pseudo continu ce qui permet de facilement les interpréter sous forme de vecteurs. Ce n'est pas le cas de données comme les extensions fichier, ou bien les chemins d'accès des fichiers. Pour employer ces metadatas, on développe des 20 méthodes de "vector embedding". Ces méthodes ont pour but de décrire ces paramètres dans un espace vectoriel continu. Pour cela on utilise dans cette implémentation du clustering de Markof pour représenter les distances fichier de manière continue, et du "vector embedding" pour dégager un espace 25 vectoriel où on peut interpréter les distances des fichiers. - Analyse L'analyse repose sur un modèle de deep-learning implémenté en TENSORFLOW, pré-entrainé sur des sets génériques qui, en partant du vecteur de description agrégé des fichiers, 30 permet de prédire sur une période donnée la probabilité 3063361 16 d'utilisation d'un fichier. Ce modèle est continuellement réentrainé sur les données de l'utilisateur. - Post-traitement Le post traitement consiste à choisir un set de 5 fichier qui va donner la satisfaction maximale. Cette satisfaction est mesurée selon deux métriques. D'une part la probabilité d'un défaut de cache sur la période à venir, mais aussi la consommation de bande passante (pour des raisons économiques). Dans la pratique, cela signifie utiliser un 10 algorithme du sac-à-dos dans lequel l'espace disponible est celui du disque local, le poids celui des fichiers, et le critère d'utilité est la note donnée par le modèle neuronal pondéré par un facteur relatif à la présence précédente du fichier (pour diminuer l'usage de bande passante). 15 Ces méthodes s'exécutent de manière asynchrone. Les figures 3 à 11 présentent des exemples de processus de traitement (thread) : - Création d'un fichier par un utilisateur (figure 3) - Ouverture d'un fichier par un utilisateur (figure 4) 20 - Lecture d'un fichier par un utilisateur (figure 5) - Ecriture d'un fichier par un utilisateur (figure 6) - Fermeture d'un fichier par un utilisateur (figure 7) - Réception par le daemon d'un événement de type « upload » (figure 8) 25 - Réception par le daemon d'un événement de type « download » (figure 9) - Réception par le daemon d'un événement de type « Jump» (figure 10) - Réception par l'ensemble de processus léger de 30 téléchargement d'un événement de type « download » (figure 11). REVENDICATIONS1 - Procédé de gestion du système de fichiers d'un terminal informatique (10) disposant d'une mémoire locale (12), connecté à un réseau comprenant au moins un équipement de stockage distant (20), comportant des étapes de calcul périodique de l'adressage local ou distant d'un fichier numérique à enregistrer, à lire ou à modifier en fonction d'une loi recalculée périodiquement caractérisé en ce que - Ladite étape de calcul de l'adressage est fonction de métadonnées présentes dans ledit fichier numérique à traiter, de l'historique d'accès dudit fichier à traiter et de l'arborescence locale des fichiers, - Ladite loi est déterminée à partir d'une loi de référence, recalculée en tâche de fond, par des traitements fonction des usages de l'utilisateur, pour commander la recopie d'un fichier distant sur la mémoire locale avant la requête d'accès audit fichier, et à effacer les fichiers locaux dont ladite loi détermine un indicateur d'utilisation inférieur à une valeur seuil, - Ladite loi de commande étant déterminée pour minimiser le volume des données transférées entre la mémoire locale et la mémoire distante et à minimiser le défaut de cache local, - Et en ce que ledit procédé comporte des étapes exécutées en tâche de fond de recopie des fichiers enregistrés locaux sur l'équipement de stockage distant, - Et en ce que les commandes de modification d'un fichier distant entraîne le téléchargement de la partie dudit fichier à modifier sur la mémoire locale, à déverrouiller la partie du fichier à modifier sur la mémoire locale, à modifier localement ladite partie du fichier à modifier, 3063361 18 à verrouiller ladite partie du fichier et à resynchroniser le fichier distant avec le fichier local. 2 - Procédé de gestion du système de fichiers d'un terminal informatique selon la revendication 1 caractérisé en 5 ce que ladite loi de commande en fonction des usages de l'utilisateur prend en compte un critère relatif à l'accessibilité dudit fichier hors connexion. 3 - Procédé de gestion du système de fichiers d'un terminal informatique selon la revendication 1 caractérisé en 10 ce que l'arborescences des fichiers locaux et distant et la table d'indexation de la totalité des fichiers locaux et distant est enregistrée dans la mémoire locale et en ce que le système d'exploitation comporte des moyens de visualisation transparent de l'arborescence. 15 4 - Procédé de gestion du système de fichiers d'un terminal informatique selon la revendication 1 caractérisé en ce qu'il comporte des prétraitements en tâche de fond du fichier de log pour regrouper les informations de log selon un critère de proximité (vector embedding). 20 5 - Procédé de gestion du système de fichiers d'un terminal informatique selon la revendication 1 caractérisé en ce qu'il comporte des prétraitements en tâche de fond de regroupement de fichiers sur un même espace de stockage en fonction d'un indicateur de distance vectorielle entre lesdits 25 fichiers. 6 - Procédé de gestion du système de fichiers d'un terminal informatique selon la revendication 4 ou 5 caractérisé en ce que lesdits prétraitements sont réalisés au moment du log, entraînement d'un réseau de neurone sur ces 30 logs, et à partir d'un réseau pré-entraîné pour calculer un indicateur numérique correspondant à la probabilité d'utilisation future pour chacun des fichiers. 3063361 19 7 - Procédé de gestion du système de fichiers d'un terminal informatique selon la revendication précédente caractérisé en ce que l'adressage d'un fichier est déterminé 5 par application d'un algorithme d'optimisation combinatoire appliqué audit indicateur numérique de probabilité d'utilisation et des caractéristiques de la mémoire locale et de la communication réseau. 8 - Equipement informatique comprenant un 10 processeur (11) et une ou plusieurs mémoires locales (12), par exemple une mémoire flash ou un disque dur, associé à un circuit réseau (13) ainsi qu'une mémoire pour l'enregistrement d'un code commandant la gestion du système de fichiers conformément au procédé conforme à la revendication 1. 15 9 - Système constitué par au moins un serveur et au moins un équipement informatique comprenant un processeur (11) et une ou plusieurs mémoires locales (12), par exemple une mémoire flash ou un disque dur, associé à un circuit réseau (13) ainsi qu'une mémoire pour l'enregistrement d'un code 20 commandant la gestion du système de fichiers conformément au procédé conforme à la revendication 1. 10 - Support de mémoire permanente comprenant un code informatique pour l'exécution par un processeur du procédé conforme à la revendication 1 25