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. Où l'outil perd

Un guide qui ne parle que des cas où ça marche te rend service à moitié. Il y a des situations où l'IA ne t'aide pas, et quelques-unes où elle te ralentit franchement. Les connaître, c'est ce qui te permet de faire confiance au reste.

Quand tu ne sais pas encore ce que tu veux. C'est le plus coûteux, et le moins visible. L'IA ne produit pas de la clarté, elle produit du code. Tu lui donnes un flou, elle te rend deux cents lignes plausibles, et tu as maintenant l'impression d'avancer alors que la question de départ n'est toujours pas tranchée. Pire : ces deux cents lignes deviennent un point d'ancrage dont tu auras du mal à te détacher. Le test simple, avant d'ouvrir une session : est-ce que je saurais reconnaître une bonne réponse si je la voyais ? Si non, va d'abord chercher la réponse, pas le code.

Quand écrire le prompt prend plus longtemps que d'écrire le code. Ça arrive plus souvent qu'on ne l'admet, sur tout ce qui est court, très spécifique à ton contexte, ou plus rapide à montrer qu'à décrire. Trois lignes que tes doigts connaissent, tu les tapes.

Quand le problème n'est pas dans le code. Une variable d'environnement absente en préproduction, une règle de firewall, un cache qui sert une vieille valeur, une donnée corrompue en base. Donne ce symptôme à un agent : il va te proposer, avec beaucoup d'assurance, de refactorer du code qui n'a rien à voir. Il travaille sur ce que tu lui montres, et tu lui montres du code. Avant de déléguer un bug, sache au moins dans quelle couche il vit.

Quand tu es en train d'apprendre quelque chose que tu veux savoir faire. Déléguer un exercice, c'est déléguer l'apprentissage. C'est parfaitement rationnel si tu ne comptes jamais refaire ce geste ; c'est un mauvais échange si c'est une compétence que tu veux acquérir. Le choix se fait en connaissance de cause, pas par défaut.

Quand le coût d'une erreur dépasse largement le coût du travail. Une migration de données irréversible, du code réglementaire, de la cryptographie. Ça ne veut pas dire « sans IA » : ça veut dire que le curseur bouge. Elle propose, elle critique, elle relit. C'est toi qui tapes.

---

4. 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 guide 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.

---

5. 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 9).
• 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 5.

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.