Un programme de 30 jours pour apprendre à coder avec l’IA

TL;DR

En trente jours, l’objectif n’est pas de devenir senior ni de produire un dashboard parfait. L’objectif est d’apprendre à faire évoluer le rôle de l’IA : d’abord professeur, ensuite reviewer, puis partenaire de débogage et enfin exécutant sous contrôle. À la fin, tu dois pouvoir expliquer, vérifier et refaire une partie de ce que tu as construit.

Le mini-dashboard n’est qu’un prétexte

Claude Code ou Codex peut générer un mini-dashboard dès le premier jour. Quelques métriques, des cartes React, un appel API simulé et des tests : tout cela est à portée d’un bon prompt.

Mais est-ce que tu sauras le faire évoluer au trentième jour ?

C’est la question qui compte. Parce qu’un projet ne devient intéressant qu’au moment où une donnée manque, qu’un test casse, qu’une règle métier change ou qu’un autre développeur doit comprendre ce qui a été fait. Le code généré est le début de l’histoire. La compétence, c’est de pouvoir continuer quand l’histoire devient moins propre.

Le programme qui suit s’appuie sur le mini-dashboard de cette série : TypeScript, React et Next.js, quelques métriques de serveur, une API simulée, des données valides ou invalides et des tests utiles. Si tu préfères un autre sujet, garde simplement la même progression. Un gestionnaire de tâches, une page de profil ou un petit outil métier peuvent très bien faire l’affaire.

Prévois entre quarante-cinq et quatre-vingt-dix minutes par jour. Si tu n’as pas ce temps, étale les journées. La régularité est plus importante que le calendrier. Conserve aussi une note très courte après chaque session : ce que tu as tenté, ce qui t’a bloqué, l’aide demandée et ce que tu sais désormais expliquer sans ouvrir la conversation avec l’IA.

Première semaine : l’IA explique, tu écris

La première semaine peut sembler frustrante : l’agent a le droit d’expliquer, de poser des questions et de relire, mais pas de prendre le clavier à ta place. C’est volontaire.

Commence par écrire le besoin du dashboard avec ses limites. Il affiche l’état d’un service, l’utilisation CPU, la mémoire et l’espace disque. Il doit gérer un chargement, une erreur API et une donnée invalide. Il n’a pas besoin d’authentification réelle, de base de données ou de graphiques temps réel. Demande à l’agent de relever les ambiguïtés. Ne lui demande pas encore le projet.

Initialise ensuite Next.js et prends le temps de comprendre l’arborescence créée. À quoi sert le dossier app ? Où vit un composant ? Quelle différence entre une donnée déclarée dans un type et une donnée réellement reçue depuis une API ? Tu peux vérifier tes réponses dans la documentation de Next.js, puis demander à l’agent de corriger uniquement ce qui est important.

Écris toi-même une première carte MetricCard, alimentée avec une donnée simulée. Elle n’a pas besoin d’être élégante dès le départ. L’important est de pouvoir expliquer ses props, son rôle et ce qui se passerait si la valeur était absente. En fin de semaine, recrée une petite carte depuis une page blanche, sans assistance, puis demande à l’agent de te poser quelques questions. Les réponses qui te résistent deviennent le programme de la semaine suivante.

Deuxième semaine : tu tentes, l’IA relit

La deuxième semaine introduit les données externes. C’est un moment important, parce qu’un type TypeScript ne valide pas magiquement ce qu’une API t’envoie à l’exécution.

Définis une réponse nominale pour tes métriques, puis invente une réponse où une valeur est absente et une autre où elle est impossible. Écris toi-même la fonction qui récupère les données. Gère le cas d’une réponse HTTP non réussie. Ensuite, montre ta tentative à l’agent et demande-lui ce qu’elle fait réellement avant de lui demander une amélioration.

Travaille ensuite les états de l’interface. Que voit l’utilisateur pendant le chargement ? Que lui dis-tu lorsque le service est indisponible ? Que signifie une valeur invalide ? Ne remplace pas silencieusement une donnée inconnue par zéro juste pour rendre l’écran plus propre. L’interface doit rester honnête sur ce qu’elle sait et ce qu’elle ne sait pas.

À la fin de la semaine, relis le diff de tous tes changements. Tu peux demander à l’agent de signaler les fichiers hors périmètre, les responsabilités mélangées et les duplications inutiles. Mais commence par faire ta propre revue. C’est cette première lecture qui transforme l’outil en relecteur plutôt qu’en arbitre.

Troisième semaine : tu pilotes les modifications

La troisième semaine est celle où l’agent commence à écrire davantage. Pas parce qu’il est devenu plus fiable qu’avant, mais parce que tu as maintenant un cadre pour contrôler ce qu’il fait.

Avant d’ajouter un test pour la carte CPU, rédige le comportement attendu. Une valeur valide doit être affichée avec son unité. Zéro doit rester valide. Une valeur hors limites doit être visible comme une anomalie, pas convertie sans bruit. Une erreur API ne doit pas faire disparaître toute la page. Ce travail prépare la stratégie de test avant que l’implémentation ne l’influence.

Tu peux alors confier à l’agent une tâche limitée, à condition qu’il commence par un plan. Il te dit les fichiers concernés, les tests prévus et les commandes de validation. Tu valides le périmètre. Puis tu lis le diff final et tu vérifies qu’un test échoue bien si tu casses volontairement le comportement qu’il est censé protéger.

Introduis aussi un bug contrôlé. Par exemple, laisse passer une métrique null jusqu’au composant. Formule ton hypothèse avant de demander de l’aide. Observe la réponse brute, la valeur après validation et celle reçue par le rendu. L’agent peut proposer deux causes probables et une expérience pour les départager. Garde la trace de ce qui a réellement tranché. Tu apprends alors quelque chose de plus précieux qu’une correction : une méthode de diagnostic.

Termine cette semaine par une session sans agent. Ajoute une nouvelle métrique en t’appuyant sur la documentation et sur ce que tu as déjà construit. Ce n’est pas un examen. C’est une manière de vérifier que tu peux encore agir sans prompt lorsque le contexte devient moins confortable.

Quatrième semaine : l’agent exécute sous contrôle

La dernière semaine ne consiste pas à déléguer tout le projet. Elle consiste à déléguer de petites parties avec une responsabilité claire.

Écris les règles stables du dépôt dans AGENTS.md pour Codex ou CLAUDE.md pour Claude Code : les commandes qui doivent être lancées, l’architecture à respecter, les conventions et les points à vérifier. Ne transforme pas ce fichier en constitution de cinquante pages. Il doit rappeler les décisions qui t’évitent de les répéter à chaque conversation.

Prends ensuite un skill qui semble pertinent et inspecte-le avant de l’utiliser. Regarde ce qu’il fait, ce qu’il suppose, les scripts qu’il lance et si cela correspond vraiment à ton projet. L’objectif n’est pas d’accumuler des skills. L’objectif est de savoir donner un contexte utile à l’agent sans ajouter de règles qui se contredisent.

Tu peux alors lui confier l’ajout de la métrique disque, ou une petite amélioration bien définie. Exige le plan, valide les fichiers concernés, lis le diff et exécute les validations. Tu peux aussi lui demander deux pistes d’architecture avec leurs compromis. Refuse une abstraction si le besoin ne la justifie pas. Une solution plus complexe n’est pas automatiquement une solution plus mature.

Les derniers jours servent à documenter et à démontrer. Écris toi-même le README : installation, commandes, architecture, limites et décisions prises. Fais-le relire par l’agent. Puis présente ton dashboard comme lors d’une revue technique. Explique le flux de données, les états d’erreur, les tests et un compromis d’architecture. Tu n’as pas besoin d’être parfait. Tu dois être capable de dire ce que tu sais, ce qui reste incertain et comment tu le vérifierais.

Ce que tu dois pouvoir faire au trentième jour

À la fin du programme, le meilleur indicateur n’est pas la taille de ton dépôt ni le nombre de lignes générées. C’est ta capacité à modifier une métrique sans tout régénérer, à dire pourquoi une donnée est validée, à lire un diff avant de l’accepter et à transformer une erreur en hypothèse vérifiable.

Tu dois aussi pouvoir distinguer ce qui a été réellement testé de ce qui est simplement supposé. Cette nuance paraît presque administrative au début. C’est pourtant l’une des différences entre obtenir du code et assumer un logiciel.

Tu n’auras pas fini d’apprendre après trente jours. Personne ne devient senior en un mois, avec ou sans IA. En revanche, tu auras changé la nature de ton rapport à l’outil. Tu ne l’utiliseras plus uniquement pour éviter la difficulté. Tu l’utiliseras pour comprendre plus vite, recevoir de meilleurs retours et faire avancer des décisions que tu sais encore expliquer.

L’IA peut produire énormément de code. La valeur du développeur reste sa capacité à comprendre le système, choisir une direction et répondre de ce qui part en production.