Contexte
La saisie terrain est la partie la plus coûteuse du travail de sécurité
Une analyse de risques, une inspection ou un rapport d'incident se remplit sur place, pas au bureau. Le travailleur a des gants, du bruit autour, parfois un éclairage difficile, et une connexion qui n'est pas garantie. Le formulaire est long parce que la réglementation l'exige.
C'est exactement le genre de tâche où un assistant devrait aider. Et exactement le genre de contexte où il peut faire plus de mal que de bien.
Le problème
Une mauvaise réponse ne coûte pas une conversion
Dans la plupart des produits, une suggestion d'IA erronée est une nuisance. Ici, elle peut se retrouver dans un document réglementaire, ou pire, orienter une décision sur un chantier. Le coût d'une erreur n'est pas symétrique avec le gain de temps.
Mon rôle
Concevoir la fonctionnalité et diriger l'équipe qui livre autour
CONFORMiT n'a pas de filière de gestion dédiée. J'ai donc conçu l'assistant tout en dirigeant l'équipe design, dont un designer dédié au module d'intelligence artificielle. Côté produit, deux product managers se partagent les modules de la plateforme et l'IA, et chaque priorité passe par un système de gates où j'évalue l'ampleur et les impacts inter-modules avant le démarrage.
- Conception des trois capacités : génération de rapports, conversation de domaine, interprétation de contenu capté sur le terrain
- Définition de la façon dont l'assistant montre d'où vient une réponse
- Arbitrage sur ce que l'assistant ne fait pas
- Direction créative pour que l'assistant reste cohérent avec le reste de la plateforme
La question de la confiance
Amener quelqu'un à croire une réponse demande plus de travail que de la produire
La difficulté centrale de ce projet n'était pas technique. Un technicien expérimenté a de bonnes raisons de se méfier d'un outil qui lui dit ce qu'il constate depuis vingt ans. S'il doit vérifier chaque réponse, l'assistant ne fait pas gagner de temps, il en coûte.
La conception a donc porté autant sur la manière de présenter une réponse que sur la réponse elle-même. Quatre mécanismes ont été retenus.
Montrer le raisonnement
La réponse peut être dépliée pour voir comment elle a été construite, au lieu d'arriver comme un verdict.
Résumer les sources
Un sommaire des sources et de la documentation mobilisée accompagne la réponse.
Rendre le désaccord facile
Voter sur la pertinence, réessayer, interrompre une réponse en cours, modifier sa question et relancer.
Garder la personne aux commandes
L'assistant prépare, la personne valide. Dans un contexte réglementaire, cette frontière ne se déplace pas.
L'arbitrage que je retiens le plus
Nous voulions afficher la source exacte derrière chaque affirmation. C'était la réponse idéale au problème de confiance, et elle n'a pas été livrée. Trop de bruit pour l'utilisateur, trop de dépendances techniques, et un risque réel de donner une fausse impression de précision quand la source est partielle.
Le compromis retenu a été le sommaire des sources. Il dit sur quoi la réponse s'appuie sans prétendre à une traçabilité ligne par ligne. Moins satisfaisant sur le papier, plus honnête à l'usage.
Confidentiel. Présentable en entrevue.
Ce qu'on a construit
Trois capacités, un seul domaine
Génération de rapports
À partir des données déjà saisies sur le terrain, plutôt qu'à partir d'une page blanche.
Conversation de domaine
Spécialisée en santé et sécurité au travail. Un assistant généraliste aurait été moins utile et plus risqué.
Interprétation de contenu
Photos et documents captés sur place, transformés en éléments exploitables dans le dossier.
Cohérence avec la plateforme
Les mêmes composants et les mêmes règles d'accessibilité que le reste du produit, portés par le design system.
Autour de ces capacités, il a fallu concevoir tout ce qui fait qu'une conversation reste utilisable dans le temps : historique et recherche dans les conversations passées, renommage, suppression, pièces jointes avec glisser-déposer, questions de démarrage pour ceux qui ne savent pas quoi demander, et les états d'erreur.
Concevoir les murs, pas seulement les portes
Le produit fonctionne avec des quotas. Nombre de messages, nombre de réponses générées, volume de téléversements. Chacune de ces limites a son écran, parce qu'un utilisateur qui bute sur un mur sans explication conclut que l'outil est brisé.
Même logique pour les fonctionnalités réservées à un plan supérieur. Plutôt que de masquer ce qui n'est pas accessible, les tentatives sont traitées comme des parcours à part entière : la personne comprend ce qu'elle vient de toucher et pourquoi.
Décisions et compromis
Ce que nous avons refusé de faire
Le choix le plus structurant a été de restreindre le domaine. Un assistant qui répond à tout inspire moins confiance qu'un assistant qui répond bien à un sujet et le dit quand il sort de son champ.
Le second a été de ne pas automatiser la validation finale. L'assistant prépare, la personne signe. Dans un contexte réglementaire, déplacer cette frontière aurait été un mauvais service rendu à l'utilisateur.
Ce que j'en retiens
L'adoption d'une fonctionnalité d'IA se joue après le lancement
Le travail intéressant commence quand les gens s'en servent autrement que prévu. C'est aussi là que l'absence d'instrumentation produit se fait le plus sentir : je peux décrire ce que j'ai observé, pas le mesurer.
Ce que je regarde maintenant. L'écart entre ce qu'une fonctionnalité d'IA peut faire et ce que les gens acceptent de lui confier. C'est un problème de conception avant d'être un problème de modèle, et c'est celui qui m'intéresse le plus en ce moment.