La démo est toujours parfaite.
Vous décrivez votre app dans un prompt. L’IA génère une interface propre, un schéma de base de données cohérent, un flux de connexion. Vous partagez le lien de prévisualisation. Quelqu’un s’exclame : “waouh, c’est incroyable”. Vous vous dites : je lance ça en une semaine.
Puis arrive le deuxième jour.
Ce qui se passe réellement
Un utilisateur se connecte et un bouton ne fonctionne pas. Le formulaire ne valide pas les données. Les permissions ne sont pas tout à fait correctes - des utilisateurs voient des données qu’ils ne devraient pas voir. Vous demandez à l’IA de corriger. Le correctif introduit un autre problème. Vous relancez un prompt. L’IA casse autre chose.
C’est ça, le problème du deuxième jour : les constructeurs d’apps IA sont optimisés pour la génération, pas pour la maintenance itérative par des non-développeurs.
Le problème fondamental est que ces outils génèrent du code. Du vrai code React et TypeScript fonctionnel. C’est présenté comme un avantage - “vous possédez votre code !”. Pour un développeur, c’est effectivement un atout. Mais pour un fondateur ou un opérateur non technique, posséder du code généré signifie assumer tous les cas particuliers, les bizarreries de gestion d’état et les dépendances non documentées.
Chaque modification d’une app générée par code est une négociation entre ce que l’IA comprend actuellement et ce que le code existant fait réellement. L’IA n’a pas de mémoire fiable de l’itération précédente. Décrivez un petit changement, et vous pourriez obtenir quelque chose qui fonctionne - ou un diff de trois fichiers qui casse tout le flux d’authentification.
Pourquoi la première version semble différente
La première version est impressionnante parce que l’IA part de zéro. Il n’y a aucun état existant à concilier, aucune décision préalable à respecter. Elle se contente de générer.
À la cinquième version de votre app, l’IA doit essentially lire plusieurs centaines de lignes de code qu’elle comprend peut-être ou non, et tenter une modification chirurgicale. Le même modèle qui a bâti toute votre app d’un coup a maintenant du mal à changer l’étiquette d’un bouton sans toucher à cinq autres éléments.
Les deux types de bâtisseurs pour qui cela importe
Les fondateurs techniques ont globalement compris le jeu. Si vous savez lire le code, comprendre les erreurs et intervenir quand l’IA se trompe, le problème du deuxième jour est gérable. Vous utilisez l’IA pour la vitesse et gérez vous-même les cas particuliers. Lovable et Bolt sont de vrais outils pour ce public.
Les opérateurs non techniques sont ceux qui se brûlent les ailes. Les premières victoires sont réelles - vous lancez quelque chose plus vite que vous ne l’auriez imaginé. Mais après six semaines, vous dépendez de l’IA pour le moindre changement, l’IA devient incohérente et vous passez plus de temps à prompter que vous n’en auriez passé à apprendre un tableur. L’app est devenue un objet que vous avez peur de toucher.
Une autre approche
Le problème n’est pas l’IA. Le problème est d’utiliser la génération de code comme fondation pour des apps que des non-développeurs doivent posséder et maintenir.
Il existe un autre modèle : utiliser l’IA pour accélérer la configuration d’une base no-code, plutôt que pour générer du code. L’IA construit une application complète - base de données, pages, permissions, navigation - mais sous forme de blocs visuels modifiables directement, sans prompt ni code. Et si vous ne voulez pas utiliser l’IA, vous pouvez tout construire ou ajuster manuellement.
C’est ce que fait l’AI Co-Builder de Softr. Vous décrivez votre app et il génère un produit complet et fonctionnel : schéma de base de données, permissions utilisateurs, navigation et pages. Le deuxième jour consiste à modifier un champ dans une interface visuelle ou à ajuster une règle de permission en un clic - sans déboguer de code généré, sans espérer que l’IA se souvienne de ce qu’elle a construit la dernière fois. L’authentification et les groupes d’utilisateurs sont intégrés dès le départ, vous n’avez donc pas à colmater des failles de sécurité dans du code généré après coup.
Ce que cela implique pour le choix d’un outil
Si vous êtes développeur : le problème du deuxième jour est soluble. Lovable et Bolt vous donnent la pleine propriété du code et une vitesse d’IA suffisante pour que le compromis en vaille la peine.
Si vous êtes un fondateur non technique créant une app métier : soyez honnête avec vous-même sur qui maintiendra cet outil dans six mois. Si la réponse n’est pas un développeur, choisissez une plateforme où le résultat est modifiable visuellement - et non une plateforme où chaque mise à jour passe par une fenêtre de chat.
Le meilleur constructeur d’apps IA pour votre projet n’est pas celui qui a la démo la plus impressionnante. C’est celui avec lequel vous serez encore capable de travailler sereinement au 90ème jour.