Relation client
IA pour les centres d’appel en Tunisie : préparer un pilote utile
Un appel client peut commencer en tunisien, passer au français pour une référence de facture et revenir à la darja pour expliquer le problème. Un pilote IA doit réussir cette conversation réelle avant de promettre une automatisation à grande échelle.
Commencer par une tâche que l’équipe peut vérifier
Pour un premier pilote, nous proposons la transcription et le résumé après appel. L’agent reste responsable de la réponse au client et peut corriger le résultat avant de l’ajouter au dossier. C’est un périmètre plus facile à mesurer qu’un agent vocal autonome qui prend des décisions pendant l’appel.
Choisissez une file précise : suivi de livraison, assistance technique ou questions de facturation. Écrivez ce que le système doit produire et ce qu’il doit laisser à un humain. Le temps gagné doit inclure le temps de relecture et de correction, sinon le résultat du pilote sera trompeur.
| Usage | Résultat attendu | Contrôle humain |
|---|---|---|
| Transcription | Texte fidèle, références et montants conservés | Comparer avec l’audio |
| Résumé après appel | Motif, faits, action convenue, question restante | Valider avant enregistrement |
| Classement des demandes | Une catégorie parmi celles du service | Corriger les mauvaises orientations |
| Brouillon de réponse | Une réponse fondée sur la procédure fournie | Approuver avant envoi |
Comment assembler transcription, compréhension et voix
Dans Baarcha, Fennec transcrit la parole tunisienne, Hannibal traite le texte et Dido produit la voix. Pour un résumé après appel, les deux premières étapes suffisent : envoyer un extrait audio autorisé à la transcription, puis demander un résumé structuré à partir du texte obtenu.
Ces modèles sont des briques. L’API publique n’est pas un logiciel de centre d’appel prêt à brancher : la connexion à la téléphonie, la séparation des locuteurs, les règles du CRM et le transfert vers un agent doivent être conçus et validés dans votre intégration. Ne confondez pas une démonstration vocale avec un service téléphonique en production.
Construire un jeu d’essai tunisien représentatif
Préparez un petit lot d’appels ou d’extraits que vous êtes autorisés à utiliser. Un point de départ pratique est 30 à 50 extraits, avec une transcription de référence relue par un locuteur tunisien. Ce nombre sert à organiser un pilote, pas à démontrer une fiabilité statistique.
Gardez une partie des extraits à l’écart pendant le réglage des consignes. Évaluez ensuite cette partie sans modifier le système entre les exemples. Vous verrez ainsi s’il fonctionne au-delà des appels utilisés pour le préparer.
- Inclure la darja, le français et les changements de langue dans une même phrase.
- Varier les accents, la qualité du micro, le bruit de fond et les interruptions.
- Noter séparément les noms, numéros de dossier, dates, montants et négations.
- Ajouter des demandes ambiguës, des informations manquantes et des clients mécontents.
- Retirer ou remplacer les données personnelles qui ne sont pas nécessaires au test.
Une consigne de résumé à essayer
Cet exemple utilise une conversation fictive. La consigne demande des faits vérifiables et une liste d’incertitudes. Dans un vrai pilote, le résumé doit rester lié à la transcription et à l’extrait audio pour que l’agent puisse contrôler chaque affirmation.
Un exemple à adapter
Résume cet échange fictif pour un agent de service client en Tunisie. Utilise seulement les informations présentes. Réponds en français avec : motif, faits confirmés, action convenue, informations manquantes. Ne crée ni numéro de dossier ni promesse commerciale. Client : Bonjour, el connexion tet9assa depuis hier. J’ai redémarré le modem deux fois. Agent : Est-ce que le voyant internet est rouge ? Client : Oui, rouge. Agent : Je vais transmettre au support technique. Je n’ai pas encore de délai de résolution. Client : D’accord, merci.
Mesurer les erreurs qui coûtent du temps au service
Le taux d’erreur de transcription est utile, mais une seule négation oubliée peut changer le sens d’un appel. Comptez aussi les résumés qui inventent une action, les mauvais classements et les informations importantes omises. Chronométrez le travail avec et sans assistance, correction comprise.
Fixez vos critères de passage avant le test. Par exemple, votre équipe peut exiger qu’aucun engagement commercial absent de l’appel n’apparaisse dans un résumé. C’est une règle de validation du pilote, pas une garantie que le modèle n’en inventera jamais.
Les points à régler avant de passer en production
Définissez qui peut consulter les enregistrements, combien de temps les conserver, comment les supprimer et qui valide les conditions d’utilisation des données. Pour les appels réels, faites confirmer les règles applicables à votre activité par les responsables concernés avant de transférer des données.
Mesurez la latence sous charge, le comportement lorsqu’un modèle est indisponible et le coût complet de l’intégration. Préparez un retour au traitement humain. Les modalités de capacité dédiée, d’hébergement et de contrat se discutent avec Baarcha ; elles ne sont pas automatiquement incluses dans l’API publique.
Pour une première discussion, apportez votre cas d’usage, les langues présentes dans les appels, le volume envisagé et votre grille de validation. Cela permet de décider ce qu’un pilote peut réellement démontrer.