Prompt, skill, outil, agent : les quatre termes circulent ensemble, souvent sans distinction nette. Pourtant, ils ne décrivent pas la même chose.
La différence la plus utile tient à ce que l’on délègue.
Le prompt porte une demande.
La skill formalise une méthode.
L’outil donne une capacité d’action.
L’agent prend en charge une partie de l’enchaînement.
On peut donc lire leur progression comme un déplacement de la frontière entre ce que l’utilisateur précise et ce que le système décide.
Le prompt : une tâche reste pilotée par l’utilisateur
Un prompt est une instruction adressée au modèle.
« Analyse ce fichier de ventes et identifie les principales anomalies. »
On peut préciser les critères, le contexte, le format attendu, ajouter des exemples. OpenAI recommande d’ailleurs de rendre explicites l’objectif et les contraintes.
Mais le pilotage reste largement humain.
Si l’analyse révèle une baisse inhabituelle sur une catégorie, quelqu’un doit demander de creuser. Si une autre source doit être consultée, il faut généralement l’indiquer. Si le résultat doit être reformulé ou transmis ailleurs, une nouvelle action est déclenchée.
Le modèle traite la tâche. L’utilisateur garde le processus.
C’est aussi ce qui limite l’idée selon laquelle le prompt engineering suffirait à rendre un système plus sophistiqué. Un prompt très long peut contenir beaucoup de logique, de règles, d’exceptions et de mise en forme. Cela ne signifie pas que le système orchestre quoi que ce soit.
Parfois, on a simplement déplacé un workflow dans du texte.
La skill : rendre une méthode disponible
La skill change le statut de cette logique.
Supposons qu’une analyse de ventes doive toujours suivre la même méthode : comparer la période à la précédente, isoler les écarts supérieurs à un seuil, vérifier si l’anomalie touche un produit ou une catégorie, produire une synthèse dans un format précis.
Il devient peu utile de réécrire ces règles dans chaque prompt.
Elles peuvent être formalisées une fois, puis réutilisées.
C’est l’idée derrière les skills dans plusieurs environnements agentiques. Microsoft les décrit comme des capacités réutilisables, liées à une tâche, composées d’instructions et éventuellement de scripts ou de ressources. Sa documentation distingue explicitement les skills des outils.
La différence avec un prompt n’est donc pas toujours visible dans la syntaxe. Une skill peut très bien contenir des instructions qui ressemblent à un prompt.
La différence est architecturale.
Le prompt appartient à une interaction. La skill devient un composant du système.
Et ce déplacement est plus important qu’il n’y paraît.
Une part significative du savoir professionnel n’est pas stockée dans une base de données. Elle existe dans des façons de faire : l’ordre des vérifications, les exceptions connues, les seuils qui doivent alerter, les contrôles à effectuer avant de valider une hypothèse.
Formaliser une skill revient à sortir une partie de ce savoir-faire de la tête des personnes pour le rendre exécutable ailleurs.
Le prochain avantage compétitif sera de mieux décrire le travail
Renaud Joly
L’outil : passer de la réponse à l’action
Une méthode n’a pourtant aucune prise sur le réel si le système ne peut pas accéder aux données ou aux applications nécessaires.
C’est le rôle de l’outil.
Un outil peut donner accès à une API, une base de données, un navigateur, un moteur de calcul, un CRM ou un système de ticketing. Microsoft le définit comme une capacité qu’un agent peut appeler pour récupérer une information ou effectuer une action.
La distinction avec une skill devient alors très concrète.
Une skill peut décrire comment analyser un pipeline commercial.
L’outil permet d’aller chercher le pipeline dans le CRM.
Une skill peut préciser comment vérifier une facture.
L’outil donne accès au logiciel comptable.
Ce passage modifie surtout le niveau de risque.
Tant qu’un modèle produit une réponse, son erreur reste contenue dans ce qu’il écrit. Lorsqu’il agit sur un système externe, l’erreur acquiert une portée opérationnelle.
Consulter un stock et le modifier ne relèvent pas du même niveau de contrôle.
Préparer un email et l’envoyer non plus.
Produire une requête SQL et l’exécuter sur une base de production encore moins.
À partir de là, évaluer uniquement la qualité du modèle devient insuffisant. Il faut regarder les permissions, les validations nécessaires, la journalisation, les possibilités d’annulation.
Le sujet bascule vers la gouvernance du système.
L’agent : une partie du chemin devient variable
L’agent ajoute autre chose : il ne reçoit plus nécessairement la totalité du chemin à suivre.
Prenons une demande plus ouverte :
« Analyse les résultats de la semaine et prépare le reporting commercial. »
Un système agentique peut récupérer les données, appliquer une méthode d’analyse, détecter un écart inhabituel, consulter une autre source, vérifier une hypothèse puis produire le rapport.
La séquence n’a pas besoin d’être entièrement écrite dans l’instruction de départ.
C’est là que se situe une différence utile avec un workflow classique.
Dans un workflow déterministe, la plupart des étapes ont été conçues à l’avance. Si A, alors B. Si B dépasse un seuil, alors C.
Dans un système agentique, certaines étapes dépendent de ce que le modèle observe pendant l’exécution.
Cette capacité ne crée pas pour autant une autonomie générale.
L’agent reste contraint par ses instructions, les outils auxquels il a accès, ses permissions et les règles d’arrêt définies autour de lui.
Mais une partie de l’orchestration change de main.
C’est probablement la distinction la plus utile : un agent ne fait pas uniquement davantage de choses. Il décide aussi, dans certaines limites, de ce qu’il doit faire ensuite.
Une progression qui n’est pas une hiérarchie
Il serait tentant de ranger ces notions dans une échelle :
prompt → skill → outil → agent.
La représentation est pratique. Techniquement, elle est fausse si on la prend trop au sérieux.
Un agent utilise des prompts.
Une skill peut contenir des prompts et des scripts.
Un outil peut fonctionner sans agent.
Un agent peut utiliser des outils sans disposer de skills formalisées.
Les catégories s’imbriquent.
Le terme « skill » lui-même reste dépendant des plateformes. Microsoft en fait aujourd’hui un composant explicite. D’autres environnements peuvent ranger les mêmes instructions sous une autre catégorie.
La distinction la plus robuste consiste donc à regarder la répartition des responsabilités.
Avec le prompt, l’humain décrit encore une grande partie de la tâche.
Avec la skill, il rend une méthode réutilisable.
Avec l’outil, il donne au système accès à une action.
Avec l’agent, il lui confie une partie du choix des étapes.
Plus on avance, plus le système gagne en latitude. Le contrôle direct diminue en proportion.
Ce n’est ni un progrès automatique ni un problème en soi. C’est un arbitrage de conception.
Après le prompt engineering, la conception des processus
L’importance prise par le prompt engineering correspondait assez bien à la première phase d’usage des modèles génératifs : l’utilisateur formulait une demande, le modèle répondait.
Les architectures agentiques déplacent déjà le travail ailleurs.
Dès qu’un système dispose de méthodes réutilisables, d’outils et d’une capacité d’orchestration, la qualité du résultat dépend beaucoup de la manière dont le travail a été découpé en amont.
Quelles décisions peuvent être formalisées ?
Quelles actions nécessitent encore une validation ?
Quelle information le système peut-il consulter seul ?
À quel moment doit-il s’arrêter et rendre la main ?
Ce sont des questions de processus, davantage que des questions de formulation.
Il y a là un changement possible dans la nature même de l’expertise recherchée.
Savoir rédiger une bonne instruction restera utile. Mais cette compétence devient secondaire dès que le problème consiste à transformer une pratique métier en système partiellement exécutable.
Le travail difficile est alors de rendre explicites les choses que les professionnels font souvent sans les formuler : les contrôles implicites, les exceptions, les signaux faibles, les moments où une règle cesse d’être valable.
C’est là que la prospective devient intéressante.
Si les agents se diffusent réellement dans les organisations, l’avantage pourrait moins venir de la capacité à « bien parler à l’IA » que de la capacité à décrire correctement le travail.
Cela suppose une connaissance assez fine des métiers pour distinguer ce qui peut être automatisé, ce qui peut être délégué sous contrôle et ce qui reste difficile à formaliser.
Un mauvais prompt produit une mauvaise réponse.
Un mauvais processus, confié à un agent compétent, peut produire une mauvaise décision avec beaucoup plus d’efficacité.
La différence mérite qu’on s’y attarde.