Le paradoxe du développement assisté par l'IA : pourquoi la vitesse grimpe de 55 % sur une page blanche mais chute de 19 % dans du code mature

• Ralentissement sur du code mature (METR, 246 tâches) : +19 % de temps par tâche pour des développeurs ayant en moyenne 5 ans d'expérience sur le dépôt
• Erreur d'auto-évaluation (aveuglement de calibration) : écart de près de 40 points de pourcentage entre le sentiment d'accélération (-20 %) et le ralentissement réel (+19 %)
• Accélération sur une page blanche (Microsoft/GitHub) : -55,8 % de temps (71,2 contre 160,9 minutes) sur un serveur HTTP type écrit de zéro
• Croissance cachée de l'arbre des paquets et des hallucinations : 14 dépendances directes se déploient en 492 paquets (et jusqu'à 1 442 sur un projet web)

Dans certaines conférences, on montre des courbes où la vitesse double grâce aux assistants IA ; dans d'autres, on cite des rapports affirmant que les réseaux de neurones ralentissent les développeurs seniors. Le paradoxe, c'est que ces deux affirmations s'appuient sur des essais contrôlés randomisés (RCT) rigoureux, avec chronométrage à la seconde, et qu'elles sont toutes les deux vraies.

Dans l'expérience de Peng et ses collègues de Microsoft Research, GitHub et MIT Sloan (`arXiv:2302.06590`), 95 développeurs ont reçu la tâche d'écrire de zéro un serveur HTTP en JavaScript devant passer des tests automatisés préétablis. Avec l'autocomplétion assistée par IA, les participants ont terminé en 71,2 minutes contre 160,9 minutes pour le groupe témoin — soit 55,8 % plus vite.

Mais en juillet 2025, l'équipe de METR (`arXiv:2507.09089`) a mené un RCT en miroir auprès de 16 mainteneurs expérimentés, sur 246 tâches réelles de production dans leurs propres dépôts matures (en moyenne 1,1 million de lignes de code, 10 ans d'historique de projet et 5 ans d'expérience personnelle par participant — environ 1 500 commits). Avec des outils IA, les développeurs ont passé 19 % de temps supplémentaire sur chaque tâche, et 75 % des participants se sont retrouvés dans le rouge.

Pourquoi les développeurs expérimentés ont-ils mal évalué leur propre

vitesse de près de 40 points de pourcentage ?

Le chiffre le plus inquiétant du rapport METR n'est pas tant ces +19 % de temps que l'effondrement de la calibration humaine. Avant le début de l'étude, des experts externes (34 économistes et 54 chercheurs en machine learning) prédisaient une accélération de 38 à 39 %, et les développeurs eux-mêmes tablaient sur 24 %. Mais après avoir terminé les 246 tâches et noté leurs temps, les participants étaient sincèrement convaincus que l'IA leur avait fait gagner environ 20 % de temps.

Le ressenti et le chronomètre ont divergé de 39 points de pourcentage (alors que la calibration normale des estimations de durée de tâche se situe à 0,64 et 0,59). L'IA fausse la perception de l'effort : rester assis en spectateur, à superviser un texte qui défile, est psychologiquement plus facile que de s'arracher soi-même à du code legacy. D'où une conclusion managériale : tout rapport sur « l'effet de l'adoption de l'IA » fondé sur des sondages auprès des employés mesure la dopamine, pas la productivité.

Où se situe la « frontière dentelée » des capacités du modèle entre

novice et expert ?

En croisant les données de METR et de Microsoft avec l'étude de Harvard sur 758 consultants de BCG (`Navigating the Jagged Technological Frontier`, 2026) et les travaux de Brynjolfsson dans le QJE sur 5 172 opérateurs de support, un tableau cohérent se dessine :

1. L'effet de nouveauté du contexte : dans le support client, l'IA a apporté en moyenne +15 %, mais les novices ont gagné +30 à 36 %, alors que les vétérans n'ont quasiment rien gagné. Sur une page blanche, chacun de nous est un novice — c'est pourquoi on y gagne -55 % de temps.

Dans un dépôt vieux de cinq ans, la principale difficulté consiste à préserver les invariants d'architecture implicites, absents des poids du modèle. 2. Le piège de la persuasion : à l'intérieur de la frontière des capacités du modèle, les consultants équipés d'IA traitaient 12,2 % de tâches en plus et 25,1 % plus vite.

Mais au-delà de cette frontière, la proportion de solutions correctes chutait de 84,5 % à 60–70,6 %, tandis que des juges externes jugeaient ces textes erronés 17,9 à 25,1 % plus convaincants.

Pour éviter de tomber dans ce piège des +19 %, je m'impose quatre règles : ne jamais déléguer la compréhension (préciser dans le cahier des charges le fichier exact, la ligne, la cause et le critère d'acceptation), bloquer via des hooks `PreToolUse` seulement 25 commandes irréversibles sur 424 autorisées (en décortiquant les enrobages `ssh`, `python -c` et `base64`), conserver 93 Ko de règles d'architecture modulaires sur disque, et séparer les niveaux de délégation `Level 0–3`.

Comment 14 paquets déclarés se transforment-ils en 492, et en quoi le

slopsquatting est-il dangereux ?

Selon USENIX Security 2025 (`arXiv:2406.10279`), sur 576 000 extraits de code, les modèles inventent des noms de bibliothèques inexistantes dans 5,2 % des cas pour les LLM commerciaux et 21,7 % pour les modèles open source (205 474 noms fantômes uniques), une faille exploitée par les attaquants (`slopsquatting`). Vérifier l'arbre de dépendances réel de son propre projet ne prend qu'une seconde :

```python import json, sys

lock = json.load(open(sys.argv[1], encoding="utf-8")) root = lock["packages"][""] direct = len(root.get("dependencies", {})) + len(root.get("devDependencies", {})) total = len([k for k in lock["packages"] if k]) print(f"Déclarés manuellement : {direct} | Réellement dans l'arbre : {total}") ```

Dans mon bot, 14 bibliothèques déclarées se sont déployées en 492 paquets, et sur un projet web, en 1 442 paquets. Le minimum de propreté obligatoire : commiter les fichiers lock, exécuter régulièrement `trufflehog`, `trivy fs --scanners vuln,secret` et `syft`.

Les hooks de sécurité, les niveaux de délégation et le contrôle des dépendances sont déjà réunis dans la pile [Nomad AI](https://nomadnet.ai) et sur la plateforme [agent.nomadnet.ai](https://agent.nomadnet.ai). Apprendre le vibe-coding d'ingénierie sans perdre le contrôle de l'architecture est possible via la [Hamidun Academy](https://academy.hamidun.com) (72 heures d'essai gratuit), et les règles et garde-fous de terrain sont accessibles sur [Vibe Club](https://hamidun.com/club).