Vibe coding : 6 mois qui ont transformé mon métier

La puissance du vibe coding : six mois qui ont transformé ma façon de développer

Après six mois de vibe coding, je partage mes essais, les limites de l’IA locale et mes premiers projets professionnels migrés avec Codex.

Par Louis Planquart · · 9 minutes de lecture

Le vibe coding ne remplace pas l’expérience du développeur : il lui permet de l’exploiter à une vitesse inédite.

Depuis maintenant six mois, je ne fais pratiquement plus que du vibe coding. Au départ, j’étais sceptique face à des outils dont l’ambition affichée semblait être de faire disparaître mon métier de cœur : analyste développeur. Avec le temps, j’ai pourtant appris à les apprécier, à comprendre leurs limites et, surtout, à mesurer ce qu’ils peuvent réellement apporter lorsqu’ils sont correctement dirigés.

Le constat après six mois

L’IA sait produire du code très rapidement. En revanche, elle ne décide pas spontanément de construire une application maintenable, sécurisée et bien architecturée. La qualité finale dépend encore largement du cadre que le développeur lui impose.

Sommaire

  1. Mes premiers POC
  2. Les modèles locaux
  3. Du POC à l’usage professionnel
  4. Le passage du GDS à Gitea
  5. Mes règles de développement
  6. Le chemin le plus court
  7. Le développement piloté par l’IA
  8. Et maintenant ?

Mes premiers POC : une belle façade ne suffit pas

Mes premiers POC se sont concentrés sur des sujets que je maîtrisais parfaitement : des fonctionnalités que j’avais déjà développées des dizaines de fois et que je réalisais presque toujours selon les mêmes principes. La création d’une fiche client en est un bon exemple.

Au début, mes prompts étaient très sommaires : Crée-moi une application de gestion de clients. Le résultat aurait probablement semblé excellent à un client peu familier avec le développement. La façade était propre et le programme fonctionnait.

Mais dès que j’ouvrais le capot, je découvrais un code comparable à celui d’un stagiaire en première année de BTS informatique : fonctionnel, certes, mais difficilement maintenable et très éloigné des standards attendus pour une application professionnelle.

Mes essais suivants ont donc été beaucoup plus directifs :

Je veux une architecture trois tiers. L’accès à la base de données doit être réalisé par une API. Utilise une stack technique professionnelle, limite les dépendances inutiles et évite Python autant que possible.

Avec ce type d’instructions, les résultats sont devenus nettement plus intéressants. J’ai commencé à comprendre que je pouvais réellement capitaliser sur l’outil, à condition de lui fournir un cadre technique précis.

Réduire les coûts avec des modèles locaux

Après ces premiers tests, la suite logique a été de chercher à réduire les coûts. Les systèmes comme Codex ou Claude Code reposent sur des quotas d’utilisation qui peuvent rapidement devenir contraignants lorsque l’on enchaîne les projets.

J’ai donc testé plusieurs modèles en local avec LM Studio et Ollama. Les premiers résultats étaient encourageants, mais je me suis vite heurté à une limite importante : la taille du contexte.

Au démarrage, tout se passait bien. Dès que le projet prenait de l’ampleur, l’agent commençait à boucler, à oublier certaines décisions ou à compresser constamment son contexte.

Une solution consiste à utiliser des modèles comportant moins de paramètres afin de libérer davantage de mémoire pour le contexte. Malheureusement, le niveau de raisonnement devient alors souvent insuffisant pour une utilisation professionnelle sur des tâches de développement complexes.

J’en ai conclu que les solutions auto-hébergées ne sont pas encore systématiquement au niveau pour cet usage, même s’il reste indispensable de les tester régulièrement.

À titre professionnel, mon client a acquis un DGX Spark disposant de 128 Go de mémoire partagée entre le CPU et le GPU. La contrainte de contexte y est beaucoup moins présente, mais certaines tâches de développement restent particulièrement longues.

Je nuance toutefois ce constat : au moment où j’écris cet article, je travaille principalement avec GPT-5.6 SOL en mode de réflexion Ultra. Lui aussi peut être lent, mais le résultat obtenu est très souvent correct dès le premier lancement.

Du POC à l’usage professionnel

Mon premier véritable cas d’usage professionnel a été la migration d’un projet d’API développé avec WinDev vers une autre technologie. Je reviendrai plus précisément sur ma méthodologie dans un prochain article.

PC SOFT facture l’utilisation de ses serveurs d’applications. L’année dernière, le coût de cette licence a doublé sans évolution suffisamment significative pour le justifier à mes yeux.

J’ai donc décidé de changer de stack technologique, tout en profitant de l’opération pour corriger un bug présent dans l’application. Grâce à ma connaissance fonctionnelle et technique du projet, j’ai pu guider précisément l’agent.

Environ deux heures plus tard, la migration était terminée. Les nouvelles API, développées dans un autre langage, continuaient d’exploiter la base HFSQL existante au travers d’un pilote ODBC, tout en fonctionnant désormais dans un environnement Linux x64.

Après une première série de tests unitaires manuels, je me suis demandé si Codex pouvait lui-même automatiser la vérification de l’ensemble des API. Je lui ai donc demandé :

Lance une campagne de tests sur mes API, fournis-moi un tableau Excel recensant tous les scénarios exécutés et corrige les dysfonctionnements détectés.

Ce jour-là, j’ai eu ma deuxième grande surprise. Le système a identifié des anomalies que je ne soupçonnais pas, a corrigé les dysfonctionnements puis a publié les modifications sur le serveur.

Une expérimentation lancée presque comme un POC venait de devenir une véritable étape de contrôle qualité.

Un point de vigilance important

Ce type d’automatisation doit rester encadré. Donner à un agent un accès direct à un environnement de production impose des sauvegardes, une traçabilité complète, une procédure de retour arrière et une validation humaine des modifications sensibles.

Remplacer le GDS par Gitea

À ce stade, mon nouveau projet fonctionnait en production, mais j’avais perdu un élément important de mon environnement habituel : le GDS, le gestionnaire de sources de PC SOFT.

Après avoir étudié plusieurs solutions, j’ai choisi de déployer Gitea dans un conteneur Docker. Gitea s’appuie sur Git et propose une interface web permettant de consulter les dépôts, l’historique, les branches et les fichiers, à la manière de GitHub, tout en restant auto-hébergé.

J’ai poussé mes sources dans le dépôt et retrouvé un gestionnaire de versions complet. Il me manquait encore la documentation.

Or, les outils d’IA sont particulièrement efficaces pour produire des documents Markdown, et Gitea sait les afficher nativement dans son interface.

En quelques étapes, je me suis retrouvé avec un gestionnaire de sources et de documentation beaucoup plus complet que le GDS que j’utilisais depuis plus de dix ans.

Mon fichier Markdown de règles de développement

Comme beaucoup de développeurs, je suis un grand partisan du moindre effort. Écrire un prompt parfait avant chaque intervention est efficace, mais particulièrement répétitif.

J’ai donc créé un fichier Markdown décrivant l’ensemble des règles que l’agent doit respecter pendant le développement.

Ce document précise notamment :

  • les architectures à privilégier selon la nature du projet ;
  • une modélisation des données rigoureuse, inspirée de Merise ;
  • la séparation claire entre le front-end, les API et la couche de données ;
  • la création de vues et de composants réutilisables ;
  • l’utilisation pertinente de l’héritage et du polymorphisme ;
  • la mise en place de threads, d’événements ou du patron observateur lorsque cela se justifie ;
  • l’utilisation d’appels asynchrones pour éviter les rechargements inutiles ;
  • la limitation des bibliothèques superflues et des dépendances difficiles à maintenir ;
  • la sauvegarde et la restauration lorsqu’une base de données est utilisée ;
  • la possibilité de configurer les ports et les paramètres d’exécution.

Ce sont finalement les principes que nous appliquons déjà au quotidien, mais dont la formalisation demande habituellement de longues phases d’architecture.

Une fois consignées dans un document de référence, ces règles deviennent une sorte de contrat technique entre l’agent et moi.

L’IA cherche toujours le chemin le plus court

J’en arrive à un sujet qui me tient particulièrement à cœur. Lorsque je demande simplement à une IA de créer un programme, sans lui faire comprendre que je suis développeur et que j’attends un résultat maintenable, elle choisit généralement le chemin le plus rapide pour atteindre l’objectif.

En revanche, lorsque je lui impose des règles d’architecture, de qualité, de sécurité et d’exploitation, elle devient un développeur extrêmement productif que je peux diriger vers un résultat précis.

C’est là que le vibe coding devient réellement puissant. Tout le monde n’est pas développeur. Nous avons suivi des études, accumulé de l’expérience, connu des projets réussis et d’autres plus difficiles.

Cette expertise nous permet de distinguer une simple démonstration fonctionnelle d’une application réellement exploitable.

L’IA ne supprime pas cette valeur. Elle nous permet au contraire de l’utiliser pour proposer à nos clients, y compris lorsque leurs budgets sont limités, des architectures, des outils et des niveaux d’automatisation qui leur auraient auparavant été difficilement accessibles.

Du vibe coding au développement piloté par l’IA

Avec le recul, ce que je pratique aujourd’hui ne correspond plus vraiment à l’image improvisée que véhicule parfois l’expression vibe coding.

Je ne demande plus simplement à une IA de produire une application. Je lui fournis une architecture cible, des conventions de développement, des règles de sécurité, des procédures de test et des contraintes d’exploitation.

Mon rôle se rapproche progressivement de celui d’un architecte ou d’un responsable technique dirigeant une équipe virtuelle : je définis le cadre, je contrôle les choix, je valide le résultat et je reste responsable de ce qui est livré.

Et maintenant ?

Aujourd’hui, j’ai converti l’ensemble de mes applications WinDev, WebDev et WinDev Mobile vers d’autres technologies.

Le prochain chantier sera la migration progressive des applications de mes clients disposant encore de contrats de maintenance.

Et là, c’est une autre histoire : il faudra gérer les dépendances existantes, les habitudes des utilisateurs, les environnements de production, les reprises de données et les engagements contractuels.

Ce sera probablement le sujet d’une prochaine série d’articles.

À retenir

Le vibe coding n’est pas un bouton magique. Sans expérience, sans règles et sans contrôle, il produit souvent une application séduisante mais fragile. Correctement dirigé par un professionnel, il devient en revanche un formidable accélérateur de conception, de migration, de test et de documentation.

L’IA ne m’a pas remplacé comme développeur : elle m’a obligé à formaliser ce que mon expérience me faisait auparavant appliquer instinctivement.

Découvrir tous mes articles sur le développement, l’IA et l’architecture SI