UiPath et TypeSafe : des décisions structurées avec les modèles Jev

UiPath annonce le connecteur TypeSafe en préversion : modèles Jev, classification des demandes, scores de confiance et précautions avant déploiement.

**Date de l’annonce :** 2026-10-20. **Périmètre :** connecteur TypeSafe dans UiPath Integration Service, annoncé en préversion. Cette analyse s’appuie sur les sources des éditeurs ; FazaSolutions ne présente pas ici un test indépendant du connecteur.

Le 20 octobre 2026, UiPath a annoncé un connecteur TypeSafe permettant d’appeler les modèles Jev depuis Integration Service.[4] La nouveauté concerne cette intégration, pas l’invention de la classification automatique. Elle vise des décisions limitées : choisir une catégorie, situer une demande sur une échelle ou évaluer une question oui/non.[4]

Pour une équipe qui traite des emails, des factures ou des tickets, l’intérêt est concret : obtenir une réponse structurée plutôt qu’un paragraphe à interpréter. Encore faut-il savoir quand cette réponse peut déclencher une action, et quand elle doit être vérifiée.

Ce que le connecteur ajoute à UiPath

Selon l’annonce, les activités Jev peuvent être utilisées dans les environnements UiPath prenant en charge les connecteurs, notamment Maestro Automate et Maestro Orchestrate.[4] L’utilisateur fournit une clé API de son propre compte TypeSafe.[22] La documentation décrit les activités List Models, Choice, Score, Noul et Evaluate (System One).[13]

La distinction avec un assistant généraliste tient à la forme de la demande. On ne lui confie pas « traite ce dossier de bout en bout ». On lui soumet un contexte et une ou plusieurs questions délimitées. Le workflow conserve les règles qui déterminent la suite.

L’annonce précise que les requêtes utilisant cette clé relèvent de l’accord direct avec TypeSafe et ne passent pas par l’UiPath AI Trust Layer.[4] Ce point mérite une vérification avant d’envoyer des informations métier : la présence d’un connecteur dans UiPath ne suffit pas à établir le régime de traitement des données du service appelé.

Le choix du modèle ne résout pas, à lui seul, l’accès aux informations métier. Notre analyse de [l’intégration entre UiPath et Snowflake](https://fazasolutions.com/articles/uipath-et-snowflake-l-integration-bidirectionnelle-change-le-pilotage-des-automatisations) aborde cette autre partie de l’architecture : rapprocher les données et les actions automatisées.

Choice, Score et Noul : trois sorties différentes

**Choice** sélectionne une option dans un ensemble défini.[14] Pour un email, les catégories pourraient être « facturation », « assistance technique », « demande commerciale » et « autre ». La réponse comporte l’option retenue, les probabilités associées aux options et un indicateur de confiance.[14]

**Score** positionne le contenu sur une échelle ordonnée dont les niveaux sont décrits à l’avance.[14] Il peut s’agir, par exemple, de niveaux de mécontentement. La sortie comprend notamment un score et une distribution de probabilités.[14] Il faut définir les niveaux assez précisément pour que le résultat ait un sens opérationnel.

**Noul** répond à une question oui/non en renvoyant une probabilité entre 0 et 1.[14] « Le message demande-t-il un remboursement ? » convient mieux que « Quelle est la meilleure manière de gérer ce client ? ». Contrairement à Choice et Score, Noul ne fournit pas de champ confidence distinct.[14] Une valeur proche de 0,5 exprime une incertitude entre oui et non, pas un niveau intermédiaire de gravité.[14]

L’activité Evaluate permet de combiner plusieurs questions sur un même contexte dans une requête.[13] Cela ne signifie pas que les questions s’expliquent mutuellement : la documentation TypeSafe indique qu’elles sont évaluées indépendamment.[14]

Un exemple : orienter une demande sans automatiser la décision sensible

Considérons un scénario illustratif, et non un déploiement client : une boîte partagée reçoit des demandes de support, de facturation et de renseignements commerciaux.

Le workflow vérifie d’abord l’identifiant du message pour éviter les doublons, puis prépare uniquement les informations nécessaires à la classification. Une question Choice propose un service destinataire ; une question Noul cherche une demande de remboursement explicite. Le code contrôle ensuite les résultats avant toute mise à jour.

Une demande clairement classée peut être proposée à la bonne file de traitement. Un message contradictoire, une catégorie « autre » ou une information manquante part en revue humaine. La présence d’une demande de remboursement n’autorise pas son exécution : les droits, les justificatifs et l’approbation restent des contrôles séparés.

Cette séparation correspond à la conception d’un [workflow d’automatisation avec IA](https://fazasolutions.com/services/automatisation-workflows-ia) : le modèle interprète l’entrée, tandis que les règles métier encadrent les actions. Notre exemple de [qualification et de routage des prospects](https://fazasolutions.com/exemples/routage-prospects) présente une autre façon de distinguer collecte, validation et affectation.

Un score de confiance n’est pas une garantie de justesse

TypeSafe calcule l’indicateur confidence de Choice et Score à partir de la répartition des probabilités.[21] Une distribution concentrée sur une option donne davantage de confiance qu’une distribution étalée.[21] Ce signal peut servir à organiser une revue humaine ; il ne constitue pas une preuve indépendante que la catégorie retenue est correcte.

Il faut donc tester les seuils sur des exemples représentatifs du processus : messages brefs, fautes, demandes mêlant plusieurs sujets, formulations inhabituelles et langues réellement rencontrées. Pour une activité entre la France et le Maroc, cela peut inclure le français et les autres langues présentes dans les demandes reçues. L’annonce ne suffit pas à établir une performance pour chacune d’elles.

Les seuils doivent dépendre de l’action envisagée. Une proposition de classement réversible n’a pas les mêmes conséquences qu’un paiement, une suppression ou un engagement commercial. Dans ces derniers cas, une confiance élevée du modèle ne remplace pas l’autorisation requise.

Les vérifications avant un pilote

**Disponibilité et accès.** Le lancement du 20 octobre est présenté comme une préversion.[4] Vérifiez l’accès dans votre environnement, les licences et les conditions de support avant de prévoir une mise en production. La connexion requiert un compte TypeSafe et sa clé API.[22] Ne supposez pas que l’usage de ce service est inclus dans votre abonnement UiPath : vérifiez les conditions commerciales applicables.

**Données transmises.** Identifiez les champs envoyés, les informations à masquer et les conditions applicables chez TypeSafe. Ne transmettez pas systématiquement une conversation complète lorsque quelques éléments suffisent à la décision.

**Erreurs et reprises.** Prévoyez les clés expirées, les indisponibilités, les délais dépassés et les réponses inutilisables. Un appel au modèle réussi ne prouve pas qu’un ticket a été créé ; une relance après un délai dépassé ne doit pas créer un doublon dans le système cible.

**Mesure.** Comparez le classement avec des décisions de référence et mesurez les erreurs par catégorie, le volume de revues humaines, les délais et le coût du traitement complet. UiPath cite des expériences internes favorables à Jev, mais ces résultats ne sont pas une garantie de performance sur vos données.[4]

Lorsque le traitement doit ensuite agir dans une application sans API, une étape RPA peut compléter le workflow. Notre guide sur la différence entre [automatisation de workflows et RPA](https://fazasolutions.com/guides/automatisation-vs-rpa) explique pourquoi cette décision se prend système par système.

Le bon point de départ

Le connecteur TypeSafe propose une manière d’ajouter des décisions structurées aux workflows UiPath. Son intérêt doit être évalué sur une question métier précise, avec une liste de réponses définie et un chemin de revue pour les cas incertains.

Un premier pilote peut rester en mode observation : le modèle propose un classement, une personne le vérifie, et aucune action sensible n’est exécutée automatiquement. Cette étape permet de décider si le modèle apporte assez de valeur pour compléter les règles existantes, sans lui déléguer d’emblée tout le processus.