Ilies AllaliL’outil que je voulais pour cadrer un site
Une phrase en entrée, l’arborescence d’un site en sortie, et un lien que le client comprend sans explication.
Sur chaque refonte, avant les maquettes, je cadre la structure du site. Quelles pages existent, comment elles s’articulent, ce qui bouge et ce qui reste en l’état. Je faisais ça dans des outils de diagramme génériques, lourds à maintenir et pénibles à partager. J’ai fini par construire le mien en mars 2026, je m’en sers sur mes missions, et il tourne aujourd’hui en production avec des plans payants.
Le besoin
Une arborescence sert à deux choses qui n’ont rien à voir. Elle me sert à penser, donc elle doit se réorganiser vite. Elle sert au client à valider un périmètre, donc elle doit se lire sans légende. Les outils de diagramme font bien la première et ratent la seconde, parce qu’ils ne savent rien de ce qu’est une page. Ce que je voulais tenait en quelques lignes, construire l’arbre d’un site, colorer chaque page selon qu’elle est à créer, à retoucher ou inchangée, et envoyer le tout en un lien. Ce qu’on voit ici est un vrai projet, la refonte d’Inversive, avec le contenu de chaque page annoté dessus.
Partir d’une phrase
Un projet démarre en décrivant le site en une phrase, et l’IA sort une arborescence complète avec les types de pages et leurs descriptions. Ce n’est pas un gadget de démonstration, c’est ce qui fait gagner l’heure de mise en place qui décourageait d’ouvrir l’outil. Le point important est ce qui vient après, tout reste éditable à la main. Une arborescence générée est un premier jet, jamais un livrable, et l’interface est faite pour qu’on la corrige plutôt que pour qu’on l’accepte.
Le wireframe au même endroit
Chaque page porte son propre wireframe lo-fi, dans le même projet que l’arbre. L’en-tête et le pied de page sont détectés comme composants globaux, donc une correction se propage partout au lieu d’être refaite treize fois. Le HTML se copie dans un outil d’import et arrive dans Figma avec ses calques, ce qui évite la reprise manuelle que je faisais avant. À ce stade je ne veux pas d’esthétique, je veux que le client discute la structure sans confondre un bloc gris avec une proposition graphique.
Le prix, et ce qu’il force à concevoir
Les outils comparables se louent autour de quinze dollars par mois, pour quelque chose qu’on utilise par projet et qu’on laisse dormir entre deux. J’ai pris le parti de l’achat unique, sans abonnement. Ça coûte immédiatement le revenu récurrent qui financerait l’IA, et c’est pour ça que l’outil accepte la clé d’un fournisseur d’IA ou une connexion depuis un client MCP. La dépense de modèle appartient à celui qui l’engage, et les crédits vendus dans l’application ne sont qu’une rampe pour ceux qui ne veulent pas gérer de clé. La décision de prix a donc dessiné l’architecture, pas l’inverse.
Construire seul, et ce que ça impose
Mon travail sur ce projet, c’est le cadrage produit, les arbitrages d’interface et la direction artistique. L’architecture, la base et le déploiement, je les délègue à une IA de développement et je les relis. Ça change ce qu’il est raisonnable de lancer, et ça impose de rester simple. L’application tourne sur une base SQLite d’un seul fichier, déployée en Docker sur mon serveur. C’est un choix assumé qui interdit de répartir la charge sur plusieurs machines, et qui en échange tient en une commande, se sauvegarde en copiant un fichier, et ne me coûte rien quand personne ne s’en sert.
D’un outil perso à un produit
Au départ c’était pour moi. Je m’en suis servi sur de vraies missions, des clients ont demandé le lien, et j’ai ajouté des plans payants avec un paiement et des licences. C’est le même chemin que mes plugins Framer, où j’ai réglé mon propre problème avant d’en faire un produit. Ce que j’en retiens vaut au-delà d’Arbo, quand j’ai besoin d’un outil qui n’existe pas, je regarde ce que ça coûterait de le fabriquer avant de chercher un contournement.