Générer de nouvelles fonctionnalités

Introduction

Jusqu'ici, nous avons appris à modifier l'existant et à réparer ce qui était cassé. Mais la véritable magie de Codex réside dans sa capacité de création. Vous avez une idée de génie sous la douche ? Codex peut l'écrire.

Cependant, générer une fonctionnalité "à partir de rien" nécessite une vraie discipline. L'erreur principale des débutants est de demander une application gigantesque en une seule phrase, ce qui aboutit toujours à un échec.

Les développeurs professionnels, eux, savent qu'une application n'est qu'un empilement de dizaines de petites fonctionnalités simples. Ce chapitre vous apprendra à penser comme eux : découper, analyser, puis construire.

Qu'est-ce qu'une fonctionnalité (Feature) ?

Une fonctionnalité est un élément autonome de votre projet qui rend un service précis à l'utilisateur final. Elle peut être purement visuelle, ou impliquer une logique très complexe.

Réfléchir avant de demander

Ne vous jetez pas sur le clavier. Prenez toujours 2 minutes pour appliquer la méthode "OQAF" (Objectif, Qui, Action, Fichiers).

• Objectif : Quel est le but précis de cette fonctionnalité ?
• Qui (L'utilisateur) : Est-ce destiné à tout le monde, ou seulement à un administrateur connecté ?
• Action : Que doit faire l'utilisateur ? (Cliquer, scroller, remplir un champ...)
• Fichiers : Où cela va-t-il s'afficher ? (Sur l'accueil, sur une nouvelle page, partout...)

graph TD;
    A[L'Idée Brute] --> B[Clarification OQAF];
    B --> C[Découpage en Petites Tâches];
    C --> D[Génération du HTML/Structure];
    D --> E[Génération du CSS/Design];
    E --> F[Génération du JS/Logique];

Construire une fonctionnalité étape par étape

Comparons deux manières de demander une fonctionnalité majeure.

Exemples de fonctionnalités simples

Commençons par créer des éléments isolés, ne nécessitant pas de base de données.

Exemples de fonctionnalités avancées

Passons aux fonctionnalités nécessitant une logique métier poussée.

Ajouter une fonctionnalité sans casser l'existant

C'est la terreur absolue. Vous demandez un beau formulaire de contact, et Codex écrase la couleur globale de tout votre site.

Pour protéger votre projet, encadrez vos prompts avec des directives de sécurité très strictes :

• "Ne modifie pas les classes globales. Utilise le fichier `contact.css`."
• "Réutilise le composant `<Button />` déjà existant au lieu d'en réinventer un nouveau."
• "Assure-toi que cette nouvelle section n'ajoute pas de barre de défilement horizontale."

Faire évoluer une fonctionnalité par itération

Rien n'est définitif en développement. Vous pouvez créer un "vieux vélo" fonctionnel, puis l'améliorer en "moto de course".

La conversation typique pour faire évoluer un élément :

Demander plusieurs propositions architecturales

Vous ne savez pas quelle est la meilleure manière de créer une fonctionnalité ? Demandez à l'IA de faire le travail de réflexion pour vous.

Je veux créer un système pour passer le site en Mode Sombre. Propose-moi 3 méthodes techniques différentes pour le faire. Compare leurs avantages et leurs inconvénients (facilité d'implémentation vs performance). Dis-moi laquelle est la plus adaptée pour un débutant.

Codex vous répondra : "Méthode 1 : Variables CSS (Recommandé). Méthode 2 : Deux fichiers CSS séparés. Méthode 3 : React Context." Vous choisirez ensuite la méthode 1, en toute connaissance de cause.

Vérifier la fonctionnalité (Checklist de validation)

Avant de crier victoire et de fermer Codex, effectuez ces tests essentiels :

• [ ] Le test critique : La fonctionnalité marche-t-elle exactement comme demandé ?
• [ ] Le test mobile : Redimensionnez votre fenêtre. C'est toujours beau ou le texte déborde-t-il ?
• [ ] Le test du silence : Ouvrez la console F12. Est-elle vierge de toute erreur rouge ?
• [ ] Le test de régression : L'ajout de ce code a-t-il cassé autre chose ailleurs (ex: le menu principal) ?

Les erreurs les plus fréquentes

• Symptôme : Un code d'une complexité délirante pour un problème simple.
  Cause : Vous n'avez pas cadré la demande. Pour faire une modale, Codex a installé Redux et 3 bibliothèques externes.
  Bonne pratique : Exigez la simplicité : "Crée cette fenêtre modale en utilisant uniquement du JavaScript Vanilla."
• Symptôme : Le code est parfait, mais le design jure avec le reste du site.
  Cause : Codex a inventé ses propres couleurs (ex: un bouton bleu vif alors que votre site est vert et noir).
  Bonne pratique : "Réutilise exactement les codes hexadécimaux et la typographie définis dans `global.css`."
• Symptôme : Vous avez demandé 4 fonctionnalités, il n'en a fait que 2.
  Cause : Limite de tokens (mémoire à court terme). Codex a "oublié" la fin de la phrase.
  Bonne pratique : Une. Seule. Fonctionnalité. Par. Prompt.
• Symptôme : La fonctionnalité marche sur votre machine, mais pas pour de vrai.
  Cause : Vous avez créé un formulaire d'envoi d'email, mais vous n'avez pas de backend serveur pour l'envoyer.
  Bonne pratique : Demandez à Codex ce qu'il vous manque : "De quoi ai-je besoin côté serveur pour que cet email parte réellement ?"
• Symptôme : Codex tourne en boucle sur la même erreur.
  Cause : La conception de base de la fonctionnalité était mauvaise.
  Bonne pratique : "Stop. Cette approche ne marche pas. Effaçons ce qu'on vient de faire et trouvons une architecture différente."

Atelier pratique

Conseils vitaux

Tableau récapitulatif : Le Découpage

Foire aux questions

À retenir

Transition vers le chapitre suivant

Vous savez désormais modifier, réparer, et créer de nouvelles choses avec Codex. Mais que faire si vous vous trompez lourdement et que vous avez besoin de tout annuler ?

Dans le prochain chapitre, nous allons découvrir le duo ultime du développement moderne : Codex et Git. Vous allez apprendre comment créer des "points de sauvegarde" temporels pour expérimenter n'importe quelle fonctionnalité sans jamais avoir peur de détruire votre projet.