L'écart entre les scores et la vraie productivité

Tous les quelques semaines, un nouveau modèle d'IA débarque avec des résultats qui donnent le vertige. Les benchmarks grimpent, les graphs sont vertigineux, et les réseaux sociaux s'enflamment. On nous annonce que l'avenir du développement vient de changer. Encore.

Sauf que après des années dans le métier, j'ai appris à distinguer deux choses : ce qui est impressionnant sur un tableau, et ce qui l'est vraiment au quotidien.

"Meilleur" ne veut pas dire "meilleur pour moi"

Attention, je ne dis pas que ces modèles sont médiocres. Je les utilise chaque jour. Ils ont transformé ma façon d'aborder le debugging, la documentation, les prototypes. Vraiment.

Mais il y a une différence fondamentale entre "ce modèle score plus haut" et "ce modèle a changé ma façon de travailler".

Pour moi, ce changement s'est produit une seule fois. Un modèle en particulier m'a permis de passer d'un assistant de complétion sophistiqué à un vrai collaborateur. Je pouvais lui confier des tâches délimitées, le laisser explorer le codebase, lui poser des questions, et lui faire confiance pour livrer. Le schéma est passé de "je demande, je reçoivent" à "je demande, on collabore, on itère".

Le plus révélateur ? Quand j'ai regardé ma production réelle sur les mois suivants, la courbe de productivité correspondait à ce changement qualitatif. Pas aux améliorations de benchmarks qui ont continué d'arriver chaque mois.

Pourquoi les benchmarks ne capturent pas ton vrai travail

Les benchmarks de code mesurent généralement ceci : des tâches isolées, bien spécifiées, avec une solution claire. Corrige ce bug. Écris cette fonction. Complete cette PR.

Mais ton vrai travail d'ingénieur, ça n'a rien à voir. C'est des requirements vagues, des dépendances cross-équipes, du legacy sans documentation, et des décisions qui nécessitent de comprendre le contexte métier qu'un modèle n'a simplement pas.

Certains benchmarks commencent à reconnaître ce problème. Quelques initiatives cherchent désormais à withhold information et forcent les modèles à poser des questions clarifying—tester si une IA sait reconnaître quand il lui manque quelque chose plutôt que de répondre avec assurance sur quelque chose qu'elle ne comprend pas. C'est un pas dans la bonne direction, mais on est encore au début.

Ce que ça veut dire pour ton stack

Si tu évalues des outils d'IA pour ton équipe, la question n'est pas "quel score ce modèle obtient sur X benchmark ?" C'est "est-ce que cet outil change vraiment comment mon équipe bosse ?"

Chez NameOcean, on réfléchit à ça à travers le prisme du Vibe Hosting—comment construire des outils qui ne se contentent pas d'exhiber des capacités d'IA mais qui amplifient réellement ce que les développeurs peuvent accomplir ? La différence compte. Un outil légèrement meilleur pour générer des snippets de code, ce n'est pas transformational. Un outil qui change ta vitesse d'itération, ton workflow de debugging, ta capacité à explorer des options architecturales ? Ça, c'est autre chose.

La question de fond

Je ne suggère pas d'ignorer les progrès. Les modèles sont meilleurs—Ils résolvent des problèmes plus complexes, gèrent plus de contexte, font moins d'erreurs embarrassantes. Ce sont des améliorations réelles.

Mais si on attend le prochain bond de benchmark pour débloquer un vrai changement dans notre productivité, on regarde peut-être dans la mauvaise direction. La dernière fois que le travail m'a vraiment semblé différent, c'était quand le modèle d'interaction a changé. Pas quand les scores ont augmenté.

Jusqu'à ce qu'on voie le prochain paradigme dans notre façon de collaborer avec ces systèmes—de meilleurs context windows, un raisonnement sur le long terme amélioré, une orchestration d'agents plus intelligente—les gains marginaux vont continuer d'arriver. Mais les gains transformationnels ? Ils sont peut-être derrière nous.

Ou peut-être que c'est juste le baseline qui se recalibre. Dans tous les cas, ça vaut le coup d'être honnête sur ce qu'on mesure réellement.

Le mot de la fin

La prochaine fois que tu vois un headline sur un benchmark, pose-toi la question : est-ce que ça représente une nouvelle façon de travailler, ou juste une meilleure performance sur des tâches qui étaient déjà à portée ? La distinction vaut peut-être plus que le chiffre lui-même.

Ton infrastructure mérite des outils qui correspondent à ta façon de builder. Pas à ce que les benchmarks disent que tu devrais faire.