Épisode 1 de l'expérience vibe coding

Il y a un an, on plaisantait : « La vraie AGI sera atteinte le jour où les LLMs comprendront le CSS. »

Contrairement à ce que pense Milo, nous n'avons pas de développeurs frontend chez Bot Resources. On n'en a jamais vraiment eu besoin. On construit des systèmes agentiques pour nos clients — le travail, c'est l'architecture, l'orchestration, l'intégration. Pour les POC et les POV, on a besoin d'une UX fonctionnelle, pas d'une belle UI. Chainlit et les bibliothèques similaires font le travail.

Depuis deux ans, on s'appuie sur les LLMs pour gérer la partie UI. Surtout le CSS. Les résultats... n'étaient pas bons. Je suis à peu près sûr qu'un vrai développeur frontend ferait un malaise en voyant nos fichiers CSS.

Notre site web reflétait ça. On l'avait utilisé pour expérimenter la génération de contenu — est-ce qu'on peut utiliser des agents pour écrire sur ce qu'on fait ? La réponse était non. Notre contenu est trop disruptif. La majeure partie contredit ce qui se trouve dans les données d'entraînement des LLMs.

Qu'est-ce qu'un agent ? Qu'est-ce qu'un système agentique ? Pourquoi les data scientists ne sont-ils pas les mieux placés pour les construire ? Pourquoi le fine-tuning est-il généralement une mauvaise idée ? Quels sont les cas d'usage réalistes ? Ces questions n'ont pas de réponses correctes dans les jeux de données d'entraînement.

Quant à l'UI de l'ancien site ? Disons simplement qu'elle était signée GPT-4 Turbo. Magnifique, élégante, bien pensée... ou pas.

Mais c'était il y a plus d'un an. Dans la plupart des industries, ça veut dire hier. Dans la nôtre, autant dire deux siècles. Pendant cette période, on est passés de chatbots à peine capables de remplacer Google + Stack Overflow sur des bugs simples à des agents capables d'éditer semi-automatiquement des bases de code pour implémenter des fonctionnalités. Il était temps de tout refaire.

L'expérience

Les agents de code qu'on utilise au quotidien sont intégrés dans notre IDE et nos outils en ligne de commande. Parfait pour le développement backend. Pour le frontend, c'est laborieux.

Le développement frontend, c'est comme des poupées russes — des composants dans des composants dans des composants. Plusieurs couches. Ajoutez la logique interne avec différents types de services et d'interfaces, et vous obtenez une base de code où comprendre quel code gère le comportement d'un bouton précis nécessite de lire des dizaines de fichiers.

Ensuite il y a la partie « esthétique ». Pour qu'un agent de code voie le site, il faut le capturer en image et le coller dans le chat. Loin d'être idéal. Et il faut quand même indiquer à l'agent quel élément précis modifier. La meilleure méthode ? Inspecter les éléments du DOM, trouver le bon, et dire à l'agent « le bouton <app-user-edit-button-admin-page> ne fonctionne pas ». Lent, fastidieux, pénible.

On a cherché des outils spécifiquement conçus pour ça. On a trouvé Lovable. On a expérimenté. Est-ce qu'on peut l'utiliser pour discuter UX/UI ? Oui. Maquetter un tableau de bord ? Oui. Construire quelque chose de réel ? Oui. Cliquer droit dans l'aperçu pour dire à l'agent de changer la couleur d'un bouton ? Oui ! Est-ce que c'est parfait ? Non. Mais c'est un début.

Il était temps de lancer une nouvelle expérience. La question : est-ce qu'on l'utilise pour un projet client ou pour nous ? Première option trop risquée. Deuxième option — peut-être, mais sur quoi ? Et là je me suis rendu compte que le contenu du site n'avait pas été mis à jour depuis juillet 2024. Tant de choses avaient changé. Il nous en fallait un nouveau.

L'ambition

Ceux qui me connaissent savent que je suis un homme posé, raisonnable et sans aucune ambition. Je ne vais jamais essayer de rendre un projet trop ambitieux, surtout s'il s'agit d'un petit projet interne. Pour vous donner une idée, quand je travaillais sur les données marketing, je n'ai jamais décidé de construire un système qui referait toute la logique d'attribution d'un adserver, en mieux.

Donc mes specs pour notre petit site d'entreprise sont raisonnables. Faites-moi confiance. Rien d'extravagant. On est une petite entreprise avec pas tant de clients que ça. Pas besoin de construire des outils élaborés pour si peu d'utilisateurs. Résumons les specs :

• Je n'aime pas les CMS.Ils sont horribles. Alors à la place, mon CMS sera Lovable. On entre dans une nouvelle ère. Déléguons entièrement à un système agentique l'intégralité du site. Après tout, que pourrait-il arriver de mal, n'est-ce pas ?
• Je veux un site complet, avec beaucoup de contenu.Même si on n'a pas le temps d'écrire ce contenu et que personne ne le lira jamais. Faisons-le quand même.
• Je veux un site multilingue.On est une entreprise française, mais curieusement la plupart de nos ventes se font à l'étranger, donc il faut de l'anglais et du français. Ah, et un de nos employés part au Japon l'année prochaine. Ajoutons une version japonaise aussi.
• Je veux une section blog.Multilingue aussi. Nouvelle logique de blog : on écrit le contenu, et on laisse Lovable trouver les illustrations et le rendre beau. La traduction sera un problème, mais on construira quelque chose pour ça plus tard.
• Ce serait bien si les visiteurs pouvaient commenter les articles du blog.Les commentaires, c'est bien. Ça flatte mon ego. Ça pourrait même me motiver à produire plus de contenu. Mais pour ça, il faut un backend et de la modération. Pour la modération, on pourrait utiliser de la modération automatisée. Je n'ai jamais essayé, allons-y. Rien à craindre ici, ce n'est pas comme si des visiteurs aléatoires sur Internet allaient tenter du prompt injection en sachant que la modération est faite par des agents.
• Je veux un backend pour les prospects.Rien d'extravagant. Un petit système agentique avec un agent de qualification et un ingénieur avant-vente capable d'analyser des cas d'usage, ce serait bien.
• Je veux un backend pour nos clients.En gros tout ce qu'on offre aux prospects mais avec des fonctionnalités en plus. Gestion des contrats et des factures. Un agent PM serait bien aussi. Ajoutez la gestion des feuilles de temps pour la facturation au temps passé, les frais d'API et les livrables pour la facturation au projet.
• Je veux un CRM complet pour nos commerciaux.Je n'aime pas les CMS mais je n'aime pas non plus les CRM. Remplaçons les deux.
• Je veux un backend pour nos employés.On a actuellement 4 employés. Il est crucial qu'ils aient des agents avec accès aux plannings de congés, aux absences et aux contrats de travail.
• Et bien sûr, tout ça doit être entièrement sécurisé, maintenable, sans vendor lock-in LLM, du SSO partout.

Comme vous pouvez tous le constater, je n'ai que des ambitions raisonnables et bien ancrées.

Ce qui s'est réellement passé (jusqu'ici)

Je me suis fixé une contrainte : je ne touche pas au code. Pas pendant le développement. Mode vibe coding intégral — des instructions en entrée, des résultats en sortie. Pour le frontend, du vrai vibe coding : je donne des instructions générales, sans fournir l'architecture du code. Pour le backend, je suis maniaquement trop ambitieux. Je n'utiliserai pas Lovable même s'il est censé pouvoir le faire. Du pur workflow d'agent de code. Des instructions strictes sur l'architecture avec une séparation des responsabilités claire. Si j'ai le temps, je ferai des articles de blog sur comment faire et pourquoi.

Lovable génère du code React/Vite, se synchronise avec GitHub, fait un commit par changement. Je déploie sur OVH via GitHub Actions. L'authentification est implémentée — une SPA utilisant Entra et Google, se connectera au backend via WebSocket avec le token d'accès dans le premier message. Cette partie était délicate. Tout le reste ? Étonnamment fluide.

J'écris le contenu en markdown. Je le colle à l'agent : « ajoute ça au blog, rends ça beau ». L'aperçu apparaît. J'ajuste si besoin.

Quand j'ai voulu l'internationalisation, j'ai demandé de créer les versions française et japonaise. L'implémentation technique a fonctionné au deuxième essai — le premier avait oublié quelques éléments, un rapide suivi a corrigé ça. Site trilingue opérationnel.

Les traductions elles-mêmes sont génériques et manquent de contexte métier. C'est logique — une bonne traduction nécessite une connaissance du domaine et de la supervision. Mais le système fonctionne.

Le site est plus beau que tout ce que j'aurais pu construire. Des heures au lieu de semaines.