LLM : pourquoi leurs capacités semblent si différentes
Pourquoi les LLM impressionnent-ils certains et déçoivent-ils d’autres ? Analysez le fossé d’usage, ses causes et ses enjeux pour votre entreprise.
L'IA ne progresse pas de la même façon pour tout le monde
Un grand modèle de langage peut paraître inutile à une personne qui l'essaie juste pour reformuler un courriel gratuitement. À l'inverse, il peut changer le quotidien d'une équipe qui s'en sert pour analyser du code, tester des hypothèses ou automatiser une partie d'un processus. Ce décalage ne vient pas seulement de perceptions différentes de l'IA. Il reflète surtout des écarts d'accès, d'expérience, de domaine... et de ce que les gens attendent vraiment du système.
Dans un post sur X, Andrej Karpathy décrit ça comme un entonnoir : une grande partie de la population connaît peu les LLM, beaucoup les utilisent de temps en temps, et une petite minorité les mobilise pour des tâches exigeantes avec des systèmes plus avancés. Il donne des ordres de grandeur, pas un recensement représentatif. Autrement dit : c'est une façon d'illustrer le phénomène, pas une statistique "au cordeau".
Ce décalage a des effets très concrets. Il complique les décisions d'investissement, alimente les débats entre métiers et directions, et peut pousser une entreprise à surestimer l'IA (ou à la sous-estimer) sans s'en rendre compte. Pour juger ces outils, il faut partir de questions simples : qu'est-ce qu'on leur demande, avec quel accès, dans quel environnement, et comment on mesure réellement la réussite.
Un entonnoir d'usages, pas une expérience commune
La plupart des discussions sur l'IA partent du principe que tout le monde parle du même outil et en tire des usages comparables. En pratique, c'est rarement le cas. Entre quelqu'un qui n'a jamais testé un chatbot et un ingénieur qui fait travailler un agent sur une partie d'un projet logiciel, l'écart porte sur l'accès, les tâches confiées et le niveau d'intégration au travail.
Karpathy distingue plusieurs groupes. Ses chiffres restent approximatifs et ses catégories ne remplacent pas une étude. Mais l'ensemble donne un cadre utile pour comprendre pourquoi les expériences sont si différentes.
Une majorité encore peu exposée
Dans son estimation, environ six milliards de personnes n'auraient à peine rencontré des LLM. La fracture numérique, la disponibilité des services, les langues prises en charge, le coût des abonnements et les usages locaux jouent évidemment un rôle. En Europe, les outils sont accessibles à beaucoup de gens, mais ça ne veut pas dire que tout le monde les utilise au quotidien dans son travail, ni même qu'on sait clairement ce qu'ils peuvent faire.
Et surtout : ne pas utiliser un outil n'est pas forcément un "retard". Si quelqu'un ne rencontre jamais de situation où le LLM fait mieux que ce qu'il y a déjà, l'adoption n'a pas grand intérêt. Les entreprises tombent parfois dans le même piège : chercher un cas d'usage "pour justifier" un abonnement, au lieu de partir d'un irritant réel.
Les utilisateurs occasionnels voient surtout le chatbot
Un deuxième groupe utilise, de temps en temps, une version grand public (souvent gratuite). Typiquement : reformuler, résumer, proposer un plan. Ça peut dépanner, mais ça donne surtout une vue "interface conversationnelle" : on pose une question, le modèle génère un texte, puis l'utilisateur relit et corrige.
Quand les réponses sont creuses, approximatives ou parfois fausses, le jugement "ça ressemble à un moteur de recherche, mais en moins bon" s'explique. L'évaluation se fait sur des tâches courtes, avec peu de contexte et sans connexion aux outils de travail. Et si le chatbot n'a pas accès aux documents pertinents, il ne peut pas produire une analyse fiable de ces documents. Ce n'est pas une preuve que le modèle ne sait rien faire : c'est juste une limite de l'usage testé.
Il faut aussi éviter l'effet inverse : une réponse bien écrite ne prouve ni que c'est exact, ni que quelqu'un l'a vérifiée. Une interface fluide peut masquer des erreurs factuelles ou une compréhension trop superficielle.
Une minorité utilise les modèles avancés sur des tâches exigeantes
Karpathy estime qu'environ vingt millions de personnes utilisent des modèles de pointe de façon professionnelle, notamment en programmation et en mathématiques. Le chiffre reste une estimation, et la catégorie n'est pas simple à définir. L'idée importante, elle, est la spécialisation : certains utilisateurs disposent de modèles, d'outils et de méthodes plus adaptés aux tâches complexes.
En développement logiciel, par exemple, un agent peut parcourir plusieurs fichiers, proposer des changements, lancer des tests et corriger des erreurs qu'il détecte. Le gain ne vient pas seulement du fait de produire quelques lignes de code. Il apparaît quand on donne un objectif assez large, que l'agent a un environnement pour agir, et que le résultat peut être vérifié.
Ça ne veut pas dire qu'un projet entier se termine toujours avec "une seule instruction". La qualité dépend du cadrage, des dépendances, des tests, de la sécurité, et surtout de la capacité de l'équipe à relire ce qui a été modifié. Mais pour une tâche bien adaptée, le gain peut être assez important pour changer l'organisation du travail.
L'accès interne aux systèmes les plus avancés
Le dernier groupe, quelques milliers de personnes selon Karpathy, aurait accès à des systèmes internes ou à des prototypes particulièrement avancés. Il évoque des ensembles d'agents capables de travailler ensemble sur des tâches longues, logicielles ou scientifiques. Ces exemples montrent une direction possible, mais ils ne doivent pas être confondus avec des capacités "générales", disponibles à tous et vérifiées de la même manière.
La différence entre une démo et un produit utilisable est majeure. Il faut regarder la fiabilité, le coût, la reproductibilité et le niveau de supervision nécessaire. Une performance obtenue en environnement contrôlé ne garantit pas qu'elle se reproduira dans une entreprise, avec ses systèmes historiques, ses règles d'accès et ses responsabilités juridiques.
Pourquoi les performances perçues divergent
Ce décalage vient moins d'une opposition entre "ceux qui comprennent l'IA" et "ceux qui ne comprennent pas", et davantage de trois variables : la difficulté de la tâche, le domaine concerné, et le niveau d'accès au système. Si on mélange ces facteurs, les comparaisons deviennent vite inutiles.
L'ambition de la tâche change tout
Une question à traiter en un paragraphe fait peu travailler le système. Une tâche plus longue, avec des étapes liées, peut au contraire tirer parti de la capacité du modèle à gérer le contexte, produire des propositions et utiliser des outils. C'est fréquent sur une migration technique, une analyse documentaire ou la préparation d'un jeu de tests.
La taille du problème ne suffit pas : il faut aussi un critère de réussite. "Améliorer notre service client" ne veut rien dire tant qu'on ne sait pas à quoi ressemble une amélioration. "Classer ces demandes selon une grille définie, proposer une réponse à partir des procédures approuvées et signaler les cas incertains" est testable. Sans définition claire du résultat attendu, l'équipe peut finir par confondre une démo convaincante avec une amélioration réellement utile.
Le temps joue aussi. Une réponse immédiate à une tâche isolée n'est pas le même usage qu'un agent qui progresse étape par étape. Et plus l'autonomie augmente, plus il faut définir les permissions, les points de contrôle et les conditions d'arrêt. Une tâche longue n'est intéressante que si son résultat reste vérifiable.
Les capacités varient selon le domaine
Les LLM ne progressent pas de façon uniforme. Ils sont souvent plus performants quand la tâche se déroule dans un environnement numérique, quand on peut évaluer le résultat et quand il existe beaucoup d'exemples. Le code illustre bien ça : on peut lancer des tests, comparer une sortie à un résultat attendu et itérer vite.
À l'inverse, une demande qui dépend d'informations très récentes, d'un contexte local mal documenté ou d'une décision dont l'impact est difficile à mesurer donne parfois des résultats beaucoup moins fiables. La performance n'est pas "une propriété abstraite du modèle". Elle dépend du couple modèle + tâche, mais aussi des données, des outils et des critères d'évaluation.
C'est pour ça qu'on parle parfois d'un caractère "accidenté" des capacités : un système peut réussir un exercice compliqué et rater une demande qui, sur le papier, semble simple. Pour une entreprise, la conséquence est claire : on ne peut pas conclure sur une démo isolée. Il faut tester les cas réels, y compris les exceptions et les entrées de mauvaise qualité.
L'accès ne se résume pas au prix d'un abonnement
Une version gratuite, une version payante et un système interne ne donnent pas forcément le même modèle, les mêmes capacités ni les mêmes intégrations. Un compte pro peut offrir une collaboration différente ou des limites d'usage différentes. Un système interne, s'il est encadré par des règles de sécurité adaptées, peut être connecté à des données et à des outils métiers. Résultat : l'expérience perçue change avec l'environnement technique.
Mais "avoir accès" ne veut pas dire "savoir en tirer parti". Il faut comprendre les limites du modèle, préparer les données, choisir les bons processus et organiser la validation. Et, là encore, le facteur humain compte : une équipe qui connaît bien son métier repère des erreurs que l'utilisateur occasionnel ne voit pas.
Ce que ce décalage change pour les entreprises
Dans les organisations, on trouve souvent des niveaux d'expérience très différents au même moment. Une direction peut entendre des développeurs parler d'automatisations déjà rentables, tandis que d'autres équipes n'ont testé qu'un chatbot généraliste. Ces deux descriptions peuvent être vraies, mais elles ne parlent pas du même périmètre. Donc, non : la décision ne devrait pas se baser sur une moyenne d'avis.
Remplacer le débat d'opinion par un test métier
La démarche la plus solide est simple : choisir une tâche suffisamment fréquente et assez cadrée, puis comparer le processus actuel à une version assistée par IA. Avant de tester, il faut documenter le temps passé, le taux d'erreur, le coût de vérification et les situations où l'humain reste indispensable.
Un protocole pragmatique peut tenir en cinq étapes :
- Choisir une tâche réelle avec un volume et un irritant mesurables.
- Définir les données accessibles et les restrictions de confidentialité.
- Fixer des critères de réussite, par exemple le temps économisé sans dégrader la qualité.
- Tester sur un échantillon représentatif, en incluant les cas difficiles et les exceptions.
- Décider sur le coût complet, en intégrant l'intégration, le contrôle, la formation et la maintenance.
Ce protocole évite deux conclusions trop rapides : "le modèle a réussi une fois, donc automatisons tout" et "il s'est trompé une fois, donc ça ne sert à rien". Le bon indicateur n'est pas l'effet spectaculaire d'une démo, mais la performance répétée dans des conditions proches de la production.
Distinguer assistance, automatisation et délégation
Toutes les tâches ne portent pas le même niveau de risque. L'IA peut proposer une première version qu'un professionnel révise, automatiser une opération déterministe avec garde-fou, ou agir de façon plus autonome sur plusieurs étapes. Plus on va vers la délégation, plus une erreur peut coûter cher.
Pour le support client, par exemple, l'outil peut d'abord aider à retrouver une procédure. La suite peut être de rédiger une réponse que le conseiller valide. L'envoi automatique ne se justifie que pour des cas bien délimités, avec des mécanismes de recours et une supervision adaptée. Un déploiement progressif produit de l'information utile sans confier trop tôt une décision sensible au système.
Mesurer la valeur nette, pas le volume généré
Produire plus de texte ou plus de code n'est pas automatiquement un gain. La valeur apparaît quand le système réduit le délai, améliore la qualité, rend possible une activité qui ne l'était pas, ou libère du temps pour une autre tâche. À l'inverse, une réponse générée vite peut coûter cher si la vérification prend autant de temps que le travail initial.
Le calcul doit inclure l'abonnement ou l'inférence, l'intégration aux outils, la préparation des données, les contrôles, la sécurité et la maintenance. Il faut aussi intégrer le coût des erreurs : mauvaise réponse à un client, fuite d'information ou modification logicielle défectueuse. Une expérimentation peu coûteuse peut être pertinente, mais elle doit répondre à une question business précise avant d'être élargie.
Évaluer les capacités sans ignorer les risques
Le même fossé qui pousse certains à minimiser l'IA peut en pousser d'autres à lui attribuer une autonomie trop grande. Une équipe qui ne voit que les meilleures performances d'un agent peut oublier les échecs moins visibles. À l'inverse, quelqu'un qui n'a vu que des réponses génériques peut passer à côté d'une vraie transformation dans un domaine spécialisé. Dans les deux cas, il faut distinguer ce qu'on observe réellement de ce qu'on promet.
Demander des preuves adaptées au contexte
Avant de confier une tâche importante à un LLM, il faut pouvoir répondre à quelques questions : le résultat est-il vérifiable ? Quelle proportion des sorties est correcte ? Quels types d'erreurs reviennent ? Qui les détecte ? Le système marche-t-il sur des données représentatives, et pas seulement sur quelques exemples choisis ?
Pour le code, les tests automatisés et la revue humaine réduisent certains risques, sans les faire disparaître. Pour une analyse juridique ou financière, la présence de références ne suffit pas à garantir l'exactitude ni la pertinence de l'interprétation. Pour des contenus destinés au public, une validation éditoriale reste nécessaire. En clair : le dispositif de contrôle doit être dimensionné selon l'impact d'une erreur, pas selon le confort qu'a le modèle à "bien écrire".
Protéger les données et clarifier les responsabilités
En France et dans l'Union européenne, l'usage d'un outil d'IA doit s'inscrire dans les règles applicables aux données personnelles, notamment le RGPD, et dans les politiques internes de sécurité. Il faut savoir quelles informations sont envoyées au service, à quel fournisseur, dans quelles conditions elles sont conservées et qui y a accès. Les données sensibles ou confidentielles ne doivent pas être copiées dans un outil grand public sans validation préalable.
L'entreprise doit aussi décider qui reste responsable du résultat. Si une décision concerne un salarié, un client ou un usager, le fait que l'automatisation soit techniquement possible ne suffit pas à justifier la délégation. Les obligations varient selon l'usage et le secteur : les équipes juridique, sécurité et métier doivent être impliquées assez tôt pour éviter de découvrir les contraintes après coup.
Préparer les équipes à des capacités qui bougent
Une évaluation réalisée aujourd'hui peut devenir obsolète après une mise à jour du modèle, une baisse de coût ou l'arrivée d'un nouvel outil. Cela ne veut pas dire qu'il faut tout re-tester chaque semaine. L'idée, plutôt, est de suivre les usages qui ont une vraie valeur, garder des scénarios d'évaluation et retester quand quelque chose de significatif change.
La formation utile n'est pas "apprendre des formulations à copier-coller". Elle aide les équipes à choisir les bonnes tâches, fournir le bon contexte, reconnaître les limites et vérifier les résultats. Les développeurs, juristes, responsables RH et équipes support n'ont pas les mêmes risques ni les mêmes critères de qualité. Une politique uniforme peut être facile à gérer, mais elle sera souvent trop permissive pour certains cas et trop restrictive pour d'autres.
La ligne de conduite, au fond, est simple : ne jugez pas les LLM uniquement sur l'expérience gratuite d'un chatbot, mais ne prenez pas non plus une démo avancée comme preuve de fiabilité générale. Évaluez la tâche, l'accès, le contrôle et le coût complet. Et, pour passer à l'action, partez d'un processus concret, définissez un indicateur avant de tester, puis impliquez les personnes qui devront assumer le résultat.