D’une phrase à un widget vivant

X by Nexow transforme une phrase en widget sur un canevas : le graphique d’un marché, le tableau d’un portefeuille, une liste de suivi qui bouge en direct. On imagine souvent que le modèle remplit un gabarit. Ce n’est pas le cas. Il écrit du code.

Le modèle écrit un module

Chaque widget est une petite arborescence de fichiers. Son point d’entrée, index.js, exporte une seule fonction :

export async function render(ctx) { … }

Le modèle le construit comme le ferait un développeur, avec des outils pour écrire, modifier, lire et lister des fichiers. Pendant qu’il écrit, il peut se renseigner : la documentation de référence de chaque connecteur, une sonde qui appelle un vrai endpoint pour voir ce qui revient, et une recherche dans les API publiques.

Le contenu des fichiers arrive en continu pendant que le modèle l’écrit : vous voyez le code apparaître au lieu d’un indicateur de chargement. Diffuser l’entrée d’un outil a un revers : l’API ne la valide plus pour vous. Notre boucle analyse à nouveau chaque appel d’outil, strictement, et renvoie toute entrée tronquée pour que le modèle recommence.

Vérifié avant de tourner

Avant qu’un widget ne soit monté, son code est débarrassé de la prose égarée et des balises markdown, puis passé au linter. Un second agent travaille à côté du premier et revérifie les endpoints dont le widget dépend, avec jusqu’à cinq sondes et une passe de réparation dans le même tour. Une fois le widget monté, un test de fumée cherche un rendu vide ou une boucle qui s’emballe.

Si un widget casse juste après avoir été construit, X le répare une fois, dans les 45 secondes, et s’arrête là. Il ne continuera pas à dépenser vos crédits pour ses propres corrections.

Une boîte dont il ne peut pas sortir

Chaque widget tourne dans sa propre iframe en bac à sable, avec les scripts autorisés et rien d’autre : il reçoit une origine opaque. Une politique de sécurité du contenu bloque les appels vers d’autres hôtes. Tout ce qui vient de l’extérieur, données ou médias, passe par ctx, que l’app récupère pour le compte du widget.

C’est aussi ainsi que les clés restent hors de portée. Le modèle ne voit jamais un identifiant : il voit seulement si une source est connectée, sans clé ou non connectée. Les clés stockées dans le cloud sont chiffrées en AES-GCM, et par défaut les appels passent par des proxys sans état.

Le modèle écrit le code. Il ne tient jamais les clés.

En direct, sans dix connexions

Un widget reste vivant grâce à ctx : historique, abonnements, données de compte, requêtes. Derrière, un hub de données partagé ouvre chaque flux une seule fois, quel que soit le nombre de widgets qui le lisent, et met les flux en pause quand l’onglet est en arrière-plan. Dix graphiques du même marché partagent un seul WebSocket.

Il y a 95 connecteurs aujourd’hui, des plateformes d’échange avec leurs propres flux WebSocket aux sources REST sur une boucle d’interrogation partagée avec temporisation. Deux sont marqués stables. Les autres portent encore un badge bêta dans l’app.