Identifiez les compétences qui prennent de la valeur quand la génération de code se banalise, et outillez-vous pour les cultiver délibérément.
Ouvrir cette leçon dans KodokonQuand une capacité se banalise, sa valeur marchande chute et se déplace vers ce qui l'encadre. La traduction écrite l'a vécu, la photographie aussi. Pour le développement, la capacité banalisée est claire : produire du code correct à partir d'une spécification précise. Ce qui prend mécaniquement de la valeur, ce sont les deux extrémités de la chaîne que l'IA ne couvre pas. En amont : la spécification - transformer un besoin flou, contradictoire, politique, en problème bien posé ; c'est la compétence que tout utilisateur d'assistant redécouvre à ses dépens, un prompt n'étant rien d'autre qu'une spécification dont on paie chaque imprécision. En aval : la vérification - revue, test, audit de sécurité, capacité à dire « ce code plausible est faux » ; elle devient critique précisément parce que le volume de code plausible explose. Et au-dessus des deux : l'architecture, les décisions de structure dont les effets se mesurent en années et que le modèle, sans mémoire de votre organisation ni responsabilité sur ses conseils, ne peut pas porter.
Le danger pour un senior n'est pas le remplacement, c'est l'atrophie non détectée. Les compétences de fond déclinent sans douleur : rien ne signale que votre capacité à déboguer sans assistance ou à concevoir une API de zéro s'est érodée, jusqu'au jour où elle est requise. La réponse est un audit délibéré et régulier de ce que vous exercez réellement - par opposition à ce que vous croyez exercer. C'est un usage d'IA à contre-emploi savoureux : utiliser le modèle pour mesurer ce que le modèle vous fait perdre.
Tu es mon coach de carrière technique, direct et sans complaisance. Voici le relevé honnête de ma semaine de travail avec assistance IA :
- Tâches où j'ai produit moi-même (l'IA en relecture) : [LISTER]
- Tâches entièrement déléguées à l'IA : [LISTER]
- Code accepté sans pouvoir l'expliquer en détail : [LISTER, même si c'est inconfortable]
- Décisions techniques prises cette semaine : [LISTER]
Analyse en trois volets :
1. Compétences réellement exercées cette semaine (celles qui montent) contre compétences déléguées (celles qui risquent l'atrophie).
2. Ma dette de compréhension : chaque élément de la troisième liste, avec le risque concret associé.
3. UN exercice de 30 minutes pour la semaine prochaine, ciblant ma compétence la plus fragile, à réaliser sans aucune assistance.
Format : bilan en 10 lignes maximum. Je préfère une critique juste à un encouragement vague.Rester critique se travaille aussi. La bonne posture s'appelle confiance calibrée : ni la méfiance systématique qui annule le gain de productivité, ni la confiance aveugle qui installe la complaisance. Calibrer, c'est ajuster l'intensité de vérification à deux variables : le coût d'une erreur (une regex de script jetable et une politique d'autorisation ne méritent pas le même examen) et le taux d'erreur constaté du modèle sur ce type de tâche - que vous ne connaîtrez qu'en vérifiant réellement, au début, tout ce qu'il produit dans votre domaine. Tenez ce compte quelques semaines : vous saurez où le modèle excelle, où il hallucine, et votre vigilance se placera exactement où elle rapporte.
À partir de maintenant et pour toute cette conversation, adopte le rôle de mentor plutôt que d'exécutant. Règles permanentes :
1. Quand je te demande du code, commence par me demander de proposer mon approche ; ne présente la tienne qu'ensuite, en la comparant explicitement à la mienne.
2. Quand tu me corriges, énonce le principe général derrière la correction, pas seulement le correctif ponctuel.
3. Une fois par réponse, pose-moi une question qui vérifie que j'ai compris, et attends ma réponse avant de continuer.
4. Si je te demande simplement de « faire à ma place », rappelle-moi la présente consigne et propose la version guidée.
Confirme que tu as compris en reformulant ces règles en une seule phrase.L'employabilité, au fond, se résume à une question que poseront tous les recruteurs des prochaines années : qu'apportez-vous que le modèle n'apporte pas ? La réponse défendable tient en trois mots vus dans ce parcours : spécifier, vérifier, décider - et une méthode : continuer d'apprendre en profondeur, avec l'IA comme tuteur exigeant plutôt que comme distributeur de solutions. Un développeur qui comprend ce qu'il déploie reste rare, donc cher. C'était la thèse de la première leçon ; c'est aussi la conclusion du parcours.