Ce que la validation humaine change pour vos agents IA

Le travail qui semble le plus facile à automatiser peut faire partie des plus difficiles à mener à terme pour un agent. Upwork a constaté que le développement web et logiciel obtenait les meilleurs résultats dans un benchmark d’agents, suivi par la data science, tandis que le support administratif affichait la moyenne la plus faible sur trois modèles. Deux modèles n’ont mené à bien que 6% des tâches de support administratif. Pour les dirigeants qui décident où automatiser, la question utile est de plus en plus de savoir si l’organisation peut déterminer de manière fiable quand une tâche est réellement terminée.

Le travail qui paraît le plus simple peut être difficile à automatiser

Cette question est au cœur de l’évolution d’Upwork, qui ne se présente plus comme une marketplace de talents mais comme une « work delivery platform ». Une marketplace met en relation un client avec une personne ; le modèle plus récent d’Upwork part d’un résultat attendu et détermine quelle combinaison de personnes et de machines doit le produire. Upwork a un intérêt commercial dans cette manière de présenter les choses, car un modèle de delivery fondé sur l’orchestration entre humains et agents élargit le rôle que sa plateforme peut jouer. Andrew Rabinovich, qui dirige l’IA chez Upwork, a présenté le cadre sous-jacent de décomposition des tâches à AI4 et, en s’appuyant sur deux décennies de données de plateforme, estime que le travail sur Upwork peut être décomposé en environ 500 à 1 000 « unités atomiques de travail » récurrentes.

Ces unités rendent peu fiables les hiérarchies simples de l’automatisation. Rabinovich cite la création de logos et la rédaction de résumés comme des tâches de bas niveau déjà automatisées, alors que le benchmark d’Upwork a constaté des taux d’achèvement en rédaction allant de 4% à 51% selon le modèle, Gemini étant à 4%. Pendant ce temps, le développement web et logiciel arrivait en tête des catégories testées. Un travail qui semble routinier peut malgré tout contenir des critères qu’un agent ne peut pas satisfaire de manière constante ou qu’une organisation ne peut pas évaluer à faible coût.

Les écarts entre catégories mettent en évidence une distinction entre produire un livrable et établir que la tâche est terminée. Un agent peut créer un document, une feuille de calcul, un design ou une base de code tout en échouant encore sur des exigences qui déterminent si le livrable est acceptable. Une fois le travail découpé en unités plus petites et attribué à des machines, chaque unité a besoin d’une définition fiable de ce qui est considéré comme terminé. L’économie de l’automatisation dépend de cette définition, car un résultat qui exige encore un travail ou un jugement substantiel conserve une partie du coût de production.

Upwork a testé l’achèvement complet

Pour mesurer cette distinction, Upwork a construit le Human+Agent Productivity Index, ou HAPI, à partir de travail réel de clients plutôt que de tâches synthétiques. Sa méthodologie, documentée dans un article publié sur arXiv en décembre, s’appuyait sur 322 missions que des clients payants avaient publiées et que des freelances humains avaient déjà menées à bien avec acceptation par le client. Des freelances experts ont ensuite créé une grille d’évaluation spécifique à chaque mission avec 5 à 20 critères d’acceptation. Ils ont classé chaque critère comme critique, important, optionnel ou écueil, et l’achèvement exigeait que chaque critère critique et important soit validé.

Cette règle rend l’achèvement plus exigeant que la simple production d’un livrable plausible. Claude, Gemini et GPT-5 ont chacun exécuté des tâches selon ces grilles, de sorte qu’un résultat pouvait satisfaire des critères individuels tout en échouant sur la mission dans son ensemble. Pour un acheteur, cela ressemble à la décision au moment de la livraison : savoir si le résultat peut être accepté. Comme Upwork exploite la marketplace et bénéficie commercialement du fait de démontrer un rôle pour sa plateforme dans une delivery humain-agent, HAPI doit être lu comme le cadre de mesure d’Upwork et évalué à l’aune de sa conception.

La conception a d’abord restreint la charge de travail aux missions que les agents avaient une chance raisonnable de terminer. Upwork a limité le benchmark à des contrats à prix fixe, à jalon unique, avec un périmètre clairement défini, même si leur durée allait encore de neuf heures à plus de 100 jours. Les missions ouvertes et complexes pour lesquelles les agents étaient jugés sans chance raisonnable de succès ont été exclues. Upwork décrit ces missions exclues comme la « vaste majorité » du travail sur sa plateforme, de sorte que la charge de travail testée par HAPI représente un sous-ensemble délibérément tractable du travail client.

Au sein de ce sous-ensemble, le benchmark a également contraint l’environnement opérationnel des agents. Chaque modèle pouvait lire l’annonce de mission et les pièces jointes, formuler un plan, produire le livrable et s’arrêter, mais il ne disposait ni de recherche web, ni de données externes, ni d’outils supplémentaires, ni d’entraînement spécifique à la tâche. Les auteurs décrivent les résultats comme prudents par rapport à des systèmes d’agents plus riches. Un agent de production équipé de navigateurs, d’API et d’outillage spécialisé pourrait se comporter différemment.

Ces choix de conception influencent l’interprétation dans des directions opposées. Exclure les missions plus difficiles et plus ouvertes donne aux agents une charge de travail plus favorable, tandis que limiter les outils leur donne un environnement d’exécution moins capable. HAPI ne peut donc pas fournir une borne supérieure ou inférieure simple pour le déploiement d’une organisation. Sa contribution méthodologique utile est plus étroite : définir l’achèvement à l’avance, puis tester si le système atteint l’intégralité du résultat requis.

Selon cette norme, l’achèvement complet par agent seul allait de 4% à 68%, selon le modèle et la catégorie. Le développement web et logiciel arrivait en premier, la data science suivait, et le support administratif arrivait en dernier en moyenne. Aucun résultat testé n’a atteint un achèvement universel, même lorsque l’expérience a ensuite introduit un guidage expert. Comme l’éventail est large, une affirmation générique sur la « capacité des agents » dit peu de chose sur un déploiement précis tant que la structure de la tâche et les conditions d’acceptation ne sont pas également connues.

Ces conditions d’acceptation changent aussi la manière dont les dirigeants doivent interpréter les démonstrations. Un système peut créer rapidement un livrable qui paraît avancé tout en manquant une exigence critique enfouie dans une pièce jointe ou en violant une condition d’acceptation. HAPI considère ce résultat comme inachevé parce que le résultat exigé par le client reste incomplet. Un business case d’automatisation a besoin de la même discipline lorsque les économies projetées reposent sur l’idée que le travail n’exige plus qu’une autre personne le termine.

La vérification constitue une ligne de partage utile

Les résultats d’achèvement font de la vérification une variable utile du workflow. Certains résultats se prêtent à un contrôle objectif : du code peut compiler et passer des tests, tandis qu’un autre modèle peut vérifier une traduction. Rabinovich caractérise l’évaluation du travail qualitatif comme largement non résolue, car une personne dotée de jugement doit décider si le résultat est suffisamment bon. Il estime que plus de 90% du travail sur la plateforme Upwork est qualitatif, une affirmation qui compte aussi commercialement pour Upwork parce que son modèle de delivery peut créer une demande de jugement humain aux côtés des agents.

Pour une organisation, la première question opérationnelle est de savoir si un résultat automatisé peut être testé par rapport à un critère objectif. Une suite de tests, un rapprochement, une règle de conformité ou une correspondance numérique peuvent transformer l’acceptation en procédure répétable. Un travail doté d’un tel critère, contenu dans une seule fonction et un seul format, est un candidat solide à un déploiement autonome une fois que la fiabilité mesurée est suffisamment élevée. La vérification donne à l’organisation un moyen fiable de détecter les échecs ; elle ne rend pas à elle seule l’agent capable de les éviter.

La question suivante est de savoir si le travail reste dans ce contexte circonscrit. Un workflow qui traverse le développement backend, le frontend, la rédaction et la validation de marque introduit des transferts entre fonctions et formats, même lorsque des composants individuels disposent de contrôles objectifs. Automatiser ces composants peut toujours avoir du sens, mais une personne reste responsable des transferts. Comme l’achèvement appartient au workflow dans son ensemble, les taux d’automatisation au niveau des composants ne peuvent pas se substituer à l’acceptation de bout en bout.

L’exemple de génération de leads de HAPI montre pourquoi les critères objectifs et la capacité d’exécution doivent être séparés. La page HAPI fournit cinq exemples de missions avec livrables téléchargeables, dont une mission qui exigeait de réduire une feuille de calcul d’applications mobiles aux entreprises ayant leur siège aux États-Unis, de trouver deux à quatre contacts marketing par entreprise et de remplir neuf colonnes spécifiées. La grille était objectivement vérifiable, le travail restait dans une seule fonction et un seul format, et aucun de ses critères ne dépendait du goût. Le livrable produit par l’agent seul a pourtant échoué à l’évaluation.

Le guidage expert n’a pas non plus permis à ce livrable particulier de réussir. Ce cas sépare la capacité à déterminer le succès de la capacité à le produire : la vérification objective rend l’échec observable, mais un modèle peut toujours manquer des données, du raisonnement, de l’accès aux outils ou de la qualité d’exécution nécessaires pour satisfaire les critères. La vérifiabilité est donc un diagnostic pour un plan d’automatisation. Le fonctionnement autonome dépend toujours d’une fiabilité d’exécution mesurée.

L’intervention d’experts modifie l’achèvement mesuré

Là où le retour d’experts a aidé, les changements mesurés ont été substantiels. Sur les tâches de faible complexité, Claude, Gemini et GPT-5 ont tous affiché un taux d’achèvement plus élevé après une intervention experte. Les résultats exacts montrent à la fois l’ampleur du changement et les différents points de départ.

Ces évolutions représentaient des gains absolus d’environ 11 à 14 points de pourcentage, tandis qu’Upwork met aussi en avant commercialement une hausse relative « jusqu’à 70% ». Ce dernier chiffre vient du faible point de départ de GPT-5 : sa progression était de 13,9 points de pourcentage, mais beaucoup plus importante lorsqu’elle est exprimée relativement à son taux d’achèvement initial. Les deux calculs sont mathématiquement valides, mais ils répondent à des questions différentes. Les dirigeants qui estiment combien de missions supplémentaires deviennent acceptables ont besoin du changement absolu d’achèvement en plus de l’amélioration relative.

L’effet de l’intervention variait aussi fortement selon la catégorie. Le taux d’achèvement de Claude en data science est passé de 64% à 93% après retour, tandis que Gemini en rédaction passait de 4% à 16%. Gemini en data science n’a montré aucune amélioration. Ces différences rendent inadapté un chiffre unique de progression pour la planification des workflows, car le choix du modèle comme la catégorie de tâche modifiaient le résultat observé.

Dans l’ensemble de l’expérience, les deuxièmes tentatives effectuées après retour d’experts ont surpassé les premières tentatives, et environ un emploi initialement échoué sur cinq a été sauvé dans ces conditions favorables. Pourtant, le plafond global d’achèvement annoncé pour le modèle le plus performant dans la discussion sur le guidage humain était de 51%. Les exécutions guidées par l’humain ont aussi pris 14,5 minutes contre 3,6 minutes pour les exécutions par agent seul, soit environ quatre fois plus longtemps. De meilleurs résultats ont donc été obtenus via un processus qui consommait aussi davantage de temps mesuré.

La comparaison expérimentale étaye une affirmation causale précise : un second passage après retour d’experts a mieux fonctionné que le premier. HAPI n’a pas exécuté de seconde tentative appariée par agent seul pour les missions échouées, de sorte que sa conception ne permet pas de séparer la contribution du retour d’experts du bénéfice d’une nouvelle tentative. L’amélioration complète ne peut donc pas être attribuée à la seule intervention experte. Pour la planification du déploiement, une nouvelle tentative et une revue experte sont deux intrants de production différents et doivent être testés séparément.

Les évaluateurs représentent aussi un niveau spécifique de capacité humaine. Chaque évaluateur avait un Job Success Score de 100% et le statut Top Rated ou Top Rated Plus. Collectivement, ils avaient gagné plus d’un million de dollars sur Upwork et cumulé plus de 96 000 heures sur la plateforme. Les organisations qui recherchent des effets d’intervention comparables doivent donc planifier en fonction du type de capacité humaine expérimentée utilisé dans le benchmark plutôt que de traiter la revue comme un rôle interchangeable.

Cette population d’évaluateurs fixe le périmètre de ce que l’expérience démontre sur la supervision. Les résultats mesurés décrivent le retour de ces freelances accomplis ; ils n’établissent pas un effet équivalent pour un évaluateur junior ou une autre population d’évaluateurs. L’expertise des évaluateurs devient donc une variable de déploiement qu’une organisation doit tester dans son propre workflow. L’étiquette « human in the loop » est trop large pour la planification des effectifs ou financière, car la boucle peut contenir des personnes au jugement et au coût très différents.

L’exemple échoué de génération de leads renforce cette distinction. Une tâche bien définie et objectivement vérifiable peut échouer même après guidage expert, tandis que l’expérience plus large peut montrer une amélioration sans isoler la cause complète de cette amélioration. Les organisations doivent donc tester la conception de la vérification, les nouvelles tentatives et l’expertise humaine comme des variables opérationnelles distinctes. Les combiner dans l’hypothèse générale qu’une revue réparera les échecs des agents donne au business case plus de certitude que l’expérience n’en établit.

L’architecture d’Upwork inclut l’orchestration et le jugement

Les mêmes questions opérationnelles apparaissent dans l’architecture produit d’Upwork elle-même, où l’entreprise a un intérêt commercial à positionner l’orchestration comme une composante de la delivery du travail. UMA, son système d’IA phare, interprète l’intention d’un client, décompose le travail demandé, oriente les composants vers des personnes ou des machines et vérifie le travail produit. Son rôle couvre l’orchestration à travers le workflow plutôt que l’exécution autonome de chaque partie d’une mission. Pour les acheteurs, le point pertinent est que le système commercial d’Upwork lui-même attribue des fonctions explicites au routage et à la vérification.

La modélisation économique d’Upwork modifie de la même manière la méthode de delivery en fonction des conséquences d’un échec. L’exécution par agent seul est privilégiée pour les tâches de faible valeur où un échec coûte peu ; la collaboration devient préférable au milieu ; et l’exécution entièrement humaine l’emporte pour les tâches de grande valeur lorsque le coût d’un mauvais résultat dépasse les économies de l’automatisation. Comme Upwork peut en bénéficier lorsque le travail continue d’utiliser des personnes fournies via sa plateforme, ce modèle comporte une incitation commerciale en faveur des combinaisons humain-agent. Sa variable de décision utile est le coût attendu de l’échec, en plus du coût nominal de production d’un résultat.

Cette vision par le coût de l’échec rend particulièrement important le travail autonome fondé sur le jugement. Ce type de travail peut s’inscrire proprement dans un seul domaine, tout en exigeant encore qu’une personne informée évalue la qualité pour l’accepter, et HAPI a trouvé ses plus fortes progressions dans le travail fondé sur le jugement. L’apport humain dans ce workflow fait partie de la production d’un résultat livrable. Une prévision qui classe le jugement requis comme une simple supervision accessoire sous-estimera les ressources nécessaires pour faire fonctionner le système.

Le cas de planification devient plus exigeant lorsque le travail fondé sur le jugement traverse aussi plusieurs fonctions. Les agents ont échoué dans chaque catégorie testée correspondant à cette combinaison, ce qui fait du travail humain assisté par l’IA l’hypothèse appropriée pour planifier un déploiement. La responsabilité transverse ajoute des décisions aux frontières, tandis que l’acceptation qualitative ajoute du jugement au moment de la livraison. Ces deux formes de travail ont besoin d’une propriété explicite et d’un financement dans le modèle opérationnel.

La revue relève de l’économie de production lorsque le jugement est requis

Une fois que le jugement humain devient une partie de la delivery, son traitement comptable affecte le business case de l’automatisation. Les organisations traitent déjà ces limites en plaçant des humains dans la boucle, en conservant des personnes responsables des transferts interfonctionnels et en utilisant des évaluateurs expérimentés lorsque les résultats n’ont pas de test d’acceptation objectif. Si l’intervention d’un expert est requise avant que le travail puisse être livré, cette revue consomme de la capacité de production. Appeler cette même capacité supervision peut donner l’impression que le workflow coûte moins cher sans changer le travail nécessaire pour l’exploiter.

Pour une automatisation fortement fondée sur le jugement, le temps de revue doit donc figurer aux côtés des coûts de modèle et des autres intrants de production, surtout lorsque l’intervention exige des collaborateurs seniors rares. Les exécutions guidées par l’humain plus longues dans HAPI rendent visible le temps de processus supplémentaire, tandis que la comparaison non appariée avec une nouvelle tentative signifie que l’ensemble de l’écart ne peut pas être attribué spécifiquement au retour. La question opérationnelle reste concrète : combien de temps expert le workflow déployé consomme-t-il par résultat accepté ? Cette mesure relie directement la revue à l’économie unitaire.

Mesurer ce temps exige que les entreprises identifient les personnes qui détiennent réellement le jugement d’acceptation. Ces personnes peuvent être dispersées entre niveaux de séniorité, familles de métiers et centres de coûts, ce qui peut masquer la dépendance et son coût de remplacement. L’expression « human in the loop » laisse donc sans réponse une question critique de staffing : quel humain a suffisamment d’expérience et d’autorité pour prendre la décision d’acceptation ? La planification de production exige que le rôle, la capacité et l’autorité soient explicites.

Une fois ce rôle explicite, le problème de staffing dépasse les évaluateurs d’aujourd’hui. Si les entreprises suppriment le travail de production d’entrée et de milieu de carrière tout en conservant des experts seniors comme évaluateurs, elles peuvent réduire les occasions par lesquelles les futurs experts développent le jugement nécessaire pour contester le résultat d’un modèle. L’horizon pertinent peut arriver vite : l’exemple de main-d’œuvre ici demande qui deviendra assez senior pour contredire un modèle dans trois ans. Un plan d’automatisation peut préserver l’expertise actuelle tout en affaiblissant la filière qui produit ses remplaçants.

Ce risque de développement de la main-d’œuvre compte surtout là où l’acceptation dépend du jugement, car un test déterministe ne peut pas porter toute la charge de la vérification. Les dirigeants qui construisent le business case de l’automatisation doivent donc tenir compte de la capacité de revue actuelle et de son offre future. L’estimation d’Upwork selon laquelle plus de 90% de son travail est qualitatif explique pourquoi cette question compte pour sa plateforme autant que pour les acheteurs. L’entreprise en bénéficie si la demande de jugement humain reste une composante d’un marché de plus en plus automatisé.

L’hypothèse de Rabinovich sur le marché futur étend cette logique commerciale aux agents eux-mêmes. Il s’attend à ce que les agents puissent créer de la demande pour les humains en les recrutant en temps réel lorsqu’ils atteignent des résultats qu’ils ne peuvent pas vérifier indépendamment. Ses exemples incluent une question médicale, une recommandation de restaurant et des questions de goût. Dans ce modèle, le livrable de l’humain passe de l’achèvement d’un projet entier à la validation du résultat de l’agent.

Parce que la validation humaine en temps réel pourrait générer du travail pour Upwork, l’hypothèse de Rabinovich s’aligne sur l’intérêt commercial de l’entreprise et doit être évaluée comme la prévision d’un dirigeant de plateforme. La question opérationnelle ne dépend pas du développement ou non de ce marché. Si la valeur humaine se déplace vers la validation, les entreprises doivent savoir où réside le jugement, qui a l’autorité pour l’exercer et quelle part de cette capacité est disponible. Le seul volume de production donne alors une mesure incomplète du rôle humain.

Reprenez le cas d’automatisation à partir de l’acceptation, de l’autorité et du coût de revue

Ces économies de production peuvent être testées avec un travail qui passe déjà dans les systèmes d’une organisation. Prenez dix résultats du workflow le plus automatisé et donnez-les à la personne qui possédait auparavant ce travail. Demandez combien auraient été envoyés à un client sans modification. La proportion obtenue donne un taux d’automatisation lié à un travail livrable, y compris la présence éventuelle d’un travail d’achèvement caché.

Ce test d’acceptation doit conduire directement à l’autorité. Identifiez la personne ayant autorité pour rejeter un résultat automatisé dans chaque workflow, puis déterminez si cette personne peut exercer cette autorité sans escalade. Un évaluateur nominal qui ne peut pas arrêter la livraison ne peut pas fournir un mécanisme d’acceptation fiable lorsque la qualité dépend du jugement. Le workflow a besoin que l’autorité de rejet soit aussi explicite que l’autorité de génération.

Lorsque la décision d’acceptation exige du jugement, requalifiez le temps passé à examiner le résultat de l’agent comme de la production et refaites le calcul financier. Incluez le niveau d’expertise réellement requis au lieu de supposer que la capacité de revue est interchangeable. Un workflow peut toujours produire des économies intéressantes avec cette comptabilité. La décision obtenue reflétera alors le système opérationnel que l’organisation doit réellement doter en personnel.

La même discipline d’acceptation doit s’étendre aux contrats fournisseurs. Examinez le sens exact de l’achèvement, car une acceptation critère par critère et une tâche simplement tentée décrivent des résultats matériellement différents. HAPI a utilisé la définition la plus stricte en exigeant que chaque critère critique et important soit validé. Pour un système déployé, l’exigence opérationnelle est une définition fiable de l’achèvement, accompagnée de l’autorité et de la vérification financée nécessaires pour l’appliquer.

Réflexions finales

La frontière pratique de l’automatisation par l’IA n’est pas de savoir si un agent peut produire un travail utile. Elle est de savoir si l’organisation peut déterminer, de manière fiable et économique, que le travail est terminé. Le benchmark d’Upwork montre qu’il s’agit de capacités différentes. Même des tâches objectivement vérifiables peuvent échouer, tandis qu’une intervention experte peut améliorer l’achèvement sans éliminer le besoin de capacité humaine.

Pour les dirigeants, cela déplace le sujet de l’automatisation de la performance du modèle vers la conception opérationnelle. Les critères d’acceptation, les coûts d’échec, l’expertise des évaluateurs, les politiques de nouvelle tentative et les transferts interfonctionnels affectent tous le coût d’un résultat accepté. Là où un jugement humain est requis pour livrer le travail, ce jugement est un intrant de production et doit apparaître en conséquence dans les plans de staffing et les calculs de ROI.

Les meilleurs candidats à l’automatisation ne sont donc pas nécessairement les tâches qui paraissent routinières. Ce sont les workflows où le succès peut être défini clairement, où les échecs peuvent être détectés de manière fiable et où le coût de la vérification n’efface pas les gains de l’automatisation. Lorsque ces conditions ne sont pas réunies, les dirigeants ont besoin d’une responsabilité humaine explicite plutôt que de supposer qu’un agent finira par devenir suffisamment fiable.

La question de management n’est plus simplement de savoir quelle quantité de travail l’IA peut exécuter. Elle est de savoir quelle quantité de travail l’IA peut mener à terme selon un niveau acceptable, qui détermine ce niveau et ce que l’organisation doit dépenser pour rendre cet achèvement fiable.