Le vibe coding sans bouillie d'IA : comment l'équipe de targetai a accéléré le développement par 12

Le vibe coding ne consiste pas à laisser l'IA écrire tout le code puis à cliquer sur « deploy ». C'est l'art de travailler avec les modèles de langage comme avec un développeur junior très rapide, mais qui hallucine parfois : poser les bonnes questions, vérifier le résultat, garder la vision d'architecture en tête. L'équipe de targetai a passé plusieurs mois à affiner cet équilibre sur des projets réels et a consigné un résultat : une accélération de 8 à 12 fois sans perte de qualité, à condition de bien faire les choses.

Le terme « vibe coding » a été introduit par Andrej Karpathy début 2025. L'idée est simple : au lieu d'écrire chaque ligne à la main, le développeur décrit son intention en langage naturel, et un outil LLM — Cursor, GitHub Copilot, Claude Code, Cline — génère l'implémentation. La vitesse d'itération est multipliée : un premier prototype fonctionnel peut voir le jour en quelques heures plutôt qu'en plusieurs semaines.

Le problème, c'est que la popularité de l'approche a amené son revers sombre : la bouillie d'IA. Il s'agit d'un code qui paraît convaincant, compile et passe les tests de base, mais qui, trois mois plus tard, devient un magma impossible à maintenir. Personne dans l'équipe ne comprend pourquoi telle partie a été écrite ainsi. Un LLM n'explique pas ses choix d'architecture : il les prend, tout simplement.

Les ingénieurs de targetai se sont demandé s'il était possible de systématiser le travail avec les LLM pour gagner en vitesse sans accumuler de dette technique. Leur réponse est oui, mais cela exige des pratiques précises.

Première pratique : un LLM travaille mieux sur des tâches au contexte strictement borné. Pas « fais la fonctionnalité d'authentification », mais « implémente la fonction validateToken dans le fichier auth/utils.ts, qui reçoit une chaîne JWT et renvoie userId, ou null si le jeton est invalide ».

Deuxième : la revue de code ne peut pas être déléguée au modèle lui-même. Il faut une personne qui comprend ce qu'elle vérifie, et pourquoi un code est mauvais, et pas seulement à quoi il ressemble.

Troisième : les décisions d'architecture se prennent avant que l'IA ne commence à générer l'implémentation. L'IA est un exécutant, pas un concepteur.

Les chiffres issus des expériences : le cycle de développement d'une nouvelle fonctionnalité a été divisé par 8 à 12, de plusieurs jours à quelques heures. Le nombre d'itérations avant le déploiement a diminué. Point essentiel : le niveau d'incidents en post-production n'a pas augmenté. C'est un contre-argument à la crainte la plus répandue, selon laquelle accélérer avec l'IA entraîne forcément plus de bugs en production. Avec la bonne méthode, ce n'est pas le cas. Chez targetai, il n'existe pas de poste dédié d'AI engineer ou de prompt engineer : l'équipe est arrivée à ces pratiques de façon organique, à force d'erreurs et d'itérations.

En pratique, l'approche se présente ainsi. Chaque développeur utilise un LLM comme binôme de programmation personnel, mais avec des règles d'hygiène. Aucune copie de code généré sans lecture ligne par ligne. Aucune requête floue : mieux vaut trois prompts ciblés qu'un seul vague. Les tests sont écrits avant la génération de l'implémentation, ce qui écarte immédiatement les variantes défaillantes dès l'étape du prompting. La documentation de la base de code interne est stockée dans un format lisible par machine et chargée automatiquement dans le contexte, ce qui améliore nettement la précision sur les tâches propres au domaine.

Le vibe coding est sorti du cycle du hype et devient une compétence d'ingénierie de base, au même titre que savoir lire une stack trace ou rédiger une pull request claire. La question n'est plus de savoir s'il faut utiliser les modèles de langage dans le développement, mais avec quel degré de discernement. L'expérience de targetai montre qu'avec des processus de travail bien construits, l'assistant d'IA ne remplace pas l'ingénieur : il multiplie sa productivité. Le prix de cette multiplication : discipline, esprit critique et volonté de ne pas se fier à un beau code simplement parce qu'il a été écrit vite.