Usage opérationnel et perspectives des solveurs

Usage opérationnel et perspectives des solveurs

Auteur : Srikanth Ramanoudjame (Ingénieur et analyste de données) avec la participation de Franck Subert (Practice Director Digital Future et Responsable des Opérations à Lyon) - Date de publication : décembre 4, 2020

Les solveurs sont une catégorie d’outils logiciels de résolution de problème. Ils prennent la modélisation d’une situation, d’un problème, à travers une description formelle, typiquement sous forme de ressources et de contraintes associées à des règles logiques, pour résoudre un problème plus ou moins complexe.

Un certain nombre de ces outils ont été développés dans le cadre de recherches et de projets en intelligence artificielle ou encore en recherche opérationnelle. Parmi ces derniers, des solveurs ont été commercialisés par des éditeurs et d’autres sont libres ou open-source.

A quoi peuvent-ils servir ? Quelles sont les différentes classes de solveurs ?

Planification complexe et excellence opérationnelle

Le bon déroulement de vos opérations est quotidiennement dépendant d’un certain nombre de tâches à réaliser, bien souvent avec des contraintes de durée, de ressources, de zone géographique, de délais admissibles, de dépendances entre tâches et de chemin critique, etc… Ce peut être des activités de planification d’essais cliniques dans l’industrie pharmacologique, de tri dans les activités postales, de flux logistiques.

Il vous faudra alors assurer une articulation optimale de ressources disponibles dans le temps (matérielles, humaines, financières…) en présence de contraintes (opérationnelles, réglementaires, temporelles…).

Ce qui permettra d’augmenter in fine l’efficience opérationnelle en optimisant :

● L’allocation de ressources associées à leurs disponibilités et nécessités

● La gestion de flux tendus (logistiques, de production…)

● L’orchestration et l’exécution de tâches interdépendantes

● …

Les problématiques de ce type, de planification complexe ou d’optimisation, peuvent être adressées au moyen d’un solveur.

Pour ce faire, il peut être utile de mener des ateliers avec le métier, des opérationnels ou décideurs en capacité de formaliser les problématiques opérationnelles en question et leurs dépendances, ainsi que les contraintes qu’ils doivent prendre en compte et elles-mêmes dynamiques (par exemple l’apparition de réglementation de données personnelles, qui amèneraient à redéfinir des politiques de rétention).

Pour tirer le maximum de valeur de votre solveur, il sera alors également utile de l’intégrer avec votre écosystème applicatif pour disposer d’une vue consolidée sur les évènements et l’état en temps réel des occurrences de processus en cours (BPMS, CEP…). Les tâches seront ainsi re-priorisées dynamiquement selon les résultats obtenus.

Perspectives d’adoption utilisateur

Il existe comme évoqué précédemment un certain nombre de solveurs sur le marché, des solutions propriétaires (AntsRoute, Asys Chronos, PetalScheduling, Praxedo…) ou bien libres (Optaplanner, Choco solver, Google OR-Tools, GEOCODE implémenté en C++, OSCAR en Scala…)

  

Ces solutions, quand elles ont été développées dans le but d’être intuitives pour le métier, sont cependant utilisées de manière très ciblée dans un nombre restreint de secteurs d’activité. La plupart des solveurs en question sont dédiés à une problématique spécifique et n’ont pas été implémentés dans une portée d’adaptabilité au-delà d’un secteur d’activité particulier.

D’autre part l’utilisation des solveurs passe par une phase initiale de modélisation du problème à résoudre et demande une compétence technique.

Les solutions génériques exposant les fonctionnalités d’un solveur sous forme par exemple de service web, aisément paramétrable par le métier pour gérer un problème d’optimisation ou de planification, sont plus absentes.

Une adoption plus large de solution basée sur les fonctionnalités d’un solveur serait par conséquent conditionnée notamment par une interface d’utilisation et de paramétrage centrée sur l’utilisateur non-technique, associée à une implémentation de solveur plus générique.

Conclusion 

Il existe aujourd’hui des solveurs très « verticaux » et axés sur des cas d’usage très spécifiques, mais qui, en contrepartie, sont davantage utilisables par l’utilisateur non-technique. A l’autre bout du spectre, il existe des solveurs plus génériques, souvent sous licences libres et nécessitant des compétences spécifiques.

Pour pallier ces limites, il serait intéressant de disposer d’un système proposant une interface permettant de construire de manière visuelle la description d’un problème générique, qui le cas échéant, pourrait être décliné en un cas plus spécifique et ciblé sur une application métier.