Comment l’IA transforme notre relation au travail dans l’ingénierie logicielle

Idée centrale — L’IA ne rend pas seulement les développeurs plus productifs : elle transforme leur rapport au temps, à l’effort, à la satisfaction et à la limite.

L’essentiel : 2 min

Article complet : 6 min

L’essentiel#

Le développement assisté par IA change brutalement les conditions matérielles du travail logiciel. En réduisant la friction entre l’idée et le résultat, il accélère la production, mais transforme aussi l’expérience subjective du travail. Le développeur ne construit plus seulement dans la durée : il entre dans une boucle rapide de possibilités, faite de prompts, de réponses, d’ajustements et de relances. Cette boucle peut rendre le travail plus excitant, presque ludique, mais aussi plus difficile à arrêter. Le risque n’est pas que les ingénieurs produisent moins ; c’est qu’ils produisent davantage dans un état de stimulation permanente, avec moins de digestion, moins de clôture et parfois moins de satisfaction. L’enjeu n’est donc pas de rejeter l’IA, mais d’apprendre à la dompter : recréer des limites, préserver la compréhension, renforcer les garde-fous, et rester producteur plutôt que consommateur de possibilités.

En trois idées#

1. L’IA transforme le code en boucle courte de récompense. Une idée peut être formulée, générée, testée et relancée en quelques minutes. Cette vitesse donne de la puissance, mais elle rapproche aussi le travail d’une mécanique de jeu : feedback immédiat, progression visible, prochaine action toujours disponible.
2. La disparition de la friction supprime aussi certains points d’arrêt. Une partie de la friction du développement était pénible et inutile. Mais elle servait aussi à ralentir, choisir, hiérarchiser. Quand tout paraît faisable rapidement, il devient plus difficile de dire : “C’est suffisant pour maintenant.”
3. Le vrai défi n’est pas la productivité, mais la maîtrise. Avec l’IA, on peut produire plus vite que l’on ne comprend. Le risque profond est une production objective plus forte, mais une appropriation subjective plus faible : plus de code, moins de digestion, et parfois une architecture qui dérive sans qu’on s’en rende compte immédiatement.

À retenir#

Le progrès ne sera pas seulement d’aller plus vite avec l’IA. Ce sera d’apprendre à aller vite sans être capturé par la vitesse : produire plus, mais garder la capacité de choisir, de comprendre, de finir, et de dire non à la prochaine possibilité.

---

Article complet#

Un ami ingénieur logiciel me racontait récemment que, depuis qu’il code avec l’IA, ses journées ont changé de nature.

Elles passent à une vitesse folle. Il enchaîne les prompts, les corrections, les essais, les améliorations. Les résultats arrivent vite. Trop vite, peut-être. À la fin de la journée, il n’a pas envie d’arrêter. Il sort de là comme après plusieurs heures de jeu vidéo : stimulé, groggy, la tête pleine.

Même en vacances, une pensée revient : j’aurais pu coder, j’aurais pu avancer.

Ce qui est frappant, ce n’est pas seulement qu’il produit plus. C’est qu’il se sent parfois moins satisfait.

Avant, une journée de développement pouvait se terminer par une forme de clôture : un problème résolu, une fonctionnalité terminée, une difficulté traversée. Maintenant, il y a toujours une dernière chose à améliorer. Un dernier prompt. Une dernière relance. Une dernière possibilité.

C’est là que quelque chose bascule.

Produire ou consommer des possibilités#

L’IA rend le développeur plus productif, mais elle peut aussi transformer son rapport subjectif au travail.

On ne produit plus seulement du code. On consomme un flux de possibilités.

Une idée surgit. On la formule. L’IA répond. On teste. On ajuste. On relance. Une autre solution apparaît. Puis une autre. Puis une autre.

La boucle est courte, rapide, gratifiante.

Elle ressemble moins à l’effort lent d’une construction qu’à une mécanique de jeu : objectif immédiat, feedback instantané, progression visible, récompense variable.

La différence, c’est que cette boucle a une légitimité professionnelle. On ne scrolle pas. On ne joue pas. On travaille.

Et c’est précisément ce qui la rend difficile à réguler.

La friction avait une fonction#

Avant l’IA, le développement logiciel contenait beaucoup de friction : chercher, lire, comprendre, écrire, tester, échouer, recommencer.

Une partie de cette friction était inutile. Elle méritait de disparaître.

Mais toute friction n’était pas mauvaise. Elle ralentissait. Elle obligeait à choisir. Elle imposait une temporalité. Elle rendait certaines tâches suffisamment coûteuses pour qu’on se demande si elles valaient vraiment la peine.

L’IA supprime une partie de cette résistance.

C’est un progrès immense.

Mais quand on change les conditions matérielles d’un métier en quelques mois, on ne change pas seulement sa productivité. On change aussi ses dérives.

Si tout devient plus facile à lancer, il devient plus difficile de s’arrêter.

Si chaque amélioration paraît accessible, chaque renoncement paraît suspect.

Si l’outil répond immédiatement, le cerveau apprend à vouloir immédiatement.

L’inachèvement devient insupportable#

Le piège est là : l’IA ne rend pas seulement le travail plus rapide. Elle rend l’inachevé plus visible.

Avant, on pouvait se dire : “Je ferai ça demain, ce serait trop long maintenant.”

Maintenant, on se dit : “Je peux sûrement le faire en dix minutes.”

Et parfois c’est vrai.

Mais dix minutes plus tard, une autre possibilité apparaît. Puis une autre. La journée ne se termine plus parce qu’un cycle est fini. Elle se termine parce qu’il est tard, parce que le corps fatigue, parce que la vie impose de sortir du flux.

L’arrêt devient extérieur au travail.

C’est un changement profond.

Le risque : produire plus, digérer moins#

Le développement logiciel n’est pas seulement une activité de production. C’est une activité de compréhension.

Il ne suffit pas que le code existe. Il faut savoir pourquoi il existe ainsi. Il faut comprendre les frontières, les responsabilités, les invariants, les décisions d’architecture.

Avec l’IA, on peut aller plus vite que sa propre capacité de digestion.

On génère. On modifie. On refactore. On avance. Mais comprend-on encore vraiment ce qui vient d’être produit ?

C’est l’un des grands risques : une production objective plus forte, mais une appropriation subjective plus faible.

Le code augmente. La maîtrise, elle, peut diminuer.

Et dans un système logiciel, cette perte de maîtrise ne se voit pas toujours immédiatement. Elle apparaît plus tard : dans les incohérences, les abstractions molles, les responsabilités floues, les bugs subtils, l’architecture qui dérive.

L’IA amplifie notre culture de la vitesse#

L’IA ne crée pas tout cela à partir de rien. Elle amplifie des tendances déjà présentes dans le logiciel : la fascination pour la vitesse, la valorisation du volume produit, la difficulté à dire “assez”, la confusion entre passion et surinvestissement.

Mais elle change l’intensité.

En quelques mois, les conditions de travail des ingénieurs logiciels ont été brutalement transformées. Ce qui demandait une journée peut parfois prendre une heure. Ce qui semblait trop coûteux devient testable immédiatement. Ce qui était bloqué devient contournable par conversation.

Face à un tel changement, les humains s’adaptent.

Mais l’adaptation n’est pas toujours saine. Elle suit les incitations de l’environnement.

Si l’environnement récompense la relance permanente, nous relançons.

Si l’environnement récompense la vitesse, nous accélérons.

Si l’environnement rend chaque possibilité disponible, nous avons du mal à renoncer.

Apprendre à dompter l’outil#

La réponse n’est pas de rejeter l’IA.

Ces outils sont trop puissants, trop utiles, trop structurants. Ils peuvent réduire la pénibilité, accélérer l’apprentissage, ouvrir des pistes, améliorer la qualité du travail.

Mais il faut apprendre à les dompter.

Dompter l’IA, ce n’est pas seulement mieux prompter. C’est recréer des limites là où la friction a disparu.

C’est décider à l’avance ce que signifie “fini”.

C’est séparer exploration et production.

C’est accepter qu’une amélioration possible ne soit pas forcément une amélioration nécessaire.

C’est garder des moments où l’on ne relance pas, où l’on relit, stabilise, documente, comprend.

Dans le logiciel, cela veut aussi dire renforcer les garde-fous : architecture explicite, contrats clairs, tests, typage, validation aux frontières, observabilité, revues sérieuses.

Plus l’IA accélère, plus les structures doivent tenir.

Sinon, la vitesse devient une force de dispersion.

Rester producteur#

Le risque de l’IA n’est pas que les développeurs ne produisent plus. C’est l’inverse : ils produiront davantage.

Le risque est qu’ils produisent dans un état intérieur de consommation permanente : toujours stimulés, jamais rassasiés, toujours proches d’une amélioration, jamais vraiment satisfaits.

Rester producteur, ce n’est pas seulement générer plus. C’est choisir. Hiérarchiser. Fermer. Assumer une forme. Dire : “C’est suffisant pour maintenant.”

Le vrai progrès ne sera donc pas seulement d’aller plus vite.

Ce sera d’aller vite sans être capturé par la vitesse.

De produire plus sans perdre la capacité de terminer.

D’utiliser l’IA sans devenir dépendant de la boucle.

Et de remettre, au cœur du travail assisté par IA, ce que l’outil tend naturellement à effacer : de la limite, de l’attention, de la digestion, et une vraie capacité à dire non à la prochaine possibilité.