EVA Builder

EVA Builder est la machine derrière la page audit : une adresse entre, un audit et un prototype de refonte sortent, à la même URL. Ce n’est pas un générateur de sites. C’est un atelier outillé où la part répétitive du travail (récolter, mesurer, appliquer le système, construire, vérifier) revient à la chaîne, pour que le temps humain aille là où il compte. Le robot qui tourne autour de ses six postes sur la page audit vient de là : c’est le même déroulé, mis en scène.

Un dossier par chantier, et rien d’autre

Tout ce qui concerne un chantier tient dans un dossier : les contenus et les mesures dans un fichier texte, les couleurs et les polices dans un JSON, le prototype en projet Astro. Pas de base de données, pas d’état caché, le dépôt est l’état. Un build reconstruit l’ensemble, et une petite garde à l’entrée vérifie que l’adresse demandée existe vraiment : une référence inconnue rend un 404, jamais la page du voisin. Ce qui protège un lien, c’est son identifiant tiré au hasard, pas un mot de passe que personne ne retient.

Le thème se déduit

Les couleurs ne sont pas choisies au jugé : elles sont extraites des images du site existant, puis exprimées en rôles (une couleur de marque, un accent, deux fonds) plutôt qu’en valeurs éparpillées. Les encres, elles, se calculent : chaque couleur de texte est dérivée de son fond pour que le contraste tienne partout. Le prototype charge l’échelle fluide d’EVA CSS, puis le thème du chantier, puis le peu de sur-mesure qui reste.

Des gardes plutôt qu’une relecture

Un prototype ne part pas parce qu’il « a l’air bien ». Un contrôle déterministe passe avant : tokens du système respectés, contrastes mesurés, chemins d’images valides, textes alternatifs présents, mesures du héro dans les clous. Les fonctions de cœur ont leurs tests, sans dépendance. Et le démon qui draine la file d’attente ne publie rien : il pousse vers un dossier « à relire ». Un travail automatique qui finit en attente est un travail fini.

L’audit de l’outil, puis sa refonte

Un outil qui audite des sites finit par mériter le même traitement. L’audit interne a listé ce qui tenait mal, et la reprise s’est faite par paliers, sans un seul commit avant que la suite de tests repasse au vert.

• Le filet d’abord. Tests sur les fonctions pures, lecture des entrées qui distingue « fichier absent » de « fichier corrompu », et fin de ce fichier de bibliothèque qui se réécrivait à chaque build sans qu’une ligne ait changé.
• Le flux ensuite. Une frise qui montre où en est chaque chantier, la file d’attente rendue visible avec un signal honnête (est-ce que la boucle tourne encore ?), et des mises à jour en direct au lieu d’un rafraîchissement à la main.
• La solidité enfin. Garde contre les requêtes qui pointent vers l’interne, plafond de taille au téléchargement, et un gabarit qui rend du vide quand une donnée manque, au lieu de laisser fuir le contenu d’un autre chantier.

Le reste est écrit noir sur blanc dans le même fichier : ce qui est différé, ce qui reste une limite connue, ce qu’on ne referme pas complètement. Un backlog honnête vaut mieux qu’un outil réputé fini.

Ce qu’elle ne décide pas

Trois choses lui échappent, et ce sont les trois qui comptent. Dire si le projet a du sens : un site refait l’an dernier n’a pas besoin de l’être, et on le dit quitte à ne pas prendre la mission. Choisir la direction artistique : une machine sait appliquer un système, elle ne sait pas quel ton va à un architecte plutôt qu’à un traiteur. Envoyer, enfin. Rien ne part tout seul.

Node et Astro pour la fabrication, Vue et Fastify pour le pilotage local, Netlify pour la diffusion. Aucun framework côté visiteur.