Le code n'est pas halluciné, il est produit — et nous le prouvons en continu.
Chaque application générée par Blueprint Maker passe K-15, une validation runtime automatisée : l'app démarre, se construit, sert ses données et se navigue — ou elle ne sort pas. Voici, en clair et daté, le pourcentage d'applications qui passent les 5 portes sur les 7 derniers jours. Aucun autre générateur d'app IA ne publie ce chiffre, parce qu'aucun n'a de gate déterministe.
Chiffre lu en base à l'instant du chargement.
Les 5 portes de K-15
L'application se compile en production (next build), sans erreur.
Le CSS est présent et porte les tokens de design (var(--bpm-*)).
Le rendu visuel passe le contrôle (capture d'écran, pas d'écran cassé).
Le seed s'exécute et l'app sert de vraies données, pas un écran vide.
Les sections se chargent et se naviguent sans erreur runtime.
Pourquoi ce chiffre existe (et pourquoi il est unique)
Blueprint Maker sépare la compréhension du métier (le LLM produit un AppSpec) de la production du code (des builders déterministes). Le LLM ne rédige jamais le code final : il est produit, pas halluciné.
Résultat : la conformité technique est garantie par construction, pas corrigée après coup. K-15 est le juge automatisé de cette promesse.
Les failles récentes du secteur (bases de données exposées, endpoints non authentifiés, suppression de base de production par un agent) viennent toutes du même choix : laisser un modèle probabiliste écrire le code final. Nous avons fait l'autre choix.
Méthodologie
Health Score = pourcentage d'applications qui passent les 5 portes de K-15 (build, design, visuel, données, navigation), calculé sur les applications générées et testées lors des 7 derniers jours glissants. Les brouillons et les applications de type note (validation synthétique) sont exclus du calcul. Même source de vérité que notre tableau de bord qualité interne.