Prompts et agents : des outils qui évoluent, un travail à cadrer

Le titre publié en 2023 posait la question d’une disparition programmée du prompt engineering. Cette formulation exprimait une hypothèse. Elle ne décrit pas une évolution démontrée, et ne permet pas de fixer une date d’obsolescence à une compétence. La question utile est de savoir ce que les améliorations des interfaces déplacent dans le travail de conception.

La présente révision distingue les faits documentés d’une analyse : les outils proposent toujours des instructions et des tests ; l’idée que l’effort se déplace vers le workflow est une lecture pratique de leurs usages, pas une prédiction sur l’avenir des métiers.

Ce qui peut devenir plus simple

Une interface qui aide à formuler une demande ou qui propose des modèles peut réduire le besoin de connaître des tournures particulières. Cela peut faciliter le premier essai. Il reste pourtant nécessaire d’expliquer les données disponibles, le résultat attendu et ce qui doit se passer lorsqu’une information manque.

La documentation Microsoft sur la création de prompts prévoit encore des instructions, des entrées d’exemple et une phase de test. Elle ne démontre pas que toute technique actuelle restera utile ; elle montre que la définition et l’évaluation de la tâche font toujours partie de la conception.

Il est raisonnable de chercher des consignes plus claires et plus courtes. Il est moins solide de bâtir une pratique sur une formule supposée fonctionner avec tout modèle et tout contexte. Une modification doit être jugée sur les cas de l’organisation.

Ce qui se déplace vers le système

Un agent peut associer des instructions, des connaissances et des outils. La présentation de Copilot Studio décrit ces composants et leur intégration dans des workflows. Dès qu’un outil peut agir, la qualité du texte produit devient une partie du problème.

Il faut également définir l’identité qui accède aux données, les actions autorisées, les validations nécessaires, les traces conservées et la reprise après erreur. Ces décisions ne peuvent pas toutes reposer sur une phrase telle que « sois prudent ». Les permissions doivent être appliquées par les services, et les règles critiques contrôlées à l’étape qui exécute l’action.

Exemple : classer une demande puis la transmettre

Imaginons un outil qui lit une demande et propose une catégorie de support. Le prompt précise les catégories, les données à examiner et le résultat attendu. Il peut produire une catégorie plausible, accompagnée d’une explication erronée ou d’un champ absent.

Un workflow exploitable ajoute des contrôles : catégorie appartenant à la liste autorisée, données obligatoires présentes, destination connue et état « à vérifier » lorsque le cas sort du périmètre. Si un responsable doit accepter la transmission, cette étape est représentée explicitement. Les doublons et erreurs d’envoi ont aussi une procédure de traitement.

Dans cet exemple illustratif, améliorer la consigne peut réduire certaines erreurs. Vérifier les champs et contrôler l’envoi apportent une autre protection. Il faut tester les deux dimensions au lieu d’attendre qu’un prompt plus long garantisse tout le processus.

La compétence durable : comparer et maintenir

Conservez un petit jeu de cas métier avec les résultats attendus, y compris les demandes ambiguës, incomplètes et hors périmètre. Rejouez-le quand vous modifiez les instructions, les sources, les outils ou le modèle. Comparez les erreurs, l’effort de vérification et la capacité à reprendre un traitement.

Une évolution d’interface peut supprimer une manipulation ; elle ne supprime pas la nécessité de décider ce qu’est un bon résultat. Former les équipes à cadrer une tâche, contrôler les références et reconnaître une limite reste donc utile. La méthode détaillée figure dans Travailler avec l’IA : formuler, vérifier, améliorer.

Sources Microsoft consultées le 23 octobre 2026. Cette analyse ne prédit ni la disparition du prompt engineering ni l’autonomie générale des agents.

IA et automatisation métier