Sushil Kumar, PDG de Cyara – Série d’interviews

Sushil Kumar, PDG de Cyara est un cadre expérimenté du logiciel d’entreprise et un entrepreneur avec plus de 25 ans de direction dans l’intelligence artificielle, le DevOps, l’infrastructure cloud, la stratégie produit et les tests logiciels. Il a rejoint Cyara en tant que PDG en décembre 2025, après avoir été co‑fondateur et PDG de RelicX.ai, où il a construit une plateforme d’automatisation de tests basée sur l’intention et alimentée par l’IA générative, qui a été acquise par Harness. Il a ensuite dirigé l’intégration de la technologie de RelicX dans Harness et a contribué à façonner sa stratégie d’automatisation des tests IA. Au début de sa carrière, Kumar a occupé le poste de directeur général du DevOps chez Broadcom, celui de vice‑président senior des produits chez CA Technologies, et a passé plus de 16 ans chez Oracle, où il a occupé des postes de direction produit senior et a aidé à développer d’importantes activités de logiciels d’entreprise. Dans l’ensemble de ces fonctions, il s’est concentré sur la construction et l’extension de plateformes d’IA, de cloud, de DevOps et d’automatisation pour les grandes entreprises. Sa nomination chez Cyara vise à élargir les capacités d’assurance de l’expérience client, alimentées par l’IA, et la portée mondiale de l’entreprise.

Cyara est une société d’assurance de l’expérience client qui aide les entreprises à tester, surveiller et valider les interactions client à travers les canaux voix, numériques, de messagerie et d’IA conversationnelle. Sa Cyara Agentic Platform est conçue pour répondre aux défis croissants engendrés par les expériences client pilotées par l’IA, notamment le test d’agents IA non déterministes, la détection d’hallucinations et de dérives comportementales, la validation de la conformité, la surveillance des systèmes de production et l’évaluation des parcours client de bout en bout. La plateforme combine le test d’agents IA, la surveillance de la production, l’assurance voix et télécom, le test des canaux numériques et l’observabilité CX, en supportant plus de 350 millions de parcours client chaque année sur une présence mondiale couvrant plus de 140 pays. À mesure que les entreprises déploient des agents IA de plus en plus autonomes dans les flux de travail orientés client, Cyara positionne sa technologie comme une couche d’assurance permettant d’évaluer si ces systèmes se comportent de manière fiable, sûre et cohérente avant et après le déploiement.

Vous avez passé la majeure partie de votre carrière à construire et à faire évoluer des logiciels d’entreprise, d’Oracle et CA/Broadcom à la création de Relicx et maintenant à la direction de Cyara. En quoi cette expérience a‑t‑elle façonné votre point de vue selon lequel les agents IA devraient être gérés davantage comme des membres d’une main‑d’œuvre que comme des logiciels traditionnels ?

J’ai passé la majeure partie de ma carrière à construire et à faire évoluer des logiciels d’entreprise, et la discipline que nous y avons instaurée était une discipline axée sur les systèmes déterministes. Vous savez ce que le logiciel est censé faire. Vous le validez par rapport à cette attente. Lorsqu’il se bloque, il vous indique : une erreur, une transaction échouée, une alerte.

Les agents IA ne fonctionnent pas ainsi. Ils sont non déterministes, de sorte que la même entrée peut emprunter un chemin différent. Plus important encore, ils peuvent agir au nom de l’entreprise. Ils prennent des engagements : remboursements, politiques, promesses. Et lorsqu’un de ces engagements est erroné, rien ne se casse. Une réponse erronée ressemble exactement à une réponse correcte. La transaction aboutit, le tableau de bord reste vert, et le client repart avec quelque chose que l’entreprise n’a jamais accepté.

Lorsque le logiciel peut prendre des décisions et des engagements, et peut se tromper sans vous le signaler, il nécessite un modèle opérationnel différent.

C’est là que la comparaison avec la main‑d’œuvre prend tout son sens. Vous ne gérez pas un employé en scriptant chaque décision qu’il prendra. Vous lui attribuez un rôle, vous établissez l’autorité qui l’accompagne, et vous élargissez cette autorité au fur et à mesure qu’il la mérite. Un agent se comporte de la même manière sous la même structure.

Mon interprétation est que l’autonomie n’est pas une décision de déploiement. C’est une série de promotions. Un agent en obtient chacune en démontrant qu’il peut accomplir la tâche, rester dans les limites de son autorité et reconnaître quand il a besoin d’aide.

À quoi ressemble concrètement un modèle opérationnel « type RH » pour les agents IA au sein d’une entreprise, et quels éléments les sociétés devraient‑elles mettre en place en premier ?

Commencez par le poste. Chaque agent devrait disposer d’une description de poste approximative avant d’entrer en production. Quels sont ses objectifs, quelles informations sont autoritaires pour lui, quelles données client peut‑il utiliser, quelles décisions peut‑il prendre de façon autonome, et où s’arrête sa responsabilité. Si une entreprise ne peut pas consigner cela dans un paragraphe, l’agent n’est pas prêt à occuper un rôle. Il est prêt pour une démonstration.

Quatre éléments découlent de ce rôle, et l’ordre est important. Des preuves avant le lancement, c’est‑à‑dire démontrer que l’agent peut accomplir le poste dans des conditions qui ressemblent au monde réel plutôt que dans un test contrôlé. Une supervision pendant son fonctionnement, afin de savoir ce que l’agent a réellement fait et pas seulement si le système a répondu. Des seuils de promotion, afin d’accorder davantage d’autorité lorsqu’il existe des preuves le justifiant et non avant. Et un propriétaire au sein de l’entreprise, pas dans l’ingénierie, qui est responsable de ce que cet agent est autorisé à faire.

Si l’ordre est erroné, le reste ne tient pas. Si la responsabilité est vague, il est impossible de prouver une bonne performance, tout comme l’échec. Le rôle vient en premier, suivi des preuves.

Si un agent IA se voit attribuer un rôle spécifique, comment les organisations devraient‑elles définir ses responsabilités, ses autorisations et ses limites avant de le laisser interagir avec les clients ou les systèmes critiques ?

Le rôle indique à quoi sert l’agent. Les autorisations indiquent ce qu’il peut atteindre. Ce sont deux conversations différentes, et les entreprises ont tendance à ne gérer que la première.

Soyez explicite sur trois points. Quels systèmes et quelles données l’agent peut toucher, et dans quelle direction, car lire un dossier client et le modifier ne sont pas la même autorisation. Ce à quoi il peut s’engager de façon autonome, là où se trouvent l’argent et la responsabilité : un remboursement, un crédit, une exception à la politique. Et ce qui force un transfert, tant les cas que vous pouvez nommer à l’avance que le signal indiquant que l’agent a dépassé sa compétence.

Ce ne sont pas des décisions à laisser à l’équipe technologique. Elles déterminent le risque que l’entreprise prend. Les personnes responsables de l’expérience client et de l’exposition à la conformité doivent avoir leur mot à dire sur la délimitation de ces frontières, et elles sont généralement les dernières sollicitées.

Ensuite, vous devez prouver que l’agent reste à l’intérieur de ces limites. L’objectif n’est pas d’éliminer chaque erreur possible. Il y aura des erreurs. La question est de savoir si l’agent comprend ses limites, sait quand s’arrêter et peut accomplir la tâche qui lui a été confiée sans créer de conséquences ailleurs dans le parcours client.

Vous soutenez que la plus grande autonomie doit être méritée plutôt qu’accordée dès le départ. Que doit démontrer un agent IA avant qu’une entreprise n’élargisse le champ des actions qu’il peut entreprendre de façon indépendante ?

Il est désormais facile de créer un agent IA. La partie difficile est de prouver qu’il mérite cette autonomie.

Avant d’élargir ce qu’un agent peut faire de façon autonome, une entreprise a besoin de preuves qu’il exécute son travail assigné de manière constante et qu’il reste dans ses limites. Cela signifie comment il gère les situations que vous attendez, ainsi que celles que vous n’aviez pas anticipées. Un agent peut sembler performant dans des conditions contrôlées et se comporter différemment lorsque le contexte ou les systèmes environnants changent.

Un client peut commencer par une simple question de facturation et devenir frustré après un paiement échoué. L’agent doit reconnaître ce changement en temps réel et modifier sa trajectoire, plutôt que de poursuivre le chemin sur lequel il a été validé.

Trois éléments doivent être vrais avant que l’autorité ne s’étende. L’agent accomplit son travail dans des conditions réelles, pas seulement dans des environnements propres. Il connaît les limites de sa propre compétence et s’arrête là. Et quelqu’un peut fournir les preuves de ces deux points à la demande.

Le niveau de preuve doit correspondre au niveau d’autonomie. Décisions mineures, preuves légères. L’accès à un système de paiement, ou la capacité d’engager l’entreprise à une exception de politique, doit être soumis à un seuil nettement plus élevé.

Comment les entreprises devraient-elles évaluer en continu la performance des agents IA une fois déployés, surtout lorsque la qualité de leurs décisions ne peut pas être capturée uniquement par les métriques de test logiciel traditionnelles ?

C’est là que la pensée logicielle traditionnelle se fissure. Avec un logiciel déterministe, vous testez si quelque chose a réussi ou échoué. Avec un agent IA, vous pouvez obtenir une réponse réussie du système et avoir tout de même une interaction client ratée.

Vous évaluez donc le résultat, pas la réponse. L’agent a-t-il compris ce que le client cherchait à accomplir ? A-t-il utilisé les bonnes informations ? A-t-il mené le parcours à son terme ? Est-il resté dans ses limites et a-t-il escaladé quand il le fallait ?

Les évaluations de base, qui notent les réponses par rapport à un ensemble de référence, constituent le minimum. Chaque entreprise en disposera. Les dimensions qui décident si un client continue de vous faire confiance sont celles qui se cachent en dessous : conformité, biais, mauvaise utilisation, et la façon dont l’agent se comporte avec de vrais appelants, leurs accents, le bruit de fond, le combiné bon marché, l’interruption à mi‑phrase. En voix, cela compte davantage que les gens ne l’imaginent, car chaque score repose sur une transcription. Si la couche de parole mal entend la question, l’agent répond à une question que personne n’a posée.

L’arithmétique mérite qu’on s’y attarde. Un score de 99 % à l’évaluation semble excellent. Sur un million de conversations par an, cela représente dix mille échecs.

Deux principes tiennent la route. La validation doit être indépendante de l’agent et des plateformes de modèle. Nous ne construisons pas les agents nous‑mêmes, ce qui explique pourquoi je peux affirmer clairement qu’aucun fournisseur ne devrait juger de sa propre IA. La norme est constituée des politiques internes de l’entreprise, de ses engagements envers les clients et de ses obligations réglementaires, et non du tableau de bord d’un fournisseur.

Et chaque défaillance en production doit devenir un verrou. Pas un ticket, pas un élément de backlog. Un test que l’agent doit réussir avant que la prochaine version ne soit déployée. Si un problème survient en production et ne se transforme pas en un test que l’agent doit passer, vous payez deux fois pour découvrir le même problème.

La confiance et la gouvernance sont de plus en plus citées comme des obstacles majeurs à l’extension de l’IA agentique. Pensez‑vous que la technologie progresse plus rapidement que la capacité des entreprises à la superviser, et quels risques cela engendre‑t‑il ?

Je pense que c’est exactement ce qui se passe, et que l’écart est structurel plutôt qu’une défaillance d’effort. Une idée peut devenir un agent orienté client en quelques semaines. La discipline opérationnelle autour de cet agent, la propriété, les preuves, la supervision, prennent beaucoup plus de temps, car elles impliquent des personnes et la responsabilité, et pas seulement le logiciel.

Le risque est que l’écart reste invisible tout en s’élargissant. Un agent peut donner à un client une réponse manifestement erronée sans aucune erreur, aucune transaction échouée et aucune alerte. Tous les tableaux de bord semblent verts. Les opérations traditionnelles dépendent des systèmes qui vous indiquent quand ils sont en difficulté, et les agents ne le font pas de manière fiable.

Je ne pense pas que la solution soit de ralentir. Les entreprises qui réussiront ici vont avancer rapidement. La solution consiste à construire les preuves et la supervision qui vous permettent d’avancer rapidement en toute confiance. Plus un agent reçoit d’autonomie, plus vous avez besoin de preuves qu’il peut assumer la responsabilité.

Lorsqu’un agent autonome prend une mauvaise décision, qui doit finalement être tenu responsable : le développeur, l’unité métier qui le déploie, le fournisseur du modèle ou le dirigeant qui a approuvé son utilisation ?

En fin de compte, l’entreprise qui déploie l’agent possède le résultat. Plusieurs parties sont impliquées dans la construction et l’exploitation du système, mais le client n’a aucune relation avec le fournisseur du modèle. Le client a une relation avec l’entreprise dont le nom figure sur l’interaction.

Cela ne signifie pas que la responsabilité repose sur une seule personne. Elle traverse la chaîne de décision. Le développeur est responsable de la façon dont le système a été construit. L’entreprise décide de ce que l’agent est autorisé à faire. Le fournisseur est responsable de la technologie qu’il fournit. La direction est responsable de s’assurer que l’entreprise dispose des contrôles et de la supervision nécessaires pour gérer le risque.

L’erreur consiste à penser que, parce que le modèle a pris la décision, le modèle en est propriétaire. Ce n’est pas le cas. Si un agent prend un engagement auprès d’un client en votre nom, cet engagement appartient à la marque. Les clients le comprennent instinctivement, tout comme les régulateurs.

Les agents IA peuvent se comporter de manière imprévisible lorsqu’ils rencontrent des situations qui n’ont pas été anticipées lors des tests. Comment les entreprises doivent‑elles tester ces cas limites avant que les agents n’aient accès aux clients, aux systèmes financiers ou aux données sensibles ?

Il faut supposer que l’agent rencontrera finalement quelque chose pour lequel il n’a pas été conçu. La question est de savoir ce qui se passe lorsqu’il le fait.

Validez donc au‑delà du chemin attendu. Soumettez à l’agent des requêtes ambiguës. Donnez‑lui des informations contradictoires. Fournissez‑lui un contexte incomplet. Placez‑le dans des situations où la bonne réponse consiste à s’arrêter et à escalader plutôt qu’à poursuivre. Ajoutez les conditions du monde réel, ce qui, pour la voix, signifie des accents, du bruit, de mauvaises connexions et des appelants qui changent de sujet à mi‑parcours. L’objectif n’est pas de confirmer que l’agent fonctionne, mais de découvrir comment il se comporte lorsque les conditions ne sont pas idéales.

Le point le plus important est que vous devez valider l’ensemble du parcours, pas l’agent isolément. Le modèle n’est généralement pas le problème. Lorsqu’un problème survient, ma première question porte sur le contexte reçu par le modèle. Il peut s’agir d’un article de connaissance obsolète, de deux systèmes aux politiques contradictoires, ou d’un transfert qui a perdu ce que le client avait déjà expliqué. Chaque composant peut réussir son propre test et le parcours client peut néanmoins échouer aux jonctions entre eux.

Cette couche entre les systèmes est celle que nous avons passée des années à instrumenter, dans plus de 450 entreprises et plus de 350 millions de parcours client par an. Qu’ils soient agentiques ou non, ils se cassent de la même façon. Nous constatons également des agents construits sur plus de 55 technologies de fournisseurs différents, ainsi que sur toutes les principales plateformes de centre de contact, ce qui nous montre que le schéma tient quel que soit le modèle sous‑jacent.

Avant qu’un agent n’obtienne l’accès à un élément crucial, l’entreprise doit disposer de preuves de son comportement lorsque les choses se passent bien et lorsqu’elles ne le sont pas.

Comment voyez‑vous l’évolution des tests IA à mesure que les entreprises passent de logiciels déterministes à des systèmes qui raisonnent, planifient, communiquent et agissent à travers plusieurs applications ?

Les tests doivent passer de la question de savoir si un système a produit la réponse attendue à celle de savoir s’il a atteint le bon résultat.

C’est un changement important. Un agent peut emprunter plusieurs chemins différents pour résoudre le même problème client, et ces chemins peuvent évoluer au fil du temps à mesure que les modèles et les connaissances qui les sous‑tendent changent. Vous ne pouvez pas rédiger un script pour chaque interaction possible. Vous devez évaluer si l’agent a compris l’intention, a pris des décisions judicieuses tout au long du processus et est resté dans les limites qui lui ont été imposées.

Je veux être prudent sur un point, car l’industrie commence à se tromper de manière coûteuse. Les tests pré‑lancement sont aujourd’hui plus importants, pas moins. Ils déterminent si un agent est prêt. L’argument selon lequel on peut les ignorer et observer la production à la place est en réalité un argument pour découvrir les problèmes devant les clients.

Ce qui change, c’est que les tests pré‑lancement ne constituent plus la fin du processus. La production révèle des conditions qu’un environnement contrôlé ne peut reproduire complètement, et ce que la production révèle devient un test que l’agent doit réussir avant la prochaine version. Preuve avant le lancement, vigilance en production, chaque étape alimentant l’autre. L’agent en cours d’exécution au sixième mois doit être nettement meilleur que celui qui a été lancé.

En regardant vers l’avenir, qu’est‑ce qui distinguera les organisations qui construisent avec succès des forces de travail IA fiables de celles qui restent bloquées à mener de petits pilotes IA agentiques ?

Les organisations qui obtiennent un véritable retour des agents sont celles qui ont construit un modèle opérationnel basé sur des preuves. Celles qui stagnent ne sont généralement pas bloquées par la technologie. Elles sont bloquées parce que personne ne peut produire ce que le niveau suivant d’approbation exige. Le service juridique pose une question raisonnable, ou le comité des risques le fait, et il n’y a pas de réponse, donc le projet pilote reste un projet pilote. La technologie peut être prête et l’organisation ne peut toujours pas justifier de lui accorder davantage d’autorité.

C’est la différence entre un projet pilote et une main‑d’œuvre opérationnelle. Dans un pilote, quelqu’un surveille constamment. Dans un modèle opérationnel, chaque agent a un rôle que l’on peut résumer en une phrase. Son autorité est limitée et consignée par écrit. Sa performance est évaluée par autre chose que l’équipe qui l’a créé. Les échecs de production deviennent des portes de libération. Plus d’autonomie suit la preuve.

La deuxième différence est la propriété. Dans les entreprises qui se développent, l’agent appartient à la fonction métier qu’il dessert, avec un propriétaire nommé qui rend compte de ce qu’il fait. Lorsqu’il reste un projet d’IA détenu par une équipe d’IA, il reste limité, car aucun dirigeant d’entreprise n’assumera le risque d’une chose qu’il ne contrôle pas.

Rien de tout cela n’est exotique. C’est proche de la façon dont une entreprise gère déjà les personnes en qui elle a confiance avec de réelles responsabilités.

Un projet pilote peut fonctionner sur la conviction d’une organisation. L’échelle nécessite des preuves.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Cyara.