Pourquoi l’IA prête à l’emploi frustré les équipes — et que faire à ce sujet

Avec la plupart des technologies, plus vous les utilisez, plus vous vous y habituez calmement. Avec les outils d’IA, le contraire s’est avéré vrai : dans son sondage annuel de plus de 49 000 développeurs, Stack Overflow a enregistré une utilisation en constante augmentation, atteignant 84 %, tandis que la confiance dans l’exactitude de ces outils a chuté de 40 % à 29 % en l’espace d’une seule année.

Cet effet est familier pour moi. Notre première expérience avec les outils d’IA en développement n’avait rien en commun avec l’effet “wow” d’un travail plus rapide et d’une réduction de la monotonie que la presse technique décrivait. Nos développeurs ont été déçus : l’IA produisait un code médiocre qui prenait beaucoup de temps à examiner et qui, finalement, devait être réécrit. L’équipe s’attendait à ce que l’IA leur fasse gagner du temps, mais elle a obtenu du travail supplémentaire. Peu de temps après ces premières tentatives d’intégration des outils d’IA dans le flux de travail quotidien, l’équipe est revenue à ses anciennes méthodes.

Aujourd’hui, ces mêmes outils accélèrent à la fois la rédaction du code et son examen pour nos développeurs — non pas parce que nous avons trouvé un meilleur modèle, mais parce que nous avons changé notre façon de travailler avec lui. Voici ce qui nous a aidés à y arriver.

Pourquoi le code écrit par l’IA frustré les développeurs

L’IA s’appuie sur une énorme masse de code public provenant de tout Internet, et ce code est rarement exemplaire : sa qualité est moyenne, et le modèle reproduit cette moyenne.

Mais “moyen” n’est pas le plafond de ce qui est possible — c’est simplement ce que le modèle produit jusqu’à ce qu’il connaisse votre projet : ses conventions, sa structure de code, ses décisions architecturales. Dans un sondage de plus de 600 développeurs, Qodo a constaté que parmi ceux qui étaient insatisfaits de la qualité du code d’IA, 44 % l’attribuaient précisément à un manque de contexte. C’est ce qui maintient la sortie à un niveau médiocre.

La bonne nouvelle est que le contexte que l’IA reçoit est à peu près la seule variable que l’équipe contrôle complètement. La façon dont l’outil comprend le projet dépend non du modèle, mais de ce que vous lui fournissez.

La deuxième raison est mentale — la nature même du travail change. Lorsque l’IA écrit la majeure partie du code, l’acte principal du développeur n’est plus l’écriture, mais la vérification de ce qui a été généré : lire la solution de quelqu’un d’autre, peser les alternatives, décider ce qui est prêt à être livré. C’est une compétence différente de celle d’écrire du code soi-même, et pour quiconque aimait la partie rédaction, cela ne vient pas facilement.

Dans son rapport Octoverse 2025, GitHub décrit exactement ce changement : les développeurs qui sont allés le plus loin avec l’IA ne s’appellent plus “auteurs de code” et deviennent quelque chose de plus proche de “directeurs créatifs”, où la compétence clé est de diriger et de vérifier. Mais la route qui mène à ce rôle passe par des erreurs et des frustrations, jusqu’à ce qu’une personne voie le rendement dans son propre travail.

Ce qui transforme l’IA d’une source de frustration en un outil de travail

Lorsque notre équipe a commencé à utiliser l’IA, certains développeurs travaillaient avec Claude Code, d’autres essayaient OpenAI Codex, GitHub Copilot ou Gemini CLI, et chaque outil donnait un résultat différent. Lorsque nous avons décidé de mettre de l’ordre dans la façon dont l’équipe travaillait avec l’IA, la première chose que nous avons faite a été de nous mettre d’accord sur un outil unique.

Ceci n’est pas seulement notre pratique. Prenez l’histoire de l’équipe de Linear : jusqu’au début de 2026, ils fonctionnaient sur un principe “laissez chacun travailler comme il le souhaite”, et en janvier, la direction a abandonné cette approche et a fait passer tout le monde à une seule façon de travailler — en réduisant le choix à deux outils d’IA et en demandant aux développeurs d’écrire du code uniquement avec eux, et non à la main. Selon la société, la productivité moyenne a augmenté le mois suivant de 30 % en termes de fusions de PR et de 33 % en termes de tâches closes par ingénieur.

Cela étant dit, un outil partagé en soi ne améliore pas le code — il doit être configuré : des règles doivent être établies, comme un fichier de règles, qui indiquent comment écrire du code — quels approches suivre, ce à éviter. Ensuite, des compétences personnalisées sont nécessaires pour les tâches typiques de votre projet, afin que vous n’ayez pas à expliquer la même chose à plusieurs reprises. Et enfin, il est utile de pointer l’agent vers votre base de code existante : il analyse la façon dont le projet est écrit et produit du nouveau code dans le même style, plutôt que dans un style générique. Plus l’outil reçoit de contexte, moins vous avez à réécrire manuellement par la suite.

Mais la partie la plus difficile n’est pas technique. Le passage de l’auteur du code à son évaluateur ne se produit pas tout seul — cette transition a besoin d’aide. La voie la plus directe est la formation et la certification. Dans notre cas, par exemple, dix développeurs suivent un programme de partenariat avec le fournisseur de l’outil, tandis qu’à côté d’eux travaille une personne responsable de l’adoption, qui explique pourquoi l’outil a produit un résultat donné et comment le corriger.

Une fois que l’équipe travaille de manière coordonnée, un goulet d’étranglement reste — l’examen — et il vaut la peine de le renforcer avec l’IA. L’agent passe en revue chaque demande de tirage et prend en charge les éléments évidents : les erreurs de routine, le style, les répétitions, les failles de sécurité. L’examinateur humain n’a plus à regarder tout indistinctement, mais seulement l’architecture et les décisions critiques. L’effet est notable, même au sein des sociétés qui construisent ces outils : chez Anthropic, après l’introduction d’un tel agent, la part des demandes de tirage ayant reçu un examen substantiel a augmenté de 16 % à 54 %, et les ingénieurs n’étaient en désaccord avec moins de 1 % de ses commentaires.

Pour nous, cela a raccourci un cycle d’examen qui s’étendait sur deux ou trois jours et plusieurs tours, et a soulagé les ingénieurs seniors de la routine, leur laissant les points vraiment difficiles. Une fois que l’outil a finalement commencé à produire des résultats qui n’avaient pas besoin d’être réécrits, la confiance en lui est apparue.

Où la confiance dans les outils d’IA porte ses fruits

Tout d’abord et avant tout — dans la rédaction du code : lorsque l’outil connaît le projet et que l’agent gère la première revue, l’équipe écrit plus et mieux, dans le même laps de temps. Dans notre cas, les outils d’IA ont accéléré le travail d’environ 30-40 %.

Au-delà de cela, l’IA a facilité l’intégration. Lorsqu’un nouveau membre rejoint un projet, quelqu’un d’expérimenté doit généralement répondre à des dizaines de questions sur la façon dont le code du projet est structuré. Maintenant, l’agent prend ce rôle : si le projet est bien documenté, le nouveau membre dirige jusqu’à 95 % de ces questions vers lui, plutôt que vers les collègues.

C’est une histoire similaire avec la documentation : un brouillon architectural grossier qui prenait auparavant des heures est maintenant, pour la plupart, écrit par l’agent lui-même — selon nos estimations, environ 80 % du brouillon, si vous lui donnez suffisamment de contexte. Ce qui reste à l’humain, c’est ce qui n’est pas dans le référentiel — les décisions, les compromis, l’expertise.

Il est tout aussi important d’être honnête sur les limites de ce que l’IA peut faire, car ce sont les attentes gonflées qui engendrent la déception dans un premier temps. L’IA ne prend pas en charge la conformité — un humain signe les données médicales ou financières, et la société, et non le modèle, est responsable en cas de fuite. Elle n’accélère pas non plus les intégrations avec les partenaires, où des dizaines d’heures sont consacrées aux appels et à la coordination.

L’IA prête à l’emploi est vraiment irritante — mais seulement lorsqu’elle est utilisée comme une solution terminée. La différence entre la frustration et le rendement réside dans ce que vous construisez autour d’elle : une norme partagée, le contexte de votre projet et le nouveau rôle du développeur.