Argo : concevoir l'interface entre un moteur de planification IA et les opérations portuaires

Contexte

Environ la moitié des conteneurs qui transitent par le Port de Montréal en repartent par train. Les faire sortir dépend de la coordination entre des organisations qui ne relèvent pas les unes des autres : l’autorité portuaire, les exploitants de terminaux, les transporteurs ferroviaires, les transporteurs maritimes. Chacune détient une partie du portrait. Aucune ne le détient au complet.

Argo a été construit pour combler cet écart. C’est une plateforme de planification par IA pour le Port de Montréal, développée avec Ivado Labs, Thales, Scale AI, le CN, le CP et les exploitants de terminaux du port, qui utilise l’apprentissage machine pour prédire les volumes d’importation et d’exportation, et la recherche opérationnelle pour optimiser les décisions qui en découlent. L’objectif : étendre l’horizon de planification du port d’environ 72 heures à dix jours.

Thales nous a intégrés au mandat de design : le modèle d’interaction et l’architecture d’information de la plateforme par laquelle les coordonnateurs du port allaient réellement se servir de ce que le moteur produisait.

Le défi

Le moteur produisait des prédictions et des plans. Ce n’était pas le problème de design. Le problème de design, c’était que trois coordonnateurs différents, travaillant pour des organisations différentes avec des responsabilités différentes, devaient agir à partir du même résultat, et qu’aucun d’eux n’agissait seul.

Le coordonnateur ferroviaire, le coordonnateur des débardeurs et le coordonnateur du port se réunissaient deux fois par jour pour planifier le travail à venir. C’est dans cette rencontre que les décisions se prenaient. Les individus pouvaient se connecter et bâtir des plans, mais le véritable rôle de la plateforme était de donner à trois personnes aux mandats différents une référence commune à partir de laquelle raisonner ensemble, puis s’engager.

La prévision, elle, était la même pour les trois. Ce qui différait, c’était ce qu’elle signifiait pour eux : les décisions qui en découlaient, les objectifs dont ils étaient redevables, et l’entreprise dont ils planifiaient le travail. Le design devait permettre à un seul portrait de parler à trois ensembles d’enjeux à la fois.

Les conséquences d’une erreur sont concrètes. Les débardeurs de cette industrie sont sur appel; ils apprennent la veille s’ils travaillent le lendemain. Un plan bâti sur la plateforme le mardi détermine qui sera appelé pour le mercredi. Le résultat d’un modèle de prévision devient, une étape plus loin, la semaine de travail d’une personne.

L’interface devait donc porter une prévision probabiliste jusque dans une salle où les décisions, elles, ne l’étaient pas. Les coordonnateurs devaient voir ce qui entrait et sortait par bateau et par train, où se trouvait chaque conteneur dans la chaîne, et depuis combien de temps il attendait à chaque étape, mesuré par rapport aux seuils de service qui définissaient si le port livrait la marchandise. Il leur fallait assez pour juger le plan, pas seulement le recevoir.

L’approche

Recherche avec chaque rôle, puis avec tous ensemble

Nous avons interviewé chaque type d’utilisateur séparément pour comprendre leur travail de planification : ce dont ils étaient responsables, ce qu’ils savaient déjà, ce qui leur manquait, et ce qu’ils faisaient pour compenser. Nous avons ensuite mené une activité Miro conjointe réunissant les trois rôles dans une même séance. Les entrevues individuelles font ressortir ce dont chaque rôle a besoin. Les mettre dans la même pièce fait ressortir où leurs besoins entrent en collision, et c’est cette partie-là qui compte quand on conçoit un artefact partagé pour une rencontre de coordination.

Concevoir la façon dont le moteur allait parler

Ma responsabilité principale était le modèle de présentation : la façon dont les métriques et les prédictions de la plateforme seraient communiquées aux personnes qui s’en servaient. Cela voulait dire déterminer quelles parties du résultat du moteur avaient leur place dans l’interface, jusqu’où projeter dans le temps, comment représenter le temps d’attente des conteneurs par rapport aux seuils de service pour qu’un coordonnateur voie d’un coup d’œil où la pression montait, et comment structurer le tout pour que trois rôles aux mandats différents trouvent chacun leur partie du portrait sans perdre le portrait commun.

La plateforme permettait aussi de travailler contre la prévision, pas seulement de la lire. Les coordonnateurs pouvaient modéliser des scénarios en ajustant les conditions que le moteur avait tenues pour acquises, le manque de travailleurs étant le cas évident, et voir de quoi le plan avait l’air de l’autre côté. C’est la partie du design qui sortait le résultat du moteur de la catégorie du verdict. Un coordonnateur capable de demander ce qui arrive si quatre personnes ne se présentent pas est un coordonnateur capable de confronter le raisonnement de la machine au sien avant de s’y engager.

Nous avons travaillé aux côtés de l’équipe d’Ivado Labs tout au long du mandat. Ils ont façonné la manière dont les données devaient être présentées, éclairés par notre recherche et les données du client; nous sommes restés proches durant le développement pour les questions et l’assurance qualité. Figma n’avait pas de mode de transfert aux développeurs à l’époque, alors nous présentions dans Figma et transformions le design en prototype pour éprouver le comportement.

Valider avec les gens qui allaient s’en servir

Nous avons ramené les wireframes et le design aux utilisateurs pour validation, plutôt que d’attendre une version construite pour découvrir si le modèle tenait la route.

L’accessibilité comme contrainte de design, pas comme étape de révision

Le Port de Montréal relève de la juridiction fédérale : le niveau AA du WCAG 2.0 était donc une exigence du client dès le départ. J’ai pris en charge l’accessibilité comportementale (navigation au clavier, gestion du focus, sémantique pour lecteurs d’écran, validée avec NVDA); Tamara Ammar s’est occupée de la couleur et des contrastes; une spécialiste en accessibilité a appuyé le travail. Intégrer l’exigence au modèle d’interaction dès le début est un exercice différent d’auditer une interface finie pour vérifier si elle s’y conforme.

Ce que le travail a produit

Argo a été livré. La plateforme est en production au Port de Montréal, et on lui attribue publiquement une amélioration de la précision des arrivées prévues de navires et de trains, passée de 80 % à plus de 95 % sur un horizon de dix jours. Ce chiffre appartient à la plateforme et aux années de travail qui ont suivi les nôtres, pas au mandat de design. Ce que nous avons apporté, c’est la couche par laquelle les coordonnateurs pouvaient agir à partir de tout cela.

Le principe de design sous-jacent : le plan n’appartenait pas au moteur. Le moteur pouvait voir dix jours à l’avance, à travers des données auxquelles aucun coordonnateur n’avait accès à lui seul. Il ne pouvait pas voir les dizaines de choses que ces trois personnes savaient à force de travailler le port. L’interface devait livrer ce que le moteur savait sous une forme que trois personnes pouvaient questionner, contester, et transformer en une décision qu’elles étaient prêtes à signer de leur nom, deux fois par jour, tous les jours.

Livrables

• Entrevues avec les coordonnateurs ferroviaires, des débardeurs et du port
• Atelier Miro conjoint réunissant les trois rôles de coordination
• Modèle d’interaction et architecture d’information de la plateforme de planification
• Modèle de présentation des prédictions et des métriques du moteur de planification IA, incluant le temps d’attente des conteneurs par rapport aux seuils de service
• Design d’interaction pour la modélisation de scénarios à partir de la prévision du moteur
• Designs d’interface adaptés à chaque rôle
• Prototype Figma interactif utilisé pour éprouver le comportement de la plateforme
• Séances de validation des wireframes et du design avec les utilisateurs
• Accessibilité comportementale WCAG 2.0 niveau AA (clavier, focus, sémantique pour lecteurs d’écran, validée avec NVDA)

Période du projet : mars 2021 à juillet 2021
Client : Thales Solutions Numériques
Acheteur : Port de Montréal
Langue de travail : français et anglais

Contributeurs et rôles

• Louis-Philippe Bellerose — Designer UX. Recherche, modèle d’interaction, architecture d’information, mise en page et comportement, présentation du résultat du moteur de planification, accessibilité comportementale, soutien à l’assurance qualité durant le développement.
• Tamara Ammar (Thales) — Designer UI. Design visuel, accessibilité des couleurs et des contrastes.

Outils utilisés

• Figma
• Miro
• MS Teams
• NVDA