Les développeurs en ont assez des outils IA imposés

Déconnexion entre les dirigeants et les développeurs sur l’adoption de l’IA

La plupart des dirigeants sont optimistes à l’égard de l’IA. C’est normal et, dans une certaine mesure, justifié. La promesse est claire : de meilleures performances, des livraisons plus rapides, des coûts réduits. Mais lorsque près de la moitié des employés affirment que l’IA ne fonctionne pas pour eux, vous avez là un véritable signal qui mérite qu’on s’y intéresse.

Selon des données récentes rapportées par Axios, 75 % des dirigeants d’entreprise pensent que le déploiement de l’IA a été une réussite. Mais seuls 45 % des employés sont de cet avis. Il s’agit là d’un écart considérable. Cela signifie que vous pourriez être en train de mettre à l’échelle des outils qui ralentissent les gens ou ajoutent des frictions. Dans le domaine de l’ingénierie en particulier, les mandats d’IA imposés d’en haut mandats en matière d’IA n’aboutissent pas. Les développeurs se voient confier des outils qui ne correspondent pas à leurs flux de travail ou qui ne résolvent pas leurs problèmes réels. Ce n’est pas de la productivité, c’est du bruit.

Nous n’optimiserons pas l’adoption de l’IA si les politiques sont rédigées dans les salles de conférence sans l’apport de ceux qui font le travail pratique. Maintenir les attentes en matière de performances tout en ne dotant pas les équipes d’outils utiles et adaptés au contexte est un moyen rapide de perdre des talents précieux ou, pire encore, de livrer du mauvais code.

Si vous êtes dans la suite du PDG, voici la solution : combler le fossé. Passez du temps à comprendre comment travaillent vos équipes d’ingénieurs. Demandez-leur ce qui ne va pas et écoutez ce qu’ils ont à vous dire. Laissez vos développeurs participer à la stratégie. Ce n’est qu’ainsi que vous obtiendrez les avantages réels de l’IA à grande échelle.

La pression concurrentielle favorise l’adoption de l’IA malgré les difficultés de mise en œuvre

La vitesse est importante. Cela ne fait aucun doute. Mais aller vite sans contrôle n’est pas du leadership, c’est de la réaction. De nombreuses organisations cherchent à adopter l’IA parce qu’elles se sentent obligées de le faire, et non parce qu’elles sont prêtes. Pas parce qu’elles sont prêtes.

Les dirigeants d’entreprises telles que Meta, Salesforce et AWS affirment ouvertement que l’IA réduit le besoin d’équipes de développement importantes. Ce n’est pas subtil. Le rapport coût-efficacité est séduisant, c’est évident. Mais la réduction des coûts n’est pas une stratégie. C’est un sous-produit d’une bonne action.

Copilot de GitHub a été adopté par 77 000 organisations depuis fin 2021. Microsoft a fait part de ces chiffres dans ses résultats du quatrième trimestre. Il ne s’agit pas d’un battage médiatique. C’est en train de se produire. Et à Y Combinator, 25 % des startups de la cohorte actuelle construisent des produits avec du code généré par l’IA comme base. Elles ne font pas que tâtonner, elles misent sur cette technologie pour l’ensemble de leur pile d’ingénierie.

Simon Lau, directeur de l’ingénierie chez ChargeLab, l’a clairement résumé : si vos concurrents utilisent l’IA et pas vous, vous êtes à la traîne. Telle est la réalité aujourd’hui. Alors oui, les dirigeants intelligents agissent rapidement. Mais la vitesse sans conception crée de la complexité. Et trop de complexité tue l’élan.

Adoptez l’IA, mais faites-le avec clarté. Sachez ce que vous cherchez à résoudre. Se contenter de courir après la technologie ne sert à rien, c’est une mise en œuvre ciblée qui le fera. Assurez-vous que vos équipes sont réellement équipées pour réussir avec les outils, et qu’on ne s’attend pas simplement à ce qu’elles les utilisent. C’est ainsi que vous resterez compétitif sans épuiser vos effectifs en cours de route.

Baisse de confiance des développeurs en raison des limitations techniques

Les outils d’IA sont utiles. Mais ils ne sont pas magiques. Et ils ne sont certainement pas infaillibles. Les équipes d’ingénieurs s’en rendent compte rapidement. Il y a un point où la promesse rencontre la réalité, et la réalité est que les outils de codage de l’IA d’aujourd’hui ont encore besoin de beaucoup d’aide. Les outils de codage de l’IA d’aujourd’hui ont encore besoin de beaucoup d’aide.

Il suffit de regarder les chiffres. Dans l’enquête 2024 de Stack Overflow menée auprès de 65 000 développeurs, 81 % d’entre eux ont déclaré que les outils d’IA amélioraient leur productivité, et 58 % ont fait état d’une efficacité accrue. C’est un bon titre. Mais regardez de plus près. Une étude Harness distincte a montré que 67 % des responsables de l’ingénierie passent désormais plus de temps à déboguer le code généré par l’IA qu’auparavant. 59 % déclarent que les outils d’IA perturbent les déploiements la moitié du temps ou plus. Pire encore, 68 % déclarent passer plus de temps à résoudre les problèmes de sécurité introduits par le code généré par l’IA.

Le schéma est cohérent : Les outils d’IA produisent davantage de code, mais il s’agit trop souvent d’un code erroné. Les développeurs doivent encore revérifier les résultats. Ils doivent combler les lacunes. Et lorsque les systèmes sont mis en production, la surface d’échec augmente. La dette technique s’accumule rapidement lorsque la logique invalide passe sans être testée.

C’est là que la confiance des développeurs commence à s’effriter. Lorsque les outils ne sont pas adaptés, les gens cessent de les utiliser. Ou pire, ils les utilisent à contrecœur et passent plus de temps à nettoyer qu’à coder.

Si vos équipes signalent davantage de bogues, des déploiements plus lents ou des cycles d’assurance qualité supplémentaires, écoutez attentivement. Ne partez pas du principe qu’une production plus importante est synonyme de progrès. Un volume élevé n’est pas synonyme de valeur élevée. Les dirigeants doivent privilégier la qualité plutôt que l’activité. Développez les outils qui réduisent réellement la complexité, et non ceux qui ne font qu’en générer davantage.

Les mandats axés sur les mesures d’utilisation de l’IA sont contre-productifs

Les indicateurs sont importants. Mais toutes ne sont pas significatives. À l’heure actuelle, trop de dirigeants mesurent l’adoption de l’IA sur la base d’indicateurs superficiels, de taux d’acceptation du code, de la fréquence d’utilisation de l’IA ou du nombre total de lignes de code générées par l’IA. Ces mesures ne disent rien sur l’utilité des outils.

Les développeurs sont intelligents. Ils savent quand un outil n’améliore pas réellement leur travail. Et lorsque les dirigeants commencent à proposer des tableaux de bord qui récompensent une utilisation superficielle, le message est clair : utilisez l’outil, quoi qu’il arrive. Même s’il casse des choses ou vous ralentit. Cela tue le moral et se traduit par une ingénierie médiocre.

De nombreux développeurs se sont déjà exprimés. Certains déclarent être suivis par des mises à jour hebdomadaires ou même des classements de leur utilisation de l’IA. Ce n’est pas un signe de réussite, c’est un signal d’alarme. Lorsque la contribution individuelle est jugée en fonction de la fréquence d’utilisation d’un outil défectueux, vous n’améliorez pas les performances. Vous ne faites que l’imposer.

La plupart de ces mandats proviennent de l’extérieur de l’organisation d’ingénierie. Les dirigeants imposent souvent des OKR ou des objectifs d’utilisation sans avoir une compréhension fonctionnelle des outils ou de leur impact. Ce manque de compréhension crée des frictions. Elle transforme l’IA d’un atout en une obligation.

Les dirigeants doivent prendre du recul et réévaluer ce qu’ils encouragent. L’objectif n’est pas d’utiliser davantage l’IA. L’objectif est d’améliorer le code, de produire des résultats plus propres et d’accroître la fiabilité. La bonne question n’est pas « À quelle fréquence utilisons-nous l’IA ? ». C’est « Est-ce que cela améliore le travail, le rend plus rapide ou plus sûr ? » Si ce n’est pas le cas, la mesure n’a pas d’importance.

L’autonomisation des développeurs favorise l’adoption de l’IA

Les outils d’IA n’échouent pas à cause de leur technologie, mais à cause de la manière dont ils sont introduits. Lorsqu’on dit aux développeurs quels outils utiliser, comment les utiliser et quand les utiliser sans les associer à la décision, l’adoption s’effondre.

ChargeLab a abordé cette question différemment, et cela a fonctionné. Son équipe d’ingénieurs, dirigée par le directeur technique Ehsan Mokhtari et le responsable de l’ingénierie Simon Lau, a évité les mandats trop lourds. Ils n’ont pas imposé un outil d’IA spécifique à l’ensemble de l’équipe. Au contraire, ils ont laissé aux développeurs la possibilité d’expérimenter. Chaque ingénieur était libre de choisir ce qui convenait le mieux à ses tâches, qu’il s’agisse de Copilote GitHubWindsurf, ChatGPT, Claude ou Cursor. Le résultat ? Les 40 développeurs de l’entreprise utilisent désormais quotidiennement des outils de codage IA, et une enquête interne a révélé une augmentation de la productivité d’environ 40 %.

C’est ainsi que vous obtiendrez une véritable adoption. Donnez aux techniciens l’autonomie nécessaire pour adapter les outils à leur propre contexte. Laissez-les diriger dans leur domaine. Il s’avère qu’ils savent ce qu’ils font. Ils savent aussi quand quelque chose est utile et quand ça ne l’est pas.

Rajesh Jethwa, directeur technique de Digiterre, l’a dit clairement : « Les personnes les plus proches des problèmes sont celles qui ont tout le contexte, et le contexte est ce qui compte vraiment lorsqu’il s’agit d’outils d’IA. » C’est un principe qui mérite d’être suivi. Si vos développeurs n’ont pas la liberté de déterminer comment l’IA s’intègre dans leur pile, vous en freinez l’impact.

Si votre objectif est d’accroître l’efficacité, d’améliorer le rendement et de renforcer l’alignement de l’équipe, commencez par laisser les développeurs définir les moyens d’y parvenir. Le soutien de la hiérarchie est important. Mais lorsque ce soutien s’accompagne de confiance et de flexibilité, cela fonctionne réellement.

La nécessité d’un alignement culturel plutôt que d’une mise en œuvre énergique

Ce n’est pas en imposant l’IA aux équipes que vous obtiendrez des gains à long terme. Le progrès découle de l’alignement. Un leadership qui comprend comment les équipes d’ingénieurs opèrent sur le terrain produit de meilleurs résultats.

Chez ChargeLab, Mokhtari ne s’est pas contenté d’autoriser l’adoption de l’IA, il s’est engagé directement avec les outils. Il a construit sa crédibilité en comprenant ce à quoi les développeurs avaient affaire. C’est important. Les développeurs respectent les dirigeants prêts à consacrer du temps aux outils, et pas seulement aux rapports. Mokhtari a également fixé un objectif clair pour l’entreprise, à savoir économiser un million de dollars grâce à une utilisation efficace de l’IA, mais il a laissé à chaque équipe la possibilité d’assurer sa propre réussite, sur la base de son travail. Voilà ce qu’est un leadership intelligent : définir la destination, mais laisser de la place à l’autonomie tactique.

Ce type d’approche culturelle n’est pas le fruit du hasard. Il est le fruit d’une volonté délibérée des dirigeants. Pas avec des slogans ou des listes de contrôle, mais en créant un environnement où les gens peuvent tester, itérer et partager ce qui fonctionne.

Comme l’a souligné Mokhtari : « Vous ne pouvez pas vraiment tirer les gens vers l’avant et les rendre innovants. Vous devez favoriser la culture. » Cela signifie qu’il faut donner aux équipes les bons outils, mais aussi les bonnes conditions, le temps, l’espace et la confiance interne. Lorsque les développeurs se sentent impliqués dans le processus, ils contribuent plus intelligemment et l’IA ajoute de la valeur sans friction.

Pour les cadres, voici ce qu’il faut savoir : la culture est évolutive. Les mandats ne le sont pas. Si vous voulez que l’IA stimule les performances de votre organisation, commencez par les personnes qui construisent l’avenir que vous souhaitez. Tout le reste suivra.

Principaux faits marquants

• Le désalignement affaiblit l’impact de l’IA : Les dirigeants considèrent que les déploiements de l’IA sont réussis, mais près de la moitié des développeurs ne sont pas d’accord. Pour éviter les frictions opérationnelles, les dirigeants doivent aligner leur stratégie sur les besoins et les retours d’information des ingénieurs sur le terrain.
• L’adoption sous pression risque d’être vouée à l’échec : Les entreprises qui accélèrent l’adoption de l’IA par crainte de prendre du retard négligent souvent la préparation et la qualité de l’exécution. Les dirigeants devraient se concentrer sur une mise en œuvre structurée, et pas seulement sur l’urgence concurrentielle.
• La confiance des développeurs dans l’IA s’estompe : Les erreurs fréquentes, le débogage fastidieux et les problèmes de sécurité croissants des outils d’IA érodent la confiance des développeurs. Les dirigeants devraient donner la priorité à la fiabilité des outils et à leur adaptation à des flux de travail complexes avant de passer à l’échelle supérieure.
• Les mesures d’utilisation ne sont pas synonymes de valeur : Le suivi de l’utilisation de l’IA par le biais du volume de code et des taux d’acceptation ne tient pas compte de l’utilité réelle des outils. Les dirigeants devraient abandonner les mesures de vanité au profit d’une évaluation basée sur l’impact qui reflète la qualité du code et les gains d’efficacité réels.
• L’autonomie favorise l’adoption : Les équipes à qui l’on fait confiance pour choisir et expérimenter leurs propres outils d’IA font état d’une adoption plus forte et de gains de productivité mesurables. Les dirigeants devraient permettre aux équipes d’adapter l’intégration de l’IA à leurs flux de travail.
• La culture l’emporte sur le contrôle dans les déploiements de l’IA : Les mandats émanant de dirigeants déconnectés échouent, tandis que les environnements ouverts et fondés sur la confiance favorisent l’engagement et l’innovation. Les dirigeants devraient investir dans la culture, la collaboration et des objectifs clairs mais flexibles pour obtenir des résultats durables.