Se faire générer des mini-projets calibrés - sans le code

Faites de l'IA un commanditaire qui rédige un cahier des charges à votre niveau, avec jalons et critères de réussite vérifiables, mais jamais le code.

8 min · 3 questions

Passé les fondamentaux, les tutoriels cessent de faire progresser : ils vous font recopier des solutions dans un chemin balisé. Ce qui fait progresser un développeur confirmé, c'est le projet légèrement au-dessus de son niveau - assez dur pour forcer des décisions, assez cadré pour ne pas s'enliser. Le problème : se calibrer soi-même est presque impossible, on choisit trop facile ou trop ambitieux. L'IA excelle à ce calibrage, à condition de lui donner le bon rôle. Le mauvais usage : « code-moi une application de suivi de dépenses » - vous obtenez le produit fini et zéro compétence. Le bon usage : l'IA joue le commanditaire qui rédige le cahier des charges ; le développeur, c'est vous.

Tu es un commanditaire de projet (product owner). Tu rédiges des cahiers des charges, tu n'écris JAMAIS de code.

Mon profil : je pratique [langage/techno] régulièrement. Je maîtrise déjà : [liste honnête]. Je veux progresser sur : [notions ciblées, ex. : gestion d'erreurs asynchrones, tests, découpage en modules].
Temps disponible : environ [X] heures, réparties sur [durée].

Rédige un cahier des charges pour un mini-projet :
- Le besoin en 5 lignes maximum, formulé comme par un vrai client (le QUOI, jamais le COMMENT).
- 3 à 5 jalons ordonnés, chacun aboutissant à quelque chose de fonctionnel et démontrable.
- Pour chaque jalon : des critères de réussite OBSERVABLES (« la commande X affiche Y », « le cas Z est rejeté avec un message clair » - pas « le code est propre »).
- Une contrainte technique qui me force à utiliser les notions ciblées.
- 2 extensions optionnelles si je finis en avance.

Interdictions : aucun extrait de code, aucun nom de fonction ou de bibliothèque imposé, aucune indication d'implémentation. L'implémentation est mon travail.

Le calibrage repose sur deux informations que vous seul possédez : ce que vous maîtrisez déjà (soyez honnête, sinon le projet sera trop facile) et ce que vous voulez travailler (une ou deux notions, pas six). Les jalons transforment le projet en boucle de feedback : chaque étape livre un comportement démontrable, ce qui interdit l'enlisement dans une architecture cathédrale. Quant aux critères de réussite observables, ils changent tout : « le code est propre » ne se vérifie pas, « l'import d'un fichier corrompu affiche une erreur explicite sans crash » se vérifie en dix secondes. Un critère non observable est une opinion ; un critère observable est un test d'acceptation.

Tu es le commanditaire du projet suivant : [rappeler le cahier des charges ou coller le jalon en cours].

Je pense avoir terminé le jalon [X]. Voici ce que mon programme fait, du point de vue d'un utilisateur : [décrire le comportement observable, pas le code].

1. Passe en revue chaque critère de réussite du jalon : pose-moi des questions précises pour vérifier qu'il est vraiment rempli, cas limites compris (entrée vide, valeur aberrante, action répétée deux fois).
2. Si un critère n'est pas rempli, dis lequel et en quoi, sans me dire comment le corriger.
3. Si tout est validé, énonce le jalon suivant - toujours sans code ni indication d'implémentation.

Ce rituel de validation reproduit la recette d'un vrai projet : le commanditaire ne lit pas votre code, il interroge le comportement. Les questions sur les cas limites sont la partie précieuse - c'est là que vous découvrez ce que votre implémentation ne gère pas. Reste le moment critique de tout projet en autonomie : le blocage. La tentation est maximale de basculer en « écris-moi cette partie ». Résistez avec un protocole d'indices gradués : chaque niveau en dit un peu plus, et vous ne consommez que le niveau nécessaire pour redémarrer.

Je suis bloqué sur mon projet [contexte]. Le blocage : [ce que vous essayez de faire, ce que vous avez tenté, où ça coince].

Donne-moi des indices GRADUÉS, un seul niveau à la fois :
- Indice 1 : la piste générale - un concept à revoir ou une direction, en une phrase.
- Indice 2 (seulement si je le demande) : plus précis - quelle partie de MON approche revoir.
- Indice 3 (seulement si je le demande) : le principe de la solution, expliqué en français, sans code.

Commence par l'indice 1 et attends ma réponse. Ne saute jamais un niveau, même si je m'impatiente ou insiste.

Quiz de validation

Vérifiez que vous avez bien retenu les points clés de cette leçon.

1. Quel rôle donner à l'IA pour qu'un mini-projet vous fasse réellement progresser ?
   • Développeur : elle code, vous relisez
   • Commanditaire : elle rédige le cahier des charges et valide les jalons, vous codez
   • Binôme : elle code une moitié, vous l'autre
2. Lequel de ces critères de réussite est correctement formulé ?
   • « Le code doit être propre et maintenable »
   • « L'architecture doit être solide »
   • « Importer un fichier vide affiche une erreur explicite sans faire planter le programme »
   • « L'application doit être performante »
3. En plein projet, vous êtes bloqué depuis une heure. Quel réflexe préserve l'apprentissage ?
   • Demander le code de la partie bloquante pour avancer
   • Abandonner le projet et en générer un plus facile
   • Demander des indices gradués, un niveau à la fois, sans code