Dans un monde technologique en constante évolution, être développeur signifie également avoir un métier qui évolue sans cesse. En particulier depuis ces dernières années avec l’arrivée en force de l’IA, les façons de faire d’un développeur en 2026 sont bien différentes qu’elles ne l’étaient ne serait-ce qu’il y a quelques années à peine.
source: https://programmerhumor.io/ai-memes/look-at-me-im-the-developer-now-1dv5
Petit tour d’horizon et réflexion personnelle sur ce vaste sujet, on est parti !
Le coding traditionnel: seul face au code
Le coding traditionnel, c’est un peu comme apprendre à faire du vélo sans les petites roulettes. Au début, c’est difficile, tu tombes, tu te relèves, et puis un jour, ça roule tout seul. C’est cette approche qu’on est beaucoup à avoir connue (ou presque) : toi, ton éditeur de code, la documentation, et beaucoup, beaucoup de café.
L'autonomie complète du développeur
Quand tu codes de manière traditionnelle, tu es maître à bord. Chaque ligne de code, c’est toi qui la penses, qui la tapes, qui la debugges. Tu pars d’un problème, tu réfléchis à l’architecture, tu choisis tes structures de données, tu implémentes la logique. Bref, c’est ton cerveau qui fait tout le boulot.
Et ce “tout faire soi-même”, ça a quelque chose de profondément satisfaisant. Quand ton code fonctionne enfin après 3 heures de debugging, cette petite montée de dopamine, c’est incomparable. Tu sais exactement pourquoi ça marche, parce que c’est toi qui as construit chaque brique.
Le truc, c’est que cette autonomie vient avec une courbe d’apprentissage assez raide. Tu dois comprendre les concepts fondamentaux : les boucles, les conditions, les fonctions, les classes, la gestion de la mémoire, les patterns de conception… Il n’y a pas de raccourci. Pas de copilote pour te suggérer la suite. Pas d’IA pour générer un boilerplate. C’est toi, face à ton clavier.
Forces: maîtrise profonde, apprentissage solide
Et justement, c’est là que réside la vraie force du coding traditionnel : l’apprentissage en profondeur.
Quand tu dois implémenter une fonctionnalité from scratch, tu es obligé de comprendre comment ça fonctionne vraiment. Tu veux trier une liste ? Tu vas apprendre la différence entre un bubble sort et un quicksort. Tu dois gérer de l’asynchrone ? Tu vas comprendre les callbacks, les promises, async/await. Pas juste copier-coller un snippet, mais vraiment comprendre ce qui se passe sous le capot.
Cette maîtrise profonde, elle devient ta boîte à outils mentale. Face à un nouveau problème, tu sais instinctivement quelle approche utiliser parce que tu as construit cette intuition problème après problème. C’est un peu comme un chef cuisinier qui goûte un plat et sait exactement comment rectifier l’assaissonement - ça vient avec l’expérience, pas avec la recette.
Et puis, il y a cette satisfaction pure de résoudre des problèmes complexes. Genre quand tu debug pendant des heures un bug vicieux, que tu deviens à moitié zinzin, et que tout s’illumine d’un coup. Cette capacité de résolution de problèmes, tu ne la développes vraiment qu’en te battant avec du code récalcitrant.
Le coding traditionnel, c’est aussi apprendre à lire de la documentation, ou a farfouiller Stack Overflow quand tu es vraiment désespéré. Tu développes cette compétence de chercher, filtrer, comprendre l’info pertinente. Et ça, c’est une compétence qui te servira toute ta vie.
Limites: courbes d'apprentissage, vitesse
Bon, soyons honnêtes : le coding traditionnel, c’est chronophage. Vraiment.
Tu veux implémenter un système d’authentification ? Prépare-toi à passer plusieurs jours (voire semaines si tu débutes) à comprendre OAuth, JWT, le stockage sécurisé des tokens, la gestion des refresh tokens, les cas d’erreur… Et on ne parle même pas encore du frontend.
Cette courbe d’apprentissage raide, elle peut être décourageante, surtout quand tu débutes. Tu vois des devs expérimentés sortir du code propre en quelques heures, et toi tu galères sur un truc qui semble basique. C’est normal, mais ça peut taper sur le moral.
Et puis, il y a la vitesse de développement. Objectivement, coder from scratch, c’est lent. Tu dois penser à tout, gérer tous les edge cases, écrire tous les tests. Un composant UI qui te prendrait 5 minutes avec un template IA peut facilement te prendre 2 heures en partant de zéro.
Il y a aussi le risque de réinventer la roue. Tu passes du temps à créer une fonction qui existe déjà dans une librairie bien testée et maintenue. Ou pire, tu implémente une solution qui marche, mais qui n’est pas optimale parce que tu ne connaissais pas le pattern standard pour ce type de problème. Très frustrant.
Coder avec l'asssitance IA: l'augmentation cognitive
Bon, maintenant qu’on a parlé du coding old school, passons à l’ère moderne : coder avec l’assistance de l’IA. Et non, je ne parle pas encore du vibe coding (patience, on y arrive).
L'IA comme copilote
L’idée, c’est simple : tu commences à écrire du code, et l’IA te propose la suite. Un peu comme l’autocomplétion de ton téléphone, mais en beaucoup, beaucoup plus smart.
Tu tapes function calculateTax, et hop, l’IA te suggère les paramètres, le corps de la fonction, voire même les cas d’erreur. Tu écris un commentaire et l’IA génère le code correspondant. C’est un peu comme avoir un collègue expérimenté qui regarde par-dessus ton épaule et te souffle des suggestions.
Dans Claude Code, par exemple, il y a la formidable fonctionnalité “Plan mode”: tu promptes, et l’IA n’exécute pas directement dans ton code, elle te propose un plan d’action. Tu peux le relire en détails, le modifier, le refuser ou l’accepter. Vraiment très cool.
En fait, tu gardes le contrôle. L’IA propose, mais c’est toi qui disposes et qui reste aux commandes, l’IA est juste là pour accélérer le process.
Et contrairement au coding traditionnel où tu dois chercher sur Stack Overflow ou dans la doc, l’IA te donne la réponse dans ton contexte. Elle comprend ton code existant, ton style, tes conventions. Les suggestions sont adaptées à ton projet, pas des snippets génériques.
Un équilibre entre contrôle et aide
Ce qui est intéressant avec l’assistance IA, c’est qu’elle crée un nouvel équilibre entre autonomie et aide.
D’un côté, tu dois quand même comprendre ce que tu fais. L’IA te suggère du code, mais c’est toi qui décide si ça fait du sens. Tu dois être capable de lire et comprendre les suggestions, de repérer les erreurs potentielles, de savoir si l’approche proposée est la bonne. En gros, tu ne peux pas être un total débutant et te reposer aveuglément sur l’IA.
D’un autre côté, l’IA te fait gagner un temps fou que tu peux utiliser pour te concentrer sur d’autres aspects comme l’architecture, la logique métier, les décisions de design, etc. Et quand on fait tout tout seul, du temps mental, on en a besoin.
L’assistance IA, c’est aussi un excellent outil d’apprentissage. Tu vois comment l’IA résout un problème, et tu apprends de nouvelles approches, de nouveaux patterns. C’est comme avoir un mentor/collègue/apprenti, en fonction de ton expertise, qui te montre des façons de faire différentes. Parfois, l’IA te propose une solution plus élégante que celle à laquelle tu pensais, et tu te dis “ah ouais, pas bête”.
Les pièges
On ne va pas se mentir, d’un autre côté, l’assistance IA peut vite rendre paresseux.
C’est tentant, d’accepter systématiquement toutes les suggestions sans les comprendre. Le problème, c’est qu’on ne progresse pas vraiment, qu’on devient dépendant de l’outil sans développer notre propre expertise, et qu’on perd un peu le contrôle de notre projet.
Il y a aussi le risque de la sur-confiance. L’IA se trompe, parfois. Elle peut te suggérer du code qui compile mais qui a des bugs subtils, ou qui n’est pas optimal pour ton cas d’usage.
Et puis, l’IA ne comprend pas toujours ton contexte métier spécifique. Elle peut générer du code techniquement correct mais qui ne correspond pas à tes besoins business. C’est à toi de faire le tri et d’adapter.
Le vibe coding: déléguer l'intention
Bon, on arrive au truc vraiment nouveau, celui qui fait débat: le vibe coding. Alors déjà, c’est quoi exactement ? Il semble que le premier à avoir mis un mot sur cette nouvelle pratique soit Andrej Karpathy, sur X.
Andrej Kerpathy sur X à propos du vibe coding
De l'idée au code par la conversation
Concrètement, tu ouvres une conversation avec Claude, ChatGPT, ou n’importe quelle IA générative, et tu lui dis un truc du genre : “Crée-moi un système de gestion d’utilisateurs avec authentification JWT, inscription, connexion, et récupération de mot de passe oublié”. Et l’IA te pond le code. Tout le code. Backend, frontend, tests, tout.
C’est un peu comme si tu passais d’artisan qui fabrique chaque pièce à la main, à architecte qui dessine les plans et supervise la construction.
Et ce qui est dingue avec le vibe coding, c’est la vitesse à laquelle tu passes de l’idée au code fonctionnel.
Tu as une vision dans ta tête. Plutôt que de passer des heures à implémenter, tu la décris. “Je veux une app de todo list avec des catégories, la possibilité de définir des deadlines, et des rappels push”. Et hop, 2 minutes plus tard, tu as une base de code.
Le développeur comme architecte/chef d'orchestre
Avec le vibe coding, ton rôle change complètement. Tu n’es plus le développeur au sens traditionnel, tu deviens plutôt un chef de projet technique.
Ton job, c’est de :
- Définir la vision : Qu'est-ce qu'on veut construire ? Pour qui ? Avec quelles contraintes ?
- Guider l'implémentation : Orienter l'IA vers les bonnes solutions techniques, les bons frameworks, les bons patterns
- Valider le résultat : Vérifier que le code généré fait ce qu'il faut, qu'il est propre, qu'il respecte les bonnes pratiques
- Intégrer et orchestrer : Assembler les différents morceaux générés par l'IA en un tout cohérent
Cette approche demande des compétences différentes du coding traditionnel. Mais alors, quelles sont-elles ?
Savoir poser les bonnes questions. Le vibe coding, c’est l’art du prompt. Si tu demandes “fais-moi une app”, tu vas obtenir quelque chose de générique et probablement pas très utile. Mais si tu demandes “crée une app de suivi de dépenses avec catégorisation automatique par IA, synchronisation multi-devices, et export en CSV”, là, tu obtiens quelque chose d’exploitable. C’est un peu comme commander au restaurant. Si tu dis juste “j’ai faim”, le serveur va galérer. Mais si tu dis “je veux le risotto aux champignons, sans fromage, avec un supplément de truffe”, tu obtiens exactement ce que tu veux.
Savoir évaluer du code rapidement. L’IA te génère 500 lignes de code. Tu dois être capable de les parcourir, comprendre l’architecture, repérer les points faibles potentiels. Tu n’as pas besoin de comprendre chaque ligne en détail, mais tu dois avoir une vision d’ensemble et savoir où regarder si quelque chose cloche.
Comprendre les concepts sans forcément maîtriser l’implémentation. Tu dois savoir ce qu’est un JWT, pourquoi c’est important, quand l’utiliser. Mais tu n’as pas forcément besoin de savoir implémenter la génération et la validation de tokens from scratch. L’IA s’en charge.
Savoir itérer et affiner. Le premier jet de l’IA est rarement parfait. Tu dois savoir identifier ce qui ne va pas et guider l’IA vers une meilleure solution. “Cette fonction est trop complexe, peux-tu la découper ?”, “Il manque la gestion d’erreur ici”, “Cette requête SQL n’est pas optimisée”.
Trop beau pour être vrai ?
Mais alors, ça semble plutôt cool, cette histoire de vibe-coding. Pourquoi ça fait autant débat ?
Le truc, c’est que le vibe-coding rend le développement accessible a tout le monde. Mais vraiment, à tout le monde, même à tonton gégé qui ne sait absolument pas lire une ligne de code.
Certains trouvent ça formidable. D’autres soulèvent quelques questions:
- Sécurité: quand tu vibes une app complète en 10 minutes, est-ce que tu sais vraiment ce qu'il y a dedans ? Le problème, ce n'est pas forcement que l'IA ne sait pas faire. Mais c'est que toi, tu peux ne pas prendre le temps de vérifier et/ou de comprendre. Et en sécurité, les bugs ne sont pas juste "un peu gênants". Ils peuvent coûter très cher.
- Maintenance et scalabilité: du code généré par IA, ça peut être impressionnant, mais ça peut aussi être redondant, mal structuré, peu cohérent entre les différentes parties et difficile à faire évoluer. Quand tu es seul sur un petit projet, ça peut passer. Mais dans une équipe ? Avec 3 ans d'évolution produit ? Avec des millieurs d'utilisateurs (on te le souhaite) ? La maintenance et la scabilité, ce n'est pas juste "est-ce que ça compile", c'est "est-ce que l'architecture supporte la croissance, les nouvelles features, les contraintes business" ?
- Debug: en coding traditionnel, tu sais globalement pourquoi tu as écrit chaque partie. Même si c’était il y a 6 mois, tu retrouves ton raisonnement (même si parfois, tu te poses quand même de sérieuse question sur ton toi passé, on est d'accord). En vibe coding, tu peux te retrouver face à 800 lignes que tu n’as jamais vraiment “pensées”. Tu les as validées. Acceptées. Intégrées. Mais pas construites mentalement. Et debugger un système que tu ne comprends qu’à moitié, c’est une expérience… sportive.
- Perte de connaissance: C’est probablement le débat le plus philosophique. Si l’IA écrit le code à ta place, est-ce que tu perds la compétence ? Est-ce qu’on risque de former des développeurs qui savent “parler à une IA” mais pas implémenter une boucle proprement ? Certains comparent ça à la calculatrice : on ne sait plus faire certaines divisions à la main. D’autres disent que ça libère du cerveau pour des problèmes plus intéressants. La question reste ouverte.
Conclusion: vers une pratique hybride ?
Alors, on fait quoi avec tout ça ? On jette nos vieux réflexes de dev à la poubelle pour parler uniquement en prompts ? Ou on ignore l’IA en mode “c’était mieux avant” ?
Peut être qu’on peut trouver un entre deux.
Le paradigme de la pizza
En promenant mes compagnons à 4 pattes et mon fils l’autre jour, je cogitais sur le sujet. Et m’est venue l’analogie suivante.
Image que tu veux faire une pizza (promis, ça a un rapport).
T’as plusieurs options.
Tu peux décider de faire toi-même la pâte from scratch, en cultivant ton blé et en faisant ta propre levure. Idem pour la sauce tomate: tu les plantes toi-mêmes, tu les récoltes, tu en fais ta sauce. Et bien sûr, on n’oublie pas la mozza: t’achètes une vache, tu trais son lait, bref t’as compris. Bon, un peu overkill, peut-être ? Si tu te lances dans un projet en 2026, et que tu refuses d’utiliser tout outil IA, c’est un peu la vibe que tu renvoies, navrée de te l’apprendre.
Bon sinon, tu peux commander ta pizza au restaurant du coin: tu choisis celle que tu souhaites sur la carte, et ta-dam, la voilà toute prête toute chaude devant ta porte ! Un petit manque de satisfaction ? de contrôle sur les ingrédients, leur qualité ? Aucune idée de comment la refaire ? Bienvenue dans le monde du vibe-coding.
Et sinon, tu peux aussi faire ta pizza maison, sans overkill le processus: tu achètes la pâte, sauce tomate et mozza, tu assaisonnes comme tu le souhaites, tu rajoutes ce que tu veux, et tu gères la cuisson. Bon compromis ? J’en ai bien l’impression.
L’assistance au coding avec l’IA, ça me semble être le sweet spot du moment. Vitesse d’exécution incomparable au développement old school, mais on garde quand même le contrôle sur son projet.
Bien sûr, il y a des parties qu’on va vouloir développer soi-même sans IA pour être 100% sûr de ce qu’on implémente. Et d’autres qu’on va déléguer à l’IA en vibe-codant un prompt histoire d’avancer plus vite.
Finalement, être développeur moderne, c’est devenir stratège: choisir ses outils en fonction du contexte, du niveau de risque, du temps disponible et de l’objectif final. Et toi, en tant que bon stratège, ton super-pouvoir ce n’est pas l’outil lui-même. C’est ta capacité à savoir quand, comment, et pourquoi l’utiliser. Et ça, IA ou pas, ça reste profondément humain.
Laisse-moi un commentaire pour me donner ton avis, même si tu n’es pas du tout d’accord avec moi - parce que ça aussi, c’est typiquement humain, et tant que c’est respectueux, on aime.
A la prochaine !
Commentaires