Oui, de deux façons complémentaires : régénérer l'application depuis une description enrichie — la voie sans code, adaptée aux évolutions de structure — ou récupérer le code source et le faire évoluer comme n'importe quel projet, par vos soins ou ceux d'un développeur. La seconde voie suppose une condition souvent négligée : que le code généré soit standard et lisible, pas un enchevêtrement que personne n'ose toucher.
Première voie : régénérer depuis la description
Le besoin évolue ? La description évolue avec lui. Vous ajoutez « chaque intervention a désormais un technicien assigné et un niveau d'urgence », vous relancez la génération, vous validez le nouveau plan : l'application regénérée intègre l'entité, les écrans et les indicateurs correspondants. C'est le mode d'évolution naturel de Blueprint Maker, sans écrire une ligne.
Cette voie est la bonne pour les évolutions structurelles — nouvelles entités, nouveaux statuts, nouveaux indicateurs. La description reste la source unique : elle documente votre outil en français, et le pipeline déterministe garantit qu'un même plan validé produit une même application.
Seconde voie : faire évoluer le code exporté
Pour ce qui dépasse le périmètre généré — un besoin très spécifique, une intégration particulière — la sortie de secours est le code lui-même. Les applications Blueprint Maker s'exportent en ZIP ou se poussent sur votre GitHub : un projet Next.js + Prisma standard, la structure que tout développeur web connaît.
C'est ici que la méthode de génération pèse : un code écrit librement par un modèle est souvent illisible et fragile à modifier ; un code écrit par des builders déterministes est homogène d'une application à l'autre — les mêmes conventions, les mêmes structures. Le code étant exportable et standard, un développeur peut y ajouter ce que la génération ne couvre pas.
Choisir sa voie selon le changement
Les deux voies ne s'excluent pas ; chacune a son terrain.
- Ajouter une entité, un statut, un indicateur : régénérer depuis la description enrichie.
- Ajuster un périmètre encore mouvant : régénérer tant que la structure n'est pas stabilisée.
- Intégrer un système externe ou un besoin hors périmètre : faire évoluer le code exporté avec un développeur.
- Reprendre l'outil en main durablement en interne : passer sur le code, l'URL dédiée ou votre hébergement au choix.