# Manifeste OS.tral.OP: La programmation par élévation pour des applications graphiques multi-plateformes, hybridables et téléportables

Ryad Ben-El-Kezadri, Salem Belhaj

<figure><img src="image_1.png" /></figure>

## To cite this version:

Ryad Ben-El-Kezadri, Salem Belhaj. Manifeste OS.tral.OP: La programmation par élévation pour des applications graphiques multi-plateformes, hybridables et téléportables. 2024. hal-04801056

HAL Id: hal-04801056

https://hal.science/hal-04801056v1

Submitted on 25 Nov 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Manifeste OS.tral.OP:

La programmation par élévation pour des applications graphiques
multi-plateformes, hybridables et téléportables

Ryad Ben-El-Kezadri¹ et Salem Belhaj²,³

¹Atlas Research & Development, Tunis, Tunisie

²Computer Science Department, College of Sciences, Northern Border University, Arabie Saoudite

³Département informatique, Ecole Nationale Supérieure d'Ingénieurs de Tunis (ENSIT), Université de Tunis, Tunisie

Résumé

Nous présentons OS.tral.OP, une méthode de développement généraliste permettant de mettre au point des applications en se basant sur les fonctions primitives du système d'exploitation: explorateur et système de fichiers. Basiquement sous OS.tral.OP, les contrôles graphiques sont représentés sous forme de fichiers vides. Un agent détecte les interactions de l'utilisateur avec cette interface homme machine (IHM) primitive et lance les tâches de back-end associées.

Une fois le back-end établi, OS.tral.OP utilise un système d'élévation pour transférer l'interface primitive vers des espaces plus complexes comme une interface desktop. Nous montrons comment assembler, via cette méthode, une IHM en composant plusieurs interfaces primitives. Nous généralisons cette approche système au web afin de permettre à l'internaute de produire librement des IHM dans le navigateur. Nous présentons à titre d'exemple l'application Lucy, mix de deux services d'intelligence artificielle, obtenu en hybridant en cours d'exécution deux IHM indépendantes.

I. Introduction

L'informatique classique est basée sur le concept d'application desktop où un ensemble dédié de contrôles, disposé dans la fenêtre du logiciel, permet d'interagir avec le programme. Avec OS.tral.OP, a contrario, les boutons sont représentés par des fichiers (fichiers `.oto` vides), ceux-ci étant directement exposés dans l'explorateur de fichiers et donc dans l'OS. L'IHM est donc visible dès le démarrage de l'OS et ne nécessite que l'exécution de l'agent pour fonctionner.

Contrairement aux applications classiques où l'interaction est déclenchée en cliquant sur un bouton, l'interaction est ici lancée par l'opération la

plus primitive du système de fichiers: la suppression de fichier (ie d'un fichier `.oto`). Un agent observe la suppression des fichiers `.oto`. Lorsqu'un tel évènement est détecté, l'agent lance la tâche associée au contrôle puis recrée le fichier `.oto` une fois le traitement terminé. Ce changement d'état du fichier, marqué par sa disparition puis sa réapparition fournit à l'utilisateur le feedback relatif au lancement et à la terminaison de sa tâche.

Une austral APP est composée de fichiers `.oto` vides (front-end), des fichiers de données et du code de l'agent surveillant les interactions dans l'IHM et lançant les traitements (back-end).

On appelle élévation sous OS.tral.OP, la capacité de l'explorateur de fichiers à élever le front-end primitif en interface desktop ou web. L'ajout à l'explorateur de fonctions d'élévation avancées est un sujet important car l'explorateur de fichiers bien que fondamental dans l'OS figure parmi les briques logicielles ayant le moins évoluées en informatique.

Le rôle du programmeur se limite pour l'IHM à générer une arborescence de fichiers permettant le contrôle de son application. On appelle matérialisation, le mécanisme découpant les données originales à traiter (exemple fichier `.pdf`, `.json`) et générant les contrôles déclenchant le traitement de ces sous-éléments. La matérialisation produit une structure arborescente joignant fichiers de contrôles et sous fichiers de données. La matière désigne la représentation fichier de cette structure, quand celle-ci est stockée sur disque, et sa forme émulée quand elle est stockée sur d'autres supports (cf la section II) ou transite sur le web.

Sous OS.tral.OP, le développeur est le responsable de la matérialisation et l'explorateur OS.tral.OP, celui de l'élévation.
La copie de matière entre répertoire permet facilement à une application de dédoubler des parts de son interface sur d'autres parties du disque et donc dans d'autres applications permettant ainsi à celles-ci de **partager leurs fonctions**.

On appelle *portail OS.tral.OP* le répertoire dédié à une austral APP dans la matière d'une autre application. Le développeur ouvre un portail inter-applicatif en créant un lien symbolique entre les matières de deux austral APPs. Une austral APP (*exo APP*) peut alors déverser sa matière (ie son IHM) dans l'autre (*endo APP*). Le développeur crée le portail au plus près des sous éléments de données à traiter, dans l'arborescence de matière de l'*endo APP*. Cela permet à l'*exo APP* de cibler plus facilement les potentiels fichiers de données à traiter. La création de portail inter-applicatif est le **premier trait** de haut niveau de OS.tral.OP.

Le **deuxième trait** de fonctions de haut niveau de OS.tral.OP est la capacité offerte aux austral.Apps à dédoubler leur interface sur le web. Ceci est possible car l'explorateur OS.tral.OP est développé comme une application web avec un serveur et un client graphique. Le serveur est chargé d'extraire une arborescence (par exemple à partir du disque) et de la transmettre au client pour affichage.

## II. Etat de l'art

OS.tral.OP s'inscrit dans la démarche *low code*. Les plateformes *low code* permettent la production d'applicatifs en minimisant l'effort de codage grâce à un environnement de développement visuel. La plupart sont accessibles sous forme d'abonnement et nécessitent donc des budgets de départ relativement élevés. Elles s'exécutent de façon centralisée dans le cloud, en utilisant le plus souvent des technologies propriétaires. OS.tral.OP a un champ d'application plus petit, celui-ci se limitant à la simplification du code des interfaces. OS.tral.OP ne modifie pas en revanche le schéma classique client-serveur et ne nécessite que l'intégration de l'élévateur OS.tral.OP dans l'architecture.

De nombreux travaux de (dé)composition d'interfaces se basent sur l'ingénierie dirigée par les modèles (MDE), UsiXML en particulier. Cette approche basée sur XML vise à la réalisation d'interfaces multimodales (contrôle par différents canaux: voix, saisie sur l'écran ou autres périphériques) multi-plateformes et multi-utilisateurs. Les spécifications UsiXML représentent l'interface à différents stades, chaque stade étant formalisé par un modèle XML, l'empilement de modèles allant de la simple représentation des tâches jusqu'à la description

d'une interface concrète. Des opérations de transformation, au cas par cas pour partie, permettent de passer d'un stade à un autre [pit14] ou de transformer une pile en une autre [lep07]. Comparé aux piles MDE capables de capter des besoins très variés allant des interfaces tangibles (TUI) [coy10] aux interfaces distribuées (DUI) [van10], le périmètre d'application d'OS.tral.OP se limite à la composition de boutons, de labels et de champs de saisie pour un utilisateur. Contrairement à UsiXML qui utilise des modèles explicites et un outillage spécifique pour les transformations, OS.tral.OP se base sur un modèle logique implicite (représentation d'arborescence dans le système de fichiers) et sur le gestionnaire de fichiers pour représenter graphiquement l'interface non élevé. Seul le passage à la représentation en mode élevé nécessite un outil spécifique (l'élévateur OS.tral.OP). Ces trois niveaux (logique, non élevé et élevé) forment la pile OS.tral.OP. Les opérations de transformation à un niveau, comme le déplacement d'un répertoire, sont automatiquement reflétées aux autres étages de la pile. Chaque niveau de représentation est également accessible lors de l'exécution.

* La représentation logique est manipulée par le développeur (via l'API de fichier par exemple) pour matérialiser l'application.

* La vue arborescente dans l'explorateur ou l'élévateur est utilisée par le testeur pour tester le back-end.

* L'affichage en mode élevé est utilisé par l'utilisateur final pour customiser son front-end.

OS.tral.OP diverge également des approches d'ingénierie à base de composants (CBSE) [mes10]. [law10] propose dans ce cadre une plateforme permettant d'abstraire des composants développés sous différentes technologies et de les assembler en cours d'exécution. Ces démarches basées sur l'envoi de messages se rapprochent davantage de la composition et de la collaboration que de l'hybridation. OS.tral.OP utilise pour sa part les propriétés plastiques de son système d'interface pour fusionner les front-end et y faire circuler la matière avec un niveau de granularité atteignant le sous-éléments d'interface.

D'autres différences peuvent être observées avec les toolkits pour DUI (Distributed User Interface) [mel09], ces boîtes à outils offrant une gamme très riche de contrôles graphiques. Une DUI suppose une application donc un ensemble de tâches, donc des contrôles d'interface dédiés. L'application Pictionary, par exemple, présuppose une zone de dessin et une horloge. La variabilité du système n'intervient pas tant dans le type des composants impliqués que dans la modalité (exemple: horloge vocale ou digitale) et le nombre d'utilisateurs. La
DUI obéit donc à un schéma préétabli permettant
au développeur de hard coder dans l'interface les
ancres capables d'accueillir les éléments distribués
d'UI créant la variabilité [mel09]. OS.tral.OP est
manipulé par l'utilisateur et conçu pour fonctionner
sans schéma préétabli. OS.tral.OP exclut le hard
coding car il doit offrir en cours d'exécution la
latitude nécessaire aux utilisateurs pour poser
leur portails où et vers quoi bon leur semble.
Les toolkits de DUI permettent en revanche une
circulation de données plus complexe permettant la
mise en oeuvre d'interactions multi-points entre les
utilisateurs. Cet aspect tranche avec OS.tral.OP
qui est d'avantage adapté pour transformer des
données le long d'un chemin linéaire comme dans
le cas de Lucy.

Plus spécifiquement dans le domaine de la
manipulation des données, de nouveaux framework
graphiques sont apparus pour implémenter des
interfaces au dessus de services d'IA. Gradio
[abi19] et Streamlit [kho22] figurent parmi les plus
populaires. Ces deux frameworks, basés sur le
language python, permettent de développer dans le
même fichier le front-end et le back-end. Ces outils
sont centrés sur l'accessibilité via la dissimulation
du code HTML et javascript derrière python et sur
la notion de partage via le cloud, le code pouvant
être aisément transféré sur serveur distant.

Sous Gradio, le fichier python déclare l'assemblage
de composants constituant le code client. A chaque
groupe de composants est associé un code serveur
c'est à dire une fonction à appeler (ie fonction de
callback) et à exécuter côté back-end suite à une
action utilisateur sur ce groupe. Seul le résultat
est retourné à l'interface qui se charge de l'afficher.

Streamlit fonctionne à l'inverse. Sa philosophie est
de transformer n'importe quel code python de data
scientists en application web. La transformation
d'un code classique se fait en modifiant les
fonctions d'entrée-sortie originalement redirigées
vers l'interface en ligne de commande. Lorsque
les fonctions d'entrée sortie sont modifiées par
leur équivalent Streamlit, la saisie et l'affichage
des entrées et des sorties sont déportés dans
le navigateur web. Sous Streamlit, l'exécution
conserve donc sa nature séquentielle et ne se
base pas sur le modèle traditionnel de callback
comme pour Gradio. Pour ce faire, Streamlit
ouvre une connexion HTTP de type wsocket à
l'initialisation. Lorsqu'une interaction est détectée
avec un composant, le serveur qui est notifié via
la wsocket, réexécute la totalité du script puis
envoie sur la wsocket le code pour repeindre toute
l'interface.

L'utilisation d'un fichier de code unique pour
le client et le serveur facilite la prise en main
de ces frameworks mais limite les capacités de

navigation entre les pages de l'interface. Gradio se
restreint à ce titre au développement d'applications
mono-page. L'assemblage des composants autorise
toutefois la présence d'onglets pour simuler un
comportement multi-page. Les nouvelles versions
de Streamlit permettent, en comparaison, la
navigation multi-page mais de façon guidée via
une barre de navigation latérale. L'utilisateur
peut interagir avec la liste de liens présente sur
cette barre pour naviguer et exécuter les scripts se
rapportant à chacune de ces pages.

A l'opposé de Gradio et Streamlit, la navigation est une fonction centrale d'OS.tral.OP puisque celle-ci permet de se déplacer dans l'arborescence de fichiers et donc entre différents écrans. Gradio et Streamlit ne sont également pas construits, contrairement à OS.tral.OP, autour de la reconfigurabilité et du mixage en temps réel d'interfaces.

Concernant la connectivité des services, Zapier et IFTTT figurent parmi les plateformes TAP (Trigger Action Platform) les plus populaires pour faire interagir des services distants et ainsi automatiser certaines tâches. Ces deux systèmes développés dans le cadre de l'internet des objets (IoT) proposent des interfaces web pour connecter les inputs de services avec les outputs d'autres. Une fois la configuration établie dans le navigateur, le workflow est sauvegardé dans le cloud sous forme de Zap (Zapier) ou d'Applet (IFTTT). Un message provenant d'un input est relayé sur l'output lorsque la condition saisie par l'utilisateur est réalisée. La plateforme open-source Node-RED [hea14] ajoute la possibilité d'exécution en local. Contrairement à la connectique d'OS.tral.OP qui est modifiable en cours d'exécution dans le client, la configuration des TAP étant scellée sur serveur, ces solutions peuvent se défaire des contraintes de développement dans le client, en particulier dans le browser (sécurité sur les connexions secondaires et performances). Elles ne proposent pas en revanche de point de reprise permettant à un humain d'interagir et contrôler le système en temps réel, la seule interaction possible dans le navigateur étant la mise en marche ou en veille du workflow.

Dans la catégorie connectivité spécialisée dans
l'IA, citons les frameworks de déploiement de
LLMs (Large Language Models). Leur surcouche
graphique, comme Open Web UI pour le framework
Ollama, offre à l'utilisateur des interfaces sous
forme de Chat. Celles-ci constituent des point
d'échange particulièrement adaptée pour faire
communiquer les LLMs installés en local. Les
capacités de communication des GUI IA évoluent
aujourd'hui via des plugins permettant l'intégration
de services distants de tout type (LLM, BD, API
REST, etc.) moyennant l'ajout de code Python.
Au delà de la richesse et de la technicité de ces
outils, trois points de comparaison permettent de différentier OS.tral.OP d'une GUI sous forme de Chat.

En termes d'apparence d'abord, le Chat affiche le flot de données sous forme verticale, ceci n'étant pas modifiable. La fenêtre de Chat vient également avec des entêtes et menus d'administration non personnalisables.

Du point de vue architectural, les plugins d'intégration<fnref n="1" /> sont essentiellement basés sur le développement et la centralisation du code dans le système de surcouche graphique alors que l'interfaçage est sous la responsabilité des agents sous OS.tral.OP.

Sur le plan philosophique enfin, les systèmes de Chat ont, comme leur nom le suggère, une appétence au contrôle par la voix. Dans ce cadre de fonctionnement, un opérateur modifierait un flux audio ou vidéo par la parole, laissant ainsi à l'IA une certaine latitude dans l'exécution. OS.tral.OP privilégie une approche industrielle contrôlée, l'objectif étant d'enrichir l'interface avec une pallette d'outils adaptée à la transformation de chaque type de donnée. Ces outils seraient alors à même de garantir un niveau minimal d'expertise humaine dans la production.

## III. Architecture OS.tral.OP

OS.tral.OP est développé comme un service web. Il possède deux modes d'exécution.

Le mode desktop permet d'utiliser OS.tral.OP à la manière d'un explorateur conventionnel. Cette technique n'est pas unique à OS.tral.OP. De nombreux programmes sont développés en langage web mais revêtent la forme d'applications desktop. Ceci est utile pour développer des applications indépendantes<fnref n="2" /> de l'OS et opérable sur tout type de hardware. Le serveur web est camouflé dans un fichier exécutable. L'explorateur OS.tral.OP s'affiche lorsque son exécutable est lancé. Client et serveur ne forment qu'un bloc et celui-ci est rendu comme une application desktop, sans l'entête de navigation commune aux browsers web. Les ports client et serveur sont utilisés en interne pour transférer la matière, mais ceux-ci sont invisibles à l'utilisateur. Les agents des austral.Apps résidant sur la machine sont connectés au serveur. Lorsque l'utilisateur navigue dans l'arborescence, OS.tral.OP détermine si le répertoire courant est contrôlé par une austral.App. Dans le cas positif, il peut s'agir de matière stockée sur fichier voire émulée en base de données (BD). OS.tral.OP délègue dans ce cas l'extraction de la matière à l'agent. Dans le cas négatif, il s'agit d'une

arborescence standard de fichiers. OS.tral.OP l'extrait lui-même et l'affiche dans sa fenêtre.

<figure><img src="image_3.png" /><figcaption>Figure 1: Architecture client-serveur</figcaption></figure>

En mode web, client et serveur ne s'exécutent généralement pas sur la même machine. Le serveur est donc lancé indépendamment et le front-end s'exécute dans le browser. Le mode web permet le téléportage d'une endo.App dans le navigateur via la saisie son URL internet. Un ou plusieurs agents peuvent être connectés localement au serveur OS.tral.OP.

Contrairement au mode desktop, le serveur ne donne accès qu'à la matière des austral.Apps qui lui sont connectées. L'agent, connecté au serveur, reçoit les notifications de clic sur les boutons. Il lance alors le back-end qui peut mettre à jour l'IHM grâce au procédé de matérialisation. L'agent notifie le serveur des mises à jour de la matière afin de lancer la synchronisation graphique dans le client. Cette dernière étape clos la boucle de synchronisation (cf figure 1).

Quel que soit le mode, l'agent peut s'affranchir du disque dur et stocker de la matière émulée en BD à la place. Chaque utilisateur peut ainsi disposer d'une IHM personnalisée. Le choix du support de stockage de la matière sort du périmètre d'OS.tral.OP, ce choix étant du ressort de l'agent. Contrairement aux explorateurs traditionnels qui ne voient pas la matière émulée, celle-ci s'affiche dans OS.tral.OP car le client la reçoit via la boucle de synchronisation.

Au niveau du client, l'arborescence de l'IHM est émulée en mémoire dans les deux modes. Les modifications opérées sur les données virtualisées dans le client sont automatiquement propagées au serveur. Ce procédé est classique en programmation web où serveur et client synchronisent leurs données, à la différence près que cette synchronisation est ici prise en charge

<footnote n="1">¹Cf l'API Pipelines de Open Web UI</footnote>

<footnote n="2">²Fraweworks tauri (https://tauri.app) et electron (https://www.electronjs.org)</footnote>
par le framework.

Modes web et desktop possèdent tout deux une version dégradée, court-circuitant la boucle de synchronisation, et permettant de prototyper rapidement des applications. Dans ce cas, l'agent n'est pas directement connecté au serveur et fonctionne en mode autonome. Il n'est pas directement notifié par le serveur mais utilise le disque comme tampon d'échange à la place. Dans ce cadre de fonctionnement, l'agent, déduit les interactions dans l'IHM en observant les changements du tampon (suppression de fichier .oto). Cette interaction peut être initiée par :

* un explorateur de fichier conventionnel au moyen de la fonction classique de suppression de fichier. L'utilisateur ne bénéfice pas bien sûr dans ce cas du service d'élévation, l'IHM apparaissant dans l'explorateur comme une simple liste indentée de fichiers.

* l'élévateur OS.tral.OP: Le serveur ne notifie pas l'agent directement. A la place, le serveur qui reçoit du client une notification de clic d'un bouton .oto supprime le fichier associé.

Une fois l'interaction détectée, l'agent lance la tâche de back-end associée, celle-ci réactualisant le disque au besoin.

## IV. L'explorateur OS.tral.OP

Lorsqu'une austral APP est visualisée dans un explorateur de fichier conventionnel, les contrôles graphiques s'affichent de façon standard sous la forme d'une liste indentée de fichiers.

C'est aussi le cas lorsque l'austral. APP s'affiche dans un explorateur de fichiers OS.tral.OP alors que l'elevation est désactivée. Une austral. APP ne s'affiche en mode graphique que lorsque l'utilisateur active le mode d'élévation dans l'explorateur.

<figure><img src="image_4.png" /><figcaption>Figure 2: Architecture du client OS.tral.OP</figcaption></figure>

### 4.1. Strates sous-jacentes

L'explorateur OS.tral.OP nécessite, pour dépasser les limites de l'affichage arborescent commun aux explorateurs de fichiers, l'intégration de jeux de fonctionnalités additionnels, appelées *strates* (cf figure 2). Le niveau de strate implémenté par un explorateur mesure la facilité de celui-ci à évoluer vers un élévateur OS.tral.OP. Cinq niveaux de strates sont définis.

**La première strate** correspond aux fonctions de base de l'explorateur c'est à dire à la navigation dans l'arborescence de fichiers et à son affichage sous forme de liste indentée.

**La seconde strate** regroupe les concepts relatifs à l'affichage élevé de la matière. Elle inclut :

* les *filtres de recherche*, couramment employés dans les environnements de développement intégré (IDE) pour cacher les fichiers et répertoires inutiles. Ceux-ci permettent de créer des vues de l'arborescence.

* la *customisation*, qui se base sur les règles CSS (Cascading Style Sheet). Celles-ci permettent de personnaliser l'affichage de façon plus poussée que le theming et le changement d'icône proposés dans les explorateurs classiques.

* la *compartimentation* (ou *enclosure layout*) [joh91] qui est la fonction centrale de la strate. Elle permet à l'utilisateur de redisposer le contenu à souhait. Elle se rapproche de l'affichage en grille des explorateurs de fichiers mais la taille et la position des éléments de cette grille sont personnalisables. L'utilisateur redispose le contenu d'un répertoire selon une grille responsive [mar10] via drag & drop. La figure 3 montre à ce titre comment les répertoires *B* et *C* apparaissent sous forme de boîtes (au lieu d'icône et de nom de fichier) et comment celles-ci peuvent être redisposés pour occuper tout ou partie de l'espace du répertoire parent *A*.

<figure><img src="image_5.png" /><figcaption>Figure 3: Mapping d'une arborescence de fichiers (1) vers un affichage en liste indentée (2) ou compartimenté (3)</figcaption></figure>
* la dualité c'est à dire la capacité à visualiser, non pas les metadata d'un fichier ou d'un répertoire (exemple nom ou icône), mais son contenu directement dans la fenêtre.

Pour un fichier, l'affichage dual se rapproche du panneau de prévisualisation de fichier existant dans certains explorateurs alternatifs mais avec en plus des possibilités d'édition. Il s'applique aux types simples comme les fichiers .txt pour les élever en champs de saisie.

Pour un répertoire, l'affichage dual (encore appelé *see-through*) permet d'imbriquer l'enclosure layout d'un répertoire dans un autre. En mode normal, le contenu d'un répertoire ne s'affiche que lorsque l'utilisateur entre dedans à l'aide de clic. Le mode *see-through* laisse transparaître l'intérieur d'un répertoire (cf figure 4). Ce contenu est affiché dans l'espace alloué au répertoire via un système de miniaturisation. Un répertoire en mode *see-through* ne peut pas être exploré. Un clic dessus ne change donc pas le répertoire courant et ne rafraîchit pas la page.

<figure><img src="image_6.png" /><figcaption>**Figure 4:** Répertoire *B* en mode *see-through*: son contenu, *D* et *E*, est directement visible dans *A*</figcaption></figure>

La troisième strate inclut la fonction d'attraction qui intervient dans la boucle de synchronisation.

* L'attraction permet à un agent d'attirer de la matière à lui. Le filtre d'attraction spécifie (i) les fichiers à associer aux boutons .oto et à transférer à l'agent et (ii) la nature de cette liste de fichiers. Par défaut tous les fichiers portant le même nom de base que le fichier .oto lui sont associés et tous les fichiers au format primitif (.txt, .jpg, etc.) sont marqués avec le type donnée. Le rôle de l'attraction ne se limite donc pas à transmettre des notifications. Les données servant d'input aux tâches de backend peuvent également être relayées. Dualité et attraction fonctionnent bien en combo, la dualité permettant la modification en ligne des données liées à un bouton .oto et l'attraction assurant leur transmission au serveur après clic.

La quatrième strate fournit les traits avancés d'OS.tral.OP à savoir la portation d'exo.Apps et la téléportation d'endo.Apps.

* La téléportation permet de charger la matière

d'une endo.App dans une interface web. Comme le montre la figure 5, client et serveur maintiennent une seule et même arborescence de fichiers. L'arborescence est initialement transférée du serveur au client. Les opérations de modification de l'arborescence au niveau du client sont par la suite reflétées au niveau du serveur afin de maintenir des vues identiques de part et d'autre du lien. Comme le porte son nom, le mode desktop permet la réalisation d'application desktop, c'est à dire fonctionnant en local. La téléportation permet de projeter ces applications locales sur internet. Elle nécessite un navigateur internet et fait office pour cette raison de fonction exclusive au mode web.

<figure><img src="image_7.png" /><figcaption>**Figure 5:** Téléportation d'interface sur le web</figcaption></figure>

* La portation permet d'ouvrir des portails inter-applicatifs dans la matière entre une endo et une exo APP. Ce trait découle de la capacité :

- d'une endo.App à créer dans son arborescence un répertoire hôte (portail) en mode *see-through* pour afficher à l'intérieur d'elle-même le contenu de l'autre côté du portail.

- d'une exo.App, à (i) se connecter par lien à un portail pour y projeter des parties de son interface, (ii) exploiter l'attraction pour transmettre à son agent l'ensemble des données nécessaires au traitement de l'action liée à un clic sur un de ses boutons .oto.

La figure 6 montre un transfert d'IHM par lien symbolique. Un portail en mode *see-through* est ouvert au niveau de la racine *A* d'une endo.App.

<figure><img src="image_8.png" /><figcaption>**Figure 6:** Portation d'interface via lien symbolique</figcaption></figure>
Le répertoire `e` de l'exo APP étant connecté par lien au portail de l'endo APP, les répertoires d'IHM fils d'e (α et β) deviennent visibles dans la racine de l'endo APP. L'exo APP utilise ensuite l'attraction pour attirer à elle la matière de l'endo APP de l'autre côté du portail.

La portation fichier utilise un lien symbolique pour créer une imbrication de matière sur le disque. La portation web crée, comme la portation fichier, un tunnel entre deux APPs mais importe la matière provenant d'une URL à la place. La portation web est réalisée dans le client donc opère sur la matière émulée contrairement à la portation fichier. Ces deux variantes sont compatibles avec les modes desktop et web.

**La cinquième strate** inclut les fonctions fournissant des espaces de visualisation additionnels.

* **le double volet** : Cet espace d'affichage est utilisé dans les explorateurs conventionnels pour comparer des répertoires ou copier des fichiers entre deux répertoires. Le double volet est optionnel pour OS.tral.OP car OS.tral.OP possède déjà des fonctions avancées de compartimentation de l'espace. Toutefois le double volet est pertinent pour comparer en mode debug une arborescence avant et après élévation ou pour déplacer en temps réel des arborescences d'interface d'un répertoire à un autre.

* **les onglets** : l'ouverture d'un répertoire change le chemin dans la barre d'adresse de l'explorateur, donc le chemin courant en mode élevé. Plutôt que d'afficher ce chemin, dans le même onglet, OS.tral.OP permet d'ouvrir un nouvel onglet et de basculer automatiquement dessus. Les onglets permettent également d'afficher plusieurs austral.Apps dans des espaces séparés. Ce comportement est similaire à la navigation par onglet sur le web.

## 4.2. Niveaux de service

OS.tral.OP définit trois niveaux de service.

Le niveau 0 implémente la première strate. Il simule le comportement traditionnel des explorateurs, c'est à dire l'absence d'élévation.

Le niveau 1 s'appuie sur les strates 2 et 3 pour offrir un affichage non linéaire de la matière.

Le niveau 2 utilise la quatrième strate pour fournir les services de portation et téléportation.

<table><thead><tr><th rowspan="2"></th><th colspan="5">Strates implémentées</th><th rowspan="2">Niveau de service</th><th rowspan="2">Open source</th><th rowspan="2">OS / DE</th><th rowspan="2">Librairie graphique</th></tr><tr><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th></tr></thead><tbody><tr><td>Win Explorer</td><td>✓</td><td>X</td><td>X</td><td>X</td><td>✓</td><td>Aucun</td><td>X</td><td>Windows</td><td>WinUI</td></tr><tr><td>Files</td><td>✓</td><td>X</td><td>X</td><td>X</td><td>✓</td><td>Aucun</td><td>✓</td><td>Windows</td><td>WinUI</td></tr><tr><td>Nautilus</td><td>✓</td><td>X</td><td>X</td><td>X</td><td>✓</td><td>Aucun</td><td>✓</td><td>Gnome*</td><td>GTK</td></tr><tr><td>Nemo</td><td>✓</td><td>X</td><td>X</td><td>X</td><td>✓</td><td>Aucun</td><td>✓</td><td>Cinnamon*</td><td>GTK</td></tr><tr><td>Dolphin</td><td>✓</td><td>X</td><td>X</td><td>X</td><td>✓</td><td>Aucun</td><td>✓</td><td>KDE*</td><td>QT</td></tr><tr><td>XFE</td><td>✓</td><td>X</td><td>X</td><td>X</td><td>✓</td><td>Aucun</td><td>✓</td><td>Linux</td><td>FOX</td></tr></tbody></table>

<caption>**Figure 7:** Comparaison d'explorateurs de fichiers</caption>

Au delà du support des protocoles d'accès aux données, le développement des gestionnaires de fichiers se concentre sur la personnalisation (lancement rapide de commandes) et l'adaptation à l'environnement desktop (DE). La variété de gestionnaires sous Linux découle de la profusion de DE et donc de librairies graphiques [pop14]. OS.tral.OP se base pour sa part sur HTML pour limiter ses dépendances logicielles.

## 4.3. Exemple d'utilisation

La figure 8 présente une suite d'opérations type pour élever une interface primitive.

Initialement, l'explorateur présente les fichiers sous la forme classique d'une liste détaillée. Quatre fichiers sont présents, les trois principaux étant un fichier .oto, un fichier .txt et un fichier .jpg (de bas en haut sur le premier écran de la figure 8).

L'utilisateur active (i) le bouton compartimentation dans l'entête de l'explorateur pour basculer en mode élévation et (ii) le mode édition afin de pouvoir éditer l'interface (étape ①). En mode édition, un clic sur un élément permet de le saisir avec la souris sans déclencher d'opération<fnref n="3" />.

Via ce mode, l'utilisateur place le fichier .txt à droite sur la grille responsive (étape ②) et redimensionne les icônes des fichiers .txt, .jpg et .oto pour leur donner les tailles respectives d'un champ de saisie, d'un panneau de visualisation d'image et d'un bouton (étape ③).

L'utilisateur utilise la dualité à l'étape ④ sur :

* le fichier texte pour transformer son icône en champ de saisie. Dès lors, c'est le contenu du fichier qui s'affiche et celui-ci peut être modifié en éditant ce champ.

* le fichier image pour transformer son icône en panneau de visualisation. L'image du fichier est alors directement visualisable dans le panneau.

Le filtrage réalisée via les filtres de recherche à l'étape ⑤ permet de simplifier l'interface en

<footnote n="1">¹Onglet uniquement</footnote>

<footnote n="2">²Prévisualisation des fichiers disponible mais pas d'édition</footnote>

<footnote n="3">³Personnalisation possible mais sans évaluation dynamique de type CSS</footnote>

<footnote n="4">⁴Éditeur texte dans une fenêtre séparée</footnote>

<footnote n="5">⁵Volets multiples uniquement</footnote>

<footnote>*Linux Desktop Environment</footnote>

<footnote n="3">³Une opération correspond au lancement de l'action associée à un bouton dans le cas d'un clic sur un fichier .oto ou à l'entrée dans un répertoire dans le cas d'un clic sur un dossier</footnote>
<figure><img src="image_9.png" /><figcaption>Figure 8: Exemple d'élévation d'une interface primitive en interface graphique</figcaption></figure>

cachant le quatrième fichier qui n'est pas utile à l'affichage.

L'utilisateur utilise à l'étape ⑥ la *customisation CSS* pour donner au bouton .oto son aspect définitif.

L'utilisateur active enfin à l'étape ⑦ le *double panneau* pour comparer son interface avant et après élévation.

# V. Principes cadre

Temps, espace et matière forment le triptyque d'OS.tral.OP, la matière évoluant dans l'espace temps.

## 5.1. Temporalité

La mise au point d'un logiciel distingue généralement 3 temps. Il existe un avant et un après compilation et un avant et un après exécution. Le cycle de vie d'une APP desktop est révelateur des moyens mis en oeuvre par OS.tral.OP pour neutraliser ces bouleversements.

L'agent d'une APP (ainsi que ceux des *exo.Apps* connectées par portail) est lancé quand l'utilisateur entre depuis l'explorateur dans le répertoire de l'APP. La matière qui arrive au client est interprétée au fil de l'eau pour afficher l'IHM. Un bouton est prévu pour quitter. OS.tral.OP place un utilisateur qui quitte une APP dans le répertoire parent de celle-ci, ferme son agent, ainsi que ceux des *exo.Apps* liées.

OS.tral.OP propose par défaut une option pour

activer la persistence de l'arborescence de matière affichée dans l'IHM. En cas d'activation de l'option, le système force la persistence sur disque. L'IHM reste alors visionnable même en cas d'arrêt du back-end. Cette forme de vie après la mort, ou de présence avant la vie selon le point de vue, amène une continuité entre l'avant et l'après éxécution. Il en découle :

1. Une remise au dernier état après re-rentrée

2. L'absence de perte de données en cas de panne de back-end

3. Une continuité d'accès aux données après les redémarrages en mode sans échec de l'OS

4. La résistance de la boucle de synchronisation principale à l'arrêt d'une *exo.App*

5. La résistance en mode desktop de la boucle de synchronisation d'une *exo.App* à l'arrêt de son *endo.App*

6. La fourniture d'un service de persistence minimal en mode web

Il n'existe également pas pour le front-end de points de rupture liés à la compilation, les IHM n'étant pas compilées mais interprétées au fil de l'eau.

## 5.2. Spatialité

Le concept de productivité desktop repose sur l'exécution simultanée d'applications s'affichant chacune dans un espace séparé. Le transfert de données entre applications nécessite le copier-coller d'une fenêtre à l'autre, le passage par la sauvegarde et le chargement dans des fichiers intermédiaires ou l'ouverture de ports de communication.
Sous OS.tral.OP, données et contrôles sont intimement liés car placés au même niveau dans la matière. Les contrôles graphiques constituent en cela des balises visuelles d'entrée dans la matière permettant coup sur coup à l'utilisateur :

1. d'ouvrir la matière grâce au double volet

2. d'implanter sur la zone cible un portail inter-applicatif

3. et d'y faire entrer des exo APP

La proximité entre contrôles et données dans l'arborescence permet à ces exo APP :

1. d'ausculter la matière en périphérie du portail

2. d'identifier automatiquement les interactions possibles avec les données

3. et d'associer ces données à leurs contrôles pour les transmettre à leur agent

Ce système d'**aller-retour** entre contrôles et données dans la matière permet en fine la mise en place d'un **continuum graphique** entre les espaces applicatifs de back-ends cloisonnés.

## 5.3. Matérialité

Sous OS.tral.OP, les contrôles graphiques sont générés à partir des données initiales.

Dans le cas de l'application Lucy où un contenu visuel est retranscrit sous forme voix, la matière est créée à partir de la donnée initiale c'est à dire de l'ensemble des images récupérées sur le serveur. Le code de matérialisation crée un répertoire pour chaque image et y place dans chacun l'image en question. L'image est accompagnée dans son répertoire de deux fichiers, le premier étant le bouton .oto. déclenchant la transformation de l'image en description texte et le second étant un fichier texte vide destiné à accueillir la description de l'image.

Ce premier aller, des données vers l'interface, permet d'établir l'enveloppe physique d'une austral APP. Cette étape est nécessaire et préalable avant toute connexion à un autre espace applicatif, car cette enveloppe constitue la base sur laquelle les portails viennent se greffer.

La génération de matière s'apparente au principe de scaffolding selon lequel certains systèmes REST échafaudent leur interface à partir de la spécification des données. La différence est que sous OS.tral.OP, l'interface n'est pas représentée sous forme HTML mais comme une arborescence de fichiers et que la construction de cette IHM primitive n'est pas automatisée mais sous la responsabilité du développeur. Sous OS.tral.OP, le scaffolding initial peut être initié par un bouton .oto ou lancé automatiquement lors de la détection de nouvelles données.

# VI. Finalité

## 6.1. Le réseau OS.tral.OP

L'essor foudroyant de l'intelligence générative [dur24] pose sur la table les questions de la place de l'Homme dans le développement et de la centralisation des logiciels dans le cloud au profit d'acteurs privés. Le partage de fonctions entre interfaces sous OS.tral.OP encourage le développement d'applications éprouvées par la communauté open source et la mise en libre accès des opérations métiers essentielles. Cette vision maillée et réutilisable du logiciel offre le moyen de canaliser l'intelligence artificielle de façon rationelle.

L'intelligence générative et OS.tral.OP ont pour eux deux, la particularité de se baser sur des données (input et output) primitives (texte, voix, vidéo), ceci autorisant un fonctionnement en tandem. OS.tral.OP peut en ce sens :

* décharger le logiciel de la complexité des interfaces, ceci permettant à l'Homme de se concentrer sur le métier

* contrôler le routage des données pour répartir les accès aux services d'IA et ne pas dépendre de fournisseurs privés uniques

* éliminer le code non essentiel en déléguant certains traitements aux back-ends connectés sur le réseau austral

Les back-ends de la communauté OS.tral.OP, c'est à dire implémentant un flux de matière australe, offrent aux développeurs des IHM directement intégrables et modulables dans leur logiciel. Dans le cas de l'intégration de plusieurs back-ends, l'IHM OS.tral.OP se comporte comme un pont permettant l'intégration de plusieurs services directement dans le navigateur.

## 6.2. Modèles de connectivité

OS.tral.OP propose trois types de connectique.

### Hybridation locale

L'hybridation locale utilise la portation en mode desktop. Elle permet à l'utilisateur d'hybrider ses applications desktop.

L'utilisateur commence par saisir dans l'explorateur le chemin de l'endo APP sur son disque. Il crée ensuite un lien (via portation fichier ou web) dans le répertoire de l'endo APP pour accueillir la matière d'une exo APP. Une fois le lien mis en place, les agents récupèrent les données des IHM au fil des interactions de l'utilisateur avec les boutons .oto.
## Hybridation distante

L'hybridation distante est le fruit de la **téléportation** d'une *endo APP* suivie de la **portation web** d'une *exo APP* en mode web. Elle crée dans l'élévateur un noeud de communication entre deux services web.

La **téléportation** est initiée en saisissant l'URL (Uniform Resource Locator) d'une *endo APP* distante dans le navigateur web.

La **portation** est ensuite réalisée en :

1. créant un répertoire *B* (portail) dans le répertoire courant *A* de l'*endo APP*

2. puis en associant à *B* l'URL d'une *exo APP*. L'*exo APP* peut alors déverser sa matière à l'intérieur de l'*endo APP*. L'intégration ou non de l'élévateur OS.tral.OP dans le serveur de l'*exo APP* dépend de la complexité de la matière à transférer (simple bouton ou arborescence complète). Dans le cas d'un simple bouton le serveur peut simplement émuler une partie du protocole de transfert de matière, ce qui limite la modification du serveur à une simple extension de son API REST.

L'hybridation distante permet par exemple :

* à une organisation privée d'augmenter un service web publique (téléporté dans le navigateur via téléportation) avec ses services propriétaires (phase de portation),

* à un utilisateur lambda de mixer deux services web publiques.

Ce modèle d'hybridation n'utilise qu'un onglet du navigateur mais peut recourir à plusieurs portations pour connecter plus de deux services.

## Chimérisation

La *chimérisation* constitue le niveau ultime de plasticité offert par OS.tral.OP. Contrairement à l'*hybridation distante*, la *chimérisation* utilise plusieurs onglets.

1. Les différents onglets sont chacun chargés avec une *endo APP* (phase de téléportation).

2. Ces onglets sont ensuite fusionnés dans un onglet additionnel où chaque *endo APP* est représentée par un répertoire distinct, à la manière d'un 'drive' dans le répertoire virtuel 'Ce PC' de l'explorateur Windows.

3. L'utilisateur peut alors croiser les arborescences des différents 'drives' pour construire en temps réel dans le navigateur sa propre interface à partir de celles des *endo APP* de départ.

# VII. Lucy

Notre but est de fournir à notre application Lucy la possibilité de décrire par la voix les figures contenues dans le manifeste OS.tral.OP.

## 7.1. Choix de conception

Deux solutions se présentent :

a. utiliser un service d'IA propriétaire dans le cloud. Ces systèmes ont l'avantage de fournir des résultats hautement qualitatifs. Ceci se fait toutefois au détriment du coût de mise en oeuvre, des contraintes de confidentialité et de la flexibilité.

b. exécuter en local des services IA open source. Ces systèmes plus rudimentaires possèdent moins de fonctionnalités. Il revient à l'utilisateur de gérer toute la chaîne de transformation des données: image en texte puis texte en voix. Cette solution à toutefois l'avantage du coût, de la flexibilité et de la sécurité. C'est celle-ci que nous choisissons.

Le contrôle d'une IA est une tâche fastidieuse. Dans l'exemple d'un serveur transformant le texte en voix, Text-To-Speech ou TTS, basé sur l'IA, il est souvent nécessaire de changer la ponctuation ou l'orthographe du prompt, voire de le découper en petits bouts pour obtenir un résultat optimal. A cela s'ajoute le fait que le même prompt ne génère jamais la même réponse. Il peut ainsi arriver de devoir prompter plusieurs centaines de fois pour atteindre la qualité souhaitée. Ceci est d'autant plus critique quand les données de base évoluent, ce qui est le cas des figures du manifeste qui changent souvent. Chaque changement exige alors de reprendre le workflow de zéro. Ces contraintes d'IA illustrent l'**aspect central de l'IHM** à mettre en place pour contrôler l'IA.

Au niveau du **back-end**, notre solution distingue deux modules.

Le premier télécharge les images du serveur web et génère une transcription pour chacune. Nous utilisons la commande *curl* standard pour le téléchargement des images et le large multimodal model (LLM) *LLaVA* pour générer une description texte à partir d'une image.

Le second transforme la description générée par *LLaVA* en parole. Ceci est réalisé via un serveur TTS propriétaire.

Trois solutions s'offrent à nous pour le **front-end** :

a. implémenter une interface HTML intégrant les deux serveurs d'IA. C'est la solution qui nécessite le plus de code d'interface car il faut à la fois générer les contrôles graphiques et gérer le workflow de données dans le programme. Ce travail génère beaucoup de perte car l'effort de
codage est perdu une fois la mission spécifique de transformation d'image en voix accomplie. Cette démarche toute intégrée de l'IHM fonctionne, en quelque sorte, à rebours du concept de modularité des serveurs IA qui eux présentent un taux de réutilisabilité très élevé.

b. implémenter deux interfaces séparées et gérer le workflow de données nous mêmes. C'est à dire en copiant collant l'output d'un serveur IA dans l'input de l'autre. Cette solution ne répond pas au besoin de productivité exposé plus tôt. Cette solution possède malgré tout l'avantage de la simplicité et de la modularité, chacun des deux serveurs pouvant éventuellement être utilisé dans un autre contexte.

c. utiliser la programmation par élévation. Cette technique présente l'avantage de la simplicité puisqu'il n'y a qu'à générer une arborescence de fichiers, l'explorateur OS.tral.OP se chargeant pour nous de la transformer en interface graphique. Elle présente également l'avantage de la productivité puisque le workflow de données est géré au sein de la même interface. C'est sur ce modèle qu'est construit Lucy.

## 7.2. Mise en oeuvre

Lucy intègre le premier module du back-end, c'est à dire la transformation des images en texte. Nous l'hybridons localement avec Maurice<fnref n="4" />, qui implémente le second module, c'est à dire la partie Text-To-Speech.

Lucy *matérialise* le front-end à partir des images récupérées du serveur. Un répertoire est créé pour chaque image avec dedans l'image en question. Chaque image est accompagnée de trois fichiers:

1. le premier est le bouton `.oto` déclenchant la transformation de l'image en description texte

2. le second est le fichier de description, celui-ci étant vide à l'initialisation.

3. le dernier est un fichier de log également vide à l'initialisation.

Deux images étant présentes sur le serveur au moment de la matérialisation, la matière est générée selon une arborescence (cf la figure 9) à deux niveaux avec 2 répertoires image et 4 fichiers dans chaque répertoire image.

<figure><img src="image_10.png" /><figcaption>**Figure 9:** Exemple de matérialisation par Lucy</figcaption></figure>

La figure 10 montre comment s'affiche le premier niveau de matière dans l'explorateur avant et après élévation. En mode non élevé (en bas sur la figure), la racine de la matière montre simplement ses deux sous-répertoires image. Ces deux répertoires n'étant pas configurés en mode *see-through*, ils s'affichent également en mode élevé de façon classique à la manière de liens web (en haut sur la figure).

<figure><img src="image_11.png" /><figcaption>**Figure 10:** Racine de la matière de Lucy avant et après élévation</figcaption></figure>

Lorsque l'utilisateur clique sur le lien de *Image1*, le contenu de ce répertoire s'affiche dans l'élévateur et peut être mis en forme tel que présenté à l'étape 7 de la figure 8.

La figure 11 montre la structure arborescente de Lucy une fois l'hybridation mise en place sur le répertoire 1.

L'installation du portail consiste à créer un nouveau répertoire dans Lucy et à le lier à Maurice via un lien symbolique. Maurice peut venir alors y matérialiser son interface, c'est à dire son bouton `.oto`. Pour faciliter l'auscultation de la matière à proximité du portail, nous créons également un lien symbolique vers la donnée `.txt` afin que l'agent de Maurice puisse facilement le récupérer au côté dans le tampon de son bouton `.oto` au moment d'un clic. Alternativement, nous pouvons utiliser la boucle de synchronisation pour faire communiquer le front-end et le back-end lors des clics<fnref n="5" />.

<footnote n="4">⁴Maurice Taieb, né à Bizerte (Tunisie), est le fondateur de l'International Afar Research Expedition (IARE) qui en novembre 1974 aboutit à la découverte des fragments fossiles de Lucy. M. Taieb était également présent sur site en Éthiopie au moment de la découverte.</footnote>

<footnote n="5">⁵Cf le mode dégradé présenté à la section III</footnote>
<figure><img src="image_12.png" /><figcaption>**Figure 11:** Hybridation locale Lucy/Maurice</figcaption></figure>

Une fois le répertoire *Image1* élevé et le répertoire du portail passé en mode *see-through*, le bouton de Maurice apparaît au côté des contrôles de Lucy (voir la figure 12).

<figure><img src="image_13.png" /><figcaption>**Figure 12:** Affichage de l'application hybridée</figcaption></figure>

Lucy dispose d'un bouton .oto (voir la figure 9) pour initier la transcription de l'image en texte. Son agent récupère l'image soit en observant les interactions avec ce bouton⁵ soit par l'intermédiaire du service d'attraction d'OS.tral.OP, comme déjà expliqué pour Maurice. L'agent relaie l'image au serveur LLaVA qui renvoie une description en retour. Celle-ci s'affiche dans le champ de saisie texte placé entre les deux boutons (voir la figure 12). La validité de la transcription peut être contrôlée en confrontant le texte avec l'image affichée en dessous dans l'espace de prévisualisation. L'utilisateur peut modifier la ponctuation ou réécrire des mots dans le champ de saisie pour améliorer l'élocution lors de la phase TTS. Cette phase est lancée en cliquant sur le bouton de Maurice.

Le champ de saisie est un point d'échange dans le flux IA. Un point d'échange est un élément essentiel en IA. Il permet à un humain d'interagir avec le flux en le modifiant. Le point d'échange se comporte dans ce dernier cas comme une interface ou un relais entre l'Homme et la machine. Notre IHM composée s'apparente ainsi à un pont intégrant,

entre les deux IA, un point d'échange pour humain.

La matière OS.tral.OP constituant une donnée primitive intelligible, à l'instar du texte de l'audio et de la vidéo, celle-ci peut elle même être échangée entre l'Homme et l'IA. Dans ce cas, l'IA et OS.tral.OP opèrent en tandem. **L'IA est le responsable de la génération de matière et OS.tral.OP celui de l'élévation.** Le double panel de l'élévateur constitue alors, pour ce nouveau flux IA, le point d'échange où l'Homme peut corriger la matière générée par la machine.

Nous représentons le fonctionnement d'OS.tral.OP comme point d'échange entre deux services avec la schématique particulière de la figure 13.

<figure><img src="image_14.png" /><figcaption>**Figure 13:** Représentation symbolique d'une hybridation locale</figcaption></figure>

Le schéma de la figure 13 est relatif à un fonctionnement sur la machine locale. En mode distant, OS.tral.OP utilise les ports réseaux pour étendre son continuum dans l'espace physique. La figure 14 représente, dans un tel cadre, une connexion entre deux services, l'un s'exécutant sur le site de Lucy à Hadar (Ethiopie) et l'autre à Bizerte (Tunisie).

<figure><img src="image_15.png" /><figcaption>**Figure 14:** Représentation symbolique d'une hybridation distante</figcaption></figure>

## Conclusion

Nous avons montré en introduction comment bâtir une interface graphique en se basant sur une structure primitive de fichiers. Nous avons ensuite généralisé ces concepts système au web. Nous avons présenté en sixième partie différents modèles de connectivité permettant de mixer ces interfaces dans une interface unique et de connecter des
services web distants. Cette démarche s’appuyant
sur le fichier pour arriver au réseau offre une
vision englobante sur le futur de systèmes agent
interconnectés utilisant les navigateurs comme pont
et point de contrôle pour les humains.

Cette capacité à croiser les front-ends exige en
contrepartie de nouvelles règles de construction
pour les interfaces, celles-ci n’étant plus
directement présentées en HTML mais sous
forme arborescente. La structure simplissime
de ces interfaces est particulièrement adaptée

pour accueillir des données primitives (texte,
image, audio) comme celles manipulées par les
services d'IA. A la manière des règles de design
responsive, qui ont permis au web de se développer
sur mobile, ces nouvelles contraintes de structure
constituent pour le web un nouveau catalyseur avec
à l'horizon la promesse d'interfaces reconfigurables
et interconnectables.

Cette perspective passe par le développement d'un
nouveau type d'explorateur, l'élévateur OS.tral.OP,
sujet de nos futurs travaux.

Références

[abi19] A. Abid, A. Abdalla, A. Abid, D. Khan, A. Alfozan, and J. Zou. Gradio: Hassle-Free Sharing and Testing of ML Models in the Wild. *ICML Workshop on Human in the Loop Learning (HILL 2019)*, Long Beach, USA, 2019.

[coy10] A. Coyette and J. Vanderdonckt. Prototyping Digital, Physical, and Mixed User Interfaces by Sketching. In *Workshop on User Interface eXtensible Markup Language UsiXML*, France, Paris, 2010.

[dur24] S. Duranton. Are Coders' Jobs At Risk? AI's Impact On The Future Of Programming. *Forbes*, 2024.

[hea14] N. Heath. *How IBM's Node-RED is Hacking Together the Internet of Things*. Techrepublic, 2014.

[joh91] B. Johnson and B. Shneiderman. Tree-Maps: A Space-Filling Approach to the Visualization of Hierarchical Information Structures. *2nd conference on Visualization '91*, pages 284–291, 1991.

[kho22] M. Khorasani, M. Abdou, and J. Hernández Fernández. *Streamlit usecases: From Web Application Development with Streamlit*. Springer, 2022.

[law10] J.-Y. L. Lawson, J. Vanderdonckt, and B. Macq. OpenInterface: A lightweight open source platform for rapid prototyping of multimodal applications. In *Proc. of 1st Int. Workshop on User Interface Extensible Markup Language UsiXML2010*, 2010.

[lep07] S. Lepreux, J. Vanderdonckt, and B. Michotte. Visual design of user interfaces by (de)

composition. In *Interactive Systems. Design, Specification, and Verification: 13th International Workshop, DSVIS 2006, Dublin, Ireland, July 26-28, 2006. Revised Papers 13*, pages 157–170. Springer, 2007.

[mar10] E. Marcotte. Responsive Web Design. *A List Apart*, 2010.

[mel09] J. Melchior, D. Grolaux, J. Vanderdonckt, and P. Van Roy. A toolkit for peer-to-peer distributed user interfaces: concepts, implementation, and applications. In *Proceedings of the 1st ACM SIGCHI symposium on Engineering interactive computing systems*, pages 69–78, 2009.

[mes10] F. Messaoud, S. B. Sassi, and H. B. Ghézala. CBSE and MDE: Approaches Combination Opportunities. In *Software Engineering Research and Practice*, pages 65–71, 2010.

[pit14] A. Pitkänen and S. Hickey. Implementation of model-based user interfaces for pictorial communication systems using UsiXML and Flex. In *Proc. of 1st Int. Workshop on User Interface Extensible Markup Language UsiXML2010*, 2010.

[pop14] D. Popov. A Taste of Mint. *Linux Magazine*, (164), 2014.

[van10] J. Vanderdonckt et al. Distributed user interfaces: how to distribute user interface elements across users, platforms, and environments. *Proc. of XI Interacción*, 20, 2010.