Le plan que vous sautez, c'est l'incident que vous déboguerez plus tard
Chaque référentiel en ingénierie logicielle vous dit d'aller vite, de livrer tôt, d'itérer en production. Pour les sites web générés par IA, c'est l'inverse. Le builder ici refuse de générer du code directement à partir de votre prompt — il s'arrête, rédige un plan, et attend que vous le regardiez — et ce refus est la décision unique autour de laquelle tout le reste de ce pipeline est construit. Plus lent au départ, plus économique ensuite, partout. Je prends ce compromis à chaque fois, et je pense que la plupart des gens qui défendent l'inverse n'ont pas vraiment observé ce que coûte une mauvaise supposition en aval.
Voici le mode d'échec que le plan est censé prévenir. Vous tapez "un site de réservation pour mon studio" et vous validez. Le système doit deviner ce que "réservation" signifie — un widget calendrier, une intégration tierce, un vrai système de réservation avec vérification des conflits — et il doit le deviner avant d'avoir écrit quoi que ce soit, car il n'y a pas d'autre ordre possible. Se tromper à l'intérieur d'un plan, c'est une correction en une phrase, cinq secondes, terminé. Se tromper à l'intérieur du code généré, ce n'est plus modifier une phrase, c'est défaire dix fichiers qui dépendent déjà de la mauvaise hypothèse. J'ai vu les deux cas se produire. La correction au stade du plan, c'est un échange. Le revirement après génération sur la même ambiguïté, c'est jeter et reconstruire.
Le plan n'est pas non plus une simple liste de tâches, et c'est ce que les gens ratent. C'est un contrat, et le système s'y tient : un vérificateur de conformité, l'un des agents qui doit donner son feu vert avant qu'un build soit livré, compare le site terminé au plan que vous avez approuvé. Chaque page prévue a-t-elle été construite ? La liste des fonctionnalités correspond-elle à ce qui a été livré ? "Terminé" n'est pas une impression ici — c'est relatif à une promesse écrite, vérifiable ligne par ligne. C'est une garantie plus forte que "le code fonctionne", et vous ne l'obtenez que parce qu'il existe un document auquel vous référer. Retirez le plan et vous retirez l'étalon de mesure.
Là où cela paie vraiment
Votre pouvoir en tant que pilote du build est concentré en amont, que vous l'exerciez ou non. Si l'architecture de l'information vous tient à cœur, la structure des pages, quelles fonctionnalités passent en v1 plutôt qu'en v2 — cette exigence vaut dix fois plus lors de la revue du plan qu'après la première passe de génération. Quatre minutes de plus à relire un plan valent mieux qu'un aller-retour à corriger un build déjà parti de travers.
L'exemple le plus clair est le type de produit — site statique simple, application installable, build framework, application avec backend et persistance réelle. Cela ressemble à un menu déroulant. Ce n'en est pas un. C'est le choix le plus structurant de tout le processus, car il détermine silencieusement une douzaine de choses qui n'ont rien à voir avec l'apparence du site.
| Type de produit | Aperçu | Publier | Comptes / base de données |
|---|---|---|---|
| Site statique simple | Instantané, puisque ce ne sont que des fichiers statiques | La sortie statique se copie proprement | Impossible — demander une connexion, c'est demander quelque chose que ce type ne peut structurellement pas faire |
| Build framework | Se compile d'abord ; un build cassé se traduit par "aucun aperçu", pas par "page cassée" | Même chemin de copie statique propre, une fois compilé | Impossible |
| Application avec backend | — | A besoin d'un endroit pour exécuter réellement un processus, ce qui échoue différemment — un processus qui plante, pas un fichier manquant | Le seul type où les comptes et les bases de données existent vraiment |
Et on ne peut pas changer de type après coup à la légère. Passer d'un site simple à une application avec serveur n'est pas une simple case à cocher — c'est presque une seconde construction, car la moitié des hypothèses du plan (comment les pages se chargent, où résident les données, ce que signifie « publier ») ont été posées en fonction de l'ancien type. Alors dites-le dès la phase de plan, même à moitié sûr·e : « il est possible que j'aie besoin de comptes utilisateurs. » Prévoir une application avec serveur et ne finalement utiliser que les parties statiques ne coûte rien. Découvrir après coup qu'on en avait besoin coûte une reconstruction.
Là où les critiques ont raison
Rien de tout cela n'est gratuit, et je ne prétendrai pas le contraire. Des espaces de travail isolés par exécution signifient que vos fichiers de connaissances sont copiés à neuf à chaque fois, sans rien qui reparte vers votre machine — tant mieux si votre ordinateur portable tombe en panne en pleine construction, tant pis pour la latence, car le provisionnement d'un espace de travail et, pour les constructions de type framework, l'exécution d'une véritable installation des dépendances à l'intérieur d'une frontière de conteneur prend du temps réel. Cette frontière de conteneur existe parce qu'une construction de type framework exécute `npm install` et des scripts de build arbitraires — du code que vous n'avez pas écrit, s'exécutant avec des privilèges de build — et faire cela sur un hôte partagé sans isolation, c'est à une attaque par confusion de dépendances près de toucher les données d'un autre client. La rapidité au détriment de la sécurité était une option. Ce n'était simplement pas un compromis acceptable.
Même chose pour la vérification. Une construction terminée ne quitte pas le pipeline quand la génération s'arrête ; elle le quitte quand un ensemble de vérificateurs indépendants cessent de trouver des éléments qui méritent d'être bloqués :
- Revue de code
- Sécurité
- Liens et SEO
- Accessibilité
- Conformité
- Une exécution réelle dans le navigateur
Ce n'est pas une seule passe, c'est un cycle signaler-corriger-revérifier, en boucle jusqu'à ce que plus personne n'ait rien à ajouter, parce qu'une seule passe de linter peut manquer une régression introduite par sa propre correction. Corriger un lien cassé et casser accidentellement la hiérarchie des titres sur la même page, c'est exactement le genre de chose qu'une vérification unique manque et qu'une revérification attrape. Le coût réel de cette boucle, c'est parfois une construction qui prend une minute de plus tout à la fin sans raison apparente. Les gens remarquent cette minute. Ils ne remarquent pas les six agents qui viennent de finir de débattre à propos de leur site. C'est une critique légitime sur l'expérience — je ne pense simplement pas que ce soit un bon argument pour livrer sans que le débat ait eu lieu.
