Pendant des décennies, écrire du code impliquait un contrat tacite. Si vous l'aviez écrit, vous le compreniez. Peut-être pas parfaitement, on oublie tous les détails d'un algorithme complexe après quelques mois. Mais au moins, vous aviez traversé le processus mental de sa construction.
Ce processus, c'est ce qui créait la compréhension. Quand vous écriviez une fonction de tri, vous deviez réfléchir aux cas limites. Que se passe-t-il avec un tableau vide ? Avec des valeurs nulles ? Avec des nombres négatifs ? Ces questions vous forçaient à explorer l'espace du problème.
Avec Copilot ou ChatGPT, ce processus s'évapore. Vous tapez un commentaire "trie ce tableau par date décroissante en gérant les valeurs null" et vous obtenez une implémentation complète. Fonctionnelle. Testée (peut-être). Mais vous n'avez jamais exploré l'espace du problème. Vous avez délégué cette exploration à l'IA.
Et voici le paradoxe. Le code fonctionne. Les tests passent. Vous êtes 10 fois plus productif qu'avant. Mais vous êtes aussi 10 fois moins connecté au code que vous produisez.
On parle beaucoup de dette technique. Du code qu'on écrit vite aujourd'hui et qu'on devra refactoriser plus tard. Mais l'IA introduit quelque chose de nouveau qu’on pourrait appeler une dette de compréhension.
Imaginez que vous utilisez Copilot pour générer 50% de votre codebase. Vous relisez rapidement, ça semble correct, vous validez. Six mois plus tard, vous devez modifier cette partie du code. Sauf que vous ne l'avez jamais vraiment comprise. Vous devez d'abord reverse-engineer ce que l'IA a fait, puis faire votre modification.
Mais voilà le piège ! Au lieu de passer une heure à décortiquer le code existant, vous demandez à l'IA de faire la modification. Elle génère du nouveau code. Vous vérifiez superficiellement. Ça marche. Vous validez. La dette de compréhension vient de grandir.
Au fil du temps, vous vous retrouvez avec une codebase de plus en plus opaque. Pas parce que le code est mal écrit. Au contraire, l'IA écrit souvent du code plus ou moins propre. Mais parce que personne dans l'équipe n'a jamais vraiment construit la carte mentale de comment tout ça fonctionne ensemble.
C'est encore plus pernicieux dans les équipes. Avant, quand LeDevNovice écrivait une fonction complexe, BenjaminCode pouvait la lire et comprendre le raisonnement de LeDevNovice. Il apprenait quelque chose sur la façon dont LeDevNovice pensait les problèmes. Maintenant, LeDevNovice génère le code avec Copilot. BenjaminCode le relit, voit que ça fonctionne, et approuve. Mais ni LeDevNovice ni BenjaminCode ne comprennent vraiment ce code. Ils ont juste validé qu'il passait les tests.
Il y a un phénomène psychologique bien documenté appelé l'effet Dunning-Kruger. Les gens incompétents dans un domaine surestiment leur compétence parce qu'ils manquent précisément de la compétence nécessaire pour évaluer leur incompétence.
L'IA crée une version sophistiquée de cet effet. Quand Copilot génère du code qui fonctionne, vous vous sentez productif. Vous avez livré la feature. Le sprint est validé. Vous êtes un bon développeur.
Mais êtes-vous vraiment devenu meilleur ? Ou est-ce que Copilot est devenu meilleur et que vous prenez le crédit ?
La différence devient claire quand vous devez résoudre un problème que l'IA ne peut pas gérer. Un bug complexe qui nécessite de comprendre trois couches d'abstraction simultanément. Un problème de performance qui demande de savoir exactement ce que fait chaque ligne de code. Une architecture à concevoir où les décisions de design auront des répercussions pendant des années.
Dans ces moments, la dette de compréhension se révèle. Vous réalisez que vous avez passé six mois à valider du code généré par l'IA sans jamais vraiment exercer vos muscles de réflexion profonde sur les problèmes.
C'est comme utiliser une calculatrice pour toutes vos opérations mathématiques. Vous êtes plus rapide, certes. Mais si on vous demande de calculer 17 × 23 mentalement, vous avez perdu cette capacité. Sauf qu'en développement, cette "capacité mentale" n'est pas juste un exercice intellectuel. C'est votre métier.
Avant l'IA, devenir un bon développeur suivait une courbe prévisible. Vous commenciez par des bugs simples. Vous galérez avec des erreurs de syntaxe. Vous appreniez à lire des stack traces. Progressivement, vous montiez en compétence. Chaque erreur vous enseignait quelque chose.
Maintenant, un junior peut utiliser ChatGPT pour générer une API REST complète en TypeScript avec authentification JWT et validation Zod. Sans comprendre les middlewares. Sans savoir ce qu'est un token Bearer. Sans avoir jamais debuggé une erreur CORS.
Le code fonctionne. Le junior se sent compétent. Il a "livré la feature". Mais il n'a jamais traversé les étapes fondamentales d'apprentissage que cette feature aurait dû apporter.
Et c'est là que ça devient problématique : comment un junior devient-il senior s'il n'a jamais vraiment souffert avec les problèmes que les seniors savent résoudre ?
Les développeurs seniors ne sont pas juste des gens qui connaissent plus de syntaxe. Ce sont des gens qui ont développé une intuition sur où les problèmes se cachent. Cette intuition vient de l'expérience. De l'échec. D'avoir passé des heures à debugger un problème avant de réaliser que le bug était dans leur compréhension du problème lui-même.
Si l'IA court-circuite cette expérience, comment construisez-vous cette intuition ?
L'IA rend des choses complexes soudainement accessibles. Vous pouvez maintenant implémenter un algorithme de machine learning sans comprendre les maths derrière. Vous pouvez créer une interface 3D avec Three.js sans savoir ce qu'est une matrice de transformation. Vous pouvez déployer un service sur Kubernetes sans comprendre ce qu'est un pod.
C'est démocratique. C'est libérateur. Et c'est aussi terrifiant.
Parce que ces technologies sont complexes pour une raison. Kubernetes n'est pas compliqué par sadisme, il résout des problèmes difficiles de distribution, de résilience, de scaling. Si vous ne comprenez pas ces problèmes, vous ne pouvez pas prendre de bonnes décisions architecturales. Vous allez utiliser Kubernetes parce que "c'est moderne", alors qu'un simple Heroku aurait suffi. Ou pire, vous allez mal configurer votre cluster et créer des problèmes que vous ne saurez même pas détecter.
On se retrouve avec des systèmes de plus en plus complexes construits par des gens qui ne comprennent pas cette complexité. Et quand ces systèmes cassent, parce qu'ils finiront par casser, personne ne sait vraiment comment les réparer.
Alors, qu'est-ce qui fait la valeur d'un développeur dans ce nouveau monde ?
Ce n'est plus la vitesse de frappe. Ce n'est plus la connaissance syntaxique, l'IA connaît la syntaxe de tous les langages. Ce n'est même plus la capacité à résoudre des problèmes algorithmiques classiques, l'IA peut générer un quicksort plus vite que vous.
La valeur se déplace vers des compétences plus subtiles.
La capacité à poser les bonnes questions. Quand l'IA génère du code, est-ce qu'elle a vraiment compris votre problème ? Est-ce qu'elle a fait les bons trade-offs ? Un développeur senior sait identifier quand une solution "qui fonctionne" n'est pas la bonne solution.
La compréhension du contexte métier. L'IA ne sait pas que votre système de facturation doit être audit-compliant. Elle ne sait pas que cette feature sera utilisée par un million d'utilisateurs simultanés. Elle ne sait pas que le client veut vraiment X mais a demandé Y parce qu'il ne connaît pas les possibilités techniques.
L'architecture et le design de systèmes. L'IA peut générer une fonction, peut-être même une classe. Mais concevoir l'architecture d'un système distribué qui évoluera sur 5 ans ? Ça demande une vision que l'IA n'a pas. Ça demande d'avoir fait des erreurs architecturales et d'avoir appris à les éviter.
Le debugging profond. Quand un problème nécessite de comprendre l'interaction entre le garbage collector, la boucle d'événements, et un driver de base de données, l'IA peut suggérer des pistes mais c'est vous qui devez suivre le fil. Et pour suivre ce fil, vous devez avoir une compréhension profonde de toutes ces couches.
Nous sommes à un point de bifurcation dans notre métier. Deux chemins s'ouvrent.
Le premier chemin : embrasser totalement l'IA. Devenir des "orchestrateurs de code généré". Mesurer notre valeur à la quantité de features livrées, pas à la compréhension du code. Maximiser la productivité court terme, accepter la dette de compréhension long terme.
Le second chemin : utiliser l'IA comme un outil d'accélération, mais maintenir une pratique délibérée de compréhension profonde. Lire le code que l'IA génère non pas pour le valider superficiellement, mais pour vraiment le comprendre. Parfois refuser les suggestions de l'IA et coder à la main pour forcer notre cerveau à explorer l'espace du problème.
Le premier chemin est plus facile. Plus rapide. Plus satisfaisant à court terme. Le second est plus difficile. Plus lent. Mais c'est celui qui construit de vraies compétences.
Et voici ce que peu de gens réalisent. Le choix n'est pas binaire. Vous ne choisissez pas une fois pour toutes. Vous choisissez tous les jours, à chaque fois que Copilot vous suggère du code. Est-ce que vous prenez deux minutes pour comprendre cette suggestion ? Ou est-ce que vous appuyez sur Tab machinalement ?
Ces micro-décisions s'accumulent. Elles forment, sur des mois et des années, le développeur que vous devenez.
Dans dix ans, il y aura des développeurs qui auront passé une décennie à orchestrer du code qu'ils ne comprennent pas vraiment. Et il y aura des développeurs qui auront utilisé l'IA pour explorer plus profondément, plus rapidement, construisant une expertise qu'aucune IA ne peut remplacer.
La vraie question n'est pas "l'IA va-t-elle remplacer les développeurs ?". C'est "quel genre de développeur allez-vous choisir d'être dans un monde où l'IA existe ?".
Et cette question, personne d'autre que vous ne peut y répondre.
Si ce contenu vous a plus les ami(e)s codeurs, n’hésitez pas à partager sur vos réseaux et à vous abonner a la newsletter afin d’être averti des prochains billets !