Tu es Software Engineer et tu te sens plus fatigué·e depuis l’arrivée de l’IA ? C’est sans doute le symptôme le plus parlant que ton approche n’est pas encore la bonne. Le paradoxe est brutal : on nous vend des outils censés déléguer une partie massive de notre travail, et pourtant beaucoup en sortent plus épuisés qu’avant.
J’ai récemment observé cette fatigue au sein de plusieurs équipes que j’accompagne. Et elle m’interpelle. Non pas qu’une forme de fatigue soit illogique en soi, mais parce qu’on parle d’outils qui devraient, a priori, nous décharger d’une partie de l’effort. De la même manière que je m’attendrais à être moins fatigué en utilisant une visseuse électrique plutôt qu’un tournevis manuel. Si l’outil censé démultiplier ta force te laisse exsangue, c’est que quelque chose dans la manière de s’en servir cloche.
D’où vient vraiment cette fatigue
En creusant avec ces équipes, trois causes reviennent systématiquement. Aucune n’est imputable à l’IA elle-même : toutes découlent de la façon dont on l’emploie.
La submersion par le code
L’IA produit du code en très grande quantité, et très vite. Le problème, c’est que ce code, ce n’est pas toi qui l’as écrit. Chaque ligne générée devient une ligne à relire, à comprendre, à vérifier. La charge cognitive ne disparaît pas : elle se déplace. On passe d’un travail d’écriture, où l’on construit progressivement sa compréhension du problème, à un travail de relecture en bloc, où il faut reconstituer après coup l’intention derrière des dizaines ou des centaines de lignes apparues d’un coup. Et relire du code qu’on n’a pas pensé soi-même est l’une des activités les plus coûteuses qui soient.
Le Context Switching permanent
L’écriture de prompts façon « Vibe Coding », où l’on lance une consigne large et où l’on laisse l’agent partir, génère d’immenses quantités de code et mobilise l’agent pendant plusieurs minutes, parfois plusieurs dizaines de minutes. Pendant ce temps, que fait-on ? On bascule sur un autre sujet. Puis sur un troisième. À chaque bascule, on repaie le coût du changement de contexte, et surtout on reproduit le problème précédent : du code à relire et à comprendre, mais cette fois multiplié par le nombre de sujets ouverts en parallèle. La fatigue n’est plus additive, elle devient multiplicative.
L’illusion de productivité
C’est sans doute le piège le plus insidieux. Il est aujourd’hui très facile d’avoir le sentiment de produire énormément et d’avancer à toute vitesse. Mais une question reste : est-on réellement plus productif en fonctionnant ainsi ? Quel est le lead time réel des incréments produits : le temps qui sépare le début d’un travail de sa mise effective en production ?
Quatre sujets entamés à 60 %, ce n’est pas 60 % de valeur livrée : c’est zéro valeur livrée et quatre sources de charge mentale ouvertes. C’est précisément ce que le schéma ci-dessous met en regard : à gauche, l’illusion de productivité : beaucoup de choses lancées, rien de terminé, et au bout la charge cognitive, le context switching et la fatigue qui montent ; à droite, le one-piece flow, un seul sujet mené de A à Z jusqu’en production avant d’attaquer le suivant.
Le one-piece flow, hérité du Toyota Production System, nous invite justement à privilégier la complétion à 100 % d’un sujet unique plutôt qu’un avancement partiel réparti sur plusieurs fronts. Tant qu’un incrément n’est pas en production, il ne crée aucune valeur : il ne fait qu’accumuler du travail en cours et de la charge mentale.
Revenir aux fondamentaux du Software Engineering
La bonne nouvelle, c’est que la solution n’a rien d’inédit. Elle nous ramène aux fondamentaux de l’ingénierie logicielle, ceux-là mêmes que le software craftsmanship défend depuis des années. L’IA ne les remplace pas : elle les rend plus accessibles et plus puissants.
- Des baby steps et des micro-itérations. Avancer par petits pas, soutenus par des tests automatisés qui entretiennent une feedback loop rapide. Chaque itération reste petite, vérifiable, et maintient ta compréhension à jour plutôt que de la diluer dans un flot de code massif.
- Le dialogue avec le produit. Identifier de petits incréments à forte valeur, en discussion étroite avec le métier, plutôt que de lancer l’agent sur des chantiers flous et tentaculaires.
- Le delivery de bout en bout. Mener un incrément de valeur de A à Z, sans interruption, jusqu’en production. C’est là, et seulement là, que la valeur se concrétise.
- L’obsession de la qualité. Refactoring intensif et amélioration continue, pour que la base de code reste saine au fil du temps au lieu de se dégrader sous le poids du code généré.
L’avantage, désormais, c’est que tu as de moins en moins de code à écrire à la main, et que ta force de frappe est démultipliée. Énormément de tâches autrefois fastidieuses peuvent être automatisées. Mais cette puissance ne doit pas servir à ouvrir dix chantiers en même temps : elle doit servir à boucler chaque chantier plus vite et plus proprement.
L’Agentic Coding bien fait
C’est tout l’enjeu de l’Agentic Coding tel que je le défends auprès de mes clients. Il ne s’agit pas de déléguer aveuglément à un agent et de regarder le code défiler, mais d’orchestrer l’outil dans la continuité directe des fondations du Software Engineering et du Craftsmanship.
Concrètement, cela signifie garder la main sur le flux : un sujet à la fois, des incréments courts, des tests qui valident chaque pas, et une revue qui reste gérable parce qu’elle porte sur de petites quantités de code dont tu comprends l’intention. L’agent devient un accélérateur au service d’une discipline, et non un générateur de travail en cours qui s’accumule plus vite que tu ne peux l’absorber.
Pratiqué ainsi, le résultat est exactement celui qu’on attendait au départ : tu vas plus vite, tu fais mieux, c’est-à-dire que tu produis moins de bugs, et tu termines tes journées moins fatigué·e. L’outil tient enfin sa promesse.
Conclusion
La fatigue à l’ère de l’IA n’est pas une fatalité, et elle n’est pas non plus le prix à payer pour aller plus vite. C’est un signal. Le signal qu’on a laissé l’outil dicter le rythme (submersion de code, context switching, illusion de productivité) au lieu de l’inscrire dans une discipline d’ingénierie éprouvée.
L’Agentic Coding bien fait ne réinvente pas le métier : il en prolonge les meilleures pratiques. Baby steps, one-piece flow, delivery de bout en bout, qualité continue. La visseuse électrique ne fatigue pas plus que le tournevis, à condition de l’utiliser pour visser, pas pour courir dans toutes les directions à la fois.