Deux jours pour une application Onze équipes. Une quarantaine de participants. Deux jours, mi-octobre, à Boulogne-Billancourt. L'objectif dépassait la simple démonstration : produire une application iOS prête à être soumise à l'App Store, avec un public défini et une réflexion sur sa commercialisation. Un challenge organisé avec Apple, qui a donné lieu à des projets variés, d'une application de pêche à un coach sportif utilisant la caméra. Le constat est net. Le vibe coding accélère fortement le passage de l'idée au code et à l'interface. La barrière d'entrée baisse. Mais transformer l'essai, c'est autre chose. La difficulté se déplace Une application qui tient en démonstration doit ensuite affronter le réel. Des données incomplètes. Des usages que personne n'avait imaginés. Des évolutions techniques. Des utilisateurs qui ne suivent pas le parcours prévu. La difficulté ne disparaît pas avec l'IA. Elle change de place. Vers la formulation du besoin. Vers la définition des critères de réussite. Vers la vérification, et la maintenance dans la durée. Ce que montrent les usages Une analyse portant sur environ 400 000 sessions d'un assistant de code va dans le même sens. Les humains y prennent environ 70 % des décisions de planification, contre 20 % des décisions d'exécution. Le cadrage reste humain. Et l'expertise métier pèse davantage que la maîtrise du code pour réussir. Les novices, eux, abandonnent bien plus souvent quand ça se complique. Le paradoxe du prototype rapide C'est là que le piège se referme. Plus le prototype a été rapide, plus il est tentant de croire que le produit est presque fini. Le planning se cale sur la vitesse de la démonstration. Puis viennent les tests sur des cas réels, la correction de comportements inattendus, la reprise du code par une autre personne. Le temps gagné au départ peut être reperdu, et au-delà. Planifier la validation dès le départ Pour un CTO ou un responsable produit, la bonne mesure d'un projet développé avec l'IA n'est donc pas le délai jusqu'à la première démo. C'est le délai jusqu'à une version qui tient face à de vrais utilisateurs. Entre les deux, il y a un travail de validation qui ne se génère pas aussi vite que le code. Des scénarios de test métier, définis dès le cadrage. Une phase de durcissement budgétée explicitement. Et l'acceptation qu'un prototype n'est pas un produit.
