La « fatigue de l'IA » : que se passe-t-il quand les équipes produit n'arrivent plus à suivre le rythme de leurs propres agents ?

Depuis deux ans, les discussions autour de l’IA dans l’ingénierie logicielle tournent autour d’un seul sujet : la productivité. Les ingénieurs livrent plus vite, écrivent plus de code et terminent en quelques heures des tâches qui prenaient autrefois plusieurs jours. Chaque nouveau modèle promet un nouveau bond en avant.

Ce qui retient beaucoup moins l’attention, c’est ce que toute cette rapidité exige de ceux qui l’utilisent. Guillaume Moigneu, directeur technique sur le terrain chez Upsun, a passé l’année dernière à observer les équipes d’ingénieurs s’adapter au développement assisté par l’IA. Pour les architectes expérimentés, ce changement a été une véritable révolution. « Je peux toujours m’occuper de l’architecture, en donnant des spécifications aux agents, puis l’IA s’occupe des détails techniques et écrit le code », explique-t-il.

Mais ces avancées prennent une tout autre dimension dès que l’IA dépasse le cadre des développeurs individuels pour s’intégrer aux processus de toute l’équipe.

La fatigue dont personne ne parle

La fatigue liée à l’IA est devenue un sujet de plainte courant, mais elle est souvent mal cernée. La plupart des gens pensent qu’elle vient d’une surcharge d’outils ou d’un battage médiatique incessant. Guillaume y voit autre chose : la charge cognitive liée à la supervision simultanée de plusieurs agents IA.

« J’ai commencé à avoir plusieurs agents en même temps sur mon ordinateur portable », raconte-t-il. « Je faisais quatre ou cinq choses différentes, parfois sur le même projet, parfois sur des projets différents, et je me sentais un peu submergé par tout ça. » Le problème, ce n’était pas la quantité de travail ; c’était la supervision constante et les changements de contexte incessants. Toujours à une commande près de finir ça. 

La plupart des développeurs ont besoin de longues périodes de concentration ininterrompue pour résoudre des problèmes complexes. Les agents IA ne fonctionnent pas comme ça. Ils terminent leur travail dès qu’ils sont prêts, renvoient des résultats à des moments imprévisibles et attendent une validation immédiate. Gérer quatre ou cinq agents en même temps, ça veut dire être interrompu quatre ou cinq fois par du code que tu n’as pas écrit, mais que tu dois quand même valider.

« À chaque fois, tu te lances dans quelque chose, puis tu changes de tâche, tu reviens en arrière, et tu te perds », explique Guillaume. « C’était vraiment accablant. » Notre cerveau a aussi besoin de repos. La plupart des études montrent que notre cerveau suit un cycle ultradien : il peut fonctionner pendant 90 minutes, puis a besoin d’un peu de repos. Le codage des agents créait une pression infinie, sans aucune pause.
 

Le problème de confiance sous-jacent

La fatigue ne concerne pas seulement l’attention ; le problème plus important, c’est la responsabilité. Quand un agent écrit du code, c’est toujours l’ingénieur qui est responsable du résultat. Cette responsabilité ne suit pas la même évolutivité que la production.

« J’ai un peu de mal à faire confiance à ce système », explique Guillaume, « parce qu’il y a tellement de code généré que je ne suis même pas sûr que tout ce code soit correct ou qu’il fasse vraiment ce que je veux qu’il fasse. » 

La charge de révision augmente à chaque agent ajouté au processus. Réviser du code généré par l’IA, ce n’est pas la même chose que réviser le travail d’un collègue. Les réviseurs humains déduisent l’intention à partir du contexte et de la conversation. L’IA n’a aucune intention à clarifier. Sa production peut être syntaxiquement correcte, passer tous les tests, et pourtant résoudre le mauvais problème, car elle a fidèlement exécuté la consigne qu’elle a reçue, plutôt que celle que l’ingénieur avait l’intention de donner.

Certaines équipes ont réagi en ajoutant encore plus de processus : plus de points de contrôle, plus de relecteurs, plus d’étapes de validation. D’autres ont essayé d’automatiser la couche de relecture elle-même. Aucune de ces solutions ne résout complètement le problème, car celui-ci est structurel. Les outils ont été conçus pour la productivité individuelle. Les processus qui les entourent n’ont pas été repensés en conséquence.
 

Quand l’équipe s’en rend compte

Ce qui commence par un gain de productivité individuel peut vite devenir un goulot d’étranglement pour l’équipe.

Guillaume décrit une dynamique qu’il a vue se reproduire à maintes reprises : un ingénieur, très compétent avec les agents, produit du code à un rythme que le reste de l’équipe ne peut pas absorber. « Si tu avais un ingénieur comme ça, ça créerait beaucoup de problèmes pour les autres », dit-il. Cet ingénieur rapide ne fait rien de mal. Mais son rendement dépasse rapidement la capacité de l’équipe à relire, intégrer et exploiter ce code. Les goulots d’étranglement se déplacent alors de l’écriture du code vers sa relecture et sa validation,

« Ce qui a commencé par un simple manque d’outils se transforme en ressentiment entre les équipes, ce qui accentue les cloisonnements déjà existants », explique Guillaume, « et c’est bien plus difficile à réparer. »
 

Ce que ça nous apprend en réalité

La « fatigue de l’IA », bien comprise, n’est pas le signe que les outils sont trop puissants ou que leur adoption est allée trop loin. C’est le signe que l’infrastructure autour des outils n’a pas suivi le rythme. Les modèles se sont améliorés plus vite que les processus. Les capacités individuelles ont pris le pas sur la coordination au sein de l’équipe.

Guillaume propose une analogie simple : « Si tu veux acheter une nouvelle voiture, c’est soit parce que tu as un problème avec celle que tu as, soit parce que tu n’en as pas encore. » En d’autres termes, les équipes changent rarement leurs processus à moins que les actuels ne fonctionnent plus. La fatigue de l’IA, c’est ce signal. Elle t’indique que les processus existants ne correspondent plus à la façon dont les équipes modernes développent des logiciels.

La question pour les responsables techniques n’est pas de savoir s’il faut ralentir l’adoption de l’IA. Il s’agit plutôt de repenser le fonctionnement des équipes pour que les humains passent moins de temps à superviser les agents et plus de temps à résoudre des problèmes. C’est le travail que la plupart des équipes n’ont pas encore commencé – et c’est exactement ce pour quoi Upsun Dispatch™ a été conçu.