OpenAI, Anthropic et Google redoutent une question des directeurs techniques

Les fournisseurs d'outils d'IA pour développeurs, d'OpenAI et Anthropic à Google en passant par des dizaines de startups proposant des agents d'IA pour coder, ont un intérêt commun : que les vice-présidents de l'ingénierie ne posent jamais une question précise. Ce n'est pas « combien d'employés utilisent l'outil ? » ni « de combien le volume de code généré a-t-il augmenté ? ». Ce qu'ils redoutent vraiment, c'est la question « quels sont les résultats réels pour l'entreprise ? ».

L'adoption de l'IA dans le développement logiciel est bel et bien explosive. GitHub Copilot revendique des millions d'utilisateurs actifs. Cursor, Replit, Windsurf et des dizaines d'outils moins connus captent les budgets des équipes technologiques du monde entier. Selon des études sectorielles, plus de 70 % des développeurs des grandes entreprises utilisent déjà au moins un outil d'IA pour coder. Les analystes estiment que l'ensemble du marché des assistants d'IA pour développeurs dépassera 10 milliards de dollars d'ici 2027.

Mais derrière ces chiffres impressionnants se cache un vrai problème. La plupart des responsables de l'ingénierie mesurent des indicateurs d'usage, pas des résultats. Ils savent combien de développeurs ont activé une licence, combien de lignes de code l'IA a suggérées et ont été acceptées, et quel pourcentage de l'équipe « utilise activement » le produit. Mais ils ne vérifient pas si le délai de mise sur le marché des fonctionnalités a diminué, si les défauts en production ont reculé, si la dette technique a baissé ou si la vitesse de développement réelle a augmenté après l'adoption de l'IA. C'est un angle mort coûteux qui, soit dit en passant, arrange parfaitement les fournisseurs.

La raison de cet écart est claire : mesurer l'usage est facile, mesurer les résultats réels est extrêmement difficile. Pour évaluer l'impact véritable de l'IA sur la productivité d'une équipe, il faut des données de référence antérieures à l'adoption, des groupes témoins corrects, des définitions solides de la « productivité » (qui fait déjà l'objet de vifs débats dans la communauté de l'ingénierie) et du temps : au minimum plusieurs trimestres. Les fournisseurs tiennent au renouvellement des licences et aux témoignages de réussite flatteurs pour le marketing, pas à des études rigoureuses qui pourraient montrer un effet modeste, voire négatif, dans certains scénarios.

Les rares études indépendantes sur le sujet donnent des résultats contrastés. Les expériences de GitHub ont montré un gain de productivité de 55 % sur des tâches spécifiques, comme écrire un serveur HTTP à partir de zéro. D'autres études, notamment de METR et de laboratoires indépendants, ont relevé des chiffres nettement plus modestes ou averti que le gain de vitesse à l'écriture du code est souvent annulé par un temps de revue et de débogage accru pour le code généré par l'IA. La réalité dépend fortement du type de tâche, du niveau d'expérience de l'équipe et de la qualité de l'organisation du travail autour des outils.

Les agents d'IA de nouvelle génération posent un problème à part. Si les premiers outils comme Copilot fonctionnaient comme une saisie semi-automatique avancée, les agents de 2025-2026 prétendent exécuter des tâches entières de façon autonome : de l'écriture du code à la création de PR, en passant par une partie du CI/CD. Cela relève la mise : si vous ne pouvez pas mesurer le ROI d'un assistant d'IA basique, comment évaluerez-vous les résultats d'un agent semi-autonome ?

La conclusion principale est simple, mais gênante pour le marché : les responsables de l'ingénierie devraient cesser de mesurer l'usage et commencer à concevoir de vraies expériences aux résultats mesurables avant de signer des contrats à six chiffres pour des outils d'IA. Définissez les indicateurs à l'avance : cycle time, defect rate, PR review time, temps d'intégration des nouveaux développeurs. Comparez des équipes avec et sans l'outil, plutôt que de suivre la seule « satisfaction » générale. Les fournisseurs ne vous l'apprendront pas, faute d'incitation. Mais la capacité à poser la question qui dérange est ce qui distingue les dirigeants techniques qui améliorent réellement le travail de leurs équipes de ceux qui achètent simplement une impression de progrès.