Utiliser l’IA pour coder : mon expérience catastrophique

Utiliser l’IA pour coder nécessite une supervision humaine constante et une approche intelligente pour éviter les pièges de la dépendance totale. Dans cette histoire, je t’emmène pas à pas au cœur de mon expérience la plus ambitieuse — et la plus catastrophique — pour en tirer des leçons applicables dès aujourd’hui.

J’en avais marre de voir ces vidéos « J’ai créé une app en 20 minutes avec ChatGPT ». J’ai donc mené une expérience pour démontrer les réalités d’utiliser l’IA pour coder un plugin WordPress complet – et les résultats sont édifiants.

Table des matières

• Chapitre 1 : Le défi insensé
• Chapitre 2 : Les premiers pas (trop faciles)
• Chapitre 3 : Le premier signal d’alarme
• Chapitre 4 : L’illusion de la perfection
• Chapitre 5 : La chute libre
• Chapitre 6 : La descente aux enfers technique
• Chapitre 7 : La prise de conscience
• Chapitre 8 : La leçon (qui change tout)
• Chapitre 9 : Les signaux d’alarme à reconnaître
• Questions fréquentes

Chapitre 1 : Le défi insensé

Tout a commencé par une frustration. Partout sur YouTube, LinkedIn, TikTok… les mêmes promesses : « Créez une app en 30 minutes avec l’IA », « Devenez développeur expert grâce à ChatGPT ».

Moi qui utilise l’IA pour coder au quotidien de manière intelligente, je savais que quelque chose clochait dans ces discours. Alors j’ai décidé de mener l’expérience ultime : et si je faisais exactement ce que ces gourous prêchent 🧞 ?

Mon défi : Développer un plugin WordPress de sécurité rivalisant avec SecuPress 🤣, entièrement avec Claude Code. Mais attention – voici le twist – je m’interdisais d’écrire une seule ligne de code moi-même. 🙈

L’objectif ? Prouver que cette approche est une impasse.

Chapitre 2 : Les premiers pas (trop faciles)

Les premières heures ont été enivrantes. Claude Code dévorait mes prompts et crachait du code à une vitesse hallucinante :

• « Crée-moi un système de détection d’intrusion » → BAM, 200 lignes de PHP
• « Ajoute un scanner de malwares » → PAF, classes et interfaces impeccables
• « Intègre un système de backup automatique » → BOOM, architecture orientée objet

En quelques heures, j’avais un dossier rempli de fichiers PHP, une structure de plugin professionnelle, des hooks WordPress partout. Magique. 🧙

Chapitre 3 : Le premier signal d’alarme

Puis est arrivé le premier coup de massue : quota épuisé en 20 minutes.

Pourquoi ? Claude devait analyser l’intégralité du projet à chaque nouveau prompt. Plus le projet grossissait, plus la consommation de tokens explosait de manière exponentielle.

Mon rythme de travail s’est transformé en torture :

1. 20 minutes de développement
2. 5 heures d’attente
3. Répéter l’opération

Mais bon, me disais-je, « c’est le prix à payer pour avoir un plugin de ouf sans écrire une ligne de code ».

J’étais encore loin de la vérité…

Chapitre 4 : L’illusion de la perfection

Au bout de 3 jours, j’avais sous les yeux un plugin impressionnant :

• ✅ Structure de fichiers impeccable
• ✅ Classes et interfaces partout
• ✅ Autoload configuré
• ✅ Hooks WordPress intégrés
• ✅ Documentation dans le code

Sur le papier, c’était du niveau professionnel. Claude avait même ajouté des commentaires en français, respecté les conventions WordPress, créé des tests unitaires…

« Bon, maintenant on teste ce bijou », me suis-je dit, confiant.

C’est là que l’histoire a basculé.

Chapitre 5 : La chute libre

J’active le plugin sur mon site de test et…

ERREUR FATALE. ÉCRAN BLANC. SITE PLANTÉ.

Premier réflexe : « Bon, c’est sûrement un petit bug, on va corriger ça vite fait. »

Je regarde les logs d’erreur. Mon sang se glace :

• Tables SQL non créées
• Méthodes définies plusieurs fois dans des fichiers différents
• Code dupliqué partout
• Hooks dans tous les sens

2 heures pour simplement faire que le plugin s’active sans planter le site. Pas pour qu’il fonctionne, hein. Juste pour qu’il ne tue pas WordPress.

Chapitre 6 : La descente aux enfers technique

Une fois le plugin activé, j’ai découvert l’ampleur du désastre. Claude avait fait une erreur de débutant classique avec les hooks WordPress :

Tout le plugin chargé sur plugins_loaded, mais dans une classe, il appelait init puis admin_init dans le constructeur.

Résultat : rien ne fonctionnait dans l’ordre. Les pages d’admin étaient cassées, les API REST plantaient, les sauvegardes ne s’enregistraient pas.

Et plus je corrigeais, plus je découvrais de problèmes. C’était comme taper dans une fourmilière avec un bâton : chaque correction révélait des nouveaux bugs.

Chapitre 7 : La prise de conscience

Assis devant mon écran, après 3 heures de debug intensif, j’ai eu une révélation brutale :

J’étais en train de corriger un code que je ne comprenais pas, écrit par une IA que je ne contrôlais pas, pour un projet que je ne maîtrisais plus.

Pire encore : pour maintenir ce plugin, j’aurais besoin de repasser par l’IA à chaque modification. Dépendance totale. Si Claude disparaît demain, mon plugin devient inmaintenable.

Et le coût ? Avec les quotas premium qui sautent en 20 minutes, maintenir ce plugin me coûterait plus cher que de le refaire proprement.

Chapitre 8 : La leçon (qui change tout)

Cette expérience m’a confirmé ce que je savais déjà : utiliser l’IA pour coder, c’est fantastique. Mais pas n’importe comment.

Depuis des mois, j’utilise l’IA quotidiennement dans mon travail, mais intelligemment :

Ma vraie méthode (celle qui marche)

1. Je planifie l’architecture moi-même
2. Je demande du code pour des fonctions spécifiques et courtes
3. Je teste immédiatement chaque morceau
4. Je comprends et modifie tout ce que j’intègre
5. Je reste capable de maintenir sans l’IA

Avec cette approche, l’IA me fait gagner un temps fou. Elle m’aide à générer des fonctions utilitaires rapidement, trouver des solutions à des problèmes spécifiques, optimiser des algorithmes existants et déboguer du code complexe.

Mais je garde toujours le contrôle.

Chapitre 9 : Les signaux d’alarme à reconnaître

Comment savoir si vous utilisez mal l’IA ? Voici les red flags ⛳ :

• ❌ Vous ne comprenez pas le code généré
• ❌ Vous ne testez pas immédiatement
• ❌ Vous dépendez de l’IA pour corriger ses propres erreurs
• ❌ Vous ne pourriez pas maintenir le code dans 1 mois
• ❌ Vos quotas explosent à cause du contexte trop lourd (bon ici ça dépend)

Épilogue : La vérité derrière les vidéos

Maintenant, quand je vois ces vidéos « J’ai créé une app en 30 minutes », je souris.

Parce que je sais ce qu’il y a derrière :

• Les 10 heures de debug non filmées
• Le code inmaintenable qu’on ne montre pas
• Les fonctionnalités qui ne marchent qu’en démo
• La dépendance totale à l’IA pour la maintenance

La vérité ? L’IA est un outil révolutionnaire qui transforme notre façon de coder. Mais comme tout outil puissant, elle peut vous sauver ou vous perdre selon comment vous l’utilisez.

Gardez votre cerveau allumé, testez tout, comprenez ce que vous intégrez, et vous découvrirez que l’IA peut vraiment décupler votre productivité.

Mais si vous lui déléguez tout en fermant les yeux… préparez-vous à vivre la même aventure que moi.

Conclusion : L’IA, un outil puissant avec le cerveau allumé

Utiliser l’IA pour coder est révolutionnaire quand c’est fait intelligemment. L’IA excelle comme assistant expert, mais la supervision humaine reste indispensable.

Mon conseil : gardez toujours votre cerveau allumé, testez systématiquement, et assurez-vous de comprendre ce que vous intégrez. C’est ainsi que vous tirerez le meilleur parti de cette technologie sans tomber dans les pièges de la dépendance.

Pour aller plus loin, consultez les bonnes pratiques de prompt engineering.