Être développeur à l'ère de l'IA : avantage durable ou métier en voie de commoditisation ?

Pendant des années, apprendre à programmer semblait être un pari relativement évident.

Le numérique se développait, les entreprises se transformaient, les logiciels devenaient omniprésents et les développeurs étaient de plus en plus recherchés. Apprendre à construire des applications semblait donc être une compétence presque universelle : on pouvait travailler pour une entreprise, créer un produit, devenir freelance ou lancer sa propre startup.

Puis l'intelligence artificielle est arrivée.

Aujourd'hui, un développeur peut demander à un modèle d'IA de générer une interface, une API, une base de données ou même une application complète. Des outils permettent déjà de transformer une simple description en prototype fonctionnel.

Une question devient alors légitime :

Si l'IA rend la création d'applications toujours plus facile, est-ce encore intéressant de devenir développeur ?

La réponse n'est probablement ni « oui, absolument » ni « non, le métier va disparaître ».

Le véritable changement est plus subtil : la valeur du développeur est progressivement en train de se déplacer.

Le code devient une commodité

Pendant longtemps, une partie importante de la valeur d'un développeur résidait dans sa capacité à transformer une spécification en code.

On lui demandait par exemple :

« Il faut une page de connexion, un tableau de bord et un système de gestion des utilisateurs. »

Il fallait savoir concevoir la base de données, écrire le backend, construire le frontend, gérer l'authentification et déployer l'application.

Aujourd'hui, une grande partie de ce travail peut être assistée par l'IA.

Cela ne signifie pas que ces tâches ont disparu. Mais leur coût tend à diminuer.

Et lorsque le coût de production d'une chose diminue fortement, cette chose a tendance à devenir moins rare.

C'est probablement l'un des changements fondamentaux apportés par l'IA au développement logiciel.

Le code lui-même pourrait progressivement devenir une commodité.

Écrire 500 lignes de code n'est plus nécessairement une démonstration de compétence. La question devient plutôt :

Ces 500 lignes font-elles réellement ce qu'il faut, dans le bon contexte, avec le niveau de sécurité, de fiabilité et de maintenabilité nécessaire ?

C'est une question très différente.

La commoditisation ne signifie pas la disparition

Il serait toutefois dangereux d'en déduire que les développeurs vont simplement disparaître.

Il existe une autre possibilité : l'IA pourrait surtout rendre les développeurs beaucoup plus productifs.

Imaginons qu'un développeur puisse produire cinq fois plus de logiciel qu'auparavant.

Deux scénarios sont alors possibles :

• soit les entreprises utilisent cette productivité pour employer moins de développeurs ;
• soit elles utilisent cette capacité pour construire beaucoup plus de logiciels.

L'histoire économique montre que les deux phénomènes peuvent coexister.

Lorsqu'une technologie rend un produit moins cher à fabriquer, la demande peut également augmenter.

Et c'est particulièrement intéressant pour le logiciel.

Aujourd'hui, des milliers d'entreprises ont encore des processus gérés avec des fichiers Excel, des emails, des PDF et des outils vieillissants.

Pourquoi ?

Parce que développer un logiciel spécifique pour une entreprise ou une niche pouvait auparavant coûter trop cher.

Si l'IA réduit fortement le coût de développement, une nouvelle catégorie de logiciels devient économiquement viable :

• des logiciels pour des marchés minuscules ;
• des outils pour des professions particulières ;
• des automatisations pour des entreprises de quelques dizaines de personnes ;
• des applications internes qui n'auraient jamais justifié une équipe de développement.

L'IA pourrait donc rendre le développement plus facile tout en provoquant une explosion du nombre de logiciels produits.

Ce qui devient moins précieux

Si l'on accepte cette hypothèse, certaines compétences risquent naturellement de perdre une partie de leur valeur relative.

C'est notamment le cas du développement très standardisé :

• créer un CRUD classique ;
• construire une landing page ;
• connecter une API ;
• créer un formulaire ;
• faire une interface administrative ;
• écrire du boilerplate ;
• implémenter une fonctionnalité très précisément décrite.

Ces compétences resteront utiles.

Mais elles seront probablement moins différenciantes.

Si une IA peut réaliser 80 % du travail en quelques secondes, savoir réaliser ces 80 % un peu plus rapidement qu'un autre développeur ne constitue plus nécessairement un avantage majeur.

Cela pousse à regarder ce qui se trouve autour du code.

Ce qui devient potentiellement plus précieux

Une application réelle n'est pas simplement du code.

Elle se trouve au milieu d'un système beaucoup plus complexe :

problème → besoin → conception → code → données → infrastructure
→ utilisateurs → contraintes métier → sécurité → opérations → résultat économique

L'IA peut intervenir sur une grande partie de cette chaîne.

Mais elle ne supprime pas automatiquement la complexité du monde réel.

Prenons un exemple : un logiciel de paie.

Construire une interface permettant d'ajouter un salarié est relativement simple.

Construire un véritable système de paie fiable est beaucoup plus complexe.

Il faut comprendre les règles sociales, les cotisations, les absences, les congés, les conventions collectives, les déclarations, les cas particuliers, les évolutions réglementaires, la sécurité des données et les conséquences d'une erreur.

Le défi n'est donc plus seulement :

« Comment écrire ce logiciel ? »

Il devient :

« Qu'est-ce que ce logiciel doit réellement faire pour être fiable dans le monde réel ? »

C'est là que la connaissance métier prend énormément de valeur.

Le développeur de demain pourrait être un hybride

Une conséquence intéressante de cette évolution est que le meilleur profil ne sera peut-être pas nécessairement celui qui connaît le plus de frameworks.

Ce pourrait être celui qui combine plusieurs compétences. Par exemple :

• programmation + finance ;
• programmation + comptabilité ;
• programmation + industrie ;
• programmation + cybersécurité ;
• programmation + droit ;
• programmation + logistique ;
• programmation + ressources humaines.

Cette combinaison crée quelque chose de difficile à automatiser.

Une personne qui comprend profondément un problème métier et qui sait construire une solution technique dispose d'un avantage différent de celui d'un développeur généraliste :

• elle peut identifier des problèmes que les autres ne voient pas ;
• elle peut comprendre pourquoi une solution proposée par une IA est incorrecte ;
• elle peut dialoguer avec les utilisateurs ;
• elle peut déterminer quelles fonctionnalités sont réellement importantes ;
• et elle peut construire elle-même la solution.

Une autre compétence devient centrale : savoir quoi construire

Il existe une différence fondamentale entre savoir programmer et savoir construire un produit.

Le premier problème est technique :

« Comment implémenter cette fonctionnalité ? »

Le second est produit :

« Est-ce que cette fonctionnalité doit exister ? »

Cette distinction devient encore plus importante lorsque le coût de développement baisse.

Si développer une fonctionnalité coûte six mois de travail, il est naturel de réfléchir longuement avant de la construire.

Si une IA permet de la développer en une heure, la tentation est de tout construire.

On risque alors de créer énormément de logiciels dont personne n'a réellement besoin.

Le goulot d'étranglement se déplace. Ce n'est plus forcément :

« Qui sait programmer ? »

mais :

« Qui sait quel problème mérite d'être résolu ? »

Et si le véritable avantage était entrepreneurial ?

C'est peut-être là que l'évolution devient la plus intéressante.

Il y a quelques années, lancer un SaaS nécessitait :

• plusieurs développeurs ;
• plusieurs mois de développement ;
• une infrastructure importante ;
• un budget conséquent.

Si l'IA réduit drastiquement ces coûts, un individu techniquement compétent peut désormais expérimenter beaucoup plus rapidement.

Une idée peut devenir un prototype.

Le prototype peut devenir un produit.

Le produit peut être testé auprès de quelques utilisateurs.

Et si personne ne l'utilise, on peut passer à autre chose.

Cela réduit considérablement le coût de l'expérimentation.

Mais il y a un paradoxe.

Si tout le monde peut construire facilement une application, construire une application devient moins différenciant.

L'avantage se déplace alors vers :

• la compréhension du marché ;
• la distribution ;
• la relation avec les clients ;
• l'expertise métier ;
• la confiance ;
• la capacité à résoudre un problème important ;
• la capacité à transformer un prototype en véritable entreprise.

Le code devient plus facile.

Construire une entreprise ne l'est pas nécessairement.

Alors, faut-il encore apprendre à programmer ?

À mon sens, oui — mais pas pour la même raison qu'il y a dix ans.

Il ne s'agit plus forcément de devenir un excellent « producteur de code ».

Il s'agit d'acquérir la capacité à comprendre et construire avec la technologie.

Un développeur qui comprend les bases de la programmation peut utiliser l'IA de manière beaucoup plus efficace qu'une personne qui ne comprend pas ce qu'elle produit. Il peut :

• lire le code généré ;
• identifier une erreur ;
• comprendre une architecture ;
• questionner une réponse de l'IA ;
• évaluer une solution ;
• faire évoluer un système.

Et surtout, savoir quand l'IA raconte n'importe quoi.

L'IA ne supprime donc pas nécessairement l'intérêt d'apprendre à programmer.

Elle pourrait au contraire rendre cette compétence plus proche d'une culture technique fondamentale.

Trois directions de carrière

Pour quelqu'un qui doit choisir aujourd'hui, je vois au moins trois grandes directions.

1. Le développeur généraliste

Apprendre le frontend, le backend, les bases de données, les APIs et le cloud.

C'est une excellente manière d'apprendre à construire.

Mais il faut garder à l'esprit que le développement standardisé est précisément l'une des zones les plus exposées à l'automatisation.

La stratégie peut donc être d'utiliser cette voie comme socle plutôt que comme destination finale.

2. L'ingénieur spécialisé

Aller plus profondément dans les systèmes : architecture, bases de données, sécurité, infrastructure, systèmes distribués, performance, fiabilité.

Plus les systèmes deviennent complexes, plus il devient difficile de simplement demander à une IA de « tout faire ».

Cette voie demande davantage de connaissances techniques, mais elle permet de comprendre ce qui se passe sous les abstractions.

3. Le constructeur de produits

Combiner technique, IA, produit et compréhension métier.

C'est probablement la voie la plus entrepreneuriale.

Le développeur ne se demande plus seulement :

« Quel code dois-je écrire ? »

mais :

« Quel problème puis-je résoudre et comment puis-je construire une solution suffisamment bonne pour que quelqu'un paie pour l'utiliser ? »

Dans ce modèle, l'IA devient un multiplicateur.

Le véritable pari

Au fond, le pari intéressant n'est peut-être pas :

« L'IA remplacera-t-elle les développeurs ? »

Personne ne peut répondre avec certitude à cette question.

Le pari plus utile est :

« Quelles compétences resteront précieuses lorsque le logiciel deviendra beaucoup moins coûteux à produire ? »

La réponse semble moins liée à la syntaxe d'un langage qu'à la capacité à comprendre les systèmes, les utilisateurs et les problèmes :

• programmation ;
• architecture ;
• IA ;
• produit ;
• domaine métier ;
• business.

Ces compétences peuvent se renforcer mutuellement.

Un développeur qui sait seulement produire du code peut être concurrencé par une IA capable de produire du code.

Un développeur qui sait comprendre un problème complexe, concevoir un système, utiliser l'IA pour accélérer son travail et comprendre le métier auquel ce système s'adresse est dans une position différente.

Finalement, le métier pourrait devenir plus intéressant

Il y a une manière optimiste de regarder cette transformation.

Pendant des décennies, les développeurs ont consacré énormément de temps à des tâches répétitives : écrire du boilerplate, chercher une erreur de syntaxe, créer des interfaces administratives, connecter des services entre eux.

Si l'IA prend progressivement en charge une partie de ce travail, cela pourrait permettre aux développeurs de consacrer davantage de temps à des questions plus intéressantes :

• Quel problème résoudre ?
• Comment concevoir le système ?
• Comment le rendre fiable ?
• Comment l'intégrer dans une organisation ?
• Comment créer un produit que les gens veulent réellement utiliser ?

La valeur du développeur pourrait donc se déplacer du code vers la capacité à construire.

Et c'est probablement la distinction la plus importante à garder en tête lorsqu'on envisage aujourd'hui une carrière dans la technologie.

Ne pas apprendre à coder uniquement pour écrire du code.

Apprendre à coder pour devenir capable de construire.

Dans un monde où le coût de production du logiciel diminue, cette capacité pourrait devenir non pas moins importante, mais simplement beaucoup plus large.