01 //
Contexte
Le client gérait seul une boutique en ligne en croissance. Avec la hausse des ventes, les demandes de suivi de commande, de conseil produit et de retour occupaient une place croissante dans son quotidien.
Le volume était estimé à environ 300 conversations par mois. Les demandes s’accumulaient et le retard de traitement augmentait.
Il souhaitait continuer à travailler seul à court terme. La mission consistait à alléger la relation client sans recruter immédiatement, tout en préparant une base capable d’accueillir d’autres usages.
02 //
Le problème
Pour répondre utilement, le système devait connaître les règles de la boutique, retrouver les informations du client et comprendre sa demande. Une question sur une commande ou un retour dépend de données et de conditions propres à chaque situation.
Il fallait aussi définir jusqu’où l’IA pouvait intervenir. Une demande ambiguë, un produit endommagé ou un client agacé nécessitent une reprise humaine, même lorsqu’ils concernent un sujet habituellement traité par le support.
L’enjeu était donc de délimiter un périmètre d’autonomie utile au commerçant et de prévoir un passage de relais dès que la situation le justifiait.
03 //
La solution
J’ai conçu un copilote relié à une base de connaissances, aux règles métier de la boutique et aux informations clients nécessaires au traitement des demandes. Pour sécuriser son fonctionnement, j’ai limité ses accès en écriture et défini les situations à transmettre au commerçant.
Un orchestrateur central identifie le type de demande, applique les règles et oriente le traitement vers le modèle ou l’agent adapté. Le système consulte ensuite les informations utiles pour formuler une réponse ou transmettre la conversation au commerçant.
Le périmètre mis en production couvre les questions courantes, l’identification d’un client connu, la vérification d’une commande, le conseil produit, certaines demandes de retour et la rédaction de courriels.
La relation client constitue le premier usage. L’architecture prévoit des extensions vers la fidélisation, l’emailing, l’acquisition ou l’analyse de données, à développer progressivement selon les besoins.
04 //
Mon intervention
J’ai pris en charge le cadrage, la conception fonctionnelle, le développement assisté par IA, les tests et la livraison. Le client a apporté sa connaissance métier, validé les règles et fait des retours sur les réponses du copilote.
Cadrage et choix de l’approche
J’ai analysé le besoin et comparé les approches possibles pour définir un premier périmètre de relation client. Ce travail a permis de préciser les demandes à prendre en charge, les informations nécessaires et les situations à transmettre au commerçant.
Base de connaissances et règles métier
J’ai structuré les connaissances de la boutique, mis en place leur vectorisation et formalisé les règles de traitement. Le copilote s’appuie sur une approche RAG. Il recherche les informations utiles dans cette base, puis les utilise comme contexte pour rédiger sa réponse.
Architecture et intégrations
J’ai conçu la logique d’orchestration qui oriente chaque demande vers le modèle ou l’agent adapté. J’ai relié ce traitement à la base de connaissances et aux informations clients nécessaires, puis intégré les règles d’escalade qui déclenchent une reprise humaine.
Sécurité et confidentialité
J’ai encadré l’autonomie du copilote pour limiter le risque d’actions inadaptées sur la boutique. Les cas sensibles reviennent au commerçant et les décisions sont enregistrées dans des logs consultables pour comprendre le traitement d’une demande.
Le volet confidentialité reste à compléter par la vérification des droits de consultation des données clients, des conditions de traitement chez les fournisseurs IA et de la durée de conservation des logs.
Développement, livraison et suivi
J’ai développé le système avec Claude Code, réalisé les tests et assuré la livraison. Après le déploiement, j’ai analysé les premiers résultats et prévu un suivi des conversations pour guider les ajustements de la base de connaissances, des règles et des prompts.
05 //
Décisions clés
Sécuriser le traitement par des règles d’escalade
J’ai intégré à l’orchestration des règles d’escalade qui définissent quand le système doit passer la main. Une demande ambiguë dès le départ, un cas sensible comme un produit arrivé endommagé, un signe d’agacement ou une conversation dépassant cinq échanges déclenchent une alerte au commerçant.
Le commerçant peut alors reprendre la conversation. Le seuil de cinq échanges ajoute une limite concrète pour éviter qu’un dialogue se prolonge sans aboutir, même si le sujet semble relever du support courant.
Limiter les permissions et contrôler les accès aux données
Le copilote ne dispose pas d’un accès d’écriture complet à la boutique. Cette restriction s’inscrit dans une logique de moindre privilège, qui consiste à ne donner à un outil que les droits utiles à sa mission.
Le contrôle d’autorisation côté serveur est un complément recommandé, à confirmer dans l’implémentation. Avant de transmettre des informations sur une commande, l’application doit vérifier que le client est autorisé à les consulter. Cette vérification doit être assurée par le code, indépendamment des consignes données au modèle.
Retrouver la bonne information grâce aux embeddings
J’ai vectorisé les contenus de la base de connaissances. Un modèle les transforme en embeddings, des représentations numériques qui permettent de comparer leur sens. La question du client est convertie de la même manière pour rechercher les contenus les plus proches.
Cette recherche sémantique permet de retrouver une information même si le client utilise d’autres mots. Par exemple, « Je veux renvoyer mon article » peut être rapproché des conditions de retour de la boutique.
Les contenus sélectionnés sont ensuite fournis au modèle pour préparer sa réponse. C’est le principe du RAG. L’intérêt est de lui transmettre un contexte ciblé, sans charger toute la documentation à chaque échange, et d’ancrer ses réponses dans les informations propres à la boutique.
Faire évoluer le système à partir des conversations
J’ai mis en place des logs, un journal des conversations et des décisions du copilote, consultable et annotable. Ils permettent de revenir sur un échange précis, d’identifier ce qui a été mal traité et de repérer les erreurs qui se répètent.
La méthode consiste à relire les échanges et à qualifier le problème pour corriger le bon élément. Il s’agit d’enrichir la base si une information manque, d’ajuster une règle métier si le traitement est inadapté, ou de préciser les consignes données au modèle dans le prompt si la réponse est mal formulée.
Après chaque ajustement, l’observation des nouveaux échanges permet de vérifier si le problème se reproduit. L’amélioration repose ainsi sur un diagnostic, une correction ciblée et une nouvelle observation, avec une validation humaine des changements.
06 //
Résultats mesurés
Une première estimation autour de 47 % de résolutions autonomes
Après le déploiement, une première estimation situe autour de 47 % la part des demandes entièrement résolues sans intervention humaine.
Ce chiffre reste à confirmer sur une période et un périmètre définis, en précisant les conversations retenues dans le calcul et les critères de résolution. Il donne un premier repère sur l’autonomie du système.
Un premier périmètre de support opérationnel
Le copilote prend en charge une partie des demandes courantes et alerte le commerçant lorsque les règles prévoient une reprise humaine. Les gains de temps et l’évolution de la satisfaction client restent à mesurer.
Un historique exploitable pour les prochaines évolutions
Les échanges et les décisions restent accessibles pour identifier les erreurs, ajuster le périmètre et choisir les prochains usages à développer. Le commerçant dispose ainsi d’une base pour faire évoluer son assistant à partir des besoins rencontrés.
07 //
Enseignements
La fiabilité commence par la qualité des connaissances
Ce projet m’a appris à accorder autant d’attention aux informations fournies au copilote qu’aux consignes données au modèle. La recherche sémantique aide à retrouver une règle de retour, mais cette règle doit être claire et à jour pour que la réponse soit utile. Structurer les connaissances et les faire valider par le client fait donc partie intégrante du travail de conception.
Le taux d’automatisation ne suffit pas à juger le résultat
J’ai retenu qu’il faut aussi regarder quelles demandes sont réellement résolues et pourquoi certaines nécessitent une reprise humaine. Une alerte au bon moment peut être la bonne issue pour un client mécontent. Les logs permettent de distinguer ces reprises utiles des erreurs à corriger et de faire évoluer le périmètre à partir des conversations réelles.
