Comment travaille l'agent

Quand tu envoies une demande, l’agent de Highwind se comporte comme un développeur produit et un designer réunis : il lit ton projet, écrit le code, vérifie que tout fonctionne et te résume ce qu’il a fait. Tu vois l’app se construire en direct dans l’aperçu. Cette page explique ce qui se passe pendant ce temps, et avec quelle technologie.

La technologie de ton app

Chaque app créée avec Highwind est un vrai projet web, avec du code standard que tu peux lire, modifier et télécharger.

React et TypeScript

L’interface est écrite en React 19 avec TypeScript strict : chaque composant est typé, les erreurs se voient avant la mise en ligne.

Vite

Le serveur de développement qui fait tourner l’aperçu en direct, et qui construit la version publiée.

Tailwind CSS v4

Tous les styles passent par des classes Tailwind. Les couleurs et les polices vivent dans un thème central.

react-router et lucide

react-router pour les apps à plusieurs écrans, lucide-react pour les icônes. Les deux sont déjà installés.

L’agent n’ajoute une bibliothèque que quand elle est vraiment utile (par exemple recharts pour des graphiques). Il ne crée ni serveur ni base de données tant que ton app n’en a pas besoin : voir Où vont les données.

Organisation des fichiers

Dossier ou fichier	Contenu
`src/App.tsx`	Le composant racine, avec les routes si l’app a plusieurs écrans
`src/pages/`	Une page par écran
`src/components/`	Les composants réutilisés (en-tête, cartes, formulaires…)
`src/lib/`	Les utilitaires (données partagées, hooks, helper `cn()`)
`src/index.css`	Le thème : couleurs, polices, animations
`public/`	Les fichiers servis tels quels, dont tes images dans `public/assets/`
`worker/index.ts`	Le serveur de l’app, seulement s’il en a un (voir Le serveur de l’app)

Tu peux tout consulter et modifier dans l’onglet Code : voir Le code.

Le déroulé d’une demande

L’agent explore. Il parcourt la liste des fichiers et ne lit que ceux dont il a besoin (étape « Parcourt les fichiers » dans le fil). Au début d’une conversation, il reçoit aussi le fichier AGENTS.md du projet ; tes consignes de projet, elles, accompagnent chaque message.
Il écrit le code, de haut en bas. Sur une nouvelle app, il rend d’abord src/App.tsx réel (la mise en page et le premier écran ou la première section), puis ajoute les sections ou les pages une à une, chacune branchée dès que son fichier existe. Résultat : l’aperçu se remplit au fil de l’eau au lieu de rester vide jusqu’à la fin.
Il n’affiche jamais un état cassé. Il n’importe jamais un fichier qui n’existe pas encore : un composant est écrit d’abord, puis utilisé à l’étape suivante.
Il vérifie. Avant de terminer, il lance l’outil check : vérification TypeScript, construction de la version de production, puis lecture des erreurs vues par l’aperçu dans ton navigateur (exceptions, erreurs de console, page blanche). Il corrige chaque erreur et relance check jusqu’à ce que tout passe. check signale aussi les couleurs écrites en dur hors du thème. Dans le fil, tu vois « Vérifié : typecheck, build et aperçu OK » ou « Des erreurs restent à corriger ».
Il résume. Il termine par un court résumé (2 à 4 phrases) de ce qu’il a construit ou changé, dans ta langue, sans coller de code.
Il propose la suite. Sous le résumé, 2 ou 3 suggestions de prochaines étapes propres à ton app. Un clic sur une suggestion l’envoie directement à l’agent.

Quand l’agent te pose des questions

Si quelques réponses changent vraiment ce qu’il doit construire (le nom de ta marque, tes vraies offres et tes prix, tes coordonnées, un choix entre deux directions très différentes), l’agent t’envoie un court formulaire au lieu de deviner, avec ses meilleures hypothèses déjà remplies. Il ne pose jamais de question sur un détail qu’il peut décider seul, et au plus un formulaire par demande. Voir Les questions de l’agent.

Quand ton app doit garder des données et que plusieurs solutions sont possibles, il te présente une carte de choix : voir Où vont les données.

Les apps à plusieurs écrans ont de vraies routes

L’agent donne à ton app la forme du vrai produit que tu demandes. Tout ce qui a plusieurs écrans (un outil, un tableau de bord, un SaaS, un site de plusieurs pages) reçoit de vraies routes avec react-router :

une page par écran dans src/pages/, avec sa propre adresse (/projets, /parametres…) ;
une mise en page commune (en-tête, barre latérale) partagée par toutes les pages ;
une navigation qui fonctionne, avec l’onglet actif mis en évidence ;
des vues de détail avec paramètre (/projets/:id) et une page pour les adresses inconnues.

Une simple landing page reste une seule page, avec des sections et des ancres. Une fois publiée, chaque adresse de ton app s’ouvre directement, même partagée en lien.

Crée un outil de suivi de factures pour freelance : un tableau de bord, une liste
des factures avec une page de détail, une page clients et une page paramètres.

La sandbox

Chaque projet tourne dans son propre environnement isolé, une sandbox, hébergée dans l’Union européenne. Le serveur de développement Vite y tourne déjà : chaque fichier écrit par l’agent apparaît aussitôt dans l’aperçu.

La sandbox d’un projet n’a accès à aucun autre projet.
L’agent y installe les paquets dont il a besoin (add_dependency) et y lance ses vérifications.
Quand tu ne l’utilises plus, l’aperçu se met en veille ; il redémarre quand tu reviens sur le projet. Ton code, lui, est enregistré dans tes versions : rien n’est perdu.

Les conventions du projet (AGENTS.md)

Chaque projet contient un fichier AGENTS.md qui décrit ses conventions. L’agent le reçoit au début de chaque conversation et le suit. On y trouve notamment :

la stack et l’alias @/ pour importer depuis src (@/components/Header) ;
où ranger composants, pages et utilitaires ;
les styles uniquement en classes Tailwind, les couleurs et polices uniquement par leurs rôles du thème ;
le mode sombre par un bloc géré dans src/index.css ;
les règles de navigation (<NavLink> ou <Link>, jamais un lien <a> interne) ;
le titre, la description et les balises de partage à remplir dans index.html ;
le dossier .highwind/, géré par Highwind, auquel il ne faut pas toucher.

Ce que l’agent ne fait jamais

L’agent ne…	Pourquoi
laisse pas de « à faire » ni de code incomplet	Chaque fichier écrit doit fonctionner tel quel
met pas de faux texte (lorem ipsum)	Il écrit un contenu réaliste, adapté à ta demande
écrit pas de couleur en dur dans un composant	Le panneau Thème ne pourrait plus changer le look de l’app
remplace pas une image que tu as fournie	Tes images restent à leur place ; les images générées ont toujours un nom libre
lit ni ne modifie les fichiers de secrets (`.env.local`, `.dev.vars`)	Ils sont gérés par Highwind et cachés à l’agent
te demande pas une clé d’API dans le chat	Il passe par une carte sécurisée (voir Les secrets)
active pas de base de données de lui-même	C’est toi qui décides, avec la carte de choix
supprime ni ne renomme de table ou de colonne	Les migrations destructives sont refusées, pour protéger les données
écrit pas la configuration du serveur ou de la base	Highwind la pose et la maintient pour lui
modifie rien en mode Discussion	Il répond, explique ou propose un plan, sans toucher à l’app (voir Le mode Discussion)

Pour aller plus loin : ce que l’agent reçoit avec ton message

En plus de ton texte, l’agent reçoit selon le cas :

les directions artistiques tirées pour une nouvelle app (voir Design et thème) ;
l’élément sélectionné dans l’aperçu, si tu en as choisi un (voir Sélectionner un élément) ;
tes consignes de projet ;
les images jointes : une image de référence (capture, maquette) qu’il regarde, ou une image du projet qu’il place dans le site ;
la liste des secrets existants (noms seulement) et l’état du backend s’il est actif ;
les sources de contexte connectées à ton compte.

Voir aussi

Bien écrire ses demandesLes formulations qui donnent les meilleurs résultats.

Design et thèmeLes standards de design et le thème par rôles.

Où vont les donnéesÉtat local, serveur ou base de données.

Les versionsChaque réponse de l'agent crée une version restaurable.