Le codage assisté par IA, pour moi qui suis une buse en développement, c’est une révolution qui me permet de concrétiser des idées en quelques heures là où cela relevait de l’impossible auparavant. Mais cette vitesse a un prix que l’on néglige trop souvent : la dette technique.
Le contexte de développement
Récemment, j’en parlais ici, j’ai développé une petite application web nommée HYCU Upgrade Path. Le concept est simple : une interface épurée pour générer et visualiser l’upgrade path d’une version A à une version B du logiciel de backup.
Pour ce faire, j’ai utilisé Lovable, une solution « no-code/low-code » qui m’a permis en quelques jours de mettre l’application en ligne.
Quelques semaines plus tard, j’ai décidé de redévelopper l’application à l’aide de Gemini, l’IA multimodale de Google, pour voir ce qu’elle avait dans le ventre.
J’ai donné des instructions similaires à chacune des 2 IA. J’attendais un résultat fonctionnel et similaire des deux côtés. Ce que je n’avais pas prévu, c’est l’écart abyssal dans la structure du code… Et le temps passé.
On parle d’une différence de 628ko contre 115ko. On parle de passer de 79 fichiers à 21 fichiers. On parle d’une semaine contre une demi journée. Un gouffre.
L’expérience Lovable
Sur le papier Lovable vend du rêve : vous décrivez, ça s’affiche. Et c’est vrai, l’expérience utilisateur est bluffante de fluidité. J’ai décrit mon besoin pour HYCU Upgrade Path, et en quelques itérations, l’application tournait sous mes yeux. Visuellement, c’était propre avec quelques ajustements à faire. Fonctionnellement, c’était un peu plus bancal.
Je ne suis pas développeur, mais mon premier réflexe a été d’aller voir le repository généré. Et là… ça a été la douche froide.
Pour une application aussi simple qu’un générateur d’upgrade path, Lovable m’a pondu une véritable usine à gaz :
- 79 fichiers créés.
- 8 dossiers imbriqués.
- Un poids total de 628ko.
Lovable a fragmenté l’application en une myriade de petits composants atomiques, a généré des fichiers de configuration en doublon et a importé des librairies « au cas où ». En regardant le dossier components/ui, j’ai trouvé 38 fichiers ! Des accordéons, des badges, des carrousels, des « toasters »… alors que mon app n’utilise qu’une fraction de tout ça.
C’est l’approche « Black Box » : tant que ça marche en façade, on ne se soucie pas de l’élégance du moteur. Le résultat est une application lourde et difficilement maintenable dans le temps. Et ça pour moi, c’est un premier red flag.
Coté modification du code par itération, je ne l’ai pas trouvé très précise. J’ai été contraint d’avancer par toutes petites itérations ce qui a rallongé le temps de développement… Une itération un peu trop musclée ? Ca cassait une fois sur deux mon interface ou donnait un résultat qui n’était pas celui attendu. Bref, pas hyper satisfait de l’expérience bien que j’ai réussi à atteindre mon but en une petite semaine de discussions.
L’expérience Gemini : L’architecte logiciel
Après cette semaine de lutte et quelques semaines en production, j’ai tenté la même expérience avec Gemini. Même prompt, même besoin, juste “pour voir” de quoi l’IA de Google était capable.
Le résultat ? Au départ, j’ai cru qu’il manquait des morceaux.
- 21 fichiers au total.
- 5 dossiers.
- 115ko sur la balance.
- Temps de développement : une demi-journée.
Gemini a adopté une approche radicalement différente, bien plus mature. Au lieu d’importer une librairie graphique massive, il a structuré le code et n’a gardé que ce qui était réellement nécessaire.
En ouvrant le dossier src/components, la différence est flagrante : 7 fichiers, tous essentiels. Pas de bruit, pas de composants inutiles.
Plus impressionnant encore, Gemini m’a fourni une architecture « Prête à mettre en prod ». Là où Lovable m’a donné un frontend en vrac, Gemini a séparé proprement le frontend du backend, et m’a même généré un docker-compose.yml et un script de déploiement (deploy.sh) pour mon VPS. Il n’a pas juste codé l’interface, il a pensé à comment je la ferais tourner, avec un joli README.md en prime.
Pour le plaisir, j’ai ajouté quelques détails supplémentaires sur mon application au passage.
Le Match Technique : L’obésité vs L’efficacité
Comparons ce qui est comparable. Voici le bilan des courses pour la même fonctionnalité :
| Métrique | Lovable | Gemini | Gain |
|---|---|---|---|
| Poids du projet | 628 ko | 115 ko | -82% |
| Nombre de fichiers | 79 | 21 | -73% |
| Philosophie | UI Kit complet (« au cas où ») | Code propre, lisible | Maintenance facilitée |
| Architecture | Frontend monolithique | Dockerisé (Front + Back) | Prêt à déployer |
| Temps de dev | 1 semaine | 1/2 journée | Productivité x10 |
Pourquoi la « propreté » compte (même pour les non-devs comme moi) ?
Vous pourriez me dire : « On s’en fiche du code ou du nombre de fichiers tant que l’app fonctionne ! ». C’est une erreur.
La maintenance : Modifier à la main le projet créé sous Lovable, c’est chercher une aiguille dans une botte de 79 fichiers. Avec Gemini, chaque fichier a un nom qui décrit réellement ce qu’il fait.
La consommation : 628ko de code à charger pour un utilisateur mobile, c’est lourd. 115ko, c’est presque instantané.
Le coût cognitif : Quand l’IA génère du code « brouillon », elle a elle-même plus de mal à se relire pour les itérations suivantes. C’est pour ça que Lovable « cassait » l’interface : elle se perdait dans sa propre complexité.
Conclusion : Le choix de l’outil fait la différence
Mon verdict est sans appel. Si vous voulez prototyper une idée en 10 minutes pour montrer que « ça bouge » à votre boss, Lovable fait illusion. C’est spectaculaire, c’est visuel, c’est une belle démo technologique.
Mais si vous voulez construire une application pérenne, que vous pourrez faire évoluer sans tout casser, une IA comme Gemini est bien plus performante à mes yeux.
L’écosystème évolue vite. Je ne l’ai pas testé pour le moment, mais un outil comme Claude Code doit même surement être capable de faire encore mieux.
