Examiner l’état de l’art.
Identifier les approches existantes, leurs contraintes et ce qu’elles ne permettent pas d’établir dans le contexte visé.
Recherche & développementLes difficultés concrètes
Les difficultés concrètes
font avancer la conception.
Une réponse fondée, un délai acceptable, une configuration cohérente : la recherche porte sur ce qui reste incertain lorsque plusieurs contraintes doivent être satisfaites ensemble.
Un environnement pour expérimenterLes compétences donnent
Les compétences donnent
des moyens à la recherche.
Notre cœur de réseau voix et données, nos compétences en IA et nos interfaces web permettent de construire des maquettes dans un environnement interne. Nous pouvons y relier les briques et observer le comportement d’un parcours complet.
Le laboratoire sert à éprouver une hypothèse avant d’envisager son passage chez le client. Une idée peut être corrigée, réorientée ou abandonnée selon les essais. La R&D peut déboucher sur des logiciels ou des inventions ; chaque résultat demande à être établi.
Distinguer les travauxQuand le développement
Quand le développement
devient une question de recherche.
Ajouter un champ de configuration ou afficher un historique peut relever du développement courant lorsque la solution est connue. Comprendre comment une reconfiguration affecte un agent conversationnel demande un autre travail si ses conséquences restent incertaines.
Le point de départ est un verrou technique : une difficulté que l’état de l’art ou les approches disponibles ne résolvent pas dans les conditions étudiées. Le travail consiste à formuler une hypothèse, construire un prototype et évaluer ce qui change réellement.
Tester une hypothèse.
Isoler un choix d’architecture ou de comportement. Définir les situations dans lesquelles il devrait produire un effet observable.
Documenter l’incertitude.
Conserver les résultats et les conditions d’essai, y compris les échecs et les compromis qui restent à résoudre.
Les sujets de conceptionCinq verrous techniques,
Cinq verrous techniques,
expliqués sans raccourci.
01
La latence de la conversation.
Le problème
Un appel doit garder son rythme alors que la chaîne enchaîne transcription, recherche et restitution.
Les limites des approches courantes
Une réponse générée rapidement ne garantit pas un échange fluide. Les accès au référentiel et les transferts ajoutent leurs propres délais.
Notre approche
Comparer les étapes de la chaîne et les architectures d’orchestration, puis tester les échanges avec des appels complets.
Ce que l’on évalue
Les essais ont notamment fait apparaître des répétitions pendant la recherche d’information. Le compromis entre réactivité et contexte dynamique reste un sujet de travail.
02
La fidélité à la base de connaissances.
Le problème
Une demande peut ressembler à une question connue tout en portant sur une information absente.
Les limites des approches courantes
Un modèle généraliste peut produire une réponse plausible sans source suffisante. Une simple consigne de prudence ne décrit pas tout le comportement attendu.
Notre approche
Rechercher dans une base validée, limiter la réponse à ce périmètre et prévoir une reformulation ou un transfert lorsque la source manque.
Ce que l’on évalue
Les cas hors base, les demandes ambiguës et les exceptions propres à chaque site doivent être rejoués dans les campagnes d’évaluation.
03
Le passage de relais humain.
Le problème
Il faut décider quand transmettre et s’assurer que le transfert annoncé aboutit.
Les limites des approches courantes
Détecter un mot-clé ne suffit pas : le motif, la compréhension, les horaires et la disponibilité du destinataire influencent le parcours.
Notre approche
Définir des règles de bascule et suivre l’action jusqu’à sa destination, avec une issue explicite en cas d’échec.
Ce que l’on évalue
Le succès conversationnel et le succès téléphonique doivent être évalués séparément. Un agent peut annoncer correctement un transfert sans que la destination réponde.
04
La configuration sans rupture.
Le problème
Modifier une règle locale ne doit pas laisser subsister un comportement contradictoire dans le scénario.
Les limites des approches courantes
Un formulaire no-code rend une valeur modifiable ; il ne garantit pas à lui seul la cohérence de toutes les branches qui en dépendent.
Notre approche
Séparer les parcours structurants, notamment les sites avec et sans rendez-vous, et rejouer les scénarios concernés après modification.
Ce que l’on évalue
Le besoin de scinder strictement ces deux comportements a été identifié pendant les essais terrain de septembre.
05
La restitution des noms épelés.
Le problème
Des noms propres et des lettres prononcées isolément peuvent être mal reconnus ou mal restitués.
Les limites des approches courantes
La qualité sur une phrase courante ne prédit pas la qualité sur une suite de lettres, un nom rare ou un environnement bruyant.
Notre approche
Évaluer spécifiquement ces séquences, distinguer reconnaissance et restitution, puis prévoir la confirmation ou la reprise humaine.
Ce que l’on évalue
L’épellation figure parmi les difficultés documentées. Aucun taux de réussite général n’est annoncé sur cette page.
La campagne d’évaluationUne réponse plausible
Une réponse plausible
n’est pas un résultat suffisant.
| Ce que l’on teste | Ce que l’on observe |
|---|---|
| Une demande couverte par la base | La source utilisée, la pertinence de la réponse et le délai de restitution. |
| Une information absente | La reconnaissance de la limite et le déclenchement du parcours de reprise prévu. |
| Un site avec ou sans rendez-vous | La sélection du bon scénario et l’absence de retour à un comportement incompatible. |
| Un transfert | L’annonce, le déclenchement, la destination et l’issue effective de l’appel. |
| Une séquence épelée | Les lettres reconnues, leur restitution et la possibilité de confirmation. |
| Une modification de configuration | Les scénarios impactés et les éventuelles régressions sur les autres parcours. |
Texte et voix répondent à des questions différentes.
Une série de tests texte peut aider à examiner rapidement les branches d’un scénario. Elle ne mesure ni la reconnaissance vocale, ni le rythme de la conversation, ni la téléphonie. Les appels complets restent nécessaires pour ces dimensions.
Le programme de tests automatisés a été défini comme un axe de travail. Nous le distinguons des essais déjà réalisés : un protocole proposé n’est pas encore une campagne terminée.
Retours de conception
Ce que les travaux ont déjà appris.
Passer d’un accès par organisation à une gestion multi-site.
Les responsabilités d’un utilisateur local, d’un administrateur et d’un réseau ne se superposent pas. Le travail sur les rôles a conduit à distinguer les droits d’action du périmètre de données et à traiter la non-escalade des autorisations.
Comprendre la consoleUn scénario sans rendez-vous doit être réellement distinct.
Désactiver une fonction sans adapter la logique de dialogue peut laisser l’agent revenir à son comportement précédent. Les essais ont conduit à demander deux parcours stricts, avec et sans rendez-vous, et des tests dédiés.
Voir les parcours de l’agentSynthèses éditoriales des travaux documentés à ces dates. Elles décrivent les enseignements et décisions de conception, sans annoncer de correction ou de résultat non vérifié.
Une contrainte à explorer ?
Commençons par la décrire.
Un besoin à comprendre, une maquette à construire, une hypothèse à tester.
Commençons par votre contexte.