Andrej Karpathy — co-fondateur d’OpenAI, ex-head of AI chez Tesla — a lâché une observation qui a déclenché 637 commentaires sur Hacker News : le fossé de compréhension sur les capacités réelles des LLMs se creuse. Ceux qui utilisent ces modèles intensément au quotidien et ceux qui en ont une vision de loin ne partagent plus la même réalité. Et la distance entre les deux camps augmente plus vite que l’adoption elle-même.
Ce n’est pas une question d’accès — ChatGPT, Claude, Gemini sont disponibles à tous depuis des années. C’est une question de calibration. Tu peux avoir utilisé ces outils des centaines de fois et avoir quand même une représentation fausse de ce qu’ils font exactement, comment ils échouent, et dans quelles conditions précises ils deviennent inutilisables.
La conséquence directe : quand une équipe décide d’intégrer un LLM dans un produit, il y a souvent autant de visions que de personnes dans la salle. Et ce décalage de représentation coûte cher — en spécifications bancales, en délais explosés, en features abandonnées à tort ou développées inutilement.
TL;DR — Le gap de compréhension sur les LLMs ne sépare pas les techs des non-techs, mais les utilisateurs intensifs des occasionnels. Ce fossé génère des décisions produit défaillantes. La seule façon de le combler : tester sur ses vrais cas d’usage, documenter les échecs, et rester réellement à jour sur les évolutions des modèles.
La fracture ne passe pas où tu crois
L’intuition naturelle : les développeurs comprennent précisément les LLMs, les non-techs les fantasment ou les diabolisent. Cette intuition est fausse. La fracture ne passe pas entre profils techniques et autres — elle passe entre ceux qui s’en servent quotidiennement sur des tâches professionnelles exigeantes et ceux qui ont un contact superficiel avec ces outils. Et les deux camps se retrouvent dans tous les métiers.
Un dev qui a testé GPT-4 une fois pour générer du code, a été bluffé par le résultat, et est passé à autre chose, a probablement une vision plus biaisée qu’un product manager qui utilise Claude chaque jour pour rédiger, analyser et déboguer. L’expérience ponctuelle mémorable — le « wow moment » — construit des modèles mentaux trompeurs parce qu’elle suréchantillonne les succès et ignore les cas d’échec. Ajoutons que les benchmarks mis en avant par les labs mesurent des performances peak sur des tâches soigneusement choisies, et tu comprendras pourquoi la représentation moyenne est systématiquement déformée vers le haut.
Les deux erreurs symétriques sur les capacités des LLMs
Il y a deux façons de se planter, et elles ne se compensent pas. La première : penser que les LLMs sont des « moteurs de recherche améliorés » — utiles pour la forme, incapables de raisonner. Cette vision sous-estime ce que les modèles récents font sur des tâches structurées : débogage de code complexe, analyse de documents longs, extraction d’information structurée, génération de tests unitaires pertinents.
La deuxième erreur : croire qu’ils peuvent « tout faire » avec le bon prompt. Cette vision génère des projets qui heurtent des murs inattendus — hallucinations sur des données factuelles critiques, dégradation rapide sur des contextes longs, incohérences sur des tâches multi-étapes sans scaffolding, sensibilité surprenante à la formulation exacte des instructions.
La réalité est plus nuancée : les LLMs excellent là où la forme compte autant que le fond, où une erreur à 5% est tolérable, et où un humain peut vérifier rapidement le résultat. Ils deviennent risqués quand la précision factuelle est critique, quand le contexte explose, ou quand la tâche exige un raisonnement causal sans aide structurelle. Ces frontières ne sont pas intuitives — et elles bougent à chaque nouvelle version de modèle.
DÉCOUVREZ NOS RÉALISATIONS
AFC Detailing
Logiciel web de planning et reservation pour un centre de preparation automobile a Saint-Berthevin (53). Application PWA sur mesure.
Voir le projet →Ce que ça donne concrètement dans une réunion de cadrage
Quand on travaille sur une application métier qui intègre un LLM, la première réunion de cadrage révèle souvent le fossé en quelques minutes. Un stakeholder pense qu’on va « brancher l’IA » en deux semaines. Un autre a peur que ça hallucine sur chaque réponse. Un troisième cite un article de 2023 sur des limitations que les modèles récents ont depuis dépassées. Ils parlent techniquement du même outil, mais pas du même objet mental.
Ces décalages ont des coûts réels : des spécifications qui sous-estiment le travail de validation, de guardrails et d’évaluation nécessaire ; des délais qui explosent quand les limites du modèle émergent seulement en phase de test ; ou des features abandonnées par excès de prudence alors qu’elles étaient tout à fait réalisables avec la bonne architecture. La vitesse de progression des modèles aggrave encore le problème — ce qu’un LLM ne faisait pas bien il y a six mois, il le fait peut-être aujourd’hui. Les représentations mentales ont une date de péremption très courte dans ce domaine.
Les benchmarks standard (MMLU, HumanEval, GPQA…) mesurent des performances moyennes sur des tâches types. Ils ne te disent rien sur ce que le modèle fera sur ton cas d’usage spécifique, avec tes données réelles, dans tes conditions opérationnelles. Un modèle qui score 90% en benchmark peut être inutilisable sur ta tâche précise.
Le vibe-check, méthode de calibration médiocre
La façon dont la majorité des gens évaluent un LLM, c’est le vibe-check : deux ou trois questions, ça répond bien, conclusion « l’IA c’est fort ». Ou ça répond à côté sur un cas, conclusion « c’est du bullshit ». Ni l’un ni l’autre ne dit quoi que ce soit d’utile sur la performance réelle du modèle sur une tâche concrète avec des données représentatives.
Une vraie calibration demande de tester le modèle sur les tâches spécifiques qui comptent pour ton usage, avec des inputs réels — pas des exemples idéaux — et en mesurant le taux d’erreur plutôt qu’en comptant les succès mémorables. C’est laborieux. Ça prend du temps. Et c’est précisément pour ça que peu de gens le font, et que le fossé de compréhension persiste malgré des années d’adoption croissante.
Le problème n’est pas que les gens ne connaissent pas les LLMs. C’est qu’ils croient les connaître alors qu’ils n’ont jamais vraiment testé leurs limites.
Comment réduire son angle mort concrètement
Première étape : tester sur tes cas d’usage réels, pas les benchmarks. Pas « GPT-4 score 90% sur MMLU » — mais « sur mes 50 derniers tickets support, le modèle catégorise-t-il correctement à 85% ? » Cette différence de perspective change complètement l’évaluation et révèle des angles morts que les évaluations génériques ne voient jamais.
Deuxième étape : documenter les échecs autant que les succès. Quand le LLM se plante, sur quoi exactement ? Quel type de requête, quelle longueur de contexte, quel format de sortie attendu ? Cette documentation accumule une connaissance opérationnelle que les benchmarks n’apportent pas, et c’est ce qui manque le plus dans les équipes qui débutent avec ces outils.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Troisième étape : rester à jour réellement — pas lire des résumés LinkedIn. Lire les release notes des modèles, les papers techniques, les évaluations indépendantes de labs comme METR ou Epoch AI. Les capacités changent vite, et ta représentation mentale d’il y a un an contient probablement plusieurs erreurs factuelles sur ce que ces systèmes peuvent faire aujourd’hui.
Construire un eval minimaliste — même 20 ou 30 cas représentatifs avec des réponses attendues — te donnera plus d’information utile sur les capacités réelles d’un modèle pour ton usage qu’une heure de tests interactifs au feeling.
Ce fossé de compréhension va continuer à s’élargir à mesure que les modèles progressent et que les cas d’usage se diversifient. Il ne se réduira pas avec plus de demos ou de conférences vulgarisées. Il se réduira uniquement par la pratique intensive, la confrontation honnête aux cas d’échec, et l’humilité de reconnaître que sa représentation mentale peut être obsolète.
Mon pari : d’ici deux ans, la capacité à correctement calibrer ce qu’un LLM peut faire sur un problème précis sera une compétence aussi différenciante dans une équipe produit que savoir lire un profil de performance web ou estimer la complexité d’une feature. Ce ne sera plus « est-ce qu’on peut utiliser l’IA ? », mais « est-ce que quelqu’un dans cette équipe sait vraiment ce qu’on lui demande de faire — et comment mesurer si ça marche ? »
Et pour les startups et équipes produit ambitieuses : si ton process de cadrage d’un projet IA ne comprend pas une phase d’évaluation sérieuse sur tes données réelles avant de commencer à développer, tu prends un pari que tu perdras très probablement en phase de test. Le vrai risque n’est pas de mal utiliser l’IA — c’est de croire qu’on la comprend alors qu’on ne s’est jamais vraiment confronté à ses limites.
