KAYRO

L’intérêt croissant pour l'intelligence artificielle (la frénésie ?) pousse de nombreux dirigeants à s'y intéresser de près. S’il est vu uniquement sous l’angle technique, un projet IA risque d’aboutir à un résultat techniquement impressionnant, mais déconnecté des attentes de vos utilisateurs.

Un produit qui fonctionne est avant tout un produit qui répond à un besoin spécifique, et suscite idéalement une réaction émotionnelle chez les utilisateurs. En dehors du monde universitaire et de la recherche, combiner product management et technologie est essentiel pour créer des produits qui seront vraiment utilisés, qu’ils intègrent ou non de l’IA.

Si ça a l’air simple, nombreux sont les produits que les utilisateurs n’adoptent jamais, et nombreux sont les projets data qui ne parviennent jamais à réduire les coûts ou engendrer des revenus. Il n’y a pas de magie, le retour sur investissement n’apparait pas tout seul. Pour faire un bon produit IA, il faut savoir faire du produit.

Dans cet article, nous nous intéresserons spécifiquement aux projets de deep learning, qui utilisent des algorithmes capables de mimer les actions du cerveau humain grâce à des réseaux de neurones artificielles, que nous allons nourir d'informations. Il peut s'agir, par exemple, de classer des enquêtes de satisfaction par émotions, ou de reconnaitre un de mes produits sur des images de surveillance. Notre objectif est de proposer une méthode complète pour lancer un projet de deep learning, de la définition de la cible au déploiement, qui s’inspire des meilleures pratiques du product management et des projets de recherche. Il n’y a pas de méthode miracle, et l’approche proposée ici ne fait pas exception. Elle devra être adaptée au cas par cas, selon votre contexte opérationnel, vos utilisateurs, vos technos, etc.

Notre situation de départ

Supposons que notre entreprise a fait un premier travail exploratoire : elle a priorisé des cas d’usages et s’est déjà assurée que le deep learning est la réponse la plus appropriée au problème identifié (certains projets demanderont plutôt d'utiliser une IA sans entraînement, l'API de GPT, du développement classique, parfois même processus manuel).

Nous avons donc une vague idée de ce que nous voulons faire, une ambition, un budget, une équipe identifiée. Le projet peut démarrer. Nous allons passer par deux grands moments : la conception et le delivery.

La conception - Identifier et mitiger les risques en amont pour s’assurer du succès du delivery

La phase de conception doit permettre de répondre à deux questions :

1. Où allons-nous ?

Il peut être tentant de se précipiter vers les données et de se plonger dans les calculs mathématiques. Cependant, si notre objectif est de garantir l'adoption de notre produit par les utilisateurs, il est essentiel de comprendre leurs préférences et de tout mettre en œuvre pour y répondre. Sans cela, notre modèle n'aura aucune utilité.

Notre objectif n’est pas de comprendre notre utilisateur, mais de comprendre ce qu’il veut réaliser avec notre produit. C’est ce qu’on appelle le “ Job-to-be-done ”.

Pour y arriver, les entretiens sont utiles, et nous les complétons avec des observations sur le terrain. Assis aux côtés des utilisateurs, nous comprenons de quelle façon ils résolvent le problème aujourd’hui (manuellement, avec un autre outil, au “feeling”…). Nous les observons faire des gestes inutiles, découvrons ce qui les fait sourire, ce qu’il ne faut surtout pas perdre, ce qui leur manque et ce qui leur fait perdre la tête. Une analyse exploratoire des données peut faire émerger de bonnes idées. En parallèle, nous nous intéressons à nos concurrents, et n’hésitons pas à nous projeter : quelle idée géniale permettrait à un concurrent d’accaparer notre marché ? Autant le faire avant lui.

Une fois au clair sur le job à réaliser, quelles sont les performances que notre produit doit atteindre ? Qu’est-ce qui est important pour notre utilisateur, quelles sont ses priorités ? Tel outil d’analyse financière devrait actualiser ses graphiques en temps réel pour permettre au courtier de réagir aux mouvements de la bourse, telle application de génération de documents juridique devra être conforme aux attendus légaux pour être recevable par un tribunal, tout est possible. Nous fixons en début de projet des métriques business à atteindre en explorant les scénarios en production, sur lesquelles tout le monde est aligné : l’équipe, les parties prenantes, la direction.

La grande spécificité d’un projet de r&d est qu’avant d’avoir réussi, nous n’avons aucune certitude sur la performance future du modèle. Si chaque produit et chaque contexte d'entreprise est distinct, il est souvent possible d'estimer la performance d'un modèle grâce à des études préliminaires. Il est important de noter que toutes les solutions d'IA ne sont pas basées sur des modèles nécessitant un entraînement, l'utilisation de modèles d'IA pré-entraînés est devenue courante, offrant une solution efficiente adaptée à des besoins spécifiques.

2. Comment y allons-nous ?

Une fois que la cible est claire, nous définissons notre stratégie pour l’atteindre. Ou plutôt devrions-nous dire : nos stratégies.

• Stratégie produit : nous devons borner le premier périmètre de fonctionnalités à mettre dans les mains de nos utilisateurs (MVP), et donc déprioriser des idées qui, à ce stade, peuvent sembler essentielles. Tout le monde a de bonnes idées et nous pourrions remplir des dizaines de pages de spécifications fonctionnelles, mais ces idées sont généralement biaisées. Ce n’est pas parce que vous travaillez dans les assurances depuis quinze ans que vous savez ce que vos assurés automobiles attendent de votre nouvel outil de constat automatisé. Ni vous, ni votre cabinet de conseil, ni votre product manager. Vous avez des hypothèses, mais elles doivent être validées sur le terrain. Dans les faits, de nombreuses fonctionnalités développées ne sont jamais utilisées par les utilisateurs, ce qui représente un gaspillage conséquent. Idéalement, la première version de votre produit a une fonctionnalité principale qui répond au job-to-be-done (encore lui) de votre produit et satisfait la métrique business la plus importante pour vos utilisateurs les plus importants.
• Stratégie technique : ici, nous cherchons à valider le type d’algorithme nécessaire (et donc faire des arbitrages sur le modèle, entre performance et précision notamment), la meilleure architecture possible, et plus généralement à choisir les technologies que nous utiliserons : R ou python, développement spécifique ou utilisation de briques existantes, etc.
• Stratégie data : les modèles peuvent changer, le matériau de base beaucoup moins (selon Gartner en 2020, plus de 25% des données critiques des plus grandes entreprises sont erronées). À ce stade, nous devons nous assurer de notre accès à un dataset de qualité, ou prévoir une stratégie pour le concevoir. Nous ne préparons pas encore les données, mais nous vérifions qu’elles sont exploitables (exactitude, conformité, sécurité…) et disponibles dans la durée pour alimenter notre produit.

Ok, nous avons déjà fait un super boulot. Une fois les environnements et la codebase préparés, nous pouvons commencer à délivrer.

Le delivery - Des itérations, de la sueur et un enjeu clé : mettre en production

Comme il est d’usage dans des contextes d’incertitude, les projets de deep-learning fonctionnent en cycles courts. Chaque sprint permet d’atteindre un objectif clairement défini, avec des déploiements réguliers exposés à quelques utilisateurs, et couvre les activités suivantes :

• Préparation des données : nous explorons les sources de données et leurs relations entre elles, nous nous assurons de la qualité des données, nous construisons le pipeline d’ingestion des données, nous préparons les données et les étiquetons. Cette dernière tâche, aussi appelée “data labeling”, est dans la plupart des cas externalisée à l’étranger, avec des effets négatifs pour l’entreprise et la société en général : les entreprises clientes ne vérifient pas toujours la qualité des données étiquetées qui serviront de base à l’entrainement de leurs modèles (et impacteront directement leur performance), et l’étiquetage est souvent réalisé par des travailleurs précaires.
• Conception ou sélection du modèle, exploration, développement des fonctionnalités et test : le développement du modèle repose sur deux phases, l’entrainement du modèle (le modèle est créé, entrainé sur un dataset d’apprentissage et optimisé en ressources consommées, temps de réponse, biais et valeurs extrêmes) et son inférence (application du modèle à un échantillon de données qu’il ne connait pas, le forçant à faire preuve de déduction pour arriver à un résultat, et comparaison des résultats obtenus avec les métriques business attendues).
• Déploiement à un petit groupe d’utilisateurs, expérimentation et intégration des feedbacks, puis déploiement à large échelle, maintenance et industrialisation : si le MVP est réussi, les enjeux deviennent principalement techniques, il faut construire une équipe capable de faire vivre le projet dans la durée.



Le "Cross-Industry Standard Process for Data Mining" (CRISP-DM) standardise les approches les plus courantes en data mining (Ml-ops.org)

Le grand risque des projets de deep learning, c’est de s’arrêter au POC (Proof Of Concept). Un POC sert à tester et valider rapidement une hypothèse avant de se lancer dans le développement. Le problème, c’est qu’ils ont tendance à se multiplier, sans jamais aboutir à un produit mis dans les mains des utilisateurs, avec de la valeur ajoutée. Dans la plupart des cas, aucune stratégie de mise en production n’a été définie, et le POC finit ses jours au cimetière des POCs avec de nombreux confrères.

Pour ne pas gaspiller du temps et frustrer les équipes, voici cinq principes pour éviter le cimetière des POCs :

• Ne pas penser POC (celui-là était facile), mais penser MVP : s’il n’est pas encore parfait, le MVP doit répondre au problème de l’utilisateur et être viable. Dès le départ, nous devons donc produire au niveau de qualité attendu et anticiper la stratégie de mise en production.

• Se concentrer sur la qualité des données : de nombreux projets se concentrent sur le développement du modèle et négligent les données. Pourtant, si leur exploration et leur préparation prend du temps, c’est la qualité (plus que la quantité) des données qui permet d’améliorer la performance du modèle et de la tester. Sans donnée de qualité, comment savoir si le pourcentage d’erreur et dû au modèle ou aux erreurs présentes dans le dataset qui ont servi à l’entrainer ?

• Évaluer la performance réelle du produit : si l’on teste la capacité technique du modèle à réaliser des sous-taches spécifiques (par exemple apprendre au modèle Tesla à détecter un feu rouge), il ne faut pas perdre de vue la valeur finale apportée à l’utilisateur. Les métriques business, définies en début de projet, représentent le contrat à remplir par l’équipe avec des critères d’acceptation basés sur des exemples concrets (si la Tesla réalise parfaitement 99.99% de ses sous-taches spécifiques, mais qu’elle écrase un passant sur un passage piéton, la valeur utilisateur n’est pas atteinte). Le Product Owner (ou Product Manager) mesure la performance des fonctionnalités et leur progression au fil du temps, ce qui permet à l’équipe d’optimiser le modèle là où il en a besoin (un modèle peut par exemple être au niveau sur les cas généraux, mais avoir besoin d’entrainement sur les cas spécifiques). Si l’équipe n’atteint pas les objectifs attendus sur une fonctionnalité, nous devons valider l’importance de cette fonctionnalité. Si elle est très importante, des investigations serons menées pour atteindre l’objectif, sinon elle sera dépriorisée (donc nous mettrons en production sans cette fonctionnalité).

• Ne pas sous-estimer les biais : si la performance globale du modèle est bonne, il est important de vérifier son comportement auprès des différentes classes de données. Un dataset d’entrainement peut comporter des données biaisées, ces biais sont appris par l’algorithme et impactent directement la performance du modèle, entrainant de potentielles conséquences éthiques (renforcées par les biais cognitifs de ceux qui développent ces algorithmes).

• Suivre dans la durée : comme pour n’importe quel site web, le monitoring est essentiel en production, mais il y a plus d’éléments à suivre pour un produit utilisant de deep learning, notamment les performances du modèle (précision pendant le ré-entraînement, retours utilisateurs, objectifs utilisateurs) et le data drift (quand les données sur lequel s’exécute le modèle diffèrent de façon trop importante des données d'entraînement).



Une cause possible du data drift: la saisonnalité (DataScientest.com)