Routine Claude Code de 15 minutes : la méthode sûre pour débuter chaque matin

Un vendredi soir, j’ai lancé à Claude Code « répare tout ce qui te semble louche dans ce projet » et je suis allé me coucher.

Le lendemain matin, 23 fichiers avaient été modifiés. Certains tournaient même correctement. Mais j’étais incapable d’expliquer ce qui avait vraiment été corrigé, ni ce que je devais vérifier. Rien que pour lire le diff de haut en bas, il m’a fallu une heure, et au final, pris de doute, je n’ai pas osé committer une seule ligne.

J’avais confié une grosse tâche à une IA brillante, et pourtant j’avais reculé au lieu d’avancer. C’est le tout premier piège dans lequel tombent les débutants.

La cause n’est pas la performance de Claude Code. J’avais simplement oublié de définir comment « fermer » le travail. Aujourd’hui, je vous donne tel quel le déroulé de 15 minutes que je fais chaque matin pendant que mon café passe.

Points clés

« Répare tout » est une recette à accidents. Chaque jour, on ne fait qu’une seule petite tâche décidée en une phrase.
Avant de commencer à éditer, on choisit d’abord la commande de vérification qui dira si c’est terminé.
Après le travail, il suffit de garder trois choses : les fichiers modifiés, le résultat de la commande de vérification, et la prochaine action.
On confie à l’IA la partie « mettre les mains dans le cambouis ». Définir le périmètre et appuyer sur le bouton de publication, c’est l’humain.
En copiant-collant le script ci-dessous, vous enchaînez automatiquement vos vérifications du matin.

Pourquoi « fermer petit » marche si bien pour les débutants

Au début, quand je touchais à Claude Code, mon objectif était toujours flou. « Rends ça propre », « rends ça lisible ». Avec ça, même une fois le travail fini, j’étais incapable de dire ce que l’IA avait fait, et jusqu’où.

C’est exactement pareil avec un humain. Demandez à un nouveau collègue « occupe-toi de ce document, comme tu le sens » : dans la plupart des cas, il se retrouve perdu. Dites-lui plutôt « remplace les chiffres de la page 3 par la dernière version et vérifie que le tableau n’est pas cassé » : il démarre tout de suite, et il sait lui-même quand c’est terminé.

Dans une routine quotidienne, l’important n’est pas d’écrire la consigne parfaite d’un seul coup. C’est de découper petit et de donner une forme qui permet de juger la fin. Une fois que vous tenez ça, même en débutant, vous pourrez dire chaque jour : « voilà jusqu’où j’ai avancé aujourd’hui ».

D’ailleurs, ce raisonnement s’appuie sur deux autres articles : Comment démarrer avec Claude Code et les bases de la gestion des permissions. Préparez d’abord votre environnement avec ceux-là, puis posez cette habitude par-dessus : l’effet est bien plus net.

Ce qu’on fait en 15 minutes, ce n’est que 4 étapes

Le matin, je ne fais que ces quatre choses. Et toujours dans le même ordre. Fixer l’ordre permet au corps de bouger sans réfléchir.

Écrire en une phrase la plus petite tâche du jour. Du type « réécrire seulement les 3 lignes d’intro du README » : un grain assez fin pour que la fin soit visible. Les gros chantiers, on les écarte exprès aujourd’hui.
Choisir d’abord la commande de vérification. « C’est bon si npm run build passe », « c’est bon si un test repasse au vert » : on fixe la forme de l’objectif avant même de toucher au code.
Travailler, puis vérifier dans l’ordre : diff, build, URL publique. On ne publie pas d’un coup ; on regarde d’abord ce que la machine peut confirmer.
Laisser une seule ligne pour la fois suivante. On note « le risque qui reste » et « la prochaine plus petite tâche ». C’est le point de départ du lendemain matin.

Le point clé, c’est le numéro 2. Si vous commencez à éditer sans avoir choisi la commande de vérification, vous retombez dans ce fameux vendredi soir : « j’ai l’impression que c’est réparé, mais aucune certitude ». Tracez la ligne d’arrivée avant de courir. Rien que ça allège énormément le travail quotidien.

Ce qu’on confie à l’IA, et ce que l’humain décide

C’est là, je crois, que les débutants se perdent le plus. On ne peut pas tout déléguer à l’IA, mais si on fait tout soi-même, autant ne pas l’utiliser. J’ai mis les repères dans un tableau.

Moment	On confie à l’IA	L’humain décide / appuie
Périmètre	Proposer des pistes	Figer la phrase du jour
Édition	Écrire le code ou le texte	La direction de ce qu’on corrige
Vérification	Lancer build et tests	Quelle vérification fait office d’objectif
Publication	Résumer le diff	Appuyer sur le bouton de publication
Opérations risquées	Demander « est-ce que je peux ? »	La décision finale de supprimer / pousser en prod

Le critère en cas de doute est simple. Ce qui est réversible va à l’IA ; ce qui est irréversible reste à l’humain. Une édition de fichier se refait autant de fois qu’on veut, donc on la confie. La publication en production ou la suppression d’un fichier, au début on appuie toujours soi-même. On ne fait passer en automatique que les gestes devenus familiers, petit à petit. Le réglage fin des autorisations est entièrement détaillé dans la documentation officielle de Claude Code ; en cas d’hésitation sur où tracer la ligne, un coup d’œil rassure.

Un modèle de consigne à copier-coller

Si vous réécrivez la consigne de zéro à chaque fois, le grain part dans tous les sens. Moi, je garde ce modèle collé dans mon appli de notes et je remplis les trous chaque matin.

Plus petite tâche du jour : (une phrase ici. Ex : réécrire les 3 lignes d'intro du README)
Périmètre autorisé : (ex : README.md uniquement. Interdiction de modifier les autres fichiers)
Méthode de vérification : (ex : npm run build doit réussir)

Marche à suivre :
1. D'abord, sans rien modifier, lis l'état actuel et résume-le.
2. N'édite que le périmètre ci-dessus. Ne touche pas à ce qui est en dehors.
3. Après édition, indique les noms des fichiers modifiés et le résultat de la vérification.
4. S'il faut supprimer, pousser en prod ou envoyer vers l'extérieur, ne l'exécute pas : demande d'abord.

Rien qu’en ajoutant les deux lignes « ne touche pas au hors-périmètre » et « les opérations dangereuses, demande d’abord », l’accident des 23 fichiers du début ne se reproduit quasiment plus. L’idée n’est pas de donner la liberté à l’IA, mais de lui tendre une boîte sûre.

Un script de vérification prêt à l’emploi

Les vérifications du matin, si on les tape à la main, on finit par les oublier. Moi, je garde ce script sous le nom morning-check.mjs et je le lance avant même de me servir un café. Ça marche dès que Node.js est installé.

// morning-check.mjs : enchaîne et exécute les vérifications du matin dans l'ordre
import { execSync } from "node:child_process";

// Listez les commandes à vérifier de haut en bas. Adaptez-les à votre projet.
const checks = [
  { label: "Fichiers modifiés", cmd: "git status --short" },
  { label: "Le build passe-t-il ?", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // Affiche le résultat tel quel. En cas d'erreur, on passe au catch ci-dessous.
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(aucune sortie)");
  } catch (e) {
    allOk = false;
    console.log("Échec :", e.message.split("\n")[0]);
  }
}

console.log("\n--- Clôture du jour ---");
console.log(allOk ? "Vérifs OK. Notez la prochaine plus petite tâche en une ligne." : "Une vérif a bloqué. Corrigez avant d'aller plus loin.");

Le lancement, c’est juste ça.

node morning-check.mjs

L’astuce est de réécrire le contenu de checks selon votre projet. Si vous avez des tests, ajoutez npm test ; pour un site statique, ajoutez la vérification de l’URL publique. Le simple fait que les mêmes commandes défilent dans le même ordre chaque matin fait quasiment disparaître les oublis de vérification. Personnellement, j’y ai ajouté un contrôle « est-ce que je suis resté bloqué sans committer à la fin ? ».

Des situations où ça marche (3 exemples)

Exemple 1 : le premier jour, on dresse juste la carte du repo Pas besoin de corriger du code tout de suite. Demandez à l’IA de résumer « où sont les répertoires sensibles » et « où se trouvent les fichiers de configuration », et lisez-le : pour un premier jour, c’est déjà une réussite. Le travail des jours suivants ira bien plus vite.

Exemple 2 : le deuxième jour, un seul paragraphe du README On se crée une petite victoire. Réécrire 3 lignes d’intro, puis vérifier avec npm run build que rien n’est cassé. C’est tout. En terminant petit et en allant jusqu’au bout de la vérification, on gagne ce sentiment : « je sais m’en occuper moi-même ».

Exemple 3 : le troisième jour, une petite amélioration reliée à un chiffre Corriger un titre d’article, ajouter un test, réparer un lien mort. On choisit une amélioration dont le résultat se voit. L’essentiel est d’empiler chaque jour un « changement allé jusqu’à la vérification ».

Exemples d’échecs, et comment s’en sortir

En toute honnêteté, je me suis cassé la figure plusieurs fois sur ces trois points.

Piège 1 : vouloir tout faire d’un seul coup. « Tout ce qui me semble louche » produit un diff énorme et invérifiable. Le remède est simple : limiter la phrase du jour à une seule chose. Le reste part dans la note de demain.

Piège 2 : considérer que le build local suffit pour dire « terminé ». Même si npm run build passe, rien ne garantit que l’URL publique affiche le bon résultat. Un jour, le build était vert mais la page publique restait l’ancienne version, et je ne m’en suis pas rendu compte. Le remède : après publication, ouvrir l’URL réelle et vérifier de ses yeux que le titre et le début du texte correspondent bien à la modification du jour.

Piège 3 : valider une approbation dangereuse par automatisme. Quand une boîte de dialogue de confirmation apparaît, le débutant a tendance à cliquer « Oui » par réflexe. Si une confirmation de suppression ou de mise en production arrive, arrêtez-vous une seconde. En cas d’hésitation, la bonne réponse est de ne pas faire cette opération aujourd’hui. Pour la logique des permissions, l’explication destinée aux non-développeurs est aussi une bonne référence.

La forme de la note à laisser pour la fois suivante

La note finale peut être courte. Mais fixez-en la forme pour que le vous du lendemain ne refasse pas les mêmes arbitrages.

- Fait aujourd'hui : réécriture des 3 lignes d'intro du README
- Méthode de vérification : npm run build réussi / titre vérifié sur l'URL publique
- Risque restant : 2 liens d'images cassés
- Plus petite tâche de demain : réparer un seul lien d'image

Avec cette note, le temps passé le lendemain matin à se demander « par quoi je commence ? » tombe à zéro. Depuis que je fais ça, mon démarrage du matin a gagné environ cinq minutes, au ressenti.

FAQ

Q. Je n’ai pas 15 minutes par jour. On peut faire plus court ? Oui. Au début, « écrire la plus petite tâche du jour en une phrase » suffit déjà. Dès que vous prenez l’habitude de choisir la commande de vérification, le temps de travail se réduit naturellement.

Q. Je ne sais pas quelle commande de vérification choisir. Si votre projet a npm run build ou npm test, commencez par là, c’est largement suffisant. S’il n’y a rien, « ouvrir l’URL publique et regarder de ses yeux » est une vérification tout à fait valable. Au début, fixez une seule chose que la machine sait confirmer.

Q. Ce ne serait pas plus rapide de tout confier à l’IA ? À court terme, ça en a l’air. Mais un « changement qu’on ne sait pas expliquer » finit toujours par devoir être relu en entier plus tard. Fermer petit est, au total, plus rapide : c’est mon ressenti concret.

Q. Par quoi un débutant devrait-il commencer en tout premier ? Par dresser la carte du repo. Avant de toucher au code, faites résumer par l’IA où se trouve quoi, et lisez-le. C’est la base pour avancer en sécurité.

Q. Cette routine fonctionne-t-elle aussi pour un déploiement en équipe ? Oui. Mais en équipe, documentez d’abord « qui approuve la publication » et « quelle vérification fait office d’objectif » : l’habitude individuelle devient alors directement une règle d’équipe.

Ce que j’ai constaté en l’essayant vraiment

Depuis ce fameux vendredi soir, j’ai arrêté de me torturer avec « jusqu’où confier à l’IA ». À la place, je ne décide chaque matin que deux choses : la phrase du jour et la commande de vérification.

En faisant tourner morning-check.mjs pendant deux semaines, ce qui a le plus changé, ce sont les oublis de vérification. Avant, je committais en croyant que le build passait, et plus tard je découvrais que c’était cassé. Depuis que je fais défiler les vérifications dans le même ordre par la machine, ces cas sont tombés à zéro.

Et puis, les 4 lignes de note laissées chaque soir. Depuis que j’ai commencé, le « c’était quoi déjà, à faire ? » du lendemain matin a disparu. Plutôt que de chercher l’usage astucieux, fermez petit et gardez une trace de la vérification. C’est modeste, mais je crois que c’est là que se joue la vitesse à laquelle un débutant avance vraiment.

Pour commencer, dès demain matin, décidez d’une seule phrase et lancez une seule commande de vérification. Quand, à force, vous aurez forgé votre propre modèle, élargissez votre stock de consignes avec le catalogue de formations : vos gestes quotidiens se réduiront encore.