Les assistants de codage IA sont partout. Ils complètent automatiquement vos fonctions, rédigent vos pull requests et promettent de rendre chaque développeur dix fois plus productif. Mais il y a un secret peu reluisant derrière le battage médiatique : les personnes qui entraînent ces modèles à écrire du code ne sont pas, par conception économique structurelle, celles qui maîtrisent le mieux l’écriture de code. La rédaction a soulevé ce point, et c’est l’une de ces observations qu’on ne peut plus ignorer une fois qu’on y réfléchit vraiment.
Le problème des données d’entraînement IA pour le codage n’est pas un bug. C’est un modèle économique.
Les personnes qui apprennent à l’IA à coder
Entraîner une IA à bien écrire du code nécessite un processus appelé RLHFUn processus d'apprentissage automatique où les modèles d'IA apprennent des retours humains sur leurs sorties, leur apprenant quelles réponses privilégier ou refuser. : apprentissage par renforcement à partir du retour humain. En termes simples, des évaluateurs humains examinent le code produit par l’IA, classent les versions selon leur qualité, signalent les erreurs et rédigent des exemples de solutions. L’IA apprend à partir de ces classements. La qualité de ces classements détermine la qualité de l’IA.
Qui sont donc ces évaluateurs ? Selon les offres d’emploi suivies par des analystes du secteur, les missions d’annotation d’entrée de gamme sur des plateformes comme Remotasks ou Outlier paient entre 15 et 30 $ de l’heure en tant que travail indépendant. Les tâches de codage spécialisées sont mieux rémunérées : DataAnnotation.tech propose environ 40 $ de l’heure et Outlier paie jusqu’à 60 $ de l’heure pour certaines tâches techniques.
Cela semble raisonnable jusqu’à ce qu’on compare avec ce que gagnent vraiment les bons développeurs. Le Bureau américain des statistiques du travail indique que le salaire médian d’un développeur logiciel était de 133 080 $ en 2024. Dans les grandes entreprises technologiques, la rémunération totale des ingénieurs de niveau intermédiaire dépasse régulièrement 250 000 $ en comptant les actions et les primes, soit environ 120 $ de l’heure, avec couverture sociale complète, sécurité de l’emploi et perspectives d’évolution.
Pourquoi un développeur gagnant ce type de salaire passerait-il ses soirées à faire du travail à la pièce sur une plateforme de gig pour une fraction de cette rémunération ? La réponse est, sans surprise, qu’il ne le ferait pas.
Qui fait vraiment ce travail
La majeure partie du travail d’entraînement de l’IA n’est pas réalisée par des ingénieurs seniors à San Francisco. Elle est effectuée par des travailleurs du Sud global, souvent dans des conditions décrites comme exploitatives. La Banque mondiale estime qu’il existe entre 150 et 430 millions de travailleurs des données dans le monde, dont la grande majorité opère dans des pays comme le Kenya, les Philippines, l’Inde et le Venezuela.
Une enquête de CBS News 60 Minutes a révélé que les travailleurs kényans spécialisés dans les données IA gagnent entre 1,50 et 2 $ de l’heure. Des documents examinés par l’émission montrent qu’OpenAI avait accepté de payer 12,50 $ de l’heure par travailleur à la société de sous-traitance SAMA, mais que les travailleurs eux-mêmes ne recevaient que 2 $. Aux Philippines, une enquête du Washington Post a révélé que Scale AI retardait ou retenait régulièrement les paiements de travailleurs qui gagnaient souvent bien en deçà du salaire minimum local. Sur 36 travailleurs interrogés, 34 ont signalé des problèmes de paiement.
Rest of World a documenté que les taux de rémunération de Scale AI varient considérablement selon les régions : 21,55 $ de l’heure pour les tâches en langue allemande contre 1,43 $ pour le télougou. Ce ne sont pas des emplois différents. Les descriptions de tâches sont identiques.
Voilà qui constitue la main-d’œuvre qui apprend à l’IA à coder. Pas les architectes seniors qui comprennent la conception de systèmes. Pas les ingénieurs confirmés qui ont passé des années à comprendre pourquoi certains modèles échouent à grande échelle. Les personnes qui entraînent l’IA sont, par nécessité économique, celles qui ne peuvent pas obtenir une meilleure rémunération ailleurs.
Les données d’entraînement IA pour le codage et le problème de qualité
Comme Privacy International l’a noté dans une analyse détaillée, il existe deux catégories d’annotateurs : les annotateurs génériques qui traitent des ensembles de données à grande échelle, et les experts ayant des connaissances spécifiques à un domaine. L’organisation a constaté que des données de mauvaise qualité conduisent directement à des résultats IA incorrects. Pour le code, cette distinction est fondamentale. Un développeur junior peut reconnaître qu’une fonction fonctionne, sans détecter qu’elle introduit une fuite mémoireDéfaut de programmation où un programme alloue de la mémoire sans jamais la libérer, entraînant une consommation croissante jusqu'au crash du système., une situation de compétition ou une vulnérabilité de sécurité qui n’apparaît qu’à grande échelle.
Les résultats sont mesurables. Une analyse de 470 pull requests open source par CodeRabbit a révélé que le code généré par l’IA produit 1,7 fois plus de problèmes que le code écrit par des humains. Les vulnérabilités de sécurité sont 2,74 fois plus fréquentes. Les erreurs de logique et de correction sont 75 % plus nombreuses. Les lacunes dans la gestion des erreurs apparaissent à près du double du taux.
Des recherches d’Apiiro, analysant le code de grandes entreprises Fortune 50, ont révélé qu’en juin 2025, le code généré par l’IA introduisait plus de 10 000 nouvelles failles de sécurité par mois. Les chemins d’élévation de privilègesAttaque de sécurité par laquelle un intrus obtient un accès ou un contrôle plus élevé que prévu, en exploitant des failles dans un système ou une application. ont bondi de 322 %. Les défauts de conception architecturale ont augmenté de 153 %. Les chercheurs l’ont formulé sans détour : l’IA corrige les fautes de frappe mais crée les bombes à retardement.
Le problème de l’autoprotection
Au-delà de la rémunération, il existe une seconde raison pour laquelle les développeurs expérimentés évitent le travail de RLHF : l’intérêt personnel. Pourquoi un ingénieur senior passerait-il son temps à enseigner méticuleusement à un système d’IA à reproduire ses propres compétences ? Chaque examen de code de qualité soumis à une plateforme d’entraînement rapproche l’IA d’un pas de plus de rendre sa propre expertise moins précieuse. Aucun acteur économique rationnel ne forme son propre remplaçant pour 40 $ de l’heure.
Cela crée un paradoxe structurel. Les développeurs qui pourraient le plus améliorer les modèles de codage IA ont le moins d’incitation à participer. Ceux qui participent sont, presque par définition, ceux qui ne peuvent pas encore prétendre aux salaires les plus élevés. L’IA apprend du second groupe et hérite de ses angles morts.
Les preuves : l’IA ralentit les développeurs expérimentés
Un essai contrôlé randomisé mené par METR, publié en juillet 2025, a suivi 16 développeurs open source expérimentés accomplissant 246 tâches réelles sur des bases de code sur lesquelles ils travaillaient en moyenne depuis cinq ans. Résultat : les développeurs utilisant des outils IA ont mis 19 % de temps en plus pour accomplir leur travail. Pas plus vite. Plus lentement.
L’écart de perception était frappant. Avant l’étude, les développeurs prédisaient que l’IA les rendrait 24 % plus rapides. Après l’étude, ils croyaient toujours avoir été 20 % plus rapides. La réalité était l’inverse. Comme l’a rapporté InfoWorld, les développeurs n’ont accepté que moins de 44 % des suggestions de code générées par l’IA, et 56 % ont apporté des modifications majeures pour corriger ce que l’IA avait produit.
Pour les développeurs expérimentés travaillant sur des bases de code qu’ils connaissent bien, les assistants de codage IA n’aident pas. Ils ajoutent de la friction. Le code qu’ils produisent reflète des modèles appris à partir de données d’entraînement IA médiocres, et non la compréhension nuancée qui vient de longues années de travail sur un système spécifique.
Les conditions de travail derrière les données
Près de 100 travailleurs kényans dans le domaine de l’IA ont publié une lettre ouverte déclarant que leurs conditions de travail « s’apparentent à l’esclavage moderne ». Le projet Fairwork d’Oxford a évalué 15 plateformes d’annotation de donnéesLe processus d'étiquetage de données brutes (textes, images, sons) pour permettre aux modèles d'IA d'apprendre à les interpréter correctement. et n’en a trouvé aucune qui atteigne le minimum requis en matière de rémunération équitable, de conditions, de contrats ou de gestion.
Les travailleurs sur ces plateformes signalent des désactivations soudaines de comptes, du travail non rémunéré déguisé en « tests de qualification » et une gestion algorithmique qui remplace la supervision humaine. Un recours collectif déposé en mai 2025 accuse Surge AI, la société mère de DataAnnotation.tech, d’avoir mal classifié les travailleurs en tant qu’indépendants pour leur refuser les protections liées aux heures supplémentaires et au salaire minimum.
Quand les travailleurs sont sous-payés, surchargés et exposés à un licenciement arbitraire, la qualité de leur production en pâtit. Ce n’est pas controversé. C’est de l’économie du travail élémentaire. Et cette qualité amoindrie se répercute directement dans les modèles IA sur lesquels des millions de développeurs s’appuient.
Ce que cela signifie
Le problème fondamental des outils de codage IA n’est pas une limitation technique qui sera résolue par un modèle plus grand ou une architecture plus intelligente. C’est un problème de marché du travail. L’économie du RLHF garantit que les personnes qui entraînent l’IA à coder ne sont pas les mieux équipées pour le faire. Tant que cela ne changera pas, les assistants de codage IA continueront à produire du code qui semble plausible mais qui échoue de la façon que seule l’expérience permet d’anticiper.
Une revue académique du MIT, de Harvard et d’autres institutions recensant les limitations fondamentales du RLHF a conclu qu’« il y a eu relativement peu de travaux publics systématisant ses défauts ». L’article a identifié de nombreux problèmes ouverts liés à la qualité du retour humain, notamment le fait que l’expertise des évaluateurs contraint directement ce que le modèle peut apprendre.
Pour l’heure, la révolution du codage IA souffre d’un problème d’enseignants. Les meilleurs enseignants sont occupés à faire le vrai travail. Les enseignants actuels font de leur mieux avec les outils et l’expérience dont ils disposent. Et l’écart entre ces deux groupes se manifeste dans chaque fonction hallucinée, chaque cas limite manqué et chaque vulnérabilité de sécurité qui passe au travers des revues de code.
Les assistants de codage IA livrent du code avec 1,7 fois plus de défauts, 2,74 fois plus de vulnérabilités de sécurité et 322 % de chemins d’élévation de privilègesAttaque de sécurité par laquelle un intrus obtient un accès ou un contrôle plus élevé que prévu, en exploitant des failles dans un système ou une application. supplémentaires par rapport au code écrit par des humains. Ce ne sont pas des douleurs de croissance. Ce sont les résultats prévisibles d’un pipeline d’entraînement où la boucle de retour humain est assurée par les mauvaises personnes. La rédaction a soulevé ce point, et il mérite un examen rigoureux de l’économie structurelle derrière les données d’entraînement IA pour le codage.
Le RLHFUn processus d'apprentissage automatique où les modèles d'IA apprennent des retours humains sur leurs sorties, leur apprenant quelles réponses privilégier ou refuser. et le problème de la qualité des évaluateurs
Les grands modèles de langage modernes sont affinés par apprentissage par renforcement à partir du retour humain (RLHF), un processus en trois étapes : collecter des évaluations humaines des sorties du modèle, entraîner un modèle de récompense pour approximer ces évaluations, puis optimiser la politique par rapport à ce modèle de récompense. Le plafond de qualité du modèle résultant est limité par la qualité du retour humain en première étape. Comme Casper et al. (2023) l’ont documenté dans leur revue systématique des limitations du RLHF, la technique « s’est imposée comme la méthode centrale utilisée pour affiner les grands modèles de langage de pointe » malgré « relativement peu de travaux publics systématisant ses défauts ».
Pour la génération de code spécifiquement, le RLHF requiert des évaluateurs capables d’évaluer non seulement si le code compile et retourne le résultat attendu, mais s’il gère les cas limites, gère la mémoire efficacement, évite les bugs de concurrence et n’introduit pas de dette architecturale. Privacy International distingue deux niveaux : les annotateurs génériques traitant de grands ensembles de données, et les annotateurs experts ayant des connaissances spécifiques à un domaine. Pour les tâches de codage, l’écart entre ces deux niveaux correspond à la différence entre « ça tourne » et « c’est prêt pour la production ».
L’économie : pourquoi les experts ne participent pas
Le Bureau américain des statistiques du travail rapporte un salaire médian de développeur logiciel de 133 080 $ (mai 2024). Dans les entreprises de type FAANG, la rémunération totale des ingénieurs de niveau intermédiaire dépasse 250 000 $ avec les actions, soit environ 120 $ de l’heure. Les ingénieurs seniors et confirmés gagnent considérablement plus.
Les tâches de codage RLHF, en revanche, paient entre 40 et 60 $ de l’heure sur des plateformes comme DataAnnotation.tech et Outlier. Les annotations d’entrée de gamme se situent entre 15 et 30 $ de l’heure. Ce sont des postes de prestataires sans avantages sociaux, sans actions, sans perspectives de carrière et avec une disponibilité irrégulière des tâches. Les travailleurs sur ces plateformes signalent que les projets bien rémunérés disparaissent rapidement et que la désactivation de compte peut survenir sans avertissement ni explication.
Le calcul rationnel pour un développeur senior est clair. À 60 $ de l’heure sans sécurité de l’emploi, le travail de RLHF représente une réduction de salaire d’environ 50 % par rapport à son équivalent salarié. Pour un ingénieur FAANG, c’est une réduction de 50 à 75 %. Le coût d’opportunité rend la participation irrationnelle pour quiconque dispose de véritables alternatives sur le marché, avant même de considérer le facteur d’autoprotection : les développeurs experts n’ont aucun intérêt à former un système qui dévalue leur propre expertise.
La provenance des données d’entraînement IA pour le codage
La majeure partie du travail d’entraînement est sous-traitée dans le Sud global. La Banque mondiale estime 150 à 430 millions de travailleurs des données dans le monde. Une enquête CBS 60 Minutes a documenté des travailleurs kényans gagnant entre 1,50 et 2 $ de l’heure sur des tâches d’entraînement IA. OpenAI payait le prestataire SAMA 12,50 $ de l’heure par travailleur ; les travailleurs recevaient 2 $. Aux Philippines, la plateforme Remotasks de Scale AI retardait ou retenait régulièrement les paiements de travailleurs gagnant sous le salaire minimum. Sur 36 travailleurs interrogés, 34 ont signalé des problèmes de paiement.
Rest of World a constaté des disparités de rémunération de l’ordre de 15 fois au sein d’une même entreprise pour des tâches identiques : 21,55 $ de l’heure pour les tâches en allemand, 1,43 $ pour le télougou. Les annotateurs de données IA vénézuéliens gagnent entre 0,90 et 2 $ de l’heure. Le projet Fairwork d’Oxford a évalué 15 plateformes et n’en a trouvé aucune atteignant le minimum requis en matière de rémunération équitable, de conditions ou de gestion.
Les structures d’entreprise masquent cette réalité. Surge AI opère DataAnnotation.tech, Taskup.ai et Gethybrid.io comme filiales orientées travailleurs tout en maintenant séparées les relations avec les clients entreprises. Remotasks est la filiale orientée travailleurs de Scale AI. Les travailleurs ne savent souvent pas à quelle entreprise IA leurs données annotées sont destinées, encore moins quel modèle ils entraînent.
Les conséquences mesurables sur la qualité
L’analyse de 470 pull requests open source par CodeRabbit a quantifié l’écart : les pull requests générées par l’IA produisent 10,83 problèmes par PR contre 6,45 pour celles rédigées par des humains (rapport de 1,7). Vulnérabilités de sécurité : 2,74 fois plus élevées. Erreurs de logique et de correction : 75 % plus fréquentes. Lacunes dans la gestion des erreurs : près de 2 fois plus. Problèmes de lisibilité : plus de 3 fois plus.
Les recherches d’Apiiro sur des bases de code Fortune 50 ont révélé que le développement assisté par IA génère 10 fois plus de failles de sécurité tout en réduisant le volume de pull requests d’un tiers. En juin 2025, le code IA introduisait plus de 10 000 nouvelles failles de sécurité par mois. Le profil des vulnérabilités s’est transformé : les erreurs de syntaxe triviales ont chuté de 76 %, mais les chemins d’élévation de privilèges ont augmenté de 322 % et les défauts de conception architecturale de 153 %. Les chercheurs ont noté que l’IA « corrige les fautes de frappe mais crée les bombes à retardement ».
Ce schéma est cohérent avec des modèles entraînés à partir du retour d’évaluateurs capables d’évaluer la correction de surface mais dépourvus de l’expérience nécessaire pour identifier les problèmes architecturaux profonds. Un évaluateur junior peut confirmer qu’une fonction retourne le résultat attendu. Il est moins probable qu’il détecte qu’elle introduit une situation de compétition sous charge simultanée, qu’elle fuit des ressources sur les chemins d’exception, ou qu’elle viole le modèle d’autorisation du système plus large.
L’étude METR : preuve empirique de l’écart
Un essai contrôlé randomisé mené par METR (juillet 2025) a suivi 16 développeurs open source expérimentés sur 246 tâches dans des dépôts auxquels ils contribuaient en moyenne depuis cinq ans. Les tâches étaient assignées aléatoirement aux conditions avec ou sans IA, en utilisant des modèles de pointe (Cursor Pro avec Claude 3.5/3.7 Sonnet).
Résultat : les tâches avec IA autorisée ont pris 19 % plus de temps. Les développeurs prédisaient un gain de vitesse de 24 % avant l’étude et estimaient encore un gain de 20 % après. L’analyse d’InfoWorld a noté que les développeurs n’acceptaient que moins de 44 % des suggestions de l’IA, 75 % lisant chaque ligne et 56 % apportant des modifications majeures. Les chercheurs ont constaté des ralentissements plus importants sur les tâches où les développeurs avaient une grande expérience de la base de code.
C’est le fossé de qualité du RLHF en action. Lorsque des développeurs expérimentés rencontrent du code généré par l’IA, ils passent plus de temps à vérifier, corriger et nettoyer la production qu’ils n’en auraient passé à l’écrire eux-mêmes. Les suggestions de l’IA reflètent des modèles appris à partir d’un retour de moindre qualité, et non le contexte spécifique de la base de code. Pour les experts, l’outil ajoute du bruit plutôt que du signal.
Les conditions de travail aggravent le problème
Près de 100 travailleurs kényans de l’IA ont décrit leurs conditions comme « une forme d’esclavage moderne » dans une lettre ouverte. Les travailleurs sont soumis à des minuteries strictes, à une surveillance algorithmique et à des désactivations de comptes arbitraires. Un recours collectif en 2025 accuse Surge AI de mal classifier les travailleurs en indépendants pour éviter les protections du droit du travail.
Dans ces conditions, optimiser le débit est rationnel. Les travailleurs apprennent à accomplir les tâches rapidement pour maintenir leurs revenus, et non à fournir l’évaluation attentive et réfléchie qui produit un signal d’entraînement de qualité. Quand votre compte peut être désactivé sans explication pour avoir travaillé trop lentement, la profondeur d’analyse devient un luxe qu’on ne peut pas se permettre. La structure des incitations sélectionne la vitesse sur la qualité à chaque niveau.
Le paradoxe structurel
Le problème fondamental n’est pas technique mais économique. Le RLHF pour le code nécessite des évaluateurs capables d’évaluer des décisions d’ingénierie de qualité production. Ces évaluateurs gagnent 133 000 $ ou plus par an dans leur carrière principale. Le pipeline d’entraînement paie entre 40 et 60 $ de l’heure comme travail de prestataire dans le meilleur des cas, et entre 1,50 et 2 $ de l’heure dans le cas le plus courant. Aucun acteur de marché rationnel disposant de réelles alternatives ne choisirait d’y participer.
Cela crée une boucle de rétroaction : des modèles entraînés sur des évaluations médiocres produisent du code médiocre, que des développeurs expérimentés perdent du temps à corriger, ce qui renforce la perception que l’IA « a encore du chemin à faire », sans pour autant modifier les fondamentaux économiques de l’entraînement. Les modèles s’améliorent progressivement grâce à l’échelle et aux changements d’architecture, mais le plafond de qualité reste contraint par le pipeline d’évaluation.
Tant que les entreprises d’IA ne paieront pas une rémunération de niveau expert pour une évaluation de code de niveau expert (ce qui augmenterait considérablement les coûts d’entraînement) ou ne développeront pas des méthodes d’évaluation qui ne dépendent pas du jugement humain (ce qui reste un problème de recherche ouvert), les assistants de codage IA continueront à produire du code qui satisfait les contrôles de surface tout en manquant les schémasCadres mentaux de représentations compressées et d'attentes que le cerveau utilise pour encoder, stocker et récupérer les informations. Lorsque vous vous souvenez de quelque chose, votre cerveau la reconstruit en utilisant des schémas plus tous les indices contextuels présents. profonds qui séparent les logiciels fiables des logiciels fragiles.
