10 agents IA pour piloter plusieurs sites e-commerce

Un agent par domaine de travail

Le système compte dix agents. Les rôles les plus visibles couvrent plusieurs moments de la chaîne e-commerce :

Les trois autres rôles ne sont pas nécessaires pour comprendre le fonctionnement général. Le système reste lisible parce que chaque agent a un domaine qu'il doit connaître suffisamment bien, et un ensemble d'actions qu'il n'a pas besoin de posséder.

Cette séparation évite de transformer un seul agent en énorme prompt qui devrait connaître les produits, les campagnes, le SEO, les stocks et les habitudes personnelles de son utilisateur. Un agent peut être bon en rédaction et mauvais en gestion de catalogue. Un autre peut avoir besoin d'accéder à Meta Ads, sans avoir la moindre raison de lire les emails personnels.

Cette logique rejoint le travail que je mène sur les agents IA et l'automatisation en entreprise : le modèle vient après le processus. Il faut d'abord savoir qui lit quoi, qui prépare quoi et qui a le droit d'agir. Selon le niveau d'autonomie recherché, un agent comme Hermes peut ensuite orchestrer une partie de ces actions.

L'expert de marque devient une pièce centrale

Dans une architecture multi-agents, la connaissance de la marque est souvent plus importante que le choix d'un prompt particulièrement sophistiqué.

L'agent expert de la marque connaît les produits, les manuels d'utilisation, les caractéristiques importantes et le ton à employer. Il peut servir de point de référence aux autres agents quand ils doivent produire un texte : fiche produit, article de blog, landing page, campagne publicitaire ou publication sociale.

Cela ne veut pas dire que l'agent de marque doit tout faire. Son rôle est plutôt de fournir le contexte qui évite aux autres agents d'inventer un argument ou de décrire un produit de manière incohérente.

La distinction est utile :

• l'agent e-commerce manipule les informations et les surfaces de la boutique ;
• l'agent SEO travaille la structure et la visibilité des contenus ;
• l'agent visuel produit les assets nécessaires ;
• l'agent de marque protège la cohérence de l'ensemble.

Sans cette séparation, chaque agent finit par avoir sa propre version de la marque. Les textes peuvent être corrects pris séparément, mais contradictoires dès qu'on les compare.

Une conversation peut faire intervenir plusieurs agents

Tous les échanges ne restent pas isolés. Dans certains cas, plusieurs agents interviennent dans une même conversation.

Un exemple simple :

1. L'entrepreneur demande une landing page pour un produit.
2. L'agent expert de la marque rédige une première version à partir des informations disponibles.
3. L'agent SEO reprend le texte et signale les améliorations à apporter.
4. L'agent e-commerce applique le résultat sur la boutique ou publie le contenu au bon endroit.

Le premier agent n'a pas besoin de tout savoir ni de tout exécuter. Il peut demander l'intervention du spécialiste concerné, puis reprendre le résultat dans la suite de la conversation.

C'est la différence entre une collection d'assistants indépendants et un système d'agents. Dans le premier cas, l'utilisateur doit copier-coller le travail d'un outil à l'autre. Dans le second, les agents peuvent se transmettre une demande structurée, à condition que les rôles et les limites soient bien définis.

La délégation ne supprime pas les contrôles. Une page peut être bien écrite et mal positionnée. Un texte peut respecter le ton de marque et contenir une information produit obsolète. Une publication peut être prête sans devoir partir immédiatement. La chaîne doit donc indiquer à quel moment on prépare, à quel moment on modifie et à quel moment on publie.

Discord sert d'interface de travail

Les agents sont principalement utilisés depuis Discord, avec des discussions individuelles organisées en threads. Ce choix répond à un problème très concret : éviter qu'un seul fil devienne un historique illisible de toutes les boutiques, campagnes et tâches personnelles.

Un thread permet de garder le sujet visible et d'éviter de mélanger son historique avec celui des autres tâches. L'utilisateur peut ouvrir une conversation avec l'agent e-commerce pour une fiche produit, une autre avec l'agent personnel pour son calendrier, puis réunir plusieurs agents quand une tâche traverse plusieurs domaines.

Discord n'est pas pour autant le système de contrôle. C'est l'interface que l'utilisateur voit. Les données de référence, les droits, les journaux d'action et les mécanismes de reprise doivent rester définis dans les outils connectés et dans l'architecture du projet.

Pour une entreprise qui veut simplement ajouter un bot dans un canal, la distinction compte. Un canal de discussion ne règle pas les doublons de catalogue, les erreurs de stock, les mauvaises audiences publicitaires ou la publication d'un contenu non relu. Il rend le travail plus naturel. Il ne remplace pas les règles métier. La même prudence vaut pour la base technique : un stack self-hosted avec Hetzner, Coolify et n8n peut donner du contrôle, mais il ajoute aussi une responsabilité d'exploitation.

MCP donne accès aux outils, pas une autorisation générale

L'agent Ads est connecté à Meta Ads via MCP. Ce type de connexion permet de faire travailler l'agent dans un environnement qui dépasse la simple génération de texte.

Mais le sigle MCP ne décide pas à la place de l'entreprise ce que l'agent peut faire. Il faut encore distinguer plusieurs niveaux :

• lire les campagnes et leurs paramètres ;
• préparer une modification ;
• modifier une campagne existante ;
• lancer une campagne ou changer un budget ;
• arrêter une campagne et en expliquer la raison.

Ces actions n'ont pas le même risque. La connexion technique peut être fonctionnelle alors que la permission métier est mal définie. C'est exactement le type de frontière que je détaille dans l'article sur la validation humaine des agents IA en production.

Le même raisonnement s'applique à l'agent e-commerce. Modifier un brouillon de fiche produit n'engage pas l'entreprise de la même manière que changer un prix, une information de stock ou une page visible par les clients.

Un abonnement ne remplace pas une architecture conforme

Dans la configuration décrite ici, l'ensemble est opéré autour d'un abonnement ChatGPT Pro à 200 €, au niveau Pro 20X. Ce montant correspond au montage de ce projet. Ce n'est ni un tarif commercial de Kirako, ni une estimation générale du coût d'un système multi-agents.

Le chiffre ne suffit pas à qualifier l'architecture. La documentation officielle d'OpenAI sur les niveaux ChatGPT Pro, consultée le 18 septembre 2026, rappelle que l'usage doit respecter des limites concernant notamment l'extraction automatique ou programmatique, le partage des identifiants, la mise à disposition du compte à d'autres personnes et l'utilisation de ChatGPT pour alimenter un service tiers. Pour un déploiement automatisé ou multi-utilisateur, il faut donc vérifier la voie d'accès et l'offre autorisées avant de reproduire ce montage. Un abonnement ChatGPT n'est pas une licence générique pour exposer dix agents à des utilisateurs ou à un service externe.

La majorité des agents utilise GPT-5.6 Sol, avec Terra et Luna pour certains besoins. Tous les rôles n'ont pas besoin du même niveau de modèle, ni de la même vitesse, ni de la même façon de traiter une demande.

Le nombre d'agents ne suffit donc pas à calculer le coût ou la complexité. Il faut aussi regarder les outils connectés, la génération d'images et de vidéos, l'hébergement, les accès aux plateformes, la surveillance et la maintenance. Le choix des modèles mérite une analyse séparée, comme dans le comparatif entre modèles IA ouverts et propriétaires.

Le bon découpage n'est pas forcément celui qui crée le plus d'agents. Il consiste à séparer les responsabilités quand cela améliore la qualité, la sécurité ou la lisibilité du travail. Un agent dédié au SEO a du sens s'il relit réellement les contenus. Il ajoute seulement du bruit s'il répète les mêmes instructions que l'agent de marque.

Ce qu'il faut cadrer avant de reproduire le montage

Avant de créer dix agents, je commencerais par cinq questions :

1. Quelle est la source fiable ? Les informations produit, les stocks, les manuels et les règles de marque ne doivent pas être copiés dans plusieurs endroits sans responsable clair.
2. Quelles actions sont autorisées ? Il faut séparer lecture, préparation, modification, publication et dépense publicitaire.
3. Quand faut-il une validation humaine ? Une règle simple vaut mieux qu'un vague "fais attention" ajouté au prompt.
4. Comment retrouver ce qui s'est passé ? Une équipe doit pouvoir identifier la demande, l'agent intervenu, l'outil utilisé et le résultat obtenu.
5. Que se passe-t-il en cas d'erreur ? Une publication, une modification de stock ou une campagne doivent avoir une procédure de correction et, si possible, de retour en arrière.

Ces questions sont plus durables que la liste exacte des modèles utilisés aujourd'hui. Les modèles changeront. Les responsabilités, les droits et les données critiques resteront au coeur du système.

Ce que je retiens de ce projet

Le projet vise à rendre le travail transmissible entre spécialistes, tout en gardant une limite claire autour des actions qui engagent la boutique, la marque ou le budget publicitaire.

Pour un entrepreneur qui gère plusieurs sites, le premier chantier ne sera pas forcément un système de dix agents. Il peut commencer par une seule boucle : prendre une information produit fiable, produire une page cohérente, la faire relire et décider précisément qui a le droit de la publier.

Quand cette boucle fonctionne, les autres agents deviennent plus faciles à ajouter. On sait quelles données ils doivent lire, quelles actions ils peuvent préparer et où l'humain doit reprendre la main. C'est à ce moment que l'on passe d'une collection de prompts à un véritable système d'agents IA connecté au travail de l'entreprise. Pour cadrer les sources, les permissions et le premier flux, un audit IA est souvent plus utile que l'installation immédiate de dix agents.