Vibe coding sans AI slop : comment l’équipe de targetai a multiplié par 12 la vitesse de développement

Le vibe coding ne consiste pas à demander à l'IA d'écrire tout le code et d'appuyer sur « deploy ». C'est la capacité à travailler avec des modèles de langage comme vous le feriez avec un développeur junior très rapide mais occasionnellement hallucinant : poser les bonnes questions, vérifier le résultat, maintenir la vision architecturale en tête. L'équipe de targetai a passé plusieurs mois à affiner cet équilibre sur des projets réels et a documenté le résultat : une accélération de 8 à 12 fois sans perte de qualité — si cela est bien fait.

Le terme « vibe coding » lui-même a été introduit par Andrej Karpathy au début de 2025. L'idée est simple : au lieu d'écrire chaque ligne manuellement, le développeur décrit l'intention en langage naturel, et l'outil LLM — Cursor, GitHub Copilot, Claude Code, Cline — génère l'implémentation. La vitesse des itérations se multiplie : vous pouvez construire un prototype fonctionnel en heures au lieu de semaines.

Le problème est que parallèlement à la popularité croissante de l'approche est venu son reflet sombre — le neural slop. Il s'agit de code qui semble convaincant, se compile, passe les tests de base, mais trois mois plus tard devient un chaos impossible à maintenir : personne dans l'équipe ne comprend pourquoi cette partie ou cette autre est écrite de cette façon. Le LLM n'explique pas ses décisions architecturales — il les prend simplement.

Les ingénieurs de targetai se sont demandé : pouvons-nous systématiser le travail avec les LLMs de manière à gagner en vitesse sans accumuler de dette technique ? Leur réponse est oui, mais cela nécessite des pratiques spécifiques.

Première : les LLMs fonctionnent mieux sur des tâches avec un contexte strictement limité. Pas « construis une fonction d'authentification », mais « implémente la fonction validateToken dans le fichier auth/utils.ts, qui prend une chaîne JWT et retourne userId ou null si le token est invalide ».

Deuxième : la révision de code ne peut pas être déléguée au modèle lui-même. Vous avez besoin d'une personne qui comprend exactement ce qu'elle examine — et pourquoi certain code est mauvais, pas seulement comment il semble.

Troisième : les décisions architecturales sont prises avant que l'IA commence à générer l'implémentation. L'IA est l'exécuteur, pas l'architecte.

Les chiffres des expériences : le cycle de développement pour les nouvelles fonctionnalités a été réduit 8 à 12 fois — de plusieurs jours à quelques heures. Le nombre d'itérations avant le déploiement a diminué. Ce qui est crucial, c'est que le niveau des incidents en production n'a pas augmenté. Cela contredit la peur la plus répandue : que l'accélération par IA signifie inévitablement plus de bugs en production. Avec la bonne méthodologie — ce n'est pas le cas.

Chez targetai, il n'y a pas de position séparée d'AI-engineer ou de prompt engineer : l'équipe est arrivée à ces pratiques organiquement, par le biais des erreurs et des itérations.

En pratique, l'approche fonctionne ainsi. Chaque développeur utilise le LLM comme un programmeur en binôme personnel, mais avec des règles d'hygiène. Ne jamais copier le code généré sans le lire ligne par ligne. Pas de requêtes vagues — mieux vaut trois prompts précis qu'un flou. Les tests sont écrits avant la génération de l'implémentation : cela filtre immédiatement les options non fonctionnelles lors de 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 — cela améliore considérablement la précision de la génération pour les tâches spécifiques au domaine.

Le vibe coding en tant que pratique est sorti du cycle de hype et devient une compétence d'ingénierie fondamentale — aussi basique que de savoir lire une stack trace ou d'écrire une demande de tirage claire. La question n'est plus de savoir s'il faut utiliser des modèles de langage dans le développement, mais comment le faire consciemment.

L'expérience de targetai montre : avec des flux de travail correctement structurés, un assistant IA ne remplace pas l'ingénieur — il multiplie sa productivité plusieurs fois. Le prix de cette multiplication — la discipline, la pensée critique, et la volonté de ne pas faire confiance au beau code simplement parce qu'il a été écrit rapidement.