Créer une application devient plus simple. Et ensuite ?

J'apprécie que les agents d'IA permettent d'essayer des idées que les gens remettaient jusque-là à plus tard. Une personne connaît bien son travail, voit ce qu'elle pourrait simplifier et peut désormais créer plus vite un petit outil pour y parvenir. Un rapport pour un client, une application pour l'équipe d'exploitation, une intégration avec le système d'un entrepôt. Davantage d'idées ont une chance de se concrétiser.

Cela change aussi ce que j'attends d'une plateforme. Chacun devrait pouvoir tester rapidement une idée, puis la faire évoluer sereinement : la mettre entre les mains des utilisateurs, comprendre ce qui fonctionne et apporter des améliorations. Pouvoir compter sur la plateforme permet de consacrer davantage d'attention au problème à résoudre. C'est dans cet esprit que nous construisons Navixy V4.

La première version de votre application aide à comprendre le problème et à tester votre approche

Supposons que vous ayez créé, avec un agent, une application pour un responsable d'exploitation. Elle affiche les livraisons et signale les retards possibles. Vous pouvez déjà l'examiner avec la personne qui l'utilisera et voir si elle l'aide dans son travail.

Cette discussion fait apparaître des détails difficiles à prévoir. Le responsable sait qu'une file d'attente se forme régulièrement dans un entrepôt. Pour un autre, il doit appeler le destinataire à l'avance. Et certaines alertes sont simplement ignorées : elles arrivent trop souvent et n'appellent aucune action.

Vous disposez maintenant d'une base pour la version suivante. Vous pouvez ajuster les alertes et vérifier s'il devient plus facile de repérer les livraisons qui nécessitent vraiment une intervention.

Trois questions se posent ensuite et déterminent le fonctionnement quotidien de l'application : sur quelles données repose-t-elle, comment la maintenir et que peut-on confier aux agents ?

Des données sur lesquelles l'application peut s'appuyer et auxquelles les utilisateurs peuvent se fier

« Le véhicule était-il en retard ? » semble être une question simple, jusqu'au choix de l'événement à utiliser pour le calcul. L'entrée sur le site de l'entrepôt et la réception de la marchandise peuvent avoir lieu à une demi-heure d'intervalle. La requête s'exécutera dans les deux cas, mais les réponses n'auront pas le même sens.

Il est utile de définir une seule fois la règle convenue avec le client, puis de l'utiliser dans toutes ses applications. Le rapport du matin et l'assistant de l'équipe d'exploitation pourront ainsi s'appuyer sur la même définition de l'arrivée. Si le client modifie la règle, il sera clair à partir de quand la nouvelle version s'applique et si ses résultats peuvent être comparés aux précédents.

Des questions en apparence plus simples influencent aussi la réponse. Les équipements transmettent des données dans différents formats, les messages arrivent avec du retard et les traces comportent des lacunes. « Le véhicule n'est pas arrivé » et « nous n'avons pas reçu les données de son arrivée » sont deux situations différentes. L'application doit les distinguer, sinon une lacune dans les données peut facilement être prise pour un retard du conducteur.

Nous réfléchissons donc à tout le parcours des données : comment conserver les enregistrements d'origine, les normaliser et les relier aux véhicules, aux personnes et aux tâches. Cette base permet ensuite de définir des événements et des indicateurs utiles. Et si un client s'interroge sur un chiffre du rapport, il devient possible de le retracer : voici les données d'origine, voici la règle et voici comment le résultat a été calculé. C'est cette approche que nous intégrons à la plateforme.

Après le lancement, vous devez maintenir et faire évoluer l'application pour vos utilisateurs

Supposons que le responsable d'exploitation ait l'habitude de recevoir un rapport au début de chaque service. Un jour, le rapport n'arrive pas. Les données ont-elles pris du retard, le calcul n'a-t-il pas abouti ou l'application n'a-t-elle pas démarré ?

L'historique d'exécution aide à le comprendre : les étapes parcourues, la durée d'un script ou d'une requête et l'endroit où le processus s'est arrêté. Un message d'erreur est utile lorsqu'il explique ce qui s'est passé et à quelle étape. Pour un agent, l'état actuel compte aussi : travaille-t-il encore, a-t-il échoué ou attend-il la validation d'une personne ? Une décision en attente et un échec n'appellent pas la même réponse.

Notre approche consiste à rendre cet historique accessible à l'analyse. Examiner le flux de données dans Inspector d'IoT Logic, consulter les journaux d'IoT Query et les rapprocher de l'exécution de l'application. Une personne, ou un agent qui l'aide dans l'analyse, dispose alors d'éléments concrets pour chercher la cause. Il devient plus facile de corriger le problème, de tester la nouvelle version et de revenir à la précédente si nécessaire.

Mais un outil peut fonctionner sans erreur et rester peu pratique. Si une mise à jour double le nombre d'alertes reçues, il faut vérifier si elles aident à repérer les livraisons importantes ou si elles détournent simplement l'attention. Les données de fonctionnement de l'application permettent d'évaluer le changement avec l'utilisateur : qu'est-ce qui a changé et est-ce plus utile ?

Lorsqu'un autre client aura besoin de l'application, la solution pourra être adaptée à ses paramètres, tout en gardant ses données et ses droits d'accès séparés. Dans notre approche, un environnement commun aide le partenaire à faire évoluer une solution pour plusieurs clients, sans entretenir une multitude de copies indépendantes.

Authentification et autorisation des agents

Un assistant qui prépare une synthèse a seulement besoin de lire les données. Un agent chargé de modifier les tâches des conducteurs a besoin d'autres permissions. Cette différence définit son accès : les données qu'il peut lire et les actions qu'il peut effectuer.

Nous appliquons la même logique qu'avec les personnes : chaque participant a un rôle et des responsabilités. Lorsqu'un agent envoie une requête, il faut établir au nom de qui il agit, pour quel client il travaille et si cette action précise lui est autorisée. Ces limites doivent rester les mêmes, que la requête passe par une application ou provienne directement de l'agent.

Si la tâche d'un conducteur change, il est utile de savoir qui l'a modifiée et quand. Si un agent n'a pas pu mener une mission à bien, il faut comprendre quelle permission lui manquait. Cet historique facilite l'examen des résultats et le choix de ce qui pourra lui être confié ensuite. Il est possible de commencer par un accès en lecture, puis d'ajouter des actions à mesure que la confiance dans son travail se construit.

Je souhaite que les partenaires aient davantage de temps à consacrer aux problèmes de leurs clients. Qu'une première application réussie marque le début d'un travail qu'ils pourront poursuivre, proposer à d'autres clients et adapter à de nouveaux besoins. C'est pour moi tout le sens d'une plateforme fiable.