Hello les amis, retour d’expérience ici sur le vibe coding et l’usage des LLM en conditions réelles, sans filtre, sans exagération et avec rien à vous vendre :) Ce que je vous propose aujourd’hui, ce n’est pas un énième article qui vous dit quoi penser, et qui polarise encore un peu plus le débat de l’usage ou non des LLMs.

La valeur ajoutée de ce retour d’expérience réside dans les réussites et les échecs que j’ai pu obtenir sur mes pratiques et dans le retour objectif que je peux vous faire sur mes résultats. Je vais commencer par un constat simple, je suis rentré dedans par curiosité, j’ai commiter dedans par nécessité.

Un truc que je me suis toujours refusé de faire et ça ne changera pas, je ne dégomme jamais les gens et je ne donne jamais de nom ou d’organisation dans mes articles. Par contre sans vergogne je pesterai jusqu’à la mort sur les mauvaises organisations de travail et sur les mauvais process. Je vous propose donc de revenir sur mes usages personnels et professionnels des LLMs et d’essayer d’avoir un retour critique et objectif sur ce que ça m’a apporté ou non.

Tiens il est marrant ce jouet, mais est-ce qu’on peut faire des vrais trucs avec ?

Ma première utilisation finalement commence à dater de la sortie de ChatGPT en grand public, le concept de vibe coding n’existait pas à l’époque, et j’ai commencé à utiliser ChatGPT pour essayer de comprendre et de trouver du sens à l’application qu’on m’avait remise à l’époque.

Un machin fait maison avec un framework bien connu mais un peu oldy dans une techno en 3 lettres, un dev parti dans des circonstances troubles, des VPS posés pépère dans un cloud cocorico qui a tendance à chauffer un peu trop … (oui désolé, cette vanne est un peu surannée, un peu comme le framework de la techno en 3 lettres) et bien sûr le code en deploy manuel scp style.

Donc là l’ambiance c’était, prendre 2 ou 3 mois à comprendre vraiment ce que ça fait et essayer de maintenir ce truc tant bien que mal, essayer de sécuriser le truc, industrialiser le déploiement et essayer de maintenir et de sécuriser le reste de l’écosystème.

Bien sûr la connaissance était perdue, donc par nécessité, j’ai commencé à demander des trucs à mon meilleur pote GPT. C’était un peu fastidieux, fallait copier-coller des trucs avec des risques d’erreur assez courants, mais ça m’a permis d’embryonner assez rapidement un docker compose, une CI/CD gitlab pour déployer ce truc avec du ansible, qui portera le templating de la conf et la gestion de docker compose sur la machine. Not great, Not terrible, mais je voulais du container et utiliser le registry GCP dans l’espoir de peut-être bouger ça dans du cloudrun ou du compute container sur GCP à un moment. En vrai c’est allé assez vite parce que je connais assez bien ce genre de trucs et finalement GPT n’a fait qu’accélérer mes idées et me faire gagner du temps sur un truc que j’aurais pu faire par moi-même. Le premier usage que j’en ai eu était donc de faire une compression de l’espace et du temps, finalement, informatique quantique avant l’heure !

Je dois dire que pour cet usage, j’ai eu l’impression de gagner du temps et surtout de valider mes choix, bon on sait tous que ChatGPT est un people pleaser donc forcément mes choix sont les meilleurs …

Deuxièmement, mis à part des souvenirs fort lointains de l’école, pas trop d’expérience de dev sur la techno en 3 lettres et c’est là que l’ami GPT a été pour le moins très utile. En comprenant vaguement de quoi ça parle et en essayant de cibler et de structurer mes demandes de changements, j’ai pu faire quelques modifs dans la base de code et mener à bien les quelques trucs qu’on m’a demandé de corriger ou qui ne me plaisait pas. Passé ce besoin, on m’a demandé de mapper une base de données infernale avec quelque 300 + tables pour lire et écrire dans certaines d’entre elles. Et là avec l’idée de mettre un fastapi et mapper les tables qui m’intéressent, j’ai pu bricoler un truc pas trop bancal et fonctionnel avec un basic auth, un certificat devant et un code pas trop compliqué. J’ai trouvé une lib avec un autorouteur qui me génère les cruds propres sur les tables que j’avais décidé. Ce petit bricolage rigolo mis en docker dans la machine qui porte l’application avec la base gigantesque, une modif de la conf nginx pour router ça proprement et profiter du serveur déjà présent et roule.

Là pour le coup, GPT a fait un peu plus que de me booster mon délai, il m’a aidé à sourcer mes technos, consolidé un peu plus mon dev bancal, revue rapide de mon code et validation technique et fonctionnelle de l’ensemble, en somme je l’ai utilisé comme accélérant sur les sujets que je maîtrisais déjà et comme conseiller technique / dev buddy pour la partie dev.

Je n’ai pas pu voir réellement l’impact réel de ces choix puisque j’ai été embarqué dans un licenciement économique ensuite … Mais je pense que j’ai réduit les dégâts et fait gagner un peu de temps au suivant. Voilà ce que je retiens de cette mission, réduction de la pénibilité opérationnelle, réduction du délai et de la pénibilité de livraison, scotch de barrage sur du code de mauvaise qualité. Pas de grande révolution à mon sens, mais comme l’outil était embryonnaire, copier-coller du code dans une page web avec une fenêtre de contexte restreinte c’est forcément limitant.

Oulala, c’est pas marrant ton use case ! si je le fais moi-même ma santé mentale va en prendre un coup !

Deuxième utilisation, cette fois-ci dans un cadre un peu plus contrôlé avec un LLM maison, ceux qui savent se reconnaîtront, coucou les copaings ;) Cette fois-ci, autre histoire, détaillée dans un de mes articles précédents, au sujet de la gestion en terraform de ~270 projets. Avec le recul, à aucun moment j’aurais pu faire ce truc sans éclater durement ma santé mentale sans l’aide du LLM.

On parle quand même de lire en gcloud l’ensemble des IAM, les API activées et les clés KMS des projets et de formater toute cette merde en Terraform. Complètement suicidaire pour faire à la main un truc pareil en bash, avec la contrainte qu’humainement ça doit être simple de pouvoir ajouter et supprimer de nouvelles entrées, mais aussi de tolérer les petites mains qui ne respectent pas le TF et de rattraper les erreurs de suppression ou création manuelle.

À aucun moment j’aurais tenté un truc aussi compliqué, tout simplement parce qu’humainement je n’en aurais pas été capable dans un délai si court et sans erreurs. C’est la brutale réalité de cette mission et la conclusion de ce projet, sans LLM on aurait fait sans Terraform et ça aurait été un cauchemar opérationnel à long terme pour tracer qui fait quoi et pourquoi. L’historique des changements aurait été absent, et les modifs humaines n’auraient pas été tracées efficacement.

Donc l’outil a apporté une complexité dans le Terraform localisé dans un endroit du code qui ne change jamais, pour permettre la manipulation “simple” de dictionnaires de données, à condition de ne pas casser le format ou de ne pas avoir de cas d’utilisation imprévu par l’automatisation du code.

Donc j’ai un peu roté du sang à la mise en place du truc, mais une fois posé et les gens qui s’en occupent formés par mes docs, ou par des manipulations ratées, le contrat est rempli et mon client est 100% autonome avec un système un peu complexe mais dans un espace du code qui ne change plus. Sa réalité opérationnelle est simple et ce n’est pas beaucoup plus compliqué ou long pour lui que de cliquer dans l’interface. Toute proportion gardée qu’il a fallu lui mettre dans les mains le terminal Linux, Git et Terraform, qui ne sont pas forcément simples à appréhender quand on n’a pas l’habitude.

Ma petite fierté quand même c’est que ça fait encore de l’usage et que ça fonctionne plutôt bien, mon usage a été stratégique et pragmatique cette fois, générer et fiabiliser un code compliqué une fois, outiller le code avec des scripts pour gérer les opérations répétitives sources d’erreurs, faire du rattrapage de manipulation humaine. Tout ça pour réduire la complexité opérationnelle et pour mettre bien mes collègues après mon départ. Les modifications sont versionnées, auditables et répétables, je pense que ça correspond tout à fait à la demande.

Le LLM m’a permis de réaliser mon idée complexe là où humainement j’aurais déjà laissé tomber. Pour autant j’ai dû le tordre et le forcer à réaliser mon ouvrage. J’ai bien senti que mon truc était complexe et difficile à appréhender, j’ai fait plusieurs essais et le LLM m’a permis d’itérer beaucoup plus vite. Dans le lot aussi, j’ai pu challenger mes pratiques et découvrir des syntaxes bash et Terraform que je ne connaissais pas. Par contre aucune magie là-dedans, j’ai dû déboguer et itérer des codes pas tout à fait fonctionnels voire carrément faux et m’approprier le résultat final. Bon résultat malgré un LLM limité et des contraintes très fortes.

C’est un peu le bordel là non ?

Dernière expérience qui est encore en cours au moment où j’écris cet article.

Pour situer le truc, on est en pleine période de changements brutaux au niveau des LLM : il y a Gemini 3 qui est sorti il y a quelques jours, GPT-5, Claude, Qwant, il y a eu Deepseek, ça n’a jamais été autant le bordel dans les offres de LLM. C’est ce qui rend la période intéressante, la tech évolue bien plus vite que nous, le marché de l’emploi est perturbé.

Le marché est inondé de marchands de tapis qui essaient de vendre des formations IA pour “apprendre” à faire des prompts. Il y a des licenciements massifs dans les bigtech américaines. Il y a une explosion de gens qui produisent des “SaaS” en 3 jours, une explosion des attaques cyber et de plus en plus de wannabe devs qui poussent en prod sans trop penser à la sécurité.

Donc en somme ce qu’on perçoit de l’extérieur d’un point de vue non technique, c’est que ce n’est pas si compliqué, tu demandes à ChatGPT et il te fait tout ce que tu veux et sans râler bien plus vite que toi à la main.

Je vais vous parler maintenant de ma mission actuelle, de ses contraintes pour contraster un peu avec le précédent paragraphe : mon client n’en peut plus de son installation bare metal OVH avec du kube dessus. Ils ont des indisponibilités et des interventions évitables liées aux contraintes du on-premise, du setup un peu bancal et du manque de soin et de maintenance de leur installation. Donc le plan, c’est une migration express vers GCP, avec un maximum de services managés et le moins possible de maintenance. Du moins c’était le plan initial, mais si une phrase pouvait résumer cette mission : “c’est pas si simple”.

Sans rentrer trop dans les détails techniques et organisationnels, voici ce que je pense de cette mission en restant constructif et bienveillant.

Ils sont assommés par des choix techniques complexes, des implémentations douteuses des collaborateurs précédents. Leur sysadmin est parti en aidant partiellement à la migration sur les détails d’infra qu’il connaissait, mais avec pas mal de trous dans la raquette et un manque de documentation sur ce qui aurait pu nous aider pour la suite de la migration.

Certaines choses ont été oubliées ou sous-estimées dans la migration, notamment le fort couplage entre les services et un problème systémique de ne pas nettoyer ce qui est mort ou obsolète.

La migration GCP a été largement sous-estimée et aucune ressource de devs n’a été disponible pour avancer sur ces sujets, au profit d’enjeux business justifiés.

Dans ces conditions, je me retrouve isolé et obligé d’assumer seul la majeure partie de la migration GCP.

Pas d’aide, pas trop d’historique, mais il y a Gemini …

Donc j’ai fait un shift dans ma stratégie, une fois mes briques fondamentales d’infra mises en place (pour certains trucs je m’aidais de ChatGPT en relisant attentivement) je me suis trouvé face à un problème un peu costaud.

j’ai besoin de devs pour avancer et pour que l’application rentre dans les nouvelles contraintes d’infrastructure cible de ma migration. Par exemple utiliser GCS nativement à la place d’un NFS coûteux et pénible sur GCP.

Mes obsessions sur cette mission : ne pas déplacer les problèmes dans la nouvelle infra et tant que possible simplifier ce qui peut l’être, rendre le plus lisible possible ce qui semble compliqué ou opaque.

Ce qui me paraissait le plus logique était de faire quelque chose de structurant pour l’infra et l’opérationnel, réduire au maximum l’utilisation de Helm au profit de Kustomize, pour maîtriser 100% le YAML produit et éviter de se perdre dans du templating compliqué et des détails d’implémentation qui rendent les changements laborieux, longs et sujets de stress et d’erreur.

Ce qui veut dire des définitions de ressources et de limites sur les pods, pas toujours de liveness/readiness probes, des énormes fichiers de values compliqués à naviguer, des configmaps et secrets pas vraiment managés.

Un repo centralisé des manifests avec un diff facile entre les envs, ArgoCD pour piloter les changements en mode GitOps.

La CI/CD qui sera chargée de builder et de commettre les nouvelles versions dans ce repo.

Petite contrainte un peu “rigolote” : Autopilot qui augmente de lui-même les ressources quand nécessaire et qui crée des diffs de YAML…

Des workflows Argo dans tous les sens (avec Argo Workflows), eux-mêmes sans déclarations de ressources ou de limites de retry.

C’est là que mon pote Gemini rentre en jeu, en plein dans l’arrivée de Gemini CLI.

Il m’a sacrément aidé à convertir les helms en kustomize et à rajouter des ressources et des probes sur tous les services. Malgré tout, ce n’était pas parfait, j’ai toujours dû remettre les mains dedans et ajuster les trucs, mais c’est sacrément pratique pour faire des trucs dans ce genre. Une pure corvée qui manuellement ne vaut pas le coup, mais sacrément pratique si c’est fait par une machine qui n’a pas de problèmes de fatigue ou de problèmes d’attention.

J’ai une relation un peu amour/haine avec ce truc. Autant parfois ça aide pas mal, autant quand il merde c’est une purge cosmique. J’ai tout vu, le modèle qui se dégrade à partir de 17h30 et qui ne sait plus rien faire, tous les jours (heures de pointe américaines), le modèle qui s’entête dans son idée alors qu’on lui dit de laisser tomber, les restrictions trop rigides de sécu qui l’empêchent de faire les tâches les plus basiques, le modèle qui s’excuse et qui fait un rollback sans qu’on lui demande rien …

Mais malgré tout, sur des actions répétitives et bien cadrées, il fait des merveilles ! Mais qu’en est-il du code applicatif ?

Toujours pas de devs, mais je peux rendre service

Bon c’est bien joli tout ça, l’infra est en place, mais les devs sont occupés à tout sauf à faire ma migration, donc j’en ai marre, c’est Gemini qui va faire le dev.

C’est là où on part dans le sombre : j’ai besoin d’avancer, je n’ai pas les bras de devs qu’on m’a promis, ma migration prend du retard avec rien de tangible. Tant pis, on va vibecoder jusqu’à ce que ça marche ou que je prenne un échec cuissant ou un abandon pur et simple.

Donc là, on part sur un truc ambitieux, mon histoire de remplacer NFS et des points de montage pénibles par l’utilisation native de GCS. Je suis parvenu plus ou moins à un résultat fonctionnel, mais à quel prix ?

Postulat de départ :

• J’ai une appli qui écrit sur du NFS et je veux utiliser des buckets GCS à la place, pour des questions de coûts et de performance.
• Mon appli utilise des fichiers statiques publics et des fichiers protégés, je ne dois pas compromettre cette sécurité.
• Je ne dois pas faire de changements majeurs dans la façon de lire et écrire ces fichiers et ça doit être transparent pour l’utilisateur.

Points de friction :

• Les fichiers sont tous mélangés sur le NFS, je veux séparer les statiques publics des autres fichiers.
• J’ai tâtonné sur la manière de ranger les fichiers et sur la manière de les sécuriser.
• L’arborescence des fichiers sur le FS n’est pas logique et je dois la conserver.
• J’ai essayé de mettre des liens signés dans l’application, mais ça casse tout.
• Je ne connais rien au code de l’appli et je ne sais pas la tester de fond en comble.

Au final j’ai un truc qui marchouille, mais j’ai quand même eu besoin d’un dev pour relire et corriger l’application. Certains changements liés au load balancer de GCP apportent aussi leur lot de problèmes non anticipés.

Je dirais que c’est une semi-victoire pour une application sur trois : je ne suis pas garagiste, je peux changer les pneus, mais si le moteur est en panne j’appelle une dépanneuse. On va dire que j’ai rendu service, mais bon, ça ne remplace pas l’expertise d’un dev. Cette appli sera migrée sans trop de soucis, le dev qui s’en charge pourra absorber cette charge.

Application trop mouvante et changement d’architecture logicielle majeur

Deuxième appli, mêmes problèmes, mais avec en plus un moteur d’indexation avec une version obsolète.

Suite à mon succès en demi-teinte, j’ai tenté la même chose avec une seconde appli, avec en plus un changement de moteur d’indexation.

Ouais, ouais, ça ressemble à une connerie ? C’en est une !

Mais vous savez quoi ? L’espace d’un instant j’avais un truc qui marchouillait, avec mon moteur d’indexation managé.

Et puis après j’ai dû rebaser avec le nouveau code des devs, qui apportait des changements majeurs et ça s’est très mal passé.

Donc standby le temps que cette appli soit stabilisée et qu’on décide de mettre un dev à plein temps dessus pour avancer.

Là, par contre, c’est un échec cuisant, des semaines de travail avec Gemini pour changer des trucs que je ne comprends pas dans un code legacy pour un truc qui sera jeté et qu’il faudra refaire.

Parce que la réalité c’est que la vélocité des LLM est fortement réduite avec une base de code avancée et pas forcément top clean. J’ai eu l’illusion d’avoir des progrès et de l’avancement, mais la vérité c’est qu’un dev aurait fait tout aussi bien avec moins de temps et avec du code maintenable.

Il faudra un dev à temps plein capable de suivre les nouveaux changements en parallèle pour faire ces changements, affaire à suivre, mais à mon avis ça peut prendre encore du temps.

Oui je comprends. Qui a le temps? Qui a le temps? Mais si personne ne prenait son temps, comment ferait-on pour avoir du temps ? (Matrix Reloaded Discours du Mérovingien)

Le boss final

Sachant ça on arrive au boss final, une appli en symfony de 5 ans, qui n’a pas bougé depuis 3 ans, pas trop de doc sur le sujet, pas d’env de qa fonctionnel. Et faut la migrer sur GCP. Donc là on a un framework obsolète, un OS obsolète, des services tiers dans des versions obsolètes, un peu de doc de dev vite fait, un env de prod qui fonctionne encore.

Bring it on ! On va faire une Apollo 13, on va faire rentrer un truc carré dans un truc rond. Cette fois-ci, ma stratégie était d’utiliser gemini comme un conseiller mais aussi comme un planificateur de projet, j’étais dans le flou pour appréhender mon infra cible.

Dans la mesure où mes changements dans le code sur les appli plus récentes sont en demi-teinte, je suis parti sur le postulat inverse sur cette appli, il faut modifier le code le moins possible et composer autour de l’infrastructure.

La première chose que j’ai faite c’est d’explorer le code et l’infra à la recherche d’indices sur le fonctionnement de l’appli. Sans accès direct aux machines des services tiers, j’ai fait des requêtes indirectes pour avoir les versions des services utilisés par l’appli.

Les variables d’environnement m’ont aussi donné des indices sur ce qui tournait et j’ai trouvé des points de montage NFS aussi.

J’ai essayé de forcer gemini à me faire des upgrades de libs, mais le moindre truc est un sac de nœuds indémêlable, donc tant que l’appli build en container, c’est un moindre mal, on verra ensuite pour le reste.

Première idée, lancer un docker compose dans une machine sur GCP, ça semblait plus simple, mais comme ça tourne déjà sur kube en prod et qu’il y a en plus des argo workflows à gérer en plus, j’ai laissé tomber cette idée. À la place, je reprends le helm de l’enfer, je le convertis en kustomize et je le déploie de la même façon que les autres applications.

Les workflows gérés de la même façon, et bien sûr les mêmes problèmes systémiques des autres applications, pas de ressources définies, pas de probes et des retries de jobs infinis en cas d’échec.

Je suis arrivé sur un compromis de faire tourner la base de données en service managé, un service d’indexation dans le kube comme en prod et une machine en mode compute container pour le second moteur d’indexation.

Le plus gros défi c’est le NFS avec les points de montage absolument partout et la quantité importante de fichiers à migrer.

Voilà ce que j’en retiens de cette expérience. Sans gemini, je n’aurais pas pu faire la moitié de ces actions tout seul, soit avec un délai virtuellement infini, soit trop épuissant moralement pour un résultat médiocre, j’aurais abandonné.

Je n’ai pas eu trop d’aide pour les précédentes applis alors autant dire qu’il va falloir finir tout seul probablement pour celle-ci. J’en suis au stade où il ne manque probablement pas grand-chose pour que ça fonctionne complètement. Il va me manquer les workflows qui crashent encore un peu, des fichiers statiques manquants et l’indexation qui semble être partielle.

Donc avec encore un peu de temps et d’intuition et de soins ça devrait enfin fonctionner. Volontairement, je n’ai pas encore fini cette mission et je vous donne l’état exact où j’en suis, ça semble inachevé et un peu amer mais c’est la réalité de mon terrain pour le moment. Je suis persuadé que les choses vont s’accélérer et qu’une fois achevée, cette migration va briller et propulser mon client pour lui permettre de livrer mieux et d’être plus serein.

Conclusion

J’ai l’impression que les LLMs sont un vecteurs d’accélération quand on sait déjà ce qu’on veut faire. Gemini est assez pratique quand on a une idée embryonnaire et qu’on a besoin de tester plusieurs idées à la fois, mais il est complètement perdu dans du code trop vieux ou pas standard.

Il ne faut pas tomber dans le piège de tout lui laisser faire sans compréhension fine du sujet, c’est une illusion de croire que c’est possible de remplacer les devs et du code historique avec cet outil.

Je pense qu’il brille vraiment sur les tâches très nulles, chronophages et répétitives, mais ça ne dispense pas de l’intuition humaine et d’utiliser son cerveau. C’est tentant d’utiliser les LLMs pour tout et rien, mais c’est très dangereux de leur faire une confiance aveugle et d’en perdre son expertise et son esprit critique.

Il faut le voir comme un collègue : parfois il peut “se tromper”, parfois il peut “ne pas comprendre” le besoin. Ce n’est pas un oracle magique qui a réponse à tout, c’est juste une calculette probabilistique qui calcule le prochain rot.

Mais au final Sam Altman a dit que le travail tel qu’on le connaît est dépassé et qu’on allait faire des trucs dans l’espace dans le futur, ouais bah en attendant mon php il va pas se mettre en prod tout seul :)