De la réponse à l’action : comment l’interface entre les personnes et l’IA a changé

Raconter l’histoire à partir de ce que l’on peut déléguer

L’histoire de l’intelligence artificielle est souvent racontée à travers ses techniques, ses résultats ou les périodes d’enthousiasme qui l’ont accompagnée. On peut aussi partir d’une question plus concrète : que pouvait demander une personne à un système, et quelle partie de la tâche pouvait-elle lui confier ? Cette perspective met l’accent sur l’interaction et la délégation, et pas seulement sur la capacité à produire une réponse.

Une conversation convaincante, une interface intégrée à un produit et une action exécutée par un logiciel sont trois choses différentes. Dans le premier cas, le système produit une réponse que la personne peut utiliser. Dans le deuxième, le dialogue est présenté à côté des fonctions d’un service. Dans le troisième, le système peut intervenir dans un processus externe, à condition de disposer des outils et des autorisations nécessaires. Le simple fait qu’une interface semble conversationnelle ne suffit pas à conclure qu’elle peut accomplir une tâche de bout en bout.

Les sources disponibles ici permettent d’observer plusieurs exemples actuels ou présentés à titre de contexte, mais elles ne documentent pas suffisamment le lancement et l’évolution d’une séquence historique commune. Ce parcours compare donc des formes d’interaction et précise ce que l’on peut affirmer pour chaque exemple. Il ne propose pas de chronologie universelle et ne soutient pas que chaque nouvelle forme soit nécessairement plus fiable ou plus utile que la précédente.

Cinq questions pour distinguer interaction et capacité

Pour comparer des produits sans confondre leurs différences, il est utile de séparer cinq dimensions. L’interface décrit la manière dont la personne communique avec le système. La technique ou le mécanisme indique, dans la mesure où la documentation le permet, ce que le logiciel fait de la demande. La portée de l’action précise s’il s’agit d’une réponse, d’une recommandation ou d’une opération effectuée en dehors de la conversation. La supervision recouvre les autorisations et les confirmations nécessaires. Enfin, le niveau de preuve disponible indique si l’affirmation vient de la documentation du produit, d’une analyse externe ou d’une démonstration évaluée.

Cette distinction permet aussi d’employer avec précision des termes proches. Un prompt est une entrée ou une instruction qui guide une réponse. Un agent désigne généralement un système organisé pour poursuivre un objectif en plusieurs étapes, même si l’usage du terme varie. Le tool-calling signifie qu’un modèle demande l’utilisation d’un outil disponible ; cela ne veut pas dire automatiquement que l’outil est exécuté, que l’opération réussit ou qu’elle est menée à bien sans supervision. Ces termes ne décrivent pas, à eux seuls, les performances réelles d’un produit.

Dialogue textuel : une réponse n’est pas une action

Le dialogue textuel donne à l’interaction la forme d’une question suivie d’une réponse. La personne écrit une demande et le système renvoie un texte. À titre de contexte journalistique, BBC Mundo décrit ChatGPT comme capable de répondre à des questions ou de générer du contenu. Cette description permet de caractériser un usage conversationnel général, mais elle ne suffit pas à établir le mécanisme précis qui produit chaque réponse, les limites qui ont été testées ni les fonctions disponibles à une date donnée.

Cette distinction est importante, car une réponse peut aider à accomplir une tâche sans l’exécuter. Si quelqu’un demande de l’aide pour rédiger un message, recevoir un brouillon ne prouve pas que le système l’a envoyé. Si la personne demande comment effectuer une réservation, obtenir des instructions ne signifie pas qu’une disponibilité a été vérifiée ni qu’une réservation a été confirmée. Il s’agit de situations illustratives, et non d’affirmations sur les fonctions d’un produit précis.

Il serait tout aussi inexact de déduire qu’une interaction textuelle ancienne reposait nécessairement sur des règles ou des scripts au seul motif qu’elle est présentée comme un chatbot. IBM propose un aperçu historique qui mentionne les premiers chatbots conversationnels, mais les informations disponibles ici ne détaillent pas le fonctionnement d’un système spécifique. Sans documentation du produit ou source historique directe, il est impossible de reconstituer rigoureusement les règles, les bases de données ou les techniques mobilisées dans un cas particulier.

La leçon de comparaison est modeste, mais utile : la conversation est un mode d’accès, pas une preuve complète de capacité. Pour évaluer un système, il faut disposer d’informations sur la tâche, les réponses acceptables, les erreurs et les conditions d’utilisation. La fluidité de l’échange ne remplace pas ces éléments.

Les assistants intégrés aux produits : une conversation située dans un service

Un assistant intégré à un produit change le lieu de l’interaction : la personne peut dialoguer dans le contexte d’un service précis, plutôt que dans une interface séparée. Cette intégration peut réduire le nombre d’étapes nécessaires pour trouver une fonction ou demander de l’aide. Cependant, la proximité avec les fonctions du produit ne prouve pas que l’assistant y ait toutes accès, qu’il interprète correctement chaque demande ou qu’il puisse les exécuter sans intervention.

La documentation Adobe disponible parmi les sources est un guide de l’interface utilisateur de son Assistant IA. La documentation de Primo Research Assistant présente un outil génératif destiné aux tâches de recherche. Ces documents permettent de décrire des exemples d’assistants proposés au sein de produits ou de services. Les informations fournies ne précisent pas les capacités exactes disponibles lors de leur lancement et ne permettent pas de reconstituer une série de changements assortis de dates vérifiées.

Un autre cas, décrit par Facephi, porte sur la conception d’une interface de décision destinée aux analystes qui reçoivent des recommandations de l’IA. Il met en lumière une question importante pour les produits : présenter une recommandation n’équivaut pas à remplacer le jugement de la personne qui la reçoit. Mais, d’après la description disponible, cette source ne documente pas une évolution historique et ne démontre pas à elle seule les résultats obtenus par une interface précise.

En pratique, pour décrire n’importe quel assistant intégré, il convient de vérifier quelles informations il peut consulter, quelles fonctions sont disponibles, quel résultat il présente et qui confirme une opération. Si les sources ne documentent que l’interface ou l’objectif général, la description doit s’en tenir à ces limites. Il ne serait pas rigoureux de combler les lacunes en supposant que le système a accès aux données de l’utilisateur ou à toutes les fonctions du produit.

Outils et actions : une frontière qui doit être vérifiée

Lorsqu’un système peut demander l’utilisation d’outils, l’interaction peut aller au-delà de la production de texte. Un outil peut, par exemple, consulter des informations ou lancer une opération dans un autre service. Mais plusieurs étapes ne doivent pas être confondues : le modèle peut proposer un appel ; le logiciel peut le valider ; un service externe peut répondre ; et une personne peut devoir autoriser le résultat. L’existence de l’une de ces étapes ne prouve pas que toutes les autres ont lieu ni que le processus est correct.

Le terme tool-calling désigne une possibilité technique, et non un résultat garanti. Un agent peut coordonner plusieurs étapes, mais cette étiquette ne prouve pas non plus que le système choisisse correctement ces étapes, conserve le contexte, se remette d’un échec ou sache s’arrêter. Pour affirmer qu’un produit exécute une action précise, il faut des sources qui décrivent l’opération et, si possible, une démonstration reproductible de ses limites et de ses exigences.

Les sources rassemblées pour cet article ne fournissent pas d’exemple suffisamment détaillé d’un système qui appelle un outil et mène à bien une action externe, ni ne décrivent les autorisations et confirmations nécessaires dans un tel cas. On n’attribue donc pas cette capacité à Primo Research Assistant, à l’assistant d’Adobe ou à un autre produit cité. La comparaison avec les assistants conversationnels sert ici à préciser ce qu’il faudrait vérifier ; elle ne permet pas d’affirmer qu’une nouvelle étape historique est déjà démontrée.

Ce que l’on peut comparer, et ce que l’on ne peut pas comparer

Une comparaison équitable utiliserait la même tâche et des critères équivalents pour chaque système. On pourrait, par exemple, examiner si une personne parvient à trouver une information, à rédiger une réponse ou à accomplir une démarche. Mais il faudrait d’abord choisir des systèmes précis, fixer leurs versions et obtenir une documentation suffisante pour connaître la tâche, les autorisations, l’intervention humaine et le résultat. Les éléments disponibles ne permettent pas de reconstituer la même tâche pour les exemples mentionnés.

C’est pourquoi cette analyse compare des catégories et des limites de preuve, plutôt que des résultats de performance. Le contexte fourni par BBC Mundo à propos de ChatGPT et la référence d’IBM aux chatbots conversationnels offrent des éléments généraux. Les guides d’Adobe et de Primo documentent des produits précis du point de vue de leurs fournisseurs. L’article de Facephi apporte un éclairage sur la présentation des recommandations et le rôle du jugement humain. Ces sources diffèrent par leur nature et leur portée ; elles ne doivent pas être traitées comme des essais comparables.

Cette prudence permet d’éviter trois erreurs fréquentes. Premièrement, prendre la description d’une fonction pour une vérification indépendante de ses performances. Deuxièmement, attribuer à un produit des capacités qu’un guide d’interface ne mentionne pas. Troisièmement, parler d’« autonomie » dès qu’une étape est supprimée, alors qu’une personne continue de prendre les décisions importantes. L’intégration, l’accès aux outils et la qualité des résultats sont des variables distinctes.

Davantage de façons d’interagir ne signifie pas un progrès mesuré

Une interface peut aider une personne à exprimer un besoin ; un assistant intégré peut placer l’aide à proximité des fonctions d’un service ; un outil peut permettre au logiciel d’agir sur un autre système. Chaque changement élargit ou réorganise les possibilités d’interaction. Pris isolément, aucun ne prouve une amélioration générale de la fiabilité, de l’utilité ou de l’autonomie.

Pour étayer une affirmation de progrès mesurable, il faudrait préciser quelle tâche est évaluée, ce que signifie la mener à bien, quelles erreurs sont prises en compte, quel degré de supervision est autorisé et avec quels systèmes la comparaison est effectuée. Il faudrait également distinguer les performances observées de la description commerciale ou documentaire d’une fonction. Sans ces éléments, l’affirmation peut porter sur une interface plus pratique ou une portée d’action plus large, mais pas sur une capacité générale supérieure.

Les incertitudes ne sont pas un défaut à dissimuler ; elles délimitent ce que le lecteur peut apprendre de la documentation disponible. Dans le cas présent, on dispose d’exemples de dialogue, d’assistants proposés au sein de services et de conception autour de recommandations, mais pas d’une base homogène permettant de raconter une succession de produits ou de comparer leurs résultats. La carte proposée ici est donc une carte de questions et de distinctions, et non un classement de systèmes.

La question essentielle est de savoir ce que l’on délègue, et sur quelles preuves

Raconter l’évolution de l’IA à partir des interactions permet de voir des changements importants sans supposer qu’ils forment une progression inévitable. Demander une réponse, consulter un assistant dans un produit et déléguer une opération sont des expériences différentes. Pour savoir dans quelle mesure les capacités ont réellement changé, il faut suivre les fonctions précises, leurs dates, les autorisations, les confirmations et le comportement en cas d’échec.

Au vu des éléments disponibles, on peut distinguer le dialogue textuel, l’assistance intégrée et la possibilité conceptuelle d’utiliser des outils. On ne peut pas affirmer que les exemples cités représentent trois étapes successives, qu’une même tâche a été mieux accomplie à chaque étape ni que les systèmes mentionnés exécutent des actions externes. Maintenir cette distinction rend la comparaison plus utile : cela évite de confondre une nouvelle interface avec une capacité démontrée.

Face à de futures affirmations selon lesquelles un produit peut désormais « faire » quelque chose, la question la plus pratique reste : qu’a-t-il fait exactement, dans quelles conditions, qui l’a confirmé et où cela est-il documenté ? La réponse permet de distinguer ce que le système suggère de ce qu’il exécute réellement, ainsi que la nouveauté d’une interface d’une amélioration mesurée.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.