Tenir un système entier en tête
Elle raisonne très bien sur ce qu’elle voit. Les interactions entre modules éloignés, les effets de bord à distance, la cohérence globale d’une grosse base : c’est là qu’elle décroche.
1 · Les faiblesses
Ce que l’IA fait mal aujourd’hui
Ces limites sont structurelles, pas des bugs en attente de correction. Les connaître évite de perdre des heures à insister là où ça ne marchera pas.
Dire « je ne sais pas »
Le mécanisme pousse à produire une réponse plausible plutôt qu’à s’abstenir. Le ton reste assuré même quand c’est faux, et il n’y a pas de signal fiable de doute.
Connaître ton métier
Les règles implicites de ton domaine, les contraintes réglementaires, l’historique des décisions : rien de tout ça n’est dans le code. Sans toi, elle optimise le mauvais objectif.
Les nouveautés récentes
Une librairie sortie ou modifiée après son entraînement sera traitée avec l’ancienne API, en toute confiance. Sur du récent, il faut la forcer à lire la doc.
Le calcul exact et le comptage
Arithmétique fine, dénombrement, manipulation précise de gros volumes : à faire exécuter par du code, jamais à demander de tête.
Arbitrer des compromis
Vitesse contre maintenabilité, dette assumée contre dette subie, périmètre à couper. Elle peut lister les options ; le choix engage une responsabilité qu’elle n’a pas.
2 · Le bon moment
Quand l’utiliser, quand s’abstenir
L'IA est un excellent accélérateur et un mauvais décideur. Elle produit vite ce que tu sais évaluer, et elle t'enfonce vite dans ce que tu ne comprends pas.
Le point de départ de tout ce chapitre✓ Là où elle excelle
Explorer une base inconnue. Écrire du code répétitif ou mécanique. Traduire d’un langage à un autre. Générer des tests à partir d’un comportement décrit. Expliquer du code obscur. Produire une première version jetable pour réfléchir. Faire une passe de relecture supplémentaire.
✗ Là où il vaut mieux fermer l’agent
Quand tu ne sais pas évaluer le résultat. Sur un domaine critique que tu ne maîtrises pas (crypto, sécurité fine, calcul financier). Quand la décision engage l’architecture pour des années. En pleine panique de production. Et quand tu es en train d’apprendre quelque chose que tu veux vraiment savoir faire.
Le test décisif : si le résultat était faux, est-ce que tu t’en
rendrais compte ? Si la réponse est non, tu n’es pas en train de déléguer une tâche —
tu es en train de parier.
3 · Le risque personnel
L’atrophie, dont personne ne parle
C’est la limite la plus inconfortable, parce qu’elle ne vient pas de l’outil mais de l’usage qu’on en fait.
Une compétence qu’on n’exerce plus s’émousse. Si tu ne débugges plus jamais toi-même, tu perds la lecture rapide d’une stack trace. Si tu n’écris plus de tests, tu perds l’intuition de ce qui doit être testé.
Le problème n’est pas de gagner du temps — c’est que ta capacité à évaluer ce que produit l’IA repose entièrement sur ces compétences. Le jour où elles s’érodent, tu ne peux plus juger, et tu acceptes tout.
Le signal d’alerte le plus net : merger du code que tu ne saurais pas réécrire, ni même expliquer ligne à ligne.
1
Comprendre avant de merger
Pas besoin d’avoir tout écrit, mais tu dois pouvoir expliquer chaque partie. Si tu ne peux pas, demande l’explication jusqu’à ce que ce soit clair.
2
Garder des zones à la main
Choisis délibérément ce que tu continues à faire toi-même — souvent le cœur métier, celui que tu dois maîtriser mieux que quiconque.
3
Apprendre d’abord, déléguer ensuite
Sur une techno que tu veux vraiment maîtriser, fais les premiers pas sans agent. Ensuite seulement, accélère.
4
S’en servir pour apprendre
Demander « explique-moi pourquoi cette approche est meilleure » transforme l’outil en professeur au lieu d’un simple exécutant.
4 · L’illusion
Trois pièges de perception
La vitesse ressentie
On se souvient du prototype sorti en dix minutes, pas des trois heures passées à corriger ce qui semblait fini. Le gain est réel, mais souvent plus faible que l’impression — surtout sur du code destiné à durer.
La propreté trompeuse
Le code généré est bien nommé, bien indenté, bien structuré. Cette apparence professionnelle endort la vigilance : on relit moins attentivement quelque chose qui a l’air bon.
La dette invisible
Produire plus vite que la capacité à comprendre crée une dette qui ne se voit pas tout de suite. Elle apparaît le jour où il faut modifier ce code — et où personne ne sait pourquoi il est écrit comme ça.
Vérifie que c’est acquis
Quel est le meilleur test pour savoir si tu peux déléguer une tâche à un agent ?
Tant que tu peux évaluer le résultat, l’IA est un accélérateur : au pire tu détectes
l’erreur et tu corriges. Dès que tu ne peux plus juger, tu ne délègues plus une tâche,
tu paries sur une sortie plausible — et un code faux qui a l’air correct passera.
À retenir
Accélérateur, pas pilote automatique
L’IA est mauvaise pour tenir un système entier en tête, dire qu’elle ne sait pas, connaître ton métier et arbitrer des compromis. Utilise-la à fond là où tu sais juger, garde la main sur ce que tu dois maîtriser, et ne merge jamais du code que tu ne saurais pas expliquer. C’est ta compétence qui rend l’outil puissant, pas l’inverse.