Quand les mandats en matière d’IA manquent leur cible et que les développeurs en paient le prix

La déconnexion entre les dirigeants et les développeurs nuit à l’adoption de l’IA

À l’heure actuelle, de nombreuses entreprises déploient des outils d’IA sans vraiment comprendre ce qui se passe sur le terrain. Les dirigeants voient les avantages, la réduction des coûts, l’accélération des cycles de développement, l’innovation. C’est une bonne chose. Mais une enquête récente a mis en évidence un problème plus profond. Alors que 75 % des dirigeants estiment que leur mise en œuvre de l’IA est en bonne voie, seuls 45 % des employés sont de cet avis. Il s’agit là d’un écart important. Près de la moitié des dirigeants ont également admis que l’IA était en train de « déchirer leur entreprise ». Cela montre un réel décalage entre l’ambition des dirigeants et l’exécution opérationnelle.

Les développeurs de logiciels, qui sont les plus proches des outils, sont essentiellement contraints d’utiliser une IA qui ne correspond souvent pas à leur façon de travailler. Les outils sont poussés du haut vers le bas, sans suffisamment de contexte sur les véritables défis auxquels les développeurs sont confrontés : maintenir un code propre, éviter les échecs lors du déploiement, et contrôler la dette technique.

Vous ne pouvez pas y remédier en multipliant les tableaux de bord, le suivi de l’utilisation des outils ou les OKR exécutifs qui comptent le nombre de suggestions d’intelligence artificielle qui sont acceptées. Souvent, ces données ne vous disent pas ce qui est important. Ce qui compte, c’est l’impact, la valeur que l’outil apporte réellement au jour le jour. À moins que les équipes dirigeantes n’obtiennent une meilleure visibilité sur ce que vivent les ingénieurs de première ligne, l’adoption restera superficielle et frustrante pour les personnes sur lesquelles vous comptez pour développer votre produit.

Megan Morrone d’Axios l’a clairement exprimé : « Même les dirigeants qui croient que l’intégration de l’IA se fait en douceur transmettent des politiques et des outils à une main-d’œuvre qui est plus frustrée qu’eux. »

Le résultat ? Des initiatives en matière d’IA qui donnent l’impression de progresser sur le papier, mais qui échouent dans la pratique. L’IA ne transformera pas votre entreprise si vos développeurs ne sont pas convaincus qu’elle fonctionne aussi pour eux.

Les mandats malavisés en matière d’IA exacerbent la dette technique et nuisent à la qualité du code.

À l’heure actuelle, la plupart des assistants de code de l’IA ne sont bons qu’à une chose : la production. Mais la production n’est pas toujours synonyme de valeur. Les développeurs signalent que ces outils poussent souvent du code défectueux, suppriment la logique valide ou interprètent mal l’intention derrière ce qu’ils construisent. Cela ralentit les choses et cause des problèmes plus tard. La question n’est pas de savoir si l’IA peut écrire du code, elle le peut manifestement. Il s’agit de savoir si ce code tient la route en production sans perdre plus de temps en débogage, en correctifs et en remaniements.

Dans une enquête récente de Harness, 59 % des ingénieurs ont déclaré que les outils d’IA perturbent les déploiements au moins la moitié du temps. C’est un signal d’alarme. Les développeurs passent plus de temps à réparer ce que l’IA casse qu’à écrire du nouveau code. Environ deux tiers d’entre eux passent plus de temps à dépanner les bogues générés par l’IA, et 68 % déclarent qu’ils doivent faire face à davantage de vulnérabilités en matière de sécurité à cause de l’IA. Vous ne pouvez pas vous permettre d’introduire ce type d’instabilité dans votre pipeline de déploiement.

Les développeurs veulent des outils plus intelligents ; en fait, ils sont souvent les premiers à tester de nouvelles solutions. Mais lorsque le code généré par l’IA commence à créer plus de travail qu’il n’en économise, la productivité baisse, la frustration augmente et la qualité en prend un coup. Laisser un code défectueux en production augmente la dette technique à long terme. Elle s’accumule comme une dette financière, sauf que, dans ce cas, elle ralentit toutes les versions futures.

Si l’IA doit faire partie de votre flux de travail de développement, elle doit être mise en œuvre avec précision. Cela signifie des examens appropriés, un suivi solide des performances au niveau du système, et pas seulement des taux d’acceptation du code, et un leadership qui pose des questions d’adoption plus intelligentes : « Est-ce mieux que ce que nous avions ? » Si la réponse est négative, corrigez le problème avant de passer à l’échelle supérieure. Les mandats vagues ne vous feront pas avancer. C’est la qualité qui le fera.

L’enthousiasme excessif des cadres est motivé par le FOMO et les pressions liées à la réduction des coûts.

Une tendance se dessine actuellement dans les conseils d’administration : agir rapidement en matière d’IA ou perdre du terrain. Cette tendance est davantage motivée par la peur de prendre du retard que par la clarté stratégique. Le raisonnement est simple : automatiser les tâches répétitives, livrer plus vite, réduire la masse salariale. L’enthousiasme est logique. L’automatisation semble efficace sur le papier, en particulier lorsque vous êtes confronté à des chiffres d’effectifs et de budget. Mais cette approche crée des frictions internes lorsqu’elle est déployée sans comprendre les lacunes opérationnelles.

De nombreux dirigeants ne cachent pas les possibilités de réduction des coûts. Mark Zuckerberg chez Meta, Marc Benioff chez Salesforce et Matt Garman chez AWS ont tous évoqué le potentiel de l’IA à réduire les besoins en personnel. L’avantage commercial semble évident, mais seulement en surface. Si les outils ne peuvent pas fournir une qualité constante dans les flux de travail réels, l’absence de talents ne sera pas compensée par l’automatisation. Vous aurez toujours besoin de développeurs qualifiés pour surveiller, ajuster et optimiser ces systèmes.

Les données montrent pourquoi l’engouement a pris de l’ampleur. Dans l’enquête 2024 de Stack Overflow menée auprès de 65 000 développeurs, 81 % d’entre eux ont constaté une augmentation de leur productivité grâce aux outils de codage de l’IA. Par ailleurs, 58 % d’entre eux ont déclaré avoir constaté des gains d’efficacité. Cela semble impressionnant, et ça l’est. Mais ces avantages ne sont pas universels, et ils ne sont pas automatiques. Microsoft a indiqué que 77 000 entreprises avaient adopté GitHub Copilot depuis la fin de l’année 2021. Chez Y Combinator, l’associé directeur Jared Friedman a souligné que 25 % des startups de leur cohorte actuelle ont désormais des bases de code presque entièrement générées par l’IA. Cette ampleur de l’adoption crée une pression, et c’est à ce moment-là que le FOMO s’insinue dans la prise de décision.

L’adoption précipitée de l’IA parce que « tout le monde le fait » accroît le risque là où les entreprises pensent le réduire. La complexité de l’ingénierie, l’infrastructure existante et les normes de gouvernance varient d’une entreprise à l’autre. Ce qui fonctionne dans une entreprise ne se transfère pas automatiquement dans une autre. Les dirigeants doivent prendre de l’avance sur l’IA. Concentrez-vous sur l’alignement des valeurs, l’intégration des processus et les résultats réels.

Les développeurs font de moins en moins confiance aux outils d’IA en raison de leurs limites pratiques

L’enthousiasme initial autour des outils de codage de l’IA outils de codage de l’IA s’estompe rapidement. Les développeurs ont vraiment essayé ces outils. Maintenant que les données d’utilisation réelle sont disponibles, la confiance s’effrite. Dans l’enquête 2024 de Stack Overflow auprès des développeurs, le sentiment favorable est passé de 77 % en 2023 à 72 % cette année. Cette baisse est le signe de frictions sous la surface.

L’IA génère du code rapidement, mais lorsque vous travaillez sur des systèmes de production, la précision et la structure comptent plus que la vitesse. Les développeurs signalent des ralentissements lorsque ces outils interprètent mal le contexte, simplifient excessivement la logique ou ne parviennent pas à gérer des dépendances complexes. La correction des faiblesses de la production générée par l’IA ajoute des étapes supplémentaires avant la livraison. La qualité n’est pas un effet secondaire, elle doit être une priorité dès le départ.

Cette limitation se manifeste surtout lorsque les équipes changent d’échelle. Dans les projets impliquant une infrastructure en couches, des protocoles précis ou des exigences de fiabilité élevées, la marge d’erreur se réduit. « L’IA est très efficace pour générer du code pour des prototypes ou des fonctions peu complexes, mais lorsque vous parlez de systèmes de production, c’est là que toutes ces petites choses échouent », a déclaré Alejandro Castellano, cofondateur et PDG de Caddi. Et il a raison. L’IA ne gère tout simplement pas les cas limites de la même manière qu’un véritable ingénieur.

Pour les dirigeants, comprendre les limites de l’ensemble des outils fait partie d’une utilisation judicieuse. Si vos équipes constatent un plus grand nombre de révisions, d’attentes non satisfaites ou de reprises grâce à l’IA, alors les faux positifs coûtent cher en temps réel. Déployez l’IA de manière stratégique, là où elle améliore les résultats. Ne l’introduisez pas partout à moins que les performances ne justifient la décision. L’adoption ne signifie rien si elle n’augmente pas la base de référence. Concentrez-vous sur les résultats utiles.

L’autonomisation des développeurs permet une adoption plus efficace de l’IA que les mandats imposés d’en haut.

Les entreprises qui tirent de réels bénéfices de l’IA sont celles qui laissent les ingénieurs diriger. Lorsque les développeurs ont la liberté de choisir des outils adaptés à leur travail, l’adoption est plus rapide, la qualité s’améliore et les résistances internes s’estompent. La plupart des développeurs souhaitent simplement que l’IA soit utile. Le fait d’imposer des outils rigides et uniques élimine la flexibilité nécessaire pour y parvenir.

Chez ChargeLab, cette approche a fonctionné. L’entreprise n’a pas imposé d’outil d’IA spécifique à ses ingénieurs. Au lieu de cela, elle leur a donné accès à une gamme d’outils, GitHub Copilot, ChatGPT, Windsurf, Cursor, Claude, et les a laissés tester, affiner et décider par eux-mêmes. Le résultat ? Une augmentation de la productivité de 40 % au sein de l’équipe d’ingénieurs. Ehsan Mokhtari, directeur technique, a joué un rôle actif dans ce processus, en mettant la main à la pâte plutôt qu’en dictant ses choix à distance. Cette crédibilité est importante.

Simon Lau, responsable de l’ingénierie chez ChargeLab, a été clair : « Nous n’obligeons pas les développeurs à utiliser l’un ou l’autre outil. Nous leur donnons les moyens d’explorer ce qui leur convient le mieux ». C’est cet état d’esprit qui a permis un engagement total. L’IA n’a pas été vendue comme un raccourci, elle a été présentée comme une option conçue pour aider.

C’est ainsi que vous obtiendrez une adhésion durable. Les vrais problèmes d’ingénierie nécessitent un contexte pour être résolus. Lorsque les développeurs ont la possibilité de tester les outils en fonction de leur propre flux de travail, ils utilisent l’IA et améliorent la manière dont elle est utilisée. Et lorsque les chefs d’équipe, et non des dirigeants déconnectés, fixent des objectifs de performance pour l’adoption de l’IA, ces mesures reflètent le travail réellement effectué.

Les cadres qui veulent être leaders dans ce domaine doivent cesser d’optimiser la vitesse et le volume. Optimisez pour l’habilitation. Définissez la vision, fournissez les outils et donnez à vos équipes la liberté de trouver ce qui fonctionne. La pression du haut vers le bas est rarement le moteur de l’innovation. C’est l’exécution habilitée qui l’est.

Principaux faits marquants

• La déconnexion entre les dirigeants et les ingénieurs affaiblit l’impact de l’IA : Les dirigeants surestiment le succès de l’adoption de l’IA par rapport à leurs équipes, avec seulement 45% des employés qui reconnaissent que cela se passe bien. Donnez la priorité à un alignement plus profond avec les flux de travail de l’ingénierie pour vous assurer que les outils d’IA répondent aux besoins quotidiens réels.
• Les mandats médiocres augmentent la dette technique : L’utilisation forcée d’outils d’IA peu performants ajoute des erreurs, ralentit les déploiements et augmente les vulnérabilités en matière de sécurité. Les dirigeants devraient exiger des preuves d’efficacité avant d’étendre les intégrations d’IA.
• Le FOMO est à l’origine de déploiements risqués de l’IA : De nombreux dirigeants adoptent des outils de codage de l’IA pour rester compétitifs ou réduire les coûts, et non pas parce que les outils ont fait leurs preuves dans leurs cas d’utilisation. Fondez les investissements dans l’IA sur les résultats, et non sur les tendances, afin d’éviter les baisses de productivité et de qualité.
• La confiance des développeurs dans les outils d’IA diminue : Les opinions favorables à l’égard des outils d’IA diminuent à mesure que les performances réelles ne sont pas à la hauteur de l’engouement initial, en particulier pour les tâches complexes ou de production. Concentrez l’utilisation de l’IA sur les flux de travail pour lesquels les outils se sont avérés fiables, plutôt que de supposer une large applicabilité.
• L’habilitation l’emporte sur l’application : Les équipes sont plus performantes lorsqu’elles ont la liberté d’explorer et de choisir leurs outils d’IA avec le soutien de la direction. Laissez les ingénieurs diriger l’adoption de l’IA dans des limites stratégiques claires pour obtenir à la fois l’adhésion et de meilleurs résultats.