Qu'est-ce que le vibe coding ?

Le vibe coding est un workflow où l’on construit un logiciel en promptant une IA et en acceptant le code généré, en grande partie sans relecture. Andrej Karpathy a forgé le terme en février 2025 — “fully give in to the vibes, embrace exponentials, and forget that the code even exists” — pour décrire l’acceptation des changements sans lire les diffs, sur des projets jetables de week-end. En un an, le terme a glissé vers toute programmation avec l’IA ; cette entrée garde le sens précis : le trait distinctif n’est pas d’utiliser l’IA — c’est de ne pas relire ce qu’elle a écrit.

Points clés

La boucle, et la ligne de démarcation

Le workflow est une boucle serrée : décrire → l’IA génère → exécuter → recoller erreurs ou envies → recommencer. Simon Willison a tracé la ligne qui garde le terme utile : si vous avez relu, testé et pourriez expliquer chaque changement, “ce n’est pas du vibe coding — c’est du développement logiciel”. Ce n’est pas du gatekeeping ; c’est une étiquette de risque. La même boucle avec relecture, c’est de l’ingénierie assistée par IA, et le mode choisi doit être une décision, pas un accident. En pratique :

// JavaScript — Cloud Code (cloud/main.js)
// The guardrail under a vibe-coded frontend: rules the AI can't skip
Parse.Cloud.beforeSave('Note', (req) => {
  // Whatever the generated client sends, ownership is enforced HERE
  if (!req.user) throw 'Sign in required';
  const acl = new Parse.ACL(req.user); // private by default
  req.object.setACL(acl);
});
// Client keys are publishable; the Master Key stays server-side.
// The vibe-coded UI can be rewritten nightly — these rules survive.

// Flutter / Dart — Back4app Flutter SDK
// The vibe-coded client can be sloppy — the backend isn't
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// iOS / Swift — Back4app Swift SDK
// The vibe-coded client can be sloppy — the backend isn't
var note = Note()
note.text = draft
_ = try await note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// Android / Kotlin — Back4app Android SDK
// The vibe-coded client can be sloppy — the backend isn't
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

Vibe coding vs. ingénierie assistée par IA vs. développement traditionnel

Le spectre, et la règle de passage

Le cadrage qui tranche la plupart des débats sur le vibe coding : c’est une étape, pas une identité. Les prototypes méritent les vibes — c’est le principe même d’un prototype. La règle qu’enseigne l’historique des incidents : le code ne passe d’une étape à l’autre que par la relecture et les tests. Fait notable, Karpathy lui-même est passé à autre chose dans l’année, en distinguant le vibe coding décontracté de l‘“agentic engineering” pour le travail sérieux — l’inventeur du terme donnant raison à ses critiques sur le périmètre.

Ce qui casse vraiment : l’historique des incidents

La section honnête que les explications des éditeurs adoucissent. Les scans du secteur relèvent des failles de classe OWASP dans environ 45 % du code généré par IA, et des outils de revue indépendants ont mesuré dans le code IA environ 1,7× plus de problèmes majeurs que dans des références écrites par des humains (le traitement académique aboutit à des conclusions similaires). Les incidents documentés partagent la même anatomie : en 2025, un scan d’apps construites sur un builder prompt-to-app populaire a trouvé 170 apps sur 1 645 qui laissaient fuir des données utilisateurs — le stack généré était livré avec la sécurité au niveau des lignes de la base de données désactivée (enregistrée comme CVE) ; la couche d’authentification d’une plateforme prompt-to-app laissait n’importe quel utilisateur entrer dans n’importe quelle app privée grâce à un ID devinable ; et une app grand public virale a été piratée quand sa base de données de backend mobile non sécurisée a permis à tout utilisateur authentifié d’extraire les ID et les messages privés des autres. Aucune de ces attaques n’était exotique. Toutes visaient les fondamentaux du backend — règles d’accès, authentification, identifiants — générés en mode permissif et acceptés sans relecture.

C’est dans le backend que ça mord

Relisez la liste des incidents et le schéma se nomme tout seul : le danger n’est pas que l’IA écrive une UI maladroite — un bouton cassé, ça se rafraîchit. Le danger se concentre là où vivent les données : l’authentification, les règles d’accès, les clés d’API collées dans le code client, l’absence de rate limiting. Le code non relu est le plus dangereux exactement là où la relecture compte le plus — et c’est la réponse architecturale : faites de la partie codée au vibe coding la partie à faible enjeu. Un frontend généré au-dessus d’un backend géré inverse le risque : la plateforme fournit une authentification durcie, des ACL en refus par défaut appliquées côté serveur, des clés client publiables avec les vrais secrets gardés ailleurs, et des fonctions côté serveur pour la logique qui ne doit pas vivre dans du code client généré. L’IA peut réécrire l’UI chaque nuit ; elle ne peut pas désactiver des règles qu’elle ne contrôle pas.

La checklist des garde-fous

1. Relisez tout ce qui touche à l’authentification, aux données ou à l’argent — la barrière de passage, non négociable.
2. Créez un point de sauvegarde dans le contrôle de version avant tout “accept all” — une annulation bon marché pour des suggestions coûteuses.
3. Gardez les secrets hors des prompts et du code client — considérez les deux comme publics.
4. Des règles d’accès en refus par défaut — l’app générée reçoit les permissions que vous avez choisies, pas celles, permissives, qu’elle a suggérées.
5. Une validation côté serveur pour chaque invariant — des hooks que le client ne peut pas contourner.
6. Des tests avant la confiance — le seul retour honnête de la boucle au-delà de “ça a l’air de tourner”.
7. Des périmètres réduits, une tâche par prompt — des diffs à taille de relecture restent relisibles.
8. Plafonnez les dépenses — des clés d’API avec quotas ; des boucles d’agent ont déjà brûlé de vrais budgets.
9. Isolez les expériences — app séparée, clés séparées, données jetables.
10. Sachez dans quel mode vous êtes — vibe ou ingénierie, choisi délibérément.

Cas d’usage courants

• Prototypes et MVP — le cas d’usage fondateur : tester l’idée ce week-end, pas ce trimestre.
• Outils personnels et internes — audience réduite, utilisateurs connus, faible rayon d’impact.
• Hackathons et démos — la vitesse est l’unique critère.
• Apprendre en construisant — la boucle comme tuteur, avec une réserve : du code non lu enseigne moins.
• Itération d’UI sur un backend stable — l’architecture à risque inversé : les vibes au-dessus, les contrats en dessous.

Devriez-vous le coder au vibe coding ? Matrice de décision

Limites et trade-offs

• Déboguer du code non lu, c’est de l’archéologie. Quand la boucle cale, quelqu’un doit finalement tout lire d’un coup — la relecture que vous avez sautée, avec les intérêts.
• La dette de compréhension s’accumule. Chaque changement accepté sans lecture creuse l’écart entre ce que fait l’app et ce que quiconque sait expliquer ; cet écart, c’est le risque.
• Les réglages par défaut de l’IA sont permissifs. Les configurations générées privilégient “ça marche” plutôt que “c’est sûr” — règles d’accès ouvertes, clés embarquées — et l’utilisateur qui aurait le plus besoin de s’en apercevoir est le moins armé pour le faire.
• Le terme dérive. “Vibe coding” désigne de plus en plus toute programmation avec l’IA, ce qui blanchit des pratiques de prototype jusque dans les discussions de production ; être précis sur le mode dans lequel on se trouve est la parade.
• L’atrophie des compétences est réelle mais mal cadrée. La compétence qui compte glisse de l’écriture du code vers sa spécification, sa relecture et son évaluation — l’atrophie ne survient que si la relecture est sautée elle aussi.

Le vibe coding sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le duo concrétise l’architecture à risque inversé : connectez le frontend généré à un backend dont les pièces porteuses sont déjà conçues par des ingénieurs — inscription, sessions et connexion sociale fournies par la plateforme ; ACL et permissions de classe appliquées côté serveur à chaque requête, en refus par défaut ; clés client publiables avec la master key conservée côté serveur ; et la garde beforeSave des onglets de code comme modèle pour chaque invariant qu’on ne peut pas confier au client écrit par l’IA. La surface codée au vibe coding reste ce que Karpathy voulait qu’elle soit — rapide, ludique, jetable — tandis que les parties qui finissent dans les rapports d’incident viennent d’une plateforme : relues une fois, appliquées toujours.