Habr : l'auteur a expliqué pourquoi AI ne doit pas être réduite au seul vibe coding

Une colonne sur Habr a fait un constat étonnamment lucide : le problème ne réside pas dans le vibe coding lui-même, mais dans l'habitude de réduire le travail avec l'IA à la simple écriture de code. L'auteur suggère de penser plus largement et de choisir non pas le chemin le plus « technologique », mais le plus court et le plus maintenable vers le résultat.

Pas du Code pour le Code

Le texte débute par une critique non des modèles, mais du terme « vibe coding » en tant que cadre trop étroit. Si vous pensez constamment en termes de « générons une application », il est facile de passer à côté de solutions plus pratiques. Pour un rapport de données, il suffit parfois de demander à l'IA d'assembler un fichier Excel avec des formules et une structure claire. Pour un projet de contenu—sélectionnez une combinaison d'un CMS prêt à l'emploi, d'un template et de plugins, plutôt que de passer du temps sur le frontend, le déploiement et le débogage de votre propre stack.

« L'IA entre vos mains est un excellent multi-outil, pas un marteau. »

C'est le pivot principal de l'article : le code ne doit pas être un objectif en soi. Si une tâche a été résolue par le marché depuis longtemps, l'IA est plus utile comme accélérateur pour la configuration, la personnalisation et le lancement, plutôt que comme usine de nouvelles dettes techniques. Cette approche est particulièrement importante pour les petites équipes, où après le lancement, le système doit toujours être maintenu, transmis à d'autres personnes, et pas surchargé de questions sur l'accès, la sécurité et la compatibilité.

Un Blog plutôt que Votre Propre CMS

L'auteur l'illustre par un cas spécifique : il fallait rapidement lancer une revue spécialisée en éducation pour une petite école privée. La tentation était typique de 2026—utiliser Claude Code ou un autre agent et « vibe coder » votre propre CMS sur une stack à la mode. Mais après un rapide contrôle de réalité, la solution s'est avérée évidente : un blog avec des sections, SEO, images, recherche et RSS—c'est un problème déjà résolu que WordPress couvre depuis des années.

Au lieu d'une application personnalisée, une stack pragmatique a été choisie : VPS sous Ubuntu, nginx, PHP 8.3, MySQL 8.0, WordPress avec le thème GeneratePress.

L'IA n'a pas disparu—elle a été utilisée comme exécutrice via SSH, écrivant du PHP, modifiant les configs, ajustant le thème, et assemblant les personnalisations via des mu-plugins.

• serveur avec nginx, PHP-FPM, MySQL, SSL, firewall et fail2ban
• page d'accueil du journal avec un bloc hero, des cartes d'articles et une grille de sections
• SEO basique, sitemap et URLs lisibles
• 12 mu-plugins pour une personnalisation ciblée
• environ 600 lignes de CSS et plusieurs scripts Python auxiliaires

Essentiellement, l'auteur n'a pas abandonné l'IA—il a cessé de forcer l'IA à construire ce qui existe déjà. C'est l'argument central de l'article : dans de nombreux projets, la victoire ne vient pas de la maximisation de la quantité de code généré, mais de la capacité à s'appuyer sur une plateforme prête à l'emploi et ne polir que les points étroits.

Là Où l'IA Est Vraiment Utile

La partie la plus forte du texte est la description du processus réel, sans magie et sans battage promotionnel. L'IA n'a pas tout fait « avec une seule commande ». Le travail s'est déroulé par itérations : une personne formule une tâche, le modèle réalise environ 80% de ce qui est nécessaire, puis commence un cycle de vérification, de recherche de problèmes visuels et de corrections ciblées.

Pour une stack inconnue, cela économise toujours énormément de temps, car vous n'avez pas besoin de passer des semaines à apprendre l'API de WordPress, les hooks, les filtres et les subtilités de la cascade CSS. Mais l'article énumère honnêtement aussi les limitations. Un agent de console ne voit pas le résultat dans un navigateur, ignore les modifications manuelles dans le panneau d'administration, et peut facilement casser un bloc adjacent en réparant le bloc actuel.

Dans un cas, l'IA a rendu le bloc des catégories HTML statique, et après avoir renommé les sections sur la page d'accueil, rien n'a été mis à jour. La correction n'est venue qu'après plusieurs itérations : d'abord via le filtre the_content, puis en abandonnant les slugs en dur au profit de get_terms(). Dans un autre cas, il a fallu séparément comprendre pourquoi les styles core de WordPress cassaient la grille à trois colonnes, et augmenter la priorité des styles personnalisés à 999.

De cela découle la deuxième conclusion importante : l'IA ne remplace pas la réflexion architecturale et la compétence technique de base. Elle accélère l'infrastructure, la personnalisation et le CSS routinier, mais ne prend pas les décisions produit mûres d'elle-même. Si une personne ne comprend pas le domaine, ne remarque pas les erreurs de sécurité, et ne peut pas évaluer la qualité du résultat, le modèle produira simplement des réponses plausibles qui s'écrouleront sur un vrai projet.

Ce Que Cela Signifie

La colonne de Habr frappe bien le nerf du marché : il est trop facile de commencer à mesurer le succès de l'IA par la quantité de code écrit autour d'elle. En pratique, l'entreprise a généralement besoin non d'un nouveau framework, mais d'une solution rapide, bon marché et maintenable. Par conséquent, le scénario le plus utile pour l'IA aujourd'hui n'est pas le vibe coding aveugle, mais de choisir le chemin le plus court : parfois ce sera un service personnalisé, parfois ce sera Excel, WordPress ou un autre produit prêt à l'emploi que vous pouvez lancer et livrer sans douleur supplémentaire.