Tout le monde adopte l'IA. Personne ne parle de l'épuisement qui suit.

Vous utilisez GitHub Copilot depuis six mois. Vous êtes plus lent qu'avant.

Ce n'est pas une hypothèse. C'est ce que des centaines de développeurs rapportent discrètement, dans des forums spécialisés, des groupes Slack et des billets de blog confidentiels. On leur a vendu une promesse de productivité. Ils ont récolté une charge cognitive supplémentaire. Et personne, dans les grandes annonces corporate, ne semble vouloir en parler.

La fatigue des développeurs face à l'IA est réelle, documentée, et en train de remodeler silencieusement la façon dont les équipes techniques fonctionnent. Comprendre ce phénomène, c'est comprendre pourquoi l'adoption d'un outil ne garantit jamais son utilité.

Quand l'assistant devient le problème

L'idée de départ était séduisante : intégrer une IA directement dans l'environnement de développement pour suggérer du code, compléter des fonctions, détecter des erreurs. GitHub Copilot, Cursor, Tabnine, Amazon CodeWhisperer — les outils se sont multipliés à une vitesse remarquable. Les entreprises ont investi. Les équipes ont suivi.

Mais quelque chose s'est grippé en chemin.

Le problème n'est pas que ces outils sont mauvais. C'est qu'ils exigent un nouveau type d'attention que personne n'avait anticipé. Chaque suggestion de code doit être évaluée, validée, corrigée ou rejetée. Ce processus de vérification permanente, multiplié par des dizaines d'interactions quotidiennes, crée ce que les chercheurs en ergonomie cognitive appellent une charge de supervision continue.

En termes simples : votre cerveau ne se repose plus. Il arbitre.

Le paradoxe de l'automatisation partielle

Il existe un principe bien établi en psychologie du travail : les automatisations partielles sont souvent plus épuisantes que l'absence d'automatisation. Pourquoi ? Parce qu'elles ne suppriment pas la responsabilité — elles la déplacent.

Avant Copilot, un développeur écrivait une fonction. Il la pensait, la construisait, la testait. Le processus était linéaire et mental. Avec Copilot, il reçoit une proposition. Il doit maintenant :

• Lire et comprendre du code qu'il n'a pas écrit
• Évaluer s'il correspond vraiment à son intention
• Détecter les erreurs subtiles ou les failles de sécurité
• Décider d'accepter, modifier ou ignorer
• Reformuler son prompt si la suggestion est hors cible

Ce n'est plus de la programmation. C'est de la gestion d'un collaborateur imprévisible qui produit beaucoup, vite, et parfois très mal.

Les signaux concrets que les équipes ignorent

Les manifestations de cette fatigue sont reconnaissables, même si elles sont rarement nommées ainsi :

Le syndrome du "juste vérifier"

Des développeurs rapportent passer plus de temps à auditer le code généré par l'IA qu'il ne leur en aurait fallu pour l'écrire eux-mêmes. Ce temps invisible ne figure dans aucun tableau de bord de productivité.

La perte de confiance en soi

Plusieurs études qualitatives menées dans des équipes d'ingénierie ont mis en évidence un phénomène troublant : les développeurs juniors, exposés trop tôt aux suggestions d'IA, perdent confiance en leur propre raisonnement. Ils ne savent plus distinguer ce qu'ils savent de ce que l'IA leur a dit de faire.

La fragmentation de la concentration

Le travail en profondeur — ce que Cal Newport appelle le deep work — est incompatible avec des interruptions constantes. Or, chaque suggestion d'IA est une micro-interruption. Sur une journée, ces micro-interruptions accumulent une dette attentionnelle considérable.

Ce que les entreprises font faux

La plupart des organisations ont adopté les outils d'IA générative comme elles adoptent n'importe quel logiciel : déploiement global, formation minimale, indicateurs de succès flous. On mesure le nombre de lignes de code générées. On ne mesure jamais le niveau d'épuisement des équipes.

Cette approche ignore un fait fondamental : un outil puissant mal intégré nuit plus qu'il n'aide. L'introduction d'une IA dans un flux de travail complexe nécessite une réflexion sur les rôles, les moments d'utilisation et les limites explicites d'autonomie accordées à l'outil.

Les équipes qui s'en sortent le mieux ne sont pas celles qui utilisent le plus l'IA. Ce sont celles qui ont défini quand ne pas l'utiliser.

Retrouver le contrôle sans rejeter les outils

La réponse à cette fatigue n'est pas le rejet de l'IA. C'est une relation plus consciente avec elle. Concrètement, cela passe par :

• Des zones sanctuarisées : des plages horaires sans assistance IA, dédiées à la réflexion pure et à la résolution de problèmes complexes
• Une utilisation ciblée : réserver les outils d'IA aux tâches répétitives et à faible valeur cognitive, pas à l'architecture ou à la logique critique
• Une culture de la revue honnête : normaliser le fait de signaler quand un outil ralentit plutôt qu'il n'accélère

La vraie question que personne ne pose

Au fond, la fatigue des développeurs face à l'IA révèle quelque chose de plus profond sur notre rapport à la technologie : nous confondons adoption et bénéfice. Utiliser un outil n'est pas en soi une preuve d'efficacité. C'est un point de départ, pas une destination.

Les développeurs qui expriment cette fatigue ne sont pas des résistants au changement. Ce sont des professionnels suffisamment lucides pour identifier quand une promesse ne tient pas ses engagements. Et cette lucidité, à l'heure où les entreprises déploient des outils d'IA à marche forcée, est peut-être la compétence la plus sous-estimée du secteur.

L'IA ne fatigue pas les développeurs. C'est l'illusion qu'elle supprime le travail de penser qui les épuise.

— Reservoir Live