L'IA Jev dans LiteTMS : où nous l'avons mise à l'œuvre

Nous avons intégré Jev, un modèle d'IA développé par TypeSafe AI, dans plusieurs flux de travail de LiteTMS. Il permet de repérer les messages de conducteurs nécessitant une attention particulière, de vérifier si deux toponymes désignent la même ville, de proposer une interprétation des fichiers d'importation ou encore d'éviter de traduire un message déjà rédigé dans la langue du destinataire. Il s'agit de micro-évaluations ciblées au sein d'un logiciel de gestion des transports (TMS), et non d'un nouvel assistant conversationnel de bureau.

Si ce nom ne vous dit rien, notre premier article sur Jev en détaille le concept. Alors qu'une IA générative classique rédige une réponse à partir d'un prompt, Jev est conçu pour répondre à une question bien plus précise, comme : « Ce message nécessite-t-il une réponse ? » LiteTMS applique ensuite cette évaluation au flux de travail concerné.

Les messages de conducteurs nécessitant une attention particulière

Un conducteur peut envoyer un simple statut de routine, poser une question ou signaler un problème. L'exploitation n'a pas à traiter chaque message avec le même niveau d'urgence. Dans la messagerie avec les conducteurs, nous avons intégré un contrôle Jev qui trie les messages entrants par sujet et détermine si l'exploitant doit intervenir. Ce mécanisme fonctionne aussi bien pour les messages écrits que pour les notes vocales une fois retranscrites.

Par exemple, « J'ai un pneu crevé » n'a pas la même portée que « Je suis arrivé ». Un message jugé prioritaire peut s'afficher dans la vue dédiée aux alertes, et un problème technique sur le véhicule peut déclencher une notification urgente. L'équipe d'exploitation conserve la main pour lire l'échange, répondre et classer le dossier. Jev n'envoie aucune réponse automatique au conducteur et ne décide pas de la gestion de la panne.

Pour un message signalant une crevaison, l'évaluation de l'IA se présente en JSON sous cette forme :

{
  "input": { "driver_message": "I have a flat tyre and cannot continue." },
  "jev_assessment": {
    "category": "vehicle_problem",
    "needs_action_probability": 0.94
  }
}

LiteTMS analyse la catégorie et le score de criticité. Un problème de véhicule associé à un score aussi élevé peut être signalé comme urgent, ce qui permet à l'exploitation de réagir sans attendre.

Les toponymes dans les ordres de transport et les documents

Un document peut mentionner « Köln » alors que l'ordre de transport indique « Cologne ». Une comparaison de texte stricte y verrait deux mots différents, alors qu'il s'agit de la même ville. Nous avons ajouté un contrôle Jev dédié à cette problématique lors de la saisie assistée des commandes et des vérifications de localités sur les lettres de voiture (CMR).

Lors de la saisie des commandes, ce module aide à faire un choix parmi les lieux suggérés ou réserve une correspondance douteuse pour examen manuel. Lors du contrôle d'une CMR, une forte probabilité de correspondance géographique écarte l'alerte d'écart de toponyme qui aurait été levée autrement. Une étape d'IA distincte lit le document, puis Jev évalue si les noms de lieux correspondent.

Pour deux variantes d'un nom de ville, l'évaluation se présente ainsi :

{
  "input": { "document_place": "Köln", "order_city": "Cologne" },
  "jev_assessment": { "same_city_probability": 0.92 }
}

Le score élevé de concordance lève l'anomalie de toponyme. Les autres vérifications de la CMR restent indépendantes.

Les fichiers d'importation aux intitulés de colonnes inhabituels

L'intégration de données dans un nouveau système démarre souvent par une feuille de calcul. Un fichier indique « numéro d'immatriculation », un autre « plaque », et un troisième utilise des en-têtes plus obscurs. LiteTMS applique d'abord des règles de correspondance classiques. Lorsque ces règles ne suffisent pas, Jev peut déduire la nature des données contenues dans le fichier et suggérer le mappage des colonnes avec les champs appropriés.

Les suggestions sont signalées comme assistées par l'IA, et la personne qui importe le fichier peut vérifier le mappage avant d'intégrer les enregistrements. Nous avons intégré cette approche à l'assistant d'importation général, ainsi qu'aux imports d'opportunités CRM et de marchandises. Un contrôle similaire permet de reconnaître une entreprise déjà présente dans la liste des tiers malgré une orthographe différente, ce qui évite les doublons lorsque le niveau de certitude est suffisant.

Supposons qu'un fichier de flotte importé utilise l'en-tête « Unit ref. » pour les plaques d'immatriculation et « Internal ID » pour les codes internes des véhicules de l'entreprise. Les valeurs d'exemple aident Jev à faire la distinction entre les deux. Lorsque les règles d'en-tête habituelles laissent le champ d'immatriculation vide, l'évaluation peut ressembler à ceci :

{
  "input": {
    "columns": {
      "col_0": { "header": "Unit ref.", "examples": ["WX 4821A", "PO 7619K"] },
      "col_1": { "header": "Internal ID", "examples": ["FLEET-17", "FLEET-42"] }
    },
    "field_to_match": "registration_number"
  },
  "jev_assessment": { "column": "col_0", "probability": 0.93 }
}

LiteTMS propose alors la première colonne pour les numéros d'immatriculation. L'exploitation valide ce mappage avant de finaliser l'importation des données. Si aucune colonne ne correspond, Jev sélectionne « none », laissant l'utilisateur mapper le champ manuellement plutôt que de forcer une association incorrecte.

Une vérification simple avant la traduction des messages

Il arrive qu'un message soit déjà rédigé dans la langue du destinataire. Avant de lancer une traduction complète du chat, LiteTMS peut solliciter Jev pour le vérifier. Une correspondance établie avec certitude permet au système d'afficher le message d'origine ; en cas de doute, le message suit le circuit de traduction habituel. La prise de décision reste ainsi prudente : le lecteur bénéficie toujours de la traduction dès lors que le système ne peut pas s'en dispenser avec certitude.

Prenons l'exemple d'un conducteur écrivant « Jestem na miejscu, czekam na załadunek », ce qui signifie « Je suis sur place, j'attends le chargement ». Pour un utilisateur lisant en polonais, la vérification peut produire l'évaluation suivante :

{
  "input": {
    "message": "Jestem na miejscu, czekam na załadunek.",
    "reader_language": "pl"
  },
  "jev_assessment": { "language": "pl", "probability": 0.96 }
}

La langue détectée correspondant à celle du destinataire, LiteTMS peut afficher le texte d'origine. Pour un utilisateur lisant en anglais, ce même message en polonais doit être traduit. Une réponse brève comme « OK » apporte moins d'indices : lorsque la langue ne peut pas être identifiée avec une certitude suffisante, le circuit de traduction habituel prend le relais.

Comment l'évaluation Jev s'intègre à LiteTMS

Jev fournit à LiteTMS un signal précieux, tandis que l'équipe d'exploitation conserve la maîtrise des opérations. Ces intégrations sont natives et s'exécutent dès lors que la couche décisionnelle de la plateforme est activée, selon le paramétrage de l'entreprise. Si Jev est indisponible, les flux habituels de messagerie, de documents et d'importation continuent de fonctionner normalement.

Regard technique : TypeSafe Jev, JSON et Java

Pour les lecteurs curieux de comprendre le fonctionnement sous-jacent, le point de départ réside dans la requête envoyée. Comme l'indique le guide de démarrage rapide de TypeSafe, une requête contient state, qui regroupe les données à évaluer, et questions, qui définit les évaluations à réaliser. Une question de type noul renvoie un nombre compris entre 0 et 1 représentant la probabilité qu'une affirmation soit vraie. Une question de type choice effectue une sélection parmi des options nommées, ce qui nous permet de déterminer la catégorie d'un message.

Voici la question d'action isolée, utilisant l'identifiant de modèle configuré dans notre intégration OpenRouter :

{
  "model": "typesafe/jev-1.13",
  "state": {
    "driver_message": "I have a flat tyre and cannot continue."
  },
  "questions": {
    "needs_action": {
      "type": "noul",
      "instructions": "The dispatcher must act on driver_message today: reply, give instructions, inform the customer or arrange help. Routine updates and thanks need no action."
    }
  }
}

La partie pertinente de la réponse ressemble à ceci :

{
  "answers": {
    "needs_action": {
      "type": "noul",
      "noul": 0.94
    }
  }
}

L'application lit answers.needs_action.noul et applique une règle. LiteTMS utilise un seuil de déclenchement de 0.55 pour signaler l'attention requise sur un message du conducteur. Après décodage du JSON, la vérification peut s'écrire en Java sous cette forme :

Double probability = 0.94; // Value from answers.needs_action.noul
boolean needsAttention = probability != null
    && Double.isFinite(probability)
    && probability >= 0.55
    && probability <= 1.0;

if (needsAttention) {
    System.out.println("Flag the message for dispatcher review");
}

Le code vérifie que la valeur est exploitable avant de la comparer au seuil. Dans LiteTMS, la détection de catégorie complète la règle : un problème de véhicule qui requiert une attention déclenche également une alerte urgente. Le modèle évalue le message ; l'application définit l'action. Si la réponse fait défaut, le flux de messagerie standard se poursuit.

Le seuil retenu dépend de l'opération qui suit. Pour une suggestion de colonne d'import, LiteTMS retient une colonne avec une probabilité minimale de 0.60 ; ignorer la traduction nécessite en revanche que la langue du lecteur soit détectée avec une probabilité d'au moins 0.90. Un score de 0.85 suffit donc à proposer une suggestion de colonne soumise à relecture humaine, mais ne permet pas de se passer de la traduction du chat. Chaque règle est calibrée en fonction de la portée de la décision.