Mindset

---

1. Ce que l'IA change vraiment à ton métier

Autant le dire tout de suite : non, l'IA ne va pas écrire ton métier à ta place. Ce qu'elle fait, c'est déplacer l'endroit où ton jugement compte.

Pendant vingt ans, le travail tenait dans un même geste : tu ouvrais un fichier vide et tu le remplissais, de la première accolade à la dernière. Aujourd'hui une bonne partie de ce remplissage part à la machine. Toi, tu interviens avant (qu'est-ce qu'on construit, et pourquoi comme ça) et après (est-ce que ce qui est sorti tient debout). Le milieu, la frappe, n'est plus le cœur de la valeur.

Le temps que tu ne passes plus à taper, tu le passes à décider. Des décisions plus nombreuses, et prises plus tôt. La vraie question n'est plus « comment j'écris cette fonction » mais « est-ce seulement la bonne fonction à écrire ». C'est un métier plus dense, pas plus tranquille. Et c'est une bonne nouvelle pour qui aime concevoir.

---

2. Les 3 niveaux d'usage

Il y a trois façons de travailler avec l'IA. Aucune n'est « meilleure » dans l'absolu : elles répondent à des tâches différentes.

Niveau 1 — Autocomplete

L'IA complète ce que tu es en train de taper, inline dans l'éditeur.

• Pour : boilerplate, fermeture de boucles, getters/setters, ce que tes doigts connaissent déjà.
• Ses limites : zéro vision d'architecture, zéro planification. Elle devine la ligne, pas l'intention.

Niveau 2 — Chat / collaboration

Tu dialogues dans un panneau, tu colles du code, tu poses des questions.

• Pour : débug, refactoring, génération de tests, questions sur le codebase.
• Ses limites : si tu ne cadres pas, elle improvise. Le dialogue ne vaut que ce que valent tes questions.

Niveau 3 — Agent autonome

L'IA explore le repo, planifie, modifie des fichiers, lance des commandes.

• Pour : features complètes, migrations, pipelines de génération.
• Prérequis : context engineering maîtrisé, supervision active, vérification de chaque sortie. Sans ça, c'est un stagiaire surpuissant lâché sans review. Exactement ce qu'on ne veut pas.

---

3. L'autre piège : l'atrophie

Il y a une crainte que peu de seniors avouent à voix haute : à force de déléguer, est-ce que je perds la main ?

La réponse mérite d'être honnête : oui, si tu ne fais rien pour l'éviter. Tester un algo dans sa tête, lire une stack trace de bout en bout, remonter une cause racine sans filet — ce sont des réflexes qui se perdent vite quand on arrête de s'en servir. Ce n'est pas dramatique, c'est physique. Un muscle qu'on n'utilise plus fond.

Il y a là une asymétrie qu'on oublie souvent. Ce livre parle aux seniors, mais le piège est bien pire pour un junior. Un senior qui arrête de lire les stack traces perd un muscle qu'il a déjà construit ; il le retrouve en quelques jours. Un junior qui laisse l'agent tout faire ne construit jamais ce muscle. Il n'a rien à retrouver. Les trois habitudes ci-dessous comptent donc double pour un débutant.

Trois habitudes suffisent à garder le tonus :

1. Une session par semaine sans agent. Tu prends une vraie tâche et tu la fais à la main, autocomplete maximum. C'est désagréable les premières fois. C'est précisément le signe que ça sert.
2. Tu écris toi-même les zones critiques. Auth, paiement, crypto, tout ce qui touche aux données des utilisateurs : tu reprends le clavier, ligne par ligne. Le coût en temps est dérisoire face à l'enjeu.
3. Une review entièrement manuelle de temps en temps. Sans demander à l'IA de te résumer le diff. C'est ce qui entretient l'œil — la capacité à sentir qu'un truc cloche avant même de savoir quoi.

L'idée de fond : tu peux déléguer l'exécution, pas la réflexion. Et la réflexion ne reste affûtée que si tu continues de t'en servir.

---

4. Les anti-patterns à reconnaître

Pourquoi leur donner un nom ? Parce qu'un travers qui porte un nom, tu le repères beaucoup plus vite quand c'est toi qui tombes dedans.

Anti-pattern 1 — Vibe Coding

Tu décris vaguement, tu acceptes ce qui sort sans le lire, tu merges.

Ce que ça coûte :

• De la dette invisible : le code marche mais ne ressemble à rien de ce que fait l'équipe.
• Des failles qui passent sous le radar. Sans contexte de sécurité, près d'une génération sur deux introduit une vulnérabilité (les chiffres et les sources sont dans le Module 8).
• Une compréhension de ton propre codebase qui s'effrite, commit après commit.

Anti-pattern 2 — Over-Trust

Tu fais confiance parce que « ça a l'air bien », ou parce que le ton est assuré.

Rappel utile : un LLM prédit du texte plausible. Il peut inventer une fonction, une librairie ou un comportement d'API avec exactement la même assurance que lorsqu'il a raison. Ce ton assuré n'est pas un signe de fiabilité, c'est même souvent l'inverse.

Anti-pattern 3 — Kitchen Sink Session

Tu ouvres une session pour un bug, tu dévies sur une idée de feature, tu reviens au bug, tu enchaînes sur un refactoring.

Résultat : le contexte se charge de tout et de n'importe quoi, et la qualité des réponses se dégrade sans prévenir. Une tâche, une session — on y revient au Module 4.

Anti-pattern 4 — Prompt-and-Ship

Générer, copier, déployer. Pas de test, pas de review, pas de compréhension.

Anti-pattern 5 — L'ancrage sur le premier plan

Tu demandes un plan à l'agent, il t'en sort un qui a l'air raisonnable, tu l'acceptes. Sans jamais demander : « et sinon, quelle autre approche ? »

Le premier plan que propose un modèle, c'est l'approche la plus courante sur le web, pas forcément la meilleure pour ton contexte. Over-Trust, c'était faire confiance au code généré. L'ancrage, c'est faire confiance à l'approche proposée. La nuance compte, parce qu'à l'ère des agents tu ne délègues plus seulement l'écriture du code : tu délègues aussi la conception. Le réflexe à garder : sur une décision qui pèse, demande deux ou trois options avec leurs compromis avant de trancher. Le premier plan est une proposition à examiner, pas la réponse à adopter par défaut.