Randall Newman, CPTO et co-fondateur de Satisfi Labs – Série d’interviews

Randall Newman, CPTO et co‑fondateur de Satisfi Labs, est un leader technologique et produit doté d’une vaste expérience dans la création de plateformes d’IA, de technologies financières et de systèmes haute performance. Depuis la co‑fondation de Satisfi Labs, Newman a joué un rôle central dans l’imagination, la conception et le déploiement de la technologie d’IA conversationnelle de l’entreprise, tout en supervisant le développement produit, l’architecture, les équipes d’ingénierie et les intégrations stratégiques. Avant Satisfi Labs, il a été responsable produit chez Satisfi Inc. et a co‑fondé la société de marketing mobile Right On Mobile. Au début de sa carrière, Newman a passé plus de 17 ans chez CIBC World Markets, où il a occupé des postes de direction senior couvrant le risque stratégique, le trading à haute fréquence et l’arbitrage d’actions, combinant une expertise en trading quantitatif avec un développement technologique pratique.

Satisfi Labs est une société d’IA spécialisée dans le déploiement d’agents IA dédiés aux sports, au divertissement, au tourisme, aux attractions et à d’autres entreprises d’expériences en direct. Fondée en 2016, l’entreprise a évolué de l’IA conversationnelle et de son Answer Engine vers une plateforme agentique conçue pour aider les organisations à automatiser le support client, à augmenter les conversions de billets et de commerce, et à extraire des insights des conversations avec les clients. Ses agents IA peuvent fonctionner dans plus de 50 langues et se connecter aux systèmes de billetterie, CRM, gestion de contenu et autres systèmes d’entreprise pour effectuer des actions telles que la vente de billets, l’escalade de conversations vers le personnel humain, la collecte d’informations client et la délivrance de réponses personnalisées. Satisfi Labs affirme que sa technologie est désormais utilisée par plus de 775 marques, avec des intégrations et des partenariats incluant des sociétés telles que Ticketmaster, Simpleview, MappedIn, Ventrata et Vozzi.

Vous avez passé près de deux décennies sur les marchés financiers, notamment en construisant des systèmes de trading à faible latence et en dirigeant des stratégies de trading à haute fréquence chez CIBC, avant de vous lancer dans l’entrepreneuriat technologique et finalement de co‑fonder Satisfi Labs. Quelles leçons tirées de systèmes où la vitesse, la fiabilité et la gestion du risque étaient essentielles ont le plus influencé votre manière de concevoir aujourd’hui des agents IA de niveau production ?

Le trading m’a appris qu’une bonne idée et une bonne entreprise sont deux choses différentes. Vous pouvez identifier correctement une opportunité et tout de même perdre de l’argent parce que votre exécution est lente, vos coûts trop élevés, ou vos hypothèses de risque erronées. L’IA est la même. La capacité du modèle n’est qu’un paramètre. L’entreprise dépend de votre capacité à transformer cette capacité en un résultat reproductible à un coût et un risque acceptables.

Gérer un portefeuille d’arbitrage d’indices enseigne également à aller au‑delà des décisions individuelles. Une petite erreur répétée sur un portefeuille devient une exposition très importante. Avec l’IA, vous pouvez avoir des milliers d’agents prenant des décisions individuellement raisonnables qui, collectivement, créent un problème. Ils dépendent tous des mêmes données erronées, ou ils réessaient tous le même service défaillant. Vous devez gérer le système, pas seulement la réponse individuelle.

Et la vitesse ne compte que lorsqu’elle améliore le résultat. En trading, il y avait des moments où les microsecondes étaient cruciales. En IA, je préfère prendre une seconde supplémentaire pour confirmer une transaction plutôt que de livrer immédiatement un résultat erroné. La discipline consiste à savoir où la vitesse crée de la valeur et où elle ne fait qu’accélérer une erreur.

La dernière leçon est celle qui a lancé toute l’entreprise. L’avantage provient de repérer une sous‑évaluation avant tout le monde. Je pense que la sous‑évaluation actuelle est que la plupart des entreprises considèrent les agents IA comme un moyen de réduire les coûts de support. Chez Satisfi Labs, nous les voyons comme un canal de revenu. Dans nos sites sportifs, environ 40 % des conversations des agents portent sur les billets. Ces fans ne viennent pas se plaindre. Ils arrivent avec de l’argent en poche, demandant où s’asseoir. Trouvez ce que le marché a mal évalué et saisissez‑le. Le même instinct que dans le commerce d’arbitrage.

Satisfi Labs a été fondée en 2017, bien avant l’actuel boom de l’IA générative, et a évolué du traitement contextuel du langage naturel et de l’IA conversationnelle vers une plateforme agentique. Quels ont été les plus grands changements architecturaux nécessaires pour passer de systèmes conçus principalement à répondre aux questions à des agents capables d’agir au nom des utilisateurs ?

Nous avons passé une décennie à créer des milliers d’agents IA pour plus de 800 clients d’entreprise, dont des équipes MLB/NFL, des sites de divertissement et des organisations touristiques. Le changement le plus important est que vous accordez au système une autorité, pas seulement de l’information.

Si un assistant vous indique quels billets sont disponibles, il fournit une réponse. S’il échange vos billets, il modifie l’inventaire, les dossiers clients et potentiellement l’argent. Vous devez maintenant savoir qui a autorisé l’action, ce qui s’est réellement passé, et comment récupérer si le processus s’arrête à mi‑parcours.

Nous séparons donc le jugement du modèle de l’autorité d’exécution. Le modèle peut interpréter une demande et proposer l’étape suivante. Les systèmes sous‑jacent appliquent les permissions, les règles métier et les limites de transaction. Une explication persuasive du modèle ne peut pas outrepasser ces contrôles.

Il faut également une distinction stricte entre “l’agent a déclaré avoir terminé la tâche” et “le système d’entreprise a confirmé l’achèvement”. Ce ne sont pas la même chose. Si une demande d’achat expire, il vaut mieux vérifier si l’achat a bien eu lieu avant de réessayer.

Et sur le plan stratégique, les meilleurs modèles ne devraient pas vous obliger à reconstruire vos contrôles métier. Je veux profiter de chaque amélioration du raisonnement sans renégocier ce que le système est autorisé à faire à chaque fois qu’un nouveau modèle est déployé.

Le terme « agentic AI » est désormais appliqué à un large éventail de produits. Du point de vue de l’ingénierie, où tracez‑vous la frontière entre un chatbot avancé, un copilote IA et un véritable agent IA autonome ?

Je poserais une seule question : quelle responsabilité la personne a‑t‑elle réellement déléguée ?

Un chatbot fournit des informations. Un copilote vous aide à accomplir votre travail, mais vous continuez à diriger et à approuver les étapes importantes. Un agent autonome a la permission de prendre certaines de ces décisions lui‑même tout en poursuivant un objectif.

L’interface ne vous indique pas lequel vous examinez. Un produit conversationnel peut disposer d’une réelle autonomie en arrière‑plan. Un élément commercialisé comme un agent peut néanmoins nécessiter qu’une personne approuve chaque action utile.

Pour une entreprise, l’autonomie doit être un accord précis : ce système peut exécuter ces actions, pour ces utilisateurs, dans ces limites, et doit s’arrêter dans ces conditions. C’est quelque chose que vous pouvez réellement tester et gouverner.

Je ne viserais pas non plus l’autonomie maximale comme objectif. Parfois, le meilleur produit pose une question bien synchronisée et gère le reste. Supprimer cette question rend la démonstration plus impressionnante mais l’entreprise moins sûre. L’objectif est d’éliminer le travail humain inutile, pas le jugement humain indispensable.

Satisfi Labs a récemment lancé Satisfi Forward, une pratique d’ingénierie déployée en avant. Quel écart constatiez‑vous entre la construction d’une plateforme IA performante et le fait de faire fonctionner les agents de manière fiable dans l’environnement réel d’un client, ce qui vous a conduit à créer ce modèle ?

Le dernier kilomètre devenait le goulot d’étranglement. Une plateforme peut standardiser beaucoup de choses, mais elle ne peut pas supposer que l’activité de chaque client fonctionne de la même façon. Leur système de billetterie présente certaines limites. Leur processus d’approbation passe par trois services. Leur définition d’un prospect qualifié diffère de celle du client suivant. Ces détails déterminent si le déploiement est réellement utile.

Vous pouvez acheter une plateforme prête à l’emploi et assembler une démonstration qui impressionne les gens. La commercialiser comme une expérience robuste pour de vrais utilisateurs, c’est différent. C’est là qu’interviennent les ingénieurs déployés en avant. Le travail de notre équipe chez Satisfi Forward est de comprendre le résultat souhaité, d’identifier ce qui le bloque, puis de construire les flux de travail et les intégrations sur la plateforme pour le réaliser.

Mais nous établissons des limites claires pour chaque engagement. Avant de construire, nous convenons de ce que signifie le succès, de qui possède le processus métier, de ce qui dépend du client et de qui le maintient après le lancement. Sinon, un projet du dernier kilomètre devient une obligation illimitée. Et l’engagement n’est pas terminé lorsque le code est livré. Il l’est lorsque le flux de travail fonctionne dans l’opération du client et que quelqu’un est responsable de le maintenir en état.

Le code est également devenu beaucoup moins cher à produire, ce qui rend ce modèle bien plus pratique qu’auparavant. Mais je ne considère pas Satisfi Forward comme un bras de services greffé à un produit SaaS. Chaque engagement nous apprend quel devrait être le prochain produit. Lorsque trois clients demandent le même flux de travail, ce n’est pas une charge de support. C’est la feuille de route qui s’écrit d’elle‑même, avec des clients payants associés. L’ancien modèle SaaS devinait les fonctionnalités et attendait les preuves. Ainsi, nous obtenons d’abord les preuves, et les revenus pendant que nous les recueillons. Je pense que c’est ainsi que les entreprises de produits se construisent à l’ère de l’IA.

Vos agents peuvent se connecter aux systèmes de billetterie, aux plateformes de gestion de la relation client, aux systèmes de gestion de contenu et à d’autres sources d’informations en temps réel. À mesure que les agents acquièrent la capacité de réaliser des transactions et de déclencher des actions, comment équilibrez‑vous l’accès aux données en temps réel et la faible latence avec la contextualisation, la sécurité et les garde‑fous contre les actions incorrectes ?

Tout d’abord, je ne laisserais jamais la rapidité compenser une faille de sécurité. Certaines exigences sont des contraintes. Vous optimisez en respectant celles‑ci.

Ensuite, vous distinguez les types de travail. Répondre à une question de stationnement et finaliser l’achat d’un billet n’exigent pas la même fraîcheur des données ni les mêmes contrôles. Vous pouvez mettre en cache les informations stables. Lorsque de l’argent change de mains, vous avez besoin du système de transaction autoritaire pour confirmer le prix, la disponibilité et la finalisation.

Les cas dangereux sont ceux où le système ne sait pas ce qui s’est passé. Un back‑end accepte un achat, mais la réponse n’arrive jamais. Si l’agent suppose un échec et réessaye, vous avez deux achats. Ce n’est pas un problème de langage. C’est un problème de récupération de transaction.

Et vous mesurez l’expérience dans les conditions qui comptent réellement. La latence moyenne d’un mardi calme ne vous apprend presque rien. Si un événement est annulé à cause de la pluie, vous avez soudainement des milliers de personnes qui demandent ce qu’il advient de leurs billets, toutes en même temps. Si vous ne planifiez qu’en fonction du trafic moyen par minute, vous manquerez la capacité nécessaire lors de ce pic. Je l’ai appris directement des systèmes de trading.

Il y a aussi une décision de coût ici. Toutes les demandes ne nécessitent pas le modèle le plus cher ni une chaîne d’agents. Utilisez le chemin le plus simple qui satisfait l’exigence, et consacrez le temps ou le calcul supplémentaire là où cela améliore réellement la décision. L’utilisateur doit obtenir un résultat honnête, y compris une déclaration honnête indiquant qu’un élément n’a pas pu être confirmé.

Satisfi Labs décrit un modèle dans lequel des agents spécialisés peuvent fonctionner ensemble comme une main‑d’œuvre IA. Quels sont les problèmes techniques les plus difficiles liés à l’orchestration de multiples agents spécialisés, en particulier concernant le routage, le contexte partagé, les décisions conflictuelles et la détermination de l’agent qui doit agir ?

La partie la plus difficile est de maintenir la responsabilité lorsque vous répartissez le travail.

Commencez par vous demander si vous avez réellement besoin d’un autre agent. Parfois, vous avez besoin d’un spécialiste. Parfois, vous avez simplement besoin d’un appel d’outil ou d’un flux de travail simple. Chaque agent que vous ajoutez représente une interprétation supplémentaire de la demande, une dépendance de plus, un point d’erreur supplémentaire. Et le nombre d’agents fonctionnant en arrière‑plan doit rester invisible pour l’utilisateur.

Lorsque plusieurs agents sont justifiés, je souhaite qu’un seul agent possède l’interaction. Les spécialistes peuvent fournir des informations ou effectuer un travail limité. Un agent de billetterie gère l’inventaire et les échanges, un agent de service client gère les politiques. Mais quelqu’un doit concilier les résultats et décider si l’utilisateur a réellement obtenu ce qu’il recherchait.

Le routage est difficile parce que les gens ne posent pas leurs questions dans des catégories bien définies. Une demande peut concerner trois agents. Le système doit décider : un seul peut‑il la gérer, plusieurs doivent‑ils être exécutés séquentiellement, ou faut‑il poser une question supplémentaire à l’utilisateur avant d’agir ?

Il en va de même pour le contexte. Vous n’envoyez pas tout à chaque agent. Cela ajoute de la latence, crée du bruit et peut divulguer des informations dont un agent n’a pas besoin. De plus, l’hypothèse d’un agent ne doit pas devenir un fait simplement parce qu’elle a été transmise à l’agent suivant.

Si deux agents sont en désaccord, je ne veux pas qu’ils se disputent jusqu’à ce que l’un semble plus convaincant. Il doit exister un modèle d’autorité clair. Le système de billetterie établit la disponibilité. L’entreprise définit la politique d’échange. Les données en temps réel l’emportent sur les données en cache, les règles métier l’emportent sur le jugement du modèle, et si le problème persiste, vous interrogez l’utilisateur ou faites intervenir une personne. La difficulté ne réside pas dans le fait de faire communiquer les agents entre eux, mais dans la capacité à reconstituer exactement quel agent a fait quoi et où la responsabilité était attribuée.

Satisfi Labs s’est de plus en plus concentré sur l’évaluation des agents par rapport aux objectifs et aux résultats commerciaux plutôt que sur des indicateurs tels que le volume de conversations. Que devraient réellement mesurer les entreprises pour déterminer si un agent IA fonctionne bien, et comment évaluer la fiabilité avant d’accorder à un agent une plus grande autonomie ?

Commencez par le résultat commercial, puis demandez quelle part de ce résultat l’agent a réellement générée.

Si quelqu’un achète des billets après avoir parlé à un agent, cela ne signifie pas automatiquement que l’agent a créé la vente. Il se peut qu’il ait acheté de toute façon. Dans la mesure du possible, vous devez privilégier des comparaisons contrôlées ou une référence crédible, et non simplement attribuer le crédit à la dernière interaction. Pour un client de billetterie, cela signifie mesurer si le fan a effectivement obtenu des places, et non si l’agent a répondu poliment. Pour un lieu qui cherche à réduire les files d’attente à la billetterie, cela signifie mesurer ce que l’agent a résolu avant que quiconque n’ait à faire la queue.

Examinez ensuite l’économie d’un résultat réussi : coûts du modèle, infrastructure, révision humaine, escalades et coût de la correction des erreurs. Un agent qui semble bon marché tant que vous ne comptez pas les personnes qui réparent son travail n’est pas économique.

La fiabilité nécessite son propre tableau de bord. Achèvement, exactitude, actions non autorisées, récupération après des pannes, qualité des escalades. Vous ne pouvez pas intégrer un incident grave de confidentialité dans un bon taux de conversion.

Pour plus d’autonomie, j’exigerais des preuves concernant la classe d’action spécifique déléguée. Testez‑la, observez‑la sous supervision, élargissez‑la dans des limites, et conservez un moyen de l’arrêter. Un bon score d’exactitude global ne prouve pas que le système est prêt pour chaque transaction. Et soyez prudent avec les incitations. Parfois, faire intervenir une personne est la bonne solution. Si vous ne récompensez l’agent que pour éviter les transferts, ne soyez pas surpris qu’il conserve des problèmes qu’il aurait dû escalader.

Vous avez récemment soutenu que l’IA vocale doit être conçue autour d’objectifs mesurables plutôt que traitée comme une interface supplémentaire pour un chatbot existant. Quels progrès techniques restent nécessaires avant que les agents vocaux puissent devenir une interface principale pour des interactions complexes et en temps réel, notamment dans des environnements tels que les stades, les attractions et les événements en direct ?

De nombreux clients demandent : pouvez‑vous simplement prendre l’application de chat et y brancher la voix ? Nous le pouvons. Mais cela ne garantit pas une bonne expérience. La prochaine vraie amélioration n’est pas une voix plus humaine, mais une interaction qui survive aux conditions réelles d’utilisation.

Dans un stade, quelqu’un parle au-dessus du bruit de la foule, utilise le nom d’un joueur méconnu, change d’avis à mi‑phrase et tente de finaliser un achat avant l’ouverture des portes. Le système doit gérer les interruptions, l’incertitude et les retards du back‑end sans perdre la tâche.

Portez une attention particulière aux détails critiques. Mal entendre une phrase informelle est une chose. Mal entendre le nombre de billets ou la date de l’événement en est une autre. L’agent doit confirmer les détails qui modifient la conséquence de l’action sans rendre toute la conversation fastidieuse.

Et la voix ne devrait pas être obligée de tout faire. Comparer vingt options de sièges est plus efficace sur un écran. Quelqu’un peut commencer par taper, monter dans la voiture, puis vouloir poursuivre la même conversation en parlant. Le système doit préserver ce contexte et utiliser la voix, le texte et les visuels selon ce qui convient le mieux à chaque instant.

Une partie de cela nécessite de meilleurs modèles. Une grande partie requiert une meilleure intégration et une conception d’interaction plus aboutie. Attendre une percée ne résoudra pas un flux de travail conçu autour du texte puis lu à haute voix. J’évaluerais les progrès ainsi : les gens accomplissent‑ils la tâche avec précision, avec moins d’effort, dans des conditions réelles ?

À mesure que les agents passent de la fourniture d’informations à la vente de billets, à la collecte de données clients, à la personnalisation d’expériences et à l’interaction avec les systèmes opérationnels, comment les entreprises doivent‑elles déterminer quelles décisions un agent peut prendre de façon autonome et lesquelles doivent toujours nécessiter une supervision humaine ?

Il s’agit de gestion des risques. Si cela tourne mal, quels dommages cela peut‑il engendrer ? L’agent ouvre‑t‑il une porte qu’il ne peut pas refermer ?

La réversibilité constitue un premier test utile, mais il faut également examiner l’exposition totale. Un remboursement peut être petit et réversible. Dix mille remboursements erronés avant que quiconque ne s’en rende compte constituent un problème différent. Il faut des limites sur les actions individuelles ainsi que sur l’activité cumulative du système.

Si l’action est à faible risque et réversible, accordez‑lui davantage d’autonomie : mettre à jour une préférence, vérifier une commande, retenir un article. À mesure que les conséquences augmentent, ajoutez une confirmation ou une approbation. Un achat peut nécessiter que le client confirme le prix. Un remboursement important peut nécessiter la validation d’un employé. Une menace pour la sécurité est immédiatement escaladée. Et certaines décisions doivent simplement rester entre les mains d’une personne, point final.

Le consentement du client et l’approbation de l’entreprise sont deux choses différentes, d’ailleurs. Le fait qu’un client confirme un achat n’autorise pas l’agent à contourner la politique de l’entreprise. Le fait qu’un employé approuve une exception ne signifie pas que le client a accepté une facturation.

Les limites doivent être appliquées par les systèmes qui exécutent l’action, et non simplement décrites dans une invite. Vous ne donnez pas à un agent un accès large puis comptez sur une invite pour lui dire d’être prudent. Et lorsqu’une personne est requise, fournissez‑lui suffisamment de contexte pour prendre une vraie décision. Confier à quelqu’un des centaines d’approbations sans aucune information, c’est créer un tampon en caoutchouc, pas une supervision. Orientez l’attention humaine là où elle réduit les risques significatifs. Ne la diluez pas à travers chaque interaction.

En regardant vers l’avenir, pensez‑vous que des technologies telles que le Model Context Protocol et la communication agent‑à‑agent vont fondamentalement changer la façon dont les systèmes d’IA d’entreprise sont construits, nous faisant passer d’agents isolés à des écosystèmes où les agents peuvent découvrir des outils, échanger du contexte et coordonner des actions entre entreprises et plateformes ?

Je pense que les protocoles sont un moyen d’atteindre un but. MCP offre aux applications d’IA un moyen commun d’accéder aux outils et au contexte. Les protocoles agent‑à‑agent gèrent la coopération entre agents. C’est précieux. Vous ne devriez pas devoir créer une intégration personnalisée chaque fois qu’un agent a besoin d’un outil. C’est similaire à ce que les API ont fait pour les intégrations logicielles.

Mais un format commun ne signifie pas que deux entreprises s’accordent sur la signification d’une action, sur qui peut l’autoriser ou sur ce qui se passe en cas d’échec. Le fait qu’un agent puisse découvrir un outil ne veut pas dire qu’il doit être autorisé à l’utiliser. Vous devez toujours déterminer l’identité, les autorisations, la confiance, la responsabilité. Si un agent demande à un autre d’accomplir une tâche et que cela échoue, qui porte la décision ?

Voici ce que je pense réellement changer. Aujourd’hui, un lieu dispose d’un site web et d’une application. Dans quelques années, il aura un agent avec lequel d’autres agents négocieront. L’assistant personnel d’un fan demande à l’agent du lieu deux places à un certain prix, ainsi qu’un laissez‑pass parking, et toute la transaction se déroule entre les deux agents. Identifier les bonnes capacités est l’étape facile. Connaître l’autorité de dépense du client, confirmer le prix total et gérer le cas où les billets sont confirmés mais le parking échoue, voilà les véritables problèmes.

Et je ne crois pas que la gestion d’un agent vous transfère automatiquement la relation client. Cela doit être gagné. Mais je ne pense pas non plus que les lieux confieront ces transactions à une société de recherche ou à une place de marché de billetterie. Notre objectif chez Satisfi Labs est d’être l’agent qui représente le lieu dans cette économie, celui suffisamment fiable pour que l’entreprise y appose son nom. Tout ce que nous avons construit autour de la fiabilité, des autorisations et de la responsabilité est ce qui nous vaut cette place.

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