4.1.4 Comment définir la qualité du livrable
?
Il est difficile de répondre à cette question
car cela dépend beaucoup du contexte, c'est-à-dire de la
problématique à résoudre et des données à
disposition.
D'abord, il est important de comprendre que la mesure de
performance en ML est particulière, par exemple un score de
prédiction de 100% est paradoxalement un mauvais score, car cela
signifie que le classifieur généralise mal (Antidot, 2018)
(Bull-Atos, 2018).
Le score de performance habituel d'un bon classifieur se situe
entre 80 et 90 %. Au-dessus, le score serait exceptionnel et en dessous, cela
dépendrait de la problématique à résoudre. Dans
certains cas un score de 50% reste acceptable car la moitié du travail
aura été fait, mais dans d'autres plus sensibles comme la
santé, le résultat serait inexploitable (Bull-Atos, 2018)
(Sinequa, 2018). Si le modèle de classification est exploité avec
un flux de données en continu, le score doit rester au-dessus de 90%
(Sinequa, 2018), ce type d'exploitation s'obtient avec des modèles
matures.
4.1.5 Comment estimer l'opportunité ?
Pour rappel, l'intégration de solutions du Machine
Learning dans les organisations est toujours en phase exploratoire, les projets
sont souvent des POC22 (projets pilotes) qui servent à
évaluer
22 Proof of concept
44
l'opportunité et la faisabilité de ce genre de
projet, notamment en termes de coût et de délai (Microsoft, 2018)
(Antidot, 2018) (Bull-Atos, 2018). Il est par conséquent difficile de
parler de ROI23. Concernant les projets appliqués à la
gestion documentaire, les retours d'expérience sont rares (DOCUMATION,
2018).
Les arguments justifiant ce type de projet pour les
entreprises sont de deux sortes (Microsoft, 2018) (Antidot, 2018) (Bull-Atos,
2018):
- Optimiser un processus métier
- Conquérir de nouveaux marchés, développer
de nouveaux usages
4.1.6 Quels sont les principaux risques ?
Un besoin mal défini représente un risque
important. Certaines entreprises pensent à tort que le Machine Learning
peut résoudre des problèmes non résolus avec les
méthodes classiques (Microsoft, 2018) (Sinequa, 2018). La méthode
du ML a besoin de données suffisamment pertinentes et en
quantité. Lancer un projet sans prendre en compte cette condition est
sans aucun doute une prise de risque.
Un facteur de risque important se situe pendant la phase de
construction du jeu de données d'entrainement. Pour construire un
classifieur, les données d'entrainement doivent être
étiquetées à la main. Cette tâche est
rébarbative car le nombre de documents à classer manuellement
peut être élevé. L'algorithme se basera sur ces
données pour construire le modèle, donc, si l'étiquetage
est mauvais, le classifieur le sera aussi (Sinequa, 2018) (GROUIN & FOREST,
2012). Par conséquent, le facteur humain doit être pris en
compte.
Un autre facteur de risque provient des métiers qui
peuvent accueillir ce genre de projets avec méfiance (Microsoft,
2018).
| 
