Les données d’Anthropic et a16z affirment que les agents dépassent les humains, mais le benchmark cache une réalité plus difficile

Les données d’Anthropic et a16z placent désormais Claude Fable 5 à 85 % sur OSWorld-Verified, au-dessus d’un score humain de 72,36 % largement cité. Un an plus tôt, le meilleur score d’agent rapporté se situait autour de 42 %. Cette progression suggère que les agents d’utilisation d’ordinateurs ont franchi un seuil qui paraissait encore lointain récemment.

Cette comparaison s’accompagne toutefois d’une importante réserve. Le score humain provient de l’étude OSWorld originale, tandis que le résultat de 85 % utilise l’évaluation révisée OSWorld-Verified. Ces chiffres décrivent des tests apparentés, mais ils ne constituent pas une confrontation contrôlée entre Claude Fable 5 et des humains.

Cette distinction compte, car les agents informatiques passent des démonstrations à des flux de travail où les erreurs ont des conséquences. OpenAI, Google, Anthropic et des développeurs spécialisés veulent tous que des agents utilisent des navigateurs, des applications de bureau et des systèmes métier. Un score élevé modifie les attentes des acheteurs, même s’il ne permet pas de déterminer si ces systèmes peuvent gérer une journée de travail ordinaire.

Les données d’Anthropic et a16z montrent une progression remarquable en un an

Le changement le plus important n’est pas qu’un modèle ait atteint 85 %. C’est qu’un benchmark difficile d’utilisation d’ordinateurs est passé d’environ 42 % à 85 % en près d’un an.

Le tableau de scores des agents informatiques mis en avant par a16z suit une forte progression sur OSWorld-Verified. Claude Fable 5 domine les résultats rapportés avec 85 %. Le graphique présente l’interaction avec les ordinateurs comme l’un des domaines de l’IA appliquée qui progresse le plus rapidement.

OSWorld teste la capacité d’un agent à accomplir des tâches dans de vrais environnements logiciels. Au lieu de répondre à une question, l’agent doit inspecter un écran et décider quoi faire. Il exécute ensuite des actions via des interfaces qui ressemblent à des commandes de souris et de clavier.

Une tâche peut nécessiter de modifier un document, de changer un paramètre d’application, de gérer des fichiers ou de déplacer des informations entre des programmes. La réussite dépend de bien plus que la génération de langage. L’agent doit identifier les éléments de l’interface, préserver l’état, planifier plusieurs étapes et reconnaître si ses actions ont fonctionné.

Le benchmark OSWorld original comprenait 369 tâches impliquant des applications telles que Chromium, LibreOffice, Thunderbird, GIMP, VLC et Visual Studio Code. Huit tâches Google Drive pouvaient être exclues, car elles exigeaient une configuration manuelle, ce qui aboutissait à une évaluation de 361 tâches.

Les chercheurs ont rapporté un taux de réussite maximal de 12,24 % pour les modèles lorsqu’ils ont présenté le benchmark en 2024. Des participants humains non familiers des logiciels ont accompli 72,36 % des tâches. Cet écart considérable a fait d’OSWorld un test utile, car il révélait des faiblesses masquées par les benchmarks conversationnels.

Les agents éprouvaient des difficultés avec l’ancrage dans les interfaces graphiques, c’est-à-dire l’association d’une cible visuelle à la bonne position à l’écran. Ils manquaient également de connaissances opérationnelles sur le fonctionnement des applications. Un modèle pouvait comprendre l’instruction tout en cliquant sur la mauvaise commande ou en perdant la trace d’une boîte de dialogue.

L’effort ultérieur OSWorld-Verified a corrigé des tâches défectueuses ou instables de la collection originale. La maintenance des benchmarks est importante, car les sites web changent, les applications sont mises à jour et les scripts d’évaluation peuvent mal interpréter des résultats valides. Un test plus propre peut mesurer les agents avec davantage de cohérence.

Toutefois, modifier un benchmark modifie aussi la signification de ses scores. Retirer les tâches défaillantes améliore la validité, mais empêche une simple comparaison historique tant que tous les anciens systèmes ne sont pas réexécutés dans des conditions identiques. Les réglages des agents, les limites d’actions, la résolution d’écran et les cadres d’évaluation doivent également correspondre.

C’est pourquoi la trajectoire de 42 % à 85 % doit surtout être comprise comme le signal d’un progrès rapide. Elle ne constitue pas une estimation contrôlée selon laquelle les agents seraient devenus exactement deux fois plus capables. La tendance est forte, mais son ampleur précise reste incertaine.

Le chiffre de 85 % reste néanmoins important. Les systèmes d’utilisation d’ordinateurs doivent traduire de manière répétée des observations visuelles en actions, de sorte que les erreurs s’accumulent au fil d’une trajectoire. Augmenter les taux d’achèvement exige des progrès en perception, raisonnement, mémoire et récupération après erreur.

Le résultat va donc au-delà d’une simple mise à jour de la qualité d’un modèle. Il indique que les développeurs s’améliorent dans l’assemblage de toute la boucle d’exécution. De meilleurs modèles aident, mais les prompts, les représentations d’écran, les étapes de réflexion et les composants spécialisés d’ancrage influencent également le résultat.

La comparaison entre Anthropic et a16z saisit donc un véritable changement. Les agents d’utilisation d’ordinateurs n’échouent plus presque automatiquement face à des tâches de bureau ordinaires. La question plus difficile est de savoir si la réussite à un benchmark prédit désormais un travail fiable hors de son environnement contrôlé.

Le titre sur le niveau humain combine deux tests différents

Claude Fable 5 semble dépasser une référence humaine célèbre, mais les éléments disponibles n’établissent pas une comparaison équivalente entre humains et agents.

Le chiffre de 72,36 % provient de tests humains menés pour l’article OSWorld original. Le chiffre de 85 % est associé à OSWorld-Verified, un ensemble de tâches et un processus d’évaluation révisés. Les traiter comme interchangeables revient à effacer le contexte méthodologique qui sous-tend les deux chiffres.

Même le terme « humain » doit être nuancé. L’étude originale testait des personnes qui ne connaissaient pas les logiciels. Leur score ne représentait pas une limite théorique de la performance humaine. Des utilisateurs expérimentés, davantage de temps ou une prise en main plus claire pourraient produire un autre résultat.

Le score de l’agent dépend également de ses conditions de fonctionnement. Les évaluations d’utilisation d’ordinateurs peuvent varier selon la résolution d’écran, l’historique d’actions disponible, le nombre maximal d’étapes, la politique de nouvelle tentative et le budget de raisonnement. Un agent autorisé à réaliser davantage d’inférences ou de réflexions peut terminer plus de tâches, tout en consommant davantage de temps et de ressources de calcul.

Les taux de réussite peuvent également être rapportés sur une seule tentative ou sur plusieurs. Un système qui réussit une fois après plusieurs exécutions offre une expérience produit différente de celle d’un système qui réussit de manière fiable du premier coup. L’automatisation métier exige généralement le second comportement.

Les données de trajectoire constituent un autre enjeu. Les tâches de benchmark et les traces d’interaction réussies peuvent influencer l’entraînement ultérieur des modèles ou la conception des agents. Cette exposition n’invalide pas automatiquement un résultat, mais elle affaiblit l’affirmation selon laquelle un score mesure une compétence informatique générale.

L’équipe OSWorld originale a constaté qu’un historique de trajectoire textuel plus long améliorait les performances. Cet historique fournissait aux agents davantage d’informations sur les décisions précédentes. Il créait toutefois aussi des difficultés d’efficacité à mesure que le contexte de raisonnement augmentait.

La résolution d’écran comptait également. Des captures d’écran de résolution plus élevée amélioraient généralement les résultats, car les modèles pouvaient localiser plus précisément les petites commandes. Ce constat montre pourquoi deux évaluations nominalement similaires peuvent produire des scores différents lorsque leurs environnements ne sont pas alignés.

Un score de 85 % laisse aussi un taux d’échec significatif. Sur 361 tâches, un taux d’échec de 15 % correspondrait à environ 54 tâches non réussies si toutes les tâches avaient le même poids. Cette estimation illustre l’écart opérationnel, même si les protocoles de benchmark rapportés peuvent agréger les exécutions différemment.

Pour une expérience grand public, un échec occasionnel peut être tolérable. Pour la paie, la conformité, l’administration des comptes ou les dossiers clients, échouer à une tâche sur sept constitue une contrainte de déploiement. Le coût dépend de la capacité du système à s’arrêter en sécurité ou à laisser derrière lui un état incorrect.

Cela ne rend pas le benchmark dénué de sens. OSWorld-Verified mesure quelque chose d’important : la capacité d’un agent à exécuter une instruction délimitée dans un environnement informatique configuré. Il offre un défi plus réaliste que les questions-réponses statiques.

Le problème commence lorsque la réussite à ce test devient une affirmation d’autonomie générale au travail. Le travail réel comporte des demandes ambiguës, des sessions interrompues, des autorisations changeantes, des informations manquantes et des conséquences qui ne peuvent pas être annulées avec une machine virtuelle neuve.

Les humains savent également reconnaître lorsque les instructions entrent en conflit avec le contexte. Ils demandent des précisions, repèrent les changements suspects et mobilisent des connaissances externes dans une tâche. Les agents informatiques optimisent souvent l’exécution de l’instruction apparente, même lorsque l’action correcte consiste à s’arrêter.

Le titre anthropic a16z est donc utile sur le plan directionnel, mais fragile sur le plan numérique. Il nous indique que Claude Fable 5 et le système d’agent qui l’entoure peuvent accomplir de nombreuses tâches de bureau standardisées. Il ne montre pas que le système est plus capable qu’un employé expérimenté dans l’ensemble des flux de travail réels.

Une affirmation plus rigoureuse de niveau humain exigerait que des humains et des agents tentent les mêmes tâches vérifiées sous des contraintes comparables. Les chercheurs devraient rapporter l’achèvement, le temps, les nouvelles tentatives, les interventions et les erreurs dommageables. Sans ces contrôles, 85 % contre 72,36 % demeure une comparaison accrocheuse entre des mesures apparentées.

Les agents informatiques mettent désormais sous pression toutes les stratégies d’automatisation

Ce score met sous pression les entreprises qui ont construit leur automatisation autour des API, des scripts et de flux de travail fixes, car les agents au niveau de l’interface peuvent atteindre des logiciels que ces méthodes ne peuvent pas couvrir.

L’automatisation traditionnelle fonctionne au mieux lorsqu’un système expose des interfaces structurées. Les développeurs relient une interface de programmation applicative, ou API, à un autre service. Les outils d’automatisation robotisée des processus suivent quant à eux des étapes et des règles d’interface prédéfinies.

Les deux approches peuvent être efficaces, mais le travail d’intégration crée des frictions. Certains outils internes n’ont pas d’API. Les logiciels plus anciens peuvent exposer des interfaces incomplètes, tandis que de petits changements de flux de travail peuvent obliger un développeur ou un consultant à reconstruire l’automatisation.

Un agent d’utilisation d’ordinateurs offre une autre voie. Il interprète les mêmes écrans qu’une personne, puis agit via l’interface existante. En théorie, cela permet à une organisation d’automatiser des logiciels sans attendre que chaque fournisseur propose une intégration dédiée.

Anthropic a introduit sa capacité d’utilisation d’ordinateurs autour de cette idée. Sa documentation sur l’utilisation d’ordinateurs décrit une boucle dans laquelle une application fournit des captures d’écran et exécute les actions de souris ou de clavier demandées. Le modèle observe chaque nouvel état avant de choisir une autre action.

Cette structure est attrayante, car elle sépare le raisonnement de l’exécution. Une entreprise peut placer le modèle dans un environnement contrôlé et décider quelles actions autoriser. L’agent n’a pas besoin d’un accès sans restriction à l’ordinateur physique d’un employé.

Le score plus élevé d’OSWorld-Verified augmente le rendement attendu de la construction de cette infrastructure. Un système qui réussit moins de la moitié de ses tâches exige une supervision constante. À 85 %, des déploiements ciblés commencent à paraître plus plausibles, surtout lorsque les échecs sont faciles à détecter.

Ce changement exerce une pression sur plusieurs groupes.

Les fournisseurs de logiciels d’entreprise doivent décider si les agents doivent utiliser leurs interfaces graphiques ou des API prises en charge. L’accès via l’interface étend la couverture, mais peut créer une charge imprévisible et contourner des flux de produit conçus pour une validation humaine.

Les fournisseurs d’automatisation doivent démontrer pourquoi les flux de travail déterministes restent précieux. Leur avantage réside dans la répétabilité, l’auditabilité et les règles explicites. Les agents informatiques les concurrencent en gérant les variations et les instructions non structurées.

Les fournisseurs de modèles sont soumis à une pression pour améliorer plus que la précision aux benchmarks. Les clients ont besoin de contrôles d’identité, de journaux d’actions, de limites d’autorisations et de moyens fiables d’interrompre l’exécution. Un modèle qui voit le bon bouton n’est qu’un composant d’un agent déployable.

OpenAI et Google sont également en concurrence dans ce domaine. Leurs systèmes utilisent différentes combinaisons de modèles visuels, de navigateurs, d’outils et d’environnements d’exécution. Les classements de benchmarks comptent, mais la portée d’un produit dépend de la sécurité avec laquelle ces composants fonctionnent ensemble.

Les développeurs d’agents spécialisés peuvent encore surpasser un modèle généraliste en limitant l’environnement. Un système conçu pour une seule application peut intégrer des analyseurs personnalisés, des règles de récupération et des contrôles de validation. L’utilisation générale d’un ordinateur couvre davantage de tâches, tandis que l’automatisation spécialisée peut offrir une plus grande prévisibilité.

Ce compromis façonnera l’adoption. Un agent généraliste pourrait rédiger un e-mail, mettre à jour une feuille de calcul et téléverser un fichier au cours d’une même session. Un système spécialisé pourrait traiter un processus de réclamation avec des contrôles plus stricts et une responsabilité plus claire.

Les entreprises doivent s’attendre à des conceptions hybrides. Un agent peut interpréter une demande et naviguer dans des états inconnus, tandis que des API exécutent des transactions sensibles. Des validateurs déterministes peuvent examiner le résultat avant toute action irréversible.

Cette conception limite l’importance d’un classement unique. La question commerciale utile n’est pas de savoir si l’utilisation d’ordinateurs par Anthropic a atteint 85 %. Elle consiste à déterminer si un système configuré peut accomplir la répartition des tâches d’une entreprise dans les limites de sa tolérance au risque.

Les organisations ont également besoin d’accéder à un contexte pertinent. Un agent qui utilise un logiciel doit savoir quel fichier, dossier client, règlement ou message s’applique. Une base de connaissances d’IA consultable peut aider les équipes à organiser ce contexte, même si elle ne remplace pas les contrôles d’exécution.

Le nouveau résultat de benchmark modifie l’hypothèse de départ. Les acheteurs n’ont plus besoin de se demander si l’automatisation au niveau de l’interface fonctionne tout court. Ils doivent déterminer où elle fonctionne de manière fiable, où elle nécessite une approbation et où une API reste plus sûre.

Ce que le score de 85 % ne mesure pas

Les preuves les plus solides contre une autonomie étendue proviennent des tâches longues, où les agents perdent encore le contexte, manquent des changements et ne vérifient pas leur propre travail.

Les tâches originales d’OSWorld impliquaient généralement environ 30 actions. C’est suffisant pour révéler des échecs d’ancrage contextuel, mais cela reste bien plus court que de nombreux flux de travail professionnels. Les missions réelles peuvent s’étendre sur plusieurs applications, documents, comptes et points de décision.

OSWorld 2.0 a été conçu pour tester ce contexte plus difficile. Son benchmark à long horizon comprend 108 flux de travail couvrant des domaines professionnels et quotidiens. Une personne compétente a besoin d’environ 1,6 heure en médiane pour accomplir une tâche.

Les flux de travail couvrent la recherche, l’ingénierie, la production créative, la finance, les opérations, l’administration, la conformité et la santé. Environ 69,6 % exigent plus d’une heure d’un utilisateur compétent. Ils incluent des informations dynamiques, des états cachés et des faits répartis entre plusieurs sources.

Un exemple consiste à soumettre une demande de remboursement. L’agent doit lire un tutoriel, examiner des reçus, vérifier des relevés bancaires et des e-mails, traiter un nouveau message, retrouver des informations sur un employé et résoudre une incohérence. Cliquer correctement n’est que le début.

Sur OSWorld 2.0, le meilleur système rapporté a terminé 20,6 % des tâches selon la métrique binaire principale. Son score partiel a atteint 54,8 %, ce qui signifie qu’il progressait souvent sans mener correctement l’ensemble du flux de travail à son terme.

Ce résultat crée le renversement central. Les agents informatiques peuvent paraître surhumains sur des tâches vérifiées plus courtes tout en restant très loin d’une performance fiable sur de longues missions professionnelles. Ces deux constats peuvent être vrais, car ils mesurent des horizons différents.

Les performances ont fortement chuté à mesure que les tâches s’allongeaient. Pour les flux de travail nécessitant entre 137 et 163 minutes humaines, aucun modèle testé n’a dépassé 10 % de réalisation binaire. Au-delà de 163 minutes, les modèles retenus n’ont achevé aucune tâche.

Le schéma d’échec a également changé. Les agents n’échouaient pas principalement parce qu’ils étaient incapables d’utiliser un contrôle de base. Ils perdaient le fil des contraintes, négligeaient de nouvelles informations, devinaient au lieu de poser des questions et sautaient la vérification finale.

Ce sont de graves défaillances en entreprise. Un employé peut souvent corriger immédiatement un clic mal placé. Un système qui oublie une condition de politique ou ignore un e-mail mis à jour peut produire un résultat qui semble complet mais qui est erroné sur le fond.

L’efficacité ajoute un autre écart. L’étude OSWorld-Human a examiné le nombre d’étapes nécessaires aux agents par rapport à des trajectoires conçues par des humains. Elle a constaté que les principaux systèmes utilisaient nettement plus d’actions que nécessaire.

Les chercheurs ont également identifié les appels au modèle pour la planification, la réflexion et l’évaluation comme des sources majeures de latence. Les étapes successives pouvaient prendre trois fois plus de temps que les premières à mesure que les trajectoires s’allongeaient. Un raisonnement plus approfondi améliorait certaines décisions tout en ralentissant le flux de travail.

Dans un exemple, modifier deux paragraphes en interligne double a pris 12 minutes à un agent. Une personne possédant une expérience informatique de base pourrait accomplir la même action en moins de 30 secondes. La seule réalisation de la tâche ne reflétait pas la différence pratique.

L’étude a indiqué que 23 % des erreurs analysées provenaient d’un mauvais ancrage visuel. Ces erreurs pouvaient ajouter jusqu’à 30 étapes inutiles à une tâche. Les comportements de récupération consommaient souvent des ressources sans garantir un résultat correct.

Cela complique de manière productive le récit anthropic a16z. Le score de 85 % reflète de véritables progrès dans l’exécution à court horizon. Les données plus récentes identifient la limite à partir de laquelle ces progrès cessent de se transférer.

Le coût reste une autre dimension absente. Un agent peut améliorer son taux de réussite en utilisant davantage de jetons de sortie, plus de tentatives ou une réflexion plus poussée. OSWorld 2.0 a constaté un compromis net entre efficacité en jetons et taux maximal de réalisation.

La configuration Claude ayant obtenu le meilleur score utilisait un budget de sortie bien plus important qu’un système GPT plus efficace. Les acheteurs ont besoin des deux mesures, car le meilleur score de benchmark ne produira pas forcément le meilleur résultat économique à grande échelle.

La sécurité n’est pas non plus capturée par un simple pourcentage de réalisation. Un agent peut techniquement terminer une tâche tout en effectuant une action inacceptable en cours de route. Il pourrait exposer des informations sensibles, accepter une invite inattendue ou effectuer un changement irréversible sans approbation.

Les environnements de benchmark partent également d’états contrôlés. Les ordinateurs de production accumulent des notifications, extensions, sessions mises en cache, demandes d’autorisation et variations d’interface. De petites différences peuvent faire échouer une stratégie d’exécution qui fonctionnait dans une machine virtuelle standard.

Le contenu web introduit des risques adversariaux. Une page peut contenir du texte qui tente de rediriger l’agent ou de demander des identifiants. Les systèmes ont besoin d’une distinction fiable entre l’instruction de l’utilisateur et le contenu non fiable affiché pendant la tâche.

Les agents d’utilisation d’ordinateurs ont donc besoin de défenses à plusieurs niveaux. Les organisations peuvent isoler les sessions, restreindre les domaines, limiter les autorisations, exiger une confirmation et valider les résultats par des systèmes séparés. Ces contrôles réduisent les risques, mais ils restreignent aussi le sens de l’opération autonome.

Un score de benchmark doit éclairer les limites de déploiement plutôt que les effacer. Les cas d’usage les plus solides à court terme sont limités, réversibles et faciles à inspecter. Les actions à fort impact doivent toujours passer par des contrôles déterministes ou une approbation humaine.

Trois signaux montreront si le résultat se transfère

La prochaine étape sera déterminée par la réalisation de tâches longues, la fiabilité dès la première tentative et une adoption mesurable en production, plutôt que par un autre record isolé de classement.

Le premier signal est la performance sur OSWorld 2.0 ou sur un autre benchmark comparable à long horizon. Le résultat de 85 % de Claude Fable 5 sur OSWorld-Verified devient bien plus convaincant si le même modèle améliore la frontière de 20,6 % de réalisation sur des flux de travail étendus.

Un progrès partiel ne suffira pas. Une tâche professionnelle ne crée souvent de la valeur que lorsque chaque étape requise est terminée et vérifiée. Les chercheurs devraient publier ensemble le taux de réalisation binaire, le crédit partiel, l’utilisation de jetons, le nombre d’actions et la fréquence des interventions.

Un gain important sur les tâches longues renforcerait l’argument selon lequel les modèles peuvent préserver les objectifs et les contraintes dans des environnements changeants. Un gain modeste suggérerait que le résultat de 85 % dépend principalement d’interactions plus courtes et limitées.

Le deuxième signal est la fiabilité dès la première tentative dans des conditions standardisées. Les fournisseurs devraient publier le nombre d’exécutions, les limites d’actions, les paramètres de raisonnement et les cadres d’évaluation derrière leurs scores. Des répétitions indépendantes rendraient les comparaisons entre modèles plus crédibles.

La variance compte, car les utilisateurs ne font pas l’expérience d’une performance moyenne de benchmark. Ils vivent une exécution à la fois. Un système qui alterne réussite et échec génère des coûts de supervision, même lorsque son résultat moyen semble solide.

Les rapports devraient également distinguer la performance directe du modèle des améliorations apportées par le cadre agentique. Un planificateur, un module d’ancrage visuel, un mécanisme de nouvelle tentative et un vérificateur peuvent relever le score final. Les acheteurs doivent savoir quels composants ont produit le gain et s’ils peuvent le reproduire.

Des résultats cohérents dès la première exécution renforceraient l’argument du niveau humain. Des scores nécessitant des tentatives répétées ou des budgets de raisonnement inhabituellement élevés l’affaibliraient pour un déploiement courant.

Le troisième signal est constitué de preuves en production issues de flux de travail métier délimités. Des rapports utiles incluraient les taux de réalisation, le temps d’exécution moyen, la fréquence des escalades et la part des résultats corrigés par des personnes.

Les déploiements les plus instructifs concerneront des logiciels dépourvus d’API pratiques. C’est là que les agents au niveau de l’interface offrent l’avantage le plus net par rapport à l’intégration conventionnelle. C’est aussi là que les changements d’interface peuvent révéler leur fragilité.

Observez si les organisations font évoluer les agents de l’observation vers l’action. Un système qui recueille des informations et prépare un brouillon comporte moins de risques qu’un système qui soumet des paiements, modifie des autorisations ou contacte des clients.

L’extension à des actions à plus fort impact indiquerait une confiance croissante dans la technologie et ses contrôles. Le maintien de restrictions aux brouillons et aux tâches en lecture seule montrerait que les progrès des benchmarks n’ont pas supprimé les préoccupations opérationnelles.

Les données Anthropic a16z méritent l’attention, car les agents d’utilisation d’ordinateurs se sont améliorés bien plus vite que ne le suggéraient les résultats initiaux d’OSWorld. Le score rapporté de 85 % de Claude Fable 5 marque une évolution crédible des capacités à court horizon.

Elles n’établissent pas que les agents surpassent désormais les personnes dans l’utilisation générale des ordinateurs. Cette conclusion exige des tests équivalents, une exécution efficace, des premières tentatives stables et une réussite sur des flux de travail longs.

Pour les développeurs et les acheteurs, la réponse pratique n’est ni le rejet ni l’autonomie immédiate. Testez les agents sur des tâches représentatives, mesurez chaque intervention et séparez les actions réversibles de celles qui ont des conséquences. Posez ensuite la question qui compte : le résultat anthropic a16z résiste-t-il au contact de votre travail réel ?