Mercor lève 750 M$ pour entraîner et évaluer l'IA, pour une valorisation de 20 Md$

L'agent répond joliment dans le chat, mais oublie de vérifier les conditions du contrat au moment de traiter un remboursement. Pour un product manager, c'est un scénario raté ; pour un développeur, c'est une erreur de plus que le classement public des modèles n'a pas permis de prévoir. Mercor a bâti son activité sur cet écart : l'entreprise recrute des spécialistes pour évaluer l'IA sur un véritable travail professionnel et préparer des données pour son entraînement ultérieur.

Le 10 novembre, l'entreprise a annoncé un tour de série D de 750 M$ pour une valorisation de 20 Md$. Pour une équipe qui déploie des agents, le plus utile ici est l'objet même de l'investissement : définir ce qu'est un travail correctement exécuté devient une tâche à part entière, et de grande ampleur. Les conditions de l'opération sont publiées dans l'annonce de Mercor.

Pourquoi une bonne réponse ne suffit pas

Prenons une boutique en ligne qui a confié les remboursements à un agent. Le client écrit : l'article est cassé, le ticket de caisse est perdu, la commande est passée via un partenaire. Le modèle connaît les règles générales de communication avec les clients. Mais il doit encore retrouver l'achat, comprendre les exceptions, choisir un mode de compensation autorisé et modifier correctement l'enregistrement dans le système.

Évaluer un tel agent demande plus que de juger la politesse de la réponse. Un expert doit décrire les actions admissibles et le résultat attendu : quand on peut rembourser, quand une vérification supplémentaire est nécessaire, quelles modifications doivent apparaître dans le système comptable. Les développeurs peuvent ensuite rejouer le scénario après un changement de modèle, de prompt ou d'outil.

Il s'agit d'un exemple hypothétique, et non d'un projet client décrit par Mercor. Il montre pourquoi il faut des évaluations sur les tâches d'une entreprise donnée. Un même modèle peut très bien expliquer les règles de remboursement et se tromper en les appliquant. Si l'on n'évalue que le message final, l'erreur reste invisible jusqu'à la réclamation d'un client.

Pour l'équipe, l'action à mener est simple : commencer par rassembler de vraies demandes et des critères de réussite. Le choix du modèle devient alors une décision d'ingénierie vérifiable. On peut comparer la qualité, le coût d'un scénario mené à terme et le nombre de cas nécessitant un humain.

Ce que disent les chiffres, et ce qu'ils ne montrent pas

Selon le digest de Latent Space fourni, Mercor a atteint un rythme annuel de revenus de 3 Md$, après 1 Md$ en février et 2 Md$ en juin. Il faut lire cet indicateur littéralement : les revenus courants sont extrapolés sur un an. Cela ne signifie pas que l'entreprise a déjà encaissé 3 Md$ sur douze mois écoulés.

Dans l'annonce du tour de table, Mercor précise aussi que l'opération inclut un rachat d'actions de salariés. La répartition n'est pas publiée ; on ne peut donc pas considérer automatiquement les 750 M$ comme des fonds destinés au développement. La valorisation de 20 Md$ ne dit rien non plus, à elle seule, de la rentabilité, de la fidélisation des clients ou de la marge du travail d'expertise.

Un autre chiffre issu de la déclaration de la direction attire particulièrement l'attention : les dépenses d'inférence de Mercor sont trois fois supérieures à sa masse salariale. L'entreprise estime que cela se justifie. Mais sans méthode de calcul ni ventilation des coûts, cet indicateur ne fournit pas de budget prêt à l'emploi pour une autre startup. Un fondateur a plutôt intérêt à calculer sa propre économie : combien coûte une tâche réussie, en tenant compte des nouvelles tentatives et de la vérification humaine.

Comment l'appliquer à son produit

Conclusion pratique de la rédaction : il vaut mieux commencer par un seul processus doté d'un résultat final clair. Par exemple, traiter un remboursement, rapprocher des documents ou corriger une catégorie d'erreurs donnée. Il faut des exemples de cas courants, d'exceptions et de situations où l'agent doit s'arrêter.

Il faudra ensuite une vérification indépendante. Si le modèle a vu toutes les tâches pendant le réglage, un score élevé peut refléter un surajustement à des exemples connus. Il convient de conserver une partie des scénarios à part et de confier aux experts l'examen des cas litigieux. Il est aussi utile de mesurer la part du travail que l'agent mène réellement à terme sans corrections.

Cette approche a un coût : le temps des spécialistes, la maintenance des données de test et la mise à jour des règles au rythme du produit. Un jeu d'évaluations maison peut lui aussi devenir obsolète ou manquer des exceptions importantes. Le tour de table de Mercor ne prouve pas que ces problèmes sont résolus. Il montre l'intérêt des investisseurs pour l'infrastructure qui entoure le déploiement de l'IA. Pour une équipe produit, la prochaine étape est très concrète : constituer un ensemble de tâches de travail et vérifier quelle part l'agent exécute déjà de façon fiable.