Claude Opus a aidé un analyste métier à lancer deux applications en deux semaines sans équipe

Une expérience avec le développement par IA a montré qu'une personne sans expérience en programmation peut déjà lancer un produit mobile sur le marché. En deux semaines, un analyste métier a construit deux applications Flutter pour RuStore et y a dépensé environ 80 heures.

Comment l'expérience s'est déroulée

L'auteur a abordé la tâche comme un test d'hypothèse : si un analyste métier sait comment décomposer les exigences, rédiger des histoires utilisateur et des critères d'acceptation, cela peut suffire pour travailler avec un assistant IA au lieu d'une équipe ordinaire. Pour le test, il a choisi deux produits différents — un suivi du temps « 168 Heures » et F1 Tycoon, un jeu sur la gestion d'une équipe Formule-1. Il a également sélectionné la stack via le modèle : Flutter et Dart pour le développement multiplateforme, Supabase comme backend gratuit pour le MVP.

Le calendrier s'est avéré presque comme un sprint complet. Les deux premiers jours ont été consacrés à la configuration de Flutter et Android Studio, puis a commencé l'assemblage en chaîne des écrans pour « 168 Heures ». Ensuite est venue la première étape difficile — l'intégration avec Supabase, où l'autorisation et les appels réseau se sont rapidement transformés en une série de corrections cycliques.

Après cela, l'auteur s'est attaqué à F1 Tycoon, mais le projet de jeu lui-même a révélé la principale limitation des modèles actuels : plus il y a de fichiers et de dépendances, plus ils maintiennent mal l'architecture globale. Au jour 14, les deux applications ont réussi la modération dans RuStore, et les dépenses directes sont restées nulles.

Où l'IA a accéléré le travail

Selon l'auteur, les meilleurs résultats ne sont pas venus des outils gratuits, mais des modèles commerciaux plus puissants. Les options gratuites produisaient souvent du code qui ne compilait pas et une UI de style ancien projet académique. GPT-5.2 s'est avéré notablement plus stable, mais c'est Claude Opus qui a livré le code le plus propre, l'interface moderne et a mieux préservé le contexte du dialogue. Mais il y a quelque chose de plus important : les compétences d'analyste métier se sont inopinément alignées avec ce qu'exige un bon prompting.

« L'IA est comme un développeur junior : plus l'exigence est précise,

plus le résultat est précis. »

En pratique, cela ne ressemblait pas à de la magie, mais à un cycle très rapide de définition de tâches et de vérification des résultats. L'auteur décrivait un écran, recevait du code, l'insérait dans le projet, l'exécutait sur le téléphone et renvoyait des erreurs spécifiques au modèle. Ce mode était comme travailler avec un junior distant très rapide : la réponse arrive en minutes et les correctifs peuvent être vérifiés immédiatement sur un appareil réel. Dans ce schéma, l'IA s'est avérée particulièrement utile pour plusieurs tâches typiques :

• générer des composants UI et des écrans en minutes
• choisir une stack de démarrage pour un débutant sans équipe
• expliquer les erreurs et la terminologie en langage simple
• écrire du code boilerplate et de la logique métier basique
• préparer la publication : signature de compilation, clés, configuration build.gradle

Où les problèmes ont commencé

Le domaine le plus douloureux a été les intégrations. Connecter Supabase semblait simple sur le papier, mais dans la réalité, une correction a facilement engendré le bogue suivant. L'auteur décrit un scénario typique : le modèle corrige une erreur d'autorisation par email, après quoi l'écran d'enregistrement se casse, puis le prochain patch touche un autre fichier.

Pour les tâches courtes, c'est tolérable, mais dans un grand projet, cela devient un jeu épuisant où corriger un problème local ne garantit pas que l'application se compile même dans son ensemble. Le deuxième problème était la mémoire du modèle. Quand F1 Tycoon a grandi à plus de 50 fichiers, l'IA a cessé de se souvenir avec confiance des classes clés, de la structure du projet et des décisions architecturales antérieures.

Pour réduire la perte de contexte, l'auteur a créé un « fichier de mémoire » séparé décrivant la structure et l'a fourni au modèle au début de chaque session. Cela a aidé, mais n'a pas complètement résolu le problème. Un risque supplémentaire était les limites de requêtes : au moment critique, l'accès au meilleur modèle pouvait être coupé pendant plusieurs heures, et tout développement s'arrêtait simplement.

À la fin de l'expérience, les deux versions sont arrivées à la boutique, mais n'ont reçu au total que 14 téléchargements.

Ce que cela signifie

L'histoire ne prouve pas que l'IA a déjà remplacé les développeurs, mais elle montre bien autre chose : le seuil pour créer un MVP a chuté drastiquement. Si une personne sait comment formuler des exigences, décomposer les tâches et déboguer patiemment, elle peut déjà atteindre une version de travail. Mais les intégrations complexes, l'architecture des grands projets et le contrôle de la qualité restent des domaines où sans un ingénieur expérimenté, la vitesse atteint rapidement un plafond même dans les expériences en solo.