AuraPlan : un seul fichier, de 18 à 245 Ko en dix-huit jours

Un outil de gestion de projet construit dans une seule page HTML, sans installation. Ce que sa courbe de taille raconte : l'élan, les noms qui gonflent, la moitié des écrans perdue en un envoi, puis la maturité.

AuraPlan est né le 9 août à 15 h 55 d'un commit au nom sans ambiguïté : « Create index.html ». Un fichier de 18 Ko. Pas d'installation, pas de compilation : React et Tailwind chargés depuis un CDN, le code interprété directement par le navigateur. Pour quelqu'un qui construit sans environnement de développement, c'est idéal : on ouvre le fichier, on le modifie avec l'IA, on le redépose sur GitHub. Dix-huit jours et 47 envois plus tard, le fichier pèse 245 Ko. Sa courbe de taille raconte l'histoire mieux que n'importe quel résumé. Jour 1 : l'élan, et des noms qui gonflent Le premier après-midi, le fichier quadruple. Et le titre de la page change six fois en cinq heures : « Roadmap & Tasks Pro » devient « Jira Enterprise », puis « Infinite Roadmap & Planning Pro », puis « AuraPlan Studio – Operating System pour Projets & Planning ». Relu aujourd'hui, c'est un symptôme : une IA à qui l'on demande « plus pro » ajoute des superlatifs. Le vocabulaire grandit plus vite que le produit. Même chose pour une fonctionnalité précise, découper une tâche du planning en tranches d'une demi-journée. En une heure, son titre passe par « Scission sur-mesure », « Scission multi-jours directe », « Scission planning exclusive », « Tranches de 0,5 j »… On itérait sur les mots plutôt que sur le comportement. Jour 2 : la moitié des écrans disparaît Le 10 août à 18 h 39, le fichier passe de 114 à 69 Ko. Dans cette version, plus de création de projet, plus de bouton de sauvegarde GitHub, plus de réglages de synchronisation. Rien d'intentionnel : j'avais demandé une modification, l'IA a réécrit le fichier entier en « simplifiant » au passage. Il a fallu deux envois (19 h 33 et 20 h 31) pour tout remettre. La leçon est devenue une règle : au-delà d'une centaine de kilo-octets, on ne demande plus de réécrire le fichier, on demande une modification ciblée. Et une baisse de taille brutale est une alarme, pas un progrès. Le soir même : la réécriture qui calme tout À 22 h 23, une réécriture complète, voulue cette fois. Les libellés deviennent simples : « Enregistrer », « Scinder », « Annuler ». Les émojis et les superlatifs disparaissent. Apparaissent des écrans d'erreur honnêtes (« L'affichage s'est interrompu »), des notifications, une aide. Le produit arrête de se vendre et commence à servir. La suite : ajouter sans casser - 12 août : un bloc-notes, et un titre qui dit enfin ce que fait l'outil : « Roadmap, Kanban, Planning & Notes ». - 13 août : un premier essai de travail à plusieurs, en pair-à-pair. - 17 août : la synchronisation par GitHub, chiffrée, avec un guide « Obtenir un jeton GitHub, trois minutes, une seule fois ». - 18 et 27 août : l'équipe, les commentaires, la remise à zéro avec « Exporter d'abord une copie ». Le travail à plusieurs mérite son propre billet : c'est l'histoire d'un abandon (le pair-à-pair) et d'une solution inattendue (GitHub comme base de données chiffrée). Ce que la courbe m'a appris - Un fichier unique, c'est du no-code idéal au départ : zéro installation, un seul objet à comprendre, un envoi pour publier. - Mais il faut surveiller sa taille comme un signe vital. Une chute brutale signale une perte de fonctionnalités. - Demander des changements ciblés plutôt que des réécritures complètes, dès que le fichier devient gros. - Se méfier des noms qui gonflent. Un bon nom décrit ce que fait l'outil, pas ce qu'on aimerait qu'il soit.