Reconnaître un objet sur une photographie et accomplir un travail dans un logiciel sont deux tâches différentes. GPT-6.1 Terra cherche à les rapprocher. Pour juger cette proposition d’OpenAI, la bonne question n’est pas de savoir si le modèle « comprend le monde », mais ce qu’il reçoit, ce qu’il peut faire et qui vérifie le résultat.
Dans sa fiche technique, OpenAI présente Terra comme un modèle de raisonnement visuel, d’utilisation de l’ordinateur et de rédaction. Les usages cités comprennent la comparaison de photographies avec un catalogue, l’interprétation de dessins techniques et les actions sur les écrans d’une application. Ce sont des capacités annoncées par le fournisseur, pas les résultats d’un essai réalisé par notre rédaction.
Lire une image ne suffit pas à terminer une tâche
Prenons un exemple hypothétique : une entreprise veut retrouver, dans son catalogue, la référence correspondant à une photographie envoyée par un client. Une première étape consiste à décrire l’objet. Une deuxième exige de comparer les références disponibles. Une troisième peut demander d’ouvrir une fiche et de préparer une réponse.
Ces étapes n’ont pas le même critère de réussite. Une description plausible peut rester trop vague pour identifier le bon produit. Un objet ressemblant peut appartenir à une autre gamme. Une référence exacte peut enfin être reportée dans le mauvais dossier. Le résultat utile est donc la correspondance vérifiée, pas seulement un commentaire convaincant sur l’image.
C’est sur cette articulation entre perception et action que se situe l’intérêt de Terra. Le lecteur gagne à séparer les deux promesses : mieux interpréter les éléments visibles et mieux enchaîner les opérations. Un progrès sur l’une ne prouve pas automatiquement la fiabilité de l’autre.
Ce que l’API reçoit réellement
La documentation indique des entrées textuelles et visuelles, avec des sorties textuelles. Elle ne prévoit pas la prise en charge directe de l’audio ou de la vidéo par le modèle. Cette précision évite un contresens : une démonstration liée à un film ne signifie pas nécessairement qu’un fichier vidéo est analysé directement comme tel.
Dans son article du 27 octobre, Clubic décrit notamment un travail de restauration d’animation passant par l’examen d’images de la séquence. Le média souligne aussi que les interventions dans les logiciels supposent des accès autorisés. Il faut donc regarder l’ensemble du dispositif : modèle, documents fournis, outils et application utilisée.
Une image d’entrée peut être une photographie, un dessin ou une capture d’écran. Cela ne rend pas ces documents équivalents. Une photographie montre une apparence ; un plan représente des conventions, des dimensions et parfois plusieurs vues. Une capture affiche l’état d’une interface à un instant donné. Pour évaluer un assistant, il faut conserver ces différences au lieu de ranger tous les exercices sous une unique étiquette de « vision ».
Du modèle à l’agent : l’étape décisive des outils
Un modèle devient utile dans un processus lorsqu’il reçoit les moyens d’exécuter les actions attendues. Pour Terra, OpenAI précise que les appels d’outils passent par la Responses API. Cette interface permet à une application de raccorder le raisonnement aux fonctions qu’elle expose.
Dans notre exemple de catalogue, un accès en lecture peut suffire pour chercher une référence. Modifier une commande serait une autre responsabilité. Même si la même IA intervient dans les deux cas, les conséquences changent. La conception du service doit donc définir les actions permises, les informations nécessaires et les moments où un contrôle est attendu.
Cette distinction donne un critère concret pour lire une démonstration. A-t-on obtenu une suggestion, un fichier exploitable ou une modification effective dans le logiciel ? Le travail est-il encore correct lorsqu’on ouvre le résultat ? Ces questions comptent davantage qu’une animation rapide de fenêtres ou une réponse assurée.
Comment comparer sans se laisser impressionner
Le guide d’OpenAI recommande, lors d’une migration depuis GPT-5.6 Terra, de comparer les modèles sur des images et des processus représentatifs, avec le même niveau d’effort de raisonnement. Cette consigne est utile : changer simultanément les documents, les outils et les réglages rend difficile l’attribution d’un progrès au nouveau modèle.
Pour une évaluation de terrain, nous retiendrions trois niveaux. D’abord, l’exactitude du résultat : la référence, les dimensions ou le contenu demandé sont-ils corrects ? Ensuite, l’exécution : les opérations prévues ont-elles réellement abouti ? Enfin, la reprise : lorsqu’une information manque, l’assistant signale-t-il l’incertitude au lieu de compléter le dossier au hasard ?
Il faut aussi inclure les corrections humaines dans le temps mesuré. Un premier résultat rapide, suivi d’une longue réparation, n’est pas nécessairement un gain. À l’inverse, demander une précision peut être la bonne décision si elle évite une action erronée. Il s’agit ici de critères d’évaluation, non d’erreurs que nous aurions constatées sur Terra.
Ce qu’on peut déjà conclure, et ce qui reste à éprouver
Terra propose une spécialisation intéressante pour les tâches où une information visuelle doit déboucher sur un travail informatique. La documentation permet d’en préciser le périmètre ; elle ne suffit pas à garantir le résultat dans tous les métiers.
Une équipe qui veut l’évaluer aurait intérêt à commencer par un dossier représentatif dont elle connaît déjà le résultat attendu, puis à introduire des cas moins nets : image ambiguë, référence absente ou étape impossible. Ce parcours montrerait à la fois ce que l’outil accomplit et comment il expose ses limites.
Le progrès recherché est très concret : obtenir un résultat utilisable avec moins de reprises, tout en conservant la maîtrise des actions. C’est à cette échelle qu’une promesse de raisonnement visuel devient un service, et qu’elle mérite d’être jugée.
Photographie d’illustration : un poste de travail à deux écrans ; il ne s’agit pas d’une démonstration de Terra.
