17 ans de dev plus tard, mes conseils et mon avis sur le Vibe Coding (coder avec l'IA)

J’ai écrit mes premières lignes de code à 14 ans, dans un éditeur texte très simple. À 32 ans, je travaille sur l’intelligence artificielle et le vibe coding a déjà changé une partie de mes réflexes de développeur. L’idée consiste à décrire à une IA ce que l’on veut construire, puis à lui faire produire une partie du code. Je partage ici mon retour après 17 ans de développement, avec de l’enthousiasme, des exemples précis et des réserves très pratiques.

Le vibe coding expliqué simplement

Le vibe coding consiste à coder avec une IA à partir d’instructions en langage naturel, directement dans un environnement de développement intelligent. Au lieu d’écrire chaque ligne à la main, je décris le résultat attendu. Je peux demander, par exemple, une application web qui fait X. L’IDE assisté par IA produit une première version du code. Des outils récents comme Cursor le font déjà très bien. On décrit l’application à créer, la plateforme génère le code, puis elle aide aussi à corriger certains bugs automatiquement.

Le terme a été popularisé par Andrej Karpathy, ancien directeur de l’IA chez Tesla. Pour lui, le vibe coding consiste à se laisser porter par l’IA, jusqu’à presque oublier que le code existe. La pratique s’éloigne du développement traditionnel. On lit les propositions de l’IA, on précise ses intentions à l’oral ou par écrit, on lance le résultat, puis on ajuste. Il arrive aussi de copier-coller. Et souvent, ça marche.

Cette approche baisse fortement la barrière d’entrée du développement logiciel. Aujourd’hui, un débutant peut créer une application fonctionnelle en une heure ou deux en discutant avec un assistant IA dans un IDE. Pour quelqu’un qui a commencé avec des éditeurs très simples, le décalage est assez vertigineux. Les ambitions de la Silicon Valley autour de l’automatisation du code deviennent beaucoup plus visibles dans les outils du quotidien.

Des éditeurs classiques aux IDE intelligents

Quand j’ai commencé à coder adolescent, j’utilisais des éditeurs simples, puis des IDE classiques comme Eclipse ou Visual Studio. Pendant 16 ans, mon outil principal a été PyCharm. Il était solide, fiable, avec de l’autocomplétion basique, de la coloration syntaxique et quelques refactorings automatiques. Le développeur gardait toute l’exécution en main. Il fallait connaître le langage, lire la documentation, chercher sur Google ou StackOverflow dès qu’un bug bloquait le projet.

Les outils ont avancé par étapes. VS Code a amélioré le confort. Les linters sont devenus plus efficaces. GitHub Copilot ou TabNine ont ensuite commencé à suggérer du code automatiquement. La bascule la plus nette, je l’ai vécue récemment avec des IDE intégrant un assistant, comme Cursor, que j’ai adopté il y a peu. Il existe aussi des solutions comme Bolt.new, Windsurf, l’IDE IA de Codeium, et même un Firebase Studio orienté développement assisté par IA.

L’IDE dépasse désormais la complétion d’une ligne. Il comprend une intention. Dans Cursor, je peux écrire en langage naturel, crée une classe User avec authentification JWT. L’outil génère la classe correspondante, parfois le fichier entier, en quelques secondes. Le résultat demande encore une relecture, mais l’écart avec l’autocomplétion classique est énorme.

Cette évolution se voit dans toute l’industrie. Une enquête de 2024 indique que 75 % des développeurs ont déjà essayé un outil d’IA pour coder et que 82 % l’utilisent régulièrement pour écrire du code. GitHub Copilot compte plus d’un million d’utilisateurs. Ces assistants prennent peu à peu une place aussi naturelle dans le workflow d’un développeur que la compilation ou le contrôle de version.

On est passé du je code tout moi-même à je code avec un copilote IA à côté de moi. Après avoir utilisé ces nouveaux IDE intelligents, le retour aux anciens réflexes devient difficile. Quand l’outil comprend bien la demande, la sensation de fluidité est très forte.

Une productivité multipliée, entre x30 ressenti et gains mesurés

Le gain de productivité est le premier choc. Sur certaines tâches, j’ai parfois l’impression d’être devenu un super-développeur, capable de produire en une journée ce qui m’aurait pris un mois. Sur des tâches routinières, le ressenti peut approcher le x30. L’IDE fait en 2 minutes ce que j’aurais fait en une heure. C’est un cas favorable, évidemment, mais l’effet devient très visible quand tout s’enchaîne correctement.

Un exemple simple revient souvent dans mon quotidien, la création de la structure d’un nouveau micro-service backend. Avant, je créais les fichiers, j’écrivais le boilerplate de l’API REST, je configurais la base de données, puis je branchais les premières routes. Maintenant, je décris le service en quelques phrases, avec les entités principales et les endpoints attendus. L’assistant génère une bonne partie du squelette. En quelques minutes, j’ai quelque chose qui tourne. Avant, la mise en place pouvait déjà me prendre la matinée.

Ce x30 reste un ressenti dans des cas idéaux. Les études plus prudentes parlent par exemple d’un développement 2 fois plus rapide en moyenne grâce à l’IA, ou de 55 % de temps gagné sur des tâches de programmation dans une recherche de Microsoft/GitHub. Même un doublement de productivité change beaucoup de choses à l’échelle d’un projet. Dans mon quotidien, je boucle parfois des fonctionnalités entières avec l’impression d’avoir un collègue très compétent, disponible 24h/24, qui code extrêmement vite.

Il y a aussi le confort mental. Je passe moins de temps sur des bugs idiots ou à retrouver la bonne syntaxe d’une fonction. L’IA absorbe une partie de la charge, ce qui me laisse plus d’énergie pour l’architecture et les choix de conception. Un développeur sur le site de Cursor raconte que l’outil anticipe exactement ce que je veux faire 25 % du temps, au point que j’ai l’impression de coder à la vitesse de la pensée (cursor.com). Je comprends très bien cette phrase. Quand le contexte est bon, on a presque l’impression de penser le logiciel et de le voir apparaître.

Le vibe coding au quotidien avec des tâches simplifiées

Dans mon travail de tous les jours, le vibe coding m’aide surtout sur des tâches précises. Elles sont rarement les plus visibles, mais elles ralentissent souvent un projet.

• Débogage rapide. Je reste moins longtemps bloqué sur un bug obscur. Je peux décrire le problème à l’assistant, par exemple telle fonction renvoie une erreur X dans telles conditions. Il m’oriente souvent vers une piste correcte, puis propose parfois directement le correctif. J’ai eu un bug sur une API qui renvoyait les mauvaises données. J’ai montré le code fautif à l’IA, qui a repéré un appel de fonction mal placé. En quelques minutes, le bug était corrigé. Sans ça, j’aurais peut-être passé une demi-journée dessus.

• Recherche de syntaxe oubliée. Je peux éviter 20 minutes dans la documentation pour retrouver un paramètre pandas ou la bonne méthode d’une API. Si j’hésite entre pandas.DataFrame.dropna() et un hypothétique drop_values(), je peux demander directement dans l’IDE, Comment supprimer les valeurs nulles dans un DataFrame pandas déjà. L’assistant répond avec la bonne méthode, souvent avec un exemple. C’est proche d’un StackOverflow intégré, sans quitter l’éditeur.

• Implémentation de fonctionnalités. Quand je conçois une nouvelle feature, je peux écrire le comportement attendu en langage naturel. Par exemple, Ajouter une fonctionnalité de reset de mot de passe. Un utilisateur entre son email, on génère un token unique, envoie un email avec un lien, et on permet la réinitialisation du mot de passe via ce lien. Dans un IDE intelligent, l’IA génère une première ébauche pour les routes, la logique de création du token et parfois même un modèle de mail. Il reste ensuite à ajuster, tester et sécuriser. La partie répétitive est déjà largement préparée.

Ces cas expliquent pourquoi le vibe coding me fait gagner du temps. Des tâches qui demandaient beaucoup d’allers-retours deviennent plus fluides. Je peux rester concentré sur la logique métier et la qualité du produit, au lieu de perdre de l’énergie sur du boilerplate ou des oublis de syntaxe.

Les limites du vibe coding et la responsabilité du développeur

Une IA qui écrit du code rend certaines étapes plus rapides. Elle ajoute aussi de nouveaux risques. À force de coder au feeling, j’ai vu les limites de cette approche. L’assistant peut être très efficace. Les décisions d’architecture, la compréhension produit et la revue de sécurité restent côté humain.

• Des choix d’architecture fragiles. Si la demande manque de précision, l’IA peut coder au plus direct. Dans le développement d’un jeu en vibe coding, un utilisateur a constaté que le modèle mettait toutes les fonctionnalités dans un seul fichier JS, au lieu de séparer l’affichage, la gestion d’état ou le menu. Résultat, un code très couplé, avec une séparation des responsabilités presque absente. J’ai vu des cas proches en web. L’IA me proposait d’appeler une nouvelle API, sans propager correctement cet appel dans l’architecture front-end. Le code allait vite et introduisait des incohérences. L’IA peut accélérer. L’architecture reste notre responsabilité.

• Des instructions floues donnent des résultats flous. L’IA travaille avec ce qu’on lui donne. Dire améliore ce module pour qu’il soit plus rapide sans préciser le contexte peut produire des modifications inutiles ou absurdes. Un développeur raconte qu’en vibe coding, s’il écrivait seulement Make it better, l’IA partait dans des changements imprévus. J’ai vécu la même chose avec des prompts trop vagues. Le bon réflexe consiste à formuler une demande presque comme une mini-spec. Sinon, le temps gagné disparaît dans les corrections.

• Du code boîte noire. Quand l’IA génère beaucoup de code, la tentation d’accepter sans tout lire devient forte. Karpathy lui-même a reconnu cliquer sur Accepter tout sans lire les diffs de code (nmn.gl). Le risque tient à la perte de compréhension de son propre code. J’ai eu le cas sur un projet où le code avançait plus vite que ma capacité à le suivre. Quand un bug subtil est apparu, j’ai dû me replonger longtemps dans une base que je maîtrisais mal. Depuis, je garde une règle simple. Même si l’IA propose, je relis et je comprends chaque ajout avant de l’intégrer.

• Risques de sécurité. L’IA peut proposer du code qui fonctionne en apparence, avec une faille au milieu. Un exemple réel m’a marqué. Un code d’authentification généré par IA exposait les clés API en clair côté client. L’interface semblait correcte, mais l’inspection réseau montrait la clé OpenAI transmise publiquement. J’ai aussi vu l’assistant suggérer de stocker un mot de passe en dur dans le code, ou d’ignorer une validation d’entrée utilisateur. Le code généré mérite la même lecture qu’une merge request écrite par un junior rapide. Utile, parfois imprudent.

Le vibe coding fonctionne donc comme un accélérateur. Karpathy prévient d’ailleurs que cette approche convient mieux à des petits projets improvisés du week-end qu’à du développement logiciel sérieux en production. Pour des projets plus ambitieux, la rigueur reste indispensable. Il reste a une architecture cible, des tests, une revue du code généré et la compréhension de chaque modification. L’IA écrit du code. La décision de l’intégrer reste humaine.

Un développeur solo peut aller beaucoup plus loin avec Shoot IA

Shoot IA est une plateforme web que j’ai développée entièrement en solo, en utilisant à fond les nouveaux outils assistés par IA. Le concept consiste à générer des portraits photo professionnels à partir de les images grâce à l’IA. En quelques mois, sans équipe derrière moi, j’ai lancé le produit et attiré plus de 10 000 utilisateurs sur shootia.fr. C’est un cap que beaucoup de startups cherchent à atteindre avec une équipe complète, entre front, back, devops et parfois beaucoup plus de monde.

Personnellement, ce résultat m’a marqué. Seul avec un IDE intelligent, j’ai pu accomplir ce qui aurait probablement demandé 5 à 10 développeurs il y a quelques années, ou une équipe de 50 personnes dans une structure plus traditionnelle.

Pour Shoot IA, j’ai utilisé Cursor et d’autres assistants pour accélérer le front-end, générer des templates d’email, tester plusieurs implémentations d’algorithmes d’image et débloquer des choix techniques. Quand j’hésitais sur une techno ou une approche, l’assistant m’aidait comme un collègue expert disponible à la demande. J’ai pu explorer rapidement plusieurs pistes, alors que seul, sans ces outils, chaque détour aurait coûté beaucoup plus cher en temps.

Le résultat est une plateforme complète, avec frontend, backend, entraînement de modèles IA et interface utilisateur. Tout a demandé du cadrage, de la relecture, des corrections et des décisions. L’IA a absorbé une partie importante de l’exécution.

Mon cas s’inscrit dans une vague plus large de fondateurs solo qui utilisent l’IA pour lancer des produits. En 2024, 36 % des startups étaient fondées par une personne seule, deux fois plus qu’en 2017. Des exemples comme Bhanu Teja, qui a codé en un week-end le prototype de SiteGPT, un outil de chatbot personnalisé, avant de le transformer en SaaS rentable à 15 000 $/mois, ou Samanyou Garg, créateur solo de l’assistant rédactionnel Writesonic, passé à plus de 10 millions d’utilisateurs en 3 ans, montrent que le passage à grande échelle peut aussi venir de petites équipes, voire d’une seule personne.

La réussite en solo grâce à l’IA reste loin d’être automatique. La possibilité existe maintenant. Un développeur déterminé, qui maîtrise le vibe coding et les outils modernes, peut construire beaucoup plus qu’avant avec les mêmes journées.

À titre personnel, passer de projets perso limités, faute de temps et de bras, à un service comme Shoot IA avec des milliers d’utilisateurs a été très motivant. J’ai le sentiment qu’un développeur équipé de ces outils peut devenir une petite équipe à lui seul, au moins jusqu’à un certain point. À un moment, s’entourer redevient nécessaire pour la maintenance, le support client ou l’accélération du développement. Ce moment arrive plus tard. L’IA permet de tenir seul plus longtemps, parce qu’elle absorbe une partie de la charge.

Le rôle du développeur change déjà

Le vibe coding et les assistants de code à base d’IA ont profondément changé ma manière de développer. Après 17 ans de code, je n’avais jamais vu un outil modifier aussi vite ma productivité et mes habitudes. Je pense que cela déplace surtout une partie du travail des développeurs.

Les tâches répétitives et la plomberie du code deviennent de plus en plus automatisées. C’est plutôt une bonne nouvelle. Le temps libéré peut aller vers la conception, l’architecture, la créativité et les décisions produit. Comme le note la CTO de GitLab, les ingénieurs logiciels restent indispensables pour guider la stratégie, superviser la qualité du code et repérer les bugs ou failles que la machine peut introduire. Dans ma pratique, je me sens plus capable avec l’IA, et toujours responsable de ce que je livre.

Cette évolution demande quand même aux développeurs de s’adapter. Ceux qui adoptent ces outils prennent une avance nette sur ceux qui les ignorent. Un codeur qui utilise bien l’IA peut livrer plus vite, produire davantage et limiter certaines erreurs, à condition de garder une vraie discipline de revue. À l’inverse, refuser ces outils revient à se priver d’un levier qui devient standard dans l’industrie. On a souvent parlé du développeur 10x, dix fois plus productif que la moyenne. L’IA rend cette idée beaucoup plus concrète pour davantage de développeurs.

Moi qui ai commencé en tapant laborieusement du code dans un éditeur basique, je regarde cette évolution avec enthousiasme. Coder ressemble de plus en plus à une discussion avec un assistant très compétent. Le vibe coding a déjà changé ma façon de travailler, et je pense que les développeurs ont beaucoup à gagner à apprendre à collaborer avec ces outils.

Cette évolution garde les développeurs dans la boucle et leur demande de monter en niveau. Il reste a mieux cadrer les demandes, relire plus sérieusement, comprendre l’architecture et garder la responsabilité du code livré. Ceux qui sauront travailler avec l’IA auront un avantage clair. Les autres risquent surtout de voir leur méthode de travail vieillir très vite.