Les erreurs fondamentales des débutants

Au Module 1, vous avez compris que diriger l’IA remplace l’écriture du code. Ce module identifie les erreurs qui sabotent cette direction. Bonne nouvelle : elles sont presque toujours les mêmes. Les connaître, c’est déjà à moitié les éviter. Nous les classons de la plus coûteuse à la plus courante.

Erreur n°1 : demander « fais tout le site » dès le premier prompt

C’est l’erreur reine, celle que presque tout le monde commet au début. On ouvre Claude, plein d’enthousiasme, et on écrit : « Crée-moi un site complet pour mon restaurant avec un menu, une réservation en ligne, un blog, un espace client et un back-office. »

Pourquoi c’est le réflexe naturel. Parce que c’est exactement ce qu’on aimerait obtenir : le résultat final, tout de suite. Et l’IA entretient l’illusion, puisqu’elle *répond* et génère effectivement beaucoup de code. Le problème, c’est que « générer du code » et « construire un logiciel » sont deux choses différentes.

Pourquoi ça échoue presque toujours. Trois causes se combinent :

La perte de contexte.

Un site complet, c’est des milliers de lignes réparties sur des dizaines de fichiers. Plus la demande est vaste, plus les détails se diluent, et plus les incohérences s’installent — sans que rien ne le signale.

L’absence de cohérence.

Chaque partie est plausible isolément, mais l’ensemble ne s’emboîte pas : le formulaire de réservation n’utilise pas le même modèle de données que l’espace client, les styles divergent, la navigation se contredit.

L’impossibilité de vérifier.

Quand 2 000 lignes tombent d’un coup, vous ne pouvez rien relire sérieusement. Vous acceptez en bloc — et vous héritez d’une base que personne ne comprend, vous compris.

Ce qui se passe ensuite est toujours le même scénario : le site « marche » lors de la première démonstration. Puis vous demandez une petite modification — changer le formulaire de réservation. L’IA, qui n’a plus le contexte complet, réécrit une partie, en casse une autre, et le château de cartes s’effondre. Vous passez alors plus de temps à réparer qu’il n’en aurait fallu pour bien construire.

La règle d’or de toute la formation : on ne demande jamais un résultat, on demande une étape.

Concrètement, au lieu de « fais le site du restaurant », on écrit une première demande minuscule : « Crée la structure d’un projet Next.js avec une page d’accueil vide et un composant d’en-tête contenant le nom du restaurant. » On teste, on valide, on passe à la suite. C’est moins grisant sur le moment, infiniment plus rapide au total.

Erreur n°2 : ne pas donner de contexte

Claude ne connaît ni votre projet, ni vos intentions, ni vos contraintes. À chaque conversation, il part avec ce que vous lui donnez — rien de plus. Sans contexte, il ne devine pas : il invente. Et ce qu’il invente double souvent ce qui existait déjà.

La première demande produit un nouveau bouton, un nouveau style, peut-être un nouveau système de modale. La seconde s’intègre à l’existant. Le contexte utile se décline en trois niveaux, à garder en tête à chaque demande :

Contexte métier.

Ce que fait le projet, pour qui, quel est l’objectif de la page ou de la fonctionnalité.

Contexte technique.

La stack, les composants déjà présents, les conventions à respecter.

Contexte stylistique.

Le ton, l’identité visuelle, un exemple existant à imiter.

Au Module 3, nous verrons comment industrialiser ce contexte grâce à un fichier `CLAUDE.md`, pour ne plus avoir à le répéter à chaque message.

Erreur n°3 : ne pas découper le projet

C’est la conséquence directe de l’erreur n°1, et sa solution concrète. Un projet doit être découpé en tâches vérifiables : assez petites pour être relues d’un coup d’œil, assez autonomes pour être testées seules. Le bon réflexe tient en une formule : une fonctionnalité = une tâche = un test = un commit.

Reprenons le site vitrine avec prise de rendez-vous. Le mauvais découpage, c’est « fais le site ». Le bon ressemble à ceci :

1. 1Mettre en place la structure du projet et la page d’accueil vide.
2. 2Créer le composant d’en-tête (header) avec la navigation.
3. 3Créer la section « hero » de la page d’accueil.
4. 4Créer la section « services ».
5. 5Créer le composant de bouton réutilisable.
6. 6Créer la modale de prise de rendez-vous.
7. 7Connecter le formulaire à l’envoi d’e-mail.

Chaque étape est courte, testable, et si elle échoue, vous savez exactement où. C’est l’inverse du « tout ou rien » : c’est du « pas à pas vérifiable ». Cet ordre a aussi une logique — les fondations et les briques réutilisables d’abord, les fonctionnalités ensuite.

Erreur n°4 : ne rien documenter

Un projet non documenté devient une boîte noire. Au début, vous vous souvenez de tout. Trois semaines plus tard, vous ne savez plus pourquoi tel choix a été fait, où se trouve telle logique, ni ce qui va casser si vous y touchez.

Pire : l’IA aussi a besoin de cette documentation. Sans elle, à chaque nouvelle conversation, Claude redécouvre votre projet de zéro et refait les mêmes erreurs. La documentation n’est pas une corvée administrative : c’est la mémoire partagée entre vous et l’IA. C’est tout l’objet du Module 3.

Erreur n°5 : accepter le code sans le lire

C’est l’erreur la plus insidieuse, car elle procure une fausse sensation de productivité. Le code apparaît, « ça a l’air de marcher », on accepte, on enchaîne. On a l’impression d’avancer à toute vitesse. En réalité, on accumule une dette invisible : chaque bloc accepté sans compréhension est une zone d’ombre de plus.

Au bout de deux semaines, le projet est truffé de code que personne n’a jamais vraiment lu — et le jour où un bug sérieux apparaît, personne ne sait par où commencer. Lire le code de l’IA ne veut pas dire tout comprendre dans le détail. Cela veut dire : vérifier que ça fait ce que vous avez demandé, repérer ce qui semble anormal, et demander une explication dès qu’un passage vous échappe. C’est une compétence, et nous lui consacrons le Module 6 entier.

Les autres pièges fréquents

• Ne jamais tester. Se fier au fait que « le code compile » ou que « la page s’affiche » sans vérifier le comportement réel.
• Ne jamais faire de commit. Travailler des heures sans sauvegarder, puis perdre tout un pan de travail quand l’IA casse quelque chose (Module 5).
• Changer d’avis sans cadrer. Enchaîner des demandes contradictoires dans la même conversation, jusqu’à un code devenu patchwork.
• Faire confiance aveuglément aux affirmations de l’IA, qui peut se tromper avec un aplomb total (Module 6).
• Copier-coller des solutions sans les adapter, surtout en sécurité, où une « solution qui marche » peut ouvrir une faille (Module 7).
• Vouloir tout optimiser trop tôt, sur un projet qui n’a pas encore prouvé son utilité.