Entre juillet 2025 et début 2026, l'expérience Condamine Apps a produit plus de 50 applications web fonctionnelles. Pas des prototypes au sens approximatif du terme, des wireframes cliquables censés simuler un produit. Des applications réellement déployées : front-ends React ou Next.js, Tailwind CSS, publiées sur Vercel, accessibles via une URL réelle. Ce qui nécessitait autrefois une petite équipe pendant plusieurs semaines prend désormais quelques jours à une seule personne.

La compression temporelle réelle

Le gain de vitesse est réel, mais il mérite d'être compris avec précision. Les outils comme Claude Code, Bolt et Cursor ne compriment pas la phase de réflexion. Ils compriment la distance entre une décision et un artefact fonctionnel. Une fois que l'on sait ce que l'on veut construire et pourquoi, l'ossature, la structure des composants, le pipeline de déploiement : tout cela s'assemble en quelques heures plutôt qu'en quelques jours. La contrainte créative disparaît. Ce qui constituait autrefois un goulot d'étranglement (écrire le boilerplate, câbler l'état, configurer le build) devient presque instantané.

Ce glissement a un effet en cascade sur la façon dont les idées sont validées. Les maquettes statiques avaient une utilité quand construire la chose réelle coûtait cher. Elles permettaient de tester une direction avant d'engager des ressources. Mais une maquette implique toujours une perte de traduction entre l'intention et l'exécution. Un prototype fonctionnel dans un navigateur, avec de vraies interactions et de vraies données, produit une qualité de retour différente. Les utilisateurs réagissent différemment. Les parties prenantes aussi. L'écart entre l'artefact et le produit final se réduit considérablement.

Ce que l'IA ne remplace pas

Cinquante applications en huit mois fait rapidement apparaître un schéma. La qualité de ce qui est construit est bornée par la qualité de la réflexion qui précède le premier prompt. Claude Code peut générer une application React complète avec routage, composants et appels API en moins d'une heure. Ce qu'il ne peut pas faire, c'est décider si cette application résout un problème réel, sert le bon utilisateur ou opère les bons arbitrages entre simplicité et fonctionnalité.

Les décisions de design restent entre les mains du designer. Non parce que les outils sont incapables de générer des choix de design, mais parce que ces choix générés sans cadre de référence humain ont tendance à être statistiquement moyens. Ils s'appuient sur des patterns présents dans les données d'entraînement. Les décisions intéressantes, spécifiques et bien raisonnées viennent d'une compréhension fine du contexte : qui utilise ça, dans quelle situation, avec quelle connaissance préalable, pour quel objectif. Cette compréhension n'émerge pas d'un prompt. Elle vient du travail qui le précède.

L'expérience des 50 applications a rendu cela concret d'une façon inattendue. Au début, les applications construites rapidement sans assez de réflexion amont accumulaient la friction vite. Des exigences floues produisent du code flou. Le refactoring via des outils IA est possible, mais coûte plus de temps que de bien poser la structure dès le départ. La leçon : l'IA accélère la production, et donc amplifie aussi les conséquences des décisions mal spécifiées.

La stack et pourquoi c'est important

React et Next.js avec Tailwind CSS, déployés sur Vercel, est un choix délibéré et pas seulement le chemin de moindre résistance. Cette stack bénéficie d'une forte familiarité des modèles IA, ce qui signifie que Claude Code produit un code plus précis et plus idiomatique pour elle que pour des frameworks plus nichés. Le pipeline de déploiement Vercel efface suffisamment de friction pour que shipper une app fonctionnelle devienne une étape triviale plutôt qu'un jalon projet. C'est important pour l'objectif central de l'expérience : réduire le coût d'une idée fonctionnelle au point qu'il devienne comparable au coût d'un sketch.

L'objectif pour 2026 est d'atteindre 100 applications. Ce chiffre compte moins que ce qu'il représente : une pratique soutenue et à volume élevé de construction et de publication. Le volume génère une reconnaissance de patterns qu'aucune lecture ni aucune théorisation ne produit. Chaque application enseigne quelque chose de précis sur ce qui fonctionne, ce qui ne fonctionne pas, là où les outils sont véritablement utiles et là où ils créent une fausse impression de progrès.

À quoi ressemble une vraie boucle de validation maintenant

Le passage du mockup-first au working-prototype-first change le rythme de validation. Une maquette statique invite des retours sur l'apparence d'une chose. Une application fonctionnelle dans un navigateur invite des retours sur son comportement. Ce sont deux conversations différentes. La première porte sur des choix visuels. La seconde sur le comportement, la logique et l'adéquation avec le contexte réel de l'utilisateur.

Pour les équipes produit et les entrepreneurs, cela importe plus qu'il n'y paraît. Le nombre d'hypothèses qui survivent à une maquette soignée et s'effondrent au premier contact avec un prototype fonctionnel est frappant. Des interactions qui semblaient évidentes dans un cadre statique deviennent confuses en mouvement. Des cas limites invisibles dans un user flow de trois écrans deviennent immédiatement apparents quand un vrai utilisateur commence à taper de façon imprévisible. Construire plus vite rend possible d'atteindre ce moment de contact plus tôt, avec moins de coût irrécupérable, et avec plus de marge pour ajuster.