« L’IA va tuer les développeurs. » On a lu ça mille fois en 2024, dix mille fois en 2025, et la prédiction continue de tourner en 2026. Pourtant les chiffres racontent une autre histoire. Pôle emploi recense en France près de 18 % d’offres en plus pour les profils tech expérimentés sur les douze derniers mois, et les rémunérations à l’embauche grimpent. Le paradoxe n’est qu’apparent. L’histoire industrielle a déjà répondu à cette question. Il suffit de regarder ce qui s’est passé quand le métier à tisser mécanique est arrivé dans les filatures du XIXᵉ siècle.
La leçon oubliée de la révolution industrielle
Quand les premiers métiers à tisser automatisés ont fait leur apparition, les tisserands manuels ont cru à leur disparition. Une partie l’a effectivement été. Tous ceux dont le geste se résumait à répéter une opération mécanique se sont retrouvés sans ressource. Mais l’industrie textile, elle, n’a pas rétréci. Elle a explosé. Le coût de production s’est effondré, la demande a été démultipliée, et de nouveaux métiers sont apparus en masse : ingénieurs mécaniciens, contremaîtres, designers, contrôleurs qualité, logisticiens, marchands. Les artisans qui avaient acquis une vraie maîtrise du métier (comprendre les fibres, lire un patron complexe, garantir une finition) sont devenus plus précieux qu’avant, parce qu’ils savaient faire ce que la machine ne savait pas faire seule : juger, arbitrer, contrôler, créer.
Ce qui se passe avec l’IA générative en 2026 est exactement de la même nature. L’IA n’élimine pas les développeurs, elle élimine certains gestes. Et elle révèle, en creux, la différence entre quelqu’un qui sait coder et quelqu’un qui comprend ce qu’est un logiciel.
Le piège du « vibe coding »
Le phénomène a un nom depuis 2025. On l’appelle le vibe coding. L’idée est séduisante. Vous décrivez en français ce que vous voulez, l’IA écrit le code, vous déployez, et vous passez à l’idée suivante. En quelques heures, n’importe qui peut désormais produire un site, une application mobile ou une API. Le résultat fonctionne, du moins visuellement. Et c’est précisément là que commencent les problèmes.
Sous le capot, un code généré sans regard expert présente presque toujours les mêmes pathologies :
- Des failles de sécurité béantes : injections SQL, XSS, secrets en clair dans le code, dépendances vulnérables non auditées, absence de contrôle d’autorisation côté serveur (la fameuse faille IDOR), authentification sommaire, gestion approximative des sessions.
- Aucune architecture pérenne : couplage fort, logique métier mélangée à l’interface, impossible à faire évoluer sans tout réécrire.
- Pas de tests automatisés, donc pas de filet de sécurité pour modifier quoi que ce soit ensuite.
- Aucune observabilité : pas de logs structurés, pas de métriques, pas d’alertes. Quand ça plante en production, personne ne sait pourquoi.
- Une dette technique colossale accumulée dès le premier sprint, parce que l’IA optimise la réponse immédiate et pas le coût total de possession.
- Une non-conformité réglementaire systématique. RGPD, accessibilité (RGAA, WCAG), AI Act, hébergement des données, tous ces sujets restent invisibles tant qu’on ne sait pas qu’ils existent.
Un site vitrine « vibe codé » peut passer en production sans incident. Une application qui traite des données personnelles, qui encaisse des paiements ou qui gère des accès, c’est une autre histoire. Et l’écart entre les deux mondes ne va pas se réduire. Il va se creuser.
Ce que l’IA fait bien, et ce qu’elle ne fait pas
Pour comprendre pourquoi les vrais développeurs vont rester indispensables, il faut savoir ce que l’IA sait faire, et ce qu’elle ne sait pas faire.
Ce qu’elle fait bien
Générer du boilerplate, traduire un cahier des charges en première version d’un module, écrire un test unitaire à partir d’une fonction existante, expliquer une bibliothèque, suggérer une expression régulière, refactoriser un bloc, documenter un endpoint. Pour un développeur expérimenté, c’est un multiplicateur de productivité majeur, souvent un facteur 2 à 4 sur les tâches mécaniques.
Ce qu’elle ne sait pas faire
Choisir la bonne architecture pour un système qui doit tenir cinq ans. Anticiper les problèmes de montée en charge. Identifier qu’un schéma de base de données va devenir ingérable à 100 000 enregistrements. Repérer qu’un appel d’API exposé sans rate limiting va coûter une fortune en cas d’abus. Comprendre qu’un workflow métier décrit par le client est en réalité incohérent avec la réalité opérationnelle. Arbitrer entre coût et qualité. Négocier un périmètre. Lire entre les lignes d’une spec floue. Tout ce qui relève du jugement, du contexte et de la responsabilité reste hors de portée. Et ça le restera longtemps.
Le nouveau profil du développeur professionnel
Le métier ne disparaît pas, il se redéfinit. Le développeur professionnel de 2026 ressemble de moins en moins à un dactylographe de code, et de plus en plus à un architecte, un éditeur et un garant de qualité. Concrètement, ses compétences-clés deviennent les suivantes.
- L’architecture logicielle : savoir découper, modulariser, choisir les bons patrons (DDD, hexagonal, microservices vs monolithe modulaire).
- La sécurité applicative : connaître l’OWASP Top 10 sur le bout des doigts, savoir auditer une dépendance, configurer correctement une politique CORS, gérer des secrets avec un coffre-fort, raisonner en termes de surface d’attaque.
- Le DevOps et la fiabilité : CI/CD, infrastructure as code, supervision, alerting, gestion des incidents, plans de continuité.
- La revue critique du code généré : repérer en lecture ce que l’IA a écrit de travers, refuser une suggestion plausible mais fausse, demander la bonne reformulation.
- La conformité : RGPD, AI Act, accessibilité, normes sectorielles (HDS pour la santé, PCI-DSS pour le paiement).
- La capacité à dialoguer avec les métiers : reformuler un besoin, challenger une spec, proposer des alternatives.
Aucune de ces compétences ne s’acquiert en quelques semaines de prompt engineering. Toutes s’acquièrent en années de pratique, sur des projets réels, avec des conséquences réelles.
Les deux marchés du logiciel qui se dessinent
D’ici trois à cinq ans, le marché du logiciel se polarise en deux segments très différents.
Il y a d’abord le marché du jetable. Sites vitrines, prototypes internes, outils de productivité personnelle, automatisations légères. Tout ce que des non-développeurs vont produire eux-mêmes avec l’IA. La valeur unitaire de ces livrables est basse, leur durée de vie courte, leurs exigences faibles. C’est un marché qui va croître en volume mais s’effondrer en marge. Il n’y a pas de business sérieux à construire dessus.
Et puis il y a le marché du logiciel professionnel. Applications métier critiques, plateformes traitant des données sensibles, systèmes connectés à de la facturation, du paiement, de la donnée client, de la donnée personnelle, des objets connectés, de l’industriel. Tout ce qui doit tenir dix ans, supporter de la charge, respecter des contraintes réglementaires, évoluer avec le métier, ne pas se faire pirater. Sur ce marché-là, la barrière d’entrée monte au lieu de baisser, parce que la complexité augmente, et avec elle la prime versée aux équipes qui savent vraiment faire.
Ce que cela signifie pour les entreprises qui commandent du logiciel
Si vous êtes décideur dans une PME, une ETI ou une collectivité, la conséquence est simple : tout ce que vous mettez en production a désormais un coût caché plus grand qu’avant. L’IA permet à n’importe quel prestataire, voire à un stagiaire, de livrer rapidement quelque chose qui ressemble à un produit fini. Le piège, c’est que la facture arrive plus tard. Sous forme de fuite de données, d’incident de production, de non-conformité, ou d’une refonte complète dans dix-huit mois parce que personne n’arrive plus à faire évoluer la base de code.
Quelques garde-fous simples permettent d’éviter le piège :
- Exiger un audit de sécurité avant la mise en production de toute application traitant des données personnelles ou financières.
- Demander à voir le code et la documentation, même quand on n’est pas développeur. L’absence de l’un comme de l’autre est un signal d’alerte.
- Faire valider l’architecture par un tiers avant d’engager un budget de développement significatif.
- Privilégier des prestataires qui maîtrisent l’IA et le métier de développeur, pas seulement l’un ou l’autre.
- Inscrire dans le contrat les exigences de tests, de sécurité, de conformité et de réversibilité.
Ni utopie, ni catastrophe, mais une professionnalisation
L’IA ne vide pas le métier de développeur, elle le professionnalise. Elle élimine la partie la moins intéressante du travail (les boucles répétitives, les variations triviales d’un même schéma) et met en valeur ce qui fait la vraie expertise : la capacité à concevoir un système qui marche bien, longtemps, en sécurité, pour les bons utilisateurs. Pour les entreprises, c’est une excellente nouvelle : leurs équipes techniques deviennent plus efficaces. Pour les vrais développeurs, c’est aussi une excellente nouvelle, parce que leur travail prend de la valeur. Et pour les amateurs du vibe coding qui produisent à la chaîne des applications fragiles, la fête durera ce que dure une bulle.
Comme le tisserand maîtrisant son métier qui a continué de prospérer pendant que la mécanisation balayait les gestes répétitifs, le développeur qui maîtrise réellement son art n’a jamais été en si bonne position.
Notre accompagnement
Chez AXALYS, nous combinons les deux mondes. Une équipe de développeurs expérimentés qui maîtrisent l’architecture, la sécurité et la conformité, outillée par les meilleures pratiques d’IA générative pour livrer plus vite, mieux, et sans compromis sur la qualité. Que vous ayez besoin de faire auditer une application existante, de cadrer un nouveau projet ou de faire monter en compétences vos équipes internes sur l’IA, parlons-en.
Crédit photo : Unsplash.
