Tu connais forcément le sketch des Inconnus.
Le mauvais chasseur, il voit un truc qui bouge, il tire. Le bon chasseur, il voit un truc qui bouge, il tire… mais c’est un bon chasseur.
En 2026, on a exactement la même discussion dans la tech. Sauf qu’on a remplacé le fusil par l’IA Agentique : Cursor, Claude Code, GitHub Copilot, et toute la galaxie d’agents qui codent avec nous.
D’un côté, on a les Puristes. Ceux qui pensent que si on n’a pas écrit chaque caractère à la main, dans la douleur, on triche. De l’autre, celles et ceux qui ont adopté ces outils et qui laissent des agents gérer une partie du travail.
Alors, c’est quoi un “bon” développeur aujourd’hui ? Celui qui refuse l’aide par “éthique” ou celle qui délègue intelligemment ?
Spoiler : c’est ni l’un ni l’autre. La vraie question, c’est l’approche.
Stop au Gatekeeping
Je vais être cash : je déteste profondément le gatekeeping dans notre métier.
Il y a cette idée toxique qui circule encore : pour que mon code soit “valide”, il faut qu’il ait nécessité du sang, de la sueur et des larmes. Si je n’ai pas galéré trois heures sur une erreur de syntaxe qu’une IA aurait réglée en 3 secondes, je n’ai pas “mérité” mon titre de développeur.
C’est n’importe quoi.
Et les chiffres le prouvent : 85 % des développeurs utilisent déjà régulièrement des outils d’IA dans leur travail selon une enquête JetBrains de 2024. Ça veut dire que les puristes qui refusent catégoriquement ces outils représentent désormais une minorité bruyante d’environ 15 %.
Ceux qui disent que l’IA c’est de la triche veulent surtout protéger leur ego. Le plaisir intellectuel de résoudre un casse-tête complexe à la main, je le comprends. Je le respecte même. Mais c’est un plaisir individuel. C’est un hobby.
Dans la réalité professionnelle, le code n’est jamais une fin en soi. La souffrance n’est pas une métrique de compétence. Passer 4 heures à déboguer manuellement quelque chose qu’un outil pourrait identifier en 30 secondes, ce n’est pas de la rigueur, c’est de l’inefficacité romantique.
Et si quelqu’un cherche à nous culpabiliser parce qu’on utilise des outils pour aller plus vite, posons-nous la question : qui ça arrange vraiment ?
Le produit est le but
Personne n’utilise mon application parce que mon architecture est pure. Les gens utilisent mon app parce qu’elle résout un problème ou qu’elle les divertit.
Le code n’est qu’un moyen. Le produit, c’est le but.
Si utiliser un agent dans mon terminal (comme Claude Code) ou dans mon éditeur (Cursor) me permet de passer de l’idée à la solution en 15 minutes au lieu de 4 heures, alors c’est la seule métrique qui compte pour l’utilisateur final. Il s’en fiche complètement de savoir si j’ai écrit chaque ligne à la main ou si j’ai piloté un agent.
Refuser ces outils pour rester un “vrai dev”, c’est comme un charpentier qui refuserait la visseuse électrique par nostalgie du tournevis manuel. C’est romantique, mais c’est inefficace. Et surtout, ça ne change rien à la qualité de la charpente si l’artisan maîtrise son métier.
L’utilisateur final ne se soucie pas de mes outils. Il se soucie du résultat. Est-ce que ça marche ? Est-ce que c’est rapide ? Est-ce que ça résout son problème ?
Tout le reste, c’est du nombrilisme technique.
Justement, l’IA demande plus de compétences, pas moins
Maintenant, attention. Je ne suis pas en train de dire que l’IA est un passe-droit pour coder n’importe comment.
Au contraire : l’IA exige une rigueur architecturale encore plus grande.
Pourquoi ? Parce que l’IA est un amplificateur. Elle magnifie ce qui existe déjà. Si je lui donne une codebase spaghetti, elle va produire plus de spaghetti, plus vite. Si je lui donne une architecture propre avec des responsabilités claires, elle devient un assistant chirurgical redoutablement efficace.
Le principe est simple : Garbage In, Garbage Out.
Par exemple : si je demande à une IA de créer un système de notifications dans une codebase où tout est déjà fortement couplé, elle va me générer un énième couplage. Si je lui demande la même chose dans une codebase bien structurée avec des responsabilités claires, elle me proposera une solution propre qui s’intègre parfaitement sans casser l’existant.
Un développeur qui ne maîtrise pas les fondamentaux (SOLID, Clean Code, séparation des responsabilités) et qui se repose aveuglément sur l’IA va créer une dette technique monstrueuse. L’IA va générer du code qui “fonctionne”, mais ce code sera probablement couplé, difficile à tester, et impossible à maintenir.
À l’inverse, une développeuse qui connaît ses principes d’architecture va utiliser l’IA comme un multiplicateur de force. Elle sait exactement ce qu’elle veut, elle structure sa pensée, et elle demande à l’IA de produire les briques de code qui respectent ses contraintes architecturales.
Les fondations essentielles restent non négociables :
- Principes SOLID : Une IA ne peut pas décider pour moi si une classe a trop de responsabilités. C’est mon job d’architecte.
- Clean Code : Nommage clair, fonctions courtes, responsabilités explicites. L’IA peut me proposer des noms, mais c’est moi qui valide la cohérence.
- Architecture claire : L’IA génère du code dans le contexte que je lui fournis. Si mon contexte est pourri, son code le sera aussi.
Ces principes ne deviennent pas obsolètes avec l’IA. Ils deviennent encore plus critiques. Parce qu’ils guident l’IA. Ils lui donnent les rails sur lesquels rouler.
Et cette rigueur ne s’arrête pas à l’architecture. Elle se prolonge dans deux pratiques essentielles : les tests et la code review.
L’IA accélère, les tests et la review sécurisent
L’IA peut générer du code très rapidement. Mais cette vitesse doit être contrebalancée par une vigilance accrue.
Les tests avec l’IA
L’IA est excellente pour générer des tests unitaires ou d’intégration. Elle peut produire en quelques secondes des dizaines de cas de test que j’aurais mis une heure à écrire manuellement.
Mais attention : c’est à moi de vérifier que ces tests testent les bons comportements.
Un test qui passe mais qui ne valide pas le bon invariant métier ne sert à rien. Pire, il donne une fausse impression de sécurité.
Les tests deviennent donc encore plus critiques dans un environnement assisté par IA. Ils sont mon filet de sécurité pour valider que le code généré fait ce que je veux qu’il fasse, pas juste ce que l’IA pense que je veux qu’il fasse.
Une bonne développeuse utilise l’IA pour écrire les tests plus vite. Pas pour les éviter.
La Code Review
Le code généré par l’IA doit être relu avec encore plus d’attention que du code écrit manuellement.
Pourquoi ? Parce que l’étude GitClear de 2024 a révélé un risque réel : une augmentation du copier-coller de code et une diminution du refactoring. Quand on laisse l’IA générer des blocs de code sans les relire attentivement, on accumule de la duplication, des patterns inappropriés, et de la dette technique.
La code review devient l’étape cruciale où je valide l’intention vs le résultat. C’est là que je corrige les hallucinations de l’IA, les mauvais patterns, les couplages indésirables.
C’est aussi là que j’apprends. En relisant le code généré, j’identifie les patterns que l’IA utilise, je comprends ses forces et ses faiblesses, et j’affine ma manière de la piloter.
Le message est clair : l’IA n’est pas un passe-droit pour skipper les bonnes pratiques. C’est un accélérateur qui rend ces pratiques encore plus nécessaires.
Ce n’est pas l’outil, c’est l’approche
Finalement, l’opposition “Dev avec IA” vs “Dev sans IA” est un faux débat.
Coder avec l’IA, ce n’est pas mal coder. Je peux produire du code de qualité exceptionnelle avec l’IA si je maîtrise mes fondamentaux et que je reste rigoureux sur la review.
De la même manière, je peux produire du code absolument dégueulasse à la main. On l’a tous vu. On l’a tous fait à un moment ou un autre.
L’IA est neutre. Elle n’est ni bonne ni mauvaise. C’est un outil. Ce qui compte, c’est l’intention et la rigueur de la personne qui l’utilise.
Prenons deux scénarios concrets :
Un développeur médiocre, qui ne comprend pas vraiment l’architecture, va demander à l’IA de générer une fonction de paiement. Il va copier-coller le résultat sans le relire, sans vérifier les edge cases, sans tester. Le code “fonctionne” en apparence, mais il est fragile, couplé, et introduit des risques de sécurité.
Une développeuse talentueuse va utiliser l’IA différemment. Elle va d’abord concevoir l’architecture de son système de paiement, définir les interfaces, les contraintes de sécurité. Ensuite, elle va demander à l’IA de générer l’implémentation d’une partie spécifique, la relire ligne par ligne, la tester, et l’adapter si nécessaire.
La différence ne se fait pas sur l’outil. Elle se fait sur la maîtrise et l’approche.
Alors, c’est quoi un bon dev en 2026 ?
Après tout ce qu’on vient de voir, la définition devient beaucoup plus claire.
Le Mauvais Dev
- Subit le code de l’IA : Copier-coller aveugle sans comprendre ce qui est généré.
- Ne connaît pas ses fondations : Pas de maîtrise de l’architecture, donc incapable de guider l’agent.
- Code pour le code : Pense que la complexité technique est une preuve de compétence.
- Juge au lieu de livrer : Passe son temps à critiquer ceux qui utilisent des “raccourcis” ou les outils modernes, plutôt qu’à livrer de la valeur. Confond ego et expertise.
- A peur de casser : Paralysé par la perfection, ne ship jamais rien.
La Bonne Dev
- Maîtrise ses fondations : SOLID, Clean Code, patterns d’architecture. Ces principes lui permettent de piloter l’IA avec précision.
- Utilise l’IA pour virer la friction : Boilerplate, génération de tests, documentation, refactoring répétitif. La plupart de ce qui est automatisable, elle l’automatise.
- Ship. Souvent. Beaucoup. : Livre de la valeur régulièrement plutôt que de chercher la perfection théorique.
- Sait adapter son niveau de qualité : Code propre et testé pour la prod, quick & dirty pour prototyper une idée à 2h du mat’.
- Teste et review le code généré : Ne fait jamais confiance aveuglément. Valide, corrige, s’approprie.
- Expérimente, se trompe, répare, recommence : La curiosité et l’apprentissage continu sont ses super-pouvoirs.
La différence ? Ce n’est pas une question d’outil. C’est une question d’état d’esprit, de rigueur, et de focus sur la valeur livrée.
Conclusion
L’IA ne remplace pas le développeur. Elle ne remplacera jamais le développeur.
Elle remplace la peur de la page blanche. Elle remplace la fatigue du boilerplate. Elle remplace les heures perdues sur des problèmes déjà résolus mille fois.
Être un bon dev en 2026, c’est avoir cette curiosité insatiable, cette rigueur sur les fondamentaux, et cette envie irrépressible de construire des trucs qui servent à quelque chose.
Que je le fasse en tapant tout à la main ou en pilotant un agent IA, personne ne s’en soucie vraiment.
Ce qui compte, c’est ce qui s’affiche sur l’écran de l’utilisateur à la fin. Et la rigueur sur l’architecture, les tests, et la review reste absolument non négociable.
Alors, j’arrête de complexer sur la méthode.
J’ouvre mon IDE.
Je soigne mon architecture.
Et je vais casser quelque chose en prod (ou presque).
Tant que ça résout un problème réel pour mes utilisateurs.
Sources :
- JetBrains Developer Ecosystem 2024 : 85% des développeurs utilisent régulièrement l’IA
- Étude GitClear 2024 : Impact de l’IA sur la qualité du code et risques de dette technique
- GitHub Developer Survey 2024 : 92% des développeurs US constatent un gain de productivité avec les outils d’IA
*Cet article a été relu et amélioré avec l’assistance de Claude Sonnet 4.5 (ironique non ?).
Loading comments...