Introduction ‒ Idées reçues et réalité sur la productivité des développeurs avec l’IA
- Mark Zuckerberg (CEO de Meta) a déclaré vouloir « remplacer tous les ingénieurs de niveau intermédiaire par l’IA d’ici fin 2025 », mettant les CTO des différentes entreprises sous la même pression.
- L’intervenant affirme clairement que « l’IA ne peut pas remplacer totalement les développeurs » et souligne que l’adoption de l’IA aide clairement la productivité, mais pas toujours, et qu’il n’est pas rare qu’elle fasse au contraire baisser la productivité.
Conception de l’étude et données
- Mesures réalisées sur 3 ans, auprès de plus de 600 entreprises, plus de 100 000 ingénieurs logiciel, plus d’un milliard de lignes de code et plusieurs dizaines de millions de commits.
- Les données proviennent majoritairement de dépôts privés (private repos), ce qui permet de mesurer les variations réelles de productivité au niveau des équipes de développement et des entreprises.
Limites des études existantes
- Les rapports pilotés par les éditeurs servent souvent à promouvoir leurs propres outils d’IA, avec un manque d’objectivité.
- Le simple nombre de commits/PR, ou l’évolution du temps moyen de travail, peut déformer la productivité réelle.
- Exemple : juste après l’usage de l’IA, les commits liés à des bugs ou à de la reprise de travail (rework) augmentent aussi, donnant seulement en apparence l’impression d’une hausse de productivité.
- Dans les « expériences greenfield (nouveaux projets) », l’effet de l’IA paraît très important, mais l’écart se réduit sur du code existant (brownfield).
- Les enquêtes déclaratives auprès des développeurs (self-report) ont peu de corrélation avec la productivité réelle (plus de 30 points d’écart entre ressenti et réalité).
Modèle de mesure de la productivité de Stanford
- Utilisation d’un modèle automatisé basé sur l’IA proche d’une évaluation par un panel d’experts :
- mesure, pour chaque commit, des changements fonctionnels (added/removed/refactored/rework)
- l’accent n’est pas mis sur le simple « nombre de lignes », mais sur « la fonctionnalité, la maintenabilité et la qualité »
- Analyse fine du volume de fonctionnalités introduites, du refactoring et de la part de corrections ultérieures (rework) dans les commits récents.
Principaux résultats de l’étude
- Globalement, l’adoption de l’IA augmente la productivité moyenne de 15 à 20 %.
- Mais une part importante de « reprise de travail » (rework) l’accompagne, ce qui tend aussi à exagérer le bénéfice perçu.
- Il existe de fortes variations selon les équipes, les entreprises et les types de tâches.
Origines des écarts de productivité : difficulté des tâches, type de projet, langage, taille de la base de code
| Type de projet | Faible complexité | Forte complexité |
|---|---|---|
| Greenfield (nouveau) | 30~40 % ↑ | 10~15 % ↑ |
| Brownfield (existant) | 15~20 % ↑ | 0~10 % ↑ |
- L’effet de l’IA est important sur les projets nouveaux (greenfield) à faible complexité.
- Sur des systèmes existants (brownfield) et complexes, l’effet diminue nettement, et dans certains cas, des baisses de productivité ont aussi été observées.
- D’après l’échantillon mentionné dans la présentation : 136 équipes issues de 27 entreprises.
Popularité des langages et effet de l’IA
- Sur Python/Java/JavaScript (langages populaires), le gain de productivité apporté par l’IA est important,
- tandis que sur COBOL/Elixir/Haskell (langages peu populaires), l’IA n’aide presque pas, et peut même faire perdre du temps et dégrader la productivité sur des tâches complexes.
- Exemple : dans le cas d’un langage peu populaire et d’une difficulté élevée, « beaucoup d’erreurs, incapacité à produire un code correct » → mieux vaut ne pas l’utiliser.
Taille de la base de code et effet de l’IA
- Plus la base de code est grande, plus l’effet positif de l’IA sur la productivité diminue fortement.
- Causes :
- limites de la fenêtre de contexte : un LLM ne peut pas intégrer tout le contexte de plusieurs fichiers ou de centaines de milliers à plusieurs millions de lignes ;
- baisse du « ratio signal/bruit » : plus le volume de contexte augmente, plus l’IA identifie mal les informations pertinentes ;
- la multiplication des complexités métier et des services accroît la difficulté réelle de réimplémentation
- En pratique, pour les grands LLM récents (comme Gemini 1.5 Pro), la précision chute brutalement de 90 % à moins de 50 % à mesure que le « nombre de tokens » augmente.
- Causes :
En résumé : quand l’IA est-elle efficace ?
- Dans la plupart des cas, l’IA améliore clairement la productivité des développeurs, surtout pour l’écriture de code nouveau et simple.
- Mais dans des environnements avec maintenance complexe, ancien code (volumineux), langages de niche et nombreuses dépendances, ses limites sont importantes,
- et la meilleure stratégie de productivité avec l’IA doit être conçue avec soin selon les caractéristiques de l’entreprise, de l’équipe et de la tâche (ce n’est pas du « one size fits all »).
- Les enquêtes, les métriques marketing et la simple hausse du nombre de commits sont peu fiables ; il faut des mesures réalistes fondées sur la fonctionnalité réelle du code, la part de travail répétitif et le volume de reprise de travail.
Commentaires et cas complémentaires
- « Ingénieur fantôme » : les données ont aussi révélé que 10 % des ingénieurs ne travaillaient presque pas tout en percevant leur salaire.
- L’accent est mis sur la nécessité d’outils d’aide à la décision pilotés par les métriques pour permettre aux leads et CTO de diagnostiquer rapidement les vrais problèmes.
Conclusion
- L’IA augmente la productivité dans « la majorité des situations », mais il faut se méfier autant de sa surestimation que de sa sous-estimation.
- Il faut identifier les conditions concrètes où l’adoption fonctionne bien — tâches simples, projets nouveaux, langages populaires, petite base de code — et l’appliquer en conséquence ; un déploiement non critique et indiscriminé peut au contraire produire des effets négatifs.
2 commentaires
Même sans l’appliquer au logiciel principal, l’IA fait gagner énormément de temps dans les programmes de test ou au démarrage d’un projet.
Même en mettant de côté le fait qu’elle puisse écrire du code, je pense que les fonctions d’assistant ont changé du tout au tout depuis l’adoption de l’IA. À mon avis, nous sommes désormais dans une époque où l’IA n’est plus une option, mais une nécessité.
En pratique, c’est très utile pour un MVP. En particulier pour les commentaires, le logging et la rédaction de l’historique, je pense qu’il faut l’utiliser systématiquement.
En revanche, quand la base de code grossit, il y a des hallucinations, l’outil oublie le code existant et produit des résultats étranges. Il faut réfléchir à l’usage du context engineering ou à des moyens de réduire la taille de la base de code.
Je pense que ça s’améliorerait si on pouvait utiliser des prompts plus grands.
Pour l’instant, ça semble bien fonctionner avec Java, Python, JavaScript et Go. J’utilise surtout Copilot, ainsi que Claude et ChatGPT.