OpenAI affirme avoir franchi un cap qu’elle s’était fixé l’an dernier : un système d’IA capable d’agir comme un stagiaire de recherche sous la direction d’un humain. L’entreprise définit ce cap de manière étroite, mais utile. Le système peut accomplir des tâches de recherche bien délimitées qui demanderaient plusieurs jours à une personne expérimentée, tandis qu’un humain reste chargé de formuler la question, d’évaluer le résultat et de décider de la suite.

Poste de recherche conceptuel avec des hypothèses reliées, des fiches de preuves et un résultat vérifié

Cette distinction compte davantage que l’étiquette. Le changement important n’est pas qu’un chatbot puisse produire une note de recherche plausible. C’est qu’un modèle de pointe puisse désormais prendre part à la partie répétitive et intermédiaire de la recherche : lire des documents techniques, écrire et déboguer du code, lancer des expériences, examiner les sorties, comparer des options et préparer un résultat destiné à la revue humaine. Les propres mesures internes d’OpenAI laissent penser que cette évolution modifie déjà l’économie du travail de recherche.

Ces mêmes mesures font aussi apparaître la contrepartie. Lorsque les agents rendent peu coûteuses la production d’hypothèses et l’exécution d’expériences, la ressource rare devient la preuve digne de confiance. Les équipes peuvent produire davantage d’idées candidates qu’elles ne sont capables d’en valider. Une boucle de recherche plus rapide peut donc accélérer la découverte, ou fabriquer une pile plus importante de conclusions séduisantes mais fragiles. La question opérationnelle n’est plus seulement de savoir si une équipe devrait utiliser un agent de recherche IA. Il faut concevoir un flux de travail où la vitesse de l’agent ne dépasse pas la capacité de l’équipe à vérifier ce qu’il fait.

Ce qu’OpenAI a effectivement annoncé

Le compte rendu publié par OpenAI le 6 septembre, « Accélérer la recherche : un regard depuis l’intérieur d’OpenAI », décrit une transformation interne plutôt qu’un résultat de référence obtenu sur un produit public. L’entreprise explique que ses chercheurs utilisent de plus en plus des agents de programmation tout au long de la journée, souvent dans des sessions concurrentes, et que ces agents prennent en charge des tâches plus complexes avec des taux de réussite plus élevés.

Quelques chiffres permettent de mieux mesurer l’ampleur du phénomène. À la mi-août, OpenAI indique que le chercheur médian de son organisation de recherche consommait plus de 600 dollars d’inférence par jour aux tarifs de l’API. L’utilisateur situé au 90e percentile dépassait 7 000 dollars par jour. Au total, l’organisation utilisait l’équivalent de 3,1 journées de travail d’agent pour chaque journée de travail humaine. Cela ne signifie pas qu’un agent travaille huit heures d’affilée, ni que sa production équivaut à celle de trois chercheurs humains. Il s’agit d’une mesure du temps d’exécution et de l’utilisation de jetons accumulés sur de nombreuses sessions concurrentes.

OpenAI indique également que le nombre d’expériences par expérimentateur actif a atteint un sommet en août, par rapport à la période de suivi commencée en janvier 2025. L’entreprise se montre prudente dans son interprétation : cette progression est corrélée à l’adoption accrue des agents de programmation, tandis que les capacités de calcul disponibles ont elles aussi augmenté, et le nombre d’expériences ne constitue qu’un indicateur indirect des progrès de la recherche. Davantage d’expériences peuvent signifier un apprentissage plus rapide. Cela peut aussi produire plus de travail en double, des comparaisons plus bruitées et davantage d’occasions d’optimiser un indicateur commode.

La publication décrit assez clairement les domaines où les agents sont utiles. Le code de recherche et d’infrastructure reste la catégorie principale, mais l’assistance technique et les tâches de surveillance ont également progressé. La planification de haut niveau demeure une faible part de la production des agents. Cette limite est importante. Le système est le plus efficace lorsqu’une personne peut décrire une tâche bornée et fournir un moyen d’en tester le résultat. Rien ne prouve qu’un modèle soit capable de choisir de manière autonome un programme de recherche utile.

OpenAI qualifie le cap actuel de « stagiaire de recherche automatisé » et affirme progresser vers un « chercheur IA automatisé » d’ici mars 2028. Il s’agit de jalons définis par l’entreprise, et non d’une certification reconnue par l’ensemble du secteur. Ils restent utiles parce qu’ils décrivent une progression concrète : automatiser d’abord des éléments de recherche bien spécifiés, puis vérifier si le système peut prendre en charge un jugement et une coordination plus larges. Les équipes devraient appliquer la même rigueur lorsqu’elles évaluent leurs propres déploiements.

L’unité de travail est en train de changer

La gestion traditionnelle de la recherche considère souvent un projet comme une suite d’activités humaines : une personne lit la littérature, propose une idée, implémente une méthode, lance des tests, analyse le résultat et rédige le compte rendu. Un agent peut condenser plusieurs de ces étapes dans une seule session, ou exécuter de nombreuses sessions en parallèle. Les dépendances logiques du projet restent les mêmes, mais le temps qui les sépare devient beaucoup plus court.

Cette évolution modifie ce que voit un responsable. Une équipe qui avait autrefois cinq idées en une semaine peut en avoir cinquante variantes le vendredi. Une équipe qui attendait auparavant qu’un ingénieur prépare une expérience peut demander à plusieurs agents de préparer simultanément des implémentations concurrentes. Un chercheur peut passer moins de temps à réparer des fichiers de configuration et davantage à décider quelle question mérite une nouvelle itération.

Le risque est de faire du débit un indicateur de réussite trompeur. Les validations de code, les exécutions terminées, les rapports générés et le nombre de jetons sont faciles à mesurer. La connaissance utile est plus difficile à quantifier. Une opération de recherche peut devenir plus rapide pour produire des artefacts sans accélérer la réduction de l’incertitude.

Un bon système de recherche assistée par IA doit donc distinguer explicitement production et apprentissage. La production demande si l’agent a créé du code, un tableau, un rapport ou une hypothèse candidate. L’apprentissage demande si le résultat a modifié ce que l’équipe devrait croire ou faire. Cette seconde catégorie exige des contrôles qu’il est facile d’oublier lorsque l’agent est récompensé pour avoir terminé une tâche.

Pour chaque exécution substantielle, un dossier de recherche devrait rendre visibles les éléments suivants :

  • la question testée et la décision qu’elle pourrait influencer ;
  • l’hypothèse, y compris le résultat qui la mettrait en défaut ;
  • les données, les versions des logiciels et des modèles, ainsi que les graines aléatoires utilisées ;
  • les modifications exactes effectuées par l’agent ;
  • l’ensemble d’évaluation et les risques connus de fuite ou de sélection ;
  • les exécutions infructueuses, et pas seulement la meilleure ;
  • la décision humaine ayant approuvé, rejeté ou différé la conclusion.

Il ne s’agit pas d’une couche de bureaucratie ajoutée après l’automatisation. C’est le mécanisme qui transforme une suite d’actions rapides en connaissance cumulative. Sans lui, des agents concurrents peuvent créer discrètement une nouvelle forme de dette technique : un historique d’expériences que personne ne peut reproduire ni expliquer.

Pourquoi la preuve devient le goulot d’étranglement

Le problème de validation ne concerne pas uniquement OpenAI. Google DeepMind a décrit une difficulté comparable dans son essai « Machines à conjectures : les agents IA et le nouveau goulot d’étranglement de la validation scientifique ». L’argument est simple : si les agents peuvent produire à grande échelle des hypothèses, concevoir des expériences, écrire du code et rédiger des articles, la communauté scientifique aura besoin de davantage de moyens pour tester ces productions de manière indépendante. Le nombre d’idées pourrait augmenter plus vite que l’offre de laboratoires, d’évaluateurs, de jeux de données et d’experts capables de les vérifier.

Ce déséquilibre change la valeur d’un agent de recherche. L’usage le plus efficace n’est pas toujours celui qui paraît le plus créatif. Un agent qui repère une hypothèse erronée, reproduit un résultat ou exécute une ablation soigneusement contrôlée peut être plus précieux qu’un agent qui propose dix pistes inédites. La seconde activité est visible et stimulante ; la première améliore la fiabilité de toute la chaîne.

Les agents de recherche héritent aussi des faiblesses de la recherche automatisée. Un système peut explorer une région étroite de l’espace des solutions parce qu’elle est plus facile à noter. Il peut reprendre des schémas issus de ses données d’entraînement en les présentant comme de nouvelles combinaisons. Il peut découvrir une astuce propre à un benchmark qui ne résiste pas à un changement de données ou de matériel. Il peut rédiger une explication convaincante après l’expérience, alors même que celle-ci ne justifiait pas cette explication.

Une étude de 2025 consacrée aux agents de recherche IA pour l’apprentissage automatique, MLE-bench research, montre pourquoi la conception de l’évaluation est déterminante. Les auteurs considèrent les agents de recherche comme des politiques de recherche se déplaçant dans un espace de solutions candidates, puis comparent différentes stratégies et différents ensembles d’opérations sur un benchmark d’apprentissage automatique. Leurs résultats montrent que la stratégie de recherche, les opérations accessibles à l’agent et la méthode d’évaluation interagissent. Un meilleur score n’est pas seulement une propriété du modèle ; c’est une propriété de l’ensemble constitué par la recherche et la mesure.

Cette leçon vaut aussi pour le travail interne. Si l’agent peut choisir la séparation des données, le point d’arrêt, la métrique et l’exemple final présenté à l’évaluateur, le flux de travail ne teste pas proprement une hypothèse. Il autorise le même système à concevoir le test, à l’exécuter et à plaider en faveur du résultat. Lorsque la décision est importante, ces étapes devraient être séparées.

Un meilleur flux de travail pour la recherche assistée par IA

Le schéma le plus utile est une boucle par étapes, avec des permissions différentes à chaque étape. Le modèle peut avancer vite, mais il ne devrait pas disposer partout du même pouvoir.

1. Formuler la question avant d’ouvrir l’agent

Commencez par une décision, et non par une demande vague d’éclairage. « Trouver un meilleur modèle » n’est pas une question de recherche. « Réduire de 20 % la latence d’inférence sur cette charge de travail tout en maintenant le rappel au-dessus de la référence actuelle » s’en approche davantage. L’équipe doit préciser ce qui est déjà connu, ce qui reste incertain, ce qui modifierait la décision et ce qui est hors périmètre.

Cette formulation empêche l’agent de transformer un objectif ambigu en problème d’optimisation arbitraire. Elle donne aussi à l’évaluateur un moyen de distinguer un résultat négatif utile d’un échec improductif.

2. Donner à l’agent un espace de travail borné

L’agent de recherche devrait avoir accès au dépôt, aux jeux de données, à la documentation et aux outils nécessaires à la tâche, mais pas à tous les identifiants ni à tous les systèmes de production de l’organisation. Utilisez un environnement jetable lorsque c’est possible. Séparez les documents de référence en lecture seule des emplacements où l’agent peut écrire.

Cette limite est particulièrement importante pour les modèles dotés de capacités d’utilisation d’ordinateur. L’aperçu de sécurité de GPT-6 Astra publié par OpenAI affirme que le modèle est nettement plus performant en programmation, navigation, sciences et utilisation de l’ordinateur, tout en décrivant une surveillance et des contrôles renforcés contre les comportements potentiellement destructeurs. L’annonce du modèle Astra indique que le modèle peut travailler dans des logiciels spécialisés afin d’inspecter des données scientifiques et d’explorer des résultats. Cette capacité est utile précisément parce qu’elle donne au modèle une portée accrue. Cette portée supplémentaire fait aussi de la conception des permissions une partie de la méthode de recherche.

Pour une expérimentation ordinaire, l’agent n’a presque jamais besoin d’envoyer des messages externes, de modifier des données de production, d’autoriser une dépense, de changer des contrôles d’accès ou de publier des résultats. Ces actions devraient rester des étapes séparées, approuvées par un humain.

3. Demander des approches concurrentes

Une trajectoire unique de l’agent peut conduire à un engagement accidentel. Demandez deux ou trois approches plausibles, dont une référence simple et une approche susceptible d’échouer pour une raison explicitement formulée. Demandez à l’agent d’identifier les hypothèses et de proposer des tests capables de départager les options.

Cela ne garantit pas la diversité. Les modèles ont tendance à reproduire les schémas courants, et plusieurs sessions parallèles peuvent partager les mêmes angles morts. Mais l’explicitation des alternatives facilite la revue et réduit le risque que la première implémentation fonctionnelle devienne la solution par défaut simplement parce qu’elle est arrivée la première.

4. Séparer l’implémentation de l’évaluation

L’agent peut écrire le dispositif expérimental, mais les tests d’acceptation et les données d’évaluation protégées devraient rester sous le contrôle de l’équipe. Si l’agent peut examiner à répétition l’ensemble de test conservé à part et modifier son implémentation jusqu’à ce que le score augmente, cet ensemble ne mesure plus correctement la généralisation.

Utilisez une commande d’évaluation fixe qui enregistre le résultat et refuse d’écraser les exécutions précédentes. Gardez un petit jeu de test privé pour la revue finale. Pour les travaux à forte valeur, demandez à une deuxième personne ou à un système distinct d’examiner la définition de l’expérience avant l’exécution finale. Le but n’est pas de créer un cérémonial compliqué. Il s’agit de rendre plus difficile le fait qu’une fuite accidentelle ou une modification silencieuse se fasse passer pour un progrès.

5. Exiger un registre des résultats, pas seulement un rapport final

Un récit final est l’artefact le plus facile à produire pour un modèle de langage et le plus difficile à auditer. Conservez les métadonnées lisibles par machine à côté du texte narratif. Enregistrez les tentatives ratées, les dépassements de délai, les changements de dépendances et les écarts inexpliqués. Si un agent affirme qu’une méthode a amélioré les performances, l’évaluateur devrait pouvoir retrouver l’exécution, reproduire l’environnement et inspecter la comparaison.

Le registre donne aussi un meilleur contexte aux agents futurs. Un système qui voit pourquoi une piste a été rejetée est moins susceptible de la reprendre. Sans cette mémoire, l’automatisation ne fait qu’accélérer la redécouverte.

6. Rendre la décision humaine explicite

L’évaluateur doit répondre à trois questions différentes : l’agent a-t-il réalisé la tâche demandée ? Le résultat est-il techniquement crédible ? Justifie-t-il la décision proposée ? Une implémentation correcte peut tout de même produire un résultat sans rapport avec la question. Un résultat statistiquement solide peut être trop coûteux ou trop fragile pour être déployé.

Écrivez la décision et le niveau de confiance qui lui est associé. « Adopter », « rejeter » et « lancer un test supplémentaire » sont des résultats différents de « l’agent a terminé la tâche ». Assimiler l’achèvement à une approbation est l’un des moyens les plus simples de créer un biais silencieux en faveur de l’automatisation.

Le coût : la concurrence est puissante et facile à mal interpréter

Les chiffres de coût internes d’OpenAI constituent un avertissement pour toute équipe qui prépare le déploiement d’agents. Une dépense médiane supérieure à 600 dollars par jour aux tarifs de l’API ne correspond pas au budget habituel d’un assistant de bureau. Ce chiffre reflète une recherche de pointe, un travail concurrent et une méthode comptable interne particulière ; il ne s’agit pas d’une estimation universelle. Il montre toutefois à quelle vitesse la dépense d’inférence peut devenir un coût d’exploitation important lorsque les agents fonctionnent en continu.

Le chiffre supérieur à 7 000 dollars par jour au 90e percentile est encore plus révélateur. Un petit nombre d’utilisateurs intensifs peut dominer la facture, surtout lorsqu’ils lancent plusieurs agents, répètent des exécutions échouées ou leur fournissent de longues fenêtres de contexte contenant des dépôts et un historique expérimental. Une équipe qui établit son budget uniquement en fonction du nombre de sièges ne verra pas ce comportement.

Les contrôles de coût doivent mesurer autre chose que les jetons. Suivez la dépense par projet, expérience, modèle et résultat. Fixez des budgets distincts pour l’exploration et la validation. Réservez les modèles les plus capables aux tâches où leur raisonnement supplémentaire change réellement le résultat, et confiez aux modèles moins coûteux la recherche de fichiers, la mise en forme, l’ossature des tests et les diagnostics courants. Arrêtez ou mettez en pause les agents après des périodes d’inactivité définies. Ajoutez une étape de revue avant les grandes séries d’exécutions gourmandes en calcul.

Il existe aussi un coût d’opportunité. Si un chercheur peut lancer vingt expériences mais n’en examiner correctement que trois, les exécutions marginales peuvent dégrader la qualité des décisions. L’objectif pertinent n’est pas de maximiser le temps d’exécution des agents. C’est de réduire le coût d’obtention d’une décision que l’équipe est capable de défendre.

Vie privée et propriété intellectuelle

Les systèmes de recherche contiennent souvent des résultats inédits, des données clients, du code propriétaire, des identifiants ou des informations sur des produits qui n’ont pas encore été annoncés. Envoyer ces éléments à un fournisseur de modèles externe relève de la gouvernance des données, même lorsque l’interface donne l’impression d’une assistance ordinaire.

Avant d’activer un agent, déterminez quelles données il peut lire, où les requêtes et les sorties sont conservées, qui peut accéder aux journaux, si les données servent à l’entraînement et comment fonctionnent les demandes de suppression. Vérifiez si les conditions applicables à l’offre entreprise ou à l’API diffèrent de celles destinées aux particuliers. Examinez le rôle des sous-traitants, des places de marché cloud, du personnel d’assistance et des systèmes de surveillance dans le traitement des données.

L’annonce des protections Frontier pour les entreprises d’Anthropic illustre l’orientation prise par les contrôles destinés aux entreprises. Anthropic explique que sa conception EFS associe des dispositifs de conservation nulle des données, une infrastructure cloud contrôlée par le client et une surveillance des usages abusifs, avec un déploiement progressif sur les produits et plateformes cloud pris en charge. Cela ne rend pas chaque déploiement sûr ou adapté, mais montre les questions que les équipes chargées des achats devraient poser : où l’information est-elle stockée, qui contrôle ce stockage et comment les contrôles de sécurité sont-ils effectués sans créer un second problème d’exposition des données ?

Pour les recherches sensibles, un déploiement local ou privé peut réduire le risque de transfert, mais il ne le supprime pas. Des modèles locaux peuvent encore exposer des données par les journaux, les machines partagées, les appels d’outils, les extensions, les sauvegardes ou un agent qui écrit des secrets dans un répertoire d’artefacts. Un modèle plus petit doté d’une frontière propre peut être plus sûr qu’un modèle plus grand bénéficiant d’un accès étendu.

Quand utiliser un agent de recherche IA

Les meilleurs cas d’usage initiaux ont trois caractéristiques : la tâche possède une entrée claire, la sortie peut être testée et un humain peut juger le résultat sans devoir reconstituer tout le processus à partir de rien. Parmi les exemples :

  • reproduire une méthode publiée dans un environnement contrôlé ;
  • transformer une expérience existante en dispositif paramétrable et reproductible ;
  • déboguer l’infrastructure et les conflits de dépendances ;
  • exécuter des ablations dont l’interprétation est définie à l’avance ;
  • vérifier qu’une affirmation tient sur des jeux de données ou des configurations documentés ;
  • surveiller des files d’expériences et signaler les exécutions échouées ou anormales ;
  • rechercher dans un corpus bibliographique borné et relier chaque affirmation à une source ;
  • préparer une comparaison de méthodes connues en indiquant explicitement les incertitudes et les éléments de preuve manquants.

Ces tâches peuvent sembler peu prestigieuses. C’est en partie ce qui fait leur intérêt. Elles réduisent les frictions autour d’un travail que les experts comprennent, mais qu’ils repoussent souvent parce qu’il est fastidieux. Elles produisent aussi des artefacts que l’on peut comparer à une norme connue.

Les agents sont moins adaptés lorsque le coût d’une conclusion erronée est élevé et que la preuve ne peut pas être vérifiée à peu de frais. Soyez prudents pour les tâches liées aux décisions cliniques, aux conclusions juridiques, aux engagements financiers, aux contrôles critiques pour la sécurité, aux données personnelles inédites ou aux affirmations ouvertes de nouveauté. Un agent peut aider à préparer et analyser ces travaux, mais le seuil de revue indépendante devrait être beaucoup plus élevé.

La même prudence vaut pour les tâches dont l’objectif est mal spécifié. Si l’équipe ne peut pas dire à quoi ressemblerait la réussite avant de voir la sortie, elle n’est pas prête à déléguer la recherche. L’agent peut toujours faire émerger des pistes, mais ses suggestions doivent rester des hypothèses et non des recommandations.

Les alternatives à un agent de pointe hébergé

Un modèle de pointe hébergé n’est pas la seule possibilité. Le choix devrait dépendre de la charge de travail et des contraintes de l’organisation.

Un modèle hébergé plus petit peut suffire pour naviguer dans un dépôt, générer des tests, nettoyer des données ou mettre en forme un rapport. Il peut réduire les coûts et la quantité de contexte sensible envoyée à un fournisseur, même si l’équipe doit toujours examiner ses conditions d’utilisation et ses paramètres de conservation.

Un modèle à poids ouverts exécuté dans un cloud privé ou sur du matériel local peut aider à préserver la confidentialité et à garantir un accès prévisible. La contrepartie est opérationnelle : l’équipe prend en charge le déploiement, les correctifs, la surveillance, l’évaluation et la planification de capacité. Les poids du modèle ne suppriment pas le besoin de gouvernance. Ils transfèrent une plus grande part de la responsabilité à l’utilisateur.

Un pipeline d’automatisation classique peut être préférable à un agent lorsque les étapes sont stables. Une expérience scriptée avec des paramètres fixes est plus facile à reproduire, auditer et budgéter qu’un modèle qui décide de l’étape suivante. Utilisez un agent lorsque le jugement ou l’adaptation apporte une valeur ; préférez un logiciel déterministe lorsque le processus est déjà connu.

Enfin, un assistant de recherche humain ou un spécialiste peut rester le meilleur choix lorsque la tâche dépend d’un savoir tacite, du contexte institutionnel ou d’une responsabilité clairement attribuée. L’objectif n’est pas de maximiser la part de travail effectuée par des modèles. Il est de rendre l’ensemble du système de recherche plus capable sans rendre ses conclusions moins fiables.

Ce que les dirigeants devraient mesurer

Un projet pilote devrait rendre compte d’autre chose que de la vitesse. Il faut au minimum mesurer :

  • le temps écoulé entre la question et un résultat pouvant être examiné ;
  • le coût par résultat accepté, et non le coût par exécution terminée ;
  • le taux de reproduction lorsqu’une autre personne relance le travail ;
  • le taux d’expériences invalides, dupliquées ou impossibles à réparer ;
  • la proportion d’affirmations de l’agent nécessitant une correction importante ;
  • le temps de revue humaine par résultat ;
  • la fréquence à laquelle l’agent découvre un résultat négatif utile ;
  • la fréquence à laquelle un humain modifie la conception de l’évaluation ou rejette l’interprétation de l’agent ;
  • les incidents de confidentialité, violations de politiques et actions non autorisées effectuées par les outils.

La mesure du temps de revue mérite une attention particulière. Si les agents produisent des résultats plus vite que les experts ne peuvent les examiner, la file d’attente devient le goulot d’étranglement. La réponse n’est pas automatiquement d’ajouter des agents. Il peut être préférable de resserrer les questions, d’améliorer le registre des résultats, de renforcer les contrôles automatiques ou de réduire le nombre d’expériences transmises à la revue humaine.

Les dirigeants devraient aussi surveiller le risque de concentration. Si un fournisseur, une famille de modèles ou un outil propriétaire s’intègre à chaque expérience, l’organisation peut perdre la capacité de reproduire ses résultats historiques lorsque les prix, l’accès, les limites de contexte ou le comportement de sécurité changent. Conservez les artefacts exportés, les commandes d’évaluation fixes et une documentation suffisante pour relancer les travaux critiques avec un autre modèle ou sans modèle.

La conclusion pratique

Le stagiaire de recherche automatisé constitue un jalon important parce qu’il rend moins coûteuse une forme de travail bien connue : transformer une question définie en code, en exécutions, en comparaisons et en une première version de résultat. Les données internes d’OpenAI suggèrent que les équipes de recherche de pointe fonctionnent déjà avec de grandes quantités d’efforts d’agents exécutés en parallèle. D’autres groupes de recherche explorent des systèmes apparentés pour produire des hypothèses et mener des expériences scientifiques.

Mais ce jalon ne rend pas le chercheur inutile. Il augmente la valeur de ses responsabilités les moins automatisables : choisir des questions qui méritent d’être posées, concevoir des tests équitables, repérer les fuites, juger la validité externe, comprendre les conséquences et décider si les preuves sont suffisantes.

Les équipes qui en tireront le plus de bénéfices considéreront les agents comme une infrastructure expérimentale, et non comme un oracle. Elles leur donneront une tâche bornée, un espace de travail contrôlé, des tests d’acceptation explicites et un historique des échecs. Elles prévoiront le coût du travail concurrent, protégeront les données sensibles et conserveront une voie de reproduction indépendante du fournisseur de modèles initial. Surtout, elles mesureront la connaissance acceptée plutôt que l’activité générée.

Lorsque les idées deviennent bon marché, la preuve devient la ressource rare. C’est le fait opérationnel qui se trouve derrière la vague actuelle de recherche assistée par IA, et c’est lui qui devrait orienter chaque décision de déploiement.

Sources