lecteurs.ch

Depuis deux ans, une petite musique revient partout : “bientôt, l’IA écrira tout le code”. Et il faut reconnaître que l’impression est forte. On voit des outils générer des fonctions entières à partir d’une consigne, corriger des bugs, proposer des tests, expliquer une base de code inconnue comme si elle l’avait écrite. Pour beaucoup, la question est devenue presque brutale : si une machine peut produire du code, à quoi sert encore un programmeur ?

La réponse la plus honnête, c’est que la programmation change vite… mais qu’elle ne disparaît pas. Elle se déplace. Elle se recombine. Et surtout, elle se réorganise autour de ce que l’IA fait bien, et de ce qu’elle fait encore mal.

Pourquoi l’ia donne l’impression de “remplacer” le code

Une grande partie du travail quotidien en développement ressemble à des tâches répétitives : écrire du “plomberie” applicative, traduire des exigences en logique, créer des endpoints, gérer des formulaires, produire des scripts d’intégration, générer des tests unitaires, corriger des erreurs de typage, réécrire une fonction plus lisible. Sur ce terrain, l’IA est très à l’aise : elle accélère, elle suggère, elle propose des variantes.

Dans certains projets simples — des applications administratives, des sites web standard, des automatisations internes — on peut déjà obtenir une grande portion de code “fonctionnel” sans écrire chaque ligne à la main. Et c’est là que naît la peur : si on peut générer 80% du code, est-ce que 80% des postes vont sauter ?

Sauf que le code n’est pas le produit final. C’est un moyen.

Le logiciel, ce n’est pas seulement écrire du code

Développer un logiciel, c’est aussi :

• comprendre le besoin réel (souvent flou, contradictoire, politique),
• cadrer les exigences, les contraintes, les priorités,
• choisir une architecture,
• définir des interfaces et des contrats,
• tester, valider, monitorer,
• documenter,
• déployer en production,
• gérer la sécurité, la conformité, la performance,
• maintenir sur la durée.

L’IA peut aider à chaque étape, mais elle ne “possède” pas la responsabilité de l’ensemble. Et dans le monde réel, c’est cette responsabilité qui coûte cher (et qui fait la différence entre un outil utile et un incident majeur).

En clair : on ne paie pas une entreprise pour “du code”. On paie pour un système qui marche, qui tient la charge, qui ne fuit pas des données, qui résiste aux erreurs humaines, et qui évolue sans tout casser.

Le nouveau rôle : moins de dactylographie, plus de supervision

Dans beaucoup d’équipes, le mouvement est déjà visible : le programmeur devient davantage un pilote qu’un scribe. Il passe moins de temps à taper et plus de temps à :

• vérifier la logique,
• relire avec un œil critique,
• détecter les angles morts,
• renforcer les tests,
• sécuriser les composants,
• intégrer proprement,
• refactoriser.

Autrement dit, le cœur du métier se rapproche de l’ingénierie : concevoir, arbitrer, valider, maintenir.

Et une compétence “surprenante” devient centrale : savoir demander. Pas au sens gadget (“écris-moi une fonction”), mais au sens méthodique : formuler un objectif, donner le contexte, préciser les contraintes, exiger un format, puis itérer. Le prompt n’est pas un tour de magie. C’est une nouvelle manière de spécifier.

Le piège : un code plausible n’est pas forcément un code fiable

L’IA produit souvent du code convaincant. Parfois même élégant. Mais “convaincant” n’est pas “correct”.

Le risque principal n’est pas que l’IA écrive du mauvais code tout le temps. Le risque, c’est qu’elle écrive du code qui a l’air bon… avec un bug discret, une hypothèse fausse, une dépendance fragile, une faille de sécurité, ou un comportement non couvert par les tests.

Et quand un système tombe, personne ne va accepter “c’est l’IA qui l’a fait” comme excuse. La responsabilité reste du côté de l’entreprise, de l’équipe, des personnes qui ont validé. Ce point est crucial : plus on accélère la production, plus la validation devient la pièce maîtresse.

Est-ce que certains postes vont quand même disparaître ?

Oui, probablement. Mais pas de la façon caricaturale “plus besoin de dev”.

Ce qui est le plus exposé, ce sont les tâches d’entrée de gamme très répétitives, où la valeur vient surtout de l’exécution rapide : produire des variantes, du CRUD standard, des scripts simples, des adaptations mineures. Les entreprises pourraient avoir besoin de moins de personnes pour le même volume de travail.

En parallèle, la barre peut monter pour les juniors : on attendra d’eux plus vite une compréhension système, une rigueur de test, une culture sécurité, une capacité à travailler avec l’IA sans se faire piéger. C’est dur à entendre, mais c’est cohérent : quand la production se banalise, la valeur se déplace vers la qualité.

Et paradoxalement, cela peut aussi créer de la demande : si construire coûte moins cher et va plus vite, davantage d’organisations voudront des logiciels, davantage de prototypes deviendront des produits, et il faudra des équipes pour industrialiser tout ça.

Les compétences qui prennent de la valeur

Si vous êtes développeur (ou en train de le devenir), voici les axes qui semblent clairement monter :

• architecture et conception : savoir découper un système, choisir les bons compromis ;
• tests et qualité : automatisation, couverture intelligente, scénarios réels ;
• sécurité : menaces, bonnes pratiques, revue de dépendances, secrets, permissions ;
• observabilité : logs, métriques, traces, détection d’incidents ;
• compréhension métier : traduire un besoin en logiciel utile, pas juste “qui compile” ;
• lecture de code : comprendre vite une base existante, diagnostiquer, refactoriser ;
• collaboration : clarifier, documenter, expliquer, faire circuler la connaissance.

L’IA n’annule pas ces compétences. Elle les rend plus visibles. Et souvent, plus indispensables.

Ce que ça change dans l’apprentissage

Il y a une tentation : se dire “inutile d’apprendre à coder, l’IA le fera”. C’est une erreur de perspective.

Apprendre à programmer, ce n’est pas mémoriser une syntaxe. C’est apprendre à penser en systèmes, à décomposer un problème, à comprendre les états, les flux, les erreurs, la complexité, les invariants. Même si demain la majorité du code est générée, ces fondations restent nécessaires pour vérifier, corriger, orienter, sécuriser.

Comme avec les calculatrices : elles n’ont pas supprimé les mathématiques. Elles ont déplacé l’effort vers des problèmes plus élevés.

Pour finir

Le futur des programmeurs ressemble moins à une extinction qu’à une redistribution des cartes. L’IA va continuer à avaler une partie de la production “mécanique”, et ce mouvement va bousculer des postes, surtout là où la valeur était principalement dans la vitesse d’exécution.

Mais le logiciel reste un métier de responsabilité : faire des choix, garantir la qualité, limiter les risques, comprendre le réel, et tenir la route dans le temps. Dans ce paysage, le programmeur ne devient pas inutile. Il devient, plus que jamais, celui qui garde le cap.