Tout le monde a un avis sur l'IA et le code en ce moment. Certains disent qu'elle va remplacer les développeurs. D'autres qu'elle n'est qu'un autocomplete sous stéroïdes. Voici le mien — construit à force de l'utiliser, pas juste d'en parler.
Le piège dont personne ne vous prévient
Quand vous commencez à utiliser l'IA pour coder, la première sensation, c'est la puissance. Vous décrivez quelque chose, elle le génère, vous collez, ça marche. Incroyable.
Puis trois jours plus tard, vous déboguez un truc que vous ne comprenez pas, dans un fichier que vous n'avez pas vraiment lu, construit sur une logique que vous n'avez jamais apprise.
Le vibe coding — décrire ce que l'on veut et accepter tout ce qui sort — n'est pas du développement. C'est sous-traiter sa réflexion à un outil qui ne comprend pas votre projet.
Le code tourne. Mais il n'est pas à vous. Et dès que quelque chose casse, vous ne savez pas par où commencer.
Ce qu'est réellement l'IA
Un assistant de code IA n'est pas un développeur. C'est un collaborateur très rapide et très cultivé, qui n'a aucun contexte sur votre projet, vos contraintes ou vos objectifs — sauf si vous le lui donnez explicitement.
Il ne sait pas :
- pourquoi vous avez choisi cette architecture
- ce que cette fonction est censée faire dans trois mois
- quels compromis vous avez déjà écartés
Vous, si. C'est toute la différence. Et cette différence est tout.
Le développeur qui utilise bien l'IA est celui qui apporte la réflexion. L'IA ne fait qu'aider à l'exécuter plus vite.
Le minimum avant de prompter
Avant de demander à l'IA de vous aider à construire quelque chose, il vous faut trois choses :
Savoir ce que vous construisez
Pas juste « un dashboard » — quelles données affiche-t-il, qui le lit, quelles actions permet-il ? Plus votre modèle mental est précis, meilleur est le résultat.
Connaître les concepts impliqués
Si vous construisez un flux d'authentification, vous devriez comprendre les sessions, les tokens et le middleware — même en surface. L'IA peut l'implémenter, mais vous devez reconnaître quand l'implémentation est fausse.
Connaître votre stack
L'IA générera avec assurance du code pour la mauvaise version de votre framework, utilisera une API dépréciée, ou suggérera une librairie qui entre en conflit avec ce que vous avez. Si vous ne connaissez pas votre stack, vous ne pouvez pas repérer ces erreurs.
Une bonne règle : si vous ne pouviez pas expliquer en français simple ce que fait le code généré, ne le committez pas.
Comment je l'utilise concrètement
Pas comme un générateur. Comme un accélérateur.
Pour comprendre — quand je tombe sur un concept que je ne maîtrise pas complètement, je demande à l'IA de me l'expliquer de trois façons différentes. Pas pour obtenir la réponse, mais pour construire l'intuition plus vite qu'une simple lecture de doc.
Pour le boilerplate — le code de setup répétitif, les fichiers de config, les définitions de types. Ce qui est mécanique et bien défini. Je le relis, je ne le copie pas bêtement.
Pour le débogage — je décris le comportement, je partage le code pertinent, et je demande des hypothèses. Je traite chaque réponse comme une piste à explorer, pas comme une solution à appliquer aveuglément.
Pour le refactoring — « voici cette fonction, voici ce qu'elle fait, quelles sont les manières plus propres de l'écrire ? » Puis je choisis celle que je comprends le mieux, pas la plus astucieuse.
Ce que je refuse de déléguer
Certaines choses restent miennes :
- Les décisions d'architecture — la structure de l'app, où vivent les données, comment les composants communiquent. L'IA n'a aucun intérêt à la santé de votre codebase sur le long terme. Vous, si.
- Comprendre un nouveau concept — je vais utiliser l'IA pour accélérer l'apprentissage, pas pour le contourner. Il y a une différence entre « explique-moi ça » et « fais-le à ma place ».
- Lire le résultat — chaque ligne générée par l'IA, je la lis. Pas en diagonale. Je la lis. C'est non négociable.
La vue d'ensemble
La peur que l'IA remplace les développeurs passe à côté du sujet.
L'IA remplace les parties mécaniques du métier — le boilerplate, les recherches, les schémas répétitifs. Elle ne remplace pas le jugement, l'architecture, l'intuition de débogage, ni la capacité à comprendre un problème avant de le résoudre.
Les développeurs les plus en danger ne sont pas les seniors qui en savent trop. Ce sont les juniors qui utilisent l'IA pour éviter d'apprendre.
Utilisez-la pour apprendre plus vite. Pour avancer plus vite. Mais jamais pour éviter de réfléchir.
Cette partie-là reste la vôtre.
Comments
Sign in with GitHub to join the conversation.