7 raisons d’embaucher un chercheur opérationnel dans une équipe de data scientists
Par Benoit Rottembourg, Data Scientist et Business Angel
La nouvelle vague de l’Intelligence Artificielle et de la Data Science en général a des effets collatéraux incontestables sur les organisations. Les data-labs poussent comme des champignons aux pieds des grands groupes industriels. Mycoses ou truffes noires, il est aujourd’hui difficile de trancher: Darwin reconnaîtra les siens. Mais ces nouvelles structures s’étoffent de Data Scientists et recrutent à tour de bras, dans un marché à la fois tendu et immature.
Puisque ces data-labs sont souvent le fruit d’un acte princier (le choix de la Direction Générale) et majoritairement un élément de communication, il est quasiment impossible à ce stade d’en mesurer «analytiquement» un quelconque retour sur investissement. Et c’est tant mieux. Pour avoir usé mes cordes vocales à prêcher les mathématiques décisionnelles depuis presque 30 ans, je ne peux que me réjouir de ce prompt renfort et des actes de contrition de nos dirigeants visionnaires.
Un fantasme, ça se gère mieux qu’une allergie.
Mais alors, concrètement, quels profils retenir pour renforcer ces équipes flambant neuves et quérir le Graal du ROI. Des statisticiens ? Des mathématiciens ? Des dresseurs d’IA ? Des machines learners ? Chaque data-lab doit il se doter de ses propres experts en Deep Learning ou en Reinforcement Learning? La question est d’autant plus complexe que sur le marché il est très rare de trouver des individus à double ou triple culture. On n’élève pas un Data Scientist comme un Pokémon, ça prend du temps et ils ne se reproduisent pas facilement en captivité. Sur le plan humain, pour ceux qui se soucient de créer une équipe un tant soit peu durable, le «skill mix» est crucial et fortement contraint. Il faut que la greffe prenne sur le receveur.
J’aimerais ici, mettre en avant l’intérêt du profil «chercheur opérationnel» au sein d’une équipe de Data Science en construction. Et mon argumentaire sera biaisé à deux titres:
- je suis chercheur opérationnel de formation, et j’ai enseigné cette discipline de 1989 à 2017,
- j’ai une tendresse particulière pour les entreprises à actif industriel ou humain lourd. Il est donc tout à fait possible qu’une banque ou une assurance ne se reconnaisse pas dans la valeur ajoutée que j’attribue à un chercheur opérationnel.
1. Dans complexité il y a complexité
Cela va sembler un truisme truffier mais un Data Scientist travaille en général sur des tables de millions voire de dizaines de millions de lignes. Ce peut être une liste de clients ou de prospects, les photos de l’état d’un équipement outdoor, une liste de créances plus ou moins douteuses ou les bookings d’un groupe hôtelier. Et, bien entendu, il va s’agir le plus souvent de croiser une table avec une autre, de les jointer pour en exfiltrer quelques otages pour analyse. La liste des clients dont la majorité des dates réservation a lieu en début de mois, par exemple. Croiser, filtrer, combiner, trier, clusteriser, il devient très facile de produire un algorithme dont le nombre d’opérations élémentaires est le cube de la taille de la table si l’on n’y prend garde. Et là ça coince.
L’usage de librairies open source (en R ou en python typiquement) est d’un confort sans nom, mais masque bien souvent cette complexité. Jusqu’au moment où les temps de calcul deviennent prohibitifs. On reconnaît le chercheur opérationnel bien formé – mais il n’est pas le seul – à l’analyse préalable de la complexité algorithmique de son calcul. Ceci facilite le passage à l’échelle et évite les sempiternels:
« Ca prend des heures en R, je vais devoir passer en python »
qu’on peut entendre parfois à l’ombre des écrans.
2. Prévoir avec modération
Une prévision n’a jamais fait gagner d’argent à qui que ce soit. C’est la décision prise grâce à la prévision qui compte. Se préoccuper de la décision, des variables de décision, du moment de la décision, de la séquence de décisions, et des contraintes régissant les décisions en séquence, et ceci dès le développement du modèle de prévision est crucial. On ne le répétera jamais assez.
La culture du chercheur opérationnel est plutôt monomaniaque, 
il voit des problèmes d’optimisation sous contraintes partout :
Certains vont même jusqu’à maximiser au lieu de minimiser mais ce sont déjà des rebelles. Si l’on y songe, aussi scolaire que soit cette formulation, c’est une excellente check-list pour identifier la valeur ajoutée d’une prévision (qui produit le vecteur c ou certains coefficients de A), autrement dit son contexte d’optimisation.
Exemple : Le directeur des opérations d’un grand groupe de recouvrement de créances vient nous voir un jour pour nous demander un algorithme de prévision du taux de recouvrement d’une dette à deux ans. Il nous fournit un historique d’une dizaine de millions de créances unitaires (telco, assurance, etc…) et attend de nous un « bon » algorithme de scoring afin de valoriser sa liste de créances en attente et de mieux gérer son lot. Le Data Scientist, excité comme une puce par la profusion d’exemples supervisés, régresse par ci, logite par là, CARTonne, pour finir par se promener aléatoirement en forêt et se booster les gradients comme pas deux. Son obsession est de minimiser son taux d’erreur. Son objectif implicite est d’être le meilleur possible « en moyenne » sur un jeu représentatif des données du client.
Mais en interrogeant un peu plus avant le décideur, vous réalisez vite – le chercheur opérationnel réalise vite – que ce n’est pas un bon algorithme en moyenne qu’il recherche. Car bien prévoir les mauvais payeurs n’a pas du tout le même impact économique que bien prévoir les bons. On se moque d’être précis sur les bons. En revanche, isoler un «bloc de mauvais payeurs» et les isoler proprement, sans même forcément comprendre pourquoi ils sont mauvais, revêt une valeur économique significative. En effet, l’entreprise peut alors économiser ces efforts et s’éviter par exemple des appels téléphoniques ou tout au moins appliquer à ce bloc un scénario de traitement peu dispendieux. Ainsi la fonction du score du prédicteur n’a rien à voir avec le scoring «bon en moyenne», mais bien plutôt le gain de l’opération consistant à éviter des appels téléphoniques. Et fondamentalement, il y a des algorithmes plus adaptés à cette fin que d’autres.
Consacrer de l’énergie, en amont, à définir le score économique recherché est une approche d’optimisation globale, qui aboutit à une meilleure chaîne algorithmique qu’un autisme technologique consistant à scorer d’abord et optimiser ensuite.
3. La sage femme de la contrainte
Je pense avoir modélisé en 29 ans de vie professionnelle, plusieurs centaines de problèmes d’optimisation. Cela ne m’a pas rendu riche pour autant, mais je crois que jamais, je n’ai rencontré un client industriel (détenteur de la problématique d’optimisation) capable de formuler ses contraintes correctement du premier coup.
Les trois plus fréquentes formes d’erreur sont les suivantes:
- Oublier des contraintes. Prenons l’exemple de R. R., brillant planificateur de ressources humaines dans les centres d’appels de Bouygues Telecom, aux prises avec le passage aux 35 heures et l’annualisation du temps de travail (la fameuse modulation). Je l’ai fait jurer un jour sur la tête de ses enfants (il en avait, et il en a toujours) que son problème d’optimisation d’emploi du temps était complet, et qu’il n’avait oublié aucune contrainte. Et bien, moins de 3 semaines plus tard, il réalisait que décidément non, au vu des premières solutions (parfaites, au sens de ses contraintes de la veille) que je lui fournissais, mes annualisations n’étaient pas équitables, concept qu’il venait d’introduire une fois ma solution sous le nez. Raphael, rassure toi, il est presque impossible de deviner ses contraintes (implicites) sans les avoir vu violées quelque part dans une solution. Quand par construction, vos solutions passées respectaient ces contraintes, vous vous attendez inconsciemment à les voir respectées par le nouvel algorithme. Vu du jeu de contraintes appauvri, vous sous-optimisiez, vu du jeu de contraintes enrichi, la solution du chercheur opérationnel était infaisable.
- Exagérer avec ses contraintes. Le mot contrainte est si facile à prononcer. En pricing, mes amis les directeurs marketing sont des grands adeptes de la contrainte qui tue (l’optimisation). Je me souviens d’un patron de grandes surfaces qui voulait «équilibrer ses prix» dans plus d’une centaine de magasins et multipliait les contraintes: pas plus de 5% d’écart avec le concurrent, pas plus de 10% d’écart entre deux produits de même couleur, entre deux magasins pour le même produit. Jamais finir un prix par autre chose que 0,90€ ou 9€. Nous avons recensé une 15 aine de familles de contraintes, dont certaines cherchaient à bien faire: le produit Premium devait être au moins 15% plus cher que le produit distributeur, etc … les paquets de 8 devaient être strictement moins chers à l’unité que les paquets de 4. Immanquablement, sur les 200 000 références que nous avions, lorsque nous avons lancé la résolution, la réponse était «Espace non réalisable». Il était mathématiquement impossible de trouver ne serait-ce qu’une seule solution satisfaisant la liste de contraintes, et donc hors de question d’optimiser quoi que ce soit sur un ensemble vide. Et les mois suivants ont été consacrés à assouplir les contraintes, à minimiser plutôt la somme des viols, ou le maximum des viols de ces contraintes, à hiérarchiser les dérogations, etc… de sorte à produire un ensemble réaliste de solutions, et à en trouver la meilleure. Dans certains cas l’excès de contraintes aboutit juste à une sous optimisation, ce qui est économiquement regrettable.
- Confondre processus d’optimisation et contraintes. L’homme est très doué pour optimiser. Mais il est bien souvent à la fois glouton et séquentiel dans son approche. Imaginez vous dans la peau d’un organisateur de croisière de luxe, avec à son bord 8 places assises, 4 à bâbord, 4 à tribord. Il cherche à asseoir les 8 passagers, dont il connait le poids à l’avance, afin de minimiser l’écart de masse entre bâbord et tribord, pour des raisons de sécurité. Etre glouton dans sa stratégie c’est se précipiter sur le passager le plus gros et le ranger à droite, le second plus gros à gauche, et ne plus jamais remettre ces choix en cause. Etre séquentiel c’est ensuite traiter les 6 autres passagers avec la même méthode pour les 6 places restantes. On peut parler de Business Rule, et cette stratégie n’est pas totalement idiote, elle est rapide, et surtout facile à retenir pour un humain. Malheureusement elle est notoirement sous-optimale (10% de déséquilibre en plus est fréquent). Lorsque l’organisateur donnera son avis à un chercheur opérationnel sur le point de lui développer un logiciel de placement, un phénomène étrange peut se produire. Il aura tendance à confondre Business Rule (sa façon bien à lui d’optimiser, par ordre de poids décroissant) et contrainte (le bateau ne peut être trop déséquilibré). Et c’est ainsi que le logiciel pourra se trouver sur-contraint par le fait de devoir traiter les passagers par ordre de poids décroissant… Ce qui est sous-optimal.
S’il est un talent du chercheur opérationnel c’est de faire accoucher un client de ses contraintes, avec pédagogie, bon sens économique et répartie. C’est doublement précieux, cela évite bien sûr des itérations inutiles et des sous-optimisations, mais surtout cela légitime (dans la perception du décideur) le rôle du Data Scientist, qui se rapproche, voire challenge, la réalité du processus industriel à instrumenter.
4. La vie est banalement linéaire (mais entière)
Soyons simplistes: une bonne partie des problèmes d’optimisation économiques de l’entreprise s’expriment de manière linéaire. Bien entendu, ce n’est pas vrai quand on se rapproche d’un processus physique: l’énergie consommée par un navire dépend du cube de sa vitesse, un véhicule use une chaussée dans un facteur de sa masse à la puissance quatre, etc…. C’est également notoirement faux quand on modélise des risques et surtout des covariances de risques. Mais on a vu très peu de contrôleurs de gestion utiliser des termes quadratiques dans leurs feuilles excel: on en revient bien souvent à des somme de coûts ou de recettes. Et quand les coûts sont non linéaires, comme lorsque qu’un coût de transport unitaire baisse avec la taille du camion, il reste tout à fait raisonnable de linéariser par morceaux.
En revanche, et là c’est plus douloureux, beaucoup de problèmes d’optimisation industriels comportent tout ou partie de variables entières ou binaires, comme le problème d’optimisation d’espace publicitaire de LCI ci-dessus. En supply chain, en manufacturing, en industrial asset management, en planification de ressources humaines, en pricing, en marketing direct: on calcule un nombre de camions, de palettes, de containers, de salariés, de messages publicitaires, de réservations, de places assises, et on affecte une campagne à un client ou un employé à un horaire, etc. Il y a des exceptions, comme la quantité de soja à mettre dans une recette industrielle, l’énergie produite par une éolienne à l’heure, ou des approximations continues raisonnables quand on a affaire à des grands nombres.
Et la vie est bien faite, le cœur technologique de la Recherche Opérationnelle, l’outil de base, c’est la programmation linéaire en nombres entiers. Le fameux outil magique qui résout le programme décrit en section 2. Avec un peu d’huile de coude, on sait même aujourd’hui traiter – ou tout au moins approximer – des problèmes de millions de variables. Il y a des souches résistantes bien entendu, mais c’est un traitement redoutable et en constante progression. Disposer de cette capacité de modélisation et de résolution, pour une équipe de Data Scientists est un atout considérable quand il s’agit d’optimiser un processus industriel.
5. Des «patterns» décisionnels
La vie de chercheur opérationnel ressemble parfois à un zoo. Il y collectionne des animaux aux drôles de pelage. Un problème de sac à dos par exemple: quand on cherche à maximiser la valeur nutritive des aliments qu’on emporte sans dépasser la limite de capacité. Mais également des flots, des chemins, des arbres, des affectations, des couvertures, des ensembles stables, des colorations, des d-colorations, des packings, des localisations, des routages, des subset sum. Vous ne connaissez pas le subset sum problem?: trouver parmi un ensemble d’entiers positifs ou négatifs un sous-ensemble dont la somme soit nulle. Se traite très mal par programmation linéaire.
Identifier ces structures combinatoires offre une capacité de modélisation très efficace. Lors d’un atelier avec client qui exprime sa problématique, repérer ces structures, ces «patterns décisionnels» peut permettre de proposer des approches algorithmiquement adaptées, de mettre le doigt sur les contraintes bloquantes et parfois de mesurer les gains possibles avant même de résoudre le problème. Comme dans l’exemple du croisiériste de tout à l’heure, très proche du subset sum.
6. Un peu plus près du ROI
Ah, le ROI, le fameux retour sur investissement, l’épée de Damoclès de toute équipe de Data Science qui se construit. Prenons une équipe d’une 15 aines de personnes (5 Data Scientists, 5 Data engineers et 5 software developers avec un peu de gras managérial), ajoutons-y un peu de cloud, quelques environnements de développement, des flux de données à organiser, et une pincée de consultants internes et externes sur un coulis d’assistance à maîtrise d’ouvrage. Faisons mijoter le tout pendant trois ans, une lune de miel raisonnable pour un DG bienveillant et qui peut parader dans les conseils d’administrations de ses collègues. 10 millions d’euros se sont écoulés. Comment allons nous rentrer dans nos frais?
80% des communiqués de presse qui parlent de Machine Learning citent des applications liées à la prédiction (de panne, de succès, de churn, d’achat, …) ou à la classification (images, texte, …) et les 20% restant concernent des jeux comme le Go, les échecs ou Jeopardy. Comment gagner 10 millions d’euros avec une bonne prédiction de panne? Combien faut-il d’éoliennes pour que mieux en prévoir les pannes fasse gagner cette somme. Disons 100 000. En admettant que la prévision fasse gagner 10% de coût de maintenance ce qui est déjà beau. Qui a 100 000 éoliennes?
Ce très lointain ROI, parfois inatteignable pour un acteur 
économique seul (avec moins de 100 000 éoliennes) est sans doute une des principales barrières à l’adoption industrielle de la Data Science. Au delà de la reconnaissance des photos de mon gosse sur Facebook. Or le chercheur opérationnel est un obsédé. Il veut maximiser quelque chose. Cette quête, sans doute scolaire, qui s’apparente parfois à rechercher sa bague sous un lampadaire, a quelque chose de bon: elle s’approche d’une valeur économique et incorpore des contraintes opérationnelles ou budgétaires. Elle force le trait.
7. De la data science sans data
Reprenons notre petit exemple de surcharge pondérale nautique. 8 sièges, 4 à bâbord, 4 à tribord. Cette fois, plaçons nous dans le contexte où l’organisateur ne connaît pas à l’avance le poids des passagers, mais ne les découvre qu’au fil de leur arrivée à bord. Supposons qu’il doive les asseoir sans possibilité de recours. Y a-t-il des stratégies plus malines que d’autres pour minimiser le déséquilibre du bateau? Et dans le pire des cas?
Moyennant quelques hypothèses gaussiennes sur la distribution des poids des voyageurs, et l’absence de corrélation entre ces poids – ce qui est clairement faux, sociologiquement – il est tout à fait possible de développer une bonne stratégie pour l’organisateur. Cette stratégie pouvant éventuellement être affinée quand les données (les distributions) seront connues.
Les problématiques d’optimisation (offline ou online comme nos deux problèmes d’équilibrage de masse) sont assez résistantes à la nature des données, tant que les ratios et les quantiles clés sont stables. Il n’en va pas de même pour les problématiques de classification et de prévisions, intrinsèquement sensibles aux distributions et au bruit. Dans des produits logiciels qui requièrent à la fois prévision et optimisation (en Supply Chain, en Workforce Management et en Revenue Management, par exemple) il est possible de bâtir des démarches itératives et conditionnelles de nature à minimiser les risques (une sur-prévision ou une sous-optimisation) et à raccourcir le délai de retour sur investissement.
La qualité de la prévision est une donnée pour le potentiel et le choix des méthodes d’optimisation. Symétriquement, le potentiel d’optimisation fournit une fonction score mieux calibrée économiquement pour le prévisionniste.
Conclusion
Qu’on me pardonne ce plaidoyer criard pour le profil de chercheur opérationnel. Il y a bien d’autres parcours professionnels capables d’apporter à une équipe cette compétence algorithmique, cette panoplie de modèles d’optimisations, cette sensibilité aux contraintes des processus et cette estimation des impacts économiques. Mais plus que la mise en avant d’un profil, c’est l’organisation de ce dialogue prévision/optimisation qui me semble militer pour la mixité des profils de Data Scientists au sein de l’équipe.
Cette hybridation de compétences, que je qualifie de «Agnostic Data Science», j’ai eu la chance de la vivre au sein du eLab, qui s’amusait à faire du Machine Learning en 2000 à Bouygues, ainsi que de la génération de colonnes, de la programmation par contraintes et des méthodes de voisinage. Je la vis à nouveau à la DSAI (Data Science and Artificial Intelligence), l’équipe de Data Analytics de Maersk, où se mêlent statistiques, machine learning, reinforcement learning, processus de décision markoviens et programmation linéaire en nombres entiers. Et je la recommande, même si pour équilibrer la masse d’un porte containers de 400 mètres de long, 59 de large et 18000 boîtes (dont 9000 à bâbord et 9000 à tribord) il faut aussi un peu de métier. Beaucoup de métier.
L’expert:
Pour contacter la rédaction: redaction@frenchweb.fr
Pour plus d'informations sur nos abonnements, merci de nous contacter à abonnement@frenchweb.fr
Vous souhaitez contribuer régulièrement en tant qu'expert sur FRENCHWEB.FR, merci de nous contacter à redaction@frenchweb.fr
