L'IA écrit ton code. Mais est-ce vraiment ton code ?

Soyons directs : voir une IA générer une API fonctionnelle, avec son système d'authentification et ses migrations de base de données, en moins de deux minutes, ça ressemble à de la magie. C'est aussi profondément déstabilisant.

Un développeur a récemment partagé son expérience sur Hacker News. Il décrivait ce moment précis où il observait des outils IA produire du « code qui marche, vraiment vite » — même à partir de prompts mal formulés. Et cette sensation étrange qui suit : un sentiment de perte. Pas celui de la productivité. Celui de la propriété. Le code fonctionne, mais il est vraiment à lui ?

Ce témoignage a trouvé un écho chez beaucoup plus de développeurs qu'ils ne voudraient l'admettre.

Le fossé entre ce qu'on veut et ce qu'on obtient

Le problème fondamental, c'est que le langage naturel est imprécis par nature. Quand tu dis à une IA « ajoute une authentification utilisateur », tu communiques une intention, pas une spécification. L'IA comble des dizaines de décisions implicites — la gestion des sessions, le stockage des tokens, les flux de réinitialisation de mot de passe, la limitation de débit — des choix auxquels tu n'as jamais pensé consciemment.

Le développement logiciel classique a toujours impliqué une phase d'expansion : partir d'exigences vagues et les formaliser. Mais cette expansion se faisait progressivement, à travers des choix humains assumés. Des choix dont on pouvait expliquer le raisonnement.

L'IA inverse ce processus. Elle prend ton brouillon et te livre une implémentation complète en quelques secondes. Tu n'as pas fait ces choix intermédiaires. Tu ne peux pas expliquer pourquoi le token expire en 24 heures plutôt qu'en 7 jours. Tu as juste… accepté les valeurs par défaut.

Pourquoi c'est important (et pas juste une question d'ego)

Ce n'est pas de la fierté blessée. La perte d'agentivité dans le code a des conséquences bien concrètes :

• Le debugging devient de l'archéologie. Quelque chose casse ? Tu suis une logique que tu n'as pas écrite, des décisions que tu n'as pas prises.
• Les failles de sécurité se cachent dans du code que tu n'as jamais relu. « Ça m'a l'air correct » n'est pas une stratégie de sécurité.
• La dette technique s'accumule silencieusement. Les valeurs par défaut de l'IA semblaient raisonner isolément, mais ton codebase contient maintenant trois approches différentes pour la gestion des erreurs parce que l'IA a proposé des variations à chaque fois.
• Le transfert de connaissances échoue. Quand un collègue te demande pourquoi le système d'auth fonctionne de cette façon, tu n'as pas de réponse.

Récupérer le contrôle sans jeter l'IA avec l'eau du bain

La solution n'est pas de rejeter les outils de coding IA — ce train est parti et il ne reviendra pas. La solution, c'est de faire évoluer notre relation avec eux.

Considère la sortie de l'IA comme un premier jet, pas une réponse finale. La différence entre les développeurs juniors qui progressent et ceux qui stagnent tient souvent à leur façon de traiter les drafts. Le code IA n'est qu'un premier jet très sophistiqué.

Définis tes spécifications plus soigneusement. Avant de requêter, note noir sur blanc les contraintes et exigences explicites. « Ajoute une authentification » devient « Ajoute une authentification basée sur JWT avec expiration du token à 1 heure, hashage bcrypt des mots de passe, et endpoints de connexion avec limitation de débit. » Plus tu es précis, plus l'IA exécute ta vision plutôt que d'en inventer une.

Relis avec intention, pas par obligation. Au lieu de lire chaque ligne (ce qui devient fastidieux et génère de la fatigue de revue), concentre-toi sur les décisions architecturales et les chemins critiques pour la sécurité. Laisse l'IA gérer le boilerplate ; ton cerveau gère le jugement.

Construis des boucles de rétroaction. Après que le code tourne, refactoris certaines sections à la main. Ajoute des commentaires expliquant les choix. Change quelque chose et observe ce qui casse. Cet engagement pratique reconstruit le modèle mental que la génération IA érode.

Le métier n'est pas mort

Il y a cette peur que le coding IA rende les développeurs interchangeables — que si le code est assez bon, peu importe qui l'a écrit. Mais le développement logiciel a toujours été plus que produire du code qui fonctionne. C'est comprendre les systèmes assez profondément pour les maintenir, les faire évoluer, et les expliquer.

Les développeurs qui s'en sortiront dans ce nouveau paysage ne seront pas ceux qui génèrent le plus de code avec l'IA. Ce seront ceux qui maintiennent des modèles mentaux solides de leurs systèmes malgré l'assistance IA — des développeurs capables de dire « L'IA a suggéré cette approche, mais je choisis l'autre parce que… »

Cette distinction — être capable d'articuler le pourquoi — c'est ce qui sépare les opérateurs des observateurs.

Les outils de coding IA sontextraordinairement utiles. Ils sont aussi le test de quelque chose de plus profond : est-ce que tu resteras engagé dans ton métier ou deviendras-tu spectateur de tes propres projets ?

Le choix, comme toujours, t'appartient.