Synopsis d’un projet de Natural Language Processing (NLP)

Le projet commença lorsque le service conformité sollicita le service big data, demandant une application capable de scruter les articles de presse du monde entier, pour remonter de façon automatique les articles négatifs, et ainsi améliorer la performance de la surveillance de la réputation des clients.

Début 2017, les Data Scientists proposent d’élaborer un algorithme de NLP pour définir un score de négativité d’articles de presse. Ils réalisent donc un Proof Of Concept (POC) dont l’objectif est de valider la faisabilité technique de la demande. Pendant 10 mois (de février à novembre 2017), les Data Scientists développent l’algorithme sur une base d’articles analysés par des utilisateurs qui constitue la base d’entrainement. A l’issu de cette phase, le POC démontre la capacité à identifier les articles qualifiés de négatifs (#1).

Suite à ce POC et face aux résultats prometteurs, le client et l’IT décident d’industrialiser la solution, lançant le projet officiellement en janvier 2018. Pour mener cela à bien, une nouvelle équipe, séparée, est montée. Le nouveau chef de projet métier lance une phase de cadrage pendant laquelle une maquette de l’application est réalisée avec l’aide d’UX Designer d’une équipe transverse. L’architecture fonctionnelle préconise de développer la solution dans une application existante car celle-ci dispose du référentiel client interne dont a besoin le projet (#2)

En parallèle, les actions de validation du projet (dossier d’architecture et autres analyses des données disponibles) sont menées. Après trois mois le projet peut effectivement démarrer (#3).

C’est en avril 2018 que les développements commencent et sont pris en charge par une équipe déjà en place à laquelle est ajouté un développeur dédié au sujet. Cette équipe utilise le framework Scrum (sprint de deux semaines) et le Product Owner voit donc les premières démonstrations assez rapidement et peut vite constater quelques retards dus par exemple à des délais administratifs (demande d’ouverture de proxy par exemple). Dès les premières démonstrations il est observable que le plan (c’est à dire l’enchainement des développements et le contenu du premier lot) ne sera pas remis en cause par le Product Owner. En effet les découvertes et remarques des utilisateurs n’entrainent pas de mise à jour du Product Backlog (#4). De plus, lors des premières démonstrations, le produit n’est pas « potentiellement livrable » et le cycle de développement prévoit, ici, une phase de tests utilisateurs.

En Juillet, les premières démonstrations sont faites avec des utilisateurs. Bien sur, ce ne sont que les premières briques pour les utilisateurs et l’équipe vise une première version exploitable en octobre 2018 (première version est mise en homologation en septembre). C’est à dire un an et neuf mois après le début du projet (lancement du POC). Le lot 1, bientôt en production n’est pas le produit dont rêve l’utilisateur mais simplement une première version implémentant le moteur de screening des news. (#5)

Constats et leçons à tirer

Constat #1 :

• en 9mois, l’IT a répondu à la question : “sait on faire du NLP ? ». A ce stade aucun incrément de valeur n’est livré aux utilisateurs puisque le POC a été réalisé sur des données statiques et n’est donc pas utilisable.

• le POC est en grosse partie jetable puisqu’une partie du code devra être réécrite dans un autre langage suite aux normes de développement établie dans le service.

Constat #2 :

• Dans le but de réduire la charge de travail l’organisation a choisi d’implémenter la solution dans une application existante. Cette décision a des conséquences parmi lesquelles nous pouvons isoler trois effets négatifs :

• Le nouveau développeur doit comprendre le fonctionnement de l’équipe et l’architecture du produit existant.
• La dette et la complexité technique ne débutent pas de zéro puisque le nouveau module est développé sur un système existant. Dés la première ligne de code, le poids de la dette se fera donc sentir.

• Le système existant étant assez peu découplé, l’évolution d’un des modules impacte non seulement le projet mais aussi l’application existante.

Constats #3 :

• Après 1an de POC, le chef de projet lance une phase de cadrage pour notamment comprendre ce que veulent les utilisateurs. La recherche s’est focalisée sur l’algorithme (notation d’un article) plutôt que sur l’usage (quel problème cherche-t-on a résoudre pour le lecteur des articles ?)

• Afin de réaliser les maquettes, le chef de projet fait appel à un UX designer, d’un autre service ne connaissant pas le sujet (ce qui présente des avantages — neutralité, écoute active, pas de biais — mais aussi des inconvénients — mauvaise compréhension du besoin métier).

• L’industrialisation est confiée à une nouvelle équipe. Il y a un cout important de passage de connaissance (accentué par l’incapacité de certaines personnes à être emphatique et pédagogique. Pour illustrer, voila une phrase entendue : « mais si ! on lui a déjà passé la connaissance, on lui a déjà envoyé le code python du POC »)

Constats #4 :

• Grâce au cycle itératif, le client découvre assez tôt les problèmes IT et donc le dérapage du planning.

• L’équipe et en particulier le Product Owner, en ne remettant pas en cause le plan initial, utilise ce qu’on appelle water-fall-scrum. A l’intérieur de cette phase de développement, l’équipe découpe et démontre au fur et a mesure mais le plan global et les phases développement / test / production n’ont pas réellement été remises en cause.

Rejouons le projet avec une approche agile

Tous ces constats illustrent bien les problèmes que rencontrent les services travaillant en cycle Waterfall ou Water-scrum-fall. Dans une démarche agile et Lean Startup, on avance de manière itérative et incrémentale pour identifier le bon produit grâce a une succession d’expérience.

Voici les principes que nous aurions pu essayer de mettre en œuvre pour mener ce projet avec un état d’esprit agile :

Piste #1 — Culture Lean Startup

• Valider au plus vite qu’un modèle de NLP était faisable (Fallait-il investir 9 mois dans le POC pour valider la faisabilité ?)

• Avoir une démarche centrée sur l’utilisateur (démarche UX dès le début)

• Identifier le Produit Minimum Viable (MVP) afin de valider au plus tôt des hypothèses les plus risquées et mettre en place une approche permettant de collecter du feedback sur l’application dans son ensemble (UI + Back End + Model NLP).

Piste #2 : Equipe stable et amélioration continue

• Constituer une équipe stable pour éviter de devoir transmettre ou réinventer (impliquer du début à la fin les data scientists, data engineers et les développeurs front

• Laisser l’opportunité à l’équipe de s’améliorer et d’améliorer le produit.

Piste #3: Découplage et Orientation service

• Découpler les applications et mettre en place des interfaces légères pour bénéficier de l’existant sans être pénaliser par la dette technique.

Piste #4: Exploiter le feedback

• Lors des démonstrations (Sprint Review), exploiter le feedback des utilisateurs pour réorienter le développement du produit. Cela doit donc se traduire par une mise à jour du backlog produit (nouvelles priorités, nouvelles fonctionnalités).

• Interagir régulièrement et sur le long terme avec les utilisateurs (s’ils sont internes comme ici, il est très simple de les impliquer tout au long du projet).

Une image pour illustrer mon point de vue :

En conclusion, je pense que les principes de développement produit agiles (au sens large, du Lean Startup au DevOps en passant par le Design Thinking) sont applicables et même indispensables à la réussite d’un projet IA. L’approche expérimentale étant déjà au cœur du développement d’un modèle de Data science, l’équipe doit s’organiser pour appliquer cette approche sur l’ensemble du produit. Il est donc important de mettre en place la boucle d’exploration scientifique (Hypothèse -> Expérience -> Data / Résultat -> Nouvelle hypothèse …)

Et Vous ?

Dans vos projets Big Data/IA, appliquez-vous une approche agile ? Avez-vous une démarche Lean Startup pour vos produits mettant en jeu des modèles de data science ?

Retrouvez l’article de Sébastien TISSOT sur Medium