IA conversationnelle, assistants, agents, workflows : comprendre les briques derrière les outils

Après avoir exploré le fonctionnement des IA conversationnelles, puis la manière de construire un échange plus utile avec elles, nous pouvons maintenant prendre un peu de recul. Dans les articles Comprendre les IA conversationnelles : dialogue, apprentissage et illusion de compréhension et Dialoguer avec une IA : prompts, méthodes et construction d’un échange, nous étions surtout placés du côté de l’utilisateur : que se passe-t-il lorsque nous posons une question, reformulons une demande ou guidons progressivement une réponse ?

Nous allons maintenant regarder ce qui se cache derrière ces usages. Lorsque nous utilisons ChatGPT, Claude, Gemini, Perplexity, DeepSeek ou d’autres services comparables, nous avons souvent l’impression d’être face à des outils de même nature, notamment parce qu’ils se présentent d’abord sous la forme d’une interface de dialogue. Pourtant, derrière cette apparence commune, plusieurs fonctions et composantes peuvent être assemblées de façons différentes. La plupart des éditeurs proposent aujourd’hui, sous des noms parfois différents, des modèles d’IA, des chatbots, des assistants spécialisés, des outils, des applications connectées, des agents ou encore des workflows. Ces différentes briques peuvent se côtoyer dans un même produit sans pour autant jouer le même rôle. L’objectif de cet article est donc de proposer une grille de lecture simple, centrée sur les concepts plutôt que sur les marques, afin de mieux distinguer leur fonction et la manière dont elles peuvent s’articuler.

Préambule : Une nomenclature pour garder les mêmes repères

Avant d’aller plus loin, il est utile de fixer quelques repères. Les éditeurs n’emploient pas toujours les mêmes mots pour désigner des fonctions proches, et certaines appellations peuvent recouvrir plusieurs usages. Dans cet article, nous utiliserons donc une nomenclature volontairement stable, fondée sur le rôle joué dans le système plutôt que sur le nom commercial choisi par chaque éditeur.

Nous parlerons ainsi de modèle d’IA, de chatbot, d’assistant spécialisé, d’outil, d’application connectée, d’agent ou de workflow. Ces notions seront précisées au fil de l’article et rapprochées des appellations employées par les différents éditeurs dans le tableau du chapitre « Comparer les éditeurs sans confondre les concepts ».

Nous emploierons également quelques termes transversaux, brique, moteur, pile, niveau, couche, socle et système, avec un sens précis que nous conserverons tout au long de l’article ; le tableau ci-dessous en fixe la définition de référence.

Un point reste essentiel : une brique décrit un rôle, alors qu’un même produit peut réunir plusieurs briques. Les appellations proposées par les différents éditeurs doivent donc être lues comme des exemples, et non comme des équivalences strictes.

Pourquoi autant de nouveaux termes ?

La confusion vient d’abord de notre point d’entrée. Pendant longtemps, beaucoup d’entre nous ont découvert l’intelligence artificielle générative sous une forme très simple : une conversation. Nous écrivions une question, l’outil répondait, puis nous reformulions. Cette expérience a installé une image mentale forte : l’IA serait avant tout une interface de dialogue. Pour commencer, cette représentation est utile. Elle permet de tester, de comprendre et d’expérimenter sans préparation technique particulière.

Mais les usages ont rapidement dépassé cette première forme. La même famille de technologies peut aujourd’hui résumer un document, analyser un fichier, écrire du code, générer une image, chercher de l’information ou préparer une suite d’actions. Nous ne sommes donc plus seulement face à une fenêtre de discussion. Nous sommes face à des systèmes qui peuvent assembler plusieurs briques, chacune remplissant un rôle particulier.

Chaque éditeur organise ensuite ces fonctions avec son propre vocabulaire. Un assistant spécialisé pourra ainsi prendre la forme d’un GPT personnalisé chez OpenAI, d’un Gem chez Google, d’un Project chez Anthropic, d’un Space chez Perplexity ou d’un Agent chez Mistral AI. Ces appellations ne recouvrent pas toujours exactement les mêmes fonctions. C’est pourquoi, comme nous l’avons posé dans le préambule, nous nous intéresserons d’abord au rôle joué par chaque brique, plutôt qu’au nom choisi par l’éditeur.

Imaginons que nous préparions un travail de recherche sur le rock des années 70. Nous voudrions classer des groupes, repérer des scènes musicales, relier des albums, identifier des producteurs, des ingénieurs du son, des managers ou quelques pièces hors normes. Au début, une simple conversation avec une IA peut suffire pour explorer une piste. Mais si nous devons croiser les sources, comparer les périodes, vérifier les liens entre les personnes et préparer une base documentaire, le besoin change de nature. À chaque étape, de nouvelles briques peuvent devenir nécessaires. Ce n’est pas le vocabulaire qui crée le besoin ; c’est le besoin qui nous oblige à distinguer les rôles.

Les grandes briques de l’IA moderne

Pour clarifier cet écosystème, nous pouvons reprendre la représentation en pile définie dans le préambule. À la base de notre parcours, nous trouvons le modèle d’IA, qui fournit la capacité de produire ou transformer du langage. Mais ce modèle n’est pas, à lui seul, une application complète. Il devient réellement exploitable lorsqu’une interface, un cadre de travail ou des outils viennent s’ajouter autour de lui.

La première forme visible est souvent le chatbot : nous lui écrivons, il répond, puis l’échange se construit. Viennent ensuite les assistants spécialisés, les outils, les applications connectées, les agents, les workflows et, plus loin, les applications métier assistées par IA. Dans cette représentation, chaque niveau ajoute une responsabilité ou un usage supplémentaire, sans nécessairement remplacer les précédents.

Dans notre exemple sur le rock des années 70, ces briques apparaîtront progressivement selon le besoin. Une question sur un groupe peut d’abord passer par un chatbot. Une recherche régulière demandera peut-être un assistant spécialisé. Un corpus de fichiers nécessitera des outils. Une base documentaire pourra appeler des connexions, puis éventuellement un agent, un workflow ou une application métier.

L’idée importante est simple : plus nous avançons dans cette représentation, moins nous parlons seulement d’intelligence artificielle, et plus nous parlons de système. L’IA reste importante, mais elle n’est pas toujours le centre. Elle agit dans un ensemble plus vaste, composé de données, d’interfaces, de règles, d’outils, de droits d’accès et de validations.

Le modèle d’IA : la brique qui produit le langage

Pour comprendre le rôle du modèle d’IA, il faut le distinguer de tout ce qui l’entoure. Le modèle est la partie qui produit ou transforme le langage à partir d’une demande, d’un contexte et de consignes. Il peut exister en plusieurs versions, évoluer dans le temps ou être adapté à certains usages. Mais dans notre grille de lecture, son rôle reste le même : fournir la capacité de génération et d’analyse sur laquelle les autres briques vont s’appuyer.

Dans l’écosystème actuel, plusieurs éditeurs développent leurs propres modèles ou familles de modèles : GPT chez OpenAI, Claude chez Anthropic, Gemini chez Google, Mistral chez Mistral AI, DeepSeek chez DeepSeek, et d’autres encore. Nous avions déjà présenté plusieurs de ces acteurs dans l’article « IA conversationnelles et développement web : dépasser les effets de mode ». Ici, nous les abordons autrement : non comme des produits à comparer, mais comme des exemples de la brique modèle, chargée de fournir les capacités de génération et d’analyse.

Cette distinction se voit particulièrement bien avec OpenAI, mais elle vaut aussi pour les autres éditeurs. GPT désigne une famille de modèles. ChatGPT, en revanche, est une application conversationnelle qui donne accès à ces modèles dans une interface de dialogue. Les GPTs personnalisés relèvent encore d’un autre rôle : ce sont des assistants configurés pour un usage particulier, auxquels on peut ajouter des consignes, des documents ou des outils. Nous retrouvons ce type de distinction chez Anthropic, Google, Mistral AI, Perplexity ou DeepSeek, même si chacun organise ses offres avec son propre vocabulaire.

Le modèle ne fonctionne jamais seul dans un contexte d’usage. Il reçoit une demande, des consignes, parfois des documents ou des données, puis produit une réponse. Cette demande lui est transmise par une interface, une application, une API ou un programme. Autrement dit, le modèle ne « décide » pas seul de travailler : il est appelé par une autre brique du système.

Pour éviter toute confusion, il faut donc distinguer ce que le modèle rend possible de ce que nous observons à l’écran. Dans notre projet sur le rock des années 70, le modèle représente la capacité à rapprocher le glam rock, le hard rock, le rock progressif ou le punk naissant, ou à proposer des liens entre groupes, albums, scènes locales, producteurs et ingénieurs du son. Mais ces rapprochements restent des sorties produites à partir d’un contexte donné. Ils devront ensuite être cadrés, vérifiés et organisés par les autres briques du système.

Un modèle seul ne connaît pas nécessairement notre corpus, nos sources, nos critères de classement ou le niveau de précision attendu. Il produit une réponse à partir du contexte fourni. Cette réponse peut être pertinente, mais elle peut aussi simplifier, généraliser ou proposer des associations crédibles en apparence. C’est pourquoi il faut garder une distinction essentielle : le modèle fournit une capacité, mais il ne garantit pas, à lui seul, la fiabilité d’un travail structuré.

Le modèle est donc le moteur, au sens défini dans notre préambule. Il peut être puissant, rapide et impressionnant, mais il ne constitue ni l’interface, ni la méthode, ni le système complet. Pour être utilisé dans un cadre concret, il doit être intégré à un dispositif d’usage : un chatbot, un assistant spécialisé, une application ou un système plus large.

Le chatbot : l’interface qui rend le dialogue possible

Le chatbot est souvent notre première rencontre avec l’IA. Nous écrivons une demande, il répond, puis nous pouvons préciser, corriger ou relancer l’échange. Cette forme est simple à comprendre, parce qu’elle reprend un geste familier : poser une question et attendre une réponse.

Mais le chatbot n’est pas le modèle lui-même. Il est plutôt l’interface qui rend le dialogue possible. Lorsque nous utilisons ChatGPT, Claude, Gemini, Perplexity ou DeepSeek Chat, nous passons par un service qui organise la conversation, affiche les réponses, conserve parfois un historique, propose des options et ajoute certaines fonctions autour de cette expérience de dialogue.

Dans notre recherche sur le rock des années 70, nous pouvons poser une question simple : “Quels groupes relier à la scène glam rock britannique ?” ou “Quels albums ont marqué le passage entre le rock psychédélique et le rock progressif ?” Mais nous pouvons aussi formuler une demande plus précise : “Prépare une synthèse sur le krautrock berlinois entre 1970 et 1976, en distinguant les groupes, les albums studio, les performances live documentées et les collaborations avec des producteurs ou ingénieurs du son. Présente la réponse sous forme de tableau, puis ajoute une courte synthèse narrative.” Le chatbot peut alors proposer une première réponse, expliquer ses choix, puis les ajuster si nous précisons la période, les formats de sortie, le type de sources ou la structure attendue.

C’est déjà très utile pour explorer une idée, préparer une recherche ou clarifier un premier classement. Mais le chatbot reste dépendant de ce que nous lui donnons dans la conversation. S’il ne connaît pas notre corpus, nos critères ou nos sources, il risque de produire une réponse intéressante, mais trop générale. Le chatbot ouvre donc le dialogue ; il ne suffit pas toujours à structurer un projet durable.

L’assistant spécialisé : un cadre pour les usages récurrents

Lorsque le besoin devient plus précis ou plus régulier, le chatbot généraliste montre vite ses limites. Nous pouvons bien sûr répéter nos consignes à chaque conversation, rappeler le contexte, préciser la période, le pays, les sources attendues ou les critères de classement. Mais cette répétition devient vite fragile. Une consigne oubliée, un exemple mal formulé, un contexte trop court, et la réponse risque de s’éloigner du besoin réel.

C’est là qu’intervient l’assistant spécialisé. Il s’agit d’un espace de travail préparé pour une tâche ou un domaine particulier. On peut lui donner un rôle, des consignes, parfois des documents de référence, des exemples de réponses attendues ou des règles propres à un projet. L’objectif n’est pas de rendre l’IA “plus intelligente”, mais de mieux cadrer son usage.

Dans notre recherche sur le rock des années 70, nous pourrions imaginer un assistant chargé d’aider à organiser un corpus musical. Il saurait que nous ne voulons pas seulement lister des groupes, mais comprendre des relations : scènes locales, influences croisées, albums marquants, trajectoires de musiciens, rôle des producteurs ou apparition de nouvelles esthétiques. Au lieu de repartir de zéro à chaque échange, nous travaillerions avec un cadre déjà posé.

Selon les plateformes, cette idée prend des noms différents : GPTs personnalisés, Gems dans Gemini, Projects dans Claude, Perplexity propose aussi des Projects... Ces termes ne sont pas strictement équivalents, mais ils répondent ici à un besoin proche : préparer un assistant pour un usage récurrent, plutôt que tout reconstruire dans chaque conversation.

Il faut donc distinguer l’assistant spécialisé de l’agent, que nous verrons plus tard. L’assistant spécialisé répond dans un cadre. Il peut guider, reformuler, comparer ou aider à décider. Mais tant qu’il ne poursuit pas lui-même un objectif en plusieurs étapes avec des outils et des actions, il reste principalement un compagnon de travail. Utile, structuré, souvent très efficace, mais il reste centré sur l’accompagnement dans un cadre préparé.

Les outils : quand l’IA ne travaille plus seulement dans la conversation

Tant que nous échangeons quelques idées avec un chatbot, la conversation suffit. Mais dès que le travail repose sur des documents, des tableaux ou des données un peu nombreuses, le copier-coller devient vite une mauvaise méthode. On oublie des lignes, on perd le contexte, on résume trop vite, et l’IA travaille sur un extrait plutôt que sur la matière réelle.

C’est là qu’interviennent les outils. Un outil ajoute une capacité précise au système utilisant l’IA : lire un PDF, analyser un tableur, parcourir un fichier, interroger le web, exécuter un calcul, générer une image ou analyser un extrait de code. Il ne remplace pas l’assistant ; il lui donne une prise plus concrète sur le travail à effectuer.

Dans une interface de chatbot, les outils apparaissent souvent comme des capacités activables : lecture de fichiers, recherche web, génération d’image, calcul ou analyse de données. Les connexions à des services externes constituent un cas particulier que nous distinguerons dans le chapitre suivant.

Dans notre recherche sur le rock des années 70, imaginons un fichier contenant plusieurs centaines d’entrées : groupes, albums, années de sortie, pays, labels, producteurs, ingénieurs du son, liens supposés avec une scène musicale. Certaines données sont incomplètes ou ambiguës. Un même musicien peut être écrit de deux manières différentes, par exemple Brian Eno dans une ligne et Eno dans une autre. Un album live peut être confondu avec un album studio. Une date peut correspondre à l’enregistrement plutôt qu’à la sortie officielle. Un label peut être renseigné pour une réédition, alors que nous cherchons l’édition d’origine.

Sans outil de lecture ou d’analyse, nous devrions découper ce fichier en morceaux, copier des extraits dans la conversation et espérer que le fil reste cohérent. Avec plusieurs centaines de lignes, cette méthode devient vite fragile : nous risquons d’oublier une partie du corpus, de comparer des éléments incomplets ou de faire valider une erreur simplement parce qu’elle était bien formulée.

Avec un outil adapté, le système peut donner au modèle accès au contenu du fichier. Elle peut repérer des doublons probables, isoler les albums sans date, comparer les pays déclarés avec les scènes musicales attribuées, ou préparer une première liste d’éléments à vérifier. Elle peut aussi analyser des images lorsque l’outil le permet : lire le texte présent sur une pochette d’album, repérer une date sur une affiche de concert, relever le nom d’un label, d’un producteur ou d’un ingénieur du son dans un visuel scanné.

La demande change alors de nature. Nous ne lui demandons plus seulement : “Que sais-tu du krautrock ?” Nous pouvons formuler une consigne plus ancrée dans le corpus : “Dans ce fichier, repère les entrées liées au krautrock berlinois entre 1970 et 1976, distingue les albums studio des captations live, puis signale les lignes dont les sources semblent insuffisantes. À partir des pochettes ou affiches fournies, relève aussi les noms de labels, de producteurs ou de lieux qui pourraient compléter le classement.”

L’outil ne rend pas la réponse automatiquement juste, mais il déplace le travail vers une matière identifiable : fichiers, données, documents, tableaux, sources. C’est un progrès important, à condition de garder un contrôle clair. Un outil peut mal interpréter une colonne, s’appuyer sur une source faible ou produire un tableau convaincant qui mélange hypothèse et fait établi. Plus nous donnons au système accès à des contenus ou à des données, plus nous devons définir ce qui doit être vérifié.

Les applications connectées : relier l’IA aux environnements existants

Avec les outils, l’IA peut traiter un fichier, une image ou un document que nous lui fournissons. Mais dans un vrai projet, les informations sont rarement réunies dans un seul fichier propre. Elles vivent souvent dans plusieurs endroits : un dossier partagé, un tableur, une base de données, un gestionnaire de notes, un CMS, un dépôt de code ou un espace documentaire. À ce moment-là, le problème n’est plus seulement d’analyser un document, mais de relier le système utilisant l’IA à un environnement existant.

Cette connexion peut prendre plusieurs formes, mais elle devient réellement intéressante lorsque le système n’attend plus que nous lui déposions un fichier dans la conversation et peut accéder, dans un cadre défini, à des ressources déjà organisées. Elle peut être reliée à un espace de stockage comme Google Drive, dont l’API permet à une application d’accéder aux fichiers d’un Drive, à une base documentaire comme Notion, qui propose des connexions et une API pour organiser des pages et des bases de données, à un dépôt Git avec des outils comme GitHub Copilot, à un CMS comme WordPress via sa REST API, ou encore à un CRM comme Salesforce ou HubSpot, où l’IA peut s’appuyer sur des données clients, des échanges et des workflows déjà en place. Dans ce cas, elle ne travaille plus sur une copie isolée, mais sur un environnement déjà organisé, avec ses dossiers, ses données, ses droits d’accès et ses règles d’usage.

Pour les développeurs, la connexion peut aussi passer par un IDE ou un outil de développement assisté. L’IA peut alors lire l’arborescence d’un projet, analyser un fichier, proposer une modification ou préparer un correctif. Des outils comme Codex, Claude Code, Gemini Code Assist ou GitHub Copilot s’inscrivent dans cette logique : l’IA n’est plus seulement dans une fenêtre de conversation, elle intervient dans l’environnement où le travail est réellement produit.

Enfin, l’un des moyens les plus souples de réaliser cette connexion reste souvent l’API. Une application peut envoyer à un modèle des données précises, recevoir une réponse structurée, puis intégrer cette réponse dans son propre fonctionnement. Dans notre recherche sur le rock des années 70, une application documentaire pourrait envoyer à l’IA les informations d’un album, les notes associées et les champs à compléter. L’IA proposerait alors une scène musicale, des liens possibles avec d’autres groupes, des producteurs à vérifier ou des sources à consulter. Mais l’application garderait la main sur l’enregistrement, la validation et l’affichage.

Cette distinction est essentielle. Connecter une IA ne veut pas dire lui donner libre accès à tout. Il faut définir ce qu’elle peut lire, ce qu’elle peut proposer, ce qu’elle peut modifier et ce qui doit rester soumis à validation. Une connexion en lecture seule peut suffire pour explorer un corpus. Un droit d’écriture demande déjà plus de prudence. Une action automatique dans un système de production exige encore plus de contrôle.

Les applications connectées rapprochent donc les fonctions d’IA du travail réel. Elles permettent au système d’accéder, dans un cadre défini, aux documents, aux données et aux outils que nous utilisons déjà. Mais elles demandent aussi plus de méthode. Connecter une IA, ce n’est pas seulement lui ouvrir une porte ; c’est décider quelles pièces elle peut visiter, ce qu’elle peut y faire, et à quel moment nous devons reprendre la main.

Les agents : de la réponse ponctuelle à la mission encadrée

Le mot agent est aujourd’hui très utilisé, parfois trop vite. Il peut donner l’impression d’un système capable de travailler seul, de comprendre un objectif et de le mener jusqu’au bout sans surveillance. Dans la pratique, il faut rester plus précis. Un agent n’est pas une IA “magique”. C’est une brique capable de prendre en charge une tâche en plusieurs étapes, en s’appuyant sur un modèle, des consignes, des outils et, lorsque nécessaire, des applications connectées.

Concrètement, nous pouvons rencontrer un agent dans plusieurs contextes. Dans ChatGPT, par exemple, lorsque l’option est disponible dans l’offre utilisée, le mode agent peut être lancé depuis le menu des outils ou en saisissant /agent dans la zone de rédaction. OpenAI présente l'agent ChatGPT comme un mode capable de raisonner, rechercher et agir à partir d’outils comme un navigateur visuel, l’analyse de fichiers, des applications connectées ou un terminal, tout en demandant des confirmations lorsque c’est nécessaire. Dans d’autres environnements, cette logique agentique peut prendre des formes spécialisées : Codex ou Claude Code pour le développement, des agents de recherche approfondie comme Gemini Deep Research, ou encore des agents construits sur mesure dans une application métier.

La différence se voit mieux si nous reprenons notre projet musical. Si nous demandons à un chatbot : “Quels groupes peut-on associer au krautrock berlinois ?”, il répond à une question. Si nous utilisons un assistant spécialisé, il peut répondre dans un cadre plus stable, en tenant compte de nos critères de classement. Si nous lui ajoutons un outil, il peut lire un fichier d’albums ou analyser des pochettes. Mais l’agent commence lorsque nous lui confions une mission à conduire, avec des étapes, des sources et un résultat attendu. Par exemple, dans un mode agent, la demande pourrait ressembler à ceci :

/agent

Nous préparons un corpus de travail sur le krautrock, avec un intérêt particulier pour la période 1968-1978.

À partir des trois sources suivantes :
- https://www.ranker.com/list/krautrock-bands-and-musicians/reference
- https://www.senscritique.com/liste/Les_100_albums_indispensables_du_Krautrock/164589
- https://fr-academic.com/dic.nsf/frwiki/924416#Principaux_groupes_ou_artistes

Réalise une analyse documentaire en plusieurs étapes.

1. Parcours les trois pages et identifie les groupes, musiciens et albums mentionnés.
2. Distingue les groupes, les artistes solo, les albums studio, les compilations éventuelles et les éléments ambigus.
3. Repère les artistes ou groupes qui apparaissent dans les trois sources.
4. Identifie les albums qui semblent revenir comme références importantes du krautrock.
5. Lorsque c’est possible, associe chaque album à son artiste, son année de sortie et sa période approximative.
6. Classe les éléments en grandes tendances : krautrock expérimental, électronique, motorik, rock psychédélique, rock progressif, ambient ou formes hybrides.
7. Signale les informations incertaines, les cas à vérifier et les éléments qui pourraient relever d’une définition élargie du krautrock.
8. Prépare un tableau de synthèse avec les colonnes suivantes :
   - artiste ou groupe ;
   - album ou élément cité ;
   - année ;
   - présence dans Ranker ;
   - présence dans SensCritique ;
   - présence dans fr-academic
   - tendance musicale dominante ;
   - niveau de confiance ;
   - points à vérifier.
9. Termine par une courte synthèse expliquant ce que ces trois sources permettent de comprendre du krautrock, mais aussi leurs limites.

Important :
- Ne fusionne pas des informations incertaines sans le signaler.
- Ne présente pas une hypothèse comme un fait établi.
- Lorsque les sources ne suffisent pas, indique clairement “à vérifier”.
- Garde une logique documentaire : l’objectif n’est pas de produire un classement définitif, mais une base de travail exploitable.

/agent

Nous préparons un corpus de travail sur le krautrock, avec un intérêt particulier pour la période 1968-1978.

À partir des trois sources suivantes :
- https://www.ranker.com/list/krautrock-bands-and-musicians/reference
- https://www.senscritique.com/liste/Les_100_albums_indispensables_du_Krautrock/164589
- https://fr-academic.com/dic.nsf/frwiki/924416#Principaux_groupes_ou_artistes

Réalise une analyse documentaire en plusieurs étapes.

1. Parcours les trois pages et identifie les groupes, musiciens et albums mentionnés.
2. Distingue les groupes, les artistes solo, les albums studio, les compilations éventuelles et les éléments ambigus.
3. Repère les artistes ou groupes qui apparaissent dans les trois sources.
4. Identifie les albums qui semblent revenir comme références importantes du krautrock.
5. Lorsque c’est possible, associe chaque album à son artiste, son année de sortie et sa période approximative.
6. Classe les éléments en grandes tendances : krautrock expérimental, électronique, motorik, rock psychédélique, rock progressif, ambient ou formes hybrides.
7. Signale les informations incertaines, les cas à vérifier et les éléments qui pourraient relever d’une définition élargie du krautrock.
8. Prépare un tableau de synthèse avec les colonnes suivantes :
   - artiste ou groupe ;
   - album ou élément cité ;
   - année ;
   - présence dans Ranker ;
   - présence dans SensCritique ;
   - présence dans fr-academic
   - tendance musicale dominante ;
   - niveau de confiance ;
   - points à vérifier.
9. Termine par une courte synthèse expliquant ce que ces trois sources permettent de comprendre du krautrock, mais aussi leurs limites.

Important :
- Ne fusionne pas des informations incertaines sans le signaler.
- Ne présente pas une hypothèse comme un fait établi.
- Lorsque les sources ne suffisent pas, indique clairement “à vérifier”.
- Garde une logique documentaire : l’objectif n’est pas de produire un classement définitif, mais une base de travail exploitable.

Ce type de requête montre bien le changement de rôle. Nous ne demandons plus seulement : “Que sais-tu du krautrock ?” Nous demandons à l’agent de parcourir des sources, d’extraire des informations, de les comparer, de signaler les incertitudes, puis de produire une base de travail structurée. Le chatbot répond à une question ; l’agent conduit une tâche.

Cela ne veut pas dire qu’il faut lui laisser tout décider. Un agent fiable a besoin d’un objectif clair, d’un périmètre, d’outils adaptés et de points de contrôle. Il doit pouvoir signaler ce qu’il ne sait pas, distinguer une hypothèse d’une information vérifiée, et s’arrêter lorsqu’une validation humaine est nécessaire. Sans ce cadre, la capacité d’action de l’agent devient vite une source d’erreurs.

On peut donc retenir une distinction simple : l’assistant aide à travailler ; l’agent prend en charge une tâche. Cette tâche peut être courte ou longue, simple ou complexe, mais elle suppose toujours un enchaînement d’étapes. C’est précisément ce qui nous mène à la notion suivante : le workflow.

Les workflows : organiser le chemin de travail

Un workflow désigne un enchaînement organisé de tâches. Le mot peut sembler technique, mais l’idée est simple : nous ne lançons plus seulement une demande dans une conversation. Nous préparons un chemin de travail, avec un point de départ, des étapes, des contrôles, parfois une validation humaine, puis une sortie exploitable.

La différence avec un agent tient surtout à leur rôle. L’agent prend en charge une tâche ; le workflow organise l’enchaînement dans lequel cette tâche peut prendre place. Cet enchaînement peut être lancé manuellement, planifié ou déclenché par un événement : une ligne ajoutée dans un tableur, un fichier déposé dans un dossier, un formulaire envoyé ou une nouvelle fiche créée dans une base.

Dans notre projet sur le rock des années 70, imaginons qu’une nouvelle entrée soit ajoutée dans une base documentaire : un groupe, un album, une année, un pays, une source. Cet ajout peut déclencher un workflow. La première étape vérifie que les champs essentiels sont présents. La deuxième demande à un agent de proposer une classification : krautrock, rock progressif, électronique, psychédélique, ambient ou forme hybride. La troisième signale les incertitudes. La quatrième envoie la proposition à une personne pour validation. La fiche n’est intégrée à la base principale qu’après relecture.

C’est lorsque ce chemin de travail doit être automatisé ou relier plusieurs services que les outils d’automatisation deviennent particulièrement utiles. Dans ChatGPT Plus, nous pouvons lancer un agent ou utiliser certaines tâches planifiées, mais nous ne construisons pas encore un workflow métier complet reliant plusieurs applications, avec des déclencheurs externes, des écritures dans une base, des notifications et des validations. Pour cela, on s’appuie généralement sur des outils comme Make, n8n ou Zapier, ou sur une intégration développée avec une API d’IA. Ces plateformes servent précisément à relier des services, déclencher des actions et faire circuler des données entre plusieurs étapes.

Le workflow pourrait alors ressembler à ceci :

• une nouvelle ligne apparaît dans le tableur,
• Make, n8n ou Zapier détecte l’événement,
• les données sont envoyées à une API d’IA ou à un agent,
• une classification est proposée,
• le résultat est enregistré dans une colonne “à vérifier”,
• une notification est envoyée au responsable du corpus,
• après validation, la fiche passe dans la base principale.

L’IA intervient bien dans le processus, mais elle n’est qu’une étape dans une chaîne plus large.

On peut donc retenir une distinction simple : l’agent conduit une tâche ; le workflow organise le circuit dans lequel cette tâche prend place. Un workflow peut contenir un agent, plusieurs agents, des outils classiques, des scripts, des appels API, des notifications, des validations humaines ou même aucune IA. Ce n’est pas l’intelligence artificielle qui définit le workflow, mais l’organisation du travail à accomplir.

Cette approche évite de tout mélanger. Elle permet de séparer la collecte, le classement, la vérification, la synthèse et la publication. Chaque étape devient plus lisible, donc plus facile à corriger et à faire évoluer. Le workflow transforme une intention générale en chemin de travail contrôlé.

Pour approfondir, on peut consulter les pages officielles de Make, n8n et Zapier, qui illustrent bien cette logique d’automatisation entre applications. Pour un futur article plus technique, le même principe pourra être repris avec une API d’IA, comme l’API OpenAI, afin de montrer comment une application peut envoyer des données à un modèle puis récupérer une réponse structurée.

Les applications métier assistées par IA

Lorsque l’on parle d’intelligence artificielle, nous avons parfois tendance à imaginer que tout passe par elle. Comme si l’IA devait recevoir une demande, comprendre tout le contexte, produire toutes les étapes, prendre les décisions et livrer le résultat final. Cette représentation est séduisante, mais elle correspond rarement à la réalité des projets. Dans la plupart des cas, une application efficace ne repose pas sur une IA qui ferait tout, mais sur un système bien construit dans lequel l’IA intervient au bon endroit.

À ce stade, il faut revenir à une idée simple : nous ne quittons pas le terrain classique de l’application. Elle possède une interface, souvent construite en HTML, CSS et JavaScript. Elle s’appuie sur une partie serveur, développée en PHP, Node.js, Python ou un autre environnement. Elle dialogue avec une base de données, gère des droits d’accès, conserve des historiques, applique des règles de validation et produit des sorties utiles. Des fonctions d’IA viennent ensuite se greffer sur ce socle, sous forme de modules ou de services : un appel API, un agent chargé d’analyser un corpus, un workflow déclenché par une nouvelle entrée, ou un outil de synthèse intégré à l’interface.

Dans notre projet sur le rock des années 70, imaginons un outil documentaire dédié au corpus. L’utilisateur ne travaillerait pas directement “dans l’IA”. Il consulterait une interface classique : fiches artistes, albums, scènes, labels, producteurs, sources. Lorsqu’une nouvelle fiche est créée, un module IA pourrait proposer des rapprochements, signaler des incohérences, suggérer une classification ou résumer une notice. Mais l’application garderait la main : elle afficherait la proposition, conserverait les sources, demanderait une validation, puis enregistrerait seulement ce qui a été confirmé.

Dans ce type d’application, une proposition de l’IA ne devrait pas devenir automatiquement une information enregistrée. Si elle suggère de rattacher un album à la scène krautrock berlinoise, l’interface devrait permettre, lorsque c’est possible, d’identifier les éléments sur lesquels la proposition s’appuie : une source consultée, un extrait repéré sur une pochette, une date de sortie, le nom d’un label, la présence d’un producteur ou une comparaison avec d’autres albums du corpus. La personne qui relit doit ensuite pouvoir accepter, corriger, refuser ou marquer l’information comme à vérifier. C’est cette étape qui donne sa valeur au système : l’IA propose, mais l’application organise la preuve, la validation et la mémoire de la décision.

Le véritable enjeu n’est donc pas de mettre une IA partout. Il consiste à décider où l’IA apporte une aide réelle, où elle doit rester silencieuse, et où la décision doit rester humaine. C’est probablement l’un des points les plus importants à comprendre, car il rappelle une idée simple : l’intelligence artificielle n’est pas une finalité technique, mais une composante au service d’un besoin.

Comparer les éditeurs sans confondre les concepts

Comparer les éditeurs reste utile, à condition de ne pas inverser la logique. Les produits changent vite, les appellations évoluent, certaines fonctions apparaissent, disparaissent ou se déplacent d’une offre à l’autre. Le tableau qui suit ne doit donc pas être lu comme une règle définitive, mais comme une photographie indicative de l’écosystème actuel.

OpenAI, Anthropic, Google, Perplexity, Mistral AI, DeepSeek et d’autres acteurs proposent aujourd’hui des briques répondant à des rôles proches : chatbots généralistes, modèles, assistants personnalisés, outils, recherche web, fonctions de recherche approfondie, API, agents ou environnements de développement assisté. Chacun les organise avec son vocabulaire, ses limites et ses choix d’intégration. Ce qui nous intéresse ici n’est donc pas le nom exact donné par chaque éditeur, mais le rôle joué par chaque brique dans le système, conformément aux repères posés au début de l’article.

L’intérêt du tableau ci-dessous n’est donc pas de mémoriser les appellations. Il est de garder la bonne question en tête : quel rôle joue cette brique dans le système ? Est-ce qu’elle permet de dialoguer, de cadrer un usage, de lire un document, de se connecter à une application, de conduire une tâche ou d’intégrer l’IA dans un développement métier ?

Conclusion : ce qu’il faut retenir

Lorsque nous parlons d’IA, nous utilisons souvent un seul mot pour désigner des réalités très différentes. Pourtant, un modèle d’IA, un chatbot, un assistant spécialisé, un outil, une application connectée, un agent, un workflow ou une application métier assistée par IA ne remplissent pas le même rôle.

Le modèle fournit la capacité de génération et d’analyse. Le chatbot rend le dialogue possible. L’assistant spécialisé installe un cadre. Les outils ajoutent des capacités opérationnelles. Les applications connectées ouvrent l’accès à des environnements existants. L’agent prend en charge une tâche en plusieurs étapes. Le workflow organise le chemin de travail. L’application métier assemble ces éléments autour d’un usage réel.

Dans notre exemple sur le rock des années 70, une simple question pouvait progressivement devenir un projet documentaire : classer des groupes, relier des scènes, vérifier des albums, identifier des producteurs, suivre des influences, construire une base de recherche. À mesure que le besoin se précise, nous ne cherchons plus seulement “une IA”, mais les bonnes briques pour les bons rôles.

L’intelligence artificielle n’est généralement qu’une composante d’un système plus vaste. Elle devient vraiment utile lorsqu’elle est placée dans un contexte clair, avec des sources identifiées, des outils adaptés, des limites explicites et des validations humaines. Cette grille de lecture pourra nous servir de repère dans les prochains articles consacrés aux API, aux agents, aux environnements de développement assistés par IA, aux workflows ou aux applications métier.