Depuis dix ans que je développe, j’ai vu passer des dizaines de “révolutions qui allaient tuer le métier”. Les frameworks low-code, WordPress, Webflow, les templates Bootstrap, les no-code builders. Aucun n’a supprimé le besoin de développeurs. Ils ont tous déplacé les besoins.
L’IA générative, c’est différent. Pas parce qu’elle va “remplacer” les développeurs — cette prédiction est paresseuse et inexacte — mais parce qu’elle change fondamentalement ce qui a de la valeur dans notre métier. Et si on ne comprend pas ce changement, on risque de se retrouver du mauvais côté de la courbe.
Je vais vous dire ce que j’observe depuis que j’utilise Claude Code et Cursor au quotidien dans mes projets, notamment pour construire deux SaaS (Oranexa et Nomisora) en solo.
Ce qui a vraiment changé
La vélocité — et ses pièges
La chose la plus immédiatement frappante quand on commence à utiliser ces outils sérieusement : on produit beaucoup plus vite. Pas 10% plus vite. Parfois deux ou trois fois plus vite sur certaines tâches.
Un composant de tableau de bord avec filtres, pagination et tri ? Avant, deux heures. Avec Claude Code en mode PLAN → BUILD, une heure, dont la moitié passée à valider ce qui sort plutôt qu’à écrire du code.
Mais voilà le piège que j’ai failli ne pas voir : la vélocité est une amplification, pas une amélioration autonome. L’IA produit vite ce qu’on lui demande. Si on lui demande la mauvaise chose, elle la produit vite et bien, et on perd autant de temps à corriger qu’on en a “gagné” à générer.
J’ai une règle maintenant : avant de donner quoi que ce soit à l’IA, je dois pouvoir énoncer le problème en une phrase précise. Si je ne peux pas, ce n’est pas l’IA qui doit travailler, c’est moi.
Le profil des tâches qui changent
Il y a un an, une bonne partie de mes journées consistait à écrire des fonctions CRUD, des composants UI standard, des validations de formulaires, de la glue entre APIs. Des tâches techniques nécessaires mais pas particulièrement intellectuellement stimulantes.
Ces tâches-là, l’IA les absorbe. Pas parfaitement — il faut toujours relire, ajuster, parfois corriger des erreurs subtiles — mais suffisamment bien pour que je ne passe plus trois heures à les écrire from scratch.
Ce qui prend maintenant une plus grande part de mon temps : comprendre exactement ce que le client veut (pas ce qu’il dit), choisir l’architecture qui va tenir dans dix-huit mois quand les besoins auront évolué, valider que ce que l’IA produit est correct et cohérent avec le reste du système, anticiper les problèmes de performance ou de sécurité que l’IA ne signale pas spontanément.
Ce n’est pas une liste de tâches “nobles” que j’essaie de valoriser artificiellement. C’est simplement ce qui reste après que l’IA a pris ce qu’elle peut prendre.
La séniorité révélée
C’est peut-être l’observation la plus importante, et la plus inconfortable : l’IA amplifie les bons développeurs et expose les autres.
Un développeur senior qui utilise Claude Code gagne un multiplicateur sur sa capacité de production. Il sait quoi demander, comment structurer le contexte, comment valider ce qui sort, quand ne pas faire confiance à l’output. L’outil devient une extension de son jugement.
Un développeur moins expérimenté qui utilise les mêmes outils peut produire beaucoup de code. Mais il ne sait pas distinguer le bon code du code qui semble correct. Il ne détecte pas l’architecture fragile déguisée en solution élégante. Il ne voit pas la faille de sécurité dans la validation d’entrée générée. Il livre vite, mais il accumule une dette technique invisible.
La séniorité ne disparaît pas avec l’IA. Elle devient plus visible, pas moins.
Ce que l’IA ne peut pas faire
Le contexte métier — vraiment
L’IA peut lire votre documentation, vos commentaires, vos noms de variables. Elle ne comprend pas le contexte implicite de votre secteur, les contraintes non-écrites de votre organisation, les décisions que vous avez prises il y a deux ans pour des raisons qui n’existent plus mais dont les conséquences existent encore.
Exemple concret sur Nomisora, mon SaaS de facturation pour thérapeutes : j’ai passé plusieurs mois à comprendre les spécificités comptables et réglementaires de ce secteur. Les thérapeutes qui font des actes remboursables versus non-remboursables, la TVA sur certaines prestations mais pas d’autres selon le statut, les obligations légales des factures pour les professions de santé réglementées.
Quand je demande à Claude Code de générer un module de facturation, il me génère quelque chose de propre et fonctionnel. Mais si je lui demandais sans contexte, il ne saurait pas qu’une facture pour un ostéopathe conventionné a des exigences différentes d’une facture pour un coach. Ce contexte-là, c’est mon travail de le connaître, de le formaliser, et de le donner à l’outil.
Le jugement architectural à long terme
L’IA optimise pour la tâche demandée. Elle ne sait pas si l’approche que vous choisissez aujourd’hui va créer un nœud de complexité insurmontable dans deux ans.
Ce n’est pas de la magie noire. C’est simplement que ce type de jugement repose sur des patterns accumulés sur des projets réels, avec des clients réels, sur des durées réelles. “Cette structure de données va poser problème quand le client voudra ajouter des multi-devises” — cette phrase suppose une expérience que l’IA n’a pas, même entraînée sur des millions de lignes de code.
La communication non-technique
L’IA peut rédiger une documentation technique impeccable. Elle ne peut pas expliquer à un client pourquoi sa feature “simple” va prendre trois semaines et pas trois heures, en des termes qui créent de la confiance plutôt que de la frustration.
Elle ne peut pas sentir dans un appel découverte que le vrai problème n’est pas celui que le client décrit. Elle ne peut pas naviguer la politique interne d’une organisation pour s’assurer que les décideurs de niveau N-2 sont alignés avant de commencer un projet.
Ce que je délègue à l’IA, ce que je ne délègue pas
Dans mon workflow quotidien, la ligne est assez claire.
Je délègue : les composants UI standards, les fonctions utilitaires, la glue entre APIs, la migration de schémas de base de données, la génération de types TypeScript à partir d’un schéma Zod, l’écriture de tests unitaires pour une logique que j’ai moi-même conçue, la rédaction de documentation technique.
Je ne délègue pas : le choix du modèle de données, les décisions d’architecture qui vont structurer le projet pendant un an, la validation finale de la logique métier critique (facturation, permissions, sécurité), la compréhension du besoin client, la priorisation des features.
La nuance importante : je ne délègue pas la conception, mais je l’utilise comme outil de réflexion. “Est-ce que cette architecture tient ?” peut être une bonne question à poser à Claude Code — pas pour obtenir la réponse définitive, mais pour identifier des angles morts que je n’aurais pas vus seul.
Un cas où l’IA m’a sauvé du temps
Sur Oranexa, mon CRM pour commerces de détail, je devais implémenter un système de gestion des emplacements d’inventaire multi-sites. La logique est non-triviale : un produit peut être dans plusieurs entrepôts, les mouvements de stock entre sites doivent être tracés, les alertes de rupture doivent être calculées par emplacement.
J’ai passé vingt minutes à spécifier le problème avec Claude Code : données d’entrée, invariants métier, cas limites. Ensuite, Claude a généré l’architecture complète — schéma de base de données, types TypeScript, hooks de logique métier, composants UI — en une heure de travail conjoint.
Sans l’outil, j’aurais passé une journée et demie sur la même tâche. La qualité du résultat était comparable. Ce gain n’est pas anodin quand on développe en solo.
Un cas où l’IA m’aurait mis dans le mur
Sur le même projet, j’ai demandé à Claude Code de générer le système de permissions multi-tenant. Il a produit quelque chose de propre, bien structuré, avec des tests. Et qui avait un bug subtil : sous certaines conditions, un utilisateur pouvait accéder aux données d’une autre organisation si son token était valide mais son organizationId n’était pas vérifié dans une route spécifique.
Ce n’était pas une erreur grossière. Le code avait l’air correct. Mais une faille de sécurité sur la séparation des données multi-tenant est précisément le type de bug qui n’apparaît pas dans les tests unitaires standards, qui passe en revue de code si le reviewer ne cherche pas activement ce type de pattern, et qui peut avoir des conséquences catastrophiques en production.
L’IA ne sait pas que la sécurité multi-tenant est un invariant absolu dans mon projet, qu’aucune route ne doit jamais retourner de données sans vérifier l’organizationId de l’organisation courante. Elle ne peut pas savoir ce qu’elle ne sait pas. Ce contexte, c’est à moi de le connaître, de le vérifier, et de l’imposer.
Le chemin des juniors : un vrai sujet
Une chose me préoccupe dans les conversations sur l’IA et le développement : ce qu’elle signifie pour les développeurs qui commencent.
Apprendre à développer en utilisant principalement l’IA pour générer du code, sans comprendre ce qui sort, c’est comme apprendre à conduire avec une voiture entièrement automatique. Ça marche dans les conditions normales. Mais quand quelque chose de non-standard arrive, vous n’avez pas les réflexes pour réagir.
Le modèle mental qui permet de valider ce que l’IA produit — de savoir si c’est correct, efficient, sécurisé, maintenable — se construit en écrivant beaucoup de code, en lisant beaucoup de code, en faisant des erreurs et en les comprenant.
Je ne dis pas que les juniors doivent éviter l’IA. Je dis que le chemin d’apprentissage doit être actif, pas passif. Utiliser l’IA pour explorer des approches alternatives, comprendre pourquoi une solution fonctionne, générer des exemples sur lesquels s’entraîner. Pas pour remplacer la phase de compréhension.
Ce que tout ça implique
Le développeur de demain n’est pas celui qui code le plus vite. Il en produit autant à moindre coût — l’IA réduit le différentiel de vitesse brute.
Ce qui devient différenciant, c’est la capacité à formuler des problèmes précisément, à valider ce qui sort, à porter le contexte métier que l’outil n’a pas, à faire des choix d’architecture qui tiennent dans la durée, à communiquer avec des non-techniques.
En d’autres termes : ce qui a toujours rendu un développeur senior précieux. L’IA n’invalide pas ces compétences. Elle les rend plus visibles, et plus essentielles.
Questions fréquentes
Les développeurs juniors vont-ils disparaître ?
Non, mais leur rôle va changer plus vite que prévu. La valeur d’un junior n’était pas dans sa capacité à écrire du code trivial — c’est ce que les seniors font le moins possible. Elle était dans l’apprentissage progressif du jugement, en prenant en charge des tâches de complexité croissante.
Ce chemin existe toujours. Mais il devient plus exigeant sur la qualité de l’apprentissage actif. Un junior qui sait lire et valider le code IA, comprendre ses limites, et l’intégrer intelligemment dans un workflow restera très employable. Un junior qui s’en sert comme béquille sans comprendre ce qui sort va se retrouver bloqué dès que les conditions changeront.
Faut-il apprendre à coder si on peut utiliser l’IA ?
Oui, et la question elle-même révèle une incompréhension de ce qu’est “coder”. Utiliser l’IA efficacement pour du développement logiciel suppose de comprendre ce que le code produit fait, pourquoi il le fait, et comment détecter quand il le fait mal.
Ce qui change, peut-être, c’est l’ordre et la priorité d’apprentissage. Comprendre les concepts fondamentaux — structures de données, algorithmes, architecture système, sécurité — devient plus important que mémoriser la syntaxe. Mais il faut toujours les comprendre.
L’IA peut-elle gérer un projet de A à Z ?
Pour des projets très bien définis et circonscrits, avec des specs précises et un domaine sans ambiguïté : en partie. Mais “gérer un projet” inclut des dimensions que l’IA ne couvre pas aujourd’hui — et que je doute qu’elle couvre à court terme : comprendre ce que le client veut vraiment (pas ce qu’il dit), arbitrer entre contraintes contradictoires, gérer les changements de scope, valider que le livrable répond au besoin original.
L’IA est un outil dans un workflow. Elle n’est pas le workflow.
Quels développeurs seront les plus valorisés dans 3 ans ?
Ceux qui savent formuler des problèmes complexes en termes que l’IA peut traiter efficacement. Ceux qui portent un contexte métier profond dans un secteur. Ceux qui peuvent valider la qualité et la sécurité de ce qui sort. Ceux qui font le lien entre le besoin non-technique et la solution technique.
En pratique : les développeurs avec une vraie expertise sectorielle (fintech, santé, e-commerce, industrie) combinée à des compétences solides en architecture et revue de code. Les généralistes qui savent tout faire correctement plutôt que tout faire vite.
Vous cherchez un développeur qui sait intégrer l’IA dans son workflow de façon responsable ? Parlons de votre projet