Article original : How to Use Vibe Coding Effectively as a Dev
Il peut sembler que tout le monde soit un vibe coder ces jours-ci, et le prompting semblait devoir devenir le nouveau codage. Mais ce code généré par l'IA est-il vraiment déployable ?
Se vanter sur les réseaux sociaux d'un script astucieux est une chose, mais pousser une application issue du vibe coding en prod comporte de nombreux risques de sécurité.
Avec autant d'outils de développement IA sur le marché désormais, les code reviews deviennent plus critiques que jamais.
Cet article explorera ce que signifie le vibe coding et comment les revues de code devraient s'adapter à l'ère de l'IA.
Table des matières :
Qu'est-ce que le Vibe Coding ?
Au début de 2025, le chercheur en IA Andrej Karpathy a popularisé le terme vibe coding pour décrire une nouvelle façon de développer dans laquelle on « s'abandonne complètement aux vibes » et laisse l'IA écrire le code pendant que l'on se concentre sur l'intention de haut niveau.
Un développeur exprime la fonctionnalité souhaitée en langage naturel, et un système d'IA (comme un LLM) génère le code source pour l'implémenter.
Cette approche de codage par prompt permet même aux débutants de produire du code fonctionnel sans connaissance approfondie des langages de programmation. Karpathy a plaisanté en disant qu'avec les agents IDE avancés (comme le mode Composer de Cursor), « je touche à peine au clavier... Je fais toujours 'Accept All', je ne lis plus les diffs... et ça marche la plupart du temps ».
Ainsi, le vibe coding consiste à coder au feeling et à faire confiance à l'IA pour gérer le gros du travail.
Comment mettre en œuvre le Vibe Coding en pratique
En pratique, le vibe coding implique généralement l'utilisation d'assistants IA et l'adaptation de votre workflow vers un style plus interactif et piloté par les prompts.
Voici un aperçu de la façon dont vous pouvez « vibe coder » un projet :
Étape 1 : Choisir un assistant IA
Sélectionnez un environnement de développement qui prend en charge la génération de code par IA. Les choix populaires incluent Cursor et GitHub Copilot.
Étape 2 : Définir vos besoins
Au lieu d'écrire du code boilerplate, décrivez ce que vous voulez construire. Fournissez à l'IA un prompt spécifique détaillant les fonctionnalités. Plus vous donnez de contexte et de détails, mieux l'IA pourra répondre à votre intention.
Par exemple, lorsque j'ai effectué une inspection SEO pour mon site web, DevTools Academy, j'ai utilisé ce prompt dans Cursor :
« Agis maintenant en tant qu'ingénieur produit senior et stratège UX. Évalue et améliore https://www.devtoolsacademy.com avec un regard pratique et sans fioritures.
Périmètre :
UX
SEO et SEO technique
Positionnement et message
Rédaction (copywriting) et architecture de l'information
Ce qu'il faut ajouter pour se démarquer dans l'espace des outils pour développeurs. »
Ce prompt fonctionne bien car il donne à l'IA un rôle clair, un périmètre défini et une intention spécifique. L'IA sait qu'elle ne se contente pas de corriger le SEO, mais qu'elle examine également comment le site communique sa valeur aux développeurs. Cette combinaison de clarté et de contexte produit des informations exploitables au lieu de suggestions superficielles.
Ci-dessous se trouve une capture d'écran de cet audit en cours, montrant comment j'ai examiné le code, les métadonnées et les recommandations UX côte à côte.
Vous pouvez consulter le code complet sur mon blog open source ici et regarder les Pull Requests fermées. Cela vous aidera à apprendre comment j'utilise tous ces agents de codage sur une application prête pour la production.
Étape 3 : Réviser le code
L'IA produira un code initial basé sur votre prompt. Considérez cela comme un prototype – ce n'est pas parfait. Exécutez le code et voyez comment il se comporte.
Regardons un exemple : ici, CodeRabbit examine l'une de mes Pull Requests sur GitHub. J'avais poussé un petit correctif pour trier correctement les articles de blog et m'assurer que le flux RSS reflète la dernière date de publication. En quelques secondes, CodeRabbit a analysé le diff, compris l'intention derrière mon changement et expliqué exactement ce que fait le nouveau code.
Il a souligné que le correctif trie désormais les articles avant de les mapper, utilise les données triées pour les éléments et la lastBuildDate, et assure un ordre chronologique approprié dans tout le flux.
C'est comme avoir un réviseur senior qui non seulement vérifie la syntaxe, mais valide également la logique et confirme que votre raisonnement tient la route.
Ceci est juste un rappel pour s'attendre à des imperfections. Le vibe coding adopte un état d'esprit « coder d'abord, affiner plus tard ». Cela signifie que vous obtenez rapidement une version fonctionnelle, puis que vous l'améliorez de manière itérative. Vous pourriez passer par plusieurs cycles de prompt -> code -> test -> ajustement.
Étape 4 : Valider, déboguer, polir
Une fois que le code généré par l'IA répond à vos attentes, effectuez une revue finale.
Tout au long du processus, l'idée centrale est que vous collaborez avec l'IA. L'agent IA sert d'assistant de codage, faisant des suggestions en temps réel, automatisant le boilerplate fastidieux et générant même des modules entiers en votre nom.
Pourquoi le code généré par Vibe Coding n'est-il pas prêt pour la production ?
Le vibe coding va vite : vous décrivez l'intention, l'IA produit quelque chose qui tourne, et vous passez au prompt suivant. Ce qui manque, c'est le travail lent et ingrat qui transforme habituellement un brouillon en logiciel livrable, comme le contexte partagé, l'alignement architectural, la vérification et la documentation.
L'IA génère du code plausible basé sur des modèles qu'elle a vus. Mais elle ne comprend pas l'historique de votre équipe, les contraintes de votre système ou les règles implicites qui maintiennent la cohérence de l'ensemble au fil du temps.
Ce décalage apparaît dès qu'une démo « qui marche sur ma machine » rencontre une base de code réelle.
Explorons les pièges courants du code issu du vibe coding, afin que vous sachiez quoi surveiller. Ensuite, dans la section de la liste de contrôle ci-dessous, je présenterai des stratégies pratiques pour traiter ou prévenir chaque problème.
Les lacunes de contexte sont la première faille.
L'IA ne voit que ce que vous lui montrez, il est donc facile pour elle de faire le bon choix local et le mauvais choix global : dupliquer une logique qui existe déjà, choisir des valeurs par défaut qui entrent en conflit avec des décisions antérieures, ou introduire des fonctions qui ne respectent pas les limites du domaine.
Le résultat est un code qui semble raisonnable isolément mais qui entre en collision avec les hypothèses et conventions existantes une fois intégré.
Ces lacunes mènent directement à des angles morts d'intégration.
Les brouillons ignorent souvent les détails concrets de votre environnement – utilitaires partagés, préoccupations transversales, configuration, hooks de déploiement et politiques opérationnelles. Les interfaces peuvent sembler alignées au premier coup d'œil et pourtant échouer à l'exécution parce que le brouillon ne correspond pas à la façon dont votre système compose les modules, gère les erreurs ou gère l'état entre les services.
Le risque le plus grave est la sécurité par omission.
L'IA inclut rarement une validation robuste des entrées, des chemins d'authentification et d'autorisation clairs, ou une limitation de débit (rate limiting) à moins que vous ne le précisiez. La gestion des secrets et la journalisation ont tendance à être superficielles ou absentes. Cela laisse des points d'exposition courants comme les gestionnaires de requêtes, les processeurs de tâches et les points de terminaison de webhooks sans les vérifications qui empêchent l'injection, le SSRF, l'assignation de masse ou l'exfiltration de données.
Même lorsque la surface semble propre, l'absence de contrôles de sécurité explicites signifie que vous faites confiance à des paramètres par défaut que vous n'avez pas choisis.
Les tests et les preuves de correction sont maigres.
La qualité en pâtit également de manière plus discrète. Au-delà du « ça tourne », il y a peu de choses pour démontrer le comportement dans les cas limites ou pour se prémunir contre les régressions.
La performance et l'évolutivité restent des inconnues : des appels réseau supplémentaires, des modèles N+1 et des boucles quadratiques s'immiscent parce que personne ne les a mesurés. Les dépendances et les environnements dérivent car les versions ne sont pas figées, l'infrastructure n'est pas déclarée et la configuration ne vit que dans la tête de l'auteur, ce qui rend le comportement différent d'une machine à l'autre et en CI.
L'opérabilité est à la traîne.
Un manque de métriques, l'absence de sondes de santé/disponibilité et l'inexistence de runbook rendent les pannes plus difficiles à détecter et plus lentes à résoudre. Ajoutez à cela les préoccupations de qualité des données et de conformité (gestion des PII, hypothèses d'encodage, obligations de licence transitives), et vous obtenez un code qui fait de belles démos mais n'est pas prêt pour les exigences de fiabilité, de sécurité et d'audit de la production.
En résumé, le vibe coding accélère la rédaction mais saute la compréhension partagée et les preuves qui rendent un logiciel sûr à livrer.
Tant que ces lacunes ne sont pas comblées, c'est un prototype, pas une version stable.
Directives pour les revues de code IA
Votre équipe doit maintenir les standards d'ingénierie pré-IA comme référence, incluant la sécurité, les tests, la lisibilité, la maintenabilité, la performance et la documentation. L'IA devrait changer la vitesse à laquelle vous rassemblez les preuves de ces standards, et non la quantité de preuves requises. En d'autres termes, utilisez l'IA pour accélérer le chemin vers votre barre d'exigence existante, jamais pour l'abaisser.
En utilisant l'IA, vous pouvez générer du code rapidement. Mais si les revues prennent le même temps (ou plus de temps), vous perdez une partie du bénéfice. L'objectif n'est pas d'assouplir les standards, c'est de raccourcir le temps nécessaire pour prouver que vous les avez respectés. Cela signifie superposer l'automatisation (tests, analyse statique, scans de secrets, SCA) et la revue assistée par IA pour attraper rapidement les problèmes évidents afin que les réviseurs humains puissent se concentrer sur l'intention, l'architecture et le risque.
Des assistants bien utilisés peuvent aider ici. Par exemple, des outils comme CodeRabbit, GitHub Copilot PR Reviewer, Claude Code, Bugbot de Cursor, Graphite AI Review et Greptile peuvent mettre en évidence des bugs potentiels, des failles de sécurité, des écarts de style et des intentions mal alignées, et résumer les diffs pour un contexte plus rapide. Traitez-les comme des accélérateurs pour votre processus existant, et non comme des remplaçants du jugement humain.
Processus de revue de code dans le Vibe Coding
Les fondamentaux d'une bonne revue de code n'ont pas changé – et en fait, ils sont plus critiques que jamais.
Voici quelques principes clés pour maintenir la vitesse sans sacrifier la qualité.
1. Faire confiance, mais vérifier.
Un réviseur suppose généralement que l'auteur comprend le système. Avec le code issu du vibe coding, l'« auteur » peut être une IA avec un contexte limité. Si quelque chose semble étrange ou inutile, questionnez-le. Exécutez le code, ajoutez/exécutez des tests, ou demandez au développeur/à l'IA des éclaircissements sur l'intention et les contraintes.
2. Ne laissez pas les revues devenir un goulot d'étranglement.
Le vibe coding génère du code rapidement. Si la revue humaine prend autant de temps que l'écriture manuelle du changement, vous avez annulé le gain.
Combattez cela en mettant l'accent sur l'automatisation en amont : exécutez des tests unitaires/d'intégration, l'analyse statique (lint/SAST), les scans de secrets, le SCA et les vérifications de performance de base dans la CI pour éliminer le bruit. Ensuite, les réviseurs passent leur temps sur les compromis de conception, les cas limites et les risques. L'équilibre est : des standards élevés, des preuves plus rapides.
3. Utilisez judicieusement les revues de code par IA
L'IA peut aider à réviser le code tout comme elle aide à le générer. Les outils modernes de « pair reviewer » scannent une PR et font remonter les bugs probables, les problèmes de sécurité, les tests manquants ou les violations de style en quelques minutes, en plus de donner des résumés en langage naturel du changement.
Les outils que vous pouvez envisager incluent CodeRabbit, GitHub Copilot PR Reviewer, Claude Code, Cursor Bugbot, Graphite et Greptile. Beaucoup s'intègrent au CLI/IDE et à GitHub/GitLab pour laisser des commentaires exploitables.
Considérez-les comme des réviseurs de première passe rapides qui augmentent la couverture et la cohérence entre les Pull Requests.
4. Le jugement humain est toujours irremplaçable.
Même le meilleur réviseur IA n'est qu'un assistant. Gardez les humains responsables de l'exactitude, de la posture de sécurité, de l'adéquation architecturale et de l'impact utilisateur. Un modèle sain est : première passe par l'IA > deuxième passe par l'humain qui inspecte les invariants, les modes de défaillance et la maintenabilité à long terme.
5. Maintenez une barre de qualité élevée.
Il est tentant d'accepter que « ça tourne » quand une IA l'a écrit. Ne le faites pas. Les parties prenantes attendent toujours que le logiciel soit robuste, sécurisé et maintenable. Conservez les standards DRY, de lisibilité et de testabilité. Insistez sur la validation des entrées, les vérifications d'autorisation (authZ) le cas échéant, et une journalisation/métriques sensées. Si vous ne pouvez pas prouver que vous avez atteint le niveau requis, c'est que vous ne l'avez pas atteint.
6. Éduquer et documenter
Lorsque les réviseurs trouvent des bugs ou des failles de sécurité dans le code généré par l'IA, capturez la leçon.
Mettez à jour les guides internes avec des modèles tels que « Lors de la génération de gestionnaires, validez et limitez les entrées, ajoutez des limites de débit, enregistrez les IDs de requête, évitez les requêtes N+1 et assainissez les sorties visibles par l'utilisateur. » Avec le temps, intégrez-les dans les prompts, les templates, les structures de repo et les vérifications CI afin que le prochain brouillon d'IA commence plus près du résultat final.
Liste de contrôle pour réviser le code généré par IA
Avant d'approuver tout changement issu du vibe coding, rendez les standards explicites et vérifiables. Utilisez cette liste de contrôle pour confirmer le comportement, la sécurité, la performance, l'intégration et la documentation afin que le brouillon obtenu de l'IA devienne un code que vous pouvez livrer en toute sécurité.
Voici une liste de contrôle qu'un réviseur humain devrait parcourir avant d'approuver un résultat de vibe coding :
1. Définir l'objectif du code (périmètre et non-objectifs).
Soyez explicite sur ce que ce changement fait et ne fait pas. Liez-le à une user story/ticket et signalez les non-objectifs afin que des changements d'IA « utiles » ne s'y glissent pas.
2. Vérifier X et Y (comportement et cas limites).
Soyez clair sur ce que vous vérifiez. Par exemple, vérifiez l'analyse des entrées et les limites de pagination, vérifiez que les chemins d'erreur renvoient le statut et le corps corrects, et vérifiez que les écritures en base de données sont idempotentes. Exécutez les tests existants, ajoutez les tests unitaires/d'intégration manquants et reproduisez les entrées limites (vide, nul, énorme, unicode).
3. Effectuer des vérifications de qualité du code (lisibilité, DRY, besoins de refactorisation).
L'IA produit souvent une logique verbeuse ou dupliquée. Assurez-vous que les noms sont significatifs, que les effets secondaires sont clairement énoncés et que la duplication est supprimée ou minimisée. Exécutez des linters/formatters, réduisez les répétitions et extrayez des helpers là où ils aident à la clarté.
4. Analyser l'organisation et la structure (s'assurer qu'il s'intègre à l'architecture).
L'IA écrit du code de manière isolée. Confirmez que le changement utilise les utilitaires, couches et limites existants (domaine/services/contrôleurs/jobs). Vérifiez les imports et le placement des modules, évitez de réinventer des helpers existants et alignez-vous sur les conventions du dépôt.
5. Valider les entrées et les hypothèses (rendre l'implicite explicite).
Listez les hypothèses faites par l'IA (paramètres régionaux/fuseau horaire par défaut, plages autorisées, champs obligatoires). Ajoutez une validation de schéma (DTO/validateurs de classe/JSON Schema). Testez les cas : vide, nul, dépassement de maximum, non-ASCII, enum inattendu, chaînes malveillantes. Et enfin, imposez des limites/timeouts.
6. Effectuer des audits de sécurité (passe minimale).
AuthN/AuthZ : Confirmez que le point de terminaison vérifie l'identité et les chemins d'autorisation ; refusez par défaut.
Entrées : Assainissez/validez les entrées, empêchez l'injection (SQL/NoSQL/commande) et échappez les sorties visibles par l'utilisateur.
Secrets : Pas de secrets dans le code/diff/logs, utilisez un gestionnaire d'env/secrets, et renouvelez toutes les clés de test.
Contrôles d'abus : Ajoutez des limites de débit, des limites de taille et des timeouts sur les opérations réseau et disque. Exécutez SAST/scan de secrets/SCA, et corrigez ou justifiez les résultats.
7. Faire une évaluation de la performance (dès maintenant, à petite échelle).
Recherchez les N+1, les appels réseau inutiles, les boucles non bornées, les tris quadratiques. Ajoutez un micro-benchmark ou effectuez un test de charge rapide pour les chemins critiques. Définissez des cache/timeout/retry sensés avec du jitter le cas échéant.
8. Gérer les dépendances (figer, justifier, minimiser).
Examinez toutes les nouvelles bibliothèques. Sont-elles nécessaires ? Maintenues ? Compatibles avec la licence ? Figez les versions, ajoutez des lockfiles ou supprimez les ajouts transitifs inutilisés.
9. Réviser la documentation (quoi ajouter et où).
Assurez-vous que la documentation est en phase avec le code. L'IA modifie souvent certaines parties ou ajoute des blocs de code à différents endroits tout en résolvant divers problèmes. Ces changements pourraient ne pas se retrouver dans la documentation.
10. Observabilité (voir les problèmes tôt).
Utilisez des logs structurés avec des IDs de requête/trace, des compteurs/timers clés (succès/erreur/latence), des sondes de santé/disponibilité et un tableau de bord de base ou une alerte.
11. Conformité et gestion des données (le cas échéant).
Identifiez toute information personnellement identifiable (PII), documentez la collecte/rétention, assurez le masquage/rédaction dans les logs, vérifiez les licences des dépendances et les contraintes de résidence des données.
Comment travailler efficacement avec les outils d'IA
À ce stade, vous pouvez probablement voir pourquoi il est très important de comprendre les compétences réelles impliquées dans le développement assisté par IA.
Il y a une différence assez importante entre un développeur expérimenté qui utilise des outils d'IA pour l'aider à en faire plus, et un débutant qui pense que l'IA peut construire le prochain Facebook ou Google avec un simple prompt.
Un développeur inexpérimenté demandera à l'IA quelque chose comme « Hé, construis-moi Twitter et ne fais aucune erreur ».
Mais un développeur expérimenté qui possède des bases solides pourrait dire quelque chose comme :
« IA, nous construisons une réplique de Twitter. Utilise
$SQL\_Database, utilise$Language, évite$Common\_Pitfalls, suis$Standard\_Practices. »« Le code généré est sujet au problème X, implémente ce correctif. »
« L'implémentation de
$Xest défectueuse à cause de$Y, fais$Zà la place. »
Comme vous pouvez le voir, vous devez toujours connaître le comment et le pourquoi et ce qui dépend de quoi. Souvent, vous devrez simplement effectuer les changements manuellement, car ce sera plus rapide. Et vous ne voulez pas externaliser la partie réflexion critique, qui est la partie que l'IA ne peut pas réellement faire.
Les LLM sont bons pour la récupération d'informations. Si vous ne savez rien de ce que vous cherchez, alors demander à une IA ne sera pas très utile (ni très fiable). Mais si vous avez une idée, des connaissances de base/du contexte et les compétences pour vérifier les réponses de l'IA, alors cela peut être vraiment utile.
Le mois dernier, j'ai partagé dans ma newsletter à quoi ressemble ma boucle de codage actuelle en pratique.
Je rédige avec Claude Code (ou Copilot/Cursor), j'ouvre une Pull Request et je laisse un réviseur IA comme CodeRabbit (ou Copilot PR Reviewer / Cursor Bugbot ou Greptile) faire la première passe. La CI exécute les tests et les scans.
Je répète jusqu'à ce que tout soit au vert et que la PR soit prête à être fusionnée. C'est rapide, mais c'est toujours discipliné.
Si vous voulez comprendre pourquoi ce genre de workflow devient essentiel, lisez cet article : L'ère du nettoyage de la bouillie d'IA a commencé. J'y parle de ce qui se passe dans l'ingénierie assistée par IA, où générer du code est facile, mais le garder propre et prêt pour la production demande de l'expérience – et vous devez avoir de bonnes compétences en programmation.
Conclusion
Le code généré par l'IA peut booster la productivité – mais la valeur en production provient toujours d'un logiciel robuste, sécurisé et maintenable.
La génération de code sans discernement crée de la dette technique. Mais lorsque vous intégrez l'IA de manière réfléchie, avec des garde-fous, des vérifications, des tests, des contrôles de sécurité et de la documentation, vous pouvez aller plus vite sans abaisser vos standards.
C'est tout pour cet article. J'espère que vous avez appris quelque chose de nouveau aujourd'hui.
Si vous avez des questions sur les revues de code, l'ingénierie, les startups ou le business en général, retrouvez-moi sur Twitter : @TheAnkurTyagi. Je serais ravi d'en discuter.
Vous voulez lire plus d'articles intéressants comme celui-ci ?
Vous pouvez en lire davantage sur les derniers outils de développement comme celui-ci sur mon site web.