eSafety : Transformer l'évaluation toxicologique en logique de données
L'Oréal Recherche & Innovation • Avril 2020 - Septembre 2022 • UX/UI Designer & Researcher
Introduction
Chaque produit cosmétique L'Oréal passe par une évaluation toxicologique avant d'atteindre le marché. La précision est critique et la traçabilité est réglementaire. Et les outils pour faire tout ça ? Word et Excel.
Des fichiers éparpillés, des versions qui divergent après trois allers-retours par email et des données enfermées dans des cellules impossibles à exploiter. Chaque évaluation repart de zéro, même quand un ingrédient similaire a été analysé des dizaines de fois, parce que retrouver l'information prend plus de temps que la recréer. Et quand un expert part, une partie de la connaissance disparaît avec lui.
Challenge
L'Oréal voulait passer d'une logique documentaire à une logique de données. Une évaluation ne serait plus un document Word mais un ensemble de données structurées, liées entre elles, exploitables par des algorithmes et donc capitalisables pour les évaluations futures.
L'enjeu dépassait la digitalisation :
Il s'agissait de transformer un processus d'évaluation toxicologique en système centralisé de collecte et d'exploitation de données de sécurité cosmétique, ouvrant la voie aux capacités de data science du département.
Mon rôle
Seul designer de l'équipe, avec une double casquette recherche et conception. L'équipe projet déployée par Saegus (l'entreprise de conseil pour laquelle je travaillais alors) comptait 6 personnes en simultanée sur toute la durée : un Product Owner, 4 développeurs full-stack et moi.
Ce ratio imposait un rythme soutenu mais permettait une collaboration étroite très appréciable. Je participais aux discussions techniques, ce qui m'évitait de concevoir des solutions irréalistes et donnait aux développeurs une visibilité directe sur les choix d'expérience utilisateur.
Discovery
Ce qu'on croyait
Le cadrage initial positionnait le projet comme une digitalisation de processus : prendre le workflow Word/Excel existant et le transposer dans une application web structurée. Les mêmes étapes, le même raisonnement, un meilleur contenant.
Ce que le terrain a montré
Les toxicologues ne sont pas des utilisateurs ordinaires. Ce sont des scientifiques avec des doctorats et des années d'expérience. Leur vocabulaire est technique, leurs processus sont régis par des contraintes réglementaires strictes et leurs attentes envers un outil sont élevées parce qu'ils savent exactement ce dont ils ont besoin.
L'immersion - 14 entretiens approfondis, observation des pratiques réelles, analyse des documents manipulés - a révélé que le problème n'était pas le contenant mais la logique. Les mêmes informations étaient saisies plusieurs fois dans différents documents. Un ingrédient évalué dans un contexte n'était pas relié à ses évaluations précédentes. La collaboration restait séquentielle : les documents circulaient par email avec des versions qui se multipliaient.
Reframing
Transposer le workflow existant dans une application aurait reproduit les mêmes problèmes dans un outil plus joli. Il fallait repenser la logique : structurer les données pour qu'elles se relient entre elles, qu'elles se capitalisent, qu'elles deviennent interrogeables. Et surtout, il fallait le faire sans trahir l'expertise des utilisateurs - sans simplifier là où la complexité est le travail.
Conception
Concevoir pour des experts, c'est résister à la tentation de simplifier. Les toxicologues n'avaient pas besoin d'une interface facile : ils avaient besoin d'une interface précise, puissante, qui parle leur langue. Trois décisions illustrent cet équilibre.
1. Un dashboard plutôt qu'un formulaire
La première version de la page d'évaluation d'un ingrédient présentait un formulaire linéaire, champ par champ. Les toxicologues l'ont rejeté : leur raisonnement n'est pas linéaire. Ils ont besoin de voir simultanément l'historique de l'ingrédient, les résultats de tests, la réglementation applicable et les évaluations précédentes. J'ai restructuré l'interface en vue tableau de bord avec des panneaux latéraux dépliables. Plus dense visuellement, mais en phase avec le modèle mental des scientifiques. La densité n'est pas un défaut quand elle sert l'expertise - et ce choix s'est avéré concluant.
2. Le compromis du champ libre
Le modèle de données imposait des champs structurés. Mais les toxicologues avaient besoin de documenter des exceptions, des cas particuliers, des nuances que la structure ne prévoyait pas. Supprimer le champ libre aurait été plus propre pour la base de données. Le conserver était essentiel pour l'adoption. Le compromis : un champ structuré principal avec un champ libre secondaire étiqueté, dont le contenu était indexé et recherchable mais pas contraint par le modèle.
3. La recherche multimodale
Les toxicologues recherchent par nom chimique, par nom commun, par numéro CAS ou par famille d'ingrédients. Proposer une seule barre de recherche avec autocomplétion multimodale - qui accepte tous ces formats - plutôt que quatre filtres séparés a réduit le temps de recherche de plusieurs minutes à quelques secondes. C'est devenu la fonctionnalité la plus citée comme "game changer" par les utilisateurs.
Obstacles
L'intégration dans l'écosystème L'Oréal
eSafety n'est pas une application isolée. Les données toxicologiques sont sensibles - l'application devait respecter les politiques de sécurité du groupe, communiquer avec d'autres systèmes et rester maintenable à long terme. Chaque choix de conception était validé techniquement : faisable, compatible et maintenable.
La courbe d'apprentissage permanente
La toxicologie n'est pas un domaine qu'on maîtrise intuitivement. Même après des mois de travail, de nouvelles subtilités émergeaient. Cette courbe d'apprentissage continue demandait de rester humble, de poser des questions, de ne jamais prétendre en savoir plus que les experts.
La transformation des habitudes
Passer de Word et Excel à une application structurée changeait fondamentalement la façon de travailler. La clé était de démontrer la valeur concrètement : quand un utilisateur constatait qu'il trouvait en quelques secondes une information qui lui aurait pris 30 minutes à chercher, la résistance diminuait.
La discipline sur 2,5 ans
15 sessions de tests ont ponctué le projet - pas des tests formels en fin de développement mais des tests continus intégrés au cycle de travail. Tests de concepts avant développement, tests de fonctionnalités sur vrais dossiers avec vraies données. Cette approche demande d'accepter que la première version n'est jamais parfaite et de remettre en question des choix qu'on pensait solides quand les retours terrain les contredisent.
Impact
Gain d'efficacité
Environ 30% de temps gagné par évaluation en conditions réelles.
Accès à l'information
Avant : une recherche d'information sur un ingrédient prenait plusieurs dizaines de minutes de fouille dans des fichiers éparpillés. Après : quelques secondes, avec l'historique complet des évaluations précédentes.
Collaboration documentaire
Avant : un document circulait par email avec 3 à 5 versions divergentes. Après : une collaboration centralisée avec traçabilité des modifications et validation intégrée.
Capitalisation des savoirs
Avant : quand un toxicologue partait, son savoir partait avec lui. Après : chaque évaluation enrichit une base de connaissances structurée, recherchable, réutilisable.
Enseignements
Concevoir pour des experts, c'est résister à la tentation de simplifier.
Les toxicologues n'avaient pas besoin d'une interface facile : ils avaient besoin d'une interface précise, puissante, qui parle leur langue. Chaque fois que j'étais tenté de "simplifier", la bonne question était : est-ce que je simplifie pour l'utilisateur ou pour moi ?
Travailler avec des scientifiques élève tes standards.
Leur rigueur est contagieuse. Quand vos utilisateurs ont de tels niveaux de compétences et de connaissances, vous ne pouvez pas vous permettre d'approximations - et cette exigence a durablement amélioré ma propre pratique.