Voici enfin la phase 3, « construire ». Avec le cahier des charges décidé au chapitre 2 et les technos et outils choisis au chapitre 3, nous allons assembler une chose qui fonctionne vraiment. La plupart de ceux qui trébuchent ici ne le font pas parce qu'ils « ne savent pas coder ». Ils abandonnent parce qu'ils visent la version finale d'un seul coup. Ce chapitre présente, sur les deux routes, une façon de créer qui enchaîne rapidement « construire petit et faire tourner », avec l'IA pour partenaire.
Viser non pas « finir d'un coup » mais « avancer par petits pas »
L'état d'esprit de base — avancer par petits tours
L'attitude la plus importante en implémentation tient en une phrase : répéter à toute vitesse « construire petit, faire tourner, corriger ». Ne cherchez pas à produire d'un coup la version finale que vous avez en tête ; créez d'abord le plus petit « bloc qui marche », puis faites-le grandir petit à petit.
Pourquoi ça marche ? Parce qu'un programme ne révèle ce qui cloche qu'une fois qu'on le fait tourner. Si vous écrivez 100 lignes avant de lancer d'un coup, vous êtes perdu, incapable de trouver la cause. Si vous écrivez 10 lignes et les lancez, l'erreur ne peut être que dans ces 10 lignes. Quand c'est l'IA qui écrit, c'est exactement pareil : demander petit et vérifier tout de suite fait avancer, au final, bien plus vite et plus sûrement.
Balancer à l'IA « crée toutes les fonctions d'un coup ». Une masse de code sort, mais au lancement, c'est plein d'erreurs. On ne trouve pas la cause, et l'énergie de corriger s'évanouit.
Demander fonction par fonction : « d'abord juste l'écran qui affiche la liste ». Ça marche, on passe à la suite, on empile. On avance toujours en gardant un « état qui marche ».
⚠️ Le code de l'IA se trompe aussi — donc faites-le toujours tourner vous-même. Le code écrit par l'IA a beau paraître crédible, il arrive souvent qu'il renvoie une erreur au lancement ou se comporte autrement que prévu. « C'est l'IA qui l'a écrit, donc c'est forcément juste » : à proscrire. Le code produit, faites-le toujours tourner de vos mains et vérifiez de vos yeux. C'est la première règle d'or à acquérir en dev indépendant. Avancer sans faire tourner accumule les erreurs jusqu'à l'ingérable.
Les étapes de la boucle « créer, faire tourner, corriger »
Ce « petit tour » se décline en 4 étapes concrètes, illustrées ci-dessous. On fait tourner une fonction dans cette boucle, encore et encore. Un tour prend de quelques minutes à quelques dizaines de minutes. Plus vous bouclez vite, plus vous progressez.
Demander concrètement à l'IA « juste cette fonction, maintenant ». Plus le périmètre est resserré, plus la précision monte.
Dès que ça sort, exécuter. Vérifier le résultat de ses propres yeux dans le navigateur ou le terminal.
En cas d'erreur ou de gêne, corriger par le dialogue : « corrige ça comme ceci ». Répéter jusqu'à ce que ça marche.
Quand ça marche, sauvegarder comme jalon (commit). Garder le bon état, passer à la fonction suivante.
💡 Ne négligez pas l'ÉTAPE 4, « sauvegarder ». En sauvegardant (commit Git) à chaque fonction qui marche, si le changement suivant casse tout, vous pouvez revenir au dernier état qui fonctionnait. C'est la corde de rappel contre le drame du « pourtant ça marchait hier ». La façon concrète de sauvegarder sera détaillée au chapitre 5.
Le style d'implémentation des routes débutant et pratique
« Avancer par petits tours » est une attitude commune, mais la façon concrète de boucler change selon la route. Selon la route choisie au chapitre 1, vérifiez votre marche à suivre. Bien sûr, vous pouvez mélanger ou changer de route en chemin.
Avec le vibe coding, assemblez l'appli en dialoguant avec l'IA. « Crée l'écran de liste » → « mets le bouton en bleu » → « fais que ça enregistre au clic » : demander en langage courant, regarder l'écran, redemander. Cette répétition est déjà la « boucle des petits tours ».
Astuce : ne demander qu'une chose à la fois. Si ça rate, il suffit de dire « annule le dernier changement ».
Remettez le cahier des charges entier à Claude Code, par exemple, et confiez-lui une implémentation d'un bloc. Ajustez l'effort selon la charge de travail, et jonglez avec les modes de permission pour éviter qu'il ne réécrive trop de fichiers de lui-même : c'est la clé d'une automatisation sûre.
Astuce : déléguer en grand, mais vérifier en petit. Bloqué ? Cherchez la solution dans le recueil d'erreurs.
Sur les deux routes, il ne faut pas oublier l'attitude de base : « faire tourner soi-même ce qui sort et vérifier ». Que vous créiez par le dialogue ou par l'automatisation, vérifier reste le travail de l'humain. Ne pas économiser ce petit effort fait toute la différence entre atteindre ou non la version finale.
Si vous intégrez des fonctions IA
Si ce que vous créez est une « appli qui utilise l'IA » — par exemple pour résumer un texte, répondre à des questions, juger une image — il vous faut un mécanisme pour appeler l'IA depuis l'appli. Ça devient un peu technique, mais les options se résument à 3 grandes catégories. Il suffit de choisir ce dont votre appli a besoin.
Pour utiliser un seul modèle d'IA depuis l'appli, la base est d'appeler une API d'IA. Voyez-la comme un guichet : « on envoie un texte, la réponse de l'IA revient ».
Pour alterner plusieurs IA selon le cas, unifiez l'écriture avec le Vercel AI SDK. Pour tout gérer de façon centralisée en exploitation, une passerelle LLM est pratique.
Pour faire répondre à partir de documents internes ou de vos propres supports, le RAG. Un mécanisme qui donne à l'IA « vos documents à vous » pour répondre, et vous démarque.
🧭 En cas de doute, ① suffit. Pour un premier MVP, appeler une seule API d'IA suffit la plupart du temps. Vous ajouterez ② et ③ quand le besoin apparaîtra — « comparer plusieurs modèles », « répondre à partir de ses données ». Là encore, « construire petit » est la bonne réponse.
Comment réagir quand on est bloqué
En cours d'implémentation, vous serez forcément bloqué quelque part. Une erreur s'affiche, ça ne se comporte pas comme prévu — ce n'est pas un échec, c'est la preuve qu'on est en train de créer. L'essentiel, une fois bloqué, est de ne pas paniquer et de trier dans l'ordre. Avec l'IA aujourd'hui, on se débloque bien plus vite qu'avant.
Copiez le texte rouge en entier et demandez « cette erreur est apparue. Cause et correction ? » Le message d'erreur est le plus grand indice. Ne réécrivez pas à votre sauce : collez d'abord.
Rappelez-vous « jusqu'où ça marchait ». Le seul endroit changé juste avant est le plus souvent la cause. En resserrant le périmètre, on trouve toujours l'origine.
Si ça s'emmêle, revenez au dernier état sauvegardé qui marchait et reprenez. Plutôt que de s'acharner, revenir en arrière est souvent plus rapide.
🔧 Pour ceux de la route pratique. Les erreurs fréquentes de Claude Code et leurs solutions sont rassemblées dans le recueil d'erreurs. Se ronger sur une même erreur est une perte de temps. Prenez l'habitude : bloqué ? cherchez d'abord ; si ça ne suffit pas, demandez à l'IA.
Résumé de ce chapitre
Le cœur de la phase 3, « construire », tient moins dans la technique que dans l'attitude de répéter à toute vitesse « construire petit, faire tourner, corriger ». Ne visez pas la version finale d'un coup ; faites grandir petit à petit un bloc qui marche.
- L'attitude de base : répéter vite « construire petit et faire tourner → corriger ». Ne pas viser la fin d'un coup.
- Le code de l'IA se trompe aussi. Ce qui sort, faites-le toujours tourner vous-même et vérifiez.
- 🌱 débutant : vibe coding en dialoguant ; 🔧 pratique : remettre le cahier des charges et automatiser sûrement avec l'effort et les modes de permission.
- Pour embarquer l'IA, partez de l'API. Plusieurs modèles : Vercel AI SDK / passerelle LLM ; données propres : RAG.
- Bloqué ? passer le message d'erreur → trier en petit → revenir à un état qui marche. Exploitez aussi le recueil d'erreurs.
Une fois une chose qui marche obtenue, il faut la mettre au monde en toute sécurité. Vous pouvez revenir au chapitre 3, « Choisir ses technos et outils » pour revoir la préparation, mais dès que l'implémentation tourne, passez au chapitre 5, « Tester et mettre au monde » pour verrouiller tests et sécurité, puis publier.